AReliableReal-TimeTransportProtocolforNetworked Control Systems over Wireless Networks (Research Master)

ATHESISSUBMITTEDTO

THE SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

OF QUEENSLAND UNIVERSITY OF TECHNOLOGY

IN FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF

MASTER OF INFORMATION TECHNOLOGY (RESEARCH)

Xiaohan Shi

School of Electrical Engineering and Computer Science Queensland University of Technology

December 11, 2012

Copyright in Relation to This Thesis

!c Copyright 2012 by Xiaohan Shi. All rights reserved.

Statement of Original Authorship

The work contained in this thesis has not been previously submitted to meet requirements for an award at this or any other higher education institution. To the best of my knowledge and belief, the thesis contains no material previously published or written by another person except where due reference is made.

Signature: QUT Verified Signature

Date:

i ii To my family

iii iv Abstract

Deploying wireless networks in networked control systems (NCSs) has become more and more popular during the last few years. As a typical type of real-time control systems, an NCS is sensitive to long and nondeterministic time delay and packetlosses.However,thenatureof the wireless channel has the potential to degrade the performance of NCS networks in many aspects, particularly in time delay and packet losses. Transport layer protocols could play an important role in providing both reliable and fast transmission service to fulfill NCS’s real-time transmission requirements. Unfortunately, none of the existing transport protocols, including the Transport Control Protocol (TCP) and the User Datagram Protocol (UDP), was designed for real-time control applications. Moreover, periodic data and sporadic data are two types of real-time data traffic with different priorities in an NCS.Duetothelackofsupportfor prioritized transmission service, the real-time performance for periodic and sporadic data in an NCS network is often degraded significantly, particularly under congested network conditions. To address these problems, a new transport layer protocol called Reliable Real-Time Transport Protocol (RRTTP) is proposed in this thesis. As a UDP-based protocol, RRTTP inherits UDP’s simplicity and fast transmission features. To improve the reliability, a retransmission and an acknowledgement mechanism are designed in RRTTP to compensate for packet losses. They are able to avoid unnecessary retransmission of the out-of-date packets in NCSs, and collisions are unlikely to happen, and small transmission delay can be achieved. Moreover, a prioritized transmission mechanism is also designed in RRTTP to improve the real-time performance of NCS networks under congested traffic conditions. Furthermore, the proposed RRTTP is implemented in the Network Simulator 2 for comprehensive simulations. The simulation results demonstrate that RRTTP outperforms TCP and UDP in terms of real-time transmissions in an NCS over wireless networks.

v vi Keywords

Network Control System, Real-Time, Transport Protocol, Packet Loss, End-to-end Delay, Peri- odic Traffic, Sporadic Traffic, Quality-of-Service, Wireless Network

vii viii Acknowledgments

This thesis would not have been possible without the support of many people. First of all, I want to express my sincere gratitude to my principal supervisor, Prof. Glen Tian, for his patience, motivation, enthusiasm, and immense knowledge. His guidance helped me in all the time of this research and writing of this thesis. Besides, I would like to give many thanks to my associate supervisors: Dr. Gus Tian and Dr. Ernest Foo, who gave me numerous good advice, read my revisions, and helped make sense of the confusions. Also, special thanks to the Discipline of Networks and Communications, School of Electrical Engineering and Computer Science, Science and Engineering Faculty, Queensland University of Technology for providing me with the support, workstations and software needed to produce andcompletemythesis.Andfinally, thanks to my family and friends who endured this long process with me, always offering support and love.

ix x Table of Contents

Abstract v

Keywords vii

Acknowledgments ix

List of Figures xvi

List of Tables xvii

1Introduction 1

1.1 Background ...... 1

1.2 Motivation and Research Problems ...... 2

1.3 ResearchObjectives...... 4

1.4 Significance of Study ...... 5

1.5 Contribution ...... 5

1.6 Limitations of Study ...... 5

1.7 RelatedPublication ...... 6

2RelatedWork 7

2.1 Network Control Systems ...... 7

2.2 Existing Problems ...... 9

2.2.1 Time Delay in Networked Control Systems ...... 9

2.2.2 Packet Loss in Network Control Systems ...... 12

xi 2.3 Existing Solutions ...... 12

2.3.1 Control Perspective Solution ...... 13

2.3.2 Network Perspective Solution ...... 13

2.4 Summary of Literature Review ...... 18

3ProtocolDesign 21

3.1 A UDP-based Protocol Design ...... 22

3.2 RRTTPPacketFormat ...... 22

3.3 Retransmission and Acknowledgement Mechanisms in RRTTP...... 24

3.3.1 Retransmission Mechanism ...... 24

3.3.2 Acknowledgement Mechanism ...... 27

3.4 Prioritized Transmission Service in RRTTP ...... 31

4RRTTPPerformanceEvaluation 37

4.1 Simulation Settings ...... 38

4.2 CriteriaMetrics ...... 39

4.3 CaseOne ...... 40

4.3.1 Simulation Scenario Specifications ...... 40

4.3.2 Simulation Results ...... 41

4.3.3 Analysis and Evaluations ...... 41

4.4 CaseTwo ...... 44

4.4.1 Simulation Scenario Specifications ...... 44

4.4.2 Simulation Results ...... 45

4.4.3 Analysis and Evaluations ...... 46

4.5 CaseThree ...... 48

4.5.1 Simulation Scenario Specifications ...... 49

4.5.2 Simulation Results ...... 49

4.5.3 Analysis and Evaluations ...... 51

xii 4.6 Case Four ...... 52

4.6.1 Simulation Scenario Specifications ...... 52

4.6.2 Simulation Results ...... 52

4.6.3 Analysis and Evaluations ...... 54

4.7 Summary of Protocol Evaluation ...... 55

5Conclusion 57

Literature Cited 61

xiii xiv List of Figures

1.1 Components that compose an NCS...... 2

2.1 A typical NCS setup and information flow ...... 8

2.2 Distributed control system with three delays ...... 10

2.3 Time spent sending message from a source node to a destination node . . . . . 10

3.1 Position of the RRTTP in the TCP/IP stack ...... 22

3.2 Fields in the header of RRTTP design ...... 23

3.3 Retransmission of a data packet...... 25

3.4 Policy for data packets that fail the checksum ...... 28

3.5 Policy for out-of-order ACK packets ...... 29

3.6 Policy for out-of-order data packets ...... 29

3.7 Retransmission of an ACK packet ...... 30

3.8 Packet validation detection process on the source host ...... 31

3.9 Packet validation detection process on the destination host ...... 32

3.10 State transition in the RRTTP sender ...... 33

3.11 State transition in the RRTTP receiver ...... 34

4.1 Network topology in simulations ...... 38

4.2 Average end-to-end delay (ms) in case one...... 42

4.3 The proportion of effective packets in case one ...... 42

4.4 Average end-to-end delay (ms) in case two ...... 46

4.5 The proportion of effective packets in case two ...... 47

xv 4.6 Average end-to-end delay for sporadic data packets in case three ...... 50

4.7 The proportion of effective sporadic data packets in casethree...... 50

4.8 Average end-to-end delay (ms) for sporadic packets in case four ...... 53

4.9 The proportion of effective sporadic packets in case four...... 53

xvi List of Tables

4.1 The case studies match-up ...... 38

4.2 Basic network specifications for simulations ...... 39

4.3 Number of channel errors in each scenario in case one ...... 40

4.4 Average end-to-end delay in case one ...... 41

4.5 The proportion of effective packets in case one ...... 42

4.6 Traffic load and network capacity utilisation ratio in case two ...... 45

4.7 Average end-to-end delay (ms) in case two ...... 46

4.8 The proportion of effective packets in case two ...... 46

4.9 Number of channel errors in each scenario in case three ...... 49

4.10 Average end-to-end delay for sporadic data packets in case three ...... 49

4.11 The proportion of effective sporadic data packets in case three ...... 50

4.12 Control periods for each scenario in case four ...... 52

4.13 Average end-to-end delay (ms) for sporadic packets in case four ...... 52

4.14 The proportion of effective sporadic packets in case four ...... 53

xvii xviii Chapter 1

Introduction

This thesis concentrates on improving real-time performance of Networked Control Systems (NCSs) over wireless networks. The main objectives of this research include providing a reliable and fast transmission service, as well as a prioritized transmission service that improves Quality-of-Service (QoS) of the real-time data in control systems. In order to achieve these objectives, a new transport layer protocol is proposed. The rest of this chapter introduces the background and motivation of this research, which is followed by the research objectives and significance.

1.1 Background

NCSs have been widely used around the world in the fields of manufacturing and industrial process control. As Figure 1.1 shows, a typical networked control system consists of five components: a plant, plant sensors, plant actuators, controllers and communication networks. The network in an NCS links the other four components togetherandprovidesdatatransmission service in between them.

Initially, the communication network development in NCSs started with the traditional centralized point-to-point network architecture. The control system took advantage of the point-to-point networks’ well known characteristics including small transmission delay and deterministic jitter. These characteristics well satisfiedtherequirementsofreal-timecontrol systems. However, the limitation of point-to-point networks on scalability and flexibility led to the introduction of the common-bus network architecture. A wired common-bus network has

1 2 CHAPTER 1. INTRODUCTION

Actuator Plant Sensor

Network

Controller

Figure 1.1:ComponentsthatcomposeanNCS. better performance on scalability and flexibility than a point-to-point network. However, instead of having dedicated networks for each communication link, all the communication nodes in a common-bus network share the same network media. Consequently, different forms of time delay uncertainty between control system components were introduced. [Lian et al., 2002] Since then, achieving small and stable time delay for NCSs became an essential task.

With the development of communication technologies, the wireless networks have been deployed in NCSs to achieve better scalability and lower maintenance cost. However, due to the fact that the physical link errors are more common in wireless networks than in wired networks [Hespanha et al., 2007], the packet losses became another crucial issue that needs to be resolved for real-time control systems over wireless networks.

1.2 Motivation and Research Problems

As the wireless standard such as the IEEE 802.11 standard is widely used in NCSs, the long and unstable time delay and the packet losses become the most critical problems. It is well known that most NCSs are real-time applications which are delay sensitive. They usually have very strict constraints on the time delay and packet losses. Thereisnodoubtthatthesetwoproblems can degrade the performance of the control systems. Therefore, it is important to search for 1.2. MOTIVATION AND RESEARCH PROBLEMS 3

solutions to solve these problems.

The solution to the time delay and packet losses issues often involves designing a set of net- work protocols or modifying network architectures to satisfy the real-time requirement in NCSs. Numerous efforts have been made in this area [Loeser and Haertig, 2004][Yang and Eisaka, 2005][Gui, 2010][Gui et al., 2011]. But we observed that verylittleworkhasbeendoneonthe transport layer to improve the real-time performance of NCSs. There are two transport layer protocols in the standard TCP/IP protocol stack: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). Currently, most NCS applications choose UDP over TCP as their transport layer protocol to take advantage of UDP’s fast transmission feature. However, UDP is so simple that it does not provide any reliable packet delivery service. The lack of reliable transmission service may degrade the system performance, especially in a wireless context. TCP is not an appropriate option for NCS applications either.AlthoughTCPhastheability to compensate for packet losses, it does not guarantee real-time QoS for NCS applications. In fact, neither UDP nor TCP was designed with the considerationofreal-timeapplicationsover wireless networks in mind in the first place. Consequently, none of them is an ideal choice for awirelessNCS.

