Wireless Personal Communications

, Volume 100, Issue 1, pp 25–46 | Cite as

Deviceless Communications: Cloud-Based Communications for Heterogeneous Networks

  • Flávio Meneses
  • Carlos Guimarães
  • Tiago Magalhães
  • Diogo Gomes
  • Daniel Corujo
  • Rui L. Aguiar


Mobile networks today see increasingly large numbers of connected user equipments (UE), allowing users to go beyond voice calling and tap into rich on-line services. Parallel to this evolution, other devices, such as TV’s, home automation or even Internet of Things controllers, have become integrated with connectivity capabilities, allowing them to not only be locally connected, but also be reachable from the Internet. In this paper we propose a deviceless communication approach, where data and media flows reaching a user can be individually shifted into nearby devices. To support this, we present a framework that explores and enhances Software Defined Network and Network Function Virtualisation concepts, allowing the opportunistic utilization of nearby devices as the user moves, while still being perceived as a single end-point towards external entities. An experimental validation scenario is presented, showcasing a video stream being delivered to a nearby large TV screen, allowing the user to watch the video while a voice call is routed to a nearby phone. Results showcase the feasibility of the proposed framework and how virtualisation of both the UE and the points of attachment contribute to reduce the impact of flow management in the physical devices.


Deviceless communication Mobile offloading OpenFlow Software Defined Networks (SDN) Network Functions Virtualisation (NFV) 

1 Introduction

Mobile user equipments (UE), such as smartphones, have been playing a key role in propelling the evolution and success of telecommunication networks.1 Moreover, as their capabilities and features evolve, service providers and network operators are led to provide on-line access to rich services and media, requiring the network to support large quantities of high bit-rate traffic on the move, while realizing complex optimization procedures in order to ensure good quality of experience to users. These aspects have motivated the deployment of new network tools, such as Software Defined Networking (SDN) and Network Function Virtualization (NFV) [2], allowing networks to more easily adapt to changing utilization scenarios. This is especially important considering that the upcoming 5G architecture aims to explore the same base infrastructure for optimal data transfers involving different utilization requirements, ranging from intermittent low bit rate Internet of Things (IoT) communications, to Ultra-HD video streaming and low-latency on-line gaming [3]. On one hand, SDN enables the separation of the control plane from the data plane, creating a more flexible switching architecture that abstracts control into software-based mechanisms. On the other hand, NFV structurally changes the way the telecommunication infrastructure is deployed, by decoupling network and service functions from the hardware and deploying them in cloud-based data-centers. In this way, a network function can be moved to, or instantiated in, various locations in the network as required, without the need for installing new equipment [2].

Complementing this evolution, other devices (e.g., smart TV’s, home automation, IoT microcontrollers) have started to have connectivity options integrated into them, allowing them to tap into on-line services as well, such as video-streaming services, or accessing applications running in the cloud (i.e., such as many on-line home automation platforms do to control sensors and actuators at home). Moreover, smartphones already incorporate a whole set of technologies (e.g., Near Field Communication, Bluetooth), enabling them to communicate with sensors in their surroundings at a low cost [4]. This highly connected environment allows us to change our perception of optimal user experience, by considering that certain aspects of service usage in our own device can be replaced by features physically existing in surrounding devices (i.e., watching a HD video in a nearby large size TV, instead of the smartphone screen).

In this paper we present the concept of deviceless communication, proposing a framework which, by progressing evolved SDN and NFV concepts [5], is able to segment and switch particular data flows which are now traditionally associated with our smartphone, into other surrounding devices with better features, or even other convenient smartphone nearby. To support this concept, a virtual representation of the UE (dubbed vUE) is instantiated in a cloud environment (e.g., operator data-center), acting as a dynamic representation of the device (and, given the increasingly pervasive nature of the smartphone, eventually acting as a representation of the user itself) towards external entities, and as a mobile anchor for flow mobility management processes. Here, mobility is handled using OpenFlow, where the SDN controller is empowered with handover decision capabilities. When an opportunity arises (indicated by an infrastructure relaying information about discovered devices, links and their characteristics) the SDN controller is able to shift specific flows towards relevant devices. This is further supported by also virtualising the points of attachment (PoA), such as base stations (BS) or access points (AP), allowing the flow shifting procedures to be fully handled in the cloud, thus reducing potential impact in the physical entities: this allows greater network granularity, as it moves all the mobility management computation to the cloud, with the physical network benefiting from the reduction of control signalling, as well as the added cloud’s power computation.

On a general sense, the infrastructure relaying information could be any location aware service providing at such time context information associated to the user. At this stage however, we are assuming that the user retains his UE with himself, acting as the contextual source of information via OpenFlow, and focusing more on exploring the environment capabilities for the communication. The UE becomes fundamentally a localized probing device. The security and privacy challenges of more general contextual infrastructures merit a separate discussion by itself and will be part of our future work.

We experimentally evaluate a scenario where the video data flow is dynamically shifted from a mobile phone into a nearby HD TV screen, while maintaining other flows (such as a voice call) in the device. In addition, we integrate virtualisation-based flow mobility management procedures, which allow the devices involved in the different flows to be perceived as a single device to external services. Results showcased the feasibility of the proposed framework, reducing the transport cost of such flows over wireless networks, and reducing energy usage on the device.

The remainder of this paper is organized as follows: Sect. 2 presents the related works of SDN and NFV over wireless and mobile environments. The framework is introduced and discussed in Sect. 3. The signalling is discussed in Sect. 4, with Sect. 5 presenting the use case and implementation options. The evaluation of the framework is provided in Sect. 6. Finally, the paper concludes in Sect. 7.

