LEVERAGING THE FULL POTENTIAL WITH NETWORK SLICING Network Functions Virtualization technology allows for easier creation and expansion of separate logical nodes and functions for a specified group of traffic and signaling, often referred to as a network slice. In turn, network slicing opens up a new way of achieving in-service software management at the network level.
ericsson White paper
Uen 284 23-3248 | December 2014
Network functions
virtualization
and software
management
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • THE PURPOSE OF NFV 2
The purpose of NFV
Network Functions Virtualization (NFV) is commonly described as a network architecture concept that uses IT virtualization technologies to virtualize entire classes of network node functions into building blocks that may be connected or chained together to create communication services.
The initial interest in introducing NFV into telecom has, to a large extent, been driven by the desire to decrease costs through the use of generic hardware platforms as well as the separation of software and hardware lifecycles. This discussion has subsequently been combined with promises of increased efficiency from the IT industry when running networking applications in virtual machines within data centers.
As the discussion has progressed, it has shifted further towards efficient management and improved time-to-market for new services.
Some of the most promoted benefits of NFV include:
› Flexibility – easier and quicker installation and provisioning of the network, which allows for more rapid service deployments.
› Cost – the above-mentioned flexibility has the potential to lower costs for managing services deployed in a network, as well as managing the network itself.
› Scalability – introduction of software services allows for easier scaling of available hardware resources. By scaling resource needs up and down over the course of the day and expanding capacity over time or in reaction to extraordinary events, it would be possible, for some use-cases, to increase the utilization of the equipment and allow for more efficient use of investments in the installed compute power.
› Security – security has been and continues to be, along with virtualization, a major challenge in networking. Operators want to be able to provision and manage the network in a secured manner, and NFV helps them achieve security and integrity through separation and isolation (as long as the environment is secured).
› Rapid deployment in another network – to better meet user needs, service providers want the ability to deploy their offerings anywhere in the world. Virtualization simplifies this.
For NFV to become really useful, software-defined networking (SDN) technology is required.
SDN allows computer-network administrators to manage network services by hiding physical deployments and presenting them as virtualized services. Network services also need to be virtualized in order to reach the same level of flexibility and achieve the advertised simplifications and gains of NFV. Without this, it is not possible to realize many of the promises of NFV in the data center.
The introduction of SDN adds even more potential to NFV, as traffic no longer needs to be steered based on IP addresses alone. With SDN technology, it can instead be handled on a per-flow basis, which allows for fine granular control of the traffic, with service-chaining solutions of subscriber policies serving as good examples. SDN may, of course, also be used to steer which path to use when several functionally identical paths are available.
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • NETWORK SLICING 3
Network slicing
A logical instantiation of a network is often called a network slice. Network slices are possible to create with both legacy platforms and network functions, but virtualization technologies substantially lower barriers to using the technology, for example through increased flexibility and decreased costs.
Currently, management of networks is mostly about managing individual network elements. One of the major ideas behind NFV is to automate management for the entire network so that complex network-spanning tasks are easier to perform. Integration of different NFV components will still be a complex task for the operator, but on the other hand NFV allows an entire network to be delivered as a pre-integrated network slice.
Another aspect of management and network slicing is setting up separate management domains for different network slices. This may allow for completely separate management of different parts of the network that are used for different purposes. Examples of use cases include mobile virtual network operators (MVNOs) and enterprise solutions. This kind of network slice would, in current Evolved Packet Core (EPC) networks, only cover the PDN gateway (PGW) and the policy control resource function (PCRF). However, for machine type communication (MTC) and machine-to- machine (M2M) solutions, it is likely that it would also cover the Mobile Management Entities (MMEs) and Serving Gateways (SGWs).
Separation of management may also be expanded into security aspects. Separate management per network slice, as described above, is a first step towards this, but by using network slicing it would be possible to deploy virtual network functions (VNFs) in separate networks with separate configuration and network topology. Add to this the potential to run VNFs on dedicated hardware, which provides more predictive characteristics as well, and it is obvious that improved security and improved quality of service assurance are also important aspects of network slicing technology.
When the operator sources a complete network slice from a single vendor, the vendor can deploy a network optimized for a selected set of terminals according to policy and behavior. The network slice may, for example, be resilient to hardware and software failures, or it may be optimized for signaling intensive behaviors, such as in machine-to-machine terminals.
When a network slice covers only a part of the network topology, it is called a sub-network slice, which indicates that network slicing can also be hierarchical. The most commonly used containment of network slices in EPC is the PGW and PCRF in the same slice. Since the PGW selects the PCRF and the Access Point Name (APN) name is used for PGW selection from the MME, the selection mechanisms employed here are often already in use in legacy networks. But with network slicing in the data center, they are likely to be even more commonly used. It is also likely that there will be dedicated PGWs and PCRFs for many different deployments, both small and large.
Adding a SGW to the previous network slice of a PGW and PCRF and thereby creating another level of network slicing (while still supporting connections from other SGWs to the PGW) is a solution that is of interest when co-located SGWs and PGWs are used. As specified by 3GPP, the SGW selection in the MME can take the selected PGW into account.
Throughout this paper, virtualized EPC networks and other mobile network solutions will be used as specific examples, although the generic principles are just as applicable to other scenarios such as fixed broadband
access, legacy platforms and other networking nodes. Figure 1: Examples of network slices in an Evolved Packet Core deployment.
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • USING NETWORK SLICING FOR SOFTWARE UPGRADES 4
Using network slicing for
software upgrades
Network slicing is not only used for simplifying the management of the network when running it with a static function set. It also has the potential to make changes to the functionality realized by networking functions.
One of the more costly processes when managing an operator network is to upgrade networking software. This process includes many complex and costly tasks, such as maintaining a parallel network deployment for testing new software and configurations, including validation of compatibility of the different software versions of different networking products. The process also includes validation of network configuration changes and validation of features and properties added by the vendor, as well as running the system to make sure that no issues are introduced in old functionality when upgrading the system.
Another aspect to consider is that the tests in the lab network do not correspond to the actual behavior of the network in live operation. This real-world behavior might require rollback of an upgrade if issues are identified.
With a complex network with many different network elements, the total time it takes to upgrade a network can be as high as the total sum of upgrading all of the network elements one by one in a row.
This is often the limiting factor for adding functionality to a network.
If an operator is orchestrating management for data center functionality such as VNF scaling, it also makes sense to use that particular management solution when handling software upgrades. If the management solution is orchestrating a network slice, it also makes sense to upgrade the end to end service per network slice as well. This is especially true if upgrades of the individual VNFs impact the operation and maintenance (O&M) solution and perhaps also business systems such as charging and event logging servers. This then drives an integration of O&M and business solutions.
Network slicing can drastically simplify the installation, validation and on-boarding of traffic for new software versions and, at the same time, decrease risks, as the integration can be done in advance and the on-boarding can also be done step-by-step while still evaluating the functionality. This has the potential to reduce deployment time of a slice down to minutes, and validation down to hours. If something goes wrong when activating a new network slice, the step-by-step migration is available for rollbacks as well, minimizing the risk of impacting higher-prioritized active user sessions.
SETTING UP A PARALLEL NETWORK SLICE FOR VALIDATION
When adding new functionality to a network, the affected network elements must all be updated and verified to support both the new and legacy functionalities. This is a complex integration activity that often takes several months. To avoid problems with live networks, some of these activities are often performed in a separate lab network that is used to verify new integration of products and configurations. This lab network can then be seen as a separate slice of the operator’s network, even though it only has limited connectivity to the rest of the network.
Network slicing allows operators to set up a lab network in parallel with the live network in the data center environment. Here they may reuse parts of the network configuration for the live instance. By taking a snapshot of the running configuration as a baseline for the new network slice, reconfigurations can be kept at a minimum.
Test tools and other validation mechanisms can then be run on this network deployment without risking the live network. When the network slice is fully tested, the same setup can be taken into live service as it is already running in the same data center environment.
Other aspects of network slicing, such as security features and separate management, enhance this solution even further.
CONNECT THE PARALLEL NETWORK TO THE TERMINALS
If the new software deployment works well in the lab environment, it is possible to add real terminals to the setup. Depending on the networking setup, different identifiers may be of interest. As an example, selection of APN in EPC can be used to select SGW and PGW. When applicable, steering based on the International Mobile Subscriber Identity (IMSI) of an actual terminal, or even IMSI-series or PLMN-IDs, can allow actual terminals to use the live radio interfaces. This allows further verification that is hard to simulate in a test environment.
With real terminals in the network slice, the KPIs from these can be compared to KPIs from the live network. For instance, if the functionality is to be the same after a software upgrade of the components in a network slice, the KPIs should scale in the same manner, which makes this validation possible to automate as well.
STEP-BY-STEP MIGRATION OF SESSIONS
Once testing with friendly users has been performed, a major advantage of network slices appears. As the deployment is done on virtual resources, there are minimal obstacles preventing it from being set to live service. The needed functionality is there, including scalability. The software deployment is therefore ready to take into service. To do this, real user terminals need to start using the new network slice. With the proper selection mechanisms in place – such as Domain Name System (DNS) for SGW and PGW, and in the future Dedicated Core (DECOR) for MME, with PLMN-ID possibly used in some cases (for example, for handling roamers differently) – this can be implemented in a finer and more granular way. By first re-attaching terminals that have a low monthly subscription fee or are pre-paid to the new network slice, the risk to subscribers that pay for and require a better service is decreased. Monitoring of KPIs during this process allows the operator to further evaluate whether everything is working as expected.
There are many aspects to consider when performing a process like this. First of all, the re-attach rate is normally within reasonable limits, as the existing EPC nodes need to cater for the signaling load of re- attaching terminals. However, in this case, scaling during operation requirements is added on top, though it is usually not an issue if the application scaling triggers are dimensioned properly.
The next thing that vendors need to address is that not all terminals will re-attach within reasonable time. Sessions may have a lifetime of weeks or more, and terminal sessions therefore need to be terminated sooner or later. Figure 2 shows how load moves from one network slice to the other. At the end, one can also see sessions being torn down when the network slice is taken down and the corresponding gradual activation of sessions on the other network slice that maps to that.
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • USING NETWORK SLICING FOR SOFTWARE UPGRADES 5 Figure 2: Load when migrating between network slices.
As an example, within EPC, the MME and SGW can be relocated with an active PDN connection through mobility procedures, but the PGW cannot be upgraded with an active session (due to the anchoring of a user IP address). So for the PGW and PCRF to be re-selected, current 3GPP standards require a re-attach that would terminate any ongoing traffic. Many of the services used in a terminal in an EPC network would accept a new IP address for the session due to a re-attachment to the network without only minor service impact. For many network deployments, it is therefore permissible to throw out the PDN connection (preferably with a re-attach requirement indication in the signaling) and wait for a new PDN connection to be established. Such an establishment can then be done directly towards the new network slice, including the PGW and PCRF.
A use case that needs more attention is when a service that requires high end to end availability is running on a dedicated APN on a dedicated PGW that is not part of the upgraded network slice in EPC, which could, for instance, be a VoLTE service. Upgrading the network slice would need to support mobility procedures in between the network slices if this upgrade is to be done without service interruption. This is possible, but might not be a prioritized solution.
Instead, the simplest and most obvious way to address long-lived sessions during software upgrades is to initiate a re-attach procedure from the dedicated services APN when it is suitable for that service.
Then it is only the service on the dedicated APN and PGW that needs to be re-attached. This does not have to be managed together in a service-oriented network slicing deployment with mobile-broadband services; instead it may be handled together with management procedures dedicated to the service in order to decrease the end to end impact. As this example shows, when multiple coordinated connections exist, the solution becomes more complex but still easier to manage and with less service impact compared to the legacy solutions.
With NFV technology and network slicing, a parallel network can therefore be easily provisioned and tested in a data center environment. It allows for easy verification and for a step-by-step approach to migrating sessions to the new network.
It is also worth noting that when a single vendor delivers the software for an entire network slice, the solution for parts of the network may be pre-integrated and delivered by that vendor. This simplifies the integration activities for the operator, as the components can be sourced and maintained as a ready solution. With software upgrades based on network slicing, the value of pre-integrated software increases even further as much of the complexity of the software upgrades becomes the responsibility of the vendor.
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • USING NETWORK SLICING FOR SOFTWARE UPGRADES 6 Figure 3: Example of parallel EPC networks with different software version combinations and
configurations.
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • USING NETWORK SLICING FOR SOFTWARE UPGRADES 7 A SUMMARIZED SOFTWARE UPGRADE PROCEDURE (AN EXAMPLE USING EPC)
› Task: The operator wants to upgrade the network to a new software version to support new services.
› Pre-requisite: A set of terminals is attached to the radio network and an existing network slice of the EPC.
› First step: Create a new network slice.
The slice is deployed with the desired software versions of the desired VNFs. The software components and versions may be pre-delivered and integrated by a single vendor, but this is not a requirement.
The software is then configured according to the desired functionality. For a pure software upgrade, this is, in principle, a clone of the software configuration of the currently active network slice. If a change in behavior is to be activated, the configuration is modified accordingly.
› Second step: Run quality assurance procedures.
When quality assurance tools are available, such as end to end test tools, these can be run to ensure that the new network slice is behaving according to expectations. The next level of assurance is to let friendly users use the network. Validation during and after such procedures can also be done through inspection of KPIs.
› Third step: Migration of re-activating sessions.
According to existing 3GPP procedures, active sessions cannot be migrated when they are active, so migration of sessions is done during attach and re-attach
procedures. The migration can be done slowly to allow for automatic inspection of KPIs in order to identify potential issues with the new software versions or configurations. It is reasonable to address the most demanding subscriptions last, as the risk of something going wrong normally decreases with time and load of the new deployment.
› Fourth step: Schedule re-activation of sessions.
Active sessions that do not re-attach to the network will not be able to connect to a new PGW, even though the SGW and MME can be relocated. To handle this, the PGW needs to disconnect active PDN connections. One efficient way of doing this with minimal service impact is to disconnect inactive subscribers, which will disconnect sessions that have not been used for a configured time.
› Fallback: If there is any indication that the new network slice is not able to fulfill the requirements for the solution, it is easy to perform a fallback at any step in the process.
All that is required is to update the slice selection configuration and wait for the sessions to move over. When the new slice is to be removed, or if the issues with the new slice are too troublesome, then a controlled scheduling of re-attachment procedures for active sessions on the new network slice can be initiated.
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • CONCLUSION 8
Conclusion
Network slicing allows an operator to put more focus on the management of network solutions driven by business cases. With network slicing, a parallel network can be set up with a new software version of the involved functionality, followed by step-by-step migration of sessions – lowering the risk for the operator and ensuring minimal disruption to subscribers.
Network slicing is simplified by NFV, and therefore opens up a new way of achieving telecom- grade software management at the network level by focusing on the characteristics needed for a specific business segment. As a result, it enables more efficient business models for operators while simplifying software architecture requirements, including software upgrades, on network elements such as MME, SGW and PGW.
With software upgrades based on network slicing, the value of vendor pre-integrated software increases, as much of the complexity of the software upgrades can become the responsibility of the vendor.
NETWORK FUNCTIONS VIRTUALIZATION AND SOFTWARE MANAGEMENT • GLOSSARY 9
GLOSSARY
APN Access Point Name
DECOR Dedicated Core (3GPP Work Item)
DNS Domain Name System
EPC Evolved Packet Core
IMSI International Mobile Subscriber Identity
M2M machine-to-machine
MME Mobility Management Entity MTC machine type communication MVNO mobile virtual network operator NFV Network Functions Virtualization O&M operation and maintenance PCRF policy control resource function
PDN Public Data Network
PGW PDN gateway
PLMN-ID Public Land Mobile Network Identifier SDN software-defined networking
SGW Serving Gateway
VNF virtual network function
© 2014 Ericsson AB – All rights reserved