Except for the standard UDP/TCP, some existing variations ofUDPhavebeendesigned. However, they are not suitable for wireless NCSs either. Reliable UDP (RUDP) is a UDP-based protocol that provides reliable transmission service [Partridge and Hinden, 1990, Velten et al., 1984]. By adding up a retransmission mechanism, a windowing mechanism, sequence numbers and three-way handshake connection on the basis of the original UDP, RUDP is able to transmit bulk data in a reliable manner. But RUDP cannot be considered as an effective substitution of the original UDP for wireless NCSs in many aspects. First of all, the nature of the periodic data traffic in NCSs results in deterministic traffic load. Therefore, RUDP’s congestion control mechanism is useless. Secondly, RUDP does not consider the timeliness requirements of the real-time traffic. Consequently, the effectiveness of the NCS packets cannot be guaranteed. UDP-Lite is another variation of UDP, which enhances the reliability of the original UDP [Larzon et al., 1999]. The main idea of UDP-Lite is to deploy partial checksum instead of complete checksum in order to minimize the drop burst length and enhance throughput. Appar- ently, the UDP-Lite is not applicable to the real-time applications in NCSs, because it is only able to reduce the packet dropouts happening at the checksum process. Nothing can be done if the packet is lost during the process of transmission. 4 CHAPTER 1. INTRODUCTION

Apart from the research gaps mentioned above, we observed that in an NCS, there are basically two types of real-time traffic flows: the periodic traffic and the sporadic traffic. The nature of these two different types of traffic flows requires different transmission policies. The periodic traffic is real-time traffic generated periodicallyinsensors.InmanyNCSapplications, aperiodicdatapacketisconsideredeffectiveonlywhenitisreceivedwithinitscontrolpe- riod. Thus, out-of-date periodic packets will be discarded.Itiscalledthepackettimeliness. Therefore, a periodic packet needs to arrive at its destination before a new periodic packet is being generated. The sporadic traffic is non-periodic real-time data traffic carrying emergency information or commands. It needs to be transmitted as fast aspossible.Theprioritylevelof sporadic traffic flows are higher than periodic flows. Consequently, a prioritized transmission service is needed to deal with these two types of real-time traffic flows. The deployment of the prioritized transmission service helps to improve the QoS ofreal-timetraffic,especiallyina congested network condition.

So far, there does not exist any effective methods that are able to provide both reliable and prioritized transmission service to periodic and sporadic data traffic. Also, considering that neither TCP nor UDP is suitable for real-time transmissions over the wireless networks, our research project are aimed to solve the following problems:

• How to improve the reliability performance of the NCS wireless networks;

• How to improve the real-time performance of the NCS wireless networks;

1.3 Research Objectives

Based on the research problems addressed above, several objectives are planned to be achieved in this research:

• We aim to design a transport layer protocol that combines UDP’s simplicity together with TCP’s reliability in order to provide both real-time and reliable transmission service for NCSs. This new protocol must also perform well over wireless networks with varying channel conditions.

• We aim to design a prioritized transmissionmechanism to dealwiththeQoSrequirements 1.4. SIGNIFICANCE OF STUDY 5

of the periodic and sporadic data traffic in an NCS. The prioritized mechanism will be integrated into the new transport layer protocol.

1.4 Significance of Study

The goal of our proposed protocol is to solve the packet lossesanddelayproblems.Moreover, unlike other solutions [Davis et al., 2007], our proposed protocol is built on the basis of the most popular wireless network standard (IEEE802.11) and themostwidelyusedprotocolstack (TCP/IP), thus it does not require any fundamental changes oftheexistingnetworkinfras- tructure in NCSs. Additionally, in consideration of the real-time requirement of NCSs, our protocol outperforms the existing transport layer protocols (TCP/UDP) in terms of reliability and real-time performance. Last but not least, the proposed prioritized transmission mechanism enables our proposed protocol to transmit periodic and sporadic data in a prioritized manner, and therefore, improve the QoS performance of NCSs, especially in a congested network condition.

1.5 Contribution

It is expected that the complement of this thesis could contribute to the field of network trans- missions in NCSs in the following ways:

• Anewtransportlayerprotocolthatisspecificallydesignedfor real-time applications in NCSs over wireless networks.

• AprioritizedtransmissionmechanismthatisusedtoenhancetheQoSperformanceof NCSs networks under congested network conditions.

1.6 Limitations of Study

The work that will be conducted may be limited in the followingways:

• Due to the fact that this protocol design is based on TCP/IP standards, it may not fit network structures other than IP based network structures. 6 CHAPTER 1. INTRODUCTION

• This research is conducted separately from any controlling design in NCSs. Therefore, pre-empt parameters such as packet lengths and time delay tolerance will be chosen from arangeofaveragenumbers.Tailoringmightbeneededtoapplythisdesigntoaspecific NCS scenario.

1.7 Related Publication

Xiaohan Shi, Guosong Tian, Yu-Chu Tian, “A Reliable Real-Time Transport Protocol for Con- trol Systems over Wireless Networks”, IEEE Australasian Telecommunication Networks and Applications Conference (ATNAC’2012), Brisbane, Australia, 7-9 November, 2012. Chapter 2

Related Work

The purpose of this review is to analyse both the problems and recent advances in research and development of network transmissions in the field of NCSs.Thereviewisorganized as follows. First, we will explain the definition of NCSs and have a glance at the history of NCS development. With the background given in the section one, two existing problems that affect the reliability of NCS communication networks will be investigated and surveyed comprehensively in section two. In the next section, different aspects of related work that aims to solve the reliability issues on NCS networks will be discussed. The current technical gap, as well as the significance of this research, is described through evaluating the performance of the related work. Lastly, section 5 draws some conclusions of this review.

2.1 Network Control Systems

ANetworkedControlSystem(NCS)isatraditionalcontrolsystem in which control system components exchange information over a real-time data network. As shown in Figure 2.1 [Zhang et al., 2001], an NCS consists of five basic components: plant under control, sensors, actuators, controllers and a communication network. Sensors are a set ofelectronicdeviceswhichare used for auto data acquisition. Real-world signals will be firstly collected by sensors and then encoded into binary formats. After that, the “computer compatible” signals are transferred to controllers through the communication network in the formofinformationpackets.The controllers are the places where control algorithms are performed. They take the signals coming from sensors as input, execute the control algorithms and then generate decisions and commands

7 8 CHAPTER 2. RELATED WORK

as output. Later on, the output of controllers will be conveyed by networks and eventually reflected on the actuators.

Figure 2.1:AtypicalNCSsetupandinformationflow.

Initially, networks are not included in a control system. Twoprimarymotivationsgive rise to the introduction of networks: more computing power and distribution of computers [Auslander and Decotignie, 2005]. It all started with the direct digital control (DDC) system in which point-to-point wiring networks were adopted. Due to the fact that point-to-point archi- tecture was expensive and short of scalability, the distributed control systems (DCS) came out to offer an efficient, flexible and reliable solution to distributed computing requirements. Though a number of candidate network architectures like Controller Area Network (CAN), CANopen and Token Bus [Farsi et al., 1999] have been proposed for dedicated purposes in DCSs, Ethernet has made its way into the NCS market after years of development andimprovement.

Recalling the definition of Networked Control Systems, all the control system components are linked together through the communication network. The network itself is not involved in the controlling process, but its importance to the NCSs is demonstrated by the services it provides: transferring input and output data between nodes,andsynchronizingcontrolloops [Auslander and Decotignie, 2005]. It is assumed that in an NCS, controllers and actuators are event-driven devices, while sensors are supposed to be time-driven devices [Cervin et al., 2003]. This means the sensors periodically perform sampling and transfer output data to controllers through the network; meanwhile, the controllers will not execute the control algorithm until the sampling data is successfully accepted. It is quite clearthatnomatterwhetherinside 2.2. EXISTING PROBLEMS 9 the sampling loops or between sensors and controllers, sampling synchronization and data transmission are essential to coordinating the controllingprocess.

Auslander and Decotignie [2005] pointed out that there are two types of transfer incidents that may happen to the network services: vacant sampling and message rejection. In the first case, the data are too late to be utilized. In the second one, excess data appear unexpectedly, and therefore are rejected. Both incidents can be included into two concerns on the network of NCSs: time latency and network reliability. The followingsectionswilldiscussthesetwo issues in detail.

2.2 Existing Problems

Compared with general data networks, control networks are more sensitive to time-critical issues [Lian et al., 2005]. The packets flowing over a control network are relatively small and constant, and more importantly, they have real-time constraints. Each data packet has to be delivered successfully within its time-bound. Consequently, it is easy to understand that time delay and packet loss may degrade the performance of the NCSs [Zhang et al., 2001], thus attracting researchers’ attention.

2.2.1 Time Delay in Networked Control Systems

Time delay is unavoidable in NCSs where networks are introduced into control systems. The change of communication architecture from point-to-point to common-bus brings even more forms of time delay uncertainty between sensors, actuators and controllers [Lian et al., 2002].

From a control perspective, time delay in NCSs consists of three parts: Tsc, Tc and Tca.

As shown in Figure 2.2 [Bernhardsson et al., 2005], Tsc indicates the communication delay between sensors and controllers, Tca represents the communication delay between sensors and actuators, and Tcstands for the computation delay which takes place just inside the controllers. Zhang et al. [2001] pointed out that communication delay in NCSs is caused by message ex- change over the shared medium. Therefore, in this review, we would like to pay more attention to the communication delay.

The communication delay between two nodes can be further divided into two categories: 10 CHAPTER 2. RELATED WORK

Figure 2.2:Distributedcontrolsystemwiththreedelays.

device delay and network delay. They are explicitly illustrated in Figure 2.3 [Lian et al., 2002].

The device delay includes the pre-processing time at the source node Tpre the waiting time of packets in the queue at the sender’s buffer Twait and the post-processing time at the destination node Tpost.Thenetworkdelayonlyconsistsofoneelement,thepackettransmission time in the network medium Ttx.Therefore,thetotalend-to-endcommunicationdelaycanbeexpressedas follows:

Tdelay = Tpre + Twait + Ttx + Tpost. (2.1)

Figure 2.3:Timespentsendingmessagefromasourcenodetoadestination node. 2.2. EXISTING PROBLEMS 11

Since these delay components differ a lot from each other withregardtotheircharacteristics, it is worth analysing these components in detail. Tpre takes place when data is collected from the external environment and encoded into proper network data format. Tpost is the time consumed to encode the network data into a physical format, and to output the data to the external environment. Both Tpre and Tpost are mainly determined by the hardware and software adopted in control system devices. In most cases, Tpre and Tpost are considered to be constant and negligible. Ttx it represents the time spent on data propagation and transmission over the physical network medium. This value can be calculated given the message size, data rate and the distance between two nodes. Consequently, Ttx is referred to as “the most deterministic parameter” in a networked system [Lian et al.,2002].ThelastelementTwait is the time duration that a packet spends in the sender’s buffer. T(wait) may be very long if there are too many packets which need to be sent, or the network is toobusytodealwiththepackets instantly. Unlike Tpost, Tpre and Ttx,thevalueofTwait may vary dramatically as a result of the combination of network protocols, architecture and traffic load. The characteristic of T(wait) makes it the ideal target object for us to deal with the time delay issue with regard to Quality- of-Service of NCS networks.

Two aspects contribute the most to the determination of Twait:thenetworkarchitectureand transport layer protocols.

It is understood that there are plenty of network architecture designs that an NCS can choose from, but Ethernet-based networks have been considered as one of the dominant NCS network architecture designs for its low cost and compatibility withmultiplecomputermanufactures [Yang, 2006]. However, Ethernet also brings negative impacts on time delay. One of them is jitter [Yang, 2006]. It is well known that Ethernet uses CSMA/CD (carrier sense multiple access with collision avoidance) mechanism to share the network medium with multiple nodes. The main idea of CSMA/CD is that each sender must make sure the medium is idle before sending messages. If a collision is detected, all senders stop and wait for a random backoff period of time before attempting to send messages again. This protocolismoreefficientcomparedwith others such as Token bus. However, it also makes Twait indeterministic. In other words, the jitter increases as Ethernet is adopted. In consideration ofthetimeconstraintsofNCSreal-time requirements, data packets may become useless after a long and unpredictable period of waiting time. 12 CHAPTER 2. RELATED WORK