2 Related Work

In our framework we propose to combine both SDN and NFV mechanisms, in order to enable seamless flow mobility in heterogeneous networks abstracting the notion of “user equipment”. Moreover, following our self-imposed limitations on the location context infrastructure, we exploit the smartphone’s sensor capabilities for discovery of neighbour devices with networking abilities to redirect the relevant traffic on an opportunistic way. Thus, this section discusses our approach along three technological approaches: (a) the related work in sensor information collection by smartphones, and its usage in network procedures; (b) mobility management initiatives for 5G networks; and (c) framework efforts for virtualising network entities in the cloud.

2.1 Participatory Network

Participatory networking (or sensing) allows users to observe their surrounding conditions (e.g., the environment, weather, traffic congestion, etc.) with their smartphones by collecting sensor information. Works such as sBike [6], have been exploring this by using a smartphone attached to a bicycle to analyse road conditions and driving state. In [7] a smartphone’s microphone was used to create a noise map by measuring ambient sounds. Applying SDN to participatory networking, in [8], an API is implemented by an OpenFlow controller to delegate read and write authority from the network’s administrators to end users, or applications and devices acting on their behalf.

In our proposal we go beyond mobile and Wi-Fi environment analysis (i.e., link strength for neighbour base stations and access points) and use the smartphones’ sensor capabilities to discover nearby devices (i.e., TVs via bluetooth) and inform the network when a flow mobility for a nearby device with better characteristics (i.e., larger screen) is possible. This results in an enhancement of the flow quality while reducing the transport cost over the mobile network and the device energy.

2.2 SDN-based Mobility and Traffic Redirecting Approaches

Originally SDN was designed for wired technologies, however the flexibility and ability provided by OpenFlow for network (re)configuration on the fly paved the way for its applicability in wireless environments. As such, while SDN has grown to encompass many protocols and software elements, OpenFlow [9] has been identified as the de-facto open network foundation (ONF) SDN standard. OpenFlow defines the communication protocol in a SDN environment, which enables the SDN controller to interact with the forwarding devices (i.e., OpenFlow switches) that compose the data plane. Service and cloud providers have been adopting SDN and OpenFlow into their networks, looking for advantages such as service agility and the capability to add features faster [10]. While in [11] OpenFlow was used to allow a regular wireless router to act as an OpenFlow switch, in OpenRoads [12] a remotely controlled flow-table, via the OpenFlow protocol, was deployed in the AP. In [13], the OpenFlow controller was able to manage the handover procedures of mobile devices, enhancing OpenFlow with a new set of messages for acquisition of information regarding the wireless link. Also, new SDN-based mobility management schemes have been proposed. In [14] a scheme to reduce the latency in handover procedures by pro-actively preparing the network was proposed. In [15, 16], an SDN-based distributed mobility management (DMM) was proposed, resulting in a scalability improvement when compared with the legacy DMM.

In [17] the authors propose to extend SDN programmability up to the UE, identifying use cases where a wireless SDN approach could bring additional benefits. In this line, approaches such as [18, 19], explore the use of SDN within the UE for bandwidth estimation and for TDMA optimizations in 802.11, respectively. Finally, in [20, 21], OpenFlow was extended all the way to the UE and experimentally evaluated in heterogeneous wireless environments for flow-based mobility management proposes. More recently, Makris et al. [22] explores intra-domain scenarios and the impact of multi-homing protocols, not only modifying the UE to operate with SDN mechanisms, but also the end-point on the receiver side. In fact, such framework and mechanisms are exploited to offload the traffic from mobile network to Wi-Fi. Also, initiatives such as [23] exploit the possibility of device-to-device communication for traffic offloading. However, such approach is suitable for content sharing, being inadequate for personal traffic. Contrary to this, our proposal does not seek content sharing, but the flow mobility between potential representations of the UE (e.g., smart TV’s). As such, our framework goes beyond offloading the traffic in a multi-radio access technology UE, and allows the network’s acquisition of the UE’s context and surroundings for further migration to neighbouring devices with networking capabilities.

2.3 Network Cloudification

In the mobile packet core network, NFV has emerged as a viable approach to increase network flexibility. However, its deployment in the radio access network (RAN) still has some synergies with the availability of high performance data centers [24]. In this context, a Cloud RAN architecture will exploit a combination of virtualisation, centralization and coordination techniques within the network [24].

Architectures such as CellSDN [25], SoftRAN [26] and Cloud-RAN [27], propose a SDN-based centralized control plane for RANs to abstract BSs from a local area (SD-RAN). Also, the SD-RANs should be connected to virtual BSs, providing a centralized control solution. More recently, SoftAir [28] introduced a new software-defined architecture for wireless systems, where cloudification and network virtualisation are exploit for scalability and flexibility. Also, the authors advocate that three management tools should be developed: (a) mobility-aware control traffic balancing; (b) resource-efficient network; and (c) distributed and collaborative traffic classification. Notwithstanding, the previous works do not implement the suggested architectures, lacking implementation and evaluation results.

Contrarily, Odin [29] and CloudMAC [30] virtualise APs in data centers for implementation of high level services, such as authentication, authorization and accounting (AAA), and management of the Wi-Fi control and management frames, respectively. However, both architectures focus solely in the IEEE 802.11 standards, neglecting the inter-technology handovers. Finally, in [5] the authors not only virtualise the AP, but actually virtualise components of the mobile node as well, envisioning a technology-agnostic mobility management for heterogeneous networks.

