Research on Application of Perceived QoS Guarantee through Infrastructure Specific Traffic Parameter Optimization

In the light of United Nations Millennium Development Goals [1] for the improvement of healthcare services especially in the rural areas of the developing countries, the developments in the information and communication technologies play a significant role. Many governments have created dedicated infrastructure for delivering quality oriented services to the citizens [2].

The knowledge of quality of service (QoS) parameter values in network based healthcare applications can be useful while designing applications and services pertaining to the medical domain [3]. These parameters allow characterizing the network and indicating their aptness for a particular application or service. In order to optimize the QoS in network based healthcare applications and services, it is crucial to study the two aspects - the parameters of the transmitted biomedical information and the transmission behavior of the communication network [4], [5].

The relationship between network behavior and application parameters have already been studied by a number of research groups. Internet2 QoS Working Group has published a survey on QoS application needs [6]. TF-STREAM reported on best-practice guidelines for deploying real-time multimedia applications [7]. HEAnet reviewed several aspects of perceived quantitative quality of applications [8]. All these approaches are qualitative and are in general applications -we aim to create a quantitative representation of application perceived QoS, especially in the case of network based healthcare applications and services over a real state wide area network infrastructure.

In this paper, we studied the various QoS parameters (End to End Delay, Jitter, Throughput) and their relationship with data packet size in order to meet the application perceived QoS of network based healthcare applications and services over Himachal State Wide Area Network (HIMSWAN) implemented as a part of the Indian National electronic Governance Plan [9]. This would allow improving the network based healthcare services [10], [11]. We, therefore, performed real network simulation on Network Simulator version 2 (NS2) and computed the optimum values for data packet size for different kind of healthcare related applications and services over TCP and UDP.

The organization of rest of the paper is as follows, Section II presents a short note on basic terminology and the tools used in this work, and Section III describes the methodology followed. Section IV presents the basic HIMSWAN network architecture under study along with the proposed tiered architecture for a ubiquitous healthcare network. Section V presents the details of our NS2 based simulation set up and its configurable parameters. Finally, in Section VI, we present our results and findings followed by the conclusion in Section VII.

• II.    BASIC TERMINOLOGY AND TOOLS

• A.    Quality of Service (QoS)

QoS is an important consideration in networking [13], [14], but it also poses a significant challenge. QoS refers to the capability of a network to provide better services to the users by handling the network traffic over various technologies. QoS parameters are key factors in the rollout of a new technology or service. These parameters increase in importance as networks become interconnected and more complex [15]. A short note on various QoS parameters is given below.

End to End delay: It refers to the time taken for a data packet to be transmitted across a network from source to destination.

Tend-to-end = (Total bits transmitted) / (Channel Capacity)

Throughput: It refers to the volume of data that can flow through a network in per unit of time. For heavy duty networks, this is likely to be the most accurate indicator of system performance.

Th link = (Number of bits from source node to destination node) / (Observation Duration) (2)

Jitter: Data packets from a source will reach the destination with different inter-packet delays. A packet's delay varies with its position in the queues of the routers along the path between source and destination and this position can vary unpredictably [16]. This variation in delay is known as jitter and can seriously affect the quality of streaming audio and/or video and affect other applications.

Jitter = ((recvtime(j) - sendtime(j)) - (recvtime(i) -sendtime(i))) / (j-i), j > i; (3)

Any given path in a network is having a minimum delay induced by different components on which we have little or no influence: transmission delay, switching time, queuing time, serialization delay and so on. Even under the best possible conditions there is always a minimum delay.

If the conditions change (for instance, there is a sudden burst on the network and queues start to build on an interface) then this delay will increase. The transit time between two consecutive packets will not be the same anymore: the second packet will have to go through a longer queue, spending more time, and generating positive jitter [17]. Once this burst is over, the queue will progressively reduce, reversing the situation. Out of two consecutive packets, the second one will spend less time in the queues, and will therefore generate negative jitter.

It is clear that the positive jitter is actually the bad news while the negative jitter is actually the good news. But for some applications, any jitter big enough can cause harm.

• B.    etwork Simulator (version 2)

NS2 is an open source discrete event driven network simulation tool [18], [19] for studying the dynamic nature of communication networks. It is implemented in C++ and OTCL programming languages. NS2 provides a highly modular platform for wired and wireless simulations supporting different network elements, protocols, traffic etc. In general, NS2 provides users with a way of specifying network parameters and simulating the corresponding behaviors. Result of the simulation is provided in a trace file with the extension .tr that contains detailed information about all the occurred events. The format of a trace string is as shown in Fig. 1.

ТУР= Time Identifier^ ”

Source Mode

Destination Node

Packet Name

Packet Size

Flags

How ID

Source Address

Destination Address

Sequence Number

Packet Unique ID

(enque(+),deque(-),receive(r),drop(d))

Figure 1: Trace file format in NS2

• C.    Transmission Control Protocol (TCP)

TCP is one of the core protocols of the Internet protocol suite (IP) and is so common that the entire suite is often called TCP/IP. TCP provides reliable, ordered, error-checked delivery of a stream of octets between programs running on computers connected to a local area network, intranet or the public Internet [20].