2.2.2 Packet Loss in Network Control Systems

Packet loss is another issue that data packets have to face during the transmission. It is one of the most common reliability problems a communication network may come across. There are alotofincidentsthatmaytriggerthepacketloss.Thefollowing are some of the main causes:

Network congestion If the network load is so heavy that an intermediate node’s (e.g. router) buffer overflows, newly arriving packets will be dropped [Bolot, 1993].

Errors in physical links Transmission errors are inevitable for all of networks, particularly for wireless networks. Any error in physical links is possible tocausepacketdropout.

Besides, Hespanha et al. [2007] pointed out that a long transmission delay may also result in packet dropout since the receiver may discard the “out-of-order” packets and ask for retrans- missions when packet reordering is caused. In addition, a packet may also be discarded even if it successfully arrives at its destination but fails its checksum.

There is no doubt that packet loss in NCSs will degrade the Quality-of-Service (QoS) per- formance of the networks and Quality-of-Performance (QoP) of the control systems. In a data network, packet loss only produces errors on the data itself.Eveninsomereal-timedata applications, such as video and audio, a certain level of packet loss is accepted. But in control networks, there is a much lower level of tolerance to packet losses. Missing a packet is not only about the data packets themselves, but also relates to the QoP of the control systems. Nilsson et al. [1998] argued that a temporary blackout of the control system can be caused by a transient fault. Therefore, packet loss is an inevitable issue that the design of the NCSs has to take into account.

2.3 Existing Solutions

Over the years, numerous efforts have been made to search for solutions to the problems discussed above. In this section, we will discuss some of the valuable contributions to the development of a communication network for NCSs.

There are two fundamental ways to address the reliability issues in NCS design Zhang et al. [2001], : 2.3. EXISTING SOLUTIONS 13

• The first method requires a comprehensive design of control strategies that takes all aspects of problems into consideration. The network does notbothertoguaranteea reliable transmission.

• The other one is to design a communication protocol to minimize the likelihood of all the unexpected effect caused by time delay and packet loss.

2.3.1 Control Perspective Solution

In the early 1990s, Luck and Ray [1990] proposed a solution to deal with the varying time delay. The concept of this proposal was to implement long buffers at both controller and actuator nodes. Data packets that transferred from sensors to controllers and controllers to actuators would be first stored in these buffers and then take part in the control loop. By doing so, the previous unstable system could be considered as a time-invariant system. This solution successfully stabilizes the time delay, but it leaves two severe shortcomings. The first one is that, it only fits the situation where the control delay is longer than the sampling period. The other one relates to the introduction of large buffers which may cause the control delay to be longer than expected [Nilsson et al., 1998].

Nilsson et al. [1998] presented a Linear Quadratic Gaussian (LQG) optimal controller de- sign after analysing two delay models: independently randomdelaysandrandomdelaysruled by underlying Markov chain. The system in which all the analysis was conducted was modelled to have a time-driven sensor node, an event-driven controller node and an event-driven actuator node. This system model is believed to have smaller time delays compared with others. By implementing timestamps on each packet to indicate its generation time, controllers are able to calculate the transfer delay through comparing the timestamp with the node’s internal clock. The history of the delays helps to optimise the controller’s behaviour.

2.3.2 Network Perspective Solution

As mentioned before, network-induced delay is caused by the sharing of network medium in NCSs. In particular, the delay is introduced by the collisions over the shared network medium. So, lookingfor a solutionto minimizethe delay or to shrink the jitter from a network perspective becomes an attractive research topic in NCS research community. It will be the focus of this 14 CHAPTER 2. RELATED WORK research.

Network Structure

At present, one of the most widely used network architecturesinNCSsisEthernetforcostand performance reasons [Yang, 2006]. Ethernet was originally designed as a bus-based protocol, with no consideration of real-time concerns. It uses the CSMA/CD mechanism to coordinate multiple nodes to share the same network medium. However, this mechanism results in non- deterministic delays when several nodes are accessing the medium at the same time. The situation will worsen with increasing number of nodes in the network. With the emergence of Switched Ethernet technology, more opportunities have been brought to the implementation of hard real-time communication on Ethernet. The idea of Switched Ethernet is achieved by introducing intelligent switches to divide a large collision domain into several small ones. A number of different protocols have been proposed to perform reliable real-time communication over Switched Ethernet [Loeser and Haertig, 2004, Yang and Eisaka, 2005].

MAC Layer

In addition to the research on hard real-time communication,somecommunicationprotocols have been designed to form a more reliable real-time transmission. A MAC layer protocol called RT-MAC was developed to prevent transferring out-of-date packets [Baldwin et al., 1999]. In a real-time system where packets are time bounded, transferring out-of-date packets is not only awasteofbandwidthcapacity,butmaycauseotherpacketstoexpire if collisions occur. Two pieces of additional information were used by RT-MAC to avoidbothcollisionsandunnecessary retransmissions: the value of a packet’s deadline and the back-off value of the transmitter nodes. The RT-MAC protocol requires inspection of the packet’s deadline three times. The first inspection happens in the preparation of the packet transmission. The second one is conducted after the back-off time expires. The last examination takes place before the retransmission of the packet if no acknowledgement is received. This comprehensive inspection mechanism will ensure the timeliness of the real-time communications on MAC-layer level. 2.3. EXISTING SOLUTIONS 15

Transport Layer

Apart from MAC layer solutions, transport layer protocols can also play important roles in improving real-time communications. However, limited efforts have been made specifically for NCSs. Fortunately, there are numerous studies on the transport layer of general data networks. Those studies could also bring valuable inspirations to the development of reliability of control networks.

Larzon et al. [1999] found that, in a delay-sensitive networkwherereal-timeapplications are running, it’s better to use UDP on the transport layer for its fast and efficient transmissions. However, some packets are still discarded, although they successfully made their ways to their destinations, due to the failure of the checksum. The checksum mechanism in UDP makes sure that every packet is delivered to the right recipient with the accurate data. But Larzon et al. [1999] found out that many packets are discardedforonlyafewbiterrors.In some circumstances such as video and audio transmissions, a partial effective packet would be better than a total pause in between the media data flow, let alone the upper layer protocols which sometimes are even equipped with error correction features. If these unsuccessful packets could be saved, both the packet loss ratio and throughput would improve a lot. So they came up with a solution called UDP-Lite,whichnotonlykeptthechecksummechanismtopreventfatal errors that may cause packets to be misdelivered, but also provided a certain level of tolerance to the packet’s bit errors. They achieved this by altering theLengthpartoftheUDPheader into a Coverage part to distinguish the error-sensitive and insensitive part of a packet. In UDP- Lite, the partial checksum checks the sensitive part of a packet but ignores any errors in the insensitive part. Therefore, UDP-Lite is able to improve theperformanceandqualityofmany UDP based real-time applications.

Unfortunately, UDP-Lite also leaves some problems to be solved. One of them is the incompatibility against the standard UDP. Larzon et al. [1999] admitted that due to the mod- ification of the Length field in the standard UDP packet header,thereceiverscouldnotperform correctly without UDP-Lite recognition. This problem motivated the research of UDP-Liter [Lam and Liew, 2004], an improved UDP Protocol that has solvedtheUDP-Litebackward incompatibility issue.

In UDP-Liter, Lam and Liew [2004] suggests to modify BSD Socket API instead of chang- ing the UDP packet header. 16 CHAPTER 2. RELATED WORK

• Adding a new BSD Socket type. First of all, Lam & Liew introduce a new socket type: SOCK DGRAM LITER in the socket() call. This new API will enable the application layer programs to specify that they are using UDP-Liter as the transport layer protocol.

• Adding new functions to the new API call. Accordingly, new functions are designed specifically for the new socket type SOCK DGRAM LITER.Inthenewfunctions,a Corruption Notification (CN) parameter is introduced to monitor the checksum state. With the value of CN appended in each data packet, the receiver is able to tell whether the coming packet is corrupted or not. Additionally, the existence of the CN value will also inform the receiver to use UDP-Liter to handle the data packets. In the case that the receivers are not UDP-Liter adapted, the packets can still beprocessedasnormalUDP packets since the UDP-Liter packet is identical to the traditional one. Lastly, the CN value could also provide effective information on the quality of received data to upper layer protocols.

In some real-time applications such as video and audio transmissions, forwarding corrupted packets to the application rather than discarding them is acceptable. The transport layer pro- tocols discussed above not only increase data throughput, but also lower packet loss ratio. However, in control systems, the requirements are significantly different. A real-time control system has a low level of tolerance to damaged data packets since any packet damage may harm the whole system. Therefore, the flexible checksum method is not suitable for NCS.

The most commonly adopted solution to address the packet lossproblemistoemploythe retransmission mechanism. Reliable UDP (RUDP) is one of the many protocols which attempt to add the retransmission function into the original UDP.

Reliable UDP [Bova and Krivoruchka, 1999] was designed by twoCiscoemployeesin order to provide reliable in-order delivery for virtual connections. It is a transport protocol based on RFCs 1151 and 908 Reliable Data Protocol and layered on the UDP/IP protocols. [Bova and Krivoruchka, 1999] It is implemented in commercialproductsfortelephonytrans- missions.

The performance criteria that RUDP tries to improve include reliable delivery, in-order transport, flow control mechanism, low overhead and high performance, error detection and individually configurable virtual connections. In order to accomplish those requirements, some 2.3. EXISTING SOLUTIONS 17

new features are introduced.

The first feature is referred to as Extended Acknowledgement (EACK).Apartfromthenor- mal ACK mechanism applied in TCP, RUDP has an enhanced ACK mechanism. The EACK segment is used to acknowledge the out-of-order segments. The sequence number of the out- of-order segment is included in the header of an EACK segment,combinedwithanACK number (the sequence number of the last received in-sequencesegment).WhenanEACK segment is received, the transmitter will check the header oftheEACKsegmentanddetermine which data packet needs to be re-sent. According to the RUDP retransmission algorithm, all the unacknowledged segments that are between the ACK number and out-of-order sequence number will be retransmitted. As an EACK segment header couldcontainmorethanoneout-of- order segment sequence number, it enables applications to adjust the retransmission frequency based on various situations.

Retransmission can also be triggered when the sender’s retransmission timer expires. When this happens, all segments that have been sent but not acknowledged are retransmitted. The retransmission timer is reset every time when an ACK is received. A recommended value of this timer is 600 milliseconds and the value is negotiated when a connection is established. Meanwhile, a retransmission counter is maintained by the sender to calculate the number of times a segment has been retransmitted. Once the counter exceeds its maximum value, the connection is considered to be broken. This function is vitaltopreventretransmittingout-of- date messages.

Flow control is also supported in RUDP by setting a number of configurable parameters in synchronisation (SYN) segments. One of the parameters is TheMaximumNumberofOutstand- ing Segments, which specifies the maximum number of segments that could be sent without getting an acknowledgement. Another one is called Receiver Input Queue Size. However, these parameters are configured only at the time when a connection isbeingbuilt.Thisisalsothe case for some other parameters such as the values of various timers and counters.

Despite many useful features as mentioned above, RUDP has limited features of dynamic adaption to the change of network conditions. Also, RUDP by nomeansprovidesanyconges- tion control. 18 CHAPTER 2. RELATED WORK

2.4 Summary of Literature Review

With the development of NCSs, decentralised network topology and common-bus network structure have been introduced into the design of communication networks in NCSs in order to take advantage of these off-the-shelf technologies with respect to scalability, low cost and high performance. However, both network-induced delay and packet loss issues contribute the most to the reliability problem of the communication networks of NCSs and therefore degrade the performance of the control systems.

