Showing posts with label SDN / NFV. Show all posts
Showing posts with label SDN / NFV. Show all posts

Sunday 21 February 2016

Possible 5G Network Architecture Evolution


Came across this interesting Network Architecture evolution Roadmap by Netmanias. Its embedded below and available to download from the Netmanias website.



Saturday 30 January 2016

SDN & NFV lecture

I have been meaning to add this interesting lecture delivered by Dr. Yaakov Stein of RAD at IETF.

The video, which cannot be embedded, is available here. If you cant wait to get into the main presentation, jump to 19.40 on the time bar at the bottom.

The slides from the presentation are embedded below.



Assuming that you understand NFV and SDN well, have a look at another interesting whitepaper that was published by Signals Research group, "Bending Iron – Software Defined Networks & Virtualization for the Mobile Operator", available here.

Saturday 28 November 2015

5G, NFV and Network Slicing


5G networks have multifaceted requirements where the network needs to be optimised for data rate, delay and connection numbers. While some industry analysts suspect that these requirements cannot be met by a single network, vendors suggest that Network Slicing will allow all these requirements to be met by a single network.

Ericsson's whitepaper provides a good definition of what network slicing means:

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.
...
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-tomachine (M2M) solutions, it is likely that it would also cover the Mobile Management Entities (MMEs) and Serving Gateways (SGWs).


NGMN came out with the 5G whitepaper which touched on this subject too: 

Figure above illustrates an example of multiple 5G slices concurrently operated on the same infrastructure. For example, a 5G slice for typical smartphone use can be realized by setting fully-fledged functions distributed across the network. Security, reliability and latency will be critical for a 5G slice supporting automotive use case. For such a slice, all the necessary (and potentially dedicated) functions can be instantiated at the cloud edge node, including the necessary vertical application due to latency constraints. To allow on-boarding of such a vertical application on a cloud node, sufficient open interfaces should be defined. For a 5G slice supporting massive machine type devices (e.g., sensors), some basic C-plane functions can be configured, omitting e.g., any mobility functions, with contentionbased resources for the access. There could be other dedicated slices operating in parallel, as well as a generic slice providing basic best-effort connectivity, to cope with unknown use cases and traffic. Irrespective of the slices to be supported by the network, the 5G network should contain functionality that ensures controlled and secure operation of the network end-to-end and at any circumstance.


Netmanias has a detailed article on this topic which is quite interesting too, its available here.

Recently, South Korean operator SK Telecom and Ericsson concluded a successful trial of this technology, see here. Ericsson is also working with NTT Docomo on 5G including network slicing, see here.

Sunday 15 February 2015

5G and NFV


In my 5G: A 2020 vision presentation, I argued that some of the technologies that will be necessary for 5G is in fact independent of 5G. One such technology is NFV. Having said that, I also argue that the minimum prototype for 5G would require an NFV based implementation.


Tieto gave an interesting presentation in our last Small Cell SIG event explaining how the network will be implemented based on NFV. The presentation is embedded below:



There is also an interesting paper that expands on this further, available from Slideshare here.

Monday 1 December 2014

Bringing Network Function Virtualization (NFV) to LTE

SDN and NFV have gained immense popularity recently. Not only are they considered important for reducing the Capex and Opex but are being touted as an important cog in the 4.5G/5G network. See here for instance.


I introduced NFV to the blog nearly a year back here. ETSI had just published their first specs around then. When I talked about SDN/NFV back in May, these ETSI standards were evolving into a significant reference documents. This is a reason 4G Americas recently published this whitepaper (embedded below), for the operators to start migrating to NFV architecture to reap long term benefits. The following is from the whitepaper:

