# Towards Intelligent, Programmable, and Open Railway Networks
## 6 An Experiment and Discussions  
To emulate the R1 policy management service, a numerical experiment is set up. In particular, the experiment is aimed at evaluating the latency in provisioning feedback policy data from different TSICUs to a TTICU.  
The RESTful approach that is adopted here imposes the well-known client-server pattern, and the setup for the numerical experiment is shown in Figure 13.  
The RESTful endpoint (EP) that is exposed by the policy management service is implemented using Vertx [37]. This toolkit has proven properties, such as multi-language support, flexibility etc., and aside from that, it includes an Apache Cassandra [38] client  
Figure 13: Setup of the numerical experiment—traffic from TSICUs to a TTICU.  
in order to facilitate the integration. Moreover, a core component within the toolkit is the event bus, which makes internal message exchange possible in a very resource-efficient and asynchronous way.  
The choice of Apache Cassandra as a NoSql distributed database backend is based on its maturity, high availability, and scalability. The service virtualization as whole is achieved by the use of Docker [39] container instances for the lightness and robustness that it shows.  
The RESTful service EP is used over HTTP/TCP/IPv6/GbE, where the interface and the IPv6 addresses are isolated in order to allow the experiment to be as unaffected by any other traffic as possible. The clients access the operations of the service in a multi-threaded way, and the clients' traffic is consisted of notification operations, i.e., POST requests, such as the request/response pattern shown in Figure 10.  
The notification operation shown in Figure 10 consists of a request, which includes the EP's URI, headers such as Host, Content-type, Accept, etc., plus an experimental header to keep track of the moment that the request is created (it is subsequently copied into the response as it is received by the EP) in a local location for the respective client nano-time scale, and the JSON description of the operation placed in the request body part.  
The traffic, that is generated for latency estimation purposes, is of a volume of twenty thousand operations of the notification type, i.e., request/response pairs.  
Thus, the recorded latency for each operation is stored in nanoseconds, where the latencies of the fifth and 15 th time frames of one thousand operation are shown in Figures 14 and 15, respectively.  
The sequence of latency values might be seen as a stochastic process; thus, a typical tool for depicting such a process is the creation of the respective probability density functions, as shown in Figure 16.  
Figure 14: Sequence of latency values measured within the fifth group of one thousand operations.  
Figure 15: Sequence of latency values measured within the 15 th group of one thousand operations.  
Despite of the observable similarity of the curves in their shapes, one must rather conclude that the process is quite far from the definition for a stationary one.  
The average latency values, which are shown in Table 1, are within the limit of 2-4 ms when averaged over the whole time frame, but it is easy to notice that the top 5% of latency values gave a higher average than that of the lower 95%; in some cases, the values were up to almost 10 times worse.