After surveying different aspects of NCSs, we can conclude that an effective way to improve the performance of NCS networks is to provide a reliable real-time transport layer protocol with lower and more deterministic time delay.

In this literature review, we first had a look at the definition and development of NCSs. This has led to discussions of existing problems affecting the QoPofNCSs.Then,wecomprehen- sively analysed the causes and effects of the two major problems, time delay and packet losses in NCS networks. Finally, two main categories of existing solutions were reviewed.

In the first category of the solutions, the problem is addressed by designing a control system model which took network reliability issues into account. But it is difficult to model random transmission delays accurately in mathematical formulations. It is even harder to deal with the random access networks, such as Ethernet, which is widely adopted in NCSs. Moreover, most control perspective solutions cannot be applied as a generalsolutiontosatisfyvarioustypesof controlling requirements.

With regard to network perspective solutions, the focus is ondesigningnetworkstructures specifically for NCSs. Although Control Area Network (CAN) and other dedicated network standards and technologies behave better than Ethernet in terms of real-time applications, the fact that Ethernet has become one of the dominating NCS network technologies makes a dedi- cated structure design, such as CAN, less competitive to be a general solution.

Aproposalforatransportlayerprotocolseemstobeanidealsolution. But limited effort has been made in this area for NCS applications, which differsinnaturefromotherreal- time applications such as video streaming. Existing research and development on transport layer protocols have been conducted for general data networks. UDP-Lite and RUDP, which have been discussed in this literature review, are two classic representatives of these modified 2.4. SUMMARY OF LITERATURE REVIEW 19 transport layer protocols. Although these developments arenotsuitableforreal-timecontrol scenarios for their lack of timeliness considerations, their design on the reliability features have inspired this research. Therefore, a transport layer protocol that provides reliable transmission for real-time applications will be developed in this work. 20 CHAPTER 2. RELATED WORK Chapter 3

Protocol Design

The most popular transport layer protocols are TCP and UDP. TCP is known for its reliable transmission, but it is too heavy to suit the real-time scenario. Moreover, it is not effective for NCS applications where the packet size is relatively small and the size of the packet overhead needs to be limited. That is why UDP is more commonly used than TCP in NCS networks. UDP transmits data at high speed and it works well in a wired network. However, in a wireless scenario where the condition of the physical channels often fluctuates, the absence of guaranteed transmission service makes UDP need to be improved for NCSs over wireless networks. Last but not the least, neither TCP nor UDP supports prioritized transmission for periodic and sporadic data in NCSs.

In order to address the above mentioned problems, the Reliable Real-Time Transport Proto- col (RRTTP) is developed in this research. As a UDP-based protocol, RRTTP takes advantages of UDP’s simplicity and fast transmission features. Also, RRTTP is a reliable transport protocol that provides guaranteed transmission service to NCS applications. Furthermore, it supports prioritized transmission for periodic and sporadic data in NCSs. Therefore, in comparison with UDP, a number of additional mechanisms including a retransmission mechanism, acknowledge- ment mechanism and prioritized transmission service are designed and added into the RRTTP design.

21 22 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL

Figure 3.1:PositionoftheRRTTPintheTCP/IPstack.

3.1 A UDP-based Protocol Design

As a UDP-based protocol, RRTTP takes advantages of UDP’s simplicity and fast transmission features. UDP is chosen as the fundamental basis of our protocol design not only because the simple structure of UDP enables us to add more functionalities very easily, but also because UDP is the most commonly used transport layer protocol in NCS networks. We are aiming at developing a new transport protocol from which most NCS real-time applications can benefit. Figure 3.1 illustrates that RRTTP is designed to be sitting onthetransportlayerofthestandard TCP/IP hierarchy.

Being a UDP-based protocol also implies that RRTTP is a connectionless protocol. Unlike TCP, RRTTP does not establish a connection between two communication end nodes. Further- more, there is neither flow control nor windowing mechanism inRRTTPinordertokeepitas simple as possible.

3.2 RRTTP Packet Format

An RRTTP packet consists of two parts: the data part and the header part. As Figure 3.2 shows, the RRTTP header is composed of 16 bytes. It is an extension of the original UDP header. The first 8 bytes of the RRTTP header are inherited directly from the original UDP header. In addition to that, 8 more bytes are added in RRTTP header to support RRTTP functions including retransmission, acknowledgement and prioritized transmission services. The additional 8 bytes 3.2. RRTTP PACKET FORMAT 23

0 16 32 bits

Source port number Destination port number

Length Checksum

Sequence number Flag

Timestamp

Figure 3.2:FieldsintheheaderofRRTTPdesign of the RRTTP header can be filled with three fields: the sequencenumber,theflagandthe timestamp. The following are the detailed descriptions of the RRTTP header:

• Source port number. This 16-bit long field stores the port number that the process binds to on the source host. It is used to identify the source process. The range of the source port number supported in RRTTP is from 0 to 65535.

• Destination port number. This field stores the port number that the process binds to on the destination host. It is used to identify the destination process. The length of this field is also 16 bits.

• Length. This field stores the total length of the RRTTP packet in bytes, including both header and data part.

• Checksum. This checksum field is used to give protection against corrupted RRTTP packets. The checksum procedures in RRTTP is exactly the sameasthatofUDPand TCP.

• Sequence number. This 16-bit field is used by RRTTP to mark the sending and receiv- ing packets when RRTTP is called by the NCS applications to start data transfers. It starts from 0 once the data transferring process is established, and the sequence number increases by 1 every time a new packet is generated in this process. Therefore, the sequence number indicates the order of packets within one process. It is very useful in both retransmission and acknowledgement (ACK) mechanisms to specify the identity of apacket.Noticethatthesequencenumberisuniqueonlywithin one process. The same 24 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL

sequence number could be reused between the same two communication nodes when multiple processes are established.

• Flag. The flag field is used to specify packet type. Although it is a 16-bit field, only the last two bits are used in the current version of RRTTP. 00 represents a periodic data packet; 01 represents an ACK for the periodic data packet. 10 represents a sporadic data packet; 11 represents an ACK for the sporadic data packet.

• Timestamp. This 32-bit field is the last field of the RRTTP header. It records the time instantly when a packet is sent out, no matter whether it is a data packet or an ACK packet. The recorded time in this field will be used in retransmission and acknowledgement mechanisms to verify the validity of the real-time packets.

Similar to that in UDP, the size of the data part of an RRTTP packet is based on the MTU of the MAC layer. In a typical 802.11 wireless network, the MTU oftheMAClayerisnormally set to be 1500 bytes. This leaves 1464 bytes for the data part ofeachRRTTPpacket(takingout 20 bytes of the IP header and 16 bytes of the RRTTP header from the 1500 bytes MTU), which is more than enough to encapsulate the NCS application data.

3.3 Retransmission and Acknowledgement Mechanisms in RRTTP

RRTTP is a reliable transport protocol for real-time applications in NCSs over wireless net- works. Generally speaking, the channel conditions in wireless networks frustrate from time to time. Data packets may be delayed, compromised or even lost during the transmission over wireless networks. With the help of a retransmission mechanisms, RRTTP has the ability to detect and compensate for the errors during the packet transmissions while also keep the timeliness of the real-time packets.

3.3.1 Retransmission Mechanism

Inspired by TCP, RRTTP deploys the retransmission mechanismtocompensateforlostor discarded packets. As Figure 3.3 shows, when an RRTTP packet is generated, the RRTTP sender assigns a sequence number to this packet. The sending time is also instantly recorded in the timestamp field of the header of this packet. Whenever this data packet is sent out, a 3.3. RETRANSMISSION AND ACKNOWLEDGEMENT MECHANISMS IN RRTTP 25

Source Destination Host Host

Seq 1

Retransmission Time-out Seq 1

ACK 1

Figure 3.3:Retransmissionofadatapacket.

retransmission timer is set up by the RRTTP sender. A corresponding ACK packet is expected to arrive at the source host before the retransmission timer expires. If the ACK is successfully received by the source host on time, the timer is cancelled. IftheACKpacketfailstoarrive in time, the data packet will be treated as missing,and a retransmission of this data packet is triggered.

Regarding the calculation of the retransmission time-out value in RRTTP, several concerns must be taken into account. RRTTP is designed to function in a wireless network scenario. The dynamic environment of the wireless network requires thecalculationofthetime-outvalue reflects the changing conditions of the network. That is why wesimplifiedandthenadoptedthe algorithm described in Allman’s work [Allman, 2000].

The duration of the retransmission timer is referred to as retransmission timeout (RTO). It is calculated as:

RT O = β × SRTTnew. (3.1)

In Equation (3.1), factor β (β>1)isaconstant.Thevalueofβ determines how “sensitive” the 26 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL

retransmission timer is to a packet loss. If β is small (β=1 for instance), the timer is set to expire right away after SRTTnew time. If β has a large value, the source host will wait for the ACK packet a bit longer than SRTTnew and the timer will not expire until βSRTTnew time later. In

our experiment experiences, we set β to be 2 in the simulation. SRTTnew is a parameter that needs to be maintained to calculate RT O.Itdenotesthevalueofthesmoothedround-triptime update. The value of SRTTnew is updated by

SRTTnew = α × SRTTold +(1− α) × RT T current, (3.2)

where SRTTold is the previous SRTT value and RT Tcurrent is the current round-trip time of the latest data packet. When this data packet is sent out from the source host, the sending time is recorded in the timestamp field of its header. When the packet reaches the destination host, the sending time of this packet will be collected and copied into the timestamp field of its corresponding ACK message. When this ACK message arrives at the source host, RT Tcurrent can be easily calculated by subtracting the sending time of the latest data packet (retrieved from the ACK message’s timestamp field) from the receiving time of this ACK message. α (0 <α<1)isasmoothingfactorthatisconstantinourwork.Itdetermines how much

“influence” that RT Tcurrent has on the calculation of SRTTnew.Ifα is close to 0, RT Tcurrent plays a more important role than SRTTold in calculating SRTTnew,implyingthatthecurrent network condition may dramatically change the value of SRTTnew.Thatisnotpreferable, because the SRTTnew should reflect the overall network conditions. Therefore, wesetα to be 0.875, which is also recommended by Allman [2000].

In case the retransmission timer expires, a “back-off” scheme is introduced to prevent excessive retransmissions. The value of RT O is updated as:

RT O =2× RT Oold. (3.3)

In order to set an upper bound to the back-off timer, we set a maximum of 3 times of retransmis- sion for a data packet. If a packet does not reach its destination after 3 times of retransmission, this packet will be discarded forever.

Apart from the retransmission timer, there is another feature that defines the RRTTP re- transmission mechanism. It is called real-time retransmission. The purpose of this feature is to 3.3. RETRANSMISSION AND ACKNOWLEDGEMENT MECHANISMS IN RRTTP 27

guarantee the timeliness of real-time packets. It is well known that the periodic traffic pattern in NCSs is always known in advance with a fixed control frequency. A packet is generated periodically in every control period. This packet is only effective within this control period and it will become useless when a new packet is generated. Therefore, the retransmission of the out-of-date packet is not necessary. In RRTTP, the retransmission is ceased immediately when a new packet is generated and is ready to be sent. This feature not only guarantees the packet timeliness, but also saves the network bandwidth by reducing the chances of resending unnecessary out-of-date packets.

It can be concluded that an RRTTP sender sets a retransmissiontimereverytimewhenit sends out a data packet. The retransmission timer is 1) cancelled when a corresponding ACK packet is received and the value of SRTTnew,andRT O are updated; or 2) expires if no ACK packet is received in time and the retransmission is triggered (the back-off scheme is applied); or 3) cancelled if a new packet is generated and a new retransmission timer is set up when this new packet is sent out.

3.3.2 Acknowledgement Mechanism