The strategies and solutions explored in the 4G Americas report on NFV aim to address these issues and others by leveraging IT virtualization technology to consolidate many network equipment types onto industry standard high volume servers, networking and storage. NFV is about separating network functions from proprietary hardware and then consolidating and running those functions as virtualized applications on a commodity server. Broadly speaking, NFV will enable carriers to virtualize network functions and run them as software applications within their networks. NFV focuses on virtualizing network functions such as firewalls, Wide-Area Network (WAN) acceleration, network routers, border controllers (used in Voice over IP (VoIP) networks), Content Delivery Networks (CDNs) and other specialized network applications. NFV is applicable to a wide variety of networking functions in both fixed and mobile networks.
“NFV is making great progress throughout the world as operators work with their vendor partners to address the opportunities of increasing efficiency within their network infrastructure elements,” stated Chris Pearson, President of 4G Americas. “There is a great deal of collaborative innovation and cooperation between wireless carriers, IT vendors, networking companies and wireless infrastructure vendors making NFV for LTE possible.”
Global communication service providers, along with many leading vendors, are participating in the European Telecommunications Standards Institute’s (ETSI) Industry Specification Group for Network Functions Virtualization (NFV ISG) to address challenges such as:
  • An increasing variety of proprietary hardware appliances like routers, firewalls and switches
  • Space and power to accommodate these appliances
  • Capital investment challenges
  • Short lifespan
  • A long procure-design-integrate-deploy lifecycle
  • Increasing complexity and diversity of network traffic
  • Network capacity limitations
Three main benefits of NFV outlined in the 4G Americas paper include:
  • Improved capital efficiency: Provisioning capacity for all functions versus each individual function, providing more granular capacity, exploiting the larger economies of scale associated with Commercial Off-the-Shelf (COTS) hardware, centralizing Virtual Network Functions (VNFs) in data centers where latency requirements allow, and separately and dynamically scaling VNFs residing in the user (or data or forwarding) plane designed for execution in the cloud, control and user-plane functions as needed.
  • Operational efficiencies: Deploying VNFs as software using cloud management techniques which enables scalable automation at the click of an operator’s (or customer’s) mouse or in response to stimulus from network analytics. The ability to automate onboarding, provisioning and in-service activation of new virtualized network functions can yield significant savings. 
  • Service agility, innovation and differentiation: In deploying these new VNFs, time-to-market for new network services can be significantly reduced, increasing the operator’s ability to capture market share and develop market-differentiating services.
In particular, mobile operators can take advantage of NFV as new services are introduced. Evolved Packet Core (EPC), Voice over LTE (VoLTE), IP Multimedia System (IMS) and enhanced messaging services, among others, are examples of opportunities to use virtualized solutions. Some operators started deploying elements of NFV in 2013 with an expectation that many service areas could be mostly virtualized in the next decade.

The whitepaper as follows:


Sunday 21 September 2014

NFV and 5G compatibility issues

There was an interesting discussion on Twitter that has been storified by Keith Dyer. Lets start by having a quick look at the C-RAN architecture that features in the discussion.


There are couple of excellent C-RAN presentations for anyone interested. This one by EE (with 9K+ views) and this from Orange (with 19K+ views).

Anyway, here is the story:


For anyone interested in exploring the discussion further, The Mobile Network has a more detailed comments here.

There are also an interesting article worth reading:

Saturday 17 May 2014

NFV and SDN - Evolution Themes and Timelines


We recently held our first Virtual Networks SIG event in Cambridge Wireless. There were some great presentations. The one by the UK operator EE summarised everything quite well. For those who are not familiar with what NFV and SDN is, I would recommend watching the video on my earlier post here.

One of the term that keeps being thrown around is 'Orchestration'. While I think I understand what it means, there is no easy way to explain it. Here are some things I found on the web that may explain it:
Orchestration means Automation, Provisioning, Coordination and Management of Physical and Virtual resources.  
Intelligent service orchestration primarily involves the principles of SDN whereby switches, routers and applications at Layer 7 can be programmed from a centralized component called the controller with intelligent decisions regarding individual flow routing in real time.
If you can provide a better definition, please do so.
There are quite a few functions and services that can be virtualised and there are some ambitious timelines.

