These figures collect the set of Q4health project experiments. Next is included the description of the Testbed applied for the experiments implementation and some note about the initial steps and its evolution along the project.
There are several OpenvSwitch instances, each on devoted to one domain, this way the VELOX VPS engine can push QoS enforcement across these multiple domains.
In the first version of the architecture of the project the virtual switches were supposed to emulate the traffic and bandwidth characteristics of the two main networks that separate the EPC and the hospital: the distribution network of the mobile carrier and the network of the Internet Service Provider of the hospital.
During the evolution of the project, it was clear that the solution would not work as expected because of a limitation of the OpenvSwitch software. These SDN virtual switches work by receiving “orders” from their controller, in this case, the ONOS application, to route the traffic through different paths and with explicit latencies added. To provide this kind of functionality the OVS box receives the first packet of the stream and forwards it to the controller, where an application decides what is the operation to be performed to the rest of the stream. In theory, except for the first packet, the execution speed of the routing is very fast, comparable to what can be obtained in a physical switch, as all the processing is done in kernel space in the OVS box.
The plan was to inspect traffic inside the EPC network to expedite latency and enforce QoS from the BlueEye user to the hospital. This user traffic is encapsulated inside the actual packets that traverse the EPC components using the GPRS Tunnelling Protocol. Unfortunately, the stable version of OVS was not capable of extract that user traffic from the packets it can capture and would have to forward every one of then to the ONOS controller where a personalized application would be capable of doing that processing. This would impose an important penalty in latency and throughput to the entire setup, so that approach was abandoned. In the final implementation of the experiments, these VMs implementing OVS were still used but with direct forwarding of all packets, mainly to add additional latency to the user traffic so it behaves more like the packets arriving through a traditional mobile operator.