Real-Time Protocols for Communication and Collaboration Environments in Telemedical Applications

The world is now moving in the era of high information and communication technology. Under the term telemedicine and tele-cooperation research series are carried out presently, intended to enable and expand a distributed, group-related cooperative work within the area of medicine. For this purpose, applications are needed, which support real-time control processes, distributed applications, communication and cooperation technology, and the representation of shared information and data. Real-Time Protocols are the basis of telemedical applications. They are needed in almost all fields of telemedicine reaching from communication transmission to reliable data transfer. In a telemedical system, how these real-time protocols are used for communications, collaboration with telemedicine applications is worth to be explored and has been discussed in this research article along with the challenges of real-time applications and their solutions by using real-time protocols.


I. INTRODUCTION
Nowadays, a lot of researches are going on to expand a distributed, group-related cooperative work within the area of medicine, supported by Information and Communication Technologies (ICT). Under the title of telemedicine, different applications are required which can support real-time control processes, distributed applications, communication, and cooperation technology, and the representation of shared information and data. For this purpose, different application-level real-time protocols are to be used for telemedical applications [1][2][3]. Suitable real-time protocols are investigated in this article that can be used in the telemedical applications required in the most common scenario of telemedicine as shown in figure 1. Where there is an experiment/operation going on in the near-end with the help of different telemedicine applications and devices. Two assistants are present in the near end to assist experts who are in the far end/s. Experts can monitor (EGC pulse, blood pressure, and other sensor information), guide and control the experiment i.e., this entire transmission is in real-time. Different types of delivery options (exchange of information) are possible during the experiment. Exchange of information can be in either real-time or store-and-forward communication [4] and [5]. Examples of real-time telemedical transactions include live audio/video conference, the examination of the patient, auscultation of heart and lung sound, and reports examination, i.e., X-ray, Computed Tomography (CT) [6], Magnetic Resonance Imaging (MRI) [7], Ultrasound, etc.
In the case of exchanging information in real-time, one must be careful about response time, bandwidth, data rate, delay, jitter, error and loss rate, reliability, etc. In contrast with the real-time method, in the store-andforward method, a set of medical information is compiled and sent to the experts for their review and interpretation as per their convenience. Examples of medical information for this method can be paper Electrocardiogram (ECG), the combination of still image frames, audio/video clips, and other related stuff [8] and [9]. In telemedicine, the quality of audio/video data and vital signal data has high importance, based on these data, doctors can make medical decisions. Lack of important information due to any reason may lead to erroneous decisions which can badly affect the overall outcome of a certain telemedical event.
To prevent this, one should always keep in mind the networks through which telemedicine applications transmit medical information (audio, video, and data). These networks must fulfill the minimum requirements (bandwidth, data rate, etc.) for the telemedical applications so that minimum transmission error/problems can be observed.  figure 1. Some of the aspects are given below:

A. Video/Audio
In Audio/Video (A/V), the camera and microphone are the most important devices. The feature of audio/ video is very time-critical for Real-Time (RT) transmission and reception. To have a smooth and error-free transmission/reception, real-time issues, such as types of data to be transmitted (for audio/video), control over the delivery of data, correct ordering in reception, delay, jitter, synchronization, packet loss, recording, encoding/compression schemes, bandwidth issue, network problem, etc. should be minimized as much as possible. To analyze the operation later, there will also be an option of recording so that both parties can discuss or evaluate the operation when needed or make evidence of any specific task performed in the ongoing operation.
B. Object Data (e.g., Medical Records) Medical records like X-ray reports, patient history, blood test reports, etc. are not time-critical. However, an errorfree transaction is needed. The expected issue, in this case, can be the size of data, packet loss, network problems, etc.
C. Real-Time Object Data (e.g., ECG, Sensors) This type of data object falls in the category of real-time data, which is off-course time-critical data and a reliable connection is required. Sending real-time information to the expert about the heart rate of patients, blood pressure, and other sensor information about operated parts of the patient's body must be delivered in time without any delay and error. Possible issues for the real-time object data can be; types of data to be transmitted (audio/video), delay, jitter, synchronization, packet loss, recording, encoding/compression schemes, bandwidth issue, network problems, etc.

