4
© 2016 NetNumber, Inc. 1 Industry White Paper Associate Member Support of IPX routing for VoLTE roaming with the co-existence of distinct IMS voice roaming scenarios Summary IPX carriers encounter new operator-to-operator scenarios with VoLTE roaming as the existing solutions are only designed to deal with the VoLTE interworking scenarios between home networks. With VoLTE roaming scenarios, the IPX network must also route the traffic between visited network and home network of a roaming VoLTE user. To accomplish this additional task, the IPX carrier must retrieve the information about the source network (for a roaming calling user) and destination network (for a roaming called user) in a different way. A further complication is the co-existence of different incompatible IMS voice roaming scenarios. The issues with these scenarios are described in GSMA IR.65 but thus far standards are lacking that solve this problem. This paper introduces a solution based on NetNumber’s TITAN platform that can be simply added to an IPX network to address this VoLTE roaming case. The solution acts purely on the signaling control messages to perform an automated discovery between VoLTE interworking and VoLTE roaming signaling traffic. In case of roaming, it can identify the visited network and home network to provide operator policy and SLA enforcement. It can also distinguish between home routing or loopback roaming calls - and then route the call accordingly. This solution can co-exist with the existing solutions on TITAN to solve the other VoLTE routing particularities: Terminating Service Domain Selection (T-SDS) – provides a simple alternative to IMS Centralized Services (ICS) for the selective routing of terminating calls between IMS Core and Mobile CS. Selective Discovery Routing (SDR) – for VoLTE carrier interworking support and for optimized call routing of services like HD Voice. Challenges with IPX routing for VoLTE roaming To support VoLTE roaming, an IPX carrier needs to distinguish its traffic between VoLTE interworking and VoLTE roaming. This is because the same IPX carrier may be involved in one or several signaling legs of a certain VoLTE call. The following diagram shows the "basic" IMS routing option with the three call legs: 1. Mobile Originating (MO) – the call leg between the VPMN and the HPMN of the A-party 2. IMS Interworking (IWT) – the call leg between both HPMN’s here in this "basic" IMS routing option 3. Mobile Terminating (MT) – the call leg between the HPMN and the VPMN of the B-party. Originating Visited Network Roaming Transit Network Calling User Originating Home Network Terminating Visited Network Roaming Transit Network Called User Terminating Home Network Interworking Transit Network MO Leg MT Leg IWT Leg P-CSCF IPX Proxy S-CSCF P-CSCF IPX Proxy S-CSCF IPX Proxy 2 1 3

Support of IPX routing for VoLTE roaming with the co

  • Upload
    others

  • View
    8

  • Download
    0

Embed Size (px)

Citation preview

© 2016 NetNumber, Inc. 1

Industry White Paper Associate Member

Support of IPX routing for VoLTE roaming with the co-existence of distinct IMS voice roaming scenarios Summary IPX carriers encounter new operator-to-operator scenarios with VoLTE roaming as the existing solutions are only designed to deal with the VoLTE interworking scenarios between home networks. With VoLTE roaming scenarios, the IPX network must also route the traffic between visited network and home network of a roaming VoLTE user. To accomplish this additional task, the IPX carrier must retrieve the information about the source network (for a roaming calling user) and destination network (for a roaming called user) in a different way.

A further complication is the co-existence of different incompatible IMS voice roaming scenarios. The issues with these scenarios are described in GSMA IR.65 but thus far standards are lacking that solve this problem.

This paper introduces a solution based on NetNumber’s TITAN platform that can be simply added to an IPX network to address this VoLTE roaming case. The solution acts purely on the signaling control messages to perform an automated discovery between VoLTE interworking and VoLTE roaming signaling traffic. In case of roaming, it can identify the visited network and home network to provide operator policy and SLA enforcement. It can also distinguish between home routing or loopback roaming calls - and then route the call accordingly.

This solution can co-exist with the existing solutions on TITAN to solve the other VoLTE routing particularities: • Terminating Service Domain Selection (T-SDS) – provides a simple alternative to IMS Centralized

