As of November 2016, there are more than 530 networks across 180 countries with LTE networks in place, providing 4G data coverage to 58 percent of the world’s population. Voice, in the form of VoLTE, is following fast, with 86 networks in nearly 50 countries in production. VoLTE-capable handsets are proliferating, with over 220 devices now available.
However, your VoLTE subscribers want to continue to experience all of the benefits of VoLTE calling whether they are calling off-net or on-net. Features like fast call setup and guaranteed QoS end to end. Without VoLTE peering, these features are lost as soon as your subscribers make or receive calls to another network.
In addition, you’re missing out on all of the general benefits of IP interconnection if you use existing TDM interconnects, and this is especially inefficient where VoLTE calls are natively packet switched to begin with.
VoLTE peering is primarily about direct connections between VoLTE-enabled MNOs, as defined by GSMA specification IR.95. On paper, this should just be a case of having 3GPP-compliant interconnect devices delivering the I-BCF and TrGW functions. However, experience from around the globe has shown that this is not the case. VoLTE is complicated, and various proprietary simplifications, extensions and just differing specification interpretations mean most VoLTE networks are not directly interoperable. The GSMA is working to improve this situation by tightening up the IR.92 VoLTE standard in release 10, but it will take time for these extensions to be universally adopted.
Addressing these issues requires a range of function. Some of this is standard fare for today’s SBCs, things like message and SDP body manipulation, handling differences in early media expectations, transcoding and coping with different frameworks for signaling priority calls. Even so, the complexity and volume of interworking required and the constantly changing landscape as new endpoints or even just new firmware releases are introduced mean you need an SBC that both excels in delivering this function and makes it as straightforward as possible to understand the issues in real time and quickly address them without needing to wait for new software revisions.
One particular area of function that has been highlighted as a barrier for connectivity is SIP preconditions. These are mandatory for VoLTE calls, and are meant to be a backwards compatible part of the SIP protocol, so calls between VoLTE and non-VoLTE endpoints should succeed as well. The reality is that this is often untrue, leading to non-optimal call flows, or even total failure to connect. This is touched on only briefly in the standards documentation, but requires significant new function to be implemented in the SBC to deliver new state machines in the B2BUA to cope with the differing demands of each end of the call.
Perimeta can do all of this and more. Powerful message manipulation functionality coupled with Metaswitch’s unique Service Assurance Server mean you can see the protocol flows, even when they are encrypted, and quickly implement the adjustments needed to achieve and maintain your peering connections. It also includes the newly required function such as preconditions interworking and handling of new 3GPP headers. Successfully deployed today in live networks in exactly this VoLTE peering role, it is a proven best-of-breed solution.