D. Robot Control
It is very crucial that while operating (especially in surgery) perfect cutting of skin or veins can take place. It requires accurate calculation and measurement. If this operation is performed by a human then a big possibility of human error is there which may affect the life of the patient. To overcome this, the need of telemedicine application that controls the robot arm is required which can perform accurate cutting or other measurements required by the operation without error/s. This robotic arm [10] and [11] is very time-critical as it cannot afford to have a delay in instruction or any problem in a network through which it is being operated.

E. Instructions Via Chat
Telemedicine applications that can facilitate near and farend sites to communicate through messages are also required in this research scenario. Here timing is not so critical, however, there are still some issues that can cause problems in the successful running of these applications, some of these issues are packet loss, encoding /compression schemes, network problems, connection reestablishment, Internet Protocol mobility, etc.

A. User Datagram Protocol (UDP)
To make applications in use, suitable protocols are required which are used to work on the application layer. In the case of telemedicine, we need real-time protocols that are the basis of telemedical applications. In this section, there will be a focus on only those real-time protocols that can fulfill the requirements of a given telemedicine scenario see figure 1. In telemedical applications, User Datagram Protocol (UDP) [12] and [13] is very well suited where quick responses/queries are required. UDP is a connection-less protocol. Data transmission is unreliable in this service, it is because there will be no acknowledgment segments to the user when data is received or any information to the sender when data is lost. This will affect the integrity of data which can be suffered due to the drop of packets. As there is no error detection in this protocol, packets can be miss-sequenced. When UDP is to be used in telemedicine, it is the responsibility of the application layer to arrange to acknowledge message receipt; the proper ordering of received packets which make it into meaningful messages, get rid of duplicate packets and requesting retransmission of faulty packets. Some of the key advantages of UDP include small packet size, high speed, no retransmission delay, etc.

B. Transmission Control Protocol (TCP)
Transmission Control Protocol (TCP) [14] is a transport layer protocol. In telemedicine, this protocol is commonly used by the application that requires guaranteed end-toend delivery of data. In other words, telemedical applications that are relatively less time-critical used to prefer TCP. This protocol is connection-oriented and creates a connection between sender and receiver and keeps it maintained until the completion of exchanging data. Data transmission in this protocol is performed with the feature of error detection/correction. This protocol also offers "flow control" whose task is to determine the need for data re-transmission, and stops the flow of data until all previous packets are successfully transferred. Key advantages of TCP include reliability, congestion control, full-duplex, etc.

C. Stream Control Transport Protocol (SCTP)
The Stream Control Transmission Protocol (SCTP) [15][16][17] is a transport protocol, which is present at an equivalent level with UDP (User Datagram Protocol) and TCP (Transmission Control Protocol), it provides transport layer functions to many internet applications. Compare to UDP and TCP, SCTP provides services and features that are more suitable for real-time protocols, especially in the telemedicine field. However, SCTP has a big drawback, that some infrastructure on the internet takes the header as defective and drops the packet. So, it is only usable in small area networks with controlled infrastructure. The main features of SCTP include multihoming and multi-streaming [16].

D. Real-Time Transport Protocol (RTP)
In telemedicine, audio and video streaming is a key feature and requires transmission to be performed in real-time. For this reason, Real-time Transport Protocol (RTP) [18] is needed to support telemedicine applications to transport information in real-time. RTP is an internet-based protocol that provides end-to-end transport service for real-time data such as audio and video stream over multicast or unicast network services [19]. RTP fulfills the need for interactive services (e.g., Internet Telephony) and media on demand (video) in telemedicine. RTP is an application layer protocol which used to run over UDP. Since RTP uses UDP, data delivery is fast. However, there is no guaranteed, Quality of Service (QoS). Furthermore, there is no reservation of bandwidth in RTP. It is the responsibility of the Real-Time Control Protocol (RTCP) to offer QoS. RTP is best suited for telemedical applications that are less sensitive to packet loss and very sensitive to packet delay. Telemedicine multimedia applications need correct timing and data playback which can be fulfilled by using RTP.
RTP takes care of timing issues by providing timestamping and featuring sequence numbers. Therefore, the most important parameters of RTP for the telemedical scenario are time stamping, sequence numbering, payload type identifier, and source identification.

E. Real-Time Control Protocol (RTCP)
Data transmission over RTP is unreliable as it isn't playing any role in providing mechanisms for flow control, error control, quality feedback, synchronization, and congestion control which is very important for telemedical applications. To overcome these problems, Real-Time Control Protocol (RTCP) [22] and [23] has been associated with RTP to provide reliability, quality of service, data delivery, and end-to-end monitoring. RTCP is used by many applications to change sender transmission rates and also for diagnostic purposes. RTCP is best suited for telemedical applications that are sensitive to packet loss and less sensitive to packet delay. RTCP is used to monitor QoS, congestion control, session size estimation, scaling, media synchronization, and source identification.
Key tasks of RTCP parameters are bandwidth-scaling, delay, jitter: packet loss, feedback, media synchronization, etc.

