Katrina Cashman Sr. Director Product Management Roaming Line of Business

1

Key Decision Areas to Implement LTE Roaming

Addressing LTE Roaming Challenges - How It Impacts Your Business Operations

IPX and Diameter

Roaming agreements and launch letters

RAEX/IOTs

Impact on Clearing and Settlement

Charging Principles and Impact on Wholesale Charging

Impact on fraud-related issues and NRTRDE in LTE

Impact on roaming VAS (steering, WSMS, VHE, etc.)

Testing LTE roaming

Support for sponsored roaming

Impact on roaming hubbing

Role of IPX in LTE Interworking and Roaming

3

IPX The Focal Point in LTE

Today GRX supports GRPS, EDGE, 3G, HSPA data roaming and MMS interworking

No inherent support for LTE or IMS

Only specified for use by mobile network operators

No required support for QoS

Developed by GSMA to foster open standardized IP connectivity for multiple types of service providers

Provides for end-to-end QoS in support of both roaming and interworking for LTE and IMS

Fully backward compatible with GRX networks

Used by MNOs, FNOs, ISPs and ASPs

Pivotal point of the whole LTE ecosystem

Use of Diameter in LTE

Todays 2G/3G networks use SS7-MAP protocol for location / subscriber / access / handover / authentication / security / identity management & handover services

However, in LTE/SAE (3GPP Rel. 8), Diameter protocol has been chosen for many of these procedures and is increasingly used for inter-operator signalling network and roaming infrastructure

In LTE environment, registration messages received would be based on Diameter (rather than SS7-MAP)

Diameter Base Protocol is defined within IETF RFC 3588 (published in September 2003)

Based on Diameter Base Protocol, 3GPP (like IETF) has also defined some specific Diameter applications to support more specific requirements in different scenarios

Diameter Agents

Diameter protocol introduces notions of Diameter agents

Relay agents: accept requests and route messages to other Diameter nodes based on routing decision performed using list of supported realms, and associated known peers

Advertise "Relay Application Identifier" in CER/CEA

Proxy agents: relay function + message modification to implement policy enforcement

Advertise supported Diameter applications in CER/CEA

Redirect agents: return information necessary for Diameter agents to communicate directly with another Diameter node

Advertise "Relay Application Identifier" in CER/CEA

Translation agents: provides translation between two protocols (e.g., RADIUSDiameter)

Advertise supported Diameter applications in CER/CEA

Diameter implementation may act as one type of agent for some requests, and as another type of agent for others

Handling of Diameter in IPX

Assumes both operators have Diameter relays

HPMN and VPMN exchange messages via Syniverse Diameter proxy

PCRF P-GW

PLMN-A

S-GW eNodeB

e-UTRAN

HSS

EPC

Gx

S1-U

S1-MME S11

S6a

S6a

IPX

Internet

MME

PCRF P-GW

PLMN

S-GW

HSS

EPC

Gx

S1-U

S1-MME S11

S6a

S5

S8

S5

S1-U

eNodeB

e-UTRAN

Internet

SGi SGi

Diameter Relay

S6a

S6a

S6a

Diameter Relay

Syniverse Diameter

Proxy

MME

Impact of LTE on Business Decisions and Processes

8

Roaming Agreements

AA.12 and AA.13 (standard roaming agreement templates) were updated in 2003 to be technology-neutral

No updates required for LTE

Many roaming agreements signed before 2003, so may need to be updated

GSMA will not provide help for old agreements

Many will already have been updated for other reasons like 3G, NRTRDE, etc., so not a big problem

Specific LTE launch letter (like for 3G)

LTE Data

LTE Voice

LTE SMS

Future services will be added at later stage

CONFIRMATION OF EFFECTIVE STARTING DATE FOR LTE ROAMING AGREEMENT

This is to confirm that on the [DATE],

[PARTNER A] [PLMN A],

and

[PARTNER B] [PLMN B]

agree to extend the commercial roaming service to LTE roaming on a [unilateral] / [bilateral] basis. The launch follows the successful completion of the applicable IREG and TADIG tests.

[This is a unilateral launch for the customers of [PARTNER A] as HPMN roaming on the network of [PARTNER B] as VPMN]

