# Control/Network  Codesign  Basics for IP-Based  Shared Networks

Authors: Miguel Díaz-Cacho Medina; Emma Delgado Romero; Antonio Barreiro Blas
Journal: Mathematical Problems in Engineering
 (2011)

---

## Abstract

Network and control relationship is an essential
aspect in the design of networked control systems (NCSs). The
design parameters are mainly centered in the transmission rate
and in the packet structure, and some studies have been made
to determine how transmission rate affects the network delay
and consequently the stability of the control. In Internet, these
analysis are mathematically complex due to the large number of
different potential scenarios. Using empirical methods, this work
deduces that the transmission scheduling problem of an NCS can
be solved by designing an appropriate transport protocol, taken
into account high and periodic sampling rates. The transport
protocol features are determined by simulation, using a new
test platform based on the NS2 network simulation suite, to
develop control/network codesign solutions. Conclusions of this
paper are that the transport features are packet-loss-based
flow control, best effort, and fairness, supplemented by a packet
priority scheme.


---

## Body

## 1. Introduction

In general, a closed-loop control system is designed without considering communication constraints due the proximity of the two extremes and the absence of sharing requirements in the control loop. If the control system has a network inserted between the controller and the plant, it is called networked control system or NCS, and communication constraints have to be taken into account, such as delays and packet losses. To maintain appropriate performance, control and sensor data transmitted through the network should have real-time requirements and are usually of small size. We call these control and sensor data,NCS data encapsulated in supermedia packets.If the control system uses Internet as intermediate network between controller and plant, the advantages are the high availability, testability, simple installation as well as low cost. These features make the use of Internet in control systems more popular in many applications, such as traffic control, teleoperation, and mobile robotics [1]. But Internet is a shared network, with variable delays and packet losses that degrades the performance of the NCS, or it may even become unstable.So far, the study of relationship between network and control system in an Internet based NCS or in teleoperation systems [2] is limited to adapt the controller design to several network variables (such as the delay constraint, the delay variation, and the number of consecutive losses [3, 4]). But in Internet, these network variables are unpredictable and unlimited. The network/control design techniques include some network design parameters, such as the transmission rate or the data packet structure to improve the performance of the NCS, and in Internet, this becomes mandatory. Then, a proper performance knowledge of an NCS under various network conditions allows to select proper codesign parameters that can model the response of the NCS.Other control and network performance studies are presented by Lian et al. [5, 6] focused on the performance analysis of MIMO control systems and on the study of the interaction between control and communication mechanism. But these studies are centered in the fieldbus technologies and LAN networks, where network load is due by the multiple network agents of the NCS. In our study, similar monitor criteria and graphs are presented, but completely oriented to the IP network features, with different results than the aforementioned works.The conclusions of Lian et al. studies [5] are that it is necessary to minimize the transmission rate to reduce the network load and not increase the delay, maintaining the control performance. This can be effective if the residual network load has no flow-control and best-effort features, such as in fieldbuses with multiagent NCSs or in IP-based networks with UDP background traffic. Further works have taken into account these results and have developed control scheduling algorithms to minimize the transmission rate. But in Internet, the main transport protocol of the residual network load is TCP, with flow-control and best-effort features, so, the aforementioned studies have no effect.This paper analyzes the responses of the NCS in networks with UDP/TCP/IP shared traffic for a range of propagation delays and queue size of the intermediate routers. This analysis will provide specific strategies to address the problem of transmission rate for NCSs on the Internet. The paper focuses on the problem with three main contributions.(i)
Definition of the performance basics and simulation parameters for NCSs in IP shared networks.(ii)
The development of a simulation framework in NS2 that provides implementation of several transport schemes. It delimits the possibility of actuation in the application and transport layers of the IP protocol architecture, basically in the transmission scheduling and flow-control mechanism.(iii)
The presentation of empirical results of the simulations in several IP shared scenarios, and codesign conclusion based on these results. Particularly, the main contribution of this paper focuses on the suitability of using a transport protocol with a packet-loss-based flow-control mechanism and best-effort feature, in addition to a packet priority scheme and fairness with other Internet data flows.This paper is organized as follows. After the Introduction and Section2, a normalization of network and control parameters are defined in Section 3, such as sharing characteristics, quality of control, and error measurement. A test platform for simulation of codesign solutions is presented in Section 4. Results of diverse simulation situations in a case study are in Section 5, and this gives specific transport design lines in Section 6. Finally conclusions are presented in Section 7.


## 2. Related Work

Classical techniques of NCS look to the network as a passive element, trying to adapt the control to a previously defined network. Modern techniques have emerged with the generic name of codesign that look to the network as an active element of the NCS. They try to model and integrate the network in the control system. Some authors refer generically to this line of work network-based control (NBC).


### 2.1. Packet Based Control

This line scans the contents and structure ofsupermedia packets to optimize the network performance and efficiency [7–10]. This method allows to work on predictive control, because the controller (or the plant) can send actual, past, and future NCS data in the same packet. Thus, if the packet is lost (or the transport control decides not to send it), the other end has predictive information received in previous packets [11]. Some authors take in to consideration this method, as seen in [12, 13].


### 2.2. Codesign of Control and Transmission Rate

Transmission rate scheduling to manage the available network resources in a fairly form prioritizes dynamically the NCS that needs more bandwidth to maintain stability. This line of work studies protocols, middleware systems, and control theory. In [14], a dynamic control algorithm is proposed that allows the use of network resources by the node with the biggest error. In [15], an NCS is designed that switches between open, and closed-loop system depending on the network access availability. In [16], a study where the optimal scheduling problem under rate-monotonic constraints and NCS stability constraints is presented. In [17], a NS2-based framework is presented to make codesign experiments. In [13], predictive control with codesign techniques to use dynamically network resources has been done. An interesting area of research is the distribution of available bandwidth between different NCS on a shared network, taking into account the state of the NCS by a supervisory system using adaptive sampling [18–20].


### 2.3. Codesign of Control and Gain

Scheduling the transmission rate is not the only line involved of an NCS that process the network status. In [21], a middleware system that modifies control gains is studied, taking in to consideration the network status. The controller output algorithm depends on the remote plant and controller global configuration. The state of the network is known by sending probe packets.


### 2.4. NCS Specific Protocols

