THE BUSINESS POTENTIAL OF NFV/SDN FOR TELECOMS

Transcription

1 WHITE PAPER THE BUSINESS POTENTIAL OF NFV/SDN FOR TELECOMS

2 WHAT YOU WILL LEARN What are the potential benefits of implementing Network Function Virtualization (NFV) and software-defined networking (SDN)? How to transform the (access) network towards a distributed cloud platform capable to reshape itself dynamically to better serve customer applications? How to run network functions and customer cloud applications on the same hardware? What are the benefits of colocating network functions and customer applications for improving customer experience? Why is it essential to implement control via policies in the NFV/SDN scenario? How does BSS/OSS support NFV and why should OSS work in real-time?

3 Network Function Virtualization (NFV) appears to be a very promising, yet very disruptive, technology. At its simplest, NFV is about decoupling software from hardware and enabling the implementation to run on a farm of commodity hardware. In other words, it means placing network functions (NF) in the cloud. THE POTENTIAL BENEFITS OF NFV/SDN TECHNOLOGY From the perspective of network operators, the new technology entails the ability to become a real cloud provider in a new sense, where a network is no longer simply an access network to data centers. On the contrary, the network can become a cloud serving as a platform for customer applications, and it can dynamically reshape its architecture to meet customer needs. This revolution is possible thanks to combining NFV and software defined networking (SDN) technologies, which means that networks can adapt by being reprogrammed. Moreover, network nodes can also become part of distributed data centers that not only can host network functions, but also host applications. From the perspective of customers, this means that applications can be moved closer to the customer, entailing lower latency and higher speed, thus leading to better customer experience. The technology also promises to open the network to iovation from the software developer ecosystem. Instead of rigid networks that are difficult to adjust to different application needs, the network is to be programmable, ready for the era of the Internet of Things (lot), where applications can have their own virtual networks programmed. From the cost savings point of view, the liberation from dedicated (expensive) hardware in favor of commodity (cheap) hardware promises to reduce CAPEX (capital expenditure). Also, the idea of a purely software-based network reconfiguration should reduce OPEX (operational expenditure). This may not be that obvious if one of the goals is to make the network more dynamic, reshaped to meet the needs of applications and thus be much more complex to control, when a traditional approach to network management is taken. From the cost savings point of view, the liberation from dedicated (expensive) hardware in favor of commodity (cheap) hardware promises to reduce CAPEX (capital expenditure). Also, the idea of a purely software-based network reconfiguration should reduce OPEX (operational expenditure). To reduce operational costs without sacrificing the benefits of a more dynamic network, a catalog-driven network management approach, typical for modern OSS systems, should be taken. It enables implementing an orchestration concept defined in the ETSI referential architecture for NFV. The catalog will capture the customer services and the related polices defined at different abstraction levels, in such a way that even the lowest level resource management policy is aligned with customer service needs. This also means a shift towards policy-driven network management and automation and can pave way to implement the self-organizing network (SON) concept. The main potential benefits of implementing NFV/SDN technology are therefore the enablement of realizing the SON concept and the reduction of OPEX. MOVING APPLICATIONS CLOSER TO THE CUSTOMER : THE NETWORK AS A DISTRIBUTED DATA CENTER The basic definition of NFV is to have network functions implemented on the same commodity hardware as is used in data centers. If so, both network functions and customer cloud applications can be run on the same hardware. It can either mean moving network functions to data centers, or the opposite: moving applications to network edges. WHITE PAPER 3

4 When NFV is combined with its complementary technology, SDN, the cloud can become a real cloud. Unlike many implementations in which in the cloud means ruing in a central data center with limited geographical distribution, the real cloud means a distributed environment where applications can be migrated as close to the customer as it takes to provide good customer experience at a reasonable cost. To make this happen, the network topology should be able to migrate across the network. If network functions can run on the same hardware as end-customer applications, it becomes possible to colocate applications and network function in the same nodes, which can effectively become microdata centers. This idea is depicted on Figure 1. vbbu vsgw vpgw APP VIP enodeb RAN EPC SGW SGW PGW PGW PDN APP DATA CENTER APP BBU BBU SGW PGW APP enodeb enodeb VIP Figure 1. Extending the cloud to the network edges: RAN and Core seen as micro-data centers An interesting case in point would be placing a video on demand (VoD) server at the enodeb node, which in fact means placing the video source as close as possible to the mobile user. From the perspective of traditional network topology, as defined by 3GPP, the network should at least include enodeb, SGW (serving gateway), and PGW (packet data network gateway). Traditional network architecture assumes that there is a link between enodeb and SGW, and it is implemented on top of the mobile backhaul, entailing many potential IP hops. The colocation of these functions in one physical node means that almost no mobile backhaul is necessary. For customers, it reduces latency, thus increasing service quality. For telecoms it lowers the burden on the mobile backhaul. LOGICAL VS. PHYSICAL NETWORK FUNCTION HIERARCHY AND PLACEMENT First, one may argue that one of the reasons why (according to the 3GPP model) SGW is not colocated with enodeb, is that SGW is meant to serve many enodebs. But thanks to virtualization, and from the logical point of view, SGW can be perceived as a higher-level node in the topology. At the same time, it can be physically implemented on many hardware nodes. These physical implementations may be colocated with many enodebs. In this way, it is still possible to preserve the logical topology as defined by 3GPP, yet the physical implementation can be dynamically adjusted to the traffic load needs. This idea is presented at the top of Figure 1, where vbbu, vsgw and vpgw preserve the 3GPP-defined dependencies between the network functions, while the physical placement of functions instances can be different. 4 WHITE PAPER

