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.
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 Section 2, 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 of supermedia 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 some NCS 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 Figure 1, 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.
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 the supermedia packets are of fixed size 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 , adding subscripts to differentiate one index from the others. and QoC have an opposite relationship: the higher is , 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
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 error of an NCS as the result of dividing the instantaneous error by the maximum permissible error 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
To make the error independent of time, instead of the mainly used integral absolute error indicator (3.3), we propose the use of average absolute error (3.4), where is the measuring interval
IAE should be measured in a minimal interval of , where 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 indexes 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: for the error component, and for the network component. So, in a network with NCSs, we define four different performance indexes(i) (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. is used to determine the stability region in Section 5.2. (ii) (3.6): this performance index computes the error and normalized delay () respect to the maximum permissible delay to maintain NCS stability () in both directions. Then, , (iii) (3.7): 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 . If and the arrival rate (or success rate) in the destination are known, , (iv): finally, is used to determine the degree of involvement of the transmission rate , normalized respect to the sampling rate (, where is the sampling rate). This index allows to punish excessive transmission rate to the network. In this work, using Assumption 3, then and 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. Figure 3 [5] represents the influence of different types of control on their performance, as a function of the sampling/transmission rate. Performance index is usually .
In Figure 3, the performance degradation with high transmission rate is highlighted by point , caused mainly by increasing packet losses and autoinduced network delays. Point 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 and , resp.) for unshared networks is proposed.
The lower limit for point is the point , given by (3.8), where is the controller bandwidth in closed loop operation [28].
Point has an upper limit given by (3.9), where is the point to point link capacity for link and is the set of point to point links traversed by the NCS data flow. is the available capacity of the network link
Points and vary depending on the available capacity of the network () and the background traffic features.
3.3. Queue Size
Queue size () has direct relationship with network delay () as seen in [(10) (presented in [25])] for Drop Tail queues, where is a link index, is the amount of links (or queues), is the propagation delay for link , is the packet size in bytes (as in Assumption 2), is the queue size for link (in packets), and is the link capacity in bits/sec
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 the 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 call background 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 ) of the network link(i)UDP shared: shared network with background traffic without flow control (mainly UDP protocol). If is the host to host link capacity and is the capacity used by the UDP flows, available capacity is (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, , 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 (), as seen in (3.12). In (3.12), is the probability of packet loss and is the retransmission time. The packet size of a TCP flow is usually higher than the supermedia packet size and is represented by (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 Figure 2 and the complete test platform is available to download in [30].
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, where NCS 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 the NCS 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 the ncsd_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 is the reference signal
with and .
Figure 4 shows the simulated gantry-crane teleoperated system.
4.2. Transport Layer
This layer involves a control/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 the backward 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 Assumption 3. Then, the TCF and encapsulation/decapsulation functions have no effect on the results.
4.3. Network Topology
Figure 5 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 () in the queues has the same value to meet Assumption 2.
The simulation scenarios attempt to reproduce different network congestion situations on the basis of the classification made in Section 3.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 capacity 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 of 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 (). (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 of 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 Table 1.
Two main simulations are designed to determine the response of an NCS in an IP based network for different shared scenarios as proposed in Section 3.4. First, the transmission rate limits to maintain performance index 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 Index Depending on Queue Size and Transmission Rate
, () and () are obtained as functions depending on the transmission rate () and the queue size () of the intermediate routers (5.1) for different scenarios (). 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
The results are graphically presented for scenarios e0, e5, e13, e83, and ev02 in Figures 6, 7, 8, 9, and 10 respectively, where axis is in logarithmic scale for presentation purposes. Subgraphs (a) show the index and related stability region, (b) the delay, and (c) the normalized loss rate. The stability region is determined by selecting and , where , represented graphically by the projection of in the horizontal plane in subgraphs (a).
(a)
(b)
(c)
(a)
(b)
(c)
(a)
(b)
(c)
(a)
(b)
(c)
(a)
(b)
(c)
Figure 11 represents performance indexes (Figure 11(a)), (Figure 11(b)), and (Figure 11(c)) obtained by simulation, setting . Relationship between performance and transmission rate, theoretically represented in Figure 3, is obtained in Figure 11(a) for all scenarios except e13, because in this scenario, with , the NCS is always unstable, due to a delay higher than as seen in Figure 11(b). In Figures 11(a) and 11(b), points (minimum transmission rate) and (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.
| (a) Performance for (NCS granty-crane LQR) |
| (b) Performance for (NCS granty-crane LQR) |
| (c) Performance for (NCS granty-crane LQR) |
Analyzing all the graphs, some interesting remarks are obtained, and some conclusions are given in Section 6.
Remark 5.1. The NCS stability region in all scenarios correlates with smallest delay (lower than 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), when remains constant, the delay ( index) increases with the queue size and the different packet sizes involved, as seen in Figures 8(b), 9(b), and 10(b). In all scenarios, when and increases, the queue fills and increases following (3.10) with due the TCP flow-control mechanism based on packet losses. If is bigger than , the NCS becomes unstable, as expected.
Remark 5.3. The delay does not increase if increases while and 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 remains unchanged and increases, decreases if .
Remark 5.4. The limit of the available network capacity can have two indicators: delay () or packet losses (). as capacity indicator is only effective in unshared networks or UDP shared networks. 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 index , 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
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 at the end of the simulation and determining if exceeds a threshold , (). 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 is large enough. Using the index as , 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
(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 decreases, and TCP background traffic causes that point increases. Figure 13 represents this remark. This is because when UDP traffic increases, the point has a lower value due to the decrease in available capacity (), and when TCP traffic increases, point has a higher value due to packet losses and to the queue occupation caused by the best-effort feature of TCP traffic.
Remark 5.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 ) are residual. When 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 and , the delay of NCS flows decreases. This remark has two important consequences.(i)High is more tolerant with delay variation as low , 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 Remark 5.4, the transport protocol for NCS data should implement flow-control based on packet losses 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, 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 the transport 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.
Acknowledgments
This work has been partially supported by Spanish Science and Technology Ministry in the Projects nos. CICYT DPI2010-20466-C02-01, and DPI2008-06738-C02-03 and by the Galician Industry and Research Ministry at the same country, under the Project no. 08DPI-011303PR.