This line is completely centered in the network component of the NCS. There are someNCS data protocols at all the layers of the IP architecture. In layer 2, NCS protocols focus on field bus technology, CAN bus, or recently EtherCAT; in network layer, the NCS research lines are in the link-queue analysis (new RED queues) and in the multicast solutions to improve real-time requirements and network use efficiency; in the transport layer, there are some solutions around the UDP protocol, developing flow-control features, such as TFRC [22], DCCP [23], or the trinomial algorithm [24]; the application layer solutions are usually focused on developing particular or generic frameworks and NCS data structures.


### 2.5. Cosimulation

To work with codesign methods, some frameworks are developed. In [25, 26], a new agent is developed to reproduce controllers and plants in the TCL user space of the NS2 network simulation suite. Authors make tests in a distributed MIMO NCS to study relationships between control and network parameters, but protocols are not tested, and only queue sizes of the routers are varied to test the NCS responses. Shared scenarios with different transport flows are not tested.


## 2.1. Packet Based Control

This line scans the contents and structure ofsupermedia packets to optimize the network performance and efficiency [7–10]. This method allows to work on predictive control, because the controller (or the plant) can send actual, past, and future NCS data in the same packet. Thus, if the packet is lost (or the transport control decides not to send it), the other end has predictive information received in previous packets [11]. Some authors take in to consideration this method, as seen in [12, 13].


## 2.2. Codesign of Control and Transmission Rate

Transmission rate scheduling to manage the available network resources in a fairly form prioritizes dynamically the NCS that needs more bandwidth to maintain stability. This line of work studies protocols, middleware systems, and control theory. In [14], a dynamic control algorithm is proposed that allows the use of network resources by the node with the biggest error. In [15], an NCS is designed that switches between open, and closed-loop system depending on the network access availability. In [16], a study where the optimal scheduling problem under rate-monotonic constraints and NCS stability constraints is presented. In [17], a NS2-based framework is presented to make codesign experiments. In [13], predictive control with codesign techniques to use dynamically network resources has been done. An interesting area of research is the distribution of available bandwidth between different NCS on a shared network, taking into account the state of the NCS by a supervisory system using adaptive sampling [18–20].


## 2.3. Codesign of Control and Gain

Scheduling the transmission rate is not the only line involved of an NCS that process the network status. In [21], a middleware system that modifies control gains is studied, taking in to consideration the network status. The controller output algorithm depends on the remote plant and controller global configuration. The state of the network is known by sending probe packets.


## 2.4. NCS Specific Protocols

This line is completely centered in the network component of the NCS. There are someNCS data protocols at all the layers of the IP architecture. In layer 2, NCS protocols focus on field bus technology, CAN bus, or recently EtherCAT; in network layer, the NCS research lines are in the link-queue analysis (new RED queues) and in the multicast solutions to improve real-time requirements and network use efficiency; in the transport layer, there are some solutions around the UDP protocol, developing flow-control features, such as TFRC [22], DCCP [23], or the trinomial algorithm [24]; the application layer solutions are usually focused on developing particular or generic frameworks and NCS data structures.


## 2.5. Cosimulation

To work with codesign methods, some frameworks are developed. In [25, 26], a new agent is developed to reproduce controllers and plants in the TCL user space of the NS2 network simulation suite. Authors make tests in a distributed MIMO NCS to study relationships between control and network parameters, but protocols are not tested, and only queue sizes of the routers are varied to test the NCS responses. Shared scenarios with different transport flows are not tested.


## 3. Network and Control Parameters and Variables

A network/control codesign framework should take into account a lot of parameters and variables to obtain correct results in a realistic way. Parameters are design values that can be controlled by the designer and determine the NCS environment; variables are network and control responses that affect the performance of the NCS. In Figure1, we present a flow chart for control/network parameters/variables involved in this study. From a control system point of view, the network parameters and variables cannot be modified, and the problem is how to model the control parameters that affect the network to maintain the control variables in an acceptable way.Figure 1
Control and network codesign parameters and variables.Control performance is a variable that depends mainly on the controller design, the plant environment, and (among others) on returned network variables, such as delay, jitter, or packet losses. All these network variables depend mainly on the characteristics of the transmission path and the amount and type of background traffic in the Internet. Transmission path is a parameter represented by the queue size of intermediate routers and propagation delay; background traffic is a parameter that has direct effect on the queue occupation and affect the network delay. Transmission rate and data packet structure are control parameters that affects directly to the control and network variables, as described below.To normalize the empirical studies in Internet-based NCS, some initial assumptions should be made but without limiting the basic conclusions of the results.Assumption 1.
Internet (or any IP-based network) is the network involved in this study. Physical and link layer technologies are unknown and not parameterizable, but we parameterize the propagation delay and the type and amount of background shared traffic. In the IP layer, we parameterize the queue type and size of intermediate routers. The first layer where the control system can actuate is the transport layer mainly by selecting an appropriate transport protocol.Assumption 2.
All thesupermedia packets are of fixed size ps∣ncs and include only one NCS sample. Thus, packet structure is fixed, and this study does not depend on it.Assumption 3.
Data sampling and packet transmission rate are equal and fixed in both extremes of the NCS. This simplifies the design without loss of generality and maintains transmission rate without dependence on the network status.Assumption 4.
The control system is well designed in closed loop with preselected fixed delays. Stability with variable delays is conditioned to situations that cannot be predicted in Internet although delays and packet losses can be monitored [4].Assumption 5.
No initial control/network codesign, no flow-control protocol and no network-dependence for the control system to know the behavior of the control system in different network situations. Network and control are completely transparent. The control system does not change its design with the network parameters/variables, and network does not change with the control parameters/variables. The base transport protocol for NCS is UDP.Control performance, transmission rate, queue size of the intermediate routers, and network background traffic are explained below.


### 3.1. Performance Criteria