Our proposal exploits the framework proposed in [5] not only to instantiate, on-demand, a virtual representation of the UE in the cloud, but actually to acquire its context via network triggers (from the PoAs) to signalize attachments, detachments and link strengths, and via UE triggers to inform the network about neighbouring network devices (such as, smart TVs). Moreover, our proposal does not focus in mobility mechanisms, but how key 5G enablers (such as, SDN, NFV and network cloudification) allow the exploitation of new scenarios where the communication is detached from physical devices by virtualising the UE in the cloud, while instantiating small instances of its context in user’s neighbouring network devices (e.g., smart TV’s). Such ability results in a mechanism to provide optimized mobility in participatory networking scenarios.

3 Framework Overview

Figure 1 presents our conceptual context and location infrastructure. In this context, the framework gathers information of the user’s surrounding environment, and dynamically updates the vUE, allowing the user to communicate in scenarios where the user has only a localized probing device, by instantiating the user’s context in nearby devices (e.g., smart TVs and smartphones). As stated, given the privacy aspects of a generic location and context architecture, we will rely on the smartphone as a sensor entity, and for simplification we will discuss our framework with a video re-routing context. Next, we discuss the description of the proposed framework.
Fig. 1

Framework overview

3.1 Framework Description

The devices have a virtual representation on the cloud (vUE). A context retrieval infrastructure collects data from sensors and devices, about all relevant context for the user and its nearby devices. This is passed to a Context and Location Awareness Engine that will control the flows for the vUE, and will perform a request to a vUE updater if required. The vUE updater will dynamically profile the vUE as the user context changes.

For a proof-of-concept prototype, the framework was simplified and a smartphone was used as UE and localized identifier, due to the complex privacy aspects of the above infrastructure. Figure 2 presents the simplified framework for the reference scenario, where a video is re-routed from the UE to a nearby TV (equipped with a set-top-box). Exploring the capabilities of such device, the Context Retrieval was deployed in the smartphone. In this way, nearby devices choose which information to share, and the user fetch permitted devices. As such the UE, can be seen as a localized probing devices that listens the user’s surrounding environment and retrieves the relevant information (such as, nearby devices and re-routing opportunities) directly to the vUE.
Fig. 2

Simplified reference scenario

For mobility purposes, in our proposal, the network controller (i.e., SDN controller) is able to manage flow mobility in the network, redirecting flows (via flow-based rules), and instantiating new network entities (such as, PoAs and UEs) in the cloud. As such, and framing a video re-routing context, our proposal improves video QoE by implementing a technology-agnostic traffic flow mobility mechanism by bringing a virtual representation of both the UE and PoAs to the cloud. In this way, flow mobility management mechanisms are migrated to the data-center, benefiting the enhanced computational power, thus allowing the implementation of more complex management decisions, when the opportunity to redirect flows towards other devices arises. The controller can also be a distributed entity and implemented in a cloud environment, in order for it to be more flexible and scalable. The network entities involved are discussed below.

3.1.1 User Equipment and Its Virtualisation

Nowadays smartphones’ capabilities (represented in our proposal as the UE) allow us to explore scenarios such as accessing a video from Youtube2 or Netflix,3 while jumping from one wireless technology to another (e.g., from LTE to Wi-Fi, or vice-versa). Moreover, with the increase of virtualization techniques, it becomes possible to explore scenarios where not only the radio access network (RAN) equipment (such as, Base Stations) is virtualised, but also the UE [5]. This enables the user to keep the context of the UE in the cloud for further usage in different equipment with networking capabilities (such as, smart TVs). As such, the user is no longer attached to an unique UE, being able to explore communication scenarios where the user is not “carrying the device”. To this end, while the UE represents a current dual-interfaced (i.e., mobile and Wi-Fi) smartphone, the vUE is created on-demand by the network controller and consists on a dynamic representation of the UE in the cloud. Also, the vUE acts not only as a proxy for the Internet access, but also as an anchor for flow mobility procedures. As such, cross-technology handovers become transparent for both end-nodes, since both continue to send/receive the traffic to/from the same entity (i.e., vUE) regardless of the physical device that eventually terminates the flow.

3.1.2 PoA and Its Virtualisation

Since our framework aims to be agnostic of the access technology, we represent the BSs and APs generically as PoAs. In this line, the vPoA represents the virtualisation of the management and control services of the PoA (such as, attachment, association, dynamic host configuration protocol (DHCP), etc.) in the cloud. Being connected via a Layer 3 (L3) tunnel, as the vPoA is responsible for the management and control traffic of the PoA, the PoA itself becomes a simpler forwarding device with wireless capabilities. This hides the challenges of multiple types of access (e.g., Wi-Fi, LTE, cable, etc.) from the on-going communication.

3.1.3 Network Controller

The network controller (i.e., SDN controller) manages all network equipment in regards to flow mobility management. As such, it communicates with all the virtualised equipment in the cloud via the OpenFlow protocol, (re)configuring the network via OpenFlow flow-based rules. Also, it has the capability of allocating resources in the cloud for instantiation of recently attached devices. For handover procedures, it maps the UE with the correspondent vUE, leveraging the handover of the flow to the selected vUE.

3.1.4 Headend, Set-Top-Box and Correspondent Node

In our reference example, we use the video headend as a video server for streaming and transcoding a video. The set-top-box is connected to a TV and receives a small context of the UE therein, while the correspondent node (CN) performs a voice call with the UE. Moreover, the set-top-box has bluetooth capabilities, allowing nearby devices locate it.

4 Signalling

