333. Reliable Delay Sensitive Loss Recovery Protocol for. Critical Health data Transmission System. Madhumita Kathuria. Department of Computer Science.
2015 1st International Conference on Futuristic trend in Computational Analysis and Knowledge Management (ABLAZE-2015)
Reliable Delay Sensitive Loss Recovery Protocol for Critical Health data Transmission System Madhumita Kathuria Department of Computer Science YMCA University of Science and Technology Faridabad, Haryana, India
Sapna Gambhir Department of Computer Science YMCA University of Science and Technology Faridabad, Haryana, Ind
time. Data generated from various sensors like, electrocardiography(ECG), electroencephalography (EEG), electromyography (EMG), respiratory monitoring, pH-level monitoring, and so forth can be considered as High priority data. On the other hand, the Low priorities data such as pulse count, body temperature, blood pressure, do not impose any sort of constraint [2]. A WBAN for health condition monitoring specified in Fig. 1 is an honorable system that assures reliable and time manageable heterogeneous packet transmission. This paper has been organized as follows: Section I signifies a brief introduction to the subject matter. Section II describes the concept how to provide Quality life by overcoming issues like reliability, delay and jitter in a critical situation. Section III provides proposed protocol with new techniques. Section IV scrutinizes all the aspects and provides the conclusion part.
Abstract-Wireless Body Area Network (WBAN) is a special kind of sensor network deployed with low power, intelligent sensors, which are placed on the human body to collect human’s vital signs, while monitoring body functions and the surrounding environment. Many applications of WBAN demand Reliable communication service; since the majority of these applications are responsible for handling time-critical data. Such an application area is a healthcare system, which offers flexibility and mobility to patients through the internet. Due to the long propagation delay and high loss rate in the WBAN, it is very tough to provide reliable data transfer for time-critical applications. In this paper, we analyze all these issues and design an efficient Reliable Delay Sensitive Loss Recovery protocol (RDSLR) for handling critical and non-critical data in WBAN. We emphasize on arrival of heterogeneous data (i.e. traffic flow) within the expected time for the analysis of actual health conditions of a patient. Reliable and loss-free data transmission requirements in a healthcare system desire arrival of data within the predefined critical time interval. Thereby, we enhance the loss recovery and delay module considering critical time parameters as an account. We evaluate the performance of the proposed approach by taking packet loss rate, elapse time, loss error time, and reliability time as key metrics. Keywords-Wireless Body Area Network (WBAN); Reliability; Loss Detection; Loss Notification; Loss Recovery; Delay; Timecritical
I.
INTRODUCTION
The development of Wireless Body Area Networks (WBAN) along with intelligent sensor technology has led to design devices having miniaturization size, so that can be worn on or implanted in the human body. These devices are known as sensors, which sense and send their data to a personal device (e.g. a PDA or a smart phone) which acts as a sink in a WBAN. WBAN can be used in healthcare systems for monitoring patient over a longer period of time, even at home to improve the quality of life and to reduce treatment cost. Reliable and timely transmission of data is extremely important to any patient monitoring system [1]. The main focus of proposed protocol is to offer reliable heterogeneous (both real-time and non-real-time) packets transmission within
Fig.1. A Wireless Body Area Network for Healthcare system.
II.
ISSUES IN HEALTHCARE WBAN
Healthcare WBANs are time-critical systems that rely on the collective data of a group of sensor nodes. Reliable data received at the sink is based on the combined data provided by all sensor nodes and not on individual data. Unlike
978-1-4799-8433-6/15/$31.00©2015 IEEE 333
2015 1st International Conference on Futuristic trend in Computational Analysis and Knowledge Management (ABLAZE-2015) conventional reliability, retransmission is inapplicable in a healthcare system and would only lead to an elapsed data arrival, which is not acceptable for this kind of time-critical application. Time-critical healthcare systems require Timely data reliability for condition detection, and revitalization. Hence, the transmission reliability for the healthcare system should be based on the critical time. So we need to measure transmission reliability and delay based on the critical time[4]. 1) Reliability means successful data delivery from the source to the sink. Packet reliability requires all the packets carrying sensed data from all the sensor nodes to be reliably transmitted to the sink. Whereas, event reliability ensures that the sink only gets enough information about a certain event happening in the network instead of sending all the sensed packets[7][9]. In addition to packet or event reliability, the successful recovery of certain event information can be reliably achieved either at hop-by-hop or end-to-end level[10]. 2) Loss Recovery is defined as delivered sensed information at sink within a defined interval of time. When sender discovers that data has been lost in the network, it retransmits the missing packets to recover the data, which further causes retransmission overhead problem. Recovering from losses can be done either applying timer-driven retransmission or data-driven retransmission [3][6]. In Timedriven recovery, if a sender does not receive a positive cumulative ACK for a packet within a certain time-out interval, it retransmits the missing data. In data-driven retransmission, it uses fast retransmission method which retransmits lost data after arrival of duplicate Acknowledges. 3) End-to-End transmission delay is the amount of time it takes for a packet to travel from source to sink. Some critical systems, i.e. healthcare systems totally depend on time, because health data received at elapse time, does not reflect the actual condition of the patient. So a minute delay is affordable, but the quality of life is badly affected when an extensive packet delay or variation in delay occurs, i.e. some packets arrive later than the rest. Such kind of Packet delay variation is often called jitter[5][8].
A. Packet Structure If a sensor has a data packet to send to the sink, it inserts its Identification (IP) number and Port number, intended Destination’s Identification number and Port number, Current packet’s sequence number, Maximum sequence number (i.e. which gives information about total number of packets travel per flow), Priority of the sensor, Packet type (data packet or feedback packet), Packet traffic (real-time or non-real-time), Critical level (high, low, medium), Timer (RTO or RTT), Rate etc. When a sink has a feedback or control packet to send to the sensor, it inserts its Identification number, intended sensor’s Identification number, Flow_ID (priority of packets) assigned by classifier module, Old_index carrying sequence number of first lost packet in previously received control packet, New_index carrying sequence number of first lost packet in current control packet, Successive index hold the number of lost packets consecutive to New index, Congestion notification (CN) bit, Time interval, Loss rate notification (LRN) etc. The architecture of data packet and control or feedback packet are given in Fig. 2(a) and 2(b). Source_IP
Destination_IP
Source port
Destination port
Sequence_no
Max_Seq_no
Rate
Timer
Packet_type
Packet_size
Critical_level
Packet_traffic
Other fields Fig. 2(a). Structure of a data packet.
Source_IP
Old_index
Destination _IP
Flow_ID
CN
New_ index
Successive index
LRN
Time Period Packet_ type
Other fields Fig. 2(b). Structure of a control packet.
III.
PROPOSED SCHEMA
B. Reliability module Packet loss is the main factor inclined reliability. The main reason for packet loss or drop includes congestion, bad channel conditions, and link breakage. Our intended reliability module’s description is given in Fig. 3. The purpose of this module is to provide: • Flow control: It limits the data flow rate so that the sender transfers data with guarantee reliable delivery. The receiver continually hints the sender about how much data was lost. • Recovery of lost packets: If any packet was not acknowledged is retransmitted. • In-ordered data transfer: The sink selects, rearranges, serve packets according to their sequence number.
The purpose of a transport protocol in heterogeneous WBAN applications like healthcare system is to achieve high reliability and to reduce delay. To achieve reliable data transmission for time-critical and real-time traffic, a new transport layer protocol called Reliable Delay Sensitive Loss Recovery Protocol (RDSLR) is proposed in this paper. This protocol is able to recover loss, avoid unnecessary retransmission, minimize duplicate retransmission and make an effort to reduce transmission delay and its variance. Moreover, proposed protocol improves the performance in case of queuing, scheduling, resource utilization, congestion, and starvation conditions of critical and real-time WBANs.
334
2015 1st International Conference on Futuristic trend in Computational Analysis and Knowledge Management (ABLAZE-2015) of packets transmitted in that interval. Percentage of loss rate is calculated from following equations. Loss Packet Counter: LPC = LPC+1 (3) Arrived Packet Counter: APC = APC+1 (4) Percentage of loss Rate: PLR=[LPC/(LPC+APC)]*100 (5)
•
Duplicate-free data transfer: The sink detects, and discards duplicate packets. 1) Flow control: In our proposed protocol, the packet transmission rate is quick start based instead of slow start. RDSLR determines the rate of data transmission exponentially, and then sends the data accordingly. a) Exponential Quick start: It follows the quick start based transmission techniques. According to the sensor priority, rate was calculated and notifies to the sink at the time of three-way handshake communication establishment method. The Initial Transmission Rate (ITR) is calculated exponentially by considering the sensor priority as given in (1) for a particular time period. (1) ITR(Sn) = 2(N-n)
3) Loss Notification: We have proposed a Selective Negative Acknowledgment scheme (SNACK), where the receiver sends a SNACK based feedback packet signifying that the receiver has not received all the mentioned data packets subsequent to the first lost packet. Hence it provides a multiple loss notification schema. New_index and Successive index fields of SNACK packet as given in Fig. 2(b), provides the sequence number of very first lost packets and the total number of consecutive lost packets. Loss rate notification field gives the idea about percentage of loss in the current interval.
where N=total number of sensors, n= priority of the sensor. The Transmission Rate (TR) is increased or decreased only by a fractional value as in (2), depending on Percentage of Loss Rate (PLR), hence called Fractional Increased and Fractional Decreased (FIFD) based quick start schema. TR(Sn)new=
TR(Sn)old+ 2floor(k*(N-n)), if PLR=Thloss
(2)
where k is any constant lies between (0-1], Thloss is the calculated loss threshold value. In highly congestion case, when loss rate is very high, TR(Sn)new can be reduced to 1 packet for all sensor nodes. Suppose our system monitors a patient and the patient is wearing four sensor devices (N=4), i.e. ECG as S1, BP as S2, Glucose as S3 and Temperature as S4. The digits indicate their priority in the medical network. The initial flow rate of each sensor is calculated from (1) as: ITR(S1 or ECG) = 2N-1 = 24-1= 23 = 8 packets per interval. ITR(S2 or BP ) = 2N-2 = 24-2 = 22 = 4 packets per interval. ITR(S3 or Glucose) = 2N-3 = 24-3= 21 = 2 packets per interval. ITR(S4 or Temp) = 2N-4 = 24-4 = 20 = 1 packet per interval. Each sensor sends their packet after a fixed time lag in an interval (i.e. calculated from three-way handshake process). Fig. 4 represents the Quick start based packet transmission scheme. 2) Loss Detection: The sequence number identifies the order of the packets sent from each sensor so that the data can be reconstructed in sequence, regardless of any fragmentation, disordering, occur during transmission. In the first two steps of the three-way handshake, both source and sink exchange an initial sequence number along with the maximum sequence number. The sequence number of packet get increased, with every transmission. If a gap is found in a sequence number, then the packet loss was detected. To improve the reliability, a better retransmission, and anacknowledgment mechanism are designed to compensate this. a) Loss rate: Proposed RDSLR protocol defines the percentage of loss rate by finding the ratio of the total number of lost packets in an interval with respect to the total number
335
2015 1st International Conference on Futuristic trend in Computational Analysis and Knowledge Management (ABLAZE-2015) Fig. 3. Proposed reliability module.
4) Enhanced Loss Recovery: Main work of this module is to deliver sensed data at sink within a defined interval of time. When sender discovers any packet loss in the network, it recovers from it by retransmitting the missing packets. Our Enhanced loss recovery module supports Duplicate Selective Negative Acknowledgment (DupSNACK) based retransmission policy. It allows the sender to selectively retransmit only selected and latest missing packets according to the Flow_id, upon reception of 2nd Duplicate SNACK or when timer expires. By doing so, it reduces the number of unnecessary retransmission. SNACK control packets are sent to sender repeatedly by the receiver, carrying three essential fields, i.e. the first field informs about the previous lost packet in the earlier received DupSNACK, second field tells about current lost packet in the recent DupSNACK, and the third field tells about number of consecutive packet loss to the current lost packet. Upon reception of 2nd Duplicate SNACK, the sender first matches the New_index field of the 1st DupSNACK with the Old_index field of the 2nd DupSNACK, if a match not occurs, then it is the indication of loss of DupSNACK and a notification about this loss is send by sender to the sink, otherwise the sender decides, how many and which lost packets have to recover, by evaluating the retransmission rate according to Flow_id. If the packet belongs to high flow, then it retransmit all lost packets; else, only selected number of lost packets with high sequence number (i.e. latest lost packets) will be retransmitted. The proposed retransmission procedure is explained with an example as shown in Fig. 5. Suppose the sender S2 received the 1st DupSNACK packet having ‘0’ value in the Old_index field (i.e. no previous loss packet), ‘12’ value in the New_index field (i.e. first lost packet in this series is P12), and ‘2’ value in Successive index field, means P13 (P12+1= P13) and P14 (P12+2= P14) are two lost packets consecutive to P12. When the S2 received 2nd DupSNACK, it first matches the New_index field of 1st DupSNACK with Old_index field of 2nd DupSNACK. It finds a match (i.e. value is ‘12’), which means no loss of SNACK and they belong to the same flow. Now it check rest two fields of 2nd DupSNACK and found a value of ‘16’ in the New_index field (i.e. first lost packet is P16), and a value of ‘1’ in the Successive index field, means P17 (P16+1= P17) is the consecutive lost packet to P16. Now S2 evaluates retransmission rate and sends only two latest lost packets P16 and P17 of it’s, not all lost packets. Algorithm for loss detection, loss rate estimation, loss notification and recovery is given in Fig. 6.
Incoming Packets
Data Packet?
Yes Check Flow_id
No
SNACK Packet
Check Sequence number
Is New_seq_no == Old_seq_no+1? Yes
No
Insert new packet into appropriate queue According to its Flow_id
Packet Loss Detection: Calculate loss rate Enqueue new packet
Duplicity Reduction: Loss List
Store sequence no of lost packet in Loss List
Is arrived packet’s seq_no present?
Packet Loss Notification: Create Selective Negative Acknowledgement (SNACK) Packet
No
Yes
Drop this duplicate packet
Enqueue this retransmitted packet
Send SNACK Packet to the right sensor node
Packet Loss Recovery: Is 2nd DupSNACK? or time out No Wait for 2 DupSNACK
Yes Check fields of SNACK packet
nd
Identify All Lost Packets
5) Reordering of out-of-sequence packets: In our protocol, we have used two double-ended priority queues (DEPQ), made up of min_max heap data structure. One is used to store high priority flows and another one store low priority flows. A single-ended priority queue supports just one of the remove operations, i.e. remove minimum priority packet or remove maximum priority packet while DEPQ allows efficient removal of both the maximum and minimum priority
Estimate how many and which Lost Packets should be sent Retransmit only selected lost packets
336
2015 1st International Conference on Futuristic trend in Computational Analysis and Knowledge Management (ABLAZE-2015) packets. A min-max heap is a complete binary tree containing alternating min and max levels to store packets. The purpose of a min-max heap is to allow us to find and delete both the largest and the smallest element of the heap in constant time. The operation perform by this module are given below. a) At the time of queuing, the incoming packet PiSn is inserted into DEPQ using insertNew(PiSn) procedure. It finds out the appropriate position for PiSn using binary search algorithm and insert PiSn in that position by pushing up the elements in the chain upwards or downwards accordingly. b) In scheduling module, the high priority packet was searched from the DEPQ using findMin() and delete from DEPQ using removeMin() procedure and forwards to service queue. c) To avoid packet level starvation in a given interval, scheduler finds the low priority packet from the DEPQ using findMax() and delete from DEPQ using removeMax(). If the low priority packet’s deadline is exceeded, then it drops this packet, otherwise it sends it to the FIFO based service queue. d) To avoid starvation problem in low priority DEPQ, we have applied a new ratio rate based servicing method. The ratio rate is 3:1. After serving 3 packets in the high priority DEPQ, it serves one packet from low priority DEPQ.
Sender (S2)
Receiver
P11 P12 P13 T i m e r
P14
Lost
P15 1st DupSNACK
P16
0 | 12 | 2 P17 Lost P18 P19
2nd DupSNACK
12 | 1 6 | 1 P16 P17 P20 P21
Retransmit selected and latest packets according to Flow_id
Fig. 5. Loss recovery using DupSNACK and Retransmission. WBAN
S3
Algorithm: lossDetection() 1. Initialize: Set Time interval Tk=100sec 2. While (Tk! =0) 2.1 For each incoming packet // check packet type 2.2.1 If (Packet_type==Data), then // Check packet Flow_id and Sequence_no 2.2.1.1 If (New_seq_no!= Old_seq_no+1), then i) Call lossrateEstimation() ii) Call lossNotification() Else i) Call Enqueue(buffer_array) 2.2.2 Else if (Packet_type==SNACK), then 2.2.2.1 Call lossRecovery() 2.2 End for 2.3 Tk -3. End while
S I N K
S2 S1 S4
Fig. 4. Quick start rate based packet transmission in a given time interval.
Algorithm: lossrateEstimation() 1. Initialize: Set Arrival Packet Counter (APC) =0 Set Loss Packet Counter (LPC) =0 2. For each Incoming Packet // check for duplicity 2.1 If (not a duplicate packet), then 2.1.1 If (gap in sequence number) i) LPC ++; 2.1.2 Else i) APC ++; 2.2 Else 2.2.1. Drop the packet. 3. Calculate Percentage of Loss Rate (PLR): PLR= (LPC/LPC+APC)*100 4. If (PLR TEDPi TELPi = (15) 0 , if TADPi