Multiple performance criteria can be created, based on the importance of the network and the control system. The literature uses the term quality of control (QoC) [27], but we use the term performance index denoted by P, adding subscripts to differentiate one index from the others. P and QoC have an opposite relationship: the higher is P, the lower is QoC and vice versa. When both values are normalized between 0 and 1, the relationship between the two terms is given by(3.1)QoC=1-P.Performance criteria should have a control component and in some situations one or more network components; the control component should be an control-error based indicator. To compare the error-based performance between different NCSs, the error must be normalized. We define the normalized errorEn of an NCS as the result of dividing the instantaneous error E by the maximum permissible error Emax defined as a design parameter for that NCS (3.2). The maximum permissible error depends on the design criteria of the NCS and must have a value low enough to maintain system stability and high enough to keep the NCS operating(3.2)En=EEmax⁡.To make the error independent of time, instead of the mainly used integral absolute errorIAE indicator (3.3), we propose the use of average absolute error AAE (3.4), where T is the measuring interval(3.3)IAE=∫0T|e(τ)|dτ,(3.4)AAE=1T∫0T|e(τ)|dτ.IAE should be measured in a minimal interval ofTms=1/vtms, where vtms is the minimum transmission rate (in packets/sec) to maintain the stability of the NCS (given in (3.8)), but AAE can be measured in continuous time simulation or execution.In shared networks, where several NCSs or distributed systems can work, performance indexesPI must take into account the amount of control and network variables for all NCSs. It does not help optimize an NCS if that implies to reduce the benefits of others. To compute control and network responses into the performance index, two relevance and scale factors are needed: K1 for the error component, and K2 for the network component. So, in a network with N NCSs, we define four different performance indexes(i)
P0 (3.5): it measures the amount of normalized error of all NCSs in the network. This performance index takes into account only the control systems. P0 is used to determine the stability region in Section 5.2. 										(3.5)P0=∑i=0NEni.(ii)
P1 (3.6): this performance index computes the error and normalized delay (τn) respect to the maximum permissible delay to maintain NCS stability (τms) in both directions. Then, τn=τ/τms,
(3.6)P1=K1∑i=0NEni+K2∑i=0Nτni.(iii)
P2 (3.7): P2 is used to measure the relationship between losses and benefits. The amount of packet loss should be normalized respect the amount of transmitted packets, so it matches the probability of packet loss p. If vt and the arrival rate (or success rate) vr in the destination are known, p=1-(vr/vt),
(3.7)P2=K1∑i=0NEni+K2∑i=0Npi.(iv)
P3: finally, P3 is used to determine the degree of involvement of the transmission rate vt, normalized respect to the sampling rate (vtn=vt/vs, where vs is the sampling rate). This index allows to punish excessive transmission rate to the network. In this work, using Assumption 3vt=vs, then vtn=1 and P3 is not taken into account.


### 3.2. Transmission Rate

The influence of the transmission rate on the performance of an NCS is given by the relationship between the network use, the delay induced by the network, and the percentage of packet losses. Figure3 [5] represents the influence of different types of control on their performance, as a function of the sampling/transmission rate. Performance index is usually P0.In Figure3, the performance degradation with high transmission rate is highlighted by point Z, caused mainly by increasing packet losses and autoinduced network delays. Point Y is defined as the minimum transmission rate of the NCS to maintain acceptable performance. In [5], a methodology to calculate the minimum and maximum transmission rate (points Y and Z, resp.) for unshared networks is proposed.The lower limit for pointY is the point X, given by (3.8), where BWc is the controller bandwidth in closed loop operation [28].(3.8)20<vtBWc.PointZ has an upper limit given by (3.9), where Cl is the point to point link capacity for link l and L is the set of point to point links traversed by the NCS data flow. Ca is the available capacity of the network link(3.9)Z∣max⁡=Ca∣max⁡=min⁡l∈L{Cl}.PointsY and Z vary depending on the available capacity of the network (Ca) and the background traffic features.


### 3.3. Queue Size

Queue size (qs) has direct relationship with network delay (τ) as seen in [(10) (presented in [25])] for Drop Tail queues, where l is a link index, L is the amount of links (or queues), τpl is the propagation delay for link l, ps is the packet size in bytes (as in Assumption 2), qsl is the queue size for link l (in packets), and Cl is the link l capacity in bits/sec(3.10)τmax⁡=∑l=1L(τpl+8ps(qsl+1)Cl).Drop Tail queues measure their size in packets, where the packet size has maximum limit given by the MTU (maximum transfer unit) parameter of the link layer technology. For shared networks with different data packet sizes, the maximum delay is calculated by substituting theps variable by its maximum potential value. That has direct effect on the packet efficiency of the NCS data in Internet, where an IP packet has a maximum value of 65.535 given by the Total Length field of the IPv4 packet header, and supermedia packets are of small size.


### 3.4. Background Traffic

In shared networks like the Internet, we distinguish traffic without flow control (UDP) and traffic with flow control (TCP). Available bandwidth depends on the amount of traffic of the two flow-styles. To simplify the explanation, we callbackground traffic to all data flows that are not related with NCS traffic. Thus, an unshared network has not background traffic in the host to host link. Background traffic is a network variable treated as a network parameter by the simulation environment. For IP shared networks, we can establish a basic classification for background traffic characteristics and their influence in the available capacity (represented by Ca) of the network link(i)
UDP shared: shared network with background traffic without flow control (mainly UDP protocol). IfC is the host to host link capacity and Cu is the capacity used by the UDP flows, available capacity is
(3.11)Ca=C-Cu.(ii)
TCP shared: shared network with flow-controlled background traffic (mainly TCP protocol). In these networks, a defined available capacity does not exist because of the best-effort feature of the TCP traffic. Then, in practice,Ca=C, but always with varying delay and packet losses. The best-effort feature is reflected in the TCP model by Padhye et al. [29], where the transmission rate increases, while the network is not saturated, that is, while there is no packet loss (p=0), as seen in (3.12). In (3.12), p is the probability of packet loss and tRTO is the retransmission time. The packet size of a TCP flow is usually higher than the supermedia packet size and is represented by ps|tcp(3.12)T=ps|tcpRTT2p/3+tRTO(33p/8)p(1+32p2).(iii)
TCP/UDP shared: shared network with both types of traffic, UDP and TCP data flows. Internet is a TCP/UDP shared network.


## 3.1. Performance Criteria

