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.
Your VoLTE subscribers want to continue to experience all of the benefits of VoLTE calling, like fast call setup and guaranteed QoS end-to-end, whether they are calling on-net or off-net. Without VoLTE peering, these features are lost as soon as your subscribers make or receive calls to or from another network.
In addition, if you use existing TDM interconnects, you will miss out on all of the general benefits of IP interconnection and this is especially inefficient when 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.
To protect and increase the revenue from all of your VoLTE network, you need to let your users roam onto other VoLTE networks, and you need to let other users roam onto yours. However, to date, there have been only seven unilateral and two bilateral VoLTE roaming agreements announced. This is testament to the fact that this is a confusing space, with three different models for supporting roaming defined in the standards.
These three models are:
Currently, all live roaming agreements use the S8HR option for simplicity. However, it is expected that the LBO options will be used by the great majority of operators because they do not suffer from the limitations faced by S8HR in areas like lawful intercept, emergency calling and eSRVCC handovers.
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.
No matter which vendor you have selected for your mobile IMS core, you can confidently select Perimeta from Metaswitch for your VoLTE roaming requirements. With all three roaming models supported, plus a wealth of additional interoperability features developed to respond to real-world issues not covered by standards, Perimeta will allow you to implement whichever roaming model you choose, even supporting different models for different roaming partners.
As the proven leader in cloud-native SBCs, Perimeta will also get you there fast, allowing you to turn up new roaming interconnects in days not months, and to locate that SBC resource in the most efficient location for you. Supporting both VMware and OpenStack, or even bare metal COTS servers if desired, and a range of different functional splits, Perimeta offers market-leading deployment flexibility.
The network-wide licensing model ensures your license usage is as optimal as your physical resource usage, automatically adjusting to changes in calling patterns as your roaming agreements evolve.
So, whether you are a mobile network operator looking to extend your existing VoLTE network with peering or roaming support, or are just planning your VoLTE deployment, or even if you are an IPX carrier seeking to ensure you are able to support all of the VoLTE roaming models set in the standards, then Perimeta is the best-of-breed choice in today’s communications world.