RRTTP uses the acknowledgement mechanism to confirm the successful arrival of a data packet. When an effective RRTTP packet is received at the destinationhost,acorrespondingACK message is generated. An ACK message is basically an RRTTP packet with zero bytes of data. Since RRTTP uses the flag field in the packet header to specify the packet type, the flag field of the ACK message header is set to be either 01 or 11. Additionally, the sequence number and timestamp field of the ACK message are set to be the same as the original data packet. This enables the RRTTP source host to distinguish which data packet this ACK message acknowledges and to calculate the current round-trip time (RT Tcurrent).

However, an ACK message may not be always successfully generated or received, as shown in Figure 3.4, Figure 3.5 and Figure 3.6.

In Figure 3.4, the data packet fails the checksum at the destination host. This means that this data packet has been damaged during the transmission. Therefore, the packet is discarded without sending any ACK messages. The RRTTP sender is able to resend the data packet when the retransmission timer at the source host expires. 28 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL

Source Destination Host Host

Seq 1 Fail the checksum, discard the data Retransmission packet without timer expires sending ACK Seq 1 message

Receive the data packet successfully

ACK 1

Figure 3.4:Policyfordatapacketsthatfailthechecksum.

In Figure 3.5, the ACK message for data packet 1 fails to arriveatthesourcehostbeforethe next data packet (data packet 2) is sent out. In this case, since the retransmission timer has been reset, the acknowledgement of the previous data packet is meaningless. So the ACK 1 message

is simply ignored by the source host, and the value of SRTTnew is not updated.

Figure 3.6 shows that data packet 1 arrives at the destinationhostafterthearrivalofdata packet 2. Data packet 1 is an out-of-order data packet. An out-of-order real-time packet is ineffective, so it should be discarded without sending any ACK messages.

As a matter of fact, all the situations described above are theresultsofthepacketsvalidation detection process of both the RRTTP sender and receiver. On the source host, the sequence number of the latest data packet is kept by the RRTTP sender. Whenever an ACK message is received, the sender compares the ACK’s sequence number withthesequencenumberkeptin the sender. Only the ACK message with the same sequence numberisacceptedbytheRRTTP sender. On the destination host, the checksum process will make sure that no damaged data packets are passed to the application layer. If a data packet fails the checksum, it is discarded by the RRTTP receiver without sending any ACK messages. Additionally, the RRTTP receiver 3.3. RETRANSMISSION AND ACKNOWLEDGEMENT MECHANISMS IN RRTTP 29

Source Destination Host Host

Data packet 1

Seq 1

Data packet 2 ACK 1 Seq 2

Out-of-date ACK will be ignored.

Figure 3.5:Policyforout-of-orderACKpackets.

Source Destination Host Host

Data packet 1

Seq 1

Data packet 2 Seq 2

Out-of-order data packet should be discarded.

Figure 3.6:Policyforout-of-orderdatapackets. 30 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL

Source Destination Host Host

Seq 1 Receive the data packet successfully

Retransmission ACK 1 Time-out

Seq 1 Discard the duplicated data packet, but retransmit its ACK ACK 1

Figure 3.7:RetransmissionofanACKpacket.

also detects out-of-order data packets. The sequence numberofthelatestdatapacketwhichhas been successfully received is kept by the RRTTP receiver. When a new data packet arrives, the RRTTP receiver compares its sequence number with the sequence number kept in the receiver. Only the data packet with a larger sequence number is confirmedasavalidone.Otherwise, this data packet is discarded. All these validation detection policies mentioned above prevent generating or receiving an ACK message.

There is one exception, the detection of “duplicated packets”. As Figure 3.7 shows, the ACK message may be lost during the transmission. The RRTTP retransmission mechanism treats any ACK failure as a sign of packet loss. So a retransmission of the last data packet is activated. This leads to “duplicated packets”. In order topreventanyfurtherduplicated packets, the RRTTP receiver must discard the duplicated packet, and resend a corresponding ACK message to reconfirm the arrival of the data packet.

The logic flows of the process of the packet validation detection process on the source and destination host are shown in Figures 3.8 and 3.9 3.4. PRIORITIZED TRANSMISSION SERVICE IN RRTTP 31

Start

Receive an ACK message

An out-of-date Yes ACK?

No

Ignore this ACK Update RTO message

End

Figure 3.8:Packetvalidationdetectionprocessonthesourcehost

3.4 Prioritized Transmission Service in RRTTP

As mentioned in Section 1.2, periodic data and sporadic data are two types of real-time data with different priorities in NCSs. The prioritized transmission service in RRTTP is designed to fulfill the requirements of transmitting periodic and sporadic data at different priority levels. Generally speaking, the sporadic data contains emergency information or commands, thus having a higher priority over the periodic data. It can be observed that without the prioritized transmission service, sporadic packets are treated in the same way as periodic packets. As aresult,sporadicpacketsoftensuffersfromlongtimedelayandunexpectedpacketlosses, especially in a congested network condition. With the prioritized transmission service, the transmission of sporadic data packets is able to suspend the transmission of periodic data packets between the same communication nodes. Simulation results in Sections 4.5.3 and 4.6.3 indicates that the prioritized transmission service is effective in improving the QoS performance of the NCS networks, particularly in a congested network.

In order to integrate the prioritized transmission service into the RRTTP design, the concept of state transition is introduced. Figures 3.10 and 3.11 illustrate the state transition in the RRTTP sender and the RRTTP receiver, respectively. 32 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL

Start

Receive a data packet

Packet fails Yes checksum?

No

An out-of-order Yes Discard the packet? packet

No

Yes A duplicated packet?

No

Discard the Send an ACK packet

End

Figure 3.9:Packetvalidationdetectionprocessonthedestinationhost 3.4. PRIORITIZED TRANSMISSION SERVICE IN RRTTP 33

CLOSED

app: active close/ last control period app: active open timeout

WAIT

recv: sporadic packets recv: periodic packets recv: ACK recv: SACK

PKT_RDY recv: sporadic packets SPKT_RDY

retransmission timout/ retransmission timout/ recv: new periodic packets recv: new sporadic packets

recv: sporadic packets send: periodic packets send: sporadic packets

PKT_SENT SPKT_SENT

app: application PKT_RDY: periodic packets ready to be sent SPKT_RDY: sporadic packets ready to be sent

Figure 3.10:StatetransitionintheRRTTPsender 34 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL

CLOSED

app: active open send: the last ACK send: the last SACK

LISTEN

recv: periodic packets recv: sporadic packets

discard discard

PKT_RECV SPKT_RECV

send: ACK send: SACK

pass to application pass to application

PKT_VLD SPKT_VLD

PKT_VLD: received periodic packets are valid SPKT_VLD: received sporadic packets are valid

Figure 3.11:StatetransitionintheRRTTPreceiver 3.4. PRIORITIZED TRANSMISSION SERVICE IN RRTTP 35

In the RRTTP sender state transition diagram, there are 6 states: CLOSED, WAIT, PKT RDY, PKT SENT, SPKT RDY and SPKT SENT. Clearly, the state transition forms a finite state machine. The description of Figure 3.10 is as follows.

First of all, the RRTTP sender remains in CLOSED state until itiswokenbytheapplication layer. Then, the sender moves to WAIT to wait for data. If the coming data is periodic, the state is set to PKT RDY, meaning the packet is ready to be sent out. If it is sporadic data, the state will be switched to state SPKT RDY. After the packet is assembled and sent out from the sender, a retransmission timer is set up and the state becomes PKT SENT or SPKT SENT, depending on the type of transmitted packet. From then on, theRRTTPsenderwaitsforthe corresponding ACK message. If the ACK message is successfully received, the sender moves back to WAIT. If the ACK fails to arrive before the timer expires, the sender returns to state PKT RDY or SPKT RDY, respectively, to retransmit the lost packet.

It is noticeable that when the sender is in state PKT RDY or PKT SENT, it can be trans- formed to state SPKT RDY when the sender receives sporadic data from the application layer. This means that the transmission of sporadic data is able to interrupt and halt the transmission of periodic data. This guarantees higher priority of sporadic data transmission.

In the RRTTP receiver state transition diagram, there are also 6 states which can be found: CLOSED, LISTEN, PKT RECV, SPKT RECV, PKT VLD and SPKT VLD. The state transi- tion presented in Figure 3.11 is described below.

Initially, the RRTTP receiver is actively opened by the application layer. When the receiver enters LISTEN state, it is ready to receive packets from the RRTTP sender. Then, the receiver moves to PKT RECV or SPKT RECV, representing the arrival of the periodic data packet or the sporadic data packet, respectively. At the same time, the RRTTP receiver checks the effectiveness of the arriving packet. If it is an valid packet, it will be passed to the application layer and the state will be changed to PKT VLD or SPKT VLD, which indicates the acceptance of a valid periodic or sporadic data packet. After that, an ACKissentoutandthestategoes back to LISTEN. If the arrival packet fails the effectivenesscheck,itisdiscarded,andthestate returns to LISTEN. 36 CHAPTER 3. DESIGN OF THE RELIABLE REAL-TIME TRANSPORT PROTOCOL Chapter 4

RRTTP Performance Evaluation

In this chapter, a number of simulations were conducted to provide a comprehensive perfor- mance evaluation for RRTTP. Considering that the most widelyusedtransportlayerprotocols are TCP and UDP, both TCP and UDP were included throughout the simulation as comparative results to RRTTP. Recall that the objective of our research istodesignatransportlayerprotocol that provides better delay performance, more reliable retransmission service, as well as the support for prioritised transmission. The simulations weredesignedtodemonstrate:

• RRTTP is capable of keeping its delay performance at an acceptable level and also pro- vides reliable transmissions at the same time, compared withTCPandUDP;and

• RRTTP can improve the QoS performance in terms of reliabilityandtimedelaywhenever required.

Two criteria of the simulations are the end-to-end delay and the proportion of effective data packets.Theend-to-enddelayandproportionofeffectivedatapackets are counted in every simulation case study. The results of these two criteria, which fulfill our expectations listed above, would be the evidence that confirm the effectiveness ofourproposedprotocol.

In order to evaluate the protocol performance in a convincingandcomprehensivemanner, we decided to conduct simulations in four different case studies. Case One and Case Two were designed to test the protocol’s ability to support reliable and real-time transmissions for periodic data packets only, while Case Three and Case Four were designed to evaluate the protocol’s ability to support prioritised transmissions when both periodic data and sporadic data packets were taken into account.

37 38 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

Additionally, since the traffic load and wireless channel conditions are the two major factors that have a significant influence on the performance of a protocol in a wireless network, the variations of traffic load and wireless channel conditions are considered as the prime parameters that define our simulation case studies. In both Case One and Case Three, the traffic input are fixed but the channel errors will increase to simulate the variation of wireless channel conditions. However, in Case Two and Case Four, a fixed number of channel errors will be given but the control period changes from scenario to scenario to generate different traffic load. The matches of parameters and simulation purposes in different case studies are listed in Table 4.1.

Table 4.1:Thecasestudiesmatch-up

Case FixedParameters VariedParameters Criteria DataPacket Type One Traffic load Channel conditions Periodic data Delay & Two Channelconditions Trafficload Periodicdata Effective data Three Traffic load Channel conditionspackets ratio Sporadic data Four Channelconditions Trafficload Sporadicdata

4.1 Simulation Settings

There are a few simulation settings to be specified before the analysis of any case studies. The topology we used in our simulations is a star topology, as shown in Figure 4.1. The node in the center denotes the controller while all other nodes around represent sensors that keep transmitting packets to the controller. All the nodes are fixed nodes in the network, and the distance between the controller and each sensor is set to be 50meters.

S2

S S3

50m

C S4

Sn

Figure 4.1:Networktopologyinsimulations 4.2. CRITERIA METRICS 39