Multiple performance criteria can be created, based on the importance of the network and the control system. The literature uses the term quality of control (QoC) [27], but we use the term performance index denoted by P, adding subscripts to differentiate one index from the others. P and QoC have an opposite relationship: the higher is P, the lower is QoC and vice versa. When both values are normalized between 0 and 1, the relationship between the two terms is given by(3.1)QoC=1-P.Performance criteria should have a control component and in some situations one or more network components; the control component should be an control-error based indicator. To compare the error-based performance between different NCSs, the error must be normalized. We define the normalized errorEn of an NCS as the result of dividing the instantaneous error E by the maximum permissible error Emax defined as a design parameter for that NCS (3.2). The maximum permissible error depends on the design criteria of the NCS and must have a value low enough to maintain system stability and high enough to keep the NCS operating(3.2)En=EEmax⁡.To make the error independent of time, instead of the mainly used integral absolute errorIAE indicator (3.3), we propose the use of average absolute error AAE (3.4), where T is the measuring interval(3.3)IAE=∫0T|e(τ)|dτ,(3.4)AAE=1T∫0T|e(τ)|dτ.IAE should be measured in a minimal interval ofTms=1/vtms, where vtms is the minimum transmission rate (in packets/sec) to maintain the stability of the NCS (given in (3.8)), but AAE can be measured in continuous time simulation or execution.In shared networks, where several NCSs or distributed systems can work, performance indexesPI must take into account the amount of control and network variables for all NCSs. It does not help optimize an NCS if that implies to reduce the benefits of others. To compute control and network responses into the performance index, two relevance and scale factors are needed: K1 for the error component, and K2 for the network component. So, in a network with N NCSs, we define four different performance indexes(i)
P0 (3.5): it measures the amount of normalized error of all NCSs in the network. This performance index takes into account only the control systems. P0 is used to determine the stability region in Section 5.2. 										(3.5)P0=∑i=0NEni.(ii)
P1 (3.6): this performance index computes the error and normalized delay (τn) respect to the maximum permissible delay to maintain NCS stability (τms) in both directions. Then, τn=τ/τms,
(3.6)P1=K1∑i=0NEni+K2∑i=0Nτni.(iii)
P2 (3.7): P2 is used to measure the relationship between losses and benefits. The amount of packet loss should be normalized respect the amount of transmitted packets, so it matches the probability of packet loss p. If vt and the arrival rate (or success rate) vr in the destination are known, p=1-(vr/vt),
(3.7)P2=K1∑i=0NEni+K2∑i=0Npi.(iv)
P3: finally, P3 is used to determine the degree of involvement of the transmission rate vt, normalized respect to the sampling rate (vtn=vt/vs, where vs is the sampling rate). This index allows to punish excessive transmission rate to the network. In this work, using Assumption 3vt=vs, then vtn=1 and P3 is not taken into account.


## 3.2. Transmission Rate

The influence of the transmission rate on the performance of an NCS is given by the relationship between the network use, the delay induced by the network, and the percentage of packet losses. Figure3 [5] represents the influence of different types of control on their performance, as a function of the sampling/transmission rate. Performance index is usually P0.In Figure3, the performance degradation with high transmission rate is highlighted by point Z, caused mainly by increasing packet losses and autoinduced network delays. Point Y is defined as the minimum transmission rate of the NCS to maintain acceptable performance. In [5], a methodology to calculate the minimum and maximum transmission rate (points Y and Z, resp.) for unshared networks is proposed.The lower limit for pointY is the point X, given by (3.8), where BWc is the controller bandwidth in closed loop operation [28].(3.8)20<vtBWc.PointZ has an upper limit given by (3.9), where Cl is the point to point link capacity for link l and L is the set of point to point links traversed by the NCS data flow. Ca is the available capacity of the network link(3.9)Z∣max⁡=Ca∣max⁡=min⁡l∈L{Cl}.PointsY and Z vary depending on the available capacity of the network (Ca) and the background traffic features.


## 3.3. Queue Size

Queue size (qs) has direct relationship with network delay (τ) as seen in [(10) (presented in [25])] for Drop Tail queues, where l is a link index, L is the amount of links (or queues), τpl is the propagation delay for link l, ps is the packet size in bytes (as in Assumption 2), qsl is the queue size for link l (in packets), and Cl is the link l capacity in bits/sec(3.10)τmax⁡=∑l=1L(τpl+8ps(qsl+1)Cl).Drop Tail queues measure their size in packets, where the packet size has maximum limit given by the MTU (maximum transfer unit) parameter of the link layer technology. For shared networks with different data packet sizes, the maximum delay is calculated by substituting theps variable by its maximum potential value. That has direct effect on the packet efficiency of the NCS data in Internet, where an IP packet has a maximum value of 65.535 given by the Total Length field of the IPv4 packet header, and supermedia packets are of small size.


## 3.4. Background Traffic

In shared networks like the Internet, we distinguish traffic without flow control (UDP) and traffic with flow control (TCP). Available bandwidth depends on the amount of traffic of the two flow-styles. To simplify the explanation, we callbackground traffic to all data flows that are not related with NCS traffic. Thus, an unshared network has not background traffic in the host to host link. Background traffic is a network variable treated as a network parameter by the simulation environment. For IP shared networks, we can establish a basic classification for background traffic characteristics and their influence in the available capacity (represented by Ca) of the network link(i)
UDP shared: shared network with background traffic without flow control (mainly UDP protocol). IfC is the host to host link capacity and Cu is the capacity used by the UDP flows, available capacity is
(3.11)Ca=C-Cu.(ii)
TCP shared: shared network with flow-controlled background traffic (mainly TCP protocol). In these networks, a defined available capacity does not exist because of the best-effort feature of the TCP traffic. Then, in practice,Ca=C, but always with varying delay and packet losses. The best-effort feature is reflected in the TCP model by Padhye et al. [29], where the transmission rate increases, while the network is not saturated, that is, while there is no packet loss (p=0), as seen in (3.12). In (3.12), p is the probability of packet loss and tRTO is the retransmission time. The packet size of a TCP flow is usually higher than the supermedia packet size and is represented by ps|tcp(3.12)T=ps|tcpRTT2p/3+tRTO(33p/8)p(1+32p2).(iii)
TCP/UDP shared: shared network with both types of traffic, UDP and TCP data flows. Internet is a TCP/UDP shared network.


## 4. NCS Test Platform

