Differences

This shows you the differences between two versions of the page.

--- ip_multimedia_subsystem [2014/11/14 11:34]
Martin Taylor [vSBC Testing]
+++ ip_multimedia_subsystem [2014/11/14 12:22] (current)
Martin Taylor [Subsequent Phases of vIMS Testing]
@@ Line 35: / Line 35: @@
 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.
-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 then answering 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.
+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.
@@ Line 49: / Line 51: @@
   * 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 (e.g.SIPp) may be deployed on COTS hardware to provide SIP traffic generation.
+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.
+===== Subsequent Phases of vIMS Testing =====
+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, the performance of OPNFV could be characterized in the context of vIMS in both control plane and user plane.
+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.

Wiki

User Tools

Site Tools

Differences

Page Tools