[Partner A] shall support over its LTE network the following services for Customers of [Partner B] (Delete what is not available):

- LTE as such (i.e. as radio / bearer technology)

- VoLTE based Voice i.e. Voice over LTE implemented in line with the GSMA defined VoLTE architecture

- VoLTE based SMS i.e. SMS over LTE implemented in line with the GSMA defined VoLTE architecture

[Partner B] shall support over its LTE network the following services for Customers of [Partner A] (Delete what is not available):

- LTE as such (i.e. as radio / bearer technology)

- VoLTE based Voice i.e. Voice over LTE implemented in line with the GSMA defined VoLTE architecture

- VoLTE based SMS i.e. SMS over LTE implemented in line with the GSMA defined VoLTE architecture

The commercial service is in accordance with the conditions set out in the International Roaming Agreement as signed by both Parties.

Date: Date:

Place: Place:

Commercial Launch Letter for LTE

AA.14 / RAEX IOT and Op Data

For next RAEX release, AA.14 will be split in two separate parts:

RAEX IOT: Annex I.3.1 improved version of IOT we have today

RAEX Op Data: rest of AA.14 without IOT

Mainly because IOT has strict rules for how to exchange it and operational data (contacts, network details, etc.) does not

Business process defined in BA.29 (IOT) and BA.19 (Op Data)

Multiple IOT support

Individual IOTs per roaming partner, or per group of roaming partners

RH support for RAEX

Outbound call correction

3G/LTE indicators

Technical specifications defined in TD.67 (IOT) and TD.77 (Op Data)

RAEX IOT and Op Data Implementation

New earliest implementation date October 2013

Implementation window: October 2013 to March 2014

AA.14 issued within this period, must follow the new format

GSMA will provide a central RAEX application

Handles creation and distribution of RAEX IOT and Op Data files, but recipient will have no advanced search functionality

Recipient can download in RAEX or PDF format

Sender and Recipient can put their agents (DCH, FCH, etc) on copy

RAEX IR.21/IR.85

RAEX IR.21 and RAEX IR.85 (IR.21 for roaming hubbing) updated to support data over LTE, including multiple PDP contexts

GSMA provides a central application to support upload, storage and creation of RAEX IR.21s

RAEX IR.21 updated to support VoLTE

New network nodes (IMS core) and their IP addresses (i.e., MME, SGW, PGW, HSS, PCRF, etc.)

Mechanism for SMS delivery (i.e., SMSoIP, SMSoSGs)

VoLTE support for CSFB

Service awareness and LBO not yet supported

Impact on Clearing and Settlement

As TAP is being used for LTE also, there is minimum impact on existing data clearing, invoicing, financial clearing and settlement processes

DCHs will continue to send RTDR to FCHs

FCHs will work exactly like today using RTDR as input from DCHs

Invoices continue to be based on TAP files

Additional reports on LTE usage to be defined

Both TAP and RTDR (Roaming Traffic Data Report) have been updated for LTE

Support for data over LTE from 2010

Support for VoLTE from 1 May 2012

TAP for Data Over LTE

For data over LTE, possible for VPMN to use call records from SGSN and SGW for home-routed access (like today for GPRS/3GPS) and additionally from PGW for local-breakout

New recording entity type codes/types for 7:P-GW and 8:S-GW

New Cause for termination value added

TAP3.11 implemented May 1, 2010

Supported from TAP3.11

TAP for Voice over LTE

TAP support for LTE/IMS (TAP3.12)

First 2 IMS services: Voice and SMS = VoLTE

Two new TAP records for VoLTE

Messaging event, SMS-MO and SMS-MT over LTE

Mobile session, originating and terminating VoLTE

Both records have service parameter to future proof for new messaging and call/session type services implemented on IMS

Future IMS-based messaging services will use the same TAP record

MMS and email are generally not IMS-based, but likely could be used

Minimum impact on operators not implementing VoLTE from day 1

Can implement TAP3.12 initially without VoLTE support

New TAP fields in two new records

New type of roamer: Public User ID (user@domain)

New type of destination: Non-charged Public User ID (user@domain)

New Recording Entity Code/Type: 9:P-CSCF