Services (ICS) for the selective routing of terminating calls between IMS Core and Mobile CS. • Selective Discovery Routing (SDR) – for VoLTE carrier interworking support and for optimized call

routing of services like HD Voice.

Challenges with IPX routing for VoLTE roaming To support VoLTE roaming, an IPX carrier needs to distinguish its traffic between VoLTE interworking and VoLTE roaming. This is because the same IPX carrier may be involved in one or several signaling legs of a certain VoLTE call. The following diagram shows the "basic" IMS routing option with the three call legs:

1. Mobile Originating (MO) – the call leg between the VPMN and the HPMN of the A-party 2. IMS Interworking (IWT) – the call leg between both HPMN’s here in this "basic" IMS routing option 3. Mobile Terminating (MT) – the call leg between the HPMN and the VPMN of the B-party.

Originating Visited Network

Roaming Transit Network

Calling User

Originating Home Network

Terminating Visited Network

Roaming Transit Network

Called User

Terminating Home NetworkInterworking Transit Network

MO Leg MT Leg

IWT Leg

P-CSCF

IPX Proxy

S-CSCF

P-CSCF

IPX Proxy

S-CSCFIPX

Proxy

2

1 3

© 2016 NetNumber, Inc. 2

Industry White Paper Associate Member

It is possible that a single IPX carrier is involved in all 3 call legs of a certain VoLTE call. Because the routing information is embedded in different signaling parameters for the different call legs, the IPX Proxy has to identify each call leg type, even if the same routing policy is applied for both roaming and interworking traffic.

The situation becomes more complex when different routing options apply to the same roaming call. Herewith a brief outline of the different IMS voice roaming scenarios (see for more details GSMA IR.65):

• Local Breakout VPMN Routing (LBO-VR) – The "basic" IMS routing or IMS roaming model without local breakout (LBO), where a call is routed from the HPMN of the A-party to the HPMN of the B-party.

• Local Breakout Home Routing (LBO-HR) – In the IMS roaming model with LBO, also called RAVEL, allows direct sending of the user plane traffic (voice, video, etc) the VPMN of A-party to the VPMN of the B-party similar as the current Mobile CS roaming routing principle. But as the IMS/VoLTE service are always provided in the HPMN, the signaling still has to be routed via the HPMN of the A-party.

• S8 Home Routing (S8HR) – In this scenario no IMS ICI signaling traffic is sent between HPMN and VPMN. The IMS Gm traffic is tunneled via the S8 interface to the P-CSCF in the HPMN and not routed via any SIP proxy in IPX networks. Therefore, this roaming option is not covered in this white paper.

The following picture shows the signaling traffic for the LBO-HR roaming scenario. This shows that after the services are provided in the HPMN of the A-party, the call is routed back to the VPMN of the A-party again to allow the local breakout with the three call legs:

1. Mobile Originating (MO) – the call leg between the VPMN and the HPMN of the A-party 2. Local Breakout (LB) – the call leg between the HPMN and the VPMN of the A-party 3. IMS Interworking (IWT) – the call leg between the VPMN of the A-party and the HPMN of the B-party 4. Mobile Terminating (MT) – the call leg between the HPMN and the VPMN of the B-party.

In addition to the signaling traffic for VoLTE roaming, there is also signaling to support the IMS registration procedure. The following picture shows the signaling flow for IMS authentication. A similar flow needs to be supported for the subscription of the registration event package.

Originating Visited Network

Roaming Transit Network

Calling User

Originating Home Network

Terminating Visited Network

Roaming Transit Network

Called User

Terminating Home Network

Interworking Transit Network

MO Leg

MT Leg

P-CSCF

IPX Proxy

S-CSCF

P-CSCF

IPX Proxy

S-CSCF

IPX Proxy

3

14IPX

Proxy

TRF

LB Leg

2

User Plane Traffic

© 2016 NetNumber, Inc. 3

Industry White Paper Associate Member

P-CSCF-vA1 IBCF-vA1 IC-A1 S-CSCF-