F. Real-Time Streaming Protocol (RTSP)
In telemedicine, reliable, controlled, on-demand delivery of real-time data is required. In telemedical systems, applications for the support of audio/video data transmissions are needed, the source of data can be live data feeds or stored clips. These applications contain features for conferencing and recording which helps to make reviews when needed and many more. To facilitate these telemedical applications, an application-level protocol named Real-Time Streaming Protocol (RTSP) is to be used. [20] and [21].

G. Real-Time Messaging Protocol (RTMP)
As in telemedical multimedia applications, support for Adobe Flash is needed which helps in adding streamed video and audio players and interactive multimedia content on web pages. This is done with the help of one real-time protocol commonly known as Real-Time Message Protocol (RTMP) [24]. RTMP is a TCP-based protocol designed to facilitate client-to-server-to-client communications. Examples of data that can be served by using RTMP can be text chat, pre-recorded data, live video data, live audio data, and others. The most important responsibility of RTMP is to specify different virtual channels on which receiving and sending of packets can take place. These channels should be independent of each other and may get active simultaneously at any given time.

H. Real-Time Media Flow Protocol (RTMFP)
Real-Time Media Flow Protocol (RTMFP) was introduced by Adobe [25]. This protocol is an application-level protocol and works on the principle of UPD. Hence, reduced latency and direct peer-to-peer connections are the key advantages of RTMFP. Table 1 represents the comparison between Real-Time Protocols to be used in the scenario of figure 1.

I. Extensible Messaging and Presence Protocol (XMPP)
Extensible Messaging and Presence Protocol (XMPP) is a communications protocol for message-oriented middleware. It is an open technology for real-time communication which provides the real-time equivalent of HTTP and is used in many diverse applications [26] and [27]. XMPP supports data transmission for both real-time and store-and-forward medical applications. By using XMPP, applications for the transmission of audio/video stream, data (medical records, ECG, sensors), instant messaging, robotic control and system control, and access to shared file space can be developed. The main advantages of XMPP for telemedical applications include its stability, interoperability, security, extensibility, decentralizations, scalability, equivalency with HTTP, HTML, and the other Internet, and many more.