To show the influence of IP shared networks on control system performance and to test the transport and control strategies, some control and network topology experiences over a simulated test platform were performed.The test platform is developed in the NS2 network simulation suite that allows to develop all the layers of the OSI protocol stack. NS2 has a C++ library to develop new agents and applications and a TCL environment to create nodes and network topologies. TCL environment works in user space. The scheme of the complete test platform is presented in Figure2 and the complete test platform is available to download in [30].Figure 2
Test platform to develop NCS codesign solutions.Figure 3
Relationship between performance and transmission rate. Theoretical approach.The test platform has one agent (tdtp_ag.o) and one application (ncsd_app.o). The agent is focused on the transport layer and implements a bidirectional transport scheme presented in [10]. The application implements controller and plant logics. User space in NS2 allows to select several transport and application parameters, such as the transport scheme and the NCS sampling rate, as well as the network topology and other network parameters.The transport layer allows to test well-known transport schemes (such as TCP, UDP, trinomial algorithm, or TFRC) and to develop new transport protocols for NCS. For any solution that uses the codesign as a start point, it is necessary to define a new sublayer between the transport and application layer, whereNCS data and network variables can interrelate. In some cases, the control system itself monitors network variables to implement a network-based control, such as the gain scheduling solutions [21].In our experiments, UDP transport protocol is used for theNCS data to meet Assumptions 3 and 5. In this way, the NCS transport protocol may not affect the delay variation and packet losses of the NCS data flow.


### 4.1. Control Application Layer

Controllers and plants are simulated by using a first-order Euler discretization method, then the state-space equations are used to be implemented in the NCS application (ncsd_app.o). Sampling rate is fixed as a parameter, and the sample is calculated with the last received data using a software-based hold last sample strategy (HLS); initial conditions are set to 0.At this moment, two models of plants (a mass spring and a gantry crane) and three controllers (LQR controller for each plant and a PID controller for the mass-spring) are developed in thencsd_app.o module of the test platform. All the NCSs implemented are validated comparing results with Matlab simulation and are designed according to Assumption 4. In this work, we use the gantry crane model with LQR controller. Equations in state space for the gantry crane are presented in (4.1) for the plant and in (4.2) for the controller, where r is the reference signal(4.1)x⃗̇=(01000-18.30.9590000100-9.5-0.003)x⃗+(07.20-0.95)u,(4.2)u=N⋅r-K⋅x⃗,withK=(12.1661,0.6646,-22.8596,and-3.4107) and N=12.1661.Figure4 shows the simulated gantry-crane teleoperated system.Figure 4
Gantry-crane NCS.


### 4.2. Transport Layer

This layer involves acontrol/network codesign sublayer and the transport control sublayer. (1)
Control/Network Codesign Sublayer: this sublayer relates network parameters with control parameters and could incorporate scheduling algorithms, deadband filters, scattering transformations, or other control/network design procedures.(2)
Transport Control Sublayer: the transport control sublayer implements several transport control functions (TCF), the transport scheduler (TS), and packet encapsulation and decapsulation using the transport header (TH).The transport control function (TCF) implements the transport control algorithm to determine the transmission rate in the transport scheduler (TS). Transmission rate (in packets per second) is usually given by the inverse of an interpacket gap (IPG) variable calculated by the TCF.Transport encapsulation and decapsulation functions insert the transport header (TH) in transmission, and process the TH in reception. Transport header includes thebackward congestion notification tag (BCN) to implement packet-loss-based flow-control by processing received sequence numbers.Using UDP as the transport scheme, the transport scheduler is transparent, making the transmission rate equal to the sampling rate, as in Assumption3. Then, the TCF and encapsulation/decapsulation functions have no effect on the results.


### 4.3. Network Topology

Figure5 shows the created network topology to simulate a standart Internet link with a bottleneck between two routers R1 and R2 and several traffic nodes. The parameters of this link are changed to obtain performance of the NCS depending on the queue size and extreme to extreme propagation delay. The MTU parameterized in the trunk link has a value of 1500 bytes, thus the maximum packet size (ps) in the queues has the same value to meet Assumption 2.Figure 5
Network topology in test platform.The simulation scenarios attempt to reproduce different network congestion situations on the basis of the classification made in Section3.4.(i)
Scenario e0. Scenario e0 represents an unshared network without background traffic. This scenario represents a situation with constant delays and without packet losses if the transmission speed is less than the capacityC of the trunk link between R1 and R2.(ii)
Scenario e5. Scenario e5 represents an UDP shared network. It uses a background UDP flow with a transmission rate of0.8·C in both directions and a packet size of 100 bytes. In this scenario, the delays are more variable, and there will be packet losses if the transmission speed is greater than the remaining capacity of the backbone link (0.2·C).(iii)
Scenario e13. Scenario e13 represents a TCP shared network. This scenario has exclusively TCP traffic with FTP (File transfer protocol) application data using a file with infinite size and packet size limited by the MTU to 1500 bytes. There are three FTP traffic sources, and the goal is to look at the reactions to flow controlled traffic load.(iv)
Scenario e83. Scenario e83 represents a UDP/TCP shared network. This scenario reproduces a situation with UDP traffic with a transmission rate of0.8·C and three FTP traffic sources. This scenario performs a critical network congestion situation with variable delays and packet losses.(v)
Scenario ev02. Scenario ev02 represents a varying UDP, TCP, and UDP/TCP shared network. It reproduces a varying network congestion situation in both directions of transmission. It has transitions from mixed UDP and TCP flows to reproduce high, middle, and low congestion transitions.


## 4.1. Control Application Layer

Controllers and plants are simulated by using a first-order Euler discretization method, then the state-space equations are used to be implemented in the NCS application (ncsd_app.o). Sampling rate is fixed as a parameter, and the sample is calculated with the last received data using a software-based hold last sample strategy (HLS); initial conditions are set to 0.At this moment, two models of plants (a mass spring and a gantry crane) and three controllers (LQR controller for each plant and a PID controller for the mass-spring) are developed in thencsd_app.o module of the test platform. All the NCSs implemented are validated comparing results with Matlab simulation and are designed according to Assumption 4. In this work, we use the gantry crane model with LQR controller. Equations in state space for the gantry crane are presented in (4.1) for the plant and in (4.2) for the controller, where r is the reference signal(4.1)x⃗̇=(01000-18.30.9590000100-9.5-0.003)x⃗+(07.20-0.95)u,(4.2)u=N⋅r-K⋅x⃗,withK=(12.1661,0.6646,-22.8596,and-3.4107) and N=12.1661.Figure4 shows the simulated gantry-crane teleoperated system.Figure 4
Gantry-crane NCS.