By virtualising the user’s context in the cloud, our framework allows the redirection of specific flows to user’s nearby devices. In our proof-of-concept prototype, we use the UE to retrieve the user’s location and surroundings context, and sync it with its vUE. Doing this, the network controller gains a better perspective of the current UE connection, gathering information such as the current link conditions, neighbouring cell or devices. This enables the network controller to optimize network utilization and experienced QoE, redirecting flows between the vUE and the current connection of the user (it can be the UE or neighbouring devices with networking capabilities). In fact, the vUE is a dynamic entity, that has changing characteristics in function of the devices surrounding the user.

Despite that discovery mechanisms for selecting the best UE or flow for handover are not in the scope of this work, the instantiation of vUEs with UEs’ context allows our framework to be flexible enough for the controller to have a broader view of the network, enabling the future incorporation of new mechanisms for this end. In Fig. 3 the signalling related with the vUE instantiation, its context update and mobility flow procedure is depicted.
Fig. 3

Signalling for vUE creation and context update

4.1 Control and Management Communication of the Framework

When a new UE attaches to the network via a wireless technology (i.e., BS or AP), the vPoA informs the network controller (i.e., SDN controller) of a new attachment via an OpenFlow message. By receiving this message, the SDN controller updates the context of the respective vUE (or instantiates a new vUE, if it has not been instantiated yet) in the cloud. Figure 3 presents this process in three key procedures:
  1. (a)

    UE-attachment it is the attachment between the UE and the network (1 and 9). This attachment is performed in cloud and generates an event in the vPoA, triggering an OpenFlow message towards the controller (2 and 10) with the UE’s identification (i.e., Media Access Control (MAC) address).

  2. (b)

    vUE instantiation Receiving the vPoA’s message, an event is generated in the controller, which verifies the existence of a vUE or if a new one is required (3). After the vUE’s instantiation, the vUE establishes an OpenFlow connection with the SDN controller, and informs the later, that it is ready to be added to the network (4). Thus, the controller updates the flow tables on the vPoA (5), in order to redirect the UE’s traffic for the respective vUE.

  3. (c)

    vUE update If by receiving the vPoA’s message (10), the generated event in the controller results in an already existence of a vUE, the controller updates the context of both vUE (11) and vPoA (12). Moreover, the vPoA monitors the link conditions of the UE via link layer messages. Changes are informed to the SDN controller via OpenFlow messages (13), which in turn updates the vUE’s context (14). Specific UE-initiated events can also be communicated to the SDN controller, with the UE sending a L3 packet towards vPoA (15a), which in turn pushes an OpenFlow header and sends it to the SDN controller (15b).


4.2 Flow Mobility Procedure

When an UE attaches to the network, its Internet access (from Wi-Fi and/or mobile network) passes through its vUE. As such, the vUE can be seen as a proxy for the communication of the UE, anchoring it to the network. In this way, the CN (and/or Headend) will see the traffic from both interfaces as being from the same UE, enabling a flow mobility transparent to the CN, in both downstream and upstream.

In case of a redirecting opportunity from a network entity, depending on the requester (e.g., vPoA or UE) and the traffic direction (i.e., downstream or upstream) different procedures are taken. An example of a possible handover procedure is illustrated in Fig. 3. The trigger is sent to the controller (15) which verifies the network state, and after deciding if the UE’s flow should be redirected, updates the flow-table of the respective vUE via OpenFlow (16). Despite being UE-initiated (15a), in our scenario, the trigger is converted into an OpenFlow message only in the vPoA (15b), which in turn sends the trigger to the controller.

The next section presents this flow mobility management process, where the UE notifies the network about the presence of a nearby device. In order to focus on the flow mobility aspects, in this paper our procedures are described considering that the UE is already attached to the network via Wi-Fi and the vUE is instantiated with its context updated.

5 Framework Deployment

For proof-of-concept of our model, a scenario where an ongoing video streaming is redirected from the UE to a nearby TV (equipped with a set-top-box) was deployed using the framework presented in Fig. 2. The scenario mimics a user in his home network accessing a video on his smartphone (1, 2 and 3) when a voice call is received (4). In this context, our framework enables the user to seamlessly keep watching the video on an alternative nearby TV screen (1, 2 and 5) while answering the call.

5.1 Use Case Description

When in its home network, the UE attaches to the Wi-Fi network and reads the bluetooth beacons sent from the set-top-box, estimating the distance of the nearest TV. Also, the controller updates the necessary UE’s context in the cloud (i.e., vUE). For simplification, in such scenario we assume that vPoAs are already instantiated in the cloud and connected to their physical counterparts (i.e., PoAs). Also, the implementation done was simplified, and only reached the virtualisation of the AP and UE, maintaining the cellular connection in its default configuration. Figure 4 depicts the signalling regarding to this scenario, while Fig. 5 illustrates the messages format for the flow mobility signalling.
Fig. 4

Signalling for the simplified reference scenario

Fig. 5

Packet formation for context update and flow mobility

The scenario starts with the user visualizing a video stream in its UE via Wi-Fi network (Fig. 4: 1–2), when a voice call is received. Answering the voice call, the user triggers an event (Fig. 4: 3), originating a handover request towards the vUE. Upon reception of the handover request, vUE updates the video stream destination, offloading it to the nearest TV (Fig. 4: 6). Ending the mobile voice call, another trigger is generated (Fig. 4: 7) informing the vUE, which in turn redirects the video stream back to the UE (Fig. 4: 10). In this way, the user is able to keep visualizing the video on another device, despite answering the call on the mobile phone.