Although we simulated a great number of scenarios in four casestudies,inordertokeepthe consistency of the comparative studies, those simulated scenarios share several basic network specifications as depicted in Table 4.2.

Table 4.2:Basicnetworkspecificationsforsimulations

MAC layer standard 802.11b MAC layer buffer type Drop-tail priority queue Channelbandwidth 1.0Mbps Basic rate 1.0 Mbps Radio propagation model Two-ray ground Routingprotocol Destination-SequencedDistanceVector Antenna OmniAntenna Network area 300m × 300m square

Other than these basic network specifications, there are somepresumptionsthatarealso applied in all simulation scenarios:

• The simulation time of each scenario is 16 seconds. Sensors start to transmit data packets at 20.0s and all transmissions stop at 36.0s.

• According to the features of NCSs, all sensor nodes generate data packets periodically. It is determined by the control period which varies from case to case. However, whenever it is set, the control period will remain fixed till the end of the simulation run.

• In NS-2, we chose Constant Bit Rate (CBR) to be the packet type on application layer.

• The application data packet size in NCSs is usually short and fixed. The size of applica- tion data packets is set to be 200 bytes.

4.2 Criteria Metrics

As mentioned before, the criteria metrics of our simulation are end-to-end delay and proportion of effective data packets.Thesetwometricsbestreflecttheperformanceofatransportlayer protocol in NCSs.

End-to-end delay is chosen to evaluate the real-time performance of the wireless network. Practically, it always takes some time for a generated data packet to travel from the transmitter 40 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

to its destination. This travel time is called end-to-end time delay. The end-to-end delay starts to be calculated when a data packet is successfully sent out from the sender. The calculation ends when this data packet is received by the receiver. In the comparative simulation, we expect to see a relatively lower and more stable end-to-end delay forourproposedprotocol.

The proportion of effective data packets is chosen to reflect the reliability performance of asimulatedprotocol.Effectivedatapacketsrefertotheperiodic or sporadic packets that have been successfully delivered to their destinations in time without failing the packet validation process. Any duplicated, out-of-date or lost packets are notconsideredaseffectivepackets.We chose the proportion of effective data packets instead of packet drop rate as the metrics in our case studies simply because packet drop rate does not reflect the reliability performance in a real-time control scenario. Obviously, a relatively higherproportionofeffectivedatapacketsis what we expect for.

4.3 Case One

4.3.1 Simulation Scenario Specifications

In the field of wireless transmission, the channel condition is always an factor that unavoidably affects the transmission performance. As Bhandarkar and Reddy [2004] point out, wireless channels are characterised by high channel error rates. Consequently, the performance of the protocol will be tested in different channel conditions in Case One.

In Case One, a total number of 10 scenarios were tested. It is worth mentioning that all channel errors, including the timing when an error occurs andthedurationofeacherror,were randomly generated. The number of channel errors changed from scenario to scenario. Scenario 1hastheleastnumberofchannelerrorswhereasscenario10has the most. The number of channel errors in each scenario can be found in Table 4.3.

Table 4.3:Numberofchannelerrorsineachscenarioincaseone

Scenario 1 2 3 4 5 6 7 8 9 10 Numberofchannelerrors 38 57 74 94 127 152 189 208 222 250

Since we only changed the number of channel errors and kept thetrafficloadconstantfor all scenarios in Case One, we decided to set the number of nodestobe5,andthecontrolperiod 4.3. CASE ONE 41 to be 50 ms in all scenarios. Clearly, there would be at least 1600 packets sent out during the 16 seconds simulation for each scenario. As the number of channel errors increases, we expected to see longer time delay and less effectively received data packets. All scenarios will be applied to RRTTP, UDP and TCP respectively. The simulation results will be collected and analysed in the following sections.

4.3.2 Simulation Results

Table 4.4 shows the average end-to-end delay for data packetsthathavebeensuccessfully received in all 10 scenarios when different transport layer protocols are applied. The trends of the delay can be easily seen in Figure 4.2. The proportion ofeffectivedatapacketsareshown in Table 4.5 and Figure 4.3.

Table 4.4:Averageend-to-enddelayincaseone

Scenarios Numberofchannelerrors RRTTP UDP TCP 1388.3659448.30549515.311449 2578.3044988.31939417.367509 3748.2541378.35264721.773842 4948.3682328.32715027.127033 51278.2965718.36651334.496111 61528.3319748.37013443.194398 71898.1281568.36608560.148393 82088.2370758.36600155.261541 92228.1407658.35634365.884542 10 250 8.122221 8.268599 92.035702

4.3.3 Analysis and Evaluations

The simulation results demonstrates our research purposes.OurproposedprotocolRRTTP performs the best among all three tested transport layer protocols.

It is seen from Table 4.4 and Figure 4.2 that TCP has the worst performance in regard to the average end-to-end delay. In scenario 1 where only 38 channel errors occurred, TCP has the most time delay, 15.31ms, while RRTTP and UDP only have a much smaller time delay, 8.37ms and 8.31ms, respectively. As the number of channel error grows, the time delay of TCP increases dramatically from 15.31ms to 92.04ms as expected.However,RRTTPandUDPboth 42 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

100 TCP UDP RRTTP 80

60

40 periodic packets (ms)

Average end-to-end delay for 20

0 38 57 74 94 127 152 189 208 222 250 Number of channel errors

Figure 4.2:Averageend-to-enddelay(ms)incaseone.

Table 4.5:Theproportionofeffectivepacketsincaseone

Scenarios Number of channel errors RRTTP(%) UDP(%) TCP(%) 13899.6296.7597.38 25799.3896.1996.06 37499.1994.1993.44 49498.8893.0692.00 512798.2590.0689.06 615298.3187.9486.81 718995.6985.8876.75 820894.8884.7582.38 922295.3883.6273.19 10 250 92.19 79.75 65.00

100

90

80

70 TCP UDP

Proportion of effective periodic packets (%) RRTTP 60 38 57 74 94 127 152 189 208 222 250 Number of channel errors

Figure 4.3:Theproportionofeffectivepacketsincaseone keep a very minimum variation in their time delay records. Neither RRTTP nor UDP has a time 4.3. CASE ONE 43

delay over 8.50ms in all 10 scenarios.

Table 4.5 indicates another advantage of RRTTP over the othertwoprotocols,thehighest proportion of effective packets. When channel errors are rare, all three protocols perform equally well. But when channel condition gets worse, the proportion of effective packets of all three protocols start to decrease. RRTTP performs the best asitremainsthehighestproportion of effective packets at all time. Even in scenario 10 where 250errorsoccurred,RRTTPstill successfully receives 92.19% effective packets. TCP performs the worst in all scenarios. Similar to RRTTP, the proportion of effective packets in TCP starts todecreaseasthechannelerrors grows, but at a more rapid speed. Eventually, only 65.00% effective packets are successfully received by TCP in scenario 10. UDP, on the other hand, performs better than TCP but worse than RRTTP. 79.75% effective packets successfully made their ways to the destination in the worst case.

It is reasonable that UDP has a good performance on end-to-endtimedelaybutfailsinthe proportion of effective packets. UDP is well known for its light weight and low transmission latency. However, the lack of compensation for packet loss results in the fact that a UDP packet will either be quickly received by its receiver or be lost during the transmission forever. When channel condition gets worse, the end-to-end delay is not significantly affected, but the packet loss increases, thus lower the proportion of effective packets as Table 4.5 shows.

TCP is unfortunately not competent in any scenarios in Case One. It is caused by many mechanisms that are not suitable for real-time transmissions. First of all, it is the retransmission mechanism. Although TCP has the ability to retransmit the lost packets, the cost is time delay. Table 4.4 clearly demonstrates the impact that TCP’s retransmission mechanism has on its end- to-end time delay. In the last 4 scenarios (from scenario 7 to 10), TCP’s average end-to-end time delay is even larger than the control period (50ms). ThisisbecauseTCPretransmitsevery lost packet regardless of timeliness. Unnecessarily retransmitted packets not only increase the average end-to-end time delay, but also occupy the communication channels, which brings more chances of collisions and packet losses. Keeping this in mind, it is understandable why TCP also fails in transmitting more effective packets. In an NCS scenario where timeliness is taken into consideration, the loss of the proportion of effective packets is caused not only by packet drop, but also by out-of-date packets. Although TCP makes sure that every data packet can be successfully received, those that failed to arrive at the destinations in time will still be considered 44 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

as “ineffective” packets in real-time control systems, thusshouldhavebedropped.

Moreover, by thoroughly analysing the TCP trace file, we discovered that TCP’s congestion control mechanism is another reason that TCP’s performance is affected in simulations. The- oretically, TCP is designed to treat every packet drop as a sign of congestion. Therefore, its congestion control mechanism adjusts the sending rate in order to avoid subsequent congestion. However, in a wireless case, in which a packet drop could also be triggered by channel errors, congestion control does not help. Some of the packets are forced to stay in the sender’s buffer when the sending rate is mistakenly reduced by TCP’s congestion control mechanism. This inevitably extends the time delay of those data packets and thus reduces TCP’s proportion of effective packets.

RRTTP performs very well in terms of both average end-to-end delay and the proportion of effective packets. It is seen from Table 4.4 that RRTTP’s average end-to-end delay is quite similar to that of UDP. In all scenarios, the difference of time delay between RRTTP and UDP is no more than 0.3ms. More importantly, similar to UDP, RRTTP’stimedelayisnoteffectedby the growing number of channel errors as well. That ensures a crucial characteristic that favors control systems: stable and predictable time delay. Other than that, RRTTP also proves itself areliabletransportlayerprotocol.IllustratedinTable4.5, RRTTP transmits the most effective packets among all three protocols. Thanks to its real-time retransmission mechanism, packets loss can be compensated by RRTTP in time. Yet, giving up the unnecessary congestion control and applying bounded retransmission retries make RRTTP moresuitableforreal-timesystems.

Overall, simulation Case One shows that when the channel conditions become worse, nei- ther UDP nor TCP could meet the timeliness and reliability requirements of NCSs at the same time. RRTTP, however, keeps a good trade-off of timeliness and reliability, and therefore, proves itself a better choice for NCSs.

4.4 Case Two

4.4.1 Simulation Scenario Specifications

In addition to channel conditions, traffic load is another factor that has significant impact on the performance of transport layer protocols. In simulation Case Two, RRTTP, UDP and TCP will 4.4. CASE TWO 45

be simulated under different traffic load conditions.

In Case Two, the traffic load changes from scenario to scenariobyadjustingthecontrol period of sporadic data traffic. The smaller the control period is, the more the packets are, thus the heavier the traffic load will be. Eight different control periods are chosen altogether to reflect the variation of traffic load. Detailed specifications of the simulations are listed in Table 4.6.

Table 4.6:Trafficloadandnetworkcapacityutilisationratioincasetwo

Control Number of Network utilisationratio (%) Scenario period packets RRTTP UDP TCP 160ms133429.121.134.1 250ms160034.925.340.1 345ms177838.828.145.5 442ms190541.530.148.8 539ms205244.732.452.5 635ms228649.836.158.5 732ms250054.539.564.0 830ms266758.142.168.3

The third column of Table 4.6 records the number of packets generated on application layer in each scenario. This number should be the same within each scenario across three transport layer protocols. However, the network capacity utilisationratioisdifferent.Accordingtothe table, it is clear that UDP, due to its lack of ACK mechanism, has the lowest utilisation ratio, while TCP utilises the most network capacity all the time. Although RRTTP also has an ACK mechanism, since we keep its ACK packages as small as possible, RRTTP’s utilisation ratio is larger than UDP but smaller than TCP.

4.4.2 Simulation Results

Table 4.7 shows the results of average end-to-end delay in each scenario for all three protocols. These results are also graphically shown in Figure 4.4. Table4.8andFigure4.5keeptrackof the proportion of effective data packets in each scenario when different protocols are applied. 46 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