## 4.2. Transport Layer

This layer involves acontrol/network codesign sublayer and the transport control sublayer. (1)
Control/Network Codesign Sublayer: this sublayer relates network parameters with control parameters and could incorporate scheduling algorithms, deadband filters, scattering transformations, or other control/network design procedures.(2)
Transport Control Sublayer: the transport control sublayer implements several transport control functions (TCF), the transport scheduler (TS), and packet encapsulation and decapsulation using the transport header (TH).The transport control function (TCF) implements the transport control algorithm to determine the transmission rate in the transport scheduler (TS). Transmission rate (in packets per second) is usually given by the inverse of an interpacket gap (IPG) variable calculated by the TCF.Transport encapsulation and decapsulation functions insert the transport header (TH) in transmission, and process the TH in reception. Transport header includes thebackward congestion notification tag (BCN) to implement packet-loss-based flow-control by processing received sequence numbers.Using UDP as the transport scheme, the transport scheduler is transparent, making the transmission rate equal to the sampling rate, as in Assumption3. Then, the TCF and encapsulation/decapsulation functions have no effect on the results.


## 4.3. Network Topology

Figure5 shows the created network topology to simulate a standart Internet link with a bottleneck between two routers R1 and R2 and several traffic nodes. The parameters of this link are changed to obtain performance of the NCS depending on the queue size and extreme to extreme propagation delay. The MTU parameterized in the trunk link has a value of 1500 bytes, thus the maximum packet size (ps) in the queues has the same value to meet Assumption 2.Figure 5
Network topology in test platform.The simulation scenarios attempt to reproduce different network congestion situations on the basis of the classification made in Section3.4.(i)
Scenario e0. Scenario e0 represents an unshared network without background traffic. This scenario represents a situation with constant delays and without packet losses if the transmission speed is less than the capacityC of the trunk link between R1 and R2.(ii)
Scenario e5. Scenario e5 represents an UDP shared network. It uses a background UDP flow with a transmission rate of0.8·C in both directions and a packet size of 100 bytes. In this scenario, the delays are more variable, and there will be packet losses if the transmission speed is greater than the remaining capacity of the backbone link (0.2·C).(iii)
Scenario e13. Scenario e13 represents a TCP shared network. This scenario has exclusively TCP traffic with FTP (File transfer protocol) application data using a file with infinite size and packet size limited by the MTU to 1500 bytes. There are three FTP traffic sources, and the goal is to look at the reactions to flow controlled traffic load.(iv)
Scenario e83. Scenario e83 represents a UDP/TCP shared network. This scenario reproduces a situation with UDP traffic with a transmission rate of0.8·C and three FTP traffic sources. This scenario performs a critical network congestion situation with variable delays and packet losses.(v)
Scenario ev02. Scenario ev02 represents a varying UDP, TCP, and UDP/TCP shared network. It reproduces a varying network congestion situation in both directions of transmission. It has transitions from mixed UDP and TCP flows to reproduce high, middle, and low congestion transitions.


## 5. Simulation Results for IP Shared Networks

Tests have been made using the gantry-crane plant with LQR controller. Simulation parameters are shown in Table1.Table 1
Simulation parameters.
NCSgantry-crane LQRreference signal10sin(2πt/13)Emax5τms0.07 secpacket size (bytes)100prop.delay(msec)30Simulation interval (sec)100Two main simulations are designed to determine the response of an NCS in an IP based network for different shared scenarios as proposed in Section3.4. First, the transmission rate limits to maintain performance index P0 in an acceptable range are obtained. As second simulations, the stability region (in similar terms as in [31]) depending on the propagation delay is obtained.


### 5.1. Performance IndexP0 Depending on Queue Size and Transmission Rate

P0, τ (=P1|(K1,K2)=(0,1)) and p (=P2|(K1,K2)=(0,1)) are obtained as functions depending on the transmission rate (vt) and the queue size (qs) of the intermediate routers (5.1) for different scenarios (ex). Measured delay τ is the average delay for success received packets along the simulation interval. The use of variable queue sizes can represent different transmission paths for the supermedia packets(5.1)P0,τ,p=f(vt,qs,ex).The results are graphically presented for scenarios e0, e5, e13, e83, and ev02 in Figures6, 7, 8, 9, and 10 respectively, where vt axis is in logarithmic scale for presentation purposes. Subgraphs (a) show the P0 index and related stability region, (b) the delay, and (c) the normalized loss rate. The stability region is determined by selecting vt and qs, where P0≤1, represented graphically by the projection of P0≤1 in the horizontal plane in subgraphs (a).Scenario e0. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario e5. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario e13. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario e83. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario ev02. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1), and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Figure11 represents performance indexes P0  (Figure 11(a)),  P1 (Figure 11(b)),  and P2  (Figure 11(c))  obtained by simulation, setting qs=60. Relationship between performance P0 and transmission rate, theoretically represented in Figure 3, is obtained in Figure 11(a) for all scenarios except e13, because in this scenario, with qs=60, the NCS is always unstable, due to a delay higher than τms as seen in Figure 11(b). In Figures 11(a) and 11(b), points Y (minimum transmission rate) and Z (maximum transmission rate) are highlighted. Scenario ev02 is not represented in Figure 11(b), because the average delay measured among the complete simulation interval is not representative in a varying scenario.Relationship between (a) performance, (b) delay, and (c) losses versus transmission rate for a gantry-crane NCS in different network scenarios.
(a)
PerformanceP0 for qs=60 (NCS granty-crane LQR)(b)
PerformanceP1 for qs=60 (NCS granty-crane LQR)(c)
PerformanceP2 for qs=60 (NCS granty-crane LQR)Analyzing all the graphs, some interesting remarks are obtained, and some conclusions are given in Section6.Remark 5.1.
The NCS stability region in all scenarios correlates with smallest delay (lower thanτms=0.07 s), as seen in Figures 6(a), 6(b), 7(a), 7(b), 8(a), 8(b), 9(a), 9(b), 10(a), and 10(b)) of Figures 6, 7, 8, 9, and 10, as theoretically expected.Remark 5.2.
In TCP/UDP shared scenarios (e13, e83, and ev02), whenvt remains constant, the delay τ (P1 index) increases with the queue size qs and the different packet sizes ps involved, as seen in Figures 8(b), 9(b), and 10(b). In all scenarios, when vt>Ca and qs increases, the queue fills and τ increases following (3.10) with ps=100 due the TCP flow-control mechanism based on packet losses. If τ is bigger than τms, the NCS becomes unstable, as expected.Remark 5.3.
The delay does not increase ifvt increases while vt<Ca and qs remains unchanged; transmission rate and delay are not closely related as commonly assumed. Relationship between delay and transmission rate depends on the available capacity and the type of background traffic in the network. In TCP shared scenario (e13, Figure 8), when qs remains unchanged and vt increases, τ decreases if vt<C.Remark 5.4.
The limit of the available network capacity can have two indicators: delay (P1) or packet losses (P2). P1 as capacity indicator is only effective in unshared networks or UDP shared networks. P2 capacity indicator is valid in all networks.