5.2 User Equipment (UE)

The UE represents a current dual-interfaced smartphone with independent Wi-Fi and cellular interfaces. Note that many of these are specific of the proof-of-concept purpose of our testbed, and commercial code would be more efficient.

To enable the smartphone to trigger an offloading event upon reception of a voice call, an Android application was developed and installed therein. The purpose of this application is to signal the network when the user is accessing an online video and simultaneously answering a call. As such, the UE is aware of nearby TVs, by constantly reading bluetooth signals from beacon devices4 attached to them. When the UE is in a call and watching a video, if it detects a TV, it informs the network about the handover opportunity. Figure 6 illustrates the application architecture. Note that for a generic implementation of a deviceless communication environment, the UE would become a powerful device discovery probe.
Fig. 6

Mobile application architecture

When the application is running, a broadcast receiver is created to receive events: (a) from the Android system when a voice call is answered or terminated (Fig. 6: 1); and (b) from the Beacon Service (Fig. 6: 3). The Beacon Service is launched by the application main activity (named as NotifyOnCall) (Fig. 6: 2) and it relies on the Android Beacon Library5 to read the bluetooth signals that are sent by the Beacons in range. The distance estimation between the UE and the TV is based on the received signal strength of each beacon device. When the broadcast receiver is signaled with an update, it refreshes its internal information and if the application is not running on background in that time, it updates the main activity (Fig. 6: 4). Of course, more powerful context aware mechanisms could be used.

When the broadcast receiver detects that the user answered an incoming call and if there is, at least, one TV in range, a trigger is sent to the network towards the vUE, identifying the nearest TV (Fig. 6: 5). When the mobile voice call is ended, the application triggers the vUE to retrieve the video back to the UE.

Finally, while this application is running in the background, the user is visualizing the online video stream in the VLC application. Security (and authentication) aspects of these procedures (such as policy-based network decisions about which video flows can be offloaded to external devices or not) are outside the scope of this work, as previously discussed.

5.3 Virtual User Equipment (vUE)

By virtualising the UE, we bring the UE’s context to the cloud, enabling a technology-agnostic mobility management. This simplifies the intelligence required for improving mobile video QoE in environments where multiple technologies are usually available. This approach differentiates clearly L2 issues from complex L3 approaches. To sync the UE context with its vUE, we used the OpenFlow protocol. In this regard, the syncing is done via specific OpenFlow Packet_in messages sent by the vPoA towards vUE, with information regarded to link events. The OpenFlow Packet_in messages are usually used when there is a flow miss-match with the flow-table of the OpenFlow switch. However, these messages can also result from a specific flow matching, allowing our OpenFlow controller (SDN controller and/or vUE) to implement an OpenFlow flow-based rule in the OpenFlow switches, which originates the required OpenFlow Packet_in message.

Finally, to enable the vUE to assist in managing the UE, we deployed a flow mobility management application to be used along with the POX6 controller. This application stores the information regarding to the UE activity such as active links, MAC addresses and current flows. Such information is further used for handover procedures directly over the UE or to assist the SDN controller for network optimization.

5.4 (Virtual) Point of Attachment (vPoA/PoA)

In our framework proposal, the PoA represents an AP, whose services, such as the attachment and DHCP, are instantiated in the cloud. In this way, while the physical AP is a wireless forwarding device, the vPoA generates, manages and controls the wireless management traffic. Figure 7 illustrates the design architecture of the deployed vPoA for the Wi-Fi use case. Moreover, the vPoA was developed over [30] implementation.
Fig. 7

Virtual point of attachment (vPoA) architecture

To enable this, an enhanced mac_80211_hwsim driver was implemented in the vPoA, enabling to run the hostapd7 (v2.1) software by emulating a wireless interface. Since the hostapd is generating the control and management Wi-Fi frames in cloud, they are tunnelled in Layer 3 towards the respective physical PoA, using the OpenFlow’s tool Capsulator.8 The mac_80211_hwsim driver modification was required in order to allow the redirection of the received flow from the tunnel before being discarded.

Regarding to the implementation of the UE context acquisition in the vPoA, the Link SAP was deployed in the vPoA for monitoring signal strength, new attachment and detachment. However, these implementations are just an illustrative example of a decision module that can be integrated within our framework, with the architecture being flexible enough to accommodate more powerful mechanisms, such as the addition of a mobility module within the UE, or other policy enforcement aspects.

5.5 SDN Controller

The SDN controller capabilities for managing the network, by creating new VMs and reconfigure the network for handover procedures, were implemented using the POX controller along with a SDN application with modules triggered by specific OpenFlow Packet_in messages from the vPoA.

5.6 Headend

To deploy the video headend, VLC was used to stream and transcode a video, mimicking a video server (represented in Fig. 8). As such, through the VLC capability of reading an input video and stream it to multiple destinations with different audio/video encodings, two video streams are available through the same IP address but on different ports. In this way, we are able to have, in the same IP, the same video but in different resolutions, enabling to alternate the video quality as we switch the destination device. This allow us to test mechanisms to improve QoE in mobile video depending on the UE context.
Fig. 8

Headend architecture

Related to the transcoding parameters: (a) the “high quality stream” is transmitted with a 1080p resolution and is targeted to TV’s or Set-top-boxes. The used codec is H264 with a planar 4:2:0 YUV pixel format and a frame rate of 24 frames/s; (b) “low quality stream” is transmitted to mobile devices (i.e., the UE). As such, it is transcoded following the media parameters for Android devices.9 Figure 9 compares both the original video and the transcoded video.
Fig. 9

Video definitions streamed by the Headend towards the end-nodes. a Video streamed to the TV (HD video). b Video streamed to the UE (SD video)

5.7 Set-Top-Box and CN

The Set-top-box was deployed in a Raspberry Pi 310 connected to a TV, running the Raspbian Jessie. Finally, the CN performs the voice call with the UE over the cellular network.

6 Evaluation

To experimentally evaluate our proof-of-concept prototype, the AMazING testbed [31] was used to deploy the physical network entities PoA, video headend, and CN. A Nexus 5 smartphone with Android 6.0 was used as UE. The AMazING nodes were equipped with a 64-bit support AMD APU CPU with 1 GHz dual-core and 4 GB of DDR3-1066 DRAM. The vPoA, vUE, and SDN controller were virtualised in Docker containers (mimicking a data-center). The Docker software was running in a Virtualbox VM, with 1 vCPU, 4 GB of RAM and Ubuntu 64-bit 16.04 LTS OS. The experiments were run 10 times, with their average presented with a confidence interval of 95%. The evaluation assumes that the virtualised entities are already instantiated.

6.1 Impact of the vPoA

To evaluate the vPoA efficiency in terms of bandwidth, we measured the UDP bandwidth with different devices, and compared against a standard Wi-Fi AP implementation (i.e., without virtualisation). The Wi-Fi attachment capability was implemented in both the AP and the vPoA, with both entities being configured in IEEE 802.11g with open system authentication. To measure the bandwidth, the iperf11 tool was used, streaming, during 30 s, UDP packets towards AP (or vPoA). The results are shown in Fig. 10a.

From Fig. 10a it is possible to conclude that the Nexus 5 was the UE device that registered inferior throughput for both strategies (i.e., with or without AP virtualisation). Also, the implementation of OpenFlow bridges on the Linux UE did not negatively affect the bandwidth, since that for both strategies, the throughput was very close to the regular Linux UE. Finally, for all kind of UE the virtualisation strategy achieved inferior throughput (less 13%).
Fig. 10

Comparison between a “traditional” AP and a vAP approach. Considering open-system authentication four messages are involved: t1 is the delay between the messages authentication request (1) and response (2); t2 is the difference between the authentication response (2) and association request (3); finally, t3 is the delay between association request (3) and response (4); a Bandwidth. b Wi-Fi attachment delay

In terms of delay, Fig. 10b compares the Wi-Fi attachment delay with and without virtualisation in a Wi-Fi network, decomposing the delay in the different attachment stages. To simplify the scheme, we measured the attachment delay in the UE using an open-system authentication. From Fig. 10b, we verify that redirecting the management information for the cloud, increments the overall attachment delay. This value was increased by 4.60 ms, and mainly due to the extra round trip time (rtt) between the AP and the vPoA. Notwithstanding, the communication delay increase has its major impact only during the attachment procedure, or alternatively, in the communication between devices attached to the same Wi-Fi AP. If, for instance, we consider that both devices (i.e., sender and receiver) are in different networks, the traffic needs to pass through the service providers network. As such, the delay may not be increased, and in fact, possibly even get decreased, since that all services (i.e., DNS and router) are made in a single physical machine. Analogously, this is also valid for a mobile network. If we virtualise network entities (such as BS and Mobile Switching Centers), despite being attached to the same antenna, the traffic needs to pass through these entities, benefiting of the reduced latency between VMs.

6.2 Signalling Impact of the vUE Flow Mobility

To evaluate the proof-of-concept scenario, the received and transmitted traffic was captured in several network entities (such as, UE and vUE, PoA and vPoA, SDN controller). Figure 11 shows the received video for the evaluated scenario.

As described in Sect. 5.1, initially the UE is accessing an online video12 with standard-definition (SD) quality (following the Android standards). When receiving a voice call, the video switches to the nearest TV upgrading to high-definition (HD) quality, leading to an increase in the throughput. When the voice call finishes, the video switches back to the UE with lower quality, decreasing the throughput to initial values. The scenario was evaluated during 45 s, with UE receiving the video in a total of 24 s (i.e., 15 s before and 9 s after the voice call), and the set-top-box (connected to the TV) in remaining 21 s. The flow mobility process to/from the UE was measured at the PoA in the time window between the offloading trigger and the first video data packet sent to the new destination, presenting a delay of \(27.85 (\pm 3.17)\,\mathrm{ms}\).

Figure 11 presents the amount of video traffic in the network, dividing it by the UE, set-to-box and vUE. The vUE receives both streams (i.e., SD and HD), in order to be able to switch between them dynamically. While the UE receives 22% of the video traffic, since the video transmitted to the TV is high-definition (HD), the set-to-box received 41% of the video traffic, corresponding to 86% more video traffic compared to the UE.
Fig. 11

Video traffic registered in each entity

Table 1 presents the signalling impact of the offloading procedure messages. As a framework that aims to operate independently of the physical layer, medium access control (MAC) headers were not considered. These messages had an impact of a 157 bytes (72 + 85 bytes) in the UE for the trigger (i.e., UDP packets) and 325 bytes in cloud entities (i.e., for the triggers to be sent as OpenFlow Packet_in messages—156 and 169 bytes, respectively). The flow mobility is completed after the implementation of two OpenFlow Flow_modification messages (i.e., the first to implement the new path and the second to remove the previous one) with an impact of 296 bytes (i.e., 172 and 124 bytes, respectively) for the OpenFlow Flow_modification messages). Despite triggers sent from the UE to update the context of its surrounding, the remaining flow management signalling and context triggers are retained in cloud. As such, while 917 bytes for scenario management were accounted in the cloud, only 157 bytes were sent over-the-air.
Table 1

Scenario signalling impact (bytes)


Type of message

Impact on UE (bytes)

Impact on vPoA (bytes)

Arriving call

Offloading opportunity



Ending call

Offloading opportunity



New UE attaching

Context update


UE detaching

Context update


UE’s signal level crossing pre-established threshold

Context update


7 Conclusion

In this paper, we exploited key 5G enablers (such as, SDN, NFV and cloudification) and the virtualisation of PoAs and UEs, providing the foundations to the concept of deviceless communication. This concept ultimately allows a user to be connected by any device on its surrounding. In this paper and in order to avoid associated context privacy issues, we simplified this concept as a UE (smartphone) deciding which nearby device to use (for quality, energy, or convenience reasons). As such, here we explore the interaction of the UE with other connected devices, such as TVs with network capabilities, for selective flow handover, enhancing the user experience by redirecting data and content and taking advantage of the better features existing in such devices (i.e., larger screen). By virtualising the UE (vUE) in the cloud, its context (not only link quality and detected neighbour cells, but also nearby devices with networking and media capabilities) is shared with the SDN controller, minimizing the delay of flow mobility decisions, while benefiting from the increase of computational power for more complex optimizations.

A proof-of-concept framework was implemented and evaluated in a real testbed with a mixed video and voice traffic set, with results showing the feasibility of the proposed mechanism. In this context, the virtualisation had a minor impact in terms of delay and throughput, and presented advantages in terms of mobility management, offloading the decisions to the cloud. As a consequence video QoE was retained even with varying UE’s network conditions, with users able to enjoy the benefits of seamless seeing their video stream being transferred onto a nearby larger screen, while maintaining a voice call.


  1. 1.

    In the past years mobile data traffic has been increasingly growing along with the number of connected devices. Despite composing 45% of the total network attached devices in 2016, smartphones accounted for 81% of the total mobile traffic, with mobile video representing 60% of the traffic [1].

  2. 2.
  3. 3.
  4. 4.

    Bluetooth beacon device: ByteReal TagBeacon 2.0.

  5. 5.
  6. 6.
  7. 7.
  8. 8.
  9. 9.
  10. 10.
  11. 11.
  12. 12.

    Video Caminandes 3:



This work is funded by FCT/MEC through national funds and when applicable co-funded by FEDER PT2020 partnership agreement under the Project UID/EEA/50008/2013, and by the Integrated Programme of SR&TD SOCA (Ref. CENTRO-01-0145-FEDER-000010), co-funded by Centro 2020 program, Portugal 2020, European Union, through the European Regional Development Fund, and by the FCT Grant SFRH/BD/96553/2013.


  1. 1.
    Cisco. (2017). Cisco visual networking index: Global mobile data traffic forecast update, 2016–2021 white paper. Accessed Sept 2017.
  2. 2.
    European Telecommunications Standards Institute. Network functions virtualisation: Network operator perspectives on nfv priorities for 5g (2017). Accessed Sept 2017.
  3. 3.
    Ericsson. (2017). 5G Systems White Paper. Accessed Sept 2017.
  4. 4.
    Onishi, H., & Asaka, T. (2016). Performance evaluation of participatory sensing scheme using delay tolerant networking. In 2016 Fourth International Symposium on Computing and Networking (CANDAR) (pp. 291–296). IEEE.Google Scholar
  5. 5.
    Meneses, F., Corujo, D., Guimaraes, C., & Aguiar, R. L. (2017). An abstraction framework for flow mobility in multi-technology 5G environments using virtualization and SDN. In 2017 IEEE Conference on Network Softwarization (NetSoft) (pp. 1–5). IEEE.Google Scholar
  6. 6.
    Saito, H., Sugo, K., Aida, H., Thepvilojanapong, N., & Tobe, Y. (2012). SBike: Acquisition of person’s state riding a bicycle with mobile sensing for participatory sensing. IPSJ Journal, 53(2), 770–782.Google Scholar
  7. 7.
    Rana, R. K., Chou, C. T., Kanhere, S. S., Bulusu, N., & Hu, W. (2010). Ear-phone: An end-to-end participatory urban noise mapping system. In Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks (pp. 105–116). ACM.Google Scholar
  8. 8.
    Ferguson, A. D., Guha, A., Liang, C., Fonseca, R., & Krishnamurthi, S. (2013). Participatory networking: An API for application control of SDNs. In ACM SIGCOMM computer communication review (Vol. 43, No. 4, pp. 327–338). ACM.Google Scholar
  9. 9.
    McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., et al. (2008). OpenFlow: Enabling innovation in campus networks. ACM SIGCOMM Computer Communication Review, 38(2), 69–74.CrossRefGoogle Scholar
  10. 10.
    Open Networking Foundation. Special report: Openflow and sdn state of the union (2016). Accessed Sept 2017.
  11. 11.
    Yiakoumis, Y., Schulz-Zander, J., & Zhu, J. (2011). Pantou: OpenFlow 1.0 for OpenWRT. Accessed Sept 2017.
  12. 12.
    Yap, K. K., Kobayashi, M., Sherwood, R., Huang, T. Y., Chan, M., Handigol, N., et al. (2010). OpenRoads: Empowering research in mobile networks. ACM SIGCOMM Computer Communication Review, 40(1), 125–126.CrossRefGoogle Scholar
  13. 13.
    Guimarães, C., Corujo, D., & Aguiar, R. L. (2014). Enhancing openflow with media independent management capabilities. In 2014 IEEE International Conference on Communications (ICC) (pp. 2995–3000). IEEE.Google Scholar
  14. 14.
    Chen, C., Lin, Y. T., Yen, L. H., Chan, M. C., & Tseng, C. C. (2016). Mobility management for low-latency handover in SDN-based enterprise networks. In 2016 IEEE Wireless Communications and Networking Conference (WCNC) (pp. 1–6). IEEE.Google Scholar
  15. 15.
    Giust, F., Cominardi, L., & Bernardos, C. J. (2015). Distributed mobility management for future 5G networks: Overview and analysis of existing approaches. IEEE Communications Magazine, 53(1), 142–149.CrossRefGoogle Scholar
  16. 16.
    Nguyen, T. T., Bonnet, C., & Harri, J. (2016). SDN-based distributed mobility management for 5G networks. In 2016 IEEE Wireless Communications and Networking Conference (WCNC) (pp. 1–7). IEEE.Google Scholar
  17. 17.
    Bernardos, C. J., De La Oliva, A., Serrano, P., Banchs, A., Contreras, L. M., Jin, H., et al. (2014). An architecture for software defined wireless networking. IEEE wireless communications, 21(3), 52–61.CrossRefGoogle Scholar
  18. 18.
    Dely, P., Kassler, A., Chow, L., Bambos, N., Bayer, N., Einsiedler, H., et al. (2014). Best-ap: Non-intrusive estimation of available bandwidth and its application for dynamic access point selection. Computer Communications, 39, 78–91.CrossRefGoogle Scholar
  19. 19.
    Lee, J., Uddin, M., Tourrilhes, J., Sen, S., Banerjee, S., Arndt, M., et al. (2014). mesdn: Mobile extension of sdn. In Proceedings of the Fifth International Workshop on Mobile Cloud Computing & Services (pp. 7–14). ACM.Google Scholar
  20. 20.
    Meneses, F., Corujo, D., Guimaraes, C., & Aguiar, R. L. (2015). Extending sdn to end nodes towards heterogeneous wireless mobility. In 2015 IEEE Globecom Workshops (GC Wkshps) (pp. 1–6). IEEE.Google Scholar
  21. 21.
    Meneses, F., Corujo, D., Guimaraes, C., & Aguiar, R. L. (2015). Multiple flow in extended sdn wireless mobility. In 2015 Fourth European Workshop on Software Defined Networks (EWSDN) (pp. 1–6). IEEE.Google Scholar
  22. 22.
    Makris, N., Choumas, K., Zarafetas, C., Korakis, T., & Tassiulas, L. (2016). Forging Client Mobility with OpenFlow: An experimental study. In 2016 IEEE Wireless Communications and Networking Conference (WCNC) (pp. 1–7). IEEE.Google Scholar
  23. 23.
    Andreev, S., Pyattaev, A., Johnsson, K., Galinina, O., & Koucheryavy, Y. (2014). Cellular traffic offloading onto network-assisted device-to-device connections. IEEE Communications Magazine, 52(4), 20–31.CrossRefGoogle Scholar
  24. 24.
    Ericsson. (2015). Cloud RAN: the benefits of virtualization, centralization and coordination—White Paper. Accessed Sept 2017.
  25. 25.
    Li, L. E., Mao, Z. M., & Rexford, J. (2012). Toward software-defined cellular networks. In 2012 European Workshop on Software Defined Networking (EWSDN) (pp. 7–12). IEEE.Google Scholar
  26. 26.
    Gudipati, A., Perry, D., Li, L. E., & Katti, S. (2013). SoftRAN: Software defined radio access network. In Proceedings of the Second ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking (pp. 25–30). ACM.Google Scholar
  27. 27.
    Cai, Y., Yu, F. R., & Bu, S. (2014). Cloud radio access networks (C-RAN) in mobile cloud computing systems. In 2014 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS) (pp. 369–374). IEEE.Google Scholar
  28. 28.
    Akyildiz, I. F., Wang, P., & Lin, S. C. (2015). SoftAir: A software defined networking architecture for 5G wireless systems. Computer Networks, 85, 1–18.CrossRefGoogle Scholar
  29. 29.
    Suresh, L., Schulz-Zander, J., Merz, R., Feldmann, A., & Vazao, T. (2012). Towards programmable enterprise WLANS with Odin. In Proceedings of the First Workshop on Hot Topics in Software Defined Networks (pp. 115–120). ACM.Google Scholar
  30. 30.
    Dely, P., Vestin, J., Kassler, A., Bayer, N., Einsiedler, H., & Peylo, C. (2012). CloudMAC—An OpenFlow based architecture for 802.11 MAC layer processing in the cloud. In 2012 IEEE Globecom Workshops (GC Wkshps) (pp. 186–191). IEEE.Google Scholar
  31. 31.
    Barraca, J. P., Gomes, D., & Aguiar, R. L. (2010). AMazING–Advanced Mobile wIreless playGrouNd. In International Conference on Testbeds and Research Infrastructures (pp. 219–230). Berlin: Springer.Google Scholar

Copyright information

© Springer Science+Business Media, LLC, part of Springer Nature 2018

Authors and Affiliations

  • Flávio Meneses
    • 1
  • Carlos Guimarães
    • 1
  • Tiago Magalhães
    • 1
  • Diogo Gomes
    • 1
  • Daniel Corujo
    • 1
  • Rui L. Aguiar
    • 1
  1. 1.Instituto de Telecomunicações and Universidade de AveiroAveiroPortugal

Personalised recommendations