Table 4.7:Averageend-to-enddelay(ms)incasetwo

Scenarios Controlperiod(ms) RRTTP UDP TCP 1608.4712248.37573716.779013 2508.3659448.30549515.311449 3458.4952968.36760514.519588 4428.4308248.27521514.730027 5398.4938848.40851214.530092 6358.5840698.28734714.012569 7328.8067728.35029213.745690 8308.7108118.32607814.413408

18 TCP UDP RRTTP 16

14

12

periodic packets (ms) 10 Average end-to-end delay for

8

60 50 45 42 39 35 32 30 Control period (ms)

Figure 4.4:Averageend-to-enddelay(ms)incasetwo

Table 4.8:Theproportionofeffectivepacketsincasetwo

Scenarios Control period RRTTP(%) UDP(%) TCP(%) 160ms99.9396.6397.15 250ms99.6396.7597.38 345ms99.7897.7597.08 442ms99.4297.1797.11 539ms99.9097.6196.15 635ms99.2196.8997.11 732ms99.1697.2497.00 830ms98.6597.0895.58

4.4.3 Analysis and Evaluations

It is seen from Table 4.7 and Figure 4.4 that UDP outperforms the others in terms of average end-to-end delay, about 8.3 ms. RRTTP’s delay performance isquitecomparablewiththatof 4.4. CASE TWO 47

TCP UDP RRTTP 100

99

98

97

96 Proportion of effective periodic packets (%) 95 60 50 45 42 39 35 32 30 Control period (ms)

Figure 4.5:Theproportionofeffectivepacketsincasetwo

UDP with small differences. TCP, on the other hand, almost doubles the time delay of UDP and RRTTP, reaching 16.8 ms in the worst case.

With regard to the proportion of effective data packets, as Table 4.8 and Figure 4.5 show, RRTTP distinguishes itself by having the highest proportioninallscenarios.Eveninscenario 8, where the most packets were transmitted, RRTTP still successfully received 98.65% data packets. That is even better than the other two protocols withtheirbestrecords.

Similar to Case One, UDP has the smallest end-to-end delay, but not the best effective packets ratio. The reason behind that is the same, the lack of compensation for packet losses. The design of UDP determines that UDP compromises its reliability for faster transmission speed. This trade-off can be clearly seen from both simulation Case One and Case Two.

Understandably, TCP has the longest end-to-end delay among all three protocols. As men- tioned in Case One, TCP’s retransmission and congestion control mechanism contribute the most to its undesired delay performance. Interestingly, TCPdoesnotperformwellineffective packets ratio in Case Two, when traffic load, rather than channel condition, is the main factor of packet drop out. In fact, it is observed from Figure 4.5 thatTCP’sperformancebecomes worse when the network is getting busier. Because of the retransmission mechanism, TCP demand more network capacity than UDP. When traffic load becomes heavier, TCP’s network capacity utilisation ratio increases significantly. Table 4.6 illustrates that in scenario 8, TCP utilises nearly 70% of network capacity which is 62% more thanUDP’s42.1%utilisationratio. There is no doubt that more network utilisation ratio leads tomorechancesofcongestion,and therefore results in longer delay and lower proportion of effective packets for TCP. 48 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

In Case Two, RRTTP successfully transmits most effective packets and keeps a relatively lower end-to-end delay at the same time. As Table 4.7 and Figure 4.4 demonstrate, RRTTP’s end-to-end delay is comparable with that of UDP. Although a upward trend has been observed for RRTTP when traffic load increases, the rise is less than 0.5ms,whichisnotsignificant.It is worth mentioning that RRTTP has a retransmission mechanism as well but it does not effect its end-to-end delay to the same extend as that of TCP due to thefactthatRRTTP’sreal-time retransmission mechanism pauses when new data packets are generated. Therefore, the end-to- end delay of RRTTP is smaller.

Other than that, RRTTP has a notable advantage over the other two protocols, reliability. Table 4.8 and Figure 4.5 clearly show that RRTTP’s proportionofeffectivepacketsisalotbetter than UDP and TCP. Almost 99% of packets successfully made their way to the destinations on time across all scenarios. RRTTP deploys bounded retransmission to compensate for packet losses. There is no doubt that traffic load has impact on RRTTP’s reliability performance. As the traffic load becomes heavy, it can be found that the proportion of effective packets drops to 98.65% for RRTTP in scenario 8. However, it is still much better than the other two protocols.

According to the analysis above, it can be summarised that RRTTP’s overall performance is the best in Case Two. With a small increase in end-to-end delay, RRTTP significantly improves transmission reliability in the circumstances where trafficloadvaries.

4.5 Case Three

Case Three and Case Four focused on testing the capability of prioritized transmission in RRTTP over wireless networks. In these two case studies, bothperiodicandsporadicdataflows were generated in each sending node. The purpose of these two simulation cases is to evaluate the protocol’s ability to transmit sporadic data packets by measuring the average end-to-end delay and the packet losses of sporadic data packets. The protocol that has the best performance on the above two criteria will be considered as a better choiceforsporadicdatatransmission.It is expected that the prioritized transmission mechanism in RRTTP is able to provide the most reliable and fast transmission service for the sporadic dataflowamongallthreetestedtransport protocols: UDP, TCP and RRTTP. 4.5. CASE THREE 49

4.5.1 Simulation Scenario Specifications

Case Three simulated the transmission of periodic and sporadic packets under different channel conditions by using RRTTP, UDP and TCP, respectively. The periodic packets were generated periodically based on a fixed control period of 50ms. Meanwhile, the sporadic packets, which have a higher priority, were randomly generated. For consistency, the number of sporadic packets was set to 155 in each of the scenarios. In Case Three, ten scenarios were tested altogether. The number of errors increased from scenario 1 toscenario10.Table4.9gives out the details of the simulation scenarios. Similar to Case One, all channel errors occurred randomly across all scenarios.

Table 4.9:Numberofchannelerrorsineachscenarioincasethree

Scenario 1 2 3 4 5 6 7 8 9 10 Numberofchannelerrors 38 57 74 94 127 152 189 208 222 250

4.5.2 Simulation Results

The average end-to-end delay for sporadic data packets is shown in Table 4.10, and the propor- tion of effective sporadic packets is depicted in Table 4.11.Thegraphicalpresentationofthe simulation results is illustrated in Figure 4.6 and Figure 4.7, respectively.

Table 4.10:Averageend-to-enddelayforsporadicdatapacketsincasethree

Channel Delay (ms) Scenario errors RRTTP UDP TCP 1389.37117210.46070419.902042 2579.77893910.78634026.559671 3749.41506910.63719653.496277 49410.04510410.46445023.996136 51279.76299210.74559966.243809 615210.43949510.38924745.826954 71899.93200210.85195854.068320 82089.31163210.81298447.840612 922210.01274510.39240744.413056 10 250 10.139967 10.834684 46.736117 50 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

TCP UDP 60 RRTTP

40

sporadic packets (ms) 20 Average end-to-end delay for

0 38 57 74 94 127 152 189 208 222 250 Number of channel errors

Figure 4.6:Averageend-to-enddelayforsporadicdatapacketsincasethree Table 4.11:Theproportionofeffectivesporadicdatapacketsincasethree

Scenarios Channel errors RRTTP(%) UDP(%) TCP(%) 13810095.48100 25710092.26100 37410092.26100 49410094.84100 512710086.45100 615210089.03100 718910087.10100 820810085.16100 922210089.68100 10 250 100 87.74 100

100

95

90

85 TCP UDP

Proportion of effective sporadic packets (%) RRTTP 80 38 57 74 94 127 152 189 208 222 250 Number of channel errors

Figure 4.7:Theproportionofeffectivesporadicdatapacketsincasethree.

It is observed from Table 4.10 and Figure 4.6 that RRTTP and UDPhavetheaverageend- to-end delay at the same level of about 10ms with minimum variations, while TCP’s end-to- end delay changes dramatically from 20ms to about 66ms at its peak time. This simulation 4.5. CASE THREE 51

result reveals that channel errors have significant impact onTCP’sdelayperformancebutnot on RRTTP or UDP. Both RRTTP and UDP display only a small time delay for sporadic data regardless of channel errors.

Regarding the reliability of transmitting sporadic packets, Table 4.11 and Figure 4.7 demon- strate that every single sporadic data packet was successfully transmitted in RRTTP and TCP across 10 scenarios. However, the situation in UDP was not as good as that of RRTTP and TCP. There were packet losses in every scenario when UDP was applied. More importantly, as the number of channel errors grew, the likelihood of packet losses increased in UDP.

4.5.3 Analysis and Evaluations

The UDP delay for sporadic packets in Case Three was small and stable. However, as to the reliability, UDP performed the worst among all the protocols. Figure 4.7 shows that there is adownwardtrendfortheproportionofeffectivesporadicpackets in UDP when the number of channel errors increased. Because UDP transmitted the sporadic packets in the same way it dealt with the periodic packets. UDP can ensure a small delay,butitwasunabletoensurea reliable transmission service for the sporadic packets. In other words, UDP is not suitable for transmitting sporadic packets in NCSs.

TCP and RRTTP are good at providing reliable transmission service for sporadic pack- ets. Figure 4.7 shows that they both successfully transmitted 100% sporadic packets in every scenario in Case Three. This demonstrates that the retransmission mechanism is an effective method to compensate for packet losses caused by channel errors. However, RRTTP’s delay performance is much better than that of TCP. By analysing the TCP trace files, it can be observed that TCP did not differentiate sporadic packets from periodic packets. When two traffic flows were sent at the same time, there was no guarantee that sporadic packets could be granted a prior access to the networks. As can be seen from Figure 4.6, the consequence was the longer and unstable average end-to-end delay in TCP compared with RRTTP. 52 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

4.6 Case Four

4.6.1 Simulation Scenario Specifications

In Case Four, the simulation is set up by changing the traffic load instead of channel errors. Similar to Case Two, the traffic load increased by adjusting the control periods for periodic data traffic. There are ten scenarios in this case, and scenario 1 has the minimum traffic load while scenario 10 has the most. As mentioned before, the sporadic data was randomly generated, but its packet number was fixed to be 155 in every scenario for consistency of simulation studies. Table 4.12 shows the details of the control period for each scenario.

Table 4.12:Controlperiodsforeachscenarioincasefour

Scenario 1 2 3 4 5 6 7 8 9 10 Controlperiod(ms) 60 50 45 42 39 35 32 30 27 25

4.6.2 Simulation Results

Figure 4.8 and Table 4.13 show the average end-to-end delay for sporadic data packets when using different transport layer protocols. The proportion of effective sporadic data packets can be found in Figure 4.9 and Table 4.14.

Table 4.13:Averageend-to-enddelay(ms)forsporadicpacketsincasefour

Scenarios Controlperiod RRTTP UDP TCP 160ms11.06385211.98956221.940364 250ms10.49294111.00729523.361823 345ms11.64433710.81080728.583056 442ms10.78391111.10181222.915075 539ms11.11465610.95681429.619019 635ms12.72635211.47716624.021483 732ms10.89440411.25041332.278414 830ms11.94350710.57067625.776271 927ms13.47535013.36019026.856075 10 25ms 13.677771 23.067848 188.907458 4.6. CASE FOUR 53

220 TCP 200 UDP RRTTP 180 160 140 120 100 80

sporadic packets(ms) 60

Average end-to-end delay for 40 20 0 60 50 45 42 39 35 32 30 27 25 Control period (ms)

Figure 4.8:Averageend-to-enddelay(ms)forsporadicpacketsincasefour

Table 4.14:Theproportionofeffectivesporadicpacketsincasefour

