Comparison of Real-Time Communications Service KPI in Edge and Cloud Domains Through Multi-Domain Transport Networks

This paper presents the deployment of a Network Slice with a Real-Time Communications Network Service being deployed in two different sites (edge and cloud) of a network comparing the service performance when the user connects to the edge or to the cloud through an optical transport network. This idea has been validated by carrying out tests over a real network testbed.


I. INTRODUCTION
Virtualization is one of the pillars in which networking has evolved to properly work on energy efficiency or on time delays reduction in order to give better service quality to the final user. Having the power to deploy a virtual image of a network function when and where is necessary has given a massive network configuration variability to the network operators never seen before. This is possible because a service can be ready in some minutes or can be removed in few seconds once it is no longer necessary, allowing to use the resources first for one service and then for a new one. All this is done by using Network Function Virtualization (NFV) technologies managing Virtual Network Functions (VNFs) independently or chaining them through a Network Service (NS). One of the latest evolutions within the NFV field to improve the NSs management is the concept of Network Slicing. A Network Slice (NetSlice) is a group of one or more interconnected NSs which aim to give the final user a more complete functionality of the requested service.
Up until some years ago, the idea was to deploy the services inside "the cloud" allowing the user to upload all its information and use any service included there. The cloud is actually any data-center (DC) placed in the core of any network domain. Now this idea is changing due to the huge amount of data being transmitted around the world. This means that the small-resources DCs are being placed on the edge of the network and the low requirements requests are being processed in there. By deploying services closer to the user, the data process is done right on the edge reducing time delays and the DCs in the core are much less congested and focused towards those high requirements services [1].
Following the work done in [2] and [3], this paper describes the deployment of a NetSlice composed by a Real-Time Communications (RTC) NS in both edge and cloud of a network interconnected through an optical transport network and, finally, compares the performance of the RTC NS in the two different sites. This paper is divided in three sections. The first section presents the NFV elements and the environment architecture used to carry out the experimental tests, a second section describes the obtained results and the third section contains the conclusions.

II. EDGE/CLOUD NFV NETWORK SLICE DEPLOYMENT
This section introduces some concepts regarding the NFV and Network Slicing fields together with a basic structure of each used element. Moreover, it presents the architecture and its structure as well as how the deployments were done in each site.

A. Real-Time Communications Network Service
The most basic element in NFV is a Virtual Network Function (VNF) [4] consisting on a descriptor to create a Virtual Machine (VM) with specific characteristics in order to offer a certain network functionality (i.e. proxy). Having this in mind, an NS is a set of interconnected VNFs (if there is more than one) to properly have a service ready to be used. The life-cycle management of both elements is carried out by a NFV orchestrator (NFV-O).
The NS selected is a Real-Time Communications (RTC) application able to create voice calls or video-conferences sessions with two or more users. Thanks to its internal architecture ( Fig. 1), it allowed to create a complex NS composed by five Virtual Network Functions (VNFs): Furthermore, the NS needs two more components which allow the configuration of the VNFs and the NS:

B. Real-Time Communications Network Slice
Network Slicing follows the same idea NSs do with VNFs. By linking multiple NSs, the user should have a better user experience and the network owner should be able to manage its network resources more efficiently. The elements that a Netslice Manager (Netslicer) must deal with are two: a Network Slice Template (NST) and a Network Slice Instance (NSI). The first one describes a set of NSs to be deployed and how are they related to each other as well as other possible options. The second element is the record of each instantiation based on the previous NST with the VMs and virtual networks information created in the DC where the NSI is deployed.
Using the Netslicer within the selected NFV-O allowed to specify two aspects: The architecture used has a transport network with two parallel paths: one is packet-based while the other is an optical network. This second path is composed by four electrical-optical switches running OpenVswitch (OVS) and the four optical switches are managed with a private optical controller. • Cloud Network: the deepest part of any network where DCs with a massive amount of resources are available to process those service requests with high requirements. If so, congestion in the transport network is reduced together with delays affecting the user experience. As the data plane, the control plane has 3 levels: •   III. EXPERIMENTAL EVALUATION This section presents how the deployments were done, which parameters were used and how were they acquired while testing to be properly evaluated and presented in the last subsection.

A. Edge vs. Core Use Case Deployments
When comparing the performance of a service deployment in two different sites of a network, there are mainly two time values to consider: the deployment time necessary to have the service ready and the time delays to transmit data between transmitter and receiver.
Regarding the first time and with all the previous elements presented, two different deployments were done. The first one selecting the creation of the NetSlice in the VIM placed on the edge (left side in Fig. 2), while the second one placed in the cloud VIM (right side in Fig. 2). In both cases the deployment time was similar as it mainly depends on how big (MB or GB) the software to install into the new VM is. For this reason, this value was not taken into consideration for the comparison.
The second time depends mainly on how much availability has the network. As different co-existing flows are being processed by network elements, the delay of each individual service data flow is affected and this is the reason why MEC was designed; to reduce as much as possible the traffic within the transport and cloud networks parts.

B. Tests Development
To evaluate the performance in both sites, the RTT and Jitter parameters were used in order to know how long a packet needs to reach the receiver (Jitter) and to come back (RTT).
To properly acquire both parameters, different calls of 10 minutes each were done using the NS deployed in both VIMs. As previously described in subsection II-A, one of the VNFs composing the NS contains a WebRTC [10] which collects data samples in real-time. Then, the samples were processed to create the results presented in Fig. 3 and Fig. 4.
One last aspect to take into consideration before the results are presented is the fact that all the samples were taken in a scenario in which the flows had the best conditions without the concurrence of other flows.

C. Results
An RTC service means two data flows: audio and video. The following subsections present the Jitter results for the audio and the RTT results for the video flow. In order not to repeat descriptions, the parameter not presented has a similar behaviour.
1) Audio: Fig. 3 contains the temporal evolution of the Jitter. Comparing the mean values of each case, it is possible to validate the difference between them and confirm that the value on the edge VIM (0.0015 ms) is lower than the mean value in the core VIM (0.041 ms). Regarding the maximum values, on the edge case, there's a peak value of over 0.004 ms and on the core case, its peak value is over 0.11 ms.
2) Video: Similar to the figure related to the audio section, Fig. 4 presents how the RTT evolves in time for each data packet with video information. Overall, the RTT mean value for the edge case is 0.39 ms, whereas for the core case is 0.42 ms. Here again, the theory in which the delays from the edge should be lower than those in the core, is also confirmed.
In fact here what is important to remark is that the length of the optical fiber used while the experiments were carried out, was of 30Km which is not a considerable distance. But what matters is that just by having that distance, there is an increment of 7,3% of the RTT. This means that with transport networks of higher distances, the RTT should increase over 10% easily, and this is a considerable delay to take into account for low-delay services like the RTC service presented.

IV. CONCLUSIONS
This paper proved that by placing the services deployments closer to the user, data transmissions are more stable in reception and the transmitter must wait less time in order to ensure the transmitted data has been well-received.