Six Network Elements Ripe for NFV

Network function virtualization (NFV) is the it-phrase of the moment. The telco market is abuzz with speculation about how the rapid spread of NFV will cut costs, increase flexibility and scalability, and speed time to market for new services. But which functions are best suited for an NFV makeover? Anything that doesn’t need a physical connection or where the physical connection can be somewhere else is a prime candidate for NFV.

1. Routers: Once the media or signaling comes into the IP network via the IP phy, then the stream is simply on the IP network and can be affected by some network infrastructure, whatever that may be. So, one of the network nodes or network infrastructure elements that best lends itself to NFV is a router; there is no reason this has to be in a box.

2. Session Border Controllers (SBCs): Like routers, SBCs also work in IP networks and can make a relatively easy transition to NFV.

3. Media servers: There are remote APIs such as MxML that enable dis-aggregation of the media server from the application or application server. And working on the media – via transcoding, conferencing, or speech recognition – can certainly happen in software.

4. Softswitches: These include software by definition and can also be run on software alone. Typically, a softswitch talks to the TDM networks with a sister VoIP gateway. But the softswitch core functions such as routing and policy are software that can run in an NFV environment.

5. Signaling nodes: Diameter routing agents (DRA) or Diameter interworking function (IWF) can be software, as these Diameter signaling controller products translate protocol to protocol or load balance the signaling. Again, to get to a TDM network, a signaling gateway would be required, but the core signaling translation and signaling aggregation can be done via NFV. Finally, elements that are found in IMS networks such as P-CSCF or MRF that don’t need to touch TDM networks can be virtualized.

6. Deep packet inspection (DPI) or WAN acceleration – maybe: These functions could also lend themselves to NFV, just based on the definition of NFV enabling elements that work in IP environments. While it’s clearly possible for these nodes to be virtualized, especially in lower scale requirements, this is the kind of solution that may still need hardware to enable speed and scalability.

NFV will help telcos transition their network functions to software-centric applications that run on commercial off-the-shelf (COTS) hardware, and it will allow multiple network functions to run in a single chassis. While NFV is still evolving, it’s future is the future of telecommunications – and we’re sure to see more of it before long.

Network function virtualization (NFV) is the it-phrase of the moment. The telco market is abuzz with speculation about how the rapid spread of NFV will cut costs, increase flexibility and scalability, and speed time to market for new services. But which functions are best suited for an NFV makeover? Anything that doesn’t need a physical connection or where the physical connection can be somewhere else is a prime candidate for NFV.

1. Routers: Once the media or signaling comes into the IP network via the IP phy, then the stream is simply on the IP network and can be affected by some network infrastructure, whatever that may be. So, one of the network nodes or network infrastructure elements that best lends itself to NFV is a router; there is no reason this has to be in a box.

2. Session Border Controllers (SBCs): Like routers, SBCs also work in IP networks and can make a relatively easy transition to NFV.

3. Media servers: There are remote APIs such as MxML that enable dis-aggregation of the media server from the application or application server. And working on the media – via transcoding, conferencing, or speech recognition – can certainly happen in software.

4. Softswitches: These include software by definition and can also be run on software alone. Typically, a softswitch talks to the TDM networks with a sister VoIP gateway. But the softswitch core functions such as routing and policy are software that can run in an NFV environment.

5. Signaling nodes: Diameter routing agents (DRA) or Diameter interworking function (IWF) can be software, as these Diameter signaling controller products translate protocol to protocol or load balance the signaling. Again, to get to a TDM network, a signaling gateway would be required, but the core signaling translation and signaling aggregation can be done via NFV. Finally, elements that are found in IMS networks such as P-CSCF or MRF that don’t need to touch TDM networks can be virtualized.

6. Deep packet inspection (DPI) or WAN acceleration – maybe: These functions could also lend themselves to NFV, just based on the definition of NFV enabling elements that work in IP environments. While it’s clearly possible for these nodes to be virtualized, especially in lower scale requirements, this is the kind of solution that may still need hardware to enable speed and scalability.

\n

NFV will help telcos transition their network functions to software-centric applications that run on commercial off-the-shelf (COTS) hardware, and it will allow multiple network functions to run in a single chassis. While NFV is still evolving, it’s future is the future of telecommunications – and we’re sure to see more of it before long.