hA1UE-A

1. REGISTER

Home network hAVisited network vA

IBCF-hA1 I-CSCF-hA1

IC network A

2. REGISTER 3. REGISTER4. REGISTER 5. REGISTER

6. REGISTER

7. 4018. 4019. 401

10. 40111. 401

12. 401

13. REGISTER 14. REGISTER 15. REGISTER

16. REGISTER 17. REGISTER18. REGISTER

19. 20020. 20021. 200

22. 20023. 200

24. 200

NetNumber’s Centralized Routing Engine (CRE) solution The NetNumber CRE application on the TITAN platform is already widely deployed as central routing engine in leading TIER1 IPX carrier networks. For VoLTE roaming support the NetNumber CRE is able to make routing decisions according to the type of signaling traffic and IPX routing policies. This also applies if the IPX carrier is involved in more or all of the call legs as shown below.

Originating Visited Network

Roaming Transit Network

Calling User

Originating Home Network

Terminating Visited Network

Roaming Transit Network

Called User

Terminating Home NetworkInterworking Transit Network

MO Leg MT Leg

IWT Leg

P-CSCF

IPX Proxy

S-CSCF

P-CSCF

IPX Proxy

S-CSCFIPX

Proxy

CRE

NetNumber Centralized Routing Engine (CRE)

© 2016 NetNumber, Inc. 4

Industry White Paper Associate Member

The NetNumber CRE application on the TITAN platform consists of the following main functional components:

• Registration Support – Supporting the 3GPP standardized IMS registration procedure as SIP routing proxy within an IPX network between the VPMN and the VPMN of a VoLTE/IMS user. This includes both the support of the registration call flow and the routing of the IMS messages.

• Call Leg Type Specific Routing Support – The CRE is able to retrieve the information from different places, depending on the type of the call leg invoking the routing decision. This enables IPX carriers to support different IMS voice roaming scenarios and to resolve their incompatibilities.

• Simplified Traffic Management – The VoLTE roaming solution can co-exist with the NetNumber SDR solution for VoLTE interworking. A common routing policy for both scenarios may be applied to simplify traffic management.

• CDR Generation – When deployed in SIP Proxy mode, the CRE is able to generate CDRs according to IPX carrier definable fields and formats.

• Policy and SLA Enforcement – Policy and Service Level Agreement (SLA) can be configured in the CRE to enforce different kind of signaling policies like to limit the maximal number of incoming and/or outgoing calls from/to a certain MNO peer. Roaming policies can also be applied to check whether the VoLTE user of a certain MNO is allowed to roam to a certain visited network. Also routing policies can be conducted to ensure that only certain type of calls are routed by the CRE.

It should also be mentioned that the CRE provided by NetNumber confirms to applicable standards for VoLTE roaming such as but not limited to 3GPP TR 29.949 and GSMA IR.65.

About NetNumber NetNumber, Inc. brings 16 years of experience delivering innovative signaling control solutions that enable carriers to accelerate implementation of new services across multiple generations of networks, while dramatically simplifying the core network and reducing operating costs. Today, we are the leading provider of Centralized Signaling and Routing Control (CSRC) solutions to the global communications industry.

The carrier-grade TITAN platform is used by more than 150 customers globally. NetNumber delivers its TITAN solution directly to customers or as part of the solutions delivered by a growing number of industry partners. The approach depends per project, situation and on customer preference.

Please visit www.netnumber.com or contact your local account representative via [email protected]

Growing Industry Recognition NetNumber continues to be recognized for innovation and unique capabilities of its TITAN platform and applications. NetNumber has established multiple partnerships with other vendors for the delivery of TITAN as integral part of a partner solution.

April&2015“Cool%Vendor%in%CSP%Infrastructure%2015”

May&2015Finalist,&“Private%Company%of%the%Year”

February&2016Finalist,&“Best%Mobile%Technology”

May&2016&Award“One%to%Watch”

June&2016&Finalist,&“Best%Core%Network%Product”