• D.    User Datagram Protocol (UDP)

UDP is suitable for purposes where error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system [21].

Applications that do not require the reliability of a TCP connection may instead use the connectionless UDP, which emphasizes low-overhead operation and reduced latency rather than error checking and delivery validation.

• E.    File Transfer Protocol (FTP)

FTP is a standard network protocol used to transfer files from one host to another host over TCP-based network [22], such as the Internet. FTP is built on client-server architecture and uses separate control and data connections between the client and the server.

• F.    Constant Bit Rate (CBR)

CBR is a term used in telecommunications, relating to the quality of service. CBR is useful for streaming multimedia content on limited capacity channels as it is the maximum bit rate that matters, not the average, so CBR would be used to take advantage of all of the capacity.

• III.    METHODOLOGY

The methodology for carrying out this work is divided in five phases. The first phase was an exhaustive bibliographical revision relating to the need, techniques and efforts being applied on the connectivity aspects of medical equipment and network based systems oriented towards remote health monitoring and treatment.

The second phase was to design the ubiquitous healthcare network over HIMSWAN. This was achieved by modeling the HIMSWAN network in NS2.

In the third phase, we identified the various types of network traffic and their pattern, relevant in the case of healthcare applications and services along with their classification as per the ITU Report [23].

In the fourth phase, the NS2 simulation was run on TCP and UDP transport protocols, the type of application (FTP/ CBR), varying the data packet sizes of data to be transferred.

In the last phase, we verified the results and thereafter presented the conclusion.

• IV.    INFRASTRUCTURE DETAILS

• A.    HIMSWAN

The major highlights of HIMSWAN architecture are as given in [10] and presented below.

Star Topology has been implemented in HIMSWAN enabling complete and granted bandwidth availability.

HIMSWAN has been implemented with four tier architecture termed as HIMSWAN Point of Presence.

1st Tier: SHQ (State Head Quarter),

2nd Tier: DHQ (District Head Quarter),

3rd Tier: THQ (Block Head Quarter), and

4th Tier: Local Level Departments

Horizontal and vertical connectivity has been implemented in HIMSWAN. DHQ to SHQ connectivity is termed as a Vertical connectivity and Connectivity of various District level organization and departments to the district head Quarter is termed as Horizontal connectivity.

Vertical connectivity has been done with the help of managed leased lines from Bharat Sanchar Nigam limited (BSNL), a leading ISP in the country.

Initially a bandwidth of 2 Mbps has been ensured for the vertical connectivity with can be maximum extended to 16 Mbps as per requirements.

• B.    Ubiquitous Healthcare Network

The proposed ubiquitous healthcare network (Fig. 2) will have three-tier architecture with the 1st tier being the State Head Quarter (SHQ), consisting of major data servers and all the super specialty facilities. 2nd Tier, the existing HIMSWAN network, will act as a data transmission interface between tiers 1 and 3. The 3rd tier will consist of all the end level healthcare service providing agencies (hospitals, clinical laboratories, medical clinics etc).

The transfer of data from the third tier to the first tier involves the use of diverse technologies and applications. It can be characterized by the type of information sent (such as radiographs or clinical findings) and by the means used to transmit it. Many areas of medical practice have potential telemedicine applications [24].

In accordance with ITU report on Global Information Infrastructure, Internet Protocol Aspects and Next Generation Networks [23], the network based healthcare services can be categorized in different classes as represented in Table I.

Figure 2: Ubiquitous Healthcare Network

• V.    SIMULATION AND EXPERIMENT

The proposed ubiquitous healthcare network was simulated over NS2. In this paper, simulation of only one segment consisting of all possible connectivity variation was considered. The detail of network segment considered for the simulation experiment is presented in Fig. 3.

Figure 3: Simulation Setup

Distance between the different nodes is as per the approximate real geographical distance. The queue size of all the routers is restricted to a maximum of 50 data packets (DropTail) considering this as minimum dedicated queue available for handling healthcare applications and services. The data packet size range for variations in simulation setup is as per the suggested guidelines in the ITU report on network performance objectives [23]. The data packets were generated for a period of one second in the simulation. The experiment has been performed a number of times to obtain stable and verifiable results.

Qo S Cl ass	Application	Example	Traffic
0	Real-time, jitter sensitive, high interaction	Trauma/ Emergency Case Remote Handling	TCP/UD P
		Remote Surgery through Robotic equipment such as NeuroArm, CyberKnife, da Vinci surgical system etc.	TCP/UD P
1	Real-time, jitter sensitive, interactive	Super - Speciality Audio / Video Consultation	UDP
		Medical Case Referral	TCP/UD P
		Disaster Relief Operations	TCP/UD P
		Patient Counselling	UDP
2	Transaction data, highly interactive (Signalling)	Radiology Report Transfer (Ultrasound, CT, MR, X-ray, DICOM [PACS] format)	UDP
		Monitoring Vital Signs (BP, Heart rate, Pulse)	TCP