Scenarios Control period RRTTP(%) UDP(%) TCP(%) 160ms100.00100.00100.00 250ms100.0095.4899.35 345ms100.0096.13100.00 442ms100.0096.77100.00 539ms100.0095.48100.00 635ms100.0096.77100.00 732ms100.0097.42100.00 830ms100.0097.42100.00 927ms100.0096.13100.00 10 25ms 100.00 92.90 94.19

100

98

96

94

92 TCP UDP

Proportion of effective sporadic packets (%) RRTTP 90 60 50 45 42 39 35 32 30 27 25 Number of channel errors

Figure 4.9:Theproportionofeffectivesporadicpacketsincasefour 54 CHAPTER 4. RRTTP PERFORMANCE EVALUATION

4.6.3 Analysis and Evaluations

It is seen from Figure 4.8 and Table 4.13 that both RRTTP and UDPhadsmalldelayfrom scenario 1 to 9. But in scenario 10, UDP’s delay climbed up to about 23ms while RRTTP’s delay still remained relatively small at about 13.7ms. TCP’sdelayperformanceforsporadic packets was the worst, particularly in scenario 10 where sporadic packets spent over 188ms on average to reach their destinations.

It is clear that RRTTP had the best delay performance across all 10 scenarios in Case Four. Although the simulation results from scenario 1 to 9 do not indicate any strong relevance of sporadic packets delay and the traffic load, the sudden rises in delay performance for TCP and UDP in scenario 10 reveal the limitation of these two protocols on handling sporadic packets under heavy traffic load. On the other hand, RRTTP utilized its prioritized transmission mechanism to stop the transmission of periodic data flow in order to keep stable and small delay for sporadic transmission.

As Figure 4.9 and Table 4.14 illustrate, 100% sporadic data packets are transmitted success- fully across all scenarios with RRTTP. TCP was reliable in most cases but failed in scenario 2and10.UDPhadpacketlossesforsporadicpacketsinalmostevery scenario except for scenario 1. The worst case for UDP was scenario 10 where only 92.90% sporadic packets were successfully transmitted.

UDP had the worst reliability performance in Case Four. As thetrafficloadbecameheavier, UDP was prone to losing more sporadic packets. This result demonstrates that UDP is not a reliable option for sporadic transmission under heavy traffic load. TCP was able to provide reliable transmission service in most cases, but failed in scenario 2 and scenario 10. In scenario 2, only the last sporadic packet failed to arrive its destination. When it was firstly sent out, it was dropped due to the channel error. TCP retransmitted it when the retransmission timer expired. However, the retransmitted packet encountered another channel error during the retransmission. Unfortunately, the simulation stopped before TCP had another chance to compensate for the packet loss. In scenario 10, the overloaded traffic resulted in more changes of traffic collisions. Therefore, more sporadic packets were dropped in the end.

UDP is able to keep delay for sporadic packets at a very low level in most cases by taking the advantage of its simplicity. However, the delay value in scenario 10 indicates that UDP’s 4.7. SUMMARY OF PROTOCOL EVALUATION 55

delay increases when the traffic is too heavy to be handled. In regards to reliability, UDP cannot guarantee a reliable transmission service for sporadic packets. Figure 4.9 and Table 4.14 indicate that when traffic load rose, UDP was prone to droppingmoresporadicpackets.

TCP’s delay performance for sporadic packets is the worst among all three protocols in Case Four. It can be seen from Figure 4.8 and Table 4.13 that there isnoclearsignofstrongrelevance of TCP’s delay for sporadic packets and the traffic load from scenario 1 to 9. But in scenario 10, when traffic load was too much to be dealt with, the delay dramatically increased.

In contrast, RRTTP’s prioritized transmission service guarantees not only small end-to-end delay, but also the highest reliability when transmitting sporadic packets. The simulation results reveal that the QoS performance of the NCS network is significantly improved by RRTTP, especially in a congested network condition.

4.7 Summary of Protocol Evaluation

Four case studies have been conducted to evaluate the performance of RRTTP. Cases One and Case Two test RRTTP’s ability to support reliable and real-time transmissions, while the other two cases evaluate RRTTP’s ability to support prioritized transmissions when both periodic data and sporadic data packets are considered.

Comparisons in simulation results demonstrate that RRTTP outperforms UDP and TCP in terms of delay performance, packet losses and QoS performance. UDP is a simple and fast transmission protocol but it cannot compensate for any packet losses. TCP is a very reliable protocol without consideration of real-time transmissions. With a real-time retransmission mechanism, RRTTP is capable of providing fast and reliable transmission service for real- time applications in NCSs over wireless networks. Moreover,RRTTP’sintegratedprioritized transmission service improves the QoS performance of NCS networks, especially in a congested network condition.

Till now, we are confident to give positive answers to the questions raised at the beginning of this chapter: RRTTP is capable of keeping its delay performance at an acceptable level and also providing reliable transmissions at the same time; and RRTTP can improve the QoS performance in terms of reliability and time delay. 56 CHAPTER 4. RRTTP PERFORMANCE EVALUATION Chapter 5

Conclusion

Deploying networked control systems (NCSs) over wireless networks to achieve better scala- bility flexibility and lower maintenance cost is becoming more and more popular. But many problems such as long and unpredictable time delay and packetlossesareintroduced.Unfortu- nately, the widely-used transport layer protocols, TCP and UDP, are not designed for real-time applications over wireless networks. TCP is too complex to carry out real-time transmissions, whereas UDP cannot guarantee transmission reliability. Therefore, they are not suitable for many NCS application scenarios.

As a result, one of the objectives of this research project wastodevelopanewtransportlayer protocol, named reliable real-time transport layer protocol (RRTTP), to get a better performance of the time delay and packet losses. RRTTP features a real-time retransmission mechanism and an acknowledgement mechanism. They are designed to improve the reliability of both traffic flows. By resending the unacknowledged packets, RRTTP is abletocompensateforpacket losses. In addition, the real-time retransmission mechanism also takes the packet timeliness into account. Out-of-date packets are not retransmitted. Together with the packet validation detection process on both the RRTTP sender and receiver side,RRTTPisabletocheckthe effectiveness of each packet and make sure to only deliver thevalidpackets.

Another objective of this project is to design a prioritized transmission mechanism to deal with two different real-time traffic flows in NCSs. Periodic and sporadic data are two types of real-time data with different priorities. The prioritized transmission mechanism in RRTTP is able to transmit these two traffic flows in different manners inordertoimprovethenetwork’s QoS performance, particularly in a congested circumstance.

57 58 CHAPTER 5. CONCLUSION

Four simulationcase studies were conducted in NS-2 to evaluate the performance of RRTTP. TCP and UDP were included in the simulation in order to give comparative results. Simulation results show that RRTTP has better reliability than UDP and improved delay performance than TCP over wireless networks. Moreover, RRTTP has the best QoS performance on transmitting the sporadic data in terms of end-to-end time delay and proportion of effective packets among the three protocols. Specifically, RRTTP outperforms UDP andTCPwhenthecongestionsor channel errors occur in a wireless network.

Although the simulation results have demonstrated RRTTP’s effectiveness, there are still some future work expected for the development of RRTTP.

• In this project, only TCP and UDP were involved in the simulation process. More transport layer protocols, such as Real-time Transport Protocol and Reliable UDP, are expected to be included in the comparative simulation case studies in the future.

• The implementation into a real-world platform is part of the future development. Linux operation system is currently chosen to be the target platform. After RRTTP is imple- mented into Linux kernel, a series of practical experiments are expected to be conducted to give a more comprehensive evaluation of RRTTP. Literature Cited

Allman, V. P. M. (2000). Computing tcp’s retransmission timer. RFC 2988, RFC Editor.

Auslander, D. and Decotignie, J. (2005). Network Fundamentals. Handbook of Networked and Embedded Control Systems,pages197–223.

Baldwin, R., Davis, I., Nathaniel, J., and Midkiff, S. (1999). A real-time medium access control protocol for ad hoc wireless local area networks. ACM SIGMOBILE Mobile Computing and Communications Review,3(2):20–27.

Bernhardsson, B., Eker, J., and Persson, J. (2005). Bluetooth in control. Handbook of Networked and Embedded Control Systems,pages699–720.

Bhandarkar, S. and Reddy, A. (2004). TCP-DCR: Making TCP robust to non-congestion events. Networking Technologies, Services, and Protocols; Performance of Computer and Communication Networks; Mobile and Wireless Communications,pages712–724.

Bolot, J. (1993). End-to-end packet delay and loss behavior in the Internet. In Proceedings of Communications Architectures, Protocols and Applications,pages289–298.ACM.

Bova, T. and Krivoruchka, T. (1999). Reliable UDP protocol. Internet-draft, IETF.

Cervin, A., Henriksson, D., Lincoln, B., Eker, J., and Arzen,K.-E.(2003).Howdoescontrol timing affect performance? Analysis and simulation of timing using jitterbug and truetime. IEEE Control Systems,23(3):16–30.

Davis, R., Burns, A., Bril, R., and Lukkien, J. (2007). Controller area network (CAN) schedulability analysis: Refuted, revisited and revised. Real-Time Systems,35(3):239–272.

Farsi, M., Ratcliff, K., and Barbosa, M. (1999). An overview of controller area network. Computing & Control Engineering Journal,10(3):113–120.

59 60 LITERATURE CITED

Gui, L. (2010). A transport protocol for real-time applications in wireless network control systems. Master’s thesis, Queensland University of Technology.

Gui, L., Tian, Y., and Fidge, C. (2011). A conditional retransmission enabled transport protocol for real-time networked control systems. In The 36th IEEE Conference on Local Computer Networks (LCN’2011),pages235–238,Bonn,Germany.IEEE.

Hespanha, J., Naghshtabrizi, P., and Xu, Y. (2007). A survey of recent results in networked control systems. Proceedings of the IEEE,95(1):138–162.

Lam, P. and Liew, S. (2004). UDP-Liter: an improved UDP protocol for real-time multimedia applications over wireless links. In 1st International Symposium on Wireless Communication Systems, 2004,pages314–318.IEEE.

Larzon, L., Degermark, M., and Pink, S. (1999). Udp lite for real time multimedia applications. HP Laboratories Bristol, Tech. Rep. HPL-IRI-1999-001.

Lian, F., Moyne, J., and Tilbury, D. (2002). Network design consideration for distributed control systems. IEEE Transactions on Control Systems Technology,10(2):297–307.

Lian, F., Moyne, J., and Tilbury, D. (2005). Network protocols for networked control systems. Handbook of Networked and Embedded Control Systems,pages651–675.

Loeser, J. and Haertig, H. (2004). Low-latency hard real-time communication over switched ethernet. In Proceedings of 16th Euromicro Conference on Real-Time Systems.,pages13–22. IEEE.

Luck, R. and Ray, A. (1990). An observer-based compensator for distributed delays. Automatica (Oxford),26(5):903–908.

Nilsson, J., Wittenmark, B., T¨orngren, M., and Sanfridson,M.(1998).Timingproblemsin real-time control systems. Intern. Rep. ISRN KTH/MMK-98/20-SE,3:2000–2004.

Partridge, C. and Hinden, R. (1990). Version 2 of the reliabledataprotocol(RDP).RFC1151, RFC Editor.

Velten, D., Hinden, R., and Sax, J. (1984). Reliable data protocol. RFC 908, RFC Editor. LITERATURE CITED 61

Yang, A. and Eisaka, T. (2005). A switched ethernet protocol for hard real-time embedded system applications. In 19th International Conference on Advanced Information Networking and Applications.,volume2,pages41–44.IEEE.

Yang, T. (2006). Networked control system: a brief survey. IEEE Proceedings of Control Theory and Applications,153(4):403–412.

Zhang, W., Branicky, M., and Phillips, S. (2001). Stability of networked control systems. IEEE Control Systems Magazine,21(1):84–99.