TAP Challenges for VoLTE

No single network element will contain all charging elements

No direct equivalent in VoLTE for visited MSC in CS

Correlation of data from SGSN/S-GW/P-CSCF CDRs via common Charging ID

Not a standard scenario today, except for combination of partial records

Some learning curve anticipated

Charging ID available from P-CSCF to identify each unique call

Also available from S-CSCF in home network

Event reference in TAP

Not all usual TAP information readily available

Wholesale Charging Principles

Charging for data over LTE is the same as charging for data over 2G/3G, potentially based on QoS

Some operators are talking about having a differentiate charge for LTE data

For voice over LTE, operators will (at least initially) maintain the legacy voice roaming charging and termination principles

Charging Principles in LTE

Address all possible scenarios

Origination and termination

Home routing and local breakout

IMS and non-IMS

Voice w/ CSFB and Voice w/ VoLTE

Types of billing/accounting records

Bearer Accounting records

TAP Billing records

IMS Accounting records

Identify all possible sources for CDRs in HPMN and VPMN and how retail billing and wholesale charging will be accomplished

Define how OCS and OFCS charging interfaces will be used for all scenarios

Implement LTE support already defined for TAP in 3.11 and new record types for VoLTE in TAP 3.12 approved in May2011 (implementation May 2012)

Impact on Wholesale Charging

Key VoLTE assumptions

VoLTE = Voice and SMS over LTE, implemented by IMS over LTE core network

Voice call routing for VoLTE when call originator is roaming shall be at least as optimal as that of current CS domain local (VPMN) breakout

Voice bearer path for a VoLTE call shall be routed from visited network of roaming call originator to terminating network

CS charging model for roaming shall be maintained in VoLTE

GSMA view: commercial principles should be technology neutral (compared to previously defined principles for 3G voice, 2G voice, SMS over GPRS)

VoLTE service invocation should be subject to normal IOT for Voice and SMS

Single IOT for Voice/SMS

Potential differences in QoS for further study

Bearer usage is mere enabler for service

Charge only for service and not for service+bearer (may not be straightforward)

Impact on Fraud-Related Issues and NRTRDE

TD.35 (NRTRDE specification) updated to support data over LTE (since 1 Oct 2010)

Like TAP, only minor, primarily editorial, changes required to support new network elements (S-GW, P-GW) and new Cause for termination value

GPRS not mandatory in NRTRDE

Fraud Forum not pursuing NRTRDE updates for VoLTE

Private User ID available in S-CSCF CDRs

Private User ID available on HSS-SCSCF Cx interface

HPMN can determine IMSI from Private User ID

Both partial and complete records can be sent to HPMN

Could be changed, pending current Fraud Forum discussion

Impact on Roaming VAS (SoR, WSMS, VHE, etc.)

Many value-added services (VAS) exist today

Traditionally based and relying on SS7 signaling procedures

In LTE, S6a, S6d, S13 and S13' interfaces replace legacy Gr, Gf, D interfaces

S6a, S6d, S13, S13 interfaces are based on diameter

VAS ecosystem needs to evolve

Flexible to support multiple services, protocols and scenarios

CSFB may impact VAS (i.e. WSMS, SoR)

Diameter / MAP interworking may be needed

Testing LTE Roaming

New LTE-provisioned SIM cards need to be exchanged

Operators expected to test LTE, also for existing roaming agreements

IR.35 and TD.47 (GPRS testing) updated to support data over LTE

New roaming scenarios

LTE-to-LTE

LTE-to-2G/3G

3 new test cases added

LTE Attach and Detach

LTE Cancel Location

LTE Operator Determined Barring

Test cases for VoLTE being defined

IREG VOLTER subgroup creating IR.25

TADIG TDS will produce a new TD PRD

Key Takeaways

Define your LTE strategy

Analyze and mitigate impacts

Consider both roaming and interworking environments

Evaluate technical, business, commercial and operational aspects

Integrate solutions across multiple technologies ensures end user QoE and simplifies operations and support

Ensure seamless 4G evolution and enable real-time engagement for your customers

Thank You! Katrina Cashman

Sr. Director Product Management katrina.cashman@syniverse.com

+1.813.637.5974