### 5.2. Stability Region Depending on Transmission Rate and Propagation Delay

Another interesting result is the stability region, meaning the results presented in [31] for fieldbuses, by fixing the queue size parameter in a very small value and changing the propagation delay of the trunk link. The stability region can be easily determined for simple scalar systems, but it may be analytically infeasible to derive the exact stability region for general systems [31]. To determine this region for NCS with network-induced delay, an analytical method using hybrid systems technique can be feasible, improving the Schurness property for the system matrices. This is more complex with NCSs in shared networks, with different traffic sources, due to the network-induced delay, autoinduced delay, and packet losses. Then, to determine the stability region a simulation methodology is needed, and the presented codesign test platform is suitable to do that.The monitored variable is the performance indexP0, and the stability criteria is very difficult to determine. In [25], the stability criteria is determined measuring the error in the second half interval of the simulation time and comparing it with the error in the first half interval. If the error decreases, then the system is considered stable. Equation (5.2) summarizes this approach(5.2)max⁡t∈[T/2,T]{|error(t)|}<max⁡t∈[0,T/2){|error(t)|}.When simulations are performed on shared networks, the criterion established in (5.2) is not valid if, in the second half of the simulation interval, the background traffic is higher than in the first half or the delay increases by changing the network path. Therefore this paper presents a simple approach, measuring the error AAE at the end of the simulation and determining if En=AAE/AAEmax exceeds a threshold T, (En<T). In fact, the loss of stability of a dynamic system is not gradual and quantitative but qualitative and abrupt. However, given the complexity of the simulated scenarios (including topology, protocols, and network load), an analytical approach of stability based on accurate models would be intractable. Moreover, the proposed experimental approach detects this character of abrupt change perfectly in the loss of stability if the proposed threshold T is large enough. Using the P0 index as En, and the value 1 for the threshold, the stability criteria used is (5.3), and results are presented in Figure 12 for scenarios e0, ev02, and e83(5.3)P0<1.Stability region for Scenarios e0, ev02, and e83.
(a)
scenario e0(b)
scenario ev02(c)
scenario e83


## 5.1. Performance IndexP0 Depending on Queue Size and Transmission Rate

P0, τ (=P1|(K1,K2)=(0,1)) and p (=P2|(K1,K2)=(0,1)) are obtained as functions depending on the transmission rate (vt) and the queue size (qs) of the intermediate routers (5.1) for different scenarios (ex). Measured delay τ is the average delay for success received packets along the simulation interval. The use of variable queue sizes can represent different transmission paths for the supermedia packets(5.1)P0,τ,p=f(vt,qs,ex).The results are graphically presented for scenarios e0, e5, e13, e83, and ev02 in Figures6, 7, 8, 9, and 10 respectively, where vt axis is in logarithmic scale for presentation purposes. Subgraphs (a) show the P0 index and related stability region, (b) the delay, and (c) the normalized loss rate. The stability region is determined by selecting vt and qs, where P0≤1, represented graphically by the projection of P0≤1 in the horizontal plane in subgraphs (a).Scenario e0. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario e5. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario e13. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario e83. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1) and τmax=1, and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Scenario ev02. (a)P0 index and stability region, (b) P1 index with (K1,K2)=(0,1), and (c) P2 index with (K1,K2)=(0,1).
(a)(b)(c)Figure11 represents performance indexes P0  (Figure 11(a)),  P1 (Figure 11(b)),  and P2  (Figure 11(c))  obtained by simulation, setting qs=60. Relationship between performance P0 and transmission rate, theoretically represented in Figure 3, is obtained in Figure 11(a) for all scenarios except e13, because in this scenario, with qs=60, the NCS is always unstable, due to a delay higher than τms as seen in Figure 11(b). In Figures 11(a) and 11(b), points Y (minimum transmission rate) and Z (maximum transmission rate) are highlighted. Scenario ev02 is not represented in Figure 11(b), because the average delay measured among the complete simulation interval is not representative in a varying scenario.Relationship between (a) performance, (b) delay, and (c) losses versus transmission rate for a gantry-crane NCS in different network scenarios.
(a)
PerformanceP0 for qs=60 (NCS granty-crane LQR)(b)
PerformanceP1 for qs=60 (NCS granty-crane LQR)(c)
PerformanceP2 for qs=60 (NCS granty-crane LQR)Analyzing all the graphs, some interesting remarks are obtained, and some conclusions are given in Section6.Remark 5.1.
The NCS stability region in all scenarios correlates with smallest delay (lower thanτms=0.07 s), as seen in Figures 6(a), 6(b), 7(a), 7(b), 8(a), 8(b), 9(a), 9(b), 10(a), and 10(b)) of Figures 6, 7, 8, 9, and 10, as theoretically expected.Remark 5.2.
In TCP/UDP shared scenarios (e13, e83, and ev02), whenvt remains constant, the delay τ (P1 index) increases with the queue size qs and the different packet sizes ps involved, as seen in Figures 8(b), 9(b), and 10(b). In all scenarios, when vt>Ca and qs increases, the queue fills and τ increases following (3.10) with ps=100 due the TCP flow-control mechanism based on packet losses. If τ is bigger than τms, the NCS becomes unstable, as expected.Remark 5.3.
The delay does not increase ifvt increases while vt<Ca and qs remains unchanged; transmission rate and delay are not closely related as commonly assumed. Relationship between delay and transmission rate depends on the available capacity and the type of background traffic in the network. In TCP shared scenario (e13, Figure 8), when qs remains unchanged and vt increases, τ decreases if vt<C.Remark 5.4.
The limit of the available network capacity can have two indicators: delay (P1) or packet losses (P2). P1 as capacity indicator is only effective in unshared networks or UDP shared networks. P2 capacity indicator is valid in all networks.