IV. PROTOTYPE MODEL
A prototype model has been suggested to support different functions/features and data transmissions that are required in the telemedical scenario. It is to be noted that the suggested prototype model can only be used for testing purposes, which means it may or may not cover all the features/functions that are required in the given telemedical scenario presented in figure 1. The prototype model will run as simulation software that is capable of using different systems to perform transmission and reception of data files (real-time data or simple data), instant messages, audio/video streams, and robot control. Applications to run the following systems are based on different real-time protocols (RTP, RTCP, RTSP, RTMFP, and XMPP). This simulation software needs to be installed on both sides (specialists and assistants). With the help of this simulation system which is named "UDE Telemedical Simulation System", one can analyze, visualize, specifies and records the behavior of telemedical applications. As "UDE Telemedical Simulation System" is consisting of different applications/systems that are to be used for the given telemedical scenario. This means, by using this single simulating system, one can play with the real-time protocols and parameters of selected features to see under which conditions we can obtain the best results. The UDE Telemedical Simulation System" in figure 2 will work in such a way that applications that are going to be used can be controlled from a graphical user interface (GUI) [28] of this system after passing through the security and admin checks. Moreover, in GUI there will be options for selecting features to be used, the available real-time protocol for those features, and altering parameters of selected features. All applications are connecting users with the devices place at near or far ends. For example, in the telemedicine case of our research, if the user (assistant) wants to send an X-ray report to another user (specialist) then just by simply clicking the browse/file button in the GUI (where the application that supports file sharing feature is running), a request will be generated at the backend to look for the required X-ray report in the database system. If the required file is not present in the data-base, then the request will move forward and the device (scanning machine for example) will be activated to get the X-ray report so that it can be sent to the specialist. Similarly, for the case with A/V, the user needs to simply click buttons in the GUI of the "UDE Telemedical Simulation System" to control microphone and camera options (for example zoom in/out, mute, play, stop, etc.). There will be an option in UDE Telemedical Simulation System to switch to other applications at any time so that the application with the highest priority can be used easily. For the case of robot control, it is very much important to shift robot control between two expert doctors (if required). Therefore, if the option of robot control is selected in GUI, then there will a separate window for this feature in which the user is asked to give the user ID and password and also to type in access control information by filling "To" and "From" form. The user then needs to click apply button to activate the shifting of the robot control. Data delivery will be based on UDP or TCP (depending on application usage) but not on SCTP as SCTP has a big drawback, that some infrastructure on the internet takes the header as defective and drops the packet. SCTP is only usable in small area networks with controlled infrastructure and we want this system/software to work not only for small area networks but also for wide area networks.
The "UDE Telemedical Simulation System" is consisting of different applications/systems that are to be used for the given telemedical scenario. In a system where there are transmission and reception of audio or video (could be A/V conferencing), devices like camera and microphones are needed to be connected on both the ends (near-end and far-end). The feature of audio/video is very time-critical for realtime transmission and reception. The audio/video system is responsible for the successful delivery of real-time packets/streams over the internet by using protocols like XMPP, RTP/RTCP, etc. Using RTSP, audio/video stream data can be controlled. RTSP behaves just like a Video Cassette Recorder (VCR). All these protocols are based on UDP or TCP. One can individually test the behavior of this audio/video system with the help of some useful tools (D-ITG [29], Wireshark [30], ping, etc.) to measure bandwidth, delay, jitter, data rate, etc. Based on the different traffic classes, different QoS can be taken as a reference to compare with actual testing values. In the case of interactive audio-on-demand, approx. 128 kbps bandwidth is required for the stereo quality audio stream with the recommended delay of less than 150 ms. Furthermore, a jitter rate of less than 100 ms and a coding standard of MPEG-1 is recommended. If video conferencing is under test, the following are the recommendations, lip-synchronization < 100 ms, delay <150 ms, jitter < 400 ms, loss rate and error rate < 0.01 % each. There is a possibility to use different coding standards which required different data rates and bandwidths. For example, H.320 requires bandwidth from the range of 80 Kbps to 2 Mbps and supports data rate from 64 bps to 1920 Kbps. Different systems/applications are needed to test instructions via chat and for sending files for data (realtime data or simple data), as now in such a case we require applications that are more sensitive to packet loss and less sensitive for packet delay. Data transmission for the delivery of instant messages or for sending files must be reliable which can be achieved by using TCP.
Real-time protocols such as RTMP and XMPP are used to send sensor data, instructions via chat, access shared file space, and for transmission of the data object (real-time or store-and-forward). However, it is suggested to use XMPP for such cases as it is an open standard protocol and provides a real-time equivalent of HTTP. XMPP also provides stability, interoperability, security scalability, presence service, and many more. The functionality of an application based on XMPP (for instructions via chat and for sending files) just for the testing purpose needs to be divided into two parts; one part will be used for sending messages and files, while the other part mainly used for receiving messages and files which can be seen in figure 3 and figure 4. Applicationbased on XMPP for features like instructions via chat, accessing shared file space, etc. can also be tested individually to check its performance by using use some useful tools like Ipref, D-ITG, Wireshark, ping, etc. The figure 5 represents the architecture diagram of the "UDE Telemedical Simulation System". In figure 5, any type of data (real-time or non-real-time) will be used by this UDE Telemedical System for simulation purposes, components of this simulation system are texting units that will perform its operation when there is a need for instant messaging. Audio, video, and display/graphic unit, position control unit for robot control applications, synchronization unit will be useful when multiple features are running at the same time with the support of timer that record time of performed activity and make logs as per requirement. All of these units are controlled by a data handling/record unit which behaves like a controlling unit of this simulation system. Data will be transferred with UDP/IP or TCP/IP socket over the network. The Context diagram of the UDE Telemedical Simulation System can be seen in figure 6.
To get a deeper understanding of how this simulation system should work so that different functions and data transmission can be tested between two or more computers, we need to focus on figure 7 and figure 8. According to figure 7 and figure 8, the user (Expert or the assistant) needs to open UDE Telemedical Simulating software on the computer, after successful opening, there will be a prompt window asking to select a model which can be the expert mode or assistant mode. If the user selects any of these modes, he then needs to provide login details for that model. Login details will be verified from a database system and after a successful login, the user (in either mode) will get the main window on the screen in which he can select feature/s to be tested. All the features like video/audio, instruction via chat, sending data object (real-time or non-real-time) files, and robot control (only available in expert mode) will be displayed in this main window see figure  9. After the selection of a particular feature, the user can then select a real-time protocol for that specific feature just by clicking the pull-down button. Here at this moment, all the valid/available real-time protocols will be displayed in a small window, moreover, the user can also manually set/select other parameters for the selected feature. There will also be an option for the user to switch to any other feature (for example was using/testing A/V and now Instant messaging and file sharing is needed) if required or use different features simultaneously. Send data now over the network to start testing its parameters. Different tools can be used to measuring parameters and outcomes some of which include but are not limited to Distributed Internet Traffic Generator (D-ITG), Ethereal/ Wireshark, Available bandwidth estimator, Ping, and Traceroute.

