SURGNET: An Integrated Surgical Data Transmission System for Telesurgery
Identifieur interne : 002051 ( Pmc/Checkpoint ); précédent : 002050; suivant : 002052SURGNET: An Integrated Surgical Data Transmission System for Telesurgery
Auteurs : Sriram Natarajan [États-Unis] ; Aura Ganz [États-Unis]Source :
- International Journal of Telemedicine and Applications [ 1687-6415 ] ; 2009.
Abstract
Remote surgery information requires quick and reliable transmission between the surgeon and the patient site. However, the networks that interconnect the surgeon and patient sites are usually time varying and lossy which can cause packet loss and delay jitter. In this paper we propose SURGNET, a telesurgery system for which we developed the architecture, algorithms and implemented it on a testbed. The algorithms include adaptive packet prediction and buffer time adjustment techniques which reduce the negative effects caused by the lossy and time varying networks. To evaluate the proposed SURGNET system, at the therapist site, we implemented a therapist panel which controls the force feedback device movements and provides image analysis functionality. At the patient site we controlled a virtual reality applet built in Matlab. The varying network conditions were emulated using NISTNet emulator. Our results show that even for severe packet loss and variable delay jitter, the proposed integrated synchronization techniques significantly improve SURGNET performance.
Url:
DOI: 10.1155/2009/435849
PubMed: 19503803
PubMed Central: 2688654
Affiliations:
Links toward previous steps (curation, corpus...)
Links to Exploration step
PMC:2688654Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">SURGNET: An Integrated Surgical Data Transmission System for Telesurgery</title><author><name sortKey="Natarajan, Sriram" sort="Natarajan, Sriram" uniqKey="Natarajan S" first="Sriram" last="Natarajan">Sriram Natarajan</name><affiliation wicri:level="4"><nlm:aff id="I1">Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003, USA</nlm:aff><country xml:lang="fr">États-Unis</country><wicri:regionArea>Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003</wicri:regionArea><placeName><region type="state">Massachusetts</region></placeName><orgName type="university">Université du Massachusetts</orgName></affiliation></author><author><name sortKey="Ganz, Aura" sort="Ganz, Aura" uniqKey="Ganz A" first="Aura" last="Ganz">Aura Ganz</name><affiliation wicri:level="4"><nlm:aff id="I1">Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003, USA</nlm:aff><country xml:lang="fr">États-Unis</country><wicri:regionArea>Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003</wicri:regionArea><placeName><region type="state">Massachusetts</region></placeName><orgName type="university">Université du Massachusetts</orgName></affiliation></author></titleStmt><publicationStmt><idno type="wicri:source">PMC</idno><idno type="pmid">19503803</idno><idno type="pmc">2688654</idno><idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2688654</idno><idno type="RBID">PMC:2688654</idno><idno type="doi">10.1155/2009/435849</idno><date when="2009">2009</date><idno type="wicri:Area/Pmc/Corpus">001105</idno><idno type="wicri:Area/Pmc/Curation">001105</idno><idno type="wicri:Area/Pmc/Checkpoint">002051</idno></publicationStmt><sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">SURGNET: An Integrated Surgical Data Transmission System for Telesurgery</title><author><name sortKey="Natarajan, Sriram" sort="Natarajan, Sriram" uniqKey="Natarajan S" first="Sriram" last="Natarajan">Sriram Natarajan</name><affiliation wicri:level="4"><nlm:aff id="I1">Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003, USA</nlm:aff><country xml:lang="fr">États-Unis</country><wicri:regionArea>Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003</wicri:regionArea><placeName><region type="state">Massachusetts</region></placeName><orgName type="university">Université du Massachusetts</orgName></affiliation></author><author><name sortKey="Ganz, Aura" sort="Ganz, Aura" uniqKey="Ganz A" first="Aura" last="Ganz">Aura Ganz</name><affiliation wicri:level="4"><nlm:aff id="I1">Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003, USA</nlm:aff><country xml:lang="fr">États-Unis</country><wicri:regionArea>Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003</wicri:regionArea><placeName><region type="state">Massachusetts</region></placeName><orgName type="university">Université du Massachusetts</orgName></affiliation></author></analytic><series><title level="j">International Journal of Telemedicine and Applications</title><idno type="ISSN">1687-6415</idno><idno type="eISSN">1687-6423</idno><imprint><date when="2009">2009</date></imprint></series></biblStruct></sourceDesc></fileDesc><profileDesc><textClass></textClass></profileDesc></teiHeader><front><div type="abstract" xml:lang="en"><p>Remote surgery information requires quick and reliable transmission between the surgeon and the patient site. However, the networks that interconnect the surgeon and patient sites are usually time varying and lossy which can cause packet loss and delay jitter. In this paper we propose SURGNET, a telesurgery system for which we developed the architecture, algorithms and implemented it on a testbed. The algorithms include adaptive packet prediction and buffer time adjustment techniques which reduce the negative effects caused by the lossy and time varying
networks. To evaluate the proposed SURGNET system, at the therapist site, we implemented a
therapist panel which controls the force feedback device movements and provides image analysis
functionality. At the patient site we controlled a virtual reality applet built in Matlab. The varying
network conditions were emulated using NISTNet emulator. Our results show that even for severe
packet loss and variable delay jitter, the proposed integrated synchronization techniques
significantly improve SURGNET performance.</p></div></front><back><div1 type="bibliography"><listBibl><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct><biblStruct></biblStruct></listBibl></div1></back></TEI><pmc article-type="research-article" xml:lang="EN"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">Int J Telemed Appl</journal-id><journal-id journal-id-type="publisher-id">IJTA</journal-id><journal-title>International Journal of Telemedicine and Applications</journal-title><issn pub-type="ppub">1687-6415</issn><issn pub-type="epub">1687-6423</issn><publisher><publisher-name>Hindawi Publishing Corporation</publisher-name></publisher></journal-meta><article-meta><article-id pub-id-type="pmid">19503803</article-id><article-id pub-id-type="pmc">2688654</article-id><article-id pub-id-type="doi">10.1155/2009/435849</article-id><article-categories><subj-group subj-group-type="heading"><subject>Research Article</subject></subj-group></article-categories><title-group><article-title>SURGNET: An Integrated Surgical Data Transmission System for Telesurgery</article-title></title-group><contrib-group><contrib contrib-type="author"><name><surname>Natarajan</surname><given-names>Sriram</given-names></name><xref ref-type="aff" rid="I1"></xref></contrib><contrib contrib-type="author"><name><surname>Ganz</surname><given-names>Aura</given-names></name><xref ref-type="aff" rid="I1"></xref><xref ref-type="corresp" rid="cor1">*</xref></contrib></contrib-group><aff id="I1">Multimedia Networks Laboratory, Electrical and Computer Science Engineering, University of Massachusetts, Amherst, MA 01003, USA</aff><author-notes><corresp id="cor1">*Aura Ganz: <email>ganz@ecs.umass.edu</email></corresp><fn fn-type="other"><p>Recommended by Robert Istepanian</p></fn></author-notes><pub-date pub-type="ppub"><year>2009</year></pub-date><pub-date pub-type="epub"><day>26</day><month>5</month><year>2009</year></pub-date><volume>2009</volume><elocation-id>435849</elocation-id><history><date date-type="received"><day>14</day><month>8</month><year>2008</year></date><date date-type="accepted"><day>18</day><month>3</month><year>2009</year></date></history><permissions><copyright-statement>Copyright © 2009 S. Natarajan and A. Ganz.</copyright-statement><copyright-year>2009</copyright-year><license license-type="open-access"><p>This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.</p></license></permissions><abstract><p>Remote surgery information requires quick and reliable transmission between the surgeon and the patient site. However, the networks that interconnect the surgeon and patient sites are usually time varying and lossy which can cause packet loss and delay jitter. In this paper we propose SURGNET, a telesurgery system for which we developed the architecture, algorithms and implemented it on a testbed. The algorithms include adaptive packet prediction and buffer time adjustment techniques which reduce the negative effects caused by the lossy and time varying
networks. To evaluate the proposed SURGNET system, at the therapist site, we implemented a
therapist panel which controls the force feedback device movements and provides image analysis
functionality. At the patient site we controlled a virtual reality applet built in Matlab. The varying
network conditions were emulated using NISTNet emulator. Our results show that even for severe
packet loss and variable delay jitter, the proposed integrated synchronization techniques
significantly improve SURGNET performance.</p></abstract></article-meta></front><body><sec sec-type="section" id="sec1"><title>1. Introduction</title><p>Remote Surgery allows the surgeon to perform surgery from remote locations without being physically present at the patient side. The high demands of this application include efficient surgical device robots and dedicated network links with reliable and high speed communication [<xref ref-type="bibr" rid="B1">1</xref>]. Surgeons in the US performed the first ever remote surgery, operating on a patient located in France via a trans-Atlantic link [<xref ref-type="bibr" rid="B2">2</xref>]. The surgery involves transferring of efficient medical information consisting of medical data such as real-time video, medical imaging, and operating surgical robots. When such real-time data with high reliability requirement is transmitted via lossy networks, the quality of temporal information gets degraded and affects the entire application.</p><p>In this paper we introduce SURGNET, a telesurgery system which enables efficient and reliable transfer of force feedback device information and medical images via lossy networks. Our system creates a closed loop architecture, that is, the update received from the remote patient side is used to perform the next movement of the force feedback device. The temporal information and irregular updates can cause the surgery device to move in the wrong direction restricting the purpose of the telesurgery. We propose algorithms that compensate for the network effects and ensure reliable transfer of such real-time data with two different synchronization techniques: intrastream and interstream. The intrastream synchronization technique modifies the output time or the rendering time at the receiver side to synchronize it with the source, and intermedia synchronization technique ensures that the closed loop structure of the architecture is maintained. In order to improve the intra-media synchronization, various research approaches have been proposed. In [<xref ref-type="bibr" rid="B3">3</xref>] the authors propose an integrated approach with a buffering scheme. In [<xref ref-type="bibr" rid="B4">4</xref>] the authors discuss the impact of delay jitter management and [<xref ref-type="bibr" rid="B5">5</xref>] discuss a moving average adaptive buffer. A dead reckoning technique which is introduced in [<xref ref-type="bibr" rid="B6">6</xref>] does not perform well in varying networking conditions. A predictor algorithm which is introduced in [<xref ref-type="bibr" rid="B7">7</xref>] linearly predicts the lost packets. However these works do not propose an integrated approach which improves the synchronization scheme for both packet loss and delay jitter. In this paper, we propose an integrated scheme which synchronizes force feedback data transmission over varying networking conditions dealing with both packet loss and delay jitter. </p><p>On the therapist side, we run a Therapist Panel GUI which shows various features of the current position of the device to the surgeon. A detailed explanation of the panel is given in the server architecture presented in <xref ref-type="sec" rid="sec2.1.1">Section 2.1.1</xref>. At the patient side (described in Section 2.1.3) we have developed and implemented an enhanced adaptive predictor algorithm which employs an adaptive extrapolation and interpolation technique to predict the lost packets. Our scheme also compensates for the intrastream synchronization by modifying the playout time of the data packet. The algorithm involves enhanced time adjustment algorithm which improves the delay between consecutive packets. The varying network conditions are emulated using NISTNet emulator (see <xref ref-type="sec" rid="sec2.1.2">Section 2.1.2</xref>). </p><p>The paper is organized as follows. In <xref ref-type="sec" rid="sec2">Section 2</xref> we discuss SURGNET system which includes the functional description of the server (therapist) and client (patient) architectures as well as the NISTNet emulator.<xref ref-type="sec" rid="sec3"> Section 3</xref> describes the proposed synchronization techniques.<xref ref-type="sec" rid="sec4"> Section 4</xref> describes our experimental results, and <xref ref-type="sec" rid="sec5">Section 5</xref> concludes the paper.</p></sec><sec sec-type="section" id="sec2"><title>2. Remote Surgery Application</title><p> SURGNET system architecture is depicted in <xref ref-type="fig" rid="fig1">Figure 1</xref>. The therapist operates the device from the server side which in turn moves the surgical device on the patient which is represented by an applet at the client side. The output of the applet can be used to update another device which performs the actual surgery on the patient. The updated positional information is sent at constant rate to the therapist wherein future movements of the device are controlled. The therapist can view the current position of the device on the Therapist Panel.</p><p>In the next subsection we provide a detailed description of the server and client architectures as well as the network emulator.</p><sec id="sec2.1"><title>2.1. Server Side</title><sec id="sec2.1.1"><title>2.1.1. Server Architecture</title><p><xref ref-type="fig" rid="fig2">Figure 2</xref> describes the functional unit of the server. At the server side we have a force feedback device (Microsoft Sidewinder Joystick) that generates real-time data. The joystick is connected to the data acquisition adapter in Matlab. An ActiveX control communicates with the joystick reads the positional information of the device, and records the movement in both <italic>X</italic> and <italic>Y</italic> axes. The end device movement controls the maximum and minimum deviation of the device and transfers it to the data processing unit which packetizes the data as UDP and sends it to the network emulator. Since UDP is an unreliable transport protocol, we run Real-Time transport Protocol (RTP) over UDP to make the communication reliable.</p><p>A detailed description of the data acquisition adapter which is designed in Matlab is given in <xref ref-type="fig" rid="fig3">Figure 3</xref>. Here an ActiveX control interfaces between the device driver and the source of the adapter. The positional and force information is obtained from the device and is transformed to update the applet at the remote location. The data obtained from the device is transmitted as UDP packets with each packet containing the positional information of the device. We run an RTP over UDP to transfer the synchronization information which includes the sequence number of each packet and the timestamp of the occurrence of each positional data.</p></sec><sec id="sec2.1.2"><title>2.1.2. Therapist Panel</title><p>The therapist panel consists of image analysis techniques which enable the surgeon to perform various manipulations on the current image received from the client (patient) side. Such manipulations are required in order to identify the requirements of the next positional movement.<xref ref-type="fig" rid="fig4"> Figure 4</xref> shows a snapshot of the therapist panel which displays the current position of the device at the remote side. The panel operates in two different modes: Monitor mode and Playback mode. When the panel is operated in the Monitor mode, the updated data is captured at regular intervals from the remote side and is updated in the panel. When the surgeon decides to inspect and manipulate a particular image, the panel switches to the Playback mode, wherein the particular image is loaded for analysis. During this time the current data from the receiver side is received and stored in the buffer. Various image manipulations can be performed during the playback mode such as gray-scale transformation techniques which can control the brightness and contrast of the image. Region of Interest (ROI) is used to select one particular location of the image to consider for further processing. Image rotation is used to rotate the picture either in the clockwise or anticlockwise direction. The server will update the client (patient) side to modify the capture location and concentrate on a particular region for further analysis.</p></sec></sec><sec id="sec2.2"><title>2.2. Network Emulator</title><p>The NISTNet network emulator [<xref ref-type="bibr" rid="B8">8</xref>] is a general-purpose tool for emulating performance dynamics in IP networks. The tool is designed to allow controlled reproducible experiments with network performance sensitive/adaptive applications and control protocols in a simple laboratory setting. By operating at the IP level, NISTNet can emulate the critical end-to-end performance characteristics imposed by various network situations. NISTNet Emulator intercepts the arriving packet and drops or introduces variable delay. Packets are modified based on the specification provided in the GUI supported by the emulator. In our experiments we tested SURGNET system with different packet loss percentages and delays. We used a Derivative Random Drop distribution which drops packets in a random fashion. The emulator which implements this functionality consists of an instrumented version of a live network implementation. NISTNet consists of two main parts: a loadable <italic>kernel module</italic>, which hooks into the normal Linux networking and real-time clock code, implements the run-time emulator and exports a set of control APIs; and a set of <italic>user interfaces</italic> which use the APIs to configure and control the operation of the kernel emulator. </p><p>The NISTNet kernel module makes use of two hooks into the Linux kernel. In order to inspect all incoming packets for potential handling, the <italic>packet intercept</italic> code seizes control of the IP packet type handler. All IP packets received by network devices are then passed directly to the NISTNet module. After <italic>packet matching</italic> determines (based on the table of emulator entries) whether and how <italic>packet processing</italic> should affect the packet, NISTNet then (possibly after delay) passes the packet on to the Linux IP level code. The <italic>fast timer</italic> takes control of the system real-time clock and uses it as a timer source for <italic>scheduling</italic> delayed packets. In the process, it reprograms the clock to interrupt at a sufficiently high rate for fine-grained packet delays.</p></sec><sec id="sec2.3"><title>2.3. Client Side</title><sec id="sec2.3.1"><title>2.3.1. Client Architecture</title><p>The adaptive buffer at the client (patient) side receives the packet and passes it to the control unit which checks the arrival sequence of packets and compensates based on the loss or delay before updating the applet (see <xref ref-type="fig" rid="fig6">Figure 6</xref>). At the client side we have developed a Virtual Reality enabled browser applet. Updated position and force information from the joystick are used to control the movement in the applet. </p><p>The delay variations and packet loss cause each data unit to arrive at the client with different time delays and varying packet loss. Due to the network impact, the data packets received at the client side do not match the data packets sent by the server, causing irregularities in the movement of the applet. To address these issues we propose an integrated synchronization scheme which is described in the next section.</p></sec><sec id="sec2.3.2"><title>2.3.2. Control Unit Flow Chart</title><p>The Control Unit at the client side checks for the sequence of arriving packets to determine which synchronization algorithm to run. In case there is no loss but there is delay jitter we invoke the enhanced time adjustment algorithm that maintains 1 millisecond time difference between consecutive packets. If the time difference between consecutive packets is more than 1 millisecond, then time contraction is selected and if the difference is less than 1 millisecond, then time expansion is selected. When a packet is lost, the control unit runs the adaptive predictor algorithm to predict the missing positional value. The predicted value is passed to the buffer for further processing and applet update.</p></sec><sec id="sec2.3.3"><title>2.3.3. Virtual Reality Applet</title><p>Force feedback rendering is tested based on the synchronized movement of the two devices at the server and client sides. In our architecture we have implemented a Virtual Reality applet which runs on the browser on the client side (see <xref ref-type="fig" rid="fig8">Figure 8</xref>). The applet is similar to the vrcrane_joystick applet which is supported by the Matlab Virtual Reality toolbox. We have modified the applet to work in our application and enable the control from the remote application. When the source sidewinder joystick device is moved at the therapist side, we control the applet movement running on the client machine.</p><p>The applet which is developed in Matlab [<xref ref-type="bibr" rid="B9">9</xref>] contains a load hanging on the crane. The crane can move in <italic>X</italic> and <italic>Z</italic> axes. Here the <italic>Y</italic> axis movement is restricted and hence is not taken into consideration. Initial movement of the joystick will set the place where the load will move and when the force is applied then the actual movement of the load will take place. This will result in both the position and force value transferred from the server to the client side. In our application we have modified the vrcrane_joystick applet in Matlab by integrating force updates.</p><p>The joystick at the therapist side generates the data and sends it to the data acquisition adapter. The data is then processed and segregated into packets. Each packet contains both force as well as the position values. These UDP packets are sent through the emulated network. Once the data reaches the client side, the adaptive buffer will store it and process it in the control unit. The control unit decides whether to run the adaptive predictor algorithm, if there is a packet loss, or passes the packet to the Virtual Time Rendering Algorithm which determines when to update the applet based on the timestamp and adjusts the difference in the actual received time of consecutive data.</p></sec></sec></sec><sec sec-type="section" id="sec3"><title>3. Synchronization Techniques </title><p>Our compensation techniques involve a combination of an adaptive predictor algorithm and an enhanced time adjustment algorithm. The proposed synchronization schemes are discussed in detail in the next subsections.</p><sec id="sec3.1"><title>3.1. Adaptive Predictor Algorithm</title><p>The force feedback data is time sensitive and used in real-time applications. Therefore, retransmission of lost packets is not desirable. In order to compensate for the packet loss, we implement an adaptive predictor algorithm which will employ extrapolation or interpolation techniques. When sufficient future packets are received we use interpolation techniques to predict the missing packet. In case a number of consecutive packets are lost we invoke extrapolation techniques. </p><p>Packets are transmitted using the UDP protocol. Since UDP is unreliable, we run RTP over UDP to make a reliable connection. Since the packets are generated every millisecond, the receiver checks the sequence number of all arriving packets. Once it detects loss, the control unit sends the packet to the Predictor Unit which predicts the value of the position of the device based on the previously arrived packet. For Interpolation, a future packet is also considered. As the rate of change in position is lower than the rate at which the packets are generated, we determine the position of the lost packet based on the neighbor packets. </p><p><statement id="head1"><title>Extrapolation Technique</title><p>we denote packet <italic>n</italic> as <italic>P</italic><sub><italic>n</italic></sub> and assume that if that packet is lost, then the predictor determines the value of the lost packet based on the value of packets <italic>P</italic><sub><italic>n</italic>−1</sub>, <italic>P</italic><sub><italic>n</italic>−2</sub>. In our experiment, our results show better performance when considering the last two packets during extrapolation. The extrapolation prediction model is given by
<disp-formula id="Eq1"><label>(1)</label><mml:math id="M1"><mml:msub><mml:mrow><mml:mi>P</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msqrt><mml:mfrac><mml:mrow><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:mfrac><mml:munderover><mml:mstyle displaystyle="true"><mml:mo>∑</mml:mo></mml:mstyle><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:mrow><mml:msup><mml:mrow><mml:mrow><mml:mo>(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>P</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>-</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup></mml:mrow></mml:msqrt><mml:mo>,</mml:mo></mml:math></disp-formula>where <italic>n</italic> = 2 (previous two packets are included).</p><p>The prediction model is a mathematical operation in estimating future values as a linear function. In (<xref ref-type="disp-formula" rid="Eq1">1</xref>) the root mean square criterion or the quadratic mean is calculated, which gives a statistical measure of the value of <italic>P</italic><sub><italic>n</italic></sub>. This measure is specifically used when the variants are both positive and negative. In our experiment the <italic>X</italic>-axis position varies in both positive and negative direction and hence this technique predicts efficiently the closest value.</p></statement></p><p><statement id="head2"><title>Interpolation Technique</title><p>If the buffer contains packet <italic>P</italic><sub><italic>n</italic>+1</sub>, we use this information to consider an interpolation technique to predict the lost packet. The interpolation prediction model is given by
<disp-formula id="Eq2"><label>(2)</label><mml:math id="M2"><mml:msub><mml:mrow><mml:mi>P</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msqrt><mml:mfrac><mml:mrow><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:mfrac><mml:mrow><mml:mo>[</mml:mo><mml:mrow><mml:munderover><mml:mstyle displaystyle="true"><mml:mo>∑</mml:mo></mml:mstyle><mml:mrow><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:munderover><mml:mrow><mml:msup><mml:mrow><mml:mrow><mml:mo>(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>P</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>-</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo>)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup></mml:mrow><mml:mo>+</mml:mo><mml:msup><mml:mrow><mml:mo minsize="1em" maxsize="1em">(</mml:mo><mml:msub><mml:mrow><mml:mi>P</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo minsize="1em" maxsize="1em">)</mml:mo></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup></mml:mrow><mml:mo>]</mml:mo></mml:mrow></mml:msqrt><mml:mo>,</mml:mo></mml:math></disp-formula>where <italic>n</italic> = 3 (previous two packets and one future packet are included).</p><p>Equation (<xref ref-type="disp-formula" rid="Eq2">2</xref>) shows the calculation for interpolation where the quadratic mean uses three values. The optimization of the parameter can be adaptively selected and set to reduce the error. The data that is received in the buffer arrive at high data rate (1 millisecond) and hence considering the closest arrived packets in such calculations gives better results.</p></statement></p></sec><sec id="sec3.2"><title>3.2. Enhanced Time Adjustment Algorithm</title><p>The Time Adjustment algorithm modifies the play out time of the packet which modifies the update rate of the applet to ensure that it synchronizes with the source. The intrapacket arrival time to the client side is variable. As explained above, in order to deliver to the applet the force feedback information as generated by the Joystick we need to keep a constant interpacket arrival delay of 1 millisecond. The proposed algorithm will adjust this time gap to 1 millisecond.</p><p>There are two cases that we have to consider: the time gap is smaller or larger than 1 millisecond. In such cases we need to run time expansion and time contraction, respectively. The time adjustment algorithm works similar to [<xref ref-type="bibr" rid="B9">9</xref>], but we do not assume any random process to the arrival of the data, as our approach runs the predictor algorithm. Adaptively the algorithm checks the arrival time of the packets and selects either virtual time contraction or virtual time expansion to adjust the intrapacket difference between the packets to be 1 millisecond. Before we describe the time adjustment algorithm, we first define the following terms: </p><list list-type="roman-lower"><list-item><p><italic>ts</italic><sub><italic>n</italic></sub>—the timestamp of <italic>n</italic>th data when generated at the server,</p></list-item><list-item><p><italic>tr</italic><sub><italic>n</italic></sub>—the timestamp of <italic>n</italic>th data when received at the client, </p></list-item><list-item><p><italic>td</italic><sub><italic>n</italic></sub>—the timestamp of <italic>n</italic>th data when updated in the applet,</p></list-item><list-item><p><italic>τ</italic>—Packet processing delay at the receiver side.</p></list-item></list><p>The following inter-arrival times between two consecutive packets are defined as follows </p><list list-type="roman-lower"><list-item><p>Source (at the server) inter-arrival time
<disp-formula id="Eq3"><label>(3)</label><mml:math id="M3"><mml:mi>T</mml:mi><mml:mi>s</mml:mi><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:math></disp-formula></p></list-item><list-item><p>Received (at the client) inter-arrival time
<disp-formula id="Eq4"><label>(4)</label><mml:math id="M4"><mml:mi>T</mml:mi><mml:mi>r</mml:mi><mml:mi>i</mml:mi><mml:mo>=</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:math></disp-formula></p></list-item><list-item><p>Processed inter-arrival time
<disp-formula id="Eq5"><label>(5)</label><mml:math id="M5"><mml:mi>T</mml:mi><mml:msub><mml:mrow><mml:mi>d</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>d</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>d</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>(</mml:mo><mml:mrow><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>r</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:mi>τ</mml:mi></mml:mrow><mml:mo>)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:math></disp-formula></p></list-item><list-item><p>Time adjustment factor
<disp-formula id="Eq6"><label>(6)</label><mml:math id="M6"><mml:mi>β</mml:mi><mml:mo>=</mml:mo><mml:mi>T</mml:mi><mml:msub><mml:mrow><mml:mi>d</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mn>1</mml:mn><mml:mo>.</mml:mo></mml:math></disp-formula></p></list-item></list><p>The applet update time <italic>Ta</italic><sub><italic>i</italic>+1</sub> uses the following time adjustment algorithm: </p><p><disp-formula id="Eq7"><label>(7)</label><mml:math id="M7"><mml:mi>T</mml:mi><mml:msub><mml:mrow><mml:mi>a</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn><mml:mi> </mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>d</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>-</mml:mo><mml:mi>β</mml:mi><mml:mo>;</mml:mo><mml:mo> </mml:mo><mml:mtext>if </mml:mtext><mml:mi>β</mml:mi><mml:mo>></mml:mo><mml:mn>0</mml:mn><mml:mo>,</mml:mo></mml:math></disp-formula><disp-formula id="Eq8"><label>(8)</label><mml:math id="M8"><mml:mi>T</mml:mi><mml:msub><mml:mrow><mml:mi>a</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mi>t</mml:mi><mml:msub><mml:mrow><mml:mi>d</mml:mi></mml:mrow><mml:mrow><mml:mi>n</mml:mi><mml:mo>+</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>+</mml:mo><mml:mi>β</mml:mi><mml:mo>;</mml:mo><mml:mo> </mml:mo><mml:mtext>if</mml:mtext><mml:mi> </mml:mi><mml:mi> </mml:mi><mml:mi>β</mml:mi><mml:mo><</mml:mo><mml:mn>0</mml:mn><mml:mo>.</mml:mo></mml:math></disp-formula></p><p>The buffering scheme receives the packets from the network, and the control unit checks for continuity of packets by analyzing the sequence number with the RTP information. If the packets arrive in order then the packets are passed to the time adjustment algorithm. Equation (<xref ref-type="disp-formula" rid="Eq4">4</xref>) calculates the time difference between the received sequential packets from the network. Each packet in the receiver takes different processing time, and (<xref ref-type="disp-formula" rid="Eq5">5</xref>) calculates the time change after processing. The applet update time is the time when the actual applet movement takes place corresponding to the movement of the force feedback device at the server side. Hence a time adjustment factor is required to readjust the time difference between the packets before updating the applet. By default the time difference between the packets should be maintained as 1 millisecond. The processed time depends on the time adjustment factor <italic>β</italic> that selects to run either the Time Contraction or Time Expansion to adaptively run and synchronize the server and client. The algorithm checks the timestamp value of the processed packets. If the time difference after processing time between the packets is more than 1 millisecond (<italic>β</italic> > 0), (<xref ref-type="disp-formula" rid="Eq7">7</xref>) Time Contraction is processed with the first packet time as reference time and adjusting the sequential packet time to 1 millisecond more. If the time difference is less than 1 millisecond (<italic>β</italic> < 0), (<xref ref-type="disp-formula" rid="Eq8">8</xref>) Time Expansion is processed with the first packet time as reference and adjusting the sequential packet time.</p></sec></sec><sec sec-type="section" id="sec4"><title>4. Experiments</title><sec id="sec4.1"><title>4.1. Testbed</title><p>As depicted in <xref ref-type="fig" rid="fig9">Figure 9</xref> the testbed consists of a Server (see <xref ref-type="sec" rid="sec2.1">Section 2.1</xref>), NISTNet Emulator (see <xref ref-type="sec" rid="sec2.2">Section 2.2</xref>) and a Client (see <xref ref-type="sec" rid="sec2.3">Section 2.3</xref>). </p><p><statement id="head3"><title>Server</title><p>The Microsoft Sidewinder Force Feedback Device which is connected to the Server has a rendering rate of 1 Khz. For convenience, we have only recorded <italic>X</italic>-axis movements for the joystick. The generated data <italic>X</italic>-axis position also moves in the negative axis due to the fact that the base of the handle in the Sidewinder Joystick is located in the center. We programmed the joystick to output negative values when the handle moves to the left and positive values when it moves to the right. </p><p>The Server runs the Matlab Processing Unit which takes input from the joystick and reads the Axis and button values from the data acquisition adapter. The server runs on a Dell Inspiron 5150 Windows XP machine, with 2.8 GHz and memory of 512 RAM.</p></statement></p><p><statement id="head4"><title>NISTNet Emulator</title><p>The Network Emulator (NISTNet) is setup on an IBM Centrino, Linux machine. The machine is treated as a router which takes input from the server, processes the packets (drops and/or delays them), and sends them to the client side. NISTNet Emulator runs on a Fedora Core 2.6.11 machine with Real Time Clock setup as separate module from the Kernel. </p></statement></p><p><statement id="head5"><title>Client Side</title><p>The Client side runs the Virtual Reality Applet. The Client side runs on an Intel Pentium 4, XP with 2 GHz and 256 of RAM Memory.</p></statement></p></sec><sec id="sec4.2"><title>4.2. Experiments</title><p><statement id="casee1"><title>Case 1</title><p><bold>Loss only.</bold> We first verify the proposed synchronization algorithms for the case in which only loss occurs in the network. The server side data was generated by random movements of the joystick handle. Positional data variations are within the maximum limit of 100 in the positive axis and −100 in the negative axis. The data generated at the server side is shown in <xref ref-type="fig" rid="fig10">Figure 10</xref>.<xref ref-type="fig" rid="fig11"> Figure 11(a)</xref> depicts the data received at the client side with 20% loss. The deviation between the generated data and the predicted data received at the client side is shown in <xref ref-type="fig" rid="fig11">Figure 11(b)</xref>.<xref ref-type="fig" rid="fig12"> Figure 12</xref> which depicts the positional data comparison between the server and the client side shows an almost perfect synchronization (with the maximum percentage deviation of 2.89%.). We also calculated the maximum percentage deviation for various percentages of loss The results are tabulated in <xref ref-type="table" rid="tab1">Table 1</xref>. </p></statement></p><p><statement id="casee2"><title>Case 2</title><p><bold>Delay jitter only.</bold> The emulator introduces random variable delay for each packet sent from the server. For each packet sent from the server, the time difference between the packets should be 1 millisecond.<xref ref-type="fig" rid="fig13"> Figure 13(a)</xref> shows the packets received at the client after the random delay has been introduced, and <xref ref-type="fig" rid="fig13">Figure 13(b)</xref> shows the time adjusted position which modifies the time difference between the packets to 1 millisecond. </p></statement></p><p><statement id="casee3"><title>Case 3</title><p><bold>Loss and delay jitter.</bold><xref ref-type="fig" rid="fig14">Figure 14(a)</xref> shows both packet loss and delay jitter between packets. In our integrated approach the control unit predicts the lost packet and passes the packet to the Time Adjustment unit which modifies the playback time.<xref ref-type="fig" rid="fig14"> Figure 14(b)</xref> shows the output of predicted packet with delay and the corresponding integrated synchronization scheme. <xref ref-type="fig" rid="fig15">Figure 15</xref> gives a comparative analysis between the data generated at the server side and predicted and time adjusted data at the client side. The results indicate the efficiency of our integrated algorithms and show their effectiveness in controlling the applet by the force feedback device. The control unit first runs the packet predictor algorithm and then the time adjustment algorithm before updating the applet. The total delay for the first 50 packets was 127 milliseconds, but after readjusting the delay, the inter-packet delay between the packets is modified to 1 millisecond and hence the overlap occurs in time.</p></statement></p></sec></sec><sec sec-type="section" id="sec5"><title>5. Conclusion and Future Work</title><p>We designed implemented, and tested SURGNET, an integrated remote surgery system. SURGNET enables the use of a force feedback device in remote surgery in spite of severe network impairments. The proposed algorithms address both the packet loss and delay jitter issues which are major constraints in time varying networks. We have also integrated medical image analysis functionality along with the force feedback data by introducing the Therapist panel. Our results show that in spite of severe loss and network delay conditions, the proposed algorithms successfully synchronized the applet at the patient side with the device on the therapist side, enabling a smooth manipulation of the surgical instruments. In our future work we plan to implement multicasting and group synchronization of devices in time varying networks.</p></sec></body><back><ack><title>Acknowledgment</title><p>This project was supported in part by the following Grants: NSF-ANI-0434985, NSF-ANI-0319871, and NSF-EIA-0080119.</p></ack><ref-list><ref id="B1"><label>1</label><citation citation-type="book"><person-group person-group-type="author"><name><surname>Basdogan</surname><given-names>C</given-names></name><name><surname>Srinivasan</surname><given-names>MA</given-names></name></person-group><person-group person-group-type="editor"><name><surname>Stanney</surname><given-names>K</given-names></name></person-group><article-title>Haptic rendering in virtual environments</article-title><source><italic>Handbook of Virtual Environments</italic></source><year>2001</year><publisher-loc>Mahwah, NJ, USA</publisher-loc><publisher-name>Lawrence Erlbaum</publisher-name><fpage>117</fpage><lpage>131</lpage></citation></ref><ref id="B2"><label>2</label><citation citation-type="other"><person-group person-group-type="author"><name><surname>Parsell</surname><given-names>DL</given-names></name></person-group><article-title>National Geographic News</article-title><comment><ext-link ext-link-type="uri" xlink:href="http://news.nationalgeographic.com/news/2001/09/0919_robotsurgery.html">http://news.nationalgeographic.com/news/2001/09/0919_robotsurgery.html</ext-link>.</comment></citation></ref><ref id="B3"><label>3</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>You</surname><given-names>Y</given-names></name><name><surname>Sung</surname><given-names>MY</given-names></name><name><surname>Jun</surname><given-names>K</given-names></name></person-group><article-title>An integrated haptic data transmission in haptic collaborative virtual
environments</article-title><conf-name>In: Proceedings of the 6th IEEE/ACIS International Conference on Computer and Information Science (ICIS '07)</conf-name><conf-date>July 2007</conf-date><conf-loc>Melbourne, Canada</conf-loc><fpage>834</fpage><lpage>839</lpage></citation></ref><ref id="B4"><label>4</label><citation citation-type="journal"><person-group person-group-type="author"><name><surname>Stone</surname><given-names>DL</given-names></name><name><surname>Jeffay</surname><given-names>K</given-names></name></person-group><article-title>An empirical study of delay jitter management policies</article-title><source><italic>Multimedia Systems</italic></source><year>1995</year><volume>2</volume><issue>6</issue><fpage>267</fpage><lpage>279</lpage></citation></ref><ref id="B5"><label>5</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Wongwirat</surname><given-names>O</given-names></name><name><surname>Ohara</surname><given-names>S</given-names></name></person-group><article-title>Moving average based adaptive buffer for haptic media
synchronization in telehaptics</article-title><conf-name>In: Proceedings of IEEE/ASME International Conference on Advanced Intelligence Mechatronics</conf-name><conf-date>July 2005</conf-date><conf-loc>Monterey, Calif, USA</conf-loc><fpage>1305</fpage><lpage>1311</lpage></citation></ref><ref id="B6"><label>6</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Hikichit</surname><given-names>K</given-names></name><name><surname>Morino</surname><given-names>H</given-names></name><name><surname>Arimoto</surname><given-names>I</given-names></name><name><surname>Sezaki</surname><given-names>K</given-names></name><name><surname>Yasuda</surname><given-names>Y</given-names></name></person-group><article-title>The evaluation of delay jitter for haptics collaboration over the internet</article-title><conf-name>In: Proceedings of IEEE Global Telecommunications Conference (GLOBECOM '02), vol. 2</conf-name><conf-date>November 2002</conf-date><conf-loc>New York, NY, USA</conf-loc><fpage>1492</fpage><lpage>1496</lpage></citation></ref><ref id="B7"><label>7</label><citation citation-type="confproc"><person-group person-group-type="author"><name><surname>Boukerche</surname><given-names>A</given-names></name><name><surname>Shirmohammadi</surname><given-names>S</given-names></name><name><surname>Hossain</surname><given-names>A</given-names></name></person-group><article-title>A prediction algorithm for haptic collaboration</article-title><conf-name>In: Proceedings of IEEE International Workshop on Haptic Audio Visual Environments and Their Applications (HAVE '05)</conf-name><conf-date>October 2005</conf-date><conf-loc>Ottawa, Canada</conf-loc><fpage>1</fpage><lpage>5</lpage></citation></ref><ref id="B8"><label>8</label><citation citation-type="other"><collab>NIST Net</collab><comment><ext-link ext-link-type="uri" xlink:href="http://www-x.antd.nist.gov/nistnet/">http://www-x.antd.nist.gov/nistnet/</ext-link>.</comment></citation></ref><ref id="B9"><label>9</label><citation citation-type="other"><collab>Matlab</collab><comment><ext-link ext-link-type="uri" xlink:href="http://www.mathworks.com/">http://www.mathworks.com/</ext-link>.</comment></citation></ref></ref-list></back><floats-wrap><fig id="fig1" position="float"><label>Figure 1</label><caption><p>SURGNET architecture.</p></caption><graphic xlink:href="IJTA2009-435849.001"></graphic></fig><fig id="fig2" position="float"><label>Figure 2</label><caption><p>Server functional description.</p></caption><graphic xlink:href="IJTA2009-435849.002"></graphic></fig><fig id="fig3" position="float"><label>Figure 3</label><caption><p>Data acquisition adapter.</p></caption><graphic xlink:href="IJTA2009-435849.003"></graphic></fig><fig id="fig4" position="float"><label>Figure 4</label><caption><p>Snapshot of therapist panel GUI.</p></caption><graphic xlink:href="IJTA2009-435849.004"></graphic></fig><fig id="fig5" position="float"><label>Figure 5</label><caption><p>NISTNet emulator.</p></caption><graphic xlink:href="IJTA2009-435849.005"></graphic></fig><fig id="fig6" position="float"><label>Figure 6</label><caption><p>Client functional description.</p></caption><graphic xlink:href="IJTA2009-435849.006"></graphic></fig><fig id="fig7" position="float"><label>Figure 7</label><caption><p>Control unit flow chart.</p></caption><graphic xlink:href="IJTA2009-435849.007"></graphic></fig><fig id="fig8" position="float"><label>Figure 8</label><caption><p>Applet at the client side.</p></caption><graphic xlink:href="IJTA2009-435849.008"></graphic></fig><fig id="fig9" position="float"><label>Figure 9</label><caption><p>SURGNET testbed.</p></caption><graphic xlink:href="IJTA2009-435849.009"></graphic></fig><fig id="fig10" position="float"><label>Figure 10</label><caption><p>Data generated at server.</p></caption><graphic xlink:href="IJTA2009-435849.010"></graphic></fig><fig id="fig11" position="float"><label>Figure 11</label><caption><p>(a) Data received at client (20% loss) <italic>unsynchronized.</italic> (b) X-Axis positional deviation (20% Loss) <italic>synchronized.</italic></p></caption><graphic xlink:href="IJTA2009-435849.011"></graphic></fig><fig id="fig12" position="float"><label>Figure 12</label><caption><p>Comparison between generated data at server and <italic>synchronized</italic> data at client.</p></caption><graphic xlink:href="IJTA2009-435849.012"></graphic></fig><fig id="fig13" position="float"><label>Figure 13</label><caption><p>(a) Variable Delay <italic>unsynchronized</italic> data. (b) Variable Delay <italic>synchronized</italic> data.</p></caption><graphic xlink:href="IJTA2009-435849.013"></graphic></fig><fig id="fig14" position="float"><label>Figure 14</label><caption><p>(a) 20% Loss with Variable delay, <italic>unsynchronized</italic> data. (b) 20% Loss with Variable delay, <italic>synchronized</italic> data.</p></caption><graphic xlink:href="IJTA2009-435849.014"></graphic></fig><fig id="fig15" position="float"><label>Figure 15</label><caption><p><italic>X</italic>-axis Positional Deviation Comparison at Server and Client Side.</p></caption><graphic xlink:href="IJTA2009-435849.015"></graphic></fig><table-wrap id="tab1" position="float"><label>Table 1</label><caption><p>Maximum percentage deviation of the predicted value of <bold>X</bold>-Axis position at client.</p></caption><table frame="hsides" rules="groups"><thead><tr><th align="left" rowspan="1" colspan="1">Loss</th><th align="center" rowspan="1" colspan="1">10% </th><th align="center" rowspan="1" colspan="1">15% </th><th align="center" rowspan="1" colspan="1">20%</th></tr></thead><tbody><tr><td align="left" rowspan="1" colspan="1">Maximum Percentage Deviation</td><td align="center" rowspan="1" colspan="1">1.48%</td><td align="center" rowspan="1" colspan="1">2.21%</td><td align="center" rowspan="1" colspan="1">2.89%</td></tr></tbody></table></table-wrap></floats-wrap></pmc><affiliations><list><country><li>États-Unis</li></country><region><li>Massachusetts</li></region><orgName><li>Université du Massachusetts</li></orgName></list><tree><country name="États-Unis"><region name="Massachusetts"><name sortKey="Natarajan, Sriram" sort="Natarajan, Sriram" uniqKey="Natarajan S" first="Sriram" last="Natarajan">Sriram Natarajan</name></region><name sortKey="Ganz, Aura" sort="Ganz, Aura" uniqKey="Ganz A" first="Aura" last="Ganz">Aura Ganz</name></country></tree></affiliations></record>Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Ticri/CIDE/explor/HapticV1/Data/Pmc/Checkpoint
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 002051 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Checkpoint/biblio.hfd -nk 002051 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien
|wiki= Ticri/CIDE
|area= HapticV1
|flux= Pmc
|étape= Checkpoint
|type= RBID
|clé= PMC:2688654
|texte= SURGNET: An Integrated Surgical Data Transmission System for Telesurgery
}}
Pour générer des pages wiki
HfdIndexSelect -h $EXPLOR_AREA/Data/Pmc/Checkpoint/RBID.i -Sk "pubmed:19503803" \
| HfdSelect -Kh $EXPLOR_AREA/Data/Pmc/Checkpoint/biblio.hfd \
| NlmPubMed2Wicri -a HapticV1
| This area was generated with Dilib version V0.6.23. |  |