5 PHYSICAL DISTRIBUTION OF NETWORK FUNCTIONS COSTS VS. BENEFITS Physical distribution is a concept well known in the IT world. For example, a distributed database brings about replications and benefits related to scalability, but at the same time problems with assuring consistency between the physically distributed nodes. In practice the decision of whether a network function should have greater distribution (have more physical nodes in different allocated locations) should be based on a cost vs. benefit calculation. The same is true for VoD services: for movies that are often watched by different users in the same geographic area, it makes sense to replicate the movie from the central server to local ones (at enodebs). Copying the movie to the network lowers the burden on the mobile backhaul. However, for movies that are not that popular, it can make more sense to transfer the movie to the customer from the central video server (many hops away). The decision of whether a network function should have greater distribution (have more physical nodes in different allocated locations) should be based on a cost vs. benefit calculation. Providing a VoD service is very close to the concept of content delivery networks (CDN). It describes how to implement CDN without a need to hardcode its topology. The NFV/SDN technology provides an elegant way to implement CDN. The described idea of moving applications closer to the customer is not limited to content-based applications, but can appeal to any type of applications that have stringent requirements towards latency. At the same time, if an application is hosted many IP hops away from the data center, it may present a heavy burden on the network. This concept is shown in Figure 1, where the virtualized network means that the RAN and Core networks can be part of a distributed cloud with a micro-data center. In the presented example, the App1 application, which was traditionally deployed at a data center, can have the resources allocated closer to the customer. WHITE PAPER 5

6 In the extreme example the resources may be allocated to the application at a RAN micro-data center. At the same time, virtual network functions may need to be colocated with the application. For example, the SGW and PGW virtualized network function can also have resources allocated closer to the customer at the same micro-data center as the application is located. In the ideal scenario, e.g. in the case of VIP customers, the application can be hosted as close as the RAN infrastructure. This way to access the application the traffic does not need to go through the mobile backhaul. As microdata centers will have limited resources compared to traditional data centers, non-vip customer requests may proceed via the mobile backhaul and the core network to the traditional data center. A CLOUD IN THE CLOUD? The opposite scenario with network functions moved to data centers is also justified in certain cases. This may be necessary when computing resources must be scaled up to handle extra traffic. The ability to allocate additional resources in the data center to handle bursts of traffic and then scale back down can be more economical than to allocate more resources at regular network nodes. In this scenario, the effect of moving network functions to the data center can bring benefits of colocating cloud applications with the NFs, which is common in IT parlance. This assumes that local communications between the colocated software components is much faster compared to when the software components reside on remote machines. Referring to the example in Figure 1, it means that, for example, SGW and PGW can have the computing resources allocated at the data center, which is hosting the given application. When deciding, which option is a better choice, the answer is: both can be. Ideally you should not hardcode the architecture for any of these scenarios. Instead, an NF and/or application relocation decision should be done by the policy that takes into account factors such as: current traffic levels, performance statistics and applications profiles (such as acceptable latency, etc.). Moreover, relocation can mean no more than allocating the extra computing (or other infrastructure) resources on remote nodes. Dynamism is a key aspect and must be driven by policies rather than direct control commands issued by humans. CONTROL VIA POLICIES: THE MAGIC ANSWER? Control via policies sounds like a magic answer, but this is probably easier said than done. When taking into account that controlling via polices requires a hierarchy of policies, policy management may also sound complicated. In fact, hierarchy of policies is all about simplification. It is best to present some examples to explain this concept. A provider of customer applications should probably not directly state whether its application should be run at any specific network edge node. Instead, the provider may define requirements, such as the maximum acceptable latency that can assure good customer experience. Application providers should probably determine such requirements, as they are the ones who best understand the applications. These application requirements define the application level policy. Network operators, who at the same time play the role of cloud providers, may treat this application policy as high-level. They may use their own policy, which additionally takes into account the network structure. For example, when many different applications are being deployed with variously defined required maximum latencies, the operator s policy may decide which application is going to be moved closer to the customer, colocated with appropriate virtual network functions, and run on hardware located at the enodeb access node. In addition, this policy may take into account the number of customers accessing the applications from the given enodeb (traffic statistics) to decide which of the applications competing for resources should be moved closer to the customers. An example of an even lower-level policy could be one deciding about allocating virtual machines (VMs) to virtual network functions. For example, such a policy may try to optimize energy efficiency or reduce the number 6 WHITE PAPER

7 of VMs ruing. However, none of these goals should be achieved at the cost of customer experience degradation. This means that policies must be defined in the maer of hierarchy, thus assuring that high-level business requirements are met. To conclude, from an application provider s perspective, a network can be treated as a cloud and that the role of application policy is to define application expectations. Moreover, there is no need to directly define how a network should be operated. From a network operator s point of view, these application requirements are a service request from the application provider. In other words, an operator may sell application hosting services and differentiate the price based on quality of service, (e.g., maximum acceptable latency). In this way, operators managing their infrastructure are assured that resource allocation is driven by business-related criteria. From an application provider s perspective, a network can be treated as a cloud and that the role of application policy is to define application expectations. Moreover, there is no need to directly define how a network should be operated. From a network operator s point of view, these application requirements are a service request from the application provider. Policy management is a broad subject. The main idea, however, is to use the service catalog for managing the hierarchy of service policies and to assure that the network is driven by high-level business requirements. This can be achieved by employing BSS/ OSS catalog-driven fulfillment/orchestration for managing an NFV/SDN-based network. CONTROL VIA POLICIES: BUSINESS VS. TECHNICAL ASPECTS When the cloud is extended to the network edges and the network becomes part of the cloud, the nodes (especially access nodes), which are closer to the customer, become micro-data centers. It does not mean that traditional data centers will become obsolete. Far from it as the cloud becomes fully distributed, it also becomes heterogeneous so it can comprise data centers of different sizes and costs. Dedicated data centers designed for massive processing are bound to provide much cheaper computing resources than micro-data centers at the edge of the network. When deciding whether or not to move applications closer to customers, it is not only customer experience goals that must be taken into account, but also the costs of infrastructure and the problem of competition between applications for scarce resources at micro-data centers. This problem may, however, also present an opportunity for network operators who will play the role of cloud providers. The services sold to the end customers may have been price differentiated per assured customer experience. So, VIP services can be more expensive and cover costs of better customer experience achieved by deploying applications at more costly micro-data centers. In the diagram (Figure 1) VIP customers may be served by instances colocated at the microdata center to assure premium customer experience, while non-vip customers may be served by applications hosted at traditional data centers, where computing resources are bound to be less expensive. At the same time, the system should check to see if it makes sense to move applications closer to the customer. If the access network is not a bottleneck, moving an application from a cheaper data center to a micro-data center that is more expensive may not be justified. What is interesting is that this may dynamically change, depending on the traffic. This all leads to the need to have a properly defined hierarchy of policies: high-level defining the business criteria and low-level related to the technical criteria. The policy hierarchy is to assure that there is no clash between the policy rules. WHITE PAPER 7

8 THE OSS ROLE: REAL-TIME OSS FOR NFV/SDN As the key to benefit from the NFV/SDN potential is implementing control via multi-level hierarchical policies, the ideal solution for policy management seems to be a service catalog where policies can be managed together with services (in fact, a policy can be treated as a service itself). The alignment between business and technical policies can be assured by leveraging the concept of TMF SID: Customer Facing Services, Resource Facing Services, and Resources. This TMF-based SID model seems perfect to model the relation between multi-level policies. Moreover, catalogdriven fulfillment seems to be a perfect match for implementing an NFV orchestration layer. Managing definitions of policies is not enough. You need a dynamic, up-to-date view of the network and the applications to be able to execute these policies. Network inventory is another OSS system that may help manage the NFV/SDN environment, as it may provide a physical infrastructure view, VNF node locations, and logical network topology, including that of micro-data centers and traditional data centers. Service assurance solutions can provide a view of the network traffic, thus helping to establish the location of the congestion and suggest when it makes sense to migrate applications to actually improve customer experience. The reallocation of applications and VNFs requires programming the network. Network inventory, together with service assurance solutions, can assist an SDN controller when making the re-routing decisions to optimize quality of service. Reallocating application and network functions must be dynamic to provide good customer experience at reasonable costs. In addition, the need to react to changing traffic and application loads means that OSS must work in real-time. Moreover, OSS needs to shift from a role of purely managing and orchestrating towards being a true part of a dynamic network. OSS IN THE CLOUD: THE NEW MEANING OSS VIRTUALIZATION Real-time OSS means that performance scalability becomes critical. To transform OSS to real-time can be challenging, but the solution lies in OSS virtualization i.e. placing OSS in the cloud. This may not be a new concept, but in this case it is more than just locating the OSS system in a data center and having it managed by the OSS provider. Instead, OSS may also be reallocated within the network nodes and be colocated, with VNFs and applications to assure the correct level of responsiveness. OSS must therefore be deployable both at traditional data centers but also follow network functions and applications when migrated to micro-data centers. Colocating OSS and VNF is essential when low latency is critical. For example, when the SDN controller needs an insight into the physical infrastructure topology, it should be able to quickly access the OSS inventory function, which can have the computing resources allocated at the same physical node where the SDN controller instance is ruing. In other words, OSS functions can be treated as part of the SDN controller and other VNF. This way the line between the network and the network management plane is blurring. OSS may also be reallocated within the network nodes and be colocated, with VNFs and applications to assure the correct level of responsiveness. OSS must therefore be deployable both at traditional data centers but also follow network functions and applications when migrated to microdata centers. 8 WHITE PAPER