## 5.2. Stability Region Depending on Transmission Rate and Propagation Delay

Another interesting result is the stability region, meaning the results presented in [31] for fieldbuses, by fixing the queue size parameter in a very small value and changing the propagation delay of the trunk link. The stability region can be easily determined for simple scalar systems, but it may be analytically infeasible to derive the exact stability region for general systems [31]. To determine this region for NCS with network-induced delay, an analytical method using hybrid systems technique can be feasible, improving the Schurness property for the system matrices. This is more complex with NCSs in shared networks, with different traffic sources, due to the network-induced delay, autoinduced delay, and packet losses. Then, to determine the stability region a simulation methodology is needed, and the presented codesign test platform is suitable to do that.The monitored variable is the performance indexP0, and the stability criteria is very difficult to determine. In [25], the stability criteria is determined measuring the error in the second half interval of the simulation time and comparing it with the error in the first half interval. If the error decreases, then the system is considered stable. Equation (5.2) summarizes this approach(5.2)max⁡t∈[T/2,T]{|error(t)|}<max⁡t∈[0,T/2){|error(t)|}.When simulations are performed on shared networks, the criterion established in (5.2) is not valid if, in the second half of the simulation interval, the background traffic is higher than in the first half or the delay increases by changing the network path. Therefore this paper presents a simple approach, measuring the error AAE at the end of the simulation and determining if En=AAE/AAEmax exceeds a threshold T, (En<T). In fact, the loss of stability of a dynamic system is not gradual and quantitative but qualitative and abrupt. However, given the complexity of the simulated scenarios (including topology, protocols, and network load), an analytical approach of stability based on accurate models would be intractable. Moreover, the proposed experimental approach detects this character of abrupt change perfectly in the loss of stability if the proposed threshold T is large enough. Using the P0 index as En, and the value 1 for the threshold, the stability criteria used is (5.3), and results are presented in Figure 12 for scenarios e0, ev02, and e83(5.3)P0<1.Stability region for Scenarios e0, ev02, and e83.
(a)
scenario e0(b)
scenario ev02(c)
scenario e83


## 6. Internet-Based NCS Considerations

From (3.11) and Remark 5.3, UDP background traffic causes that point Z decreases, and TCP background traffic causes that point Y increases. Figure 13 represents this remark. This is because when UDP traffic increases, the point Z has a lower value due to the decrease in available capacity (Ca), and when TCP traffic increases, point Y has a higher value due to packet losses and to the queue occupation caused by the best-effort feature of TCP traffic.Figure 13
Relationship between performance and transmission rate with background traffic.Remark5.3 is full of importance due to the generally supposed assumption that increasing the transmission rate of the NCS causes delay increases and the NCS becomes unstable. Remark 5.3 is caused by the best-effort feature of TCP flows that makes that the queues are mainly occupied by TCP packets if other flows (such as NCS flows with low vt) are residual. When vt increases, TCP flows increase their packet losses, and, due to the flow-control feature, TCP decreases its transmission rate. This causes that the queue is increasingly occupied with NCS supermedia packets, and, while vt<C and ps|ncs<ps|tcp, the delay of NCS flows decreases. This remark has two important consequences.(i)
Highvt is more tolerant with delay variation as low vt, as seen in the stability region of Figures 8(a), 9(a), and 10(a), and in the stability regions of  Figure 12.(ii)
In Internet, with mostly TCP background traffic, it is more important to generate high transmission rates than low transmission rates. Thus, this solution is not compatible with pure deadband solutions [32] that try to minimize transmission speed.From Remark5.4, the transport protocol for NCS data should implement flow-control based on packet losses P2 to detect automatically the instantaneous available capacity of the network link. Some protocols such as BTP [33] have flow control based on delay (or RTT) monitoring but may not be useful in TCP shared networks. If multiple NCS share the network, some fairness and supermedia packet priority features should be mandatory to maintain global performance indexes.As global conclusion, in NCSs through Internet,vt design in the application layer is complex and unnecessary, and may be replaced by the design of an appropriate transport protocol, with flow control, best-effort and fairness features. Flow-control allows to detect the available link capacity, best-effort feature allows taking advantage of the network resources without increasing the network delay, and the fairness and priority feature allows to solve the well-known congestion problem in TCP/IP networks and share the network with other NCSs without compromising the stability of any particular NCS.Then, in Internet, the NCS sampling rate follows digitalization criteria, in place of transmission criteria, and transmission rate can be modeled by the transport protocol, according to network conditions.


## 7. Conclusions and Future Work

A test platform has been presented to study relationships between control and network, and to develop new codesign strategies for packet-based NCSs in shared networks. Shared network situations are normalized and have provided the basis for the realization of preliminary simulations to improve control/network codesign. Interesting remarks and considerations are obtained.The transmission rate and packet structure are the main control parameters that can influence the network variables such as delay and packet losses. So far, the transmission rate was selected to minimize the quantization error criteria, while looking for a low transmission rate to maintain stability based on codesign studies with no best-effort background traffic. In Internet, the most used background traffic is TCP, with best-effort feature, and conclusions of this work are that in this case, it is recommended to use high transmission rates but lower than available capacity of the link.Thus, transport protocol has a lot of importance in the stability of an Internet shared NCS, and codesign strategies are of interest to maintain performance indexes in an acceptable way. The transport protocol features are:(i)
packet-loss-based flow-control,(ii)
best effort and fairness to compete with TCP flows,(iii)
a data priority schema to compete with UDP or other supermedia flows.Transport protocols with these features can be tested in thetransport control sublayer of the presented test platform, and data priority can be developed in the network/control codesign sublayer.Future lines involve the design, development, and test of new transport schemes and codesign solutions to share the Internet or IP networks with certain guarantees of fairness and acceptable performance indexes for the control. TCP-friendly protocols for the transport scheme, and deadband solutions for the data priority problem, are a good start. Studies for packet structures are an interesting line of research, because they are involved in the packet size, packet efficiency and data priority of an NCS through Internet.



---

*Source: 239512-2011-09-28.xml*