3	Transaction data, interactive	Real Time DB handling	TCP
		Clinical Document Transfer (PDF, PNG formats)	TCP
		Telepharmacy	TCP
4	Low loss only (short transactions, bulk data, video streaming)	Educational Purpose	TCP/UD P
5	Traditional Usage	Inventory Status	TCP
		Human Resource Status	TCP
		Daily Reports	TCP

• VI.    RESULTS AND DISCUSSION

• A.    Scenario 1: TCP Services ( Traffic Type: TCP, Traffic Source Application: FTP)

The scenario presents optimal data packet value for network based healthcare applications and services involving transmission over TCP. The behavior of data packet size against QoS parameters [End to End Delay, Jitter, and Throughput] was examined.

The minimum EED (0.060916 sec) remains constant irrespective of the data packet size; however, there is a lot of variation in maximum EED. Maximum EED is lowest (0.136329 sec) for data packet size 500 bytes, which keeps on increasing with increase in the data packet size and touches the highest point (0.616214 sec) for data packet size of 2500 bytes (Fig. 4).

Figure 4: Packet Size versus End to End Delay

The general tendency of packet size versus jitter (Fig. 5) is same as that of EED. The minimum jitter value is same for all the data packet size variations considering the fact that the first event always tends to have zero jitter. Maximum value for positive jitter is 0.094906 sec for data packet size 2500 bytes and is minimum for data packet size 500 bytes. However, all the data packets of size 500 bytes received 100% positive jitter whereas, this value is 88.57% in case of 2500 bytes data packet size.

Figure 5: Packet Size versus Jitter

Fig. 6 shows the results obtained for packet size versus link throughput and Fig. 7 shows the relationship between packet size and overall system throughput. Considering the fact that system maximum throughput is bounded by the lowest link in the process, therefore, we consider the minimum link throughput as system throughput. In the case of TCP based transmission, Link6 comes out to be the bottleneck link in our system. System throughput increases with the increase in the data packet size. The maximum throughput of 444.979 Kbps is achievable with the data packet size of 2500 bytes.

Figure 6: Packet Size versus Link Throughput

Figure 7: Packet Size versus System Throughput

To sum up, all these tendencies recommend the use of a low data packet size (500 bytes) for QoS classes 0-2 (jitter, delay sensitive) category of network based healthcare applications and services. On the other hand, data packet size of 2500 bytes was found suitable for jitter and delay insensitive category of applications (QoS classes 3-5).

• B.    Scenario 2: UDP Services ( Traffic Type: UDP, Traffic Source Application: CBR)

This scenario evaluates the behavior of QoS parameters against data packet size for network based healthcare applications and services over UDP.

The maximum EED versus packet size plot shows a lot of fluctuation (Fig. 8). Maximum EED is lowest (0.43441 sec) in the case of 500 bytes data packet size while, it is maximum (0.80854 sec) for data packet sizes 1000 and 2000 bytes. The values obtained also show that the minimal EED values remain almost constant for different variation in the data packet sizes. It is also observed that the maximal EED in all the cases is caused at the last tier router. This may be due to the bottleneck offered by the 0.54 Mbps link connectivity of the last node, resulting in a high number of dropped data packets.

Figure 8: Packet Size versus End to End Delay

Jitter experienced a lot of fluctuations along with the increase of packet size (Fig. 9). Maximum positive jitter is lowest (0.003408 sec) for data packet size 500 bytes and highest (0.014815 sec) in the case of data packet sizes 2000 and 2500 bytes. A sharp increase of 117 % in the jitter value (data packet size 1500 bytes to 2000 bytes) is also noticeable.

Figure 9: Packet Size versus Jitter

Figure 10: Packet Size versus Link Throughput

Fig. 10 presents the relationship of packet size versus link throughput and Fig. 11 shows its relation against system throughput. Results show that Link2 (0.54 Mbps connection) of our simulation setup comes out to be the bottleneck link. System throughput is least (542.951 Kbps) for 500 bytes data packet size and is maximum (545 Kbps) for 1500 bytes of data packet size.

Figure 11: Packet Size versus System Throughput

To summarise, it can be claimed that in the case of UDP network based healthcare applications and services, a data packet size of 500 bytes is suitable for dealy and jitter senstive applications belonging to the QoS classes 0-2. However, for QoS classes 3-5 (delay and jitter insensative applications), a data packet size of 1500 bytes is recommended.

• VII. CONCLUSION

  In this paper, data packet size as a critical application parameter for network based healthcare applications and services has been evaluated in order to meet the application perceived QoS over the proposed ubiquitous healthcare network. The results obtained show that the data packet size of 500 bytes is most optimal for QoS classes 0-2 applications over TCP, whereas, for applications belonging to QoS classes 3-5 in Table I, a data packet size of 2500 bytes is efficient.

In the case of UDP based healthcare applications and services, a data packet size of 500 bytes is found most competent. However, a data packet size of 1500 bytes is optimal for QoS class 3-5 applications.

These values have been selected according to the simulated network measurements and are thus recommended for further design of the network based healthcare services in order to guarantee the perceived QoS.