The IP Multimedia Subsystem is a standardized architecture for voice and video communications and messaging in both fixed and mobile networks. The architecture as a whole is described in http://www.3gpp.org/DynaReport/23228.htm. This architecture describes a large number of functional elements. In practical implementations, several IMS functions are often combined into single VNFs.

IMS makes use of three standardized protocols:

• SIP (Session Initiation Protocol) - used to set up and tear down voice and video calls, and to transport text messages
• Diameter - used for communication with back-end functions such as user authentication, billing and policy control
• RTP (Real-Time Protocol) - used to transport voice and video media streams

SIP and Diameter support the control plane for IMS, while RTP supports the user plane.

The key elements of IMS are as follows:

• IMS core (Call Session Control Function, Breakout Gateway Control Function) - performs user authentication and registration, routes SIP messages between and among all the other IMS elements
• Access Session Border Controller (Proxy Call Session Control Function, Access Transfer Control Function, Access Transfer Gateway) - provides the secure edge of the IMS network facing its users
• Interconnect Session Border Controller (Interconnect Border Control Function, Transit Gateway) - provides the secure edge of the IMS network facing other network operators
• AS (Application Server) - supports all application layer functions including telephony calling features, store-and-forward message delivery etc
• MRF (Media Resource Function) - provides certain media-related functions such as mixing media for multi-way calls
• HSS (Home Subscriber Server) - stores details of subscribers, including authentication credentials
• Billing (Charging Data Function) - collects charging events and creates Call Detail Records
• MGCF / MGW (Media Gateway Control Function / Media Gateway) - supports interconnect with TDM networks

A complete vIMS implementation requires the deployment of numerous different VNFs, and is therefore complex to achieve in practice. For the purposes of testing vIMS on OPNFV, it makes sense to focus first on those elements that are most performance-sensitive.

Most of the elements of IMS operate exclusively in the control plane. The only exceptions are the SBC functions and the Media Resource Function. The SBC functions are heavily loaded in the user plane since they are required to relay all of the media streams associated with calls established in the IMS domain. The MRF is relatively lightly loaded since it is only invoked in calls that require media processing such as multi-way calls.

Virtualized SBCs are known to apply heavy stress to the networking fabric of the underlying infrastructure. In the user plane, SBCs relay large numbers of RTP media streams, most of which comprise small packets containing audio payload. The capacity of a vSBC in terms of concurrent media sessions is therefore highly dependent on the ability of the virtualization infrastructure to handle the transport and switching of large numbers of small (~100 byte) packets.

By contrast, the control plane functions in an IMS network are not packet- or bandwidth-intensive. Their performance tends to be compute-limited, not network-limited, and they therefore do not tend to suffer performance degradation introduced by limitations in the network virtualization infrastructure.

It is therefore proposed that the first phase of OPNFV performance testing in the vIMS domain be focused on vSBC.

In this proposed first phase of vIMS testing, a single VNF comprising a virtualized session border controller is deployed on the OPNFV platform, with the aim of characterizing the performance impact of different approaches to network virtualization within the platform on the throughput of the vSBC.

It is worth noting that vSBC is unique among the set of proposed test cases for performance characterization of OPNFV in that its user plane function handles exclusively small packets. Other proposed test cases such as vEPC, vBRAS and vPE all handle a mix of small and large packets that is typical of broadband user traffic. With this type of traffic, a 1 Gbps load in the user plane will comprise of the order of 150k packets per second. Whereas with a vSBC performing relay of RTP streams carrying audio payload, a 1 Gbps load in the user plane will comprise of the order of 1.25M packets per second. The vSBC use case therefore puts particular emphasis on the effect of per-packet overheads in the network virtualization implementation within OPNFV. Real-world experience with virtualization of the SBC function suggests that this presents some significant challenges.

Load is applied to the vSBC with the aid of a SIP traffic generator. This simulates the effect of a large number of IMS endpoints establishing audio sessions. The traffic generator emulates both ends of a voice call by sending SIP INVITE requests towards the vSBC, and answering these call setup attempts with 200 OK responses. The traffic generator then sends bi-directional RTP streams via the vSBC to simulate the user plane load. The number of concurrent sessions is ramped up until an appreciable level of packet loss is experienced in the user plane. The number of concurrent sessions at which this occurs provides an indication of the maximum effective user plane throughput of the vSBC. While performing the test, latency and latency variation of RTP packet transmission should also be monitored to verify that they remain within acceptable limits.

The performance of the vSBC software should first be characterized on bare metal, to take the network virtualization element of the OPNFV platform out of the equation. The same compute node hardware as is used in the OPNFV platform should be used for this purpose.

The vSBC should then be deployed on the network virtualization solution to be tested in the OPNFV platform. This may be based on Open vSwitch (OVS) or some fork of OVS that incorporates data plane acceleration, for example by incorporating DPDK. It may be deemed useful to test the performance of the vSBC using hypervisor bypass techniques, for example Single Root I/O Virtualization (SR-IOV), for comparison purposes. It may also be deemed useful to test the performance of the vSBC on the OPNFV platform with commercial software solutions for data plane acceleration.

The vSBC implementation being proposed for this testing is the Perimeta SBC from Metaswitch Networks. Key points about this implementation:

• The software is mature and production quality. It is deployed in hundreds of networks today (on bare metal COTS x86 platforms).
• Its software data plane is highly optimized for x86 hardware, and leverages DPDK to deliver excellent performance on bare metal COTS without any hardware acceleration.
• Its implementation of SBC functionality is fully-featured and therefore provides a realistic view of the performance of a real-world VNF.
• It is available today packaged and supported as a VNF and is deployed as such in at least one production network.
• The software is available under a commercial license.

A SIP traffic generator is required to test vSBC performance. Commercial solutions are available from vendors such as Ixia and Spirent. Alternatively, a solution based on open source software (e.g.SIPp) may be deployed on COTS hardware.

As described above, the proposed vSBC test case is specifically intended to explore the performance of OPNFV in the IMS user plane. For a broader characterization of OPNFV in the context of vIMS, a more complete implementation of vIMS should be tested on OPNFV.

The vIMS test case can be progressively expanded by adding more and more of the distinct functions defined by the IMS architecture. A logical next step beyond vSBC testing would be to add a virtualized IMS core. The VNF implementation proposed for this purpose is Clearwater Core, an open source implementation of the IMS core functions from Metaswitch Networks. See http://www.projectclearwater.org/.

Clearwater is implemented with a scale-out architecture using stateless SIP processing elements allied with a distributed, scalable, fault-tolerant state store based on well-known open source elements. With Perimeta SBC providing a virtualized P-CSCF and Clearwater Core providing virtualized S-CSCF, I-CSCF, BGCF and (optionally) AS, all the key call processing functions of a vIMS could be tested. The same SIP traffic generation capabilities used to test vSBC would also be needed to test this more complete implementation of vIMS.

With this test setup, not only could the performance of OPNFV be characterized for IMS purposes in both control plane and user plane, but some other aspects of OPNFV functionality such as support for dynamic scale-out could be explored. Given that the current scope of OPNFV does not include the NFV Orchestrator function, it would not be possible to test automatic scale-out, but scale-out (and scale-in) functionality could be verified by means of manual operations invoked on the Virtual Infrastructure Manager (e.g. via the Horizon console of OpenStack).

An even more complete test of vIMS on OPNFV could be accomplished by adding further functional elements such as vHSS, vPCRF etc. Also, the vIMS could be layered on top of vEPC to enable the testing of a complete virtualized VoLTE solution.