Service Function Chaining Dataplane Elements in Mobile Networks

The evolution of the network towards 5G implies a challenge for the infrastructure. The targeted services and the full deployment of virtualization in all segments of the network will need service function chains that previously resided in the(local and remote) infrastructure of the Network operators to extend to the radio access network (RAN). Existing mobile networks use cases presented to the working group and the requirement gathering process of the ITU-R IMT 2020 and different initiatives in Europe, Korea and China to anticipate network elements that will be needed in 5G networks allow us to define use cases for this next generation mobile networks. Once on the pillars of them will be service-aware orchestration. We present scenarios identifying where different network functions con be deployed in a fully virtualised future network, where both the core and the edge provide advanced virtualisation capabilities. These scenarios will allow us to derive Service Function Chaining (SFC)-specific requirements.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. Much of the terminology used in this document has been defined by either the 3rd Generation Partnership Project (3GPP) or by activities related to 5G networks like IMT2020 in ITU-R. Some terms are defined here for convenience, in addition to those found in RFC6459. UEUser equipment like tablets or smartphones eNBenhanced NodeB, radio access part of the LTE system S-GWServing Gateway, primary function is user plane mobility P-GWPacket Gateway, actual service creation point, terminates 3GPP mobile network, interface to Packet Data Networks (PDN) HSSHome Subscriber Server (control plane element) MMEMobility Management Entity (control plane element) GTPGPRS (General Packet Radio Service) Tunnel Protocol S-IPSource IP address D-IPDestination IP address IMSIThe International Mobile Subscriber Identity that identifies a mobile subscriber (S)GiEgress termination point of the mobile network (SGi in case of LTE, Gi in case of UMTS/HSPA). The internal data structure of this interface is not standardized by 3GPP PCRF3GPP standardized Policy and Charging Rules Function PCEFPolicy and Charging Enforcement Function TDFTraffic Detection Function TSSFTraffic Steering Support Function IDSIntrusion Detection System FWFirewall ACLAccess Control List PEPPerformance Enhancement Proxy IMSIP Multimedia Subsystem LILegal Intercept

Current mobile access networks terminate at a mobile service creation point (called Packet Gateway) typically located at the edge of an operator IP backbone. Within the mobile network, the user payload is encapsulated in 3GPP specific tunnels terminating eventually at the P-GW. In many cases application-specific IP traffic is not directly exchanged between the original mobile network, more specific the P-GW, and an application platform, but will be forced to pass a set of service functions. Network operators use these service functions to differentiate their services. In order to cope with the stringent requirements of 5G networks (cf. Section 1.3), we expect a new architecture to appear. This architecture will surely make extensive use of virtualisation up to the RAN. We also expect that IP packets will need to be processed much earlier that in the current 3GPP architecture. In this context, it is foreseeable that Service Function Chaining will play a substantial role when managing the chains network traffic will traverse. We also expect new kinds of service functions specific to the radio access part to appear and that these new service functions will need to be managed by the SFC management infrastructure of the operator.

As set forth by the 5G Infrastructure Public Private Partenrship (5GPPP), the evolution of the infrastructure towards 5G should enable the following features in the mobile environment: Providing 1000 times higher wireless area capacity Saving up to 90% of energy per service provided Reducing the average service creation time cycle from 90 hours to 90 minutes Facilitating very dense deployments of wireless communication links to connect over 7 trillion wireless devices serving over 7 billion people

[SFC-Mobile-UC] presents the structure of end-to-end carrier networks and focused on the Service Function Chaining use cases for mobile carrier networks, such as current 3GPP- based networks. We recognise that other types of carrier networks that are currently deployed share similarities in the structure of the access networks and the service functions with mobile networks. The evolution towards 5G networks will make the distinction between these different types of networks blur and eventually disappear. 5G networks are expected to massively deploy virtualisation technologies from the radio elements to the core of the network. The four building blocks of the RAN, i.e. i) spectrum allocation or physical layer (PHY), i) Medium Access Control (MAC), iii) Radio Link Control (RLC) and iv) Packet Data Convergence, are candidates for virtualisation.

[SFC-Mobile-UC] provides an overview of mobile networks up to LTE (Long Term Evolution) networks. As the specifications mature, we will provide the updates to the LTE architecture.

The major functional components of an LTE network are shown in Figure 2 and include user equipment (UE) like smartphones or tablets, the LTE radio unit named enhanced NodeB (eNB), the serving gateway (S-GW) which together with the mobility management entity (MME) takes care of mobility and the packet gateway (P-GW), which finally terminates the actual mobile service. These elements are described in detail in . Other important components are the home subscriber system (HSS), the Policy and Charging Rule Function (PCRF) and the optional components: the Traffic Detection Function (TDF) and the Traffic Steering Support Function (TSSF), which are described in . The P-GW interface towards the SGi-LAN is called the SGi-interface, which is described in . The TDF resides on this interface. Finally, the SGi-LAN is the home of service function chains (SFC), which are not standardized by 3GPP.

Source [SFC-Mobile-UC] Service Functions handle session flows between mobile user equipment and application platforms. Control plane metadata supporting policy based traffic handling may be linked to individual service functions. In 5G networks, we expect the packet gateway (P-GW) to loose its central position and be integrated with functions in the RAN. Radio Resource Control (RRC) in 5G network will be integrated into the Control Plane environment.

TBD: We expect classification schemes for 5G networks to evolve as the standards appear.

TBD: We except the RRC to be integrated with the SFC Control plane in 5G.

4G mobile operators use service function chains to enable and optimize service delivery, offer network related customer services, optimize network behavior or protect networks against attacks and ensure privacy. Service function chains are essential to their business. Without these, mobile operators are not able to deliver the necessary and contracted Quality of Experience (QoE) or even certain products to their customers. As set forth by the 5G-PPP [5GPPP], the evolution of the infrastructure towards 5G should enable the following features in the mobile environment: Providing 1000 times higher wireless area capacity Saving up to 90% of energy per service provided Reducing the average service creation time cycle from 90 hours to 90 minutes Facilitating very dense deployments of wireless communication links to connect over 7 trillion wireless To meet these additional requirements, operators will need to make an extensive use of service chains and to extend their scope to functions in the Radio Access Network.

Virtualisation and softwarization will be among the key technology introduced in the design of future 5G Network architecture. They allow to decouple the binding between hardware and software components in a flexible way. While used in conjunction with SFC, future mobile network may support the dynamical allocation of Network Functions (NFs) in network nodes and their orchestration according to the requirements of the implemented service. These concepts will be the building blocks of the future 5G architecture. Current efforts in the definition of SFC mostly focus on Core Network functions. We believe that the cloudification of RAN functions will increase the flexiblity needed to support very demanding and heterogeneous services envisioned by future 5G Networks, and hence the definition of the SFC Dataplane elements must also take into account functions once considered monolithically embedded in the eNB. In the next sections, we present some technical solutions that leverage on these novel concepts.

The current 3GPP LTE Mobile Network architecture offers a low flexibility. Even by applying SFC techniques, specific network functions are executed in well-defined units (e.g., eNB and P-GW functions are carried out in dedicated hardware). Moreover, those network equipment are usually physically located in precise locations. This static approach burdens the flexibility needed by future 5G Networks. Softwarization and Virtualisation techniques allow for the flexible deployment of functions in the network. Therefore, the placement and execution of network functions should not be driven by topological constraints, but rather on QoS ones such as the specific requirements of the implemented service (e.g., latency, bandwidth and reliability, among others), the radio characteristics and the transport network capacity. This approach enables enables the concurrent execution of different instantiations of the protocol stack in the same nework infrastructure, as envisioned by the network slicing [REF NGMN Description of Network Slicing Concepts] concepts. SFC is set to be a fundamental technology in this framework, allowing the dynamic deployment of different chains across many network slices spanning different cloud infrastructure arrangements. Hence, network functions can be physically located into different zones of the network: near the transmission point (edge cloud) or in centralised data centers (central cloud). The choice on the orchestration of such network functions will hence happen on a per-service basis.

Source [SFC-Mobile-UC] In order to achieve a service aware orchestration described above, there are some challenges that need to be addressed. They are illustrated by the following examples : Vehicular communications need low latency and sessionless connectivity. Therefore, almost all the VNFs belonging to this service should be located close to the transmission point, including those traditionally located in the core network; Tactile Internet applications require both low latency and session continuity. Therefore, most of the the network functions should be located close to the transmission point, but some control plane ones should be located in the core network; Broadband access users do not usually have strict latency requirements. Thus, the network functions related to them may be located in the core network, efficiently exploiting the multiplexing gain enabled by this kind of deployment.

Traditional architectures force a fixed topological relation between network functions, while in a virtualized architecture, as the one proposed above, these constraints are relaxed. This difference is especially highlighted for access and core network functions. While in a traditional architecture, these functions were usually executed in different parts of the network (e.g., the scheduler in the base station and a firewall in the centre of the network), a virtualised architecture blends the boundaries between access and core functions: their final location is decided on a functional basis. For instance, services with strict latency requirements may be located close to the transmission points, while services that can exploit centralisation may be located in the core data centre. The application of this concept may end up with access and core functions sharing the same network location. This fact enables possible improvements, as detailed in the following example. Currently, mobility and scheduling decisions are taken separately. The mobility-related network functions are traditionally located in the core network and their decisions are taken before scheduling ones, which are taken subsequently, in the access network. It is important to note that a decision about mobility cannot be modified at the scheduling level. With a fully virtualised architecture, the mobility and scheduler network functions may be co-located in the same network node, enabling a possible joint-optimization between mobility and scheduling. However, this is only one example of possible optimizations that can be achieved using this kind of approach. The proposed approach reduces high latencies introduced by the traditional access-core deployment. Therefore, further optimisation may be introduced as the impact of signalling protocols is reduced. SFC is expected to play a fundamental role in this picture, allowing the flexible chaining of network functions.

Organizational security policies must apply to ensure the integrity of the SFC environment. SFC will very likely handle user traffic and user specific information in greater detail than the current service environments do today. This is reflected in the considerations of carrying more metadata through the service chains and the control systems of the service chains. This metadata will contain sensitive information about the user and the environment in which the user is situated. This will require proper considerations in the design, implementation and operations of such environments to preserve the privacy of the user and also the integrity of the provided metadata.

This document has no actions for IANA.

This work has been partially performed in the scope of the SUPERFLUIDITY project, which has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No.671566 (Research and Innovation Action). This work has also been partially performed in the framework of the H2020-ICT-2014-2 project 5G NORMA. The authors would like to acknowledge the contributions of their colleagues. This information reflects the consortium's view, but the consortium is not liable for any use that may be made of any of the information contained therein.