V. CONCLUSIONS AND FUTURE WORK
The purpose of this research was to find suitable real-time protocols that can be used for the telemedical applications and are required in the given research scenario, for this reason, brief discussion and examination has been performed on the most important protocols that are required in a given scenario, comparison table has also been provided in table 1 which gives detail information about the offered services/features of each real-time protocol.
When performing a comprehensive comparison among different transport protocols (UDP, TCP, and SCTP), it has been noted that SCTP is the best-suited transport layer protocol as it provides services and features that are more suitable for real-time protocols, especially in the telemedicine field. However, SCTP has a big drawback, that some infrastructure on the internet takes the header as defective and drops the packet; therefore, SCTP is only usable in small area networks with controlled infrastructure. Hence using SCTP is not a good choice and we need to use either UDP or TCP for data delivery. All the real-time protocols that have been discussed in this research are based on either UDP or TCP. Based on the analysis and supporting features of different real-time protocols, different telemedical applications for different purposes need to be developed. RTP/RTCP is suggested to be the best suited real-time protocol for telemedical applications (like robot control, audio/video conferencing, video streaming, etc.) that are less sensitive to packet loss and very sensitive for packet delay. The use of RTSP will be like adding VCR functionality to an application. When there is a requirement of applications (ECG, X-rays, MRI data, CT, Ultrasound, text instruction via chat, file sharing, etc.) that are more sensitive to packet loss and less sensitive for packet delay, then in such case XMPP is suggested to be used. RTMP (TCP-based) and RTMFP (UDP-based) these protocols are both used to add interactive multimedia content on web pages and require an Adobe flash player. A prototype model (named "UDE Telemedical Simulation System") has been proposed in this research with the objective that this prototype model should enable different functions/features that are required in telemedicine scenarios and data transmissions between two computer systems. UDE Telemedical Simulation System will work as a simulation system/software in which users can play with the selection of different real-time protocols and parameters of selected applications and features under which conditions the best results can obtain from figure 9.
To examine the important parameters like delay, jitter, bandwidth, etc. of different telemedical applications/systems used in the "UDE Telemedical Simulation System", some important tools like Ipref, Wireshark, available bandwidth estimator, etc. are to be used.
As future work, UDE Telemedical Simulation System needs to be implemented; the effective implementation and success of a UDE Telemedical Simulation System depend on the seamless and continuous communication transfer and its clear interaction between the various ends. Possible approaches and methods to minimize and overcome the real-time network problems to achieve maximum QoS are worth to be investigated. Techniques for reliable data connections, robust continuous transmission systems, and fully utilize the available resources of a transmission channel by enhancing the quality of service are also need to be investigated.

Acknowledgment
I would like to give my special thanks to my supervisor, Pascal A. Klein, a very resourceful and responsible researcher, who has supported me throughout my research work. I wish to thanks the University Duisburg-Essen and Prof. Dr.-Ing. Axel Hunger, to provide me an opportunity to explore the area that I was interested in.

Authors Contributions
Sadiq ur Rehman-conceived the presented idea, worked on overview, analysis, and comparison of real-time protocols with the design and development of testing scenarios and prototype model. Syeda Bushra Ahmedwrote the manuscript as per the SSURJET Template (including re-draw of UML diagrams) in consultation with Sadiq Ur Rehman. Muhammad Hasnain Raza-proofread, checked the grammar, and approved the final manuscript with the incorporation of the latest references.

Conflict of Interest
There is no conflict of interest between all the authors.

Data Availability Statement
All data generated or analyzed during this study are included in this published article.

Funding
This research received no external funding.