Key Decision Areas to

Implement LTE Roaming

Katrina Cashman
Sr. Director Product Management
Roaming Line of Business

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

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., RADIUS<>Diameter)
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

EPC

Assumes both operators have Diameter

relays

S6a

MME

HSS

S1-MME

e-UTRAN
eNodeB

HPMN and VPMN exchange messages via

Syniverse Diameter proxy

S11

S-GW

S1-U

S6a
Diameter
Relay

S5

PCRF

Gx

P-GW

PLMN-A
S6a

SGi

Internet

Internet

IPX
Syniverse
Diameter
Proxy

SGi

S8

S6a
Diameter
Relay

P-GW

Gx

PCRF

S5
S6a

HSS

S6a

EPC

e-UTRAN
S1-U

S1-U

S-GW

eNodeB

S11

MME

S1-MME

PLMN

Impact of LTE on Business

Decisions and Processes

Roaming Agreements
AA.12 and AA.13 (standard roaming agreement
templates) were updated in 2003 to be technologyneutral
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

Commercial Launch Letter for LTE

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:

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:SGW
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