ETSI has been working on NFV and as I recently found out (see tweet below) there may be some 3GPP standardisation activity starting soon.
Anyway, here is the complete presentation by EE:



There was another brilliant presentation by Huawei but the substance was more in the talk, rather than the slides. The slides are here in case you want to see and download.

Related post:



Tuesday 15 October 2013

What is Network Function Virtualisation (NFV)?


Software Defined Networking (SDN) and Network Function Virtualization (NFV) are the two recent buzzwords taking the telecoms market by storm. Every network vendor now has some kind of strategy to use this NFV and SDN to help operators save money. So what exactly is NFV? I found a good simple video by Spirent that explains this well. Here it is:


To add a description to this, I would borrow an explanation and a very good example from Wendy Zajack, Director Product Communications, Alcatel-Lucent in ALU blog:

Let’s take this virtualization concept to a network environment. For me cloud means I can get my stuff where ever I am and on any device –  meaning I can pull out my smart phone, my iPad, my computer – and show my mom the  latest pictures of  her grand kids.  I am not limited to only having one type of photo album I put my photos in – and only that. I can also show her both photos and videos together – and am not just limited to showing her the kids in one format and on one device.
Today in a telecom network is a lot of equipment that can only do one thing.  These machines are focused on what they are do and they do it really well – this is why telecom providers are considered so ‘trusted.’ Back in the days of landline phones even when the power was out you could always make a call.  These machines run alone with dedicated resources.  These machines are made by various different vendors and speak various languages or ‘protocols’ to exchange information with each other when necessary. Some don’t even talk at all – they are just set-up and then left to run.  So, every day your operator is running a mini United Nations and corralling that to get you to access all of your stuff.  But it is a United Nations with a fixed number of seats, and with only a specific nation allowed to occupy a specific seat, with the seat left unused if there was a no-show. That is a lot of underutilized equipment that is tough and expensive to manage.  It also has a shelf life of 15 years… while your average store-bought computer is doubling in speed every 18 months.
Virtualizing the network means the ability to run a variety of applications (or functions) on a standard piece of computing equipment, rather than on dedicated, specialized processors and equipment, to drive lower costs (more value), more re-use of the equipment between applications (more sharing), and a greater ability to change what is using the equipment to meet the changing user needs (more responsiveness).  This has already started in enterprises as a way to control IT costs and improve the performance and of course way greener.
To give this a sports analogy – imagine if in American football instead of having specialists in all the different positions (QB, LB, RB, etc), you had a bunch of generalists who could play any position – you might only need a 22 or 33 man squad (2 or 3 players for every position) rather than the normal squad of  53.   The management of your team would be much simpler as ‘one player fits all’ positions.   It is easy to see how this would benefit a service provider – simplifying the procurement and management of the network elements (team) and giving them the ability to do more, with less.

Dimitris Mavrakis from Informa wrote an excellent summary from the IIR SDN and NFV conference in Informa blog here. Its worth reading his article but I want to highlight one section that shows how the operators think deployment would be done:

The speaker from BT provided a good roadmap for implementing SDN and NFV:
  1. Start with a small part of the network, which may not be critical for the operation of the whole. Perhaps introduce incremental capacity upgrades or improvements in specific and isolated parts of the network.
  2. Integrate with existing OSS/BSS and other parts of the network.
  3. Plan a larger-scale rollout so that it fits with the longer-term network strategy.