9 SUMMARY From the customer perspective, NFV/SDN promises rapid introduction of compelling applications and providing better customer experience. These promises are founded on the disruptive potential of NFV/SDN to transform the network from just an access plane towards a real cloud-based platform for applications in the era of digital services. SDN is supposed to allow for the programing of virtual networks according to customer application needs, thus potentially opening up the network for software-based iovation. NFV enables iovation to be free from hardware limitations as it removes the constraints of dedicated hardware, while also enabling scaling-up and scaling-down networks by the dynamic allocation and deallocation of infrastructure resources. The latter is especially interesting, as it lets operators extend the cloud to the network edges this way the network nodes can become micro-data centers capable of hosting not only virtual network functions but also customer applications. This concept is all about bringing applications closer to the customer, thus providing better customer experience, especially for applications sensitive to latency problems. In mobile networks, this means that applications could literally follow the customer on the go. From the network management point of view, this transformation means that networks will become much more dynamic and adaptive to the needs of customer applications. The instantiation of network functions and the allocation of distributed infrastructure resources become dynamic, so the network topology can be shaped based on the current demand. To be able to assure that networks behave according to business needs, controlling via policies becomes a must. Moreover, policies must be defined in a hierarchical maer, reflecting different abstraction layers. It is essential to assure that low-level technical ones are driven by business, customer-oriented rules. To implement this concept, traditional BSS/OSS must be transformed into real-time systems. Catalog-driven fulfillment is one of the essential solutions that can be used to model customer services and the related policies, aligned with technical services and low-level policies. This way fulfillment systems can orchestrate an NFV/SDN-based network. WHITE PAPER 9

10 The role of network and service inventory is to manage the end-to-end dynamic view of the network, comprising physical infrastructure (including data centers and micro-data center topology) and the logical view including VNF chains. Together with the service assurance stack (the role of which is to provide real-time insight into the traffic, performance and quality of service), these systems are to assist the VNF and application placement algorithms. For SDN controllers, these systems can detect failures and trigger a re-routing algorithm to mitigate the service impact of any network issues. BSS/OSS has to meet stringent real-time requirements, be virtualized and deployable in the cloud. This means that BSS/ OSS should be scalable along with VNFs and applications leading to scenarios wherein BSS/OSS functions can be colocated together with VNFs (and customer applications) that they are to support. This concept means that the traditional separation of the network from the network management is blurring. In essence, BSS/OSS functions supporting VNFs in real-time, can be treated as part of VNF implementation or at least as its software components. In conclusion, the NFV/SDN technology promises to open up the way to a new era of more dynamic and customer application-shaped networks. RELATED MATERIALS White Paper: Software Defined Networking how BSS/OSS tools can help unleash iovation ABOUT COMARCH Comarch is a provider of complete IT solutions for telecoms. Since 1993 the company has helped CSPs on 4 continents optimize costs, increase business efficiency and transform BSS/OSS operations. Comarch solutions combine rich out-of-thebox functionalities with high configurability and are complemented with a wide range of services. The company s flexible approach to projects and a variety of deployment models help telecoms make networks smarter, improve customer experience and quickly launch digital services, such as cloud and M2M. This strategy has earned Comarch the trust and loyalty of its clients, including the world s leading CSPs: Vodafone, T-Mobile, Telefónica, E-Plus, KPN and MTS. Copyright Comarch All Rights Reserved telco-enquiries@comarch.com telecoms.comarch.com