LTE Implement KC
-
Upload
muthanna-ali -
Category
Documents
-
view
37 -
download
4
Transcript of LTE Implement KC
-
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 [email protected]
+1.813.637.5974