Deutsche Telecom is now considered to be deploying in the first phase, with a small trial in Hrvatski Telecom, its Croatian subsidiary, called Project Terrastream. BT, Telefonica, NTT Communications and other operators are at a similar stage, although DT is considered the first to deploy SDN and NFV for commercial network services beyond the data center.
Stage 2 in the roadmap is a far more complicated task. Integrating with existing components that may perform the same function but are not virtualized requires east-west APIs that are not clearly defined, especially when a network is multivendor. This is a very active point of discussion, but it remains to be seen whether Tier-1 vendors will be willing to openly integrate with their peers and even smaller, specialist vendors. OSS/BSS is also a major challenge, where multivendor networks are controlled by multiple systems and introducing a new service may require risking several parameters in many of these OSS/BSS consoles. This is another area that is not likely to change rapidly but rather in small, incremental steps.
The final stage is perhaps the biggest barrier due to the financial commitment and resources required. Long-term strategy may translate to five or even 10 years ahead – when networks are fully virtualized – and the economic environment may not allow such bold investments. Moreover, it is not clear if SDN and NFV guarantee new services and revenues outside the data center or operator cloud. If they do not, both technologies – and similar IT concepts – are likely to be deployed incrementally and replace equipment that reaches end-of-life. Cost savings in the network currently do not justify forklift upgrades or the replacement of adequately functional network components.
There is also a growing realization that bare-metal platforms (i.e., the proprietary hardware-based platforms that power today’s networks) are here to stay for several years. This hardware has been customized and adapted for use in telecom networks, allowing high performance for radio, core, transport, fixed and optical networks. Replacing these high-capacity components with virtualized ones is likely to affect performance significantly and operators are certainly not willing to take the risk of disrupting the operation of their network.
A major theme at the conference was that proprietary platforms (particularly ATCA) will be replaced by common off-the-shelf (COTS) hardware. ATCA is a hardware platform designed specifically for telecoms, but several vendors have adapted the platform to their own cause, creating fragmentation, incompatibility and vendor lock-in. Although ATCA is in theory telecoms-specific COTS, proprietary extensions have forced operators to turn to COTS, which is now driven by IT vendors, including Intel, HP, IBM, Dell and others.


ETSI has just published first specifications on NFV. Their press release here says:

ETSI has published the first five specifications on Network Functions Virtualisation (NFV). This is a major milestone towards the use of NFV to simplify the roll-out of new network services, reduce deployment and operational costs and encourage innovation.
These documents clearly identify an agreed framework and terminology for NFV which will help the industry to channel its efforts towards fully interoperable NFV solutions. This in turn will make it easier for network operators and NFV solutions providers to work together and will facilitate global economies of scale.
The IT and Network industries are collaborating in ETSI's Industry Specification Group for Network Functions Virtualisation (NFV ISG) to achieve a consistent approach and common architecture for the hardware and software infrastructure needed to support virtualised network functions. Early NFV deployments are already underway and are expected to accelerate during 2014-15. These new specifications have been produced in less than 10 months to satisfy the high industry demand – NFV ISG only began work in January 2013.
NFV ISG was initiated by the world's leading telecoms network operators. The work has attracted broad industry support and participation has risen rapidly to over 150 companies of all sizes from all over the world, including network operators, telecommunication equipment vendors, IT vendors and technology providers. Like all ETSI standards, these NFV specifications have been agreed by a consensus of all those involved.
The five published documents (which are publicly available via www.etsi.org/nfv) include four ETSI Group Specifications (GSs) designed to align understanding about NFV across the industry. They cover NFV use cases, requirements, the architectural framework, and terminology. The fifth GS defines a framework for co-ordinating and promoting public demonstrations of Proof of Concept (PoC) platforms illustrating key aspects of NFV. Its objective is to encourage the development of an open ecosystem by integrating components from different players.
Work is continuing in NFV ISG to develop further guidance to industry, and more detailed specifications are scheduled for 2014. In addition, to avoid the duplication of effort and to minimise fragmentation amongst multiple standards development organisations, NFV ISG is undertaking a gap analysis to identify what additional work needs to be done, and which bodies are best placed to do it.
The ETSI specifications are available at: http://www.etsi.org/technologies-clusters/technologies/nfv

The first document that shows various use cases is embedded below: