Voice Over LTE

1 COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.
ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
This package contains slides from many, many contributors including: BRIGANT, Eric BROUWER, Wim CARSON, Chris FAGGION, Nadge LICHTER, Joe SACHDEV, Vineet URIE, Alistair YU, Jim You, of course, get credit for delivering it. Add your name in place of Speaker Name and delete this whole note.
Voice and SMS in LTE Technical Overview

Speaker Name
Date
COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
AGENDA
1. Introduction 2. Solution Architecture Overview 3. End-User Services
You will have to modify the agenda based on the sections you include in your talk
4. Regulatory Services
5. Provisioning / migrating subscribers 6. Roadmap 7. Supporting Sections
3 COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED. ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION
1. Introduction
Voice in LTE Introduction

Initial LTE deployments were focused on data services
- However, carriers are quickly expanding to voice services as well
In an attempt to ease introduction of voice in LTE, phased approaches are available:

Circuit-Switched Fallback (CSFB) This method drops the UE from LTE to CDMA 1x any time a voice all is active Dual-Transceiver Handsets (SVLTE) Approach requiring specialized handsets has traction among CDMA operators
IMS with GSMA VoLTE This is the widely accepted target architecture for voice in LTE
Note there are other niche approaches that a small set of vendors and service providers are pursuing:
- Use SIP UE with proprietary enhancements to MSC
This method enhances an existing MSC with a SIP Gm interface (i.e. NSN FastTrack)
- These approaches have limited traction in the market place. The supporting ecosystem is uncertain.
Market and network trends impacting voice solution for LTE

Voice remains important but no longer is the dominant service in terms of radio network load
- Market will however split between legacy and rich services
- Some operators targeting rich services only for power users with others planning to generalize rich services to all users - Legacy services expected to remain the only option for legacy terminals
LTE rollout will be similar to 3G

- Gradual increase in covered area across network
- Some operators targeting LTE coverage to exceed 3G deployment - Others planning to always have wider 3G coverage than LTE - May also depend on frequency bands allocated for LTE - i.e., higher bands may result in coverage holes indoors etc.
- Support for users roaming onto networks without LTE coverage will remain key requirement for at least 10 years
SMS solution typically required from day 1

- Data only terminals MAY be an exception depending on configuration update mechanism
Assumed requirements for Voice and SMS over LTE capable terminals
Services
- Voice service continuity to be ensured during handover to CDMA access
- Solution to support handover from CDMA to LTE requires standardization when, and if, agreed technical solution and need has been determined
- Voice service may be controlled using IMS servers and applications

- Including when in CDMA circuit mode
- Voice service to be available while roaming on other LTE networks

- Independent of preferred voice solution of visited network
Network
- Voice specific functionality in E-UTRAN and EPC to be minimized
- Header compression (RoHC) and Semi-Persistent Scheduling in E-UTRAN - Possibly CSFB and/or SRVCC support in MME
- Possibly CSFB and/or SRVCC support in MSCs
- No additional requirements imposed on roaming partner networks

Options for Supporting Voice and SMS with LTE

There are three options we can discuss for voice/SMS services with LTE:
Option CS Fall-back (CSFB) Description UE is registered in LTE and is paged over LTE but takes call in CDMA Circuit mode Comment Attractive as a means of re-using all the CS infrastructure. Note this option precludes simultaneous LTE data and voice (different carriers)
Simultaneous Voice and LTE (SVLTE)
UE maintains simultaneous registration on LTE network for data and legacy network for voice/SMS
Offered in the UE at the expense of greater complexity and shorter battery life.
Voice over LTE (VoLTE)
Uses a standard 3GPP IMS and LTE features to improve voice capacity Continuity Options: Hand-down to CDMA circuit domain LTE <-> eHRPD PS HO required if VoIP over eHRPD is supported
8
Call control for native LTE voice and SMS service is provided by IMS. IMSbased call control can be provided in the CDMA domain via the IMS anchoring for calls originated in CDMA circuit mode.
Voice with LTE and CDMA Networks Standards

VoLTE Standards span 3GPP R8 (2008) to current release
- All variants of CDMA (1x, 1x Advanced, EVDO Rev A, Multi-Carrier EVDO and DO Advanced) have been enhanced to allow delivery of voice in a mixed LTE/CDMA network including options for 1x CSFB, 1x SRVCC, 1x DRVCC, and VoIP handover via eHRPD PSHO.
Alcatel-Lucent is a very active participant in 3GPP and 3GPP2. 3GPP2 references include
- C.S0087: E-UTRAN cdma2000 HRPD Connectivity and Inter-working Air Interface
- C.S0097: E-UTRAN cdma2000 1x Connectivity and Interworking Air Interface

- A.S0022: IOS for eHRPD RAN Interfaces and Interworking with E-UTRAN - X.S0042: Voice Call Continuity Between IMS and Circuit Switched Systems - X.S0057: E-UTRAN eHRPD Connectivity and Interworking: Core Network Aspects
GSMA VoLTE (formerly referred to as OneVoice)

GSM Association (GSMA) sponsored IR.92 profile is an industry effort to ease the introduction of VoLTE/VoIMS via specification of critical interworking requirements between UE and network vendors
- Work initiated within standalone "One Voice" forum and transferred to GSMA IREG RiLTE in early 2010
Alcatel-Lucent was one of the original members of the One Voice forum and is an active participant within RiLTE working group managing this profile
We have completed an end-to-end evaluation of the GSMA VoLTE IR.92 Profile v2.0 specification across the ALU portfolio and ALU LTE Solution is currently ready for initial UE interoperability testing of this profile
ALU is committed to supporting GSMA VoLTE IR.92 profile and IR.88
Primary Migration strategies for Voice and SMS services: Industry Trends
Initial LTE launch
Data modems only. Deploy 1H2011 Including smartphones; earliest test 1H2011; deploy 2H2011
Service Rollout
Full range of terminals; earliest test 2H2011; deploy 1H2012
Mass market
Network optimization
Full range of terminals 2013+
Option for data only devices

LTE only Data only devices LTE and eHRPD Data only devices LTE and eHRPD Data only devices LTE and eHRPD Data only devices
VoLTE with DRVCC SRVCC
IMS VoLTE (complete LTE coverage)
IMS VoLTE (complete LTE coverage)
SVLTE
IMS VoLTE/VoIP over eHRPD
IMS VoLTE/VoIP over eHRPD
LTE with Dual Tx CSFB

IP-Optimized solution
IMS VoLTE with S102 SRVCC CDMA
IMS VoLTE with S102 SRVCC CDMA
IP+Circuit solution
11
Voice and SMS via S102 CSFB
2a. Solution Architecture Overview: Circuit-Switched Fallback
CS Fallback
Approach
and SMS over S102

- Voice call setup (either mobile originated or incoming page) triggers UE move from LTE to 1x to then support voice over CS
- SMS delivery over LTE using S102 interface
Handover
- LTE->1x: Data session suspended during voice call
Key elements
- Upgrade to MME, E-UTRAN and all MSCs (or installation of IWS) for S102 interface in LTE coverage area
- Only selected MSC need be upgraded if only used for SMS over S102, e.g., for SMS to data-only endpoints
- CSFB client in terminal
Target usage
- Operators with embedded 1x network building LTE overlay, or - Operators building LTE network and choosing SMS over S102
CS Fallback and SMS over S102 are both defined in 3GPP TS 23.272. + 3GPP2 C.S0097
CS Fallback - High Level Architecture

MSC CDMA 1X CS Network CDMA 1x MSC CS Network
E-UTRAN
MME
New interface S102 from MSC to MME

PDN
E-UTRAN
MME
PDN
eNode B
SGW
PGW
Data Paging/SMS
eNode B
SGW
PGW
While carrying data only
No Simultaneous Voice + Data

- Handset falls back to legacy circuit coverage for voice - Data sessions suspended
Circuit Voice Data
- Handset uses LTE network where possible to achieve highest throughput - Handset served by an MSC in legacy network for voice and SMS
- Incoming voice calls paged over S102 interface from MSC to MME, similar to Gs interface in GPRS - SMS delivered over S102 without requiring inter-RAT handover
CSFB Tradeoff
- Re-uses legacy circuit infrastructure - But at the cost of Inter-RAT handover per voice call, and suspended data sessions
CS Fallback: Roaming Considerations

If a UE requires CSFB and CSFB is available in a visited network, roaming voice service operates in the visited network with the same restrictions as in todays roaming environment. If a UE requires CSFB and CSFB is not available in a visited network, the UE will disable E-UTRAN capability and select a CDMA network Further details can be found in 3GPP TS 23.221 Annex A
Figure A.5-1 from 3GPP TS 23.221: UE behavior for CS Voice only
UE is set to CS Voice only Fail or Success with SMS only indication or Success with CSFB Not Preferred indication UE initiates a combined EPS/ IMSI attach procedure Success with no SMS-only indication and no CSFB Not Preferred indication UE checks for voice centric or data centric setting
Voice centric
Data centric
UE uses CSFB
UE stays in current RAT
UE reselects to other RAT
CS Fallback Benefits, Costs, and Limitations

Benefits Provides mechanism for basic, transparent voice service to LTE handsets - Applicable to voice handsets if LTE is deployed in advance of IMS Limitations CSFB procedures in eUTRAN require per-call migration to CDMA - Increases call setup delay - Range of figures depending on network conditions
- Applicable to LTE roamers whose home network is not IMS capable

- Does not require IMS client in UE Can be used to provide basic voice service to certain users in networks where IMS voice is available as a premium service Costs Requires support of S102 interface on MME and MSCs - S102 required on only a subset of MSCs if only SMS delivery (not CSFB) is required
2b. Solution Architecture Overview: Simultaneous Voice and LTE (SVLTE)
Simultaneous (Circuit) Voice and LTE (SVLTE)

MSC CDMA 1x BTS CS Network
E-UTRAN
MME PDN
Circuit Voice Data
eNode B
SGW
PGW
SVLTE Two phones in one to re-use legacy voice capabilities while offering LTE for data Particularly attractive to CDMA-2000 operators as it provides data connectivity during voice calls SVLTE is not defined in standards
- It is a handset ecosystem marketing term - No hard-and-fast rules on network or handset impact - To date Alcatel-Lucent has done IOT only with LTE / CDMA 1x handsets: No network impact
SVLTE is not known to have traction among 3GPP operators

- UMTS offers simultaneous voice and data already
Device Options Two Example Device Solutions

Qualcomms SVLTE/SVDO Qualcomm Simultaneous V&D
- Enables Dual Transceiver Devices capable of
- Simultaneous 1x Voice with LTE Data, and
- Simultaneous 1x Voice with eHRPD (EV-DO) Data
Rx/Tx
Rx/Tx
- Qualcomm 2-chip initial solution: Fusion

- MDM9600 supporting LTE and EV-DO (eHRPD) data
DO/ LTE
1x
- MSM8655 supporting 1x Voice and Smartphone operating system
- Devices would have one transceiver for Voice, and one serving LTE and EV-DO
- Qualcomm planning single-chip SVLTE/SVDO follow on solution
CSFB Dual Receiver for LTE data and 1x CS Voice

- Standards-based device with separate receiver for LTE and CDMA
- The device shown at right has a single Tx, but Separate receivers for LTE and eHRPD - A Dual Tx device may be capable of simultaneous 1x Voice with LTE Data
Rx Tx Rx
LTE
1x / DO
2c. Solution Architecture Overview: Voice over LTE
VoLTE Required Solution Enhancements

Approach:
- Provide voice to LTE UEs using IMS to provide the voice services
Key elements:
- LTE E-UTRAN enhanced for VoIP delivery - IMS core with Telephony Application Server (TAS) to provide end-user services - VCC to provide handover capabilities between different radio domains (i.e., packet and circuit)
The next slides will explore each of these areas in more detail
VoLTE Alcatel-Lucent Products

CDMA 1X
8610 ICC
1357 ULIS 8615 IeCCF
5110 SMS C
BTS
MSC
PSTN/PLMN
VitalQIP
eHRPD
eHRPD
Elements added for IMS
BTS
HSGW
eRNC
7510 MG 5420 PCM 5060 MGC-8

IMS Core
E-UTRAN
5420 CTS (TAS)
9471 MME
5780 DSC
8650 SDM
Enhanced Packet Core (Voice + Data)
5450 ISC
5420 SCG
5900 MRF
94xx eNB 7750 SGW 7750 PGW
VoLTE Required LTE E-UTRAN Enhancements for VoIP Delivery

Header compression using Robust Header Compression (RoHC)
- Reduced overhead but robust to consecutive packet errors.
Delay management for VoIP QoS control

- QoS policy enforcement through Priority management - Air interface resource management for VoIP QoS control - Bearer QoS with DSCP marking in backhaul - Smaller scheduling interval (TTI = 1ms)
Semi-persistent scheduling for VoIP

- Reduce scheduling overhead
Short PDCP sequence number to reduce the packet overhead. RLC UM (RLC Unacknowledged Mode, no retransmission)
- Reduce the delay and jitter of VoIP packets.
IMS core with Telephony Application Server (TAS)

The IMS core and TAS adds the following components:
- Session manager consisting of P-CSCF, S-CSCF, I-CSCF, and BGCF, provided by the 5450 ISC - TAS to provide the voice services - uses 5420 CTS - SCC AS providing service centralization and VCC provided by 5420 SCG
- Web portal to support subscriber feature configuration such as call forwarding uses 5420 PCM
- MGCF and MGW to provide connectivity to the PSTN
- These functions are provided by the 5020/5060 MGC-8 and the 7510 MG respectively
- Media resource function to support functions such as announcements and conferencing capabilities - provided by the 5900 MRF - DNS/ENUM server to resolve IP addresses and E.164 addresses
- This function is provided by VitalQIP. Note this function could be shared with the DNS function already in the LTE network
The IMS core and TAS also leverage the following entities from LTE:
- Home Subscriber System for subscriber data (8650 SDM) - Offline charging function (8615 IeCCF) - Online charging function (8610 ICC) - Lawful intercept gateway (1357 ULIS)
VoLTE user plane aspects Two party calls

LTE to LTE call
CDMA MSC
VoLTE to VoLTE call

- Each UE has dedicated signaling connection to own S-SCCF and TAS (may be shared)
HSGW E-UTRAN MME IMS SCC AS PDN eNode B SGW PGW
TAS
- Direct packet voice connection between two parties, routed via own PGW (may be shared)
Each UE has dedicated QCI=1 bearer established for voice service If UE not on same network then user plane carried over inter-operator interconnection (normally via GSMA sponsored IPX)
VoLTE to CS call
VoLTE to mobile CS
CDMA
MSC
CS Network
- LTE connected UE has dedicated signaling connection to own S-CSCF and TAS
- CS connected UE has dedicated signaling connection to MSC

- During call MSC and IMS linked together using ISUP via MGCF (or using SIP if MSC supports IP)
HSGW E-UTRAN MME
MGW
MGCF SCC IMS TAS
PDN eNode B SGW PGW
- Media path connected via MGW under control of MGCF

LTE connected UE has dedicated QCI=1 bearer established for voice service
IMS Signaling
Packet Data
Circuit Voice
Circuit signaling
Packet Voice
25
VoLTE user plane aspects Multi-party calls

LTE to LTE conference call
VoLTE to VoLTE conference call

CS Network
CDMA
MSC
- Each UE has dedicated signaling connection to own S-SCCF and TAS (may be shared) - Media path from each UE directed to conference bridge hosted by MRF (Media Resource Function)
HSGW E-UTRAN MME IMS SCC AS PDN eNode B SGW PGW
TAS
Each UE has dedicated QCI=1 bearer established for voice service
MRF
VoLTE to CS call
- Each UE has dedicated signaling connection to own S-SCCF and TAS (may be shared)
LTE to LTE call with

CDMA MSC
3rd
party on hold
CS Network
- Direct packet voice connection between two active parties, routed via own PGW (may be shared)
Each active UE has dedicated QCI=1 bearer established for voice service
HSGW E-UTRAN MME IMS SCC AS PDN eNode B SGW PGW TAS
- Media path for held UE directed to announcement service hosted by MRF (Media Resource Function)
Held UE has dedicated QCI=1 bearer established for voice service
MRF
Circuit Voice
Circuit signaling
Packet Voice
26
IMS Signaling
Packet Data
VoLTE Hand down to 3G network

Voice Call Continuity is used to provide session continuity from LTE to CDMA for voice calls Two options exist:
- Handover while remaining in packet (PS)
- Handover from LTE to 3G eHRPD can be done without the need for SRVCC
- Handover to circuit (CS)

- SRVCC requires UE and network functionality along with bearer path reconfiguration by SCC AS
- Alternatively UE based dual transceiver solution can be used with SCC AS bearer reconfiguration to provide hand down.
When handing over to CDMA, PS data services are suspended Note that CS handover from CDMA to LTE is not defined in the standards
- UE needs to wait for call using CS bearer to end before reselecting LTE cell - Reverse SRVCC now being worked in standards
VoLTE handover to legacy mobile network Using PS handover (towards eHRPD only)
Before
CDMA MSC CS Network
Approach
- Simple PS handover triggered by MME involving HSGW and S/PGW
HSGW E-UTRAN MME
MGW MGCF SCC
IMS
TAS
PDN eNode B SGW PGW
Service restrictions
- Full IMS services maintained during handover and remainder of call
- Gm signaling interface available - PS Voice bearer support required
after
CDMA
MSC
CS Network
- VoIMS is not viable over 1x

HSGW E-UTRAN MME MGW MGCF SCC IMS TAS
PDN eNode B SGW PGW
Circuit Voice
Circuit signaling
Packet Voice
28
IMS Signaling
Packet Data
VoLTE handover to legacy mobile network Using SRVCC (B party in CS network)

CDMA MSC
Before
CS Network
Approach
- SRVCC mechanism triggered by MME, involving MSC and SCC
TAS
HSGW E-UTRAN MME
MGW
MGCF SCC
IMS
PDN eNode B SGW PGW
- Parallel PS handover used for data services
after
MSC CS Network
CDMA
- (Most) IMS services maintained during handover and remainder of call
HSGW E-UTRAN MME
- Available over all mobile networks with SRVCC roaming agreements

- Requires SRVCC support in visited network
TAS
MGW MGCF SCC
IMS
PDN eNode B SGW PGW
Figures are simplified

Packet Voice
29
Circuit Voice
Circuit signaling
IMS Signaling
Packet Data
VoLTE handover to legacy mobile network Using SRVCC (B party in LTE)

CDMA MSC
Before
CS Network
Approach
HSGW E-UTRAN MME MGW MGCF SCC IMS TAS
- SRVCC mechanism triggered by MME, involving MSC and SCC - Parallel PS handover used for data services
PDN eNode B SGW PGW
after
CDMA MSC CS Network
- (Most) IMS services maintained during handover and remainder of call - Available over all mobile networks with SRVCC roaming agreements
HSGW E-UTRAN MME
MGW MGCF SCC
IMS TAS
- Requires SRVCC support in visited network
PDN eNode B SGW PGW

Packet Voice
30
Circuit Voice
Circuit signaling
IMS Signaling
Packet Data
VoLTE handover to legacy mobile network Using DRVCC (B party in CS network) No S102
CDMA MSC
Before
CS Network
Approach
- DRVCC mechanism triggered by UE, UE initiated new HO leg in CDMA
TAS
HSGW E-UTRAN MME
MGW
MGCF SCC
IMS
PDN eNode B SGW PGW
- Parallel PS handover used for data services
after
CDMA MSC CS Network
- (Most) IMS services maintained during handover and remainder of call - Available over all mobile networks
TAS
HSGW E-UTRAN MME
MGW MGCF SCC
IMS
PDN eNode B SGW PGW

Packet Voice
31
Circuit Voice
Circuit signaling
IMS Signaling
Packet Data
VoLTE and CDMA Integration Implementation Options
VoLTE with CDMA Circuit

Routing Through IMS
Calls are routed through the IMS to fulfill a variety of requirements not all requirements apply to all solutions.
- Domain Selection - Incoming calls to UE with combined VoLTE/Circuit solutions must be routed to the appropriate domain. This is usually achieved via VCC application server on the IMS - Domain Transfer - Hand down from VoIP to Circuit is controlled by the VCC application server on the IMS - IMS Based Services Those calls on which IMS based services are desired (including calls in the CDMA network) must be routed through the IMS and TAS for services control. Some next generation services examples include:
- Simultaneous ringing of desk, cellular, home phones
- Time of day routing to desk, cellular, home - Call logging and account codes - Powerful call blocking - Enterprise extension dialing - etc.
VoLTE with CDMA Circuit

Supplementary Services
Supplementary Services provisioning and status are synced between the IMS and CDMA networks to a greater or lesser degree Supplementary Services are categorized into groups as follows
- Static (not changeable by the end user) Services such as caller ID presentation and restriction must be consistently configured on both the IMS (TAS) and CDMA (HLR) initially. - Semi-static (changed by the end user and remain in that state until changed back by the end user e.g., temporarily persistent status) such as CW Disable, ID Privacy, Call Forwarding, Call Blocking. These services are further categorized based on application to incoming or outgoing calls of those listed ID Privacy is the only service that applies to outgoing calls. The service activation data for this category of services may require special handling - Per call service activation such as Cancel Call Waiting (for this call only). These services are provided by the serving system (IMS or CDMA) - Mid call services such as Three Way Calling, Call Hold, Call Transfer, Accept Waiting Call. These services are provided by the serving system (IMS or CDMA)
Service Delivery Options IMS Service Delivery in LTE (Baseline)

UE Initiates call using SIP signaling
TAS applies originating features Call routed to B-party IP Bearer is set up
MGW MGCF
IMS Core
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
MRF
eNode B SGW PGW
Packet Voice
35
IMS Signaling
Service Delivery Options IMS Service Delivery in LTE to PSTN

UE Initiates call using SIP signaling TAS applies originating features Call routed to MGCF (B-party in PSTN) MGCF signals PSTN MGCF instructs MGW to set up PSTN connection IP Bearer is set up
PSTN/PLMN
MGW MGCF
IMS Core
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
MRF
eNode B SGW PGW
Circuit Voice
Circuit signaling
Packet Voice
36
IMS Signaling
Packet Data
Service Delivery Options IMS Service Delivery - Attributes

Features provided by IMS & TAS Simultaneous LTE voice and data supported Call Flow supports LTE to CDMA Hand-down (SRVCC or DRVCC)
Service Delivery Options
IMS Service Delivery in eHRPD Gm Method with eHRPD Bearer

UE Initiates call using SIP signaling TAS applies originating features Call routed to MGCF (B-party in PSTN) MGCF signals PSTN MGCF instructs MGW to set up PSTN connection IP Bearer is set up
MSC
PSTN/PLMN
eHRPD
Core
BTS
eRNC
HSGW MGW MGCF

IMS Core
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
MRF
eNode B SGW PGW
Circuit Voice
Circuit signaling
Packet Voice
38
IMS Signaling
Packet Data
Service Delivery Options IMS Service Delivery in eHRPD - Attributes

Features provided by IMS & TAS Requires optimized PS-PS Handover support
- Supports handover in both directions
Simultaneous voice and data supported Well suited to handle small coverage holes in LTE layer Avoids need for SRVCC or DRVCC as long as eHRPD is available Better quality (PS HO to eHRPD)
This option is attractive for service providers that have a large embedded base of eHRPD voice-enabled packet networks
IMS Anchored Solution for calls in CDMA

Standard solution as described in 3GPP2 X.S0042-A Voice Call Continuity
between IMS and Circuit Switched Systems
In general, the solution is designed to anchor all voice calls through the IMS and IMS application servers. This is intended to provide IMS Next Gen Services to the subscribers both when in IMS and when in CDMA circuit. Anchoring Options
- For incoming calls this can be achieved in several ways
- Terminating Triggers at the Home MSC. In this case, it is possible to use multiple terminating triggers at the Home MSC to support both legacy network incoming call services and IMS anchoring - Assigning an IMS number or porting the existing number to IMS - Modification of the HLR to support forced routing to IMS at LOCREQ
- For originations in the CDMA network, this is achieved via (WIN or pre-WIN) Originating Triggers. This may be problematic when the user is roaming outside the service provider coverage depending on trigger support from roaming partners.
Anchoring Options at the VCC Anchoring Function

5420 SCG receives the Invoke and responds with the Return Result for the cases below. Origination anchoring
- OriginationRequest: ANSI-41D (pre-WIN) - OriginationRequest: Origination Attempt Authorized - OriginationRequest: All Calls
Termination anchoring
- New assigned directory number in IMS number range - Re-use of an existing number
- number portability or - AnalyzedInformation: Initial Termination at Home MSC or - AnalyzedInformation: Advanced Termination Trigger at Home MSC
Support of multiple trigger options allows some services (e.g., CRBT) to continue to be offered in the Home MSC/WIN SCP if desired.
Limited IMS Service Delivery in CDMA: WIN Anchoring Originating Call

CDMA UE Initiates call to MSC MSC has originating attempt trigger for UE pointing to SCC AS. Sends trigger with dialed digits. SCC AS saves dialed digits and returns PSI DN MSC initiates call to PSI DN MGCF sets up incoming circuit bearer MGCF routes call to SCC AS SCC AS sends INVITE to TAS with saved dialed digits TAS applies originating features Call routed to MGCF (B-party in PSTN) MGCF signals PSTN MGCF instructs MGW to set up PSTN connection
BTS
MSC
PSTN/PLMN
eHRPD
eHRPD
BTS
HSGW RNC MGW MGCF

IMS Core
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF SCC AS
MRF
eNode B SGW PGW
Limited IMS Service Delivery in CDMA: WIN Origination Anchoring

Features initiated in origination dial string (e.g., CCW, extension dialing) from IMS TAS Mid-call features (e.g., 3WC) from MSC Some services limit handover (e.g. conferencing) SCC AS with WIN support required to anchor call in IMS No impact on MSC (beyond support of WIN triggers) HLR provisioning of WIN triggers and appropriate end user services This may be attractive to service providers for early introductions May be an issue with origination trigger support when UE is roaming in CDMA partner network
Service Delivery Options Local Service Delivery in CDMA: MSC Provides Services
UE Initiates call to B-party MSC routes call to B-party Circuit bearer is completed
MSC
PSTN/PLMN
CDMA
eHRPD
BTS
RND
HSGW MGW MGCF

IMS Core
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
SCC AS
MRF
eNode B
SGW
PGW
Local Service Delivery in CDMA: MSC Provides Services Attributes

All features from CDMA MSC while in CDMA Mode No handover support from or to LTE Need a mechanism to allow user in CDMA to activate services at the TAS
No impact on MSC
This option is primarily useful for LTE subscribers roaming into another service providers network
Service Delivery Options WIN Anchoring for Incoming Calls

PSTN/PLMN
Call initiated to UE at Home MSC H-MSC sends triggered message to SCC AS which saves call info and returns a PSI DN MSC sets up a call to PSI DN MGCF sets up incoming circuit bearer MGCF routes call to SCC AS SCC AS sends INVITE to TAS with saved dialed digits TAS applies terminating features Call is routed back to SCC AS for domain selection
H-MSC
CDMA MSC MGW MGCF

IMS Core
BTS
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
SCC AS
MRF
eNode B
SGW
PGW
Service Delivery Options Domain Selection to CDMA

PSTN/PLMN
H-MSC
Call routed into IMS and to TAS TAS applies terminating features Call is routed to SCC AS for domain selection SCC AS does not find UE registered in IMS and queries the HLR for routing digits HLR returns routing digits Call routed through MGCF to routing destination Call delivered to UE
CDMA MSC MGW MGCF

IMS Core
BTS
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
SCC AS
MRF
eNode B
SGW
PGW
Service Delivery Options Domain Selection to LTE

PSTN/PLMN
Call routed into IMS and to TAS TAS applies terminating features Call is routed to SCC AS for domain selection SCC AS does find UE registered in IMS and routes the call through the S-CSCF H-MSC
S-CSCF routes call to UE Contact Address Bearer path is allocated and connected
Call delivered to UE
CDMA MSC MGW MGCF

IMS Core
BTS
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
SCC AS
MRF
eNode B
SGW
PGW
Limited IMS Service Delivery in CDMA: WIN Termination Anchoring

This is attractive when existing CDMA customers (DNs) are migrated to VoLTE with CDMA
Incoming Call Features (e.g., CF, Call Blocking, TOD routing, etc. ) from IMS TAS
- Possible to provide some services (e.g., CRBT) at the Home MSC if that is desired
Mid-call features (e.g., 3WC) from MSC Some services limit handover (e.g. conferencing) SCC AS with WIN support required to anchor call in IMS No impact on MSC (beyond support of WIN triggers) HLR provisioning of WIN triggers and appropriate end user services No issue with trigger support while CDMA roaming as all incoming calls route through the Home MSC in the HPLMN
Basic VoLTE and CDMA Option

Originations on CDMA network are NOT anchored through IMS
- It may be difficult or expensive to support anchoring of CDMA originations through the IMS especially in the case of roaming in another CDMA network. Thus Local Service Delivery at the Serving CDMA MSC provides the same solution in both the home and visited CDMA networks.
Incoming calls are routed through the IMS via following

- New assigned directory number in IMS number range or re-use of an existing CDMA number via porting number to IMS or WIN triggers at the Home MSC
Domain Transfer (SRVCC or DRVCC) supported for VoLTE to CDMA Services are provided by the serving network for originations and by the IMS for terminations
- Incoming call semi-static feature activations (e.g., CF) at the IMS TAS via web browser interface from smart phone or PC. - Assume CW Disable (temporarily persistent) not supported - Multi-party or held calls in the IMS are not controllable by the UE after VoLTE to CDMA domain transfer (hand down).
Enhancements to Basic VoLTE and CDMA Option

Add support for anchoring CDMA originations through IMS
- Gain the ability to offer TAS based enhanced or Next Generation services such as extension dialing, call logging, consistently regardless of access network (LTE or CDMA). - Feature activation codes can be supported for semi-static feature changes since the feature activation
Add support for Ut interface in the TAS and UE

- Add the capability for the UE to determine the need for and automatically perform feature activation via XML data interface (Ut) to the TAS perhaps via features management GUI on the device
Roaming Impacts
CDMA Roaming for VoLTE/CDMA users
- As discussed elsewhere, support of origination call triggers in a roaming partner network may be problematic - Similarly, support of S102 for SRVCC hand down to CDMA may not be supported in all CDMA networks.
LTE Roaming for VoLTE users

- GSMA specifies an architecture that provides for local breakout from the PGW to a P-CSCF in the VPLMN and the reminder of the IMS in the Home PLMN (LBO to Home IMS).
- Business issues such as charging and routing determination require additional features currently targeted for Release 11. If the roaming partners agree that those business issues can be avoided it may be possible to support VoLTE roaming prior to Release 11.
VoLTE Handoff Options
VoLTE Handoff Options

Approach
Non-Optimized eHRPD Optimized eHRPD 1x DRVCC 1x SRVCC
Network Destination Enhancemen t Required?

eHRPD VoIP eHRPD VoIP 1x CS 1x CS None S101 VCC App Server S102
Device Dual Receiver or Dual Radio * Single or Dual Radio C.S0087 Tunnel Dual Radio Single Radio C.S0097 Tunnel
Availability Today Future Future Future
* Non-Optimized eHRPD HO supports Single or Dual Radio devices. However, for

VoLTE HO, separate receivers for LTE and eHRPD may improve handoff delay.
VoLTE Handoff
When VoLTE is used, a solution is required for dealing with mobility outside of an area with LTE coverage, to provide voice call continuity
Non-Optimized eHRPD Upon reaching the edge of LTE coverage, a nonoptimized handover is executed without S101.
- Delay can be prohibitive, but studies are underway to improve performance to where it might be acceptable for voice calls.
Optimized eHRPD Upon reaching edge of LTE coverage, an optimized handover using S101 is executed. The call remains in the packet domain on eHRPD. 1x DRVCC Similar to SRVCC, but device controls call establishment over 1x, no need for S102 interface or GCSNA layer. Upon reaching edge of LTE coverage, UE initiates 1x call setup while maintaining VoIP call leg. After 1x call is answered, UE switches to circuit mode and UE is handed off to 1x. VCC App Server required.
- Partially standardized in X.S0042 as Dual Radio Domain Transfer.
1x SRVCC Upon reaching the edge of LTE coverage, the 1x call is set up over the S102 tunnel and then the UE handed over to 1x.
Interworking LTE with EV-DO via eHRPD (Optimized)

1xEV-DO (HRPD and eHRPD) 3GPP2
LTE-eHRPD Legacy EV-DO AT RNC / eRNC PDSN AAA
SW upgrade on existing equipment Potential future SW upgrade on existing equipment
Packet Switched Core
HA
eHRPD
BTS
IMS
HS GW
Internet / Intranet
LTE 3GPP
With addition of Optimized Handoff with S101 signaling for pre-registration and handoff, and S103 for data forwarding, handoff performance improves
LTE UE
S103
S101
MME SGW eNode B
PCRF
HSS
Evolved Packet Core
PDN GW
LTE VoIP DRVCC Handoff to CDMA 1x Circuit Switch Voice (without S102)
HLR MSC/ BSC BTS
Circuit Switched Core (Voice)
PSTN ANSI41
Voice Channels
CDMA2000 1X 3GPP2
Legacy 1X AT
LTE - 1X AT
LTE supports VoIP and Hands Off to CDMA2000 1X Circuit Network outside of LTE Coverage
SCG
IMS
MGC/MGW
Internet / Intranet
LTE
3GPP
LTE UE SGW eNode B
MME
PCRF
HSS
Evolved Packet Core
PDN GW
IMS SCG VCC application allows dual radio LTE VoIP services to hand off to 1X CS Voice without S102.
VCC : IMS to CS Handover Call Flow DRVCC

5) VCC updates the IP addresses for the existing call to connect to the new, incoming call MGW.
SCG VCC App Server
CTS TAS
3) 1X Orig MSC
4) INVITE
CSCF
MGCF MGW
BS 2) Handover Trigger
domain
6) BYE Broadband Access LTE RAN & EPC
IMS
MGCF MGW
pCSCF PSTN VoIP Bearer Path Circuit Bearer Path Signaling Path
1) Existing VoLTE call between the Handset on LTE and PSTN user.
LTE VoIP SRVCC Handoff to CDMA 1x Circuit Switch Voice (with S102)
HLR MSC/ BSC BTS S102
Circuit Switched Core (Voice)
PSTN ANSI41
Voice Channels
CDMA2000 1X 3GPP2
Legacy 1X AT
LTE - 1X AT
LTE supports VoIP and Hands Off to CDMA2000 1X Circuit Network outside of LTE Coverage
SCG
IMS
MGC/MGW
S102 is used for Hand Off Signaling LTE
Internet / Intranet
3GPP
LTE UE SGW eNode B
MME
PCRF
HSS
Evolved Packet Core
PDN GW
IMS SCG VCC application with S102 allows LTE VoIP services to hand off to 1X CS Voice.
VCC : IMS to CS Handover Call Flow - SRVCC

6) VCC reconfigures the IP addresses for the existing call to connect to the new, incoming call.
VCC App Server

CTS TAS
4) INVITE MSC MGCF MGW 3) 1x Orig 5) HO Command 7) BYE 1) Existing VoLTE call between the Handset on LTE and PSTN user. Broadband Access LTE RAN & EPC
60
CSCF
BS
S102 2) Handover Trigger pCSCF
domain
IMS
MGCF MGW
PSTN VoIP Bearer Path Circuit Bearer Path Signaling Path
Single Radio Voice Call Continuity PS to CS (E-UTRAN/CDMA SRVCC)

UE in LTE with established call to PSTN subscriber UE measures signal strength UE reports signal strength to eNB eNB decides HO is required and sends request to MME MME sends request to MSC enhanced with S102 interface* MSC prepares handover, signals BTS and initiates call to SCC AS using STN-SR In parallel to IMS processing the MSC sends HO response back to MME MSC CDMA UE tunes to new network MGCF sets up incoming circuit bearer MGCF routes call to SCC AS SCC AS sends RE-INVITE to TAS with new bearer IP TAS forwards to MGCF MGCF instructs MGW to update IP connection
PSTN/PLMN
BTS
MGW MGCF
IMS Core
PCM
TAS
E-UTRAN
MME
PCRF
HSS/HLR
CSCF
SCC AS
MRF
eNode B SGW PGW

Mid-Call Services with LTE to CDMA Hand-down

Case 1: Mid-call service (3WC, CW, CT, Hold) occurs and returns to single-party call prior to Hand-down.
- The mid-call (multi-party) was completely handled in IMS TAS. Hand-down is not impacted.
Case 2: Single party call is Handed-down to CDMA. Then a mid-call service is initiated on the CDMA MSC
- The mid-call (multi-party) is completely handled in the CDMA MSC. The Hand-down that occurred prior to the mid-call services is (clearly) not impacted by the subsequent mid-call service. Note: multi-legged calls may result in multiple calls through the IMS depending on anchoring strategy but they are treated as independent calls by the IMS no bridging is done in the IMS.
Case 3: Mid-call service (multi-party call) is active on the IMS WHEN the hand-down is attempted
- If the multi-party call is stable (no party is on hold), the call will hand-down, but UE control of the conference bridge is lost. - If any of the parties are on hold, the hand-down is denied by the VCC Application Server and the call continues in the LTE network
VoLTE and topologies for large geographic regions

Where the speed of light is perceptible to the end user.
Alternate Home Network Topology Options

- Topology 1: Dynamic P-CSCF/IMS/AS
- Dynamic allocation of P-CSCF, UVP, CTS, SCC-AS based on user location
- Topology 2: Home IMS/AS and Home P-CSCF

- Home use of P-CSCF (w/ BGW) - Home region IMS associated with UE - Static Allocation of AS(s) (CTS, SCC-AS)
- Topology 3: Home IMS/AS and Regional P-CSCF

- Regional use of P-CSCF (w/ BGW) - Home region IMS associated with UE - Static Allocation of AS(s) (CTS, SCC-AS)
Topology 1: Dynamic Allocation Model

Region Y (UE Home)
LTE TAS (CTS) LCP DNS SCC AS (SCG) LTE TAS (CTS) LCP DNS VitalQIP DNS SCC AS (SCG)
Region X
MSC
S-CSCF I-CSCF 5450 ISC
MSC
VitalQIP DNS
. . .
MSC
. . .
MSC
A-BGF P-CSCF
PCRF P-GW S-GW
PCRF A-BGF P-CSCF P-GW S-GW
EPC
EPC
UE1
AS and IMS Core Depends on region
UE1
CTS User Profile Data Options Primary/Protect & CSD

Primary/Protect Option
Sub A Data Sub B Data Sub C Data Sub D Data Sub A Data Sub B Data Sub C Data Sub D Data
CSD Option
HSS
Sub A Data Sub B Data Sub C Data Sub D Data Sub E Data Sub F Data Sub G Data Sub H Data
Other Apps
App Server
...
App Server App Server App Server
Geo-redundant Pair
...
App Server
App Server
Sub E Data Sub F Data Sub G Data Sub H Data
Sub E Data Sub F Data Sub G Data Sub H Data
App Server
App Server
Centralized Subscriber Database and Dynamic CTS Assignment With this option, CTS specific service data for a subscriber is stored as repository (transparent) data in the HSS Any CTS can retrieve a copy of a subscribers data from the HSS and process calls to/from the subscriber
Geo-redundant Pair
CTS User Profile Data Options Why CSD?

Improved user profile data integrity (consistency, integrity, backup, restore) because user profile data is being centralized in a single physical database. Flexibility regarding scalability and geo-graphical redundancy because session control and application layer are user-data-less (any ISC, CTS may serve any user).
- Dynamic allocation of user to a CTS server based on location
In our case, we will discuss on a per region basis
- When the network is extended with new CTS instances traffic may re-balance automatically across the whole network and or region without the need of moving users manually from one CTS to another CTS. - Geographical redundancy is present by default. So, can be introduced on-the-fly without needing to provision a Protect CTS/FSDB as well as re-provisioning of the per user IFC (to point to Primary/Protect TAS instance).
CTS Dynamic Assignment Description

The subscribers iFC is stored in IMS HSS
- The iFC contains the CTS-FQDN;
The CTS-FQDN resolution is based on local DNS resolution

- The Same CTS-FQDN will resolve differently in each region - Example on next slide
At UE registration, a CTS is selected and that CTS is notified of the registration

- The S-CSCF keeps that affiliation - The CTS assignment information is stored in transparent HSS data - The CTS queries HSS for a copy of subscribers data and caches a copy in its local database, which it uses to process subsequent calls to/from the subscriber
The user will stay assigned to that CTS until:

- The user re-registers with a different S-CSCF - Expiration of timed re-assignment (if AT&T uses this option) - A duplex CTS failure
If the user re-registers from another region:

- User will register with local P-CSCF, I-CSCF, and S-CSCF - Resolution of CTS-FQDN in the other region will assign a local CTS instance - Flow on next slide
Topology 2: Home IMS/AS and Home P-CSCF

Region Y (UE Home)
Region X
MSC
MSC
VitalQIP DNS
. . .
MSC
. . .
MSC
A-BGF P-CSCF
PCRF P-GW S-GW
EPC
EPC
UE1
Topology 3: Home IMS/AS, Regional P-CSCF

Region Y (UE Home)
Region X
MSC
MSC
VitalQIP DNS
. . .
MSC
. . .
MSC
A-BGF P-CSCF
PCRF P-GW S-GW
EPC
EPC
UE1
Voice Gap Call Flow w/ Transport Delay Consideration (LTE UE1 to LTE UE2)
Dynamic Home P-CSCF Regional P-CSCF
UE1 MSC+MG CF I-CSCF SCC AS1 S-CSCF Orig TAS

S-CSCF S-CSCF2 Term AS S-CSCF2 SCC AS2

S-CSCF2 P-CSCF (w/ SBC) UE2
Call Setup
Invite (STN-SR, MGW SDP) Invite (STN-SR, MGW MGW control SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) ENUM lookup MSC initiates a call to the Session Transfer Number for Single Radio (STN-SR). STNSR is a provisioned fixed value retrieved from HSS
Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) MGW control
v
200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) MGW control 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer)
Re-Invite(MGW SDP) 200 OK (SDP Answer) MGW control 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer)
Transport Delay
Voice Gap Call Flow w/ Transport Delay Consideration (LTE UE1 to PSTN)

S-CSCF MGCF PSTN
Call Setup
Re-Invite(MGW SDP) Re-Invite(MGW SDP) MGW control
v
MGW control 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) MGW control 200 OK (SDP Answer) 200 OK (SDP Answer)
Transport Delay
73
200 OK (SDP Answer)
Voice Gap Call Flow w/ Transport Delay Consideration (LTE UE1 to LTE UE2 (3G))

S-CSCF S-CSCF2 Term AS S-CSCF2

SCC AS2 MGCF UE2
Call Setup
Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) Re-Invite(MGW SDP) MGW control
MGW control
200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) 200 OK (SDP Answer) MGW control 200 OK (SDP Answer) 200 OK (SDP Answer)
200 OK (SDP Answer)
Transport Delay
SRVCC Voice Gap Estimate Comparison APPLIES for CDMA? (for home network scenarios with ~40ms one way transport delay) LTE UE1 to LTE UE2 LTE UE1 to PSTN LTE UE1 to LTE UE2
Dynamic AS
in LTE Coverage Mean Peak UE1 and UE2/PSTN 180 same region UE1 and UE2/PSTN 220 across country 275 335
Mean
130 205
Peak
205 265
in 3G Coverage Mean Peak 175 215 270 330
Home IMS/AS and Home P-CSCF
LTE UE1 to LTE UE2 LTE UE1 to PSTN in LTE Coverage Mean Peak Mean Peak UE1 and UE2/PSTN 190 home region UE1 and UE2/PSTN 260 across country 295 395 130 210 205 321
LTE UE1 to LTE UE2 in 3G Coverage Mean Peak 175 300 270 450
Home IMS/AS and Regional P-CSCF
LTE UE1 to LTE UE2 LTE UE1 to PSTN in LTE Coverage Mean Peak Mean Peak UE1 and UE2/PSTN 190 home region UE1 and UE2/PSTN 315 across country 295 475 130 210 205 321
LTE UE1 to LTE UE2 in 3G Coverage Mean Peak 175 300 270 450
MS location matter if Bearer is optimized shortest path? Is assumption that bearer also g
*Assume Border Gateway anchoring/pivoting with P-CSCF (and no media release)
Other Considerations
Characteristic Voice Gap P-CSCF Selection I-/S-CSCF Selection CTS selection SCG Selection STN-SR Routing
Dynamic Allocation Most scenarios under 300ms Dynamic PGW assisted I-/S- always local to PCSCF Requires CSDB and regional DNS for local CTS assignment Dynamic allocation based on regional DNS Unique STN-SR to each SCG, could require write to PS/CS HSS
Home P-CSCF/Home Region Some cross country scenarios over 300ms Static (e.g. provisioned in handset) I-/S- always local to PCSCF Always assigned in home network Always assigned in home network Static STN-SR; requires capacity engineering; resource utilization considerations Always in home network?
Local P-CSCF/Home region Most cross country scenarios over 300ms Dynamic PGW assisted
Need mechanism to determine UE home region (e.g. regional domain names)
Always assigned in home network Always assigned in home network Static STN-SR ; requires capacity engineering; resource utilization considerations Always in home network?
What if additional app Need dynamic allocation for all servers?
Voice Gap Time Result Summary

- Voice gap times are strongly dependent on transport delays, hence, are impacted by network topology choices. Some network topologies result in more cases of greater than 300ms voice gap times than others for home network SRVCC scenarios - Review of voice gap times associated with three common topology choices suggest that Voice gap times could be reduced to around 300ms for most cases using one of the following techniques :
- Delay HO command by fixed amount, e.g., 100-150 msec
- Higher voice gap numbers reduced by corresponding amount (minimum voice gap of 100-150 msec remains) - Impact on HO performance should be small - Allows acceptable voice gap times with suboptimal network topologies
- Trigger HO command with first detection of downlink media

- Limit maximum HO delay to ~200-300 msec to limit impact on HO perf - Minimize voice gap to 100-150 msec in wider range of cases than 1.
- Higher development impact than 1.
- An alternate option is eSRVCC

- Planned for 3GPP Release 10. Stage 2 Complete, Stage 3 expected to be completed in March 2011. - ALU plans to support eSRVCC in its roadmap when Stage 3 is completely defined in standards.
Voice Interruption Time (from 3GPP TR 23.856)

IMS Bearer before HO b3.Tune to CS b2.HO CMD
UE
MME /eNodB
b1.HO CMD
MSC
a1.Invite a4.200 OK
SCC AS
a2.Offer a3.Answer
Remote
Uplin
CS Bearer after HO
k Uplin
D ow
nlink
MGW
IMS Bearer after HO
nlink D ow
- The voice downlink media flow is interrupted after step a2 or step b2, and restored after both step a4 and step b3 are finished. So the interruption time of the flow is:
- Td = MAX(Ta1+Ta2+Ta3+Ta4-Tb1-Tb2, Tb3)
- Steps (Tb1+Tb2) happen in the network that the UE currently attaches, with few signalling nodes and faster signalling processes. It is reasonable to assume that duration of (Tb1+Tb2) is shorter than the total duration of (Ta1+Ta2+Ta3+Ta4) in roaming case (either the UE or the remote is roaming or both) or the case of the UE and remote are not in the same PLMN. - Tb3 is specified less than 300 ms according to TS 36.133, and normally is about 100 ms
Introducing ATCF/ATGW to reduce voice interruption time during AT

- Ta1+Ta2+Ta3+Ta4 represents the transmitting and processing time delay of the messages for remote update procedure. It is dependent on the serving IMS network of the SRVCC UE, as well as the home IMS network of the SRVCC UE, and the remote network of the remote end. - The interruption time may be worsened in following scenarios:
- The call is inter-operator, with more entities involved; - The remote users is roaming; - The poor performances in any of the networks involved, causing additional delay; - The poor performance of the remote end, causing additional delay; - The access bandwidth is limited.
Conclusion: the study has shown that the performance of SRVCC handover is mainly dependant on the delay brought by the remote update procedure. Thus the introduction of ATCF/ATGW for media anchoring in the serving network to reduce voice interruption time.
eSRVCC- Basic concepts

P-CSCF is in VPLMN An ATCF (Access Transfer Control Functionality ) inserted in the IMS sig. path at REGISTER
- The @ of the ATCF passed to the MME as a STN-eSR
The VATF anchors voice media (in an ATGW) at sip session set-up when relevant
The MSC invoked by the MME at SR-VCC HO issues the SRVCC procedure per REl8/9 specs
- This SRVCC procedure targets the ATCF (STN-eSR) - Access Transfer and UE RAT change performed simultaneously (same concept as Rel9 SRVCC)
Access Leg Serving Leg UE After transfer CS radio MSC Server After transfer ATCF ATGW Home Leg SN HN After transfer Before transfer Mw
I/S-CSCF, SCC AS
Remote Leg
Remote End
Gm UE Before transfer
eSRVCC - IMS Registration

ATCF adds STN-eSR into the REGISTER propagated to the SCC AS SC AS populates the new value of STNeSR in the HSS user data HSS updates the MME/SGSN with the new value of STN-eSR
MSC MGCF CDMA MGW
Remote UE
BTS HSS/HLR
MME E-UTRAN
Enhanced Packet Core (Voice + Data) IMS
IMS Core
TAS
ATCF
SCC AS
eNode B SGW Impacted Entity PGW PCRF
P-CSCF
VPLMN
83
HPLMN
eSRVCC IMS Session Establishment

The ATCF inserted in the sig. path. The ATGW may be inserted in the data plane Access leg between UE and ATCF Home leg between the ATCF and the SCC AS Remote leg between the SCC AS and the remote UE
MSC MGCF CDMA MGW
Remote UE
BTS
HSS/HLR
MME SGSN E-UTRAN

IMS Core
TAS
ATGW
IMS
HSPA eNode B NB RNC
ATCF
SCC AS
SGW Impacted Entity
PGW PCRF
P-CSCF
VPLMN
84
HPLMN
eSRVCC Access Transfer

The SRVCC per Rel9 takes place (no change). The signalling for Call anchoring onto CS domain only needs to go to the ATCF+ATGW (SCC AS no longer receives STN-SR)
1. Voice over IMS 2. SRVCC trigger 3. Voice over CS
MSC
MGCF MGW
Remote UE
CDMA
BTS
HSS/HLR
MME SGSN E-UTRAN

IMS Core
TAS
ATGW
IMS
HSPA eNode B NB
ATCF
SCC AS
SGW RNC Impacted Entity
PGW
P-CSCF
VPLMN
PCRF
85
HPLMN
2d. Solution Architecture Roaming considerations
LTE-LTE : Home routed traffic scenario

PDN GW IP address HSS IP Address PDN GW IP address APN & Default PDN GW ID (FQDN or IP address) vplmnAddressallowed =No
Gx
HPCRF
SG i
Rx
DNS
HSS
PGW
Inter PLMN IP Backbone S8 S11
Home operators IP services
HPLMN
S9
DNS MME
S1-mme
S6a
VPCRF
Inter PLMN IP Backbone required GSMA IR.34
eNB
E-UTRAN
S1u
SGW
S5
PGW
SGi
Data Services (e.g., VPN, FTP)
VPLMN
Principle Most Operators use home routed model. This model consists in routing the traffic back from the visited network to the home PDN GW. Using the home PDN-GW, the subscriber home operator can still connect with the requested external IP networks access public internet access, IMS services or for private networks like corporate networks or web based services. The subscribers profile and security credential will be retrieved from the HSS and the user experience will remain the same as if in home within the capabilities of the visited network and possible restrictions subject to Roaming agreements.
LTE - Local breakout model (new model)

vplmnAddressallowed =yes
HPCRF
Rx
HSS
S9
Home operators IP services
HPLMN
DNS
S1-mme
S6a
MME
S11 S1u
VPCRF
eNB
E-UTRAN
SGW
S5
PGW
SGi
VPLMN
Principle This model consists in using services available within the capabilities of the visited network. The SGW and the PGW are used in the visited network and not require from Home Operator any IP backbone interconnection. The subscribers profile will be retrieved from the HSS in the home network and the user experience will depend of the capabilities of the visited network and possible restrictions that may have been agreed in Roaming agreements. Offer Services not requiring an operator control in the home network (internet access)
IMS Roaming: P-CSCF in Visited network

Gx
HPCRF
SG i
Rx
S-CSCF
DNS
HSS
PGW
P-CSCF
IMS
I-CSCF
HPLMN
DNS MME
S1-mme S6a S8 Inter PLMN IP Backbone IPX S9
VPCRF
P-CSCF
eNB
E-UTRAN
S11
S1u
PGW
S5
SGW
PGW
SGi
VPLMN
Principle
P-CSCF located in visited network : P-CSCF of visited network discuss directly with I-CSCF of home network. I-CSCF is a contact point between visited and home networks.
IMS Roaming Session Flow

Home1 Home2 HSS I B C F 8 I B C F 10 9 TAS 12 I-CSCF 11 S-CSCF 13 IBCF
HSS
TAS 7
6 ENUM S-CSCF 4 IBCF
IPX 3 IBCF Visiting1 2 P-CSCF 15 B G W B G W ENUM
14
IBCF Visiting2
P-CSCF
16
eNode B
1
eNode B
SGW
PGW
PGW
SGW
Originating subscriber is from Home1 and is roaming in Visiting1

Destination subscriber is from Home2 and is roaming in Visiting2
Diameter Routing Architecture (as proposed by GSMA)
Benefits of including Diameter Routing Agents in Diameter Architecture

- Solution to Diameter signalling scalability. Presence of DRA functions will eliminate the geometric explosion of diameter interfaces between clients and servers (e.g., MME and HSS). - DRA(s) will maintain or have access to Subscriber to Diameter Server mapping database to route an incoming Diameter message from a client to the server. - Secure point of interconnect for inbound and outbound roamers.
- A DRA function can provide such interconnection in a secure manner without exposing the internal topology of the operators network. It will determine whether a specific Diameter message is meant for internal HPLMN consumption or for a VPLMN based on the network domain/realm information that identifies the Diameter Server.
3. End User Services
Alcatel-Lucent Offer for Voice Service on IMS Core Elements

Telephony Application Server End User Control & Administration
Alcatel-Lucent 5420 Converged Telephony Server (CTS) Telephony services to any SIP, IP or POTS subscriber, mobile and fixed Residential services Business services PBX trunking Regulatory feature support Scalable, Robust
Alcatel-Lucent 5420 Personal Communication Manager (PCM) End user self-care and administrator management of call features, call logs, voice mail Consistent look-and-feel end user interface via standard web browser Click-to-dial any phone number on any web page
Find me/follow me
Open APIs
Voice in LTE VoIMS related Standards in 3GPP

22.173, IMS Multimedia Telephony Service and supplementary services; Stage 1 22.228, Service Reqs for the IP Multimedia Core Network Subsystem 23.204, Support of SMS over generic 3GPP Internet Protocol (IP) access; Stage 2 23.216, Single Radio Voice Call Continuity (SRVCC); Stage 2 23.228, IP Multimedia Subsystem (IMS); Stage 2 23.237, IP Multimedia Subsystem (IMS) Service Continuity; Stage 2 23.272, Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2 23.292, IP Multimedia Subsystem (IMS) centralized services; Stage 2 24.229, IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3
24.628, Common Basic Communication Procedures

29.864, Service Data Descriptions for AS Interoperabilty 32.260, IMS Charging 32.299, Charging Management Diameter Charging Applications 24.173, Multimedia Telephony Service and Supplementary Services 24.604, Communication Diversion (CDIV) 24.605, Conference 24.606, Message Waiting Indication (MWI) 24.607, Originating ID Presentation and Restriction (OIP/OIR)
24.608, Terminating ID Presentation and Restriction (TIP/TIR)

24.610, Communication Hold 24.611, Anonymous Communication Rejection; Call Barring (CB) 24.615, Communication Waiting (CW) 24.616, Malicious Communication Identification (MCID) 24.629, Explicit Communication Transfer (ECT) 24.642, Completion of Communication to Busy Subscriber (CCBS)
And many, many more

5420 CTS Feature Packages

Feature Packages Silver Residential/Consumer
- Includes MMTel Features
A la Carte Features Attendant Console Deluxe Auto Attendant Hunt Group Queuing
Gold Residential/Consumer
Core Business
Premium Business US Military PBX VPN
Large Call Limit

Location Based Services
Every subscriber is assigned a feature package, and optionally a la carte features Service provider selects which features in the feature package are enabled per sub 5420 PCM subscriber licenses purchased separately Multiple feature packages can be supported per 5420 CTS Feature packages can be customized per service provider
5420 CTS Feature Package Silver Residential/ Gold Residential

-
User Call Services: Anonymous Call Rejection Automatic Call Back Automatic Recall Call Barring (Outgoing Calls) Call Blocking (Incoming Calls) Call Completion to Busy Subscriber Call Forwarding:
Incoming Incoming Intl
Generalized Category Names Outgoing Call Barring
Call Waiting Terminating:
Reminder Call Remote Access Service Selective Calling Features:

-
Calling Line ID Related Features:
Advanced Endpoints Flashable Endpoints (INFO Method) TISPAN Simple Endpoint Cancel: Per Call, Mid Call, Persistent Caller ID with Call Waiting Calling Line ID Presentation, Restriction, w/ Override Connected Line Identity Presentation, Restriction Calling Name Identification Presentation, Restriction
Call Completion to Busy Subscriber Blocking Completion to Busy Subscriber Bearer-Based Call Forwarding Call Deflection Call Forwarding Always (CFA) (Variable) Call Forwarding Busy (CFB) Call Forwarding Default Call Forwarding Local Call Forwarding No Answer (CFNA) Call Forwarding Password Protected Call Forwarding Unregistered (CFU) Call Forwarding to Voicemail (CFVM) Inhibition of Incoming Forwarded Calls (IIFC)
Calling Party Category (CPC) Conference Calling (3-Way, N-Way, Programmable - SIP and SMDI 3-way, TISPAN) - Message Waiting Indicator Configurable Feature Codes (NANPA Vertical Service Codes) - VM Originated Calls Device Extensions Warmline Dial Code Feature Status Interrogation Do Not Disturb (DND) Additional Supported Services: Dual Mode Service/ Single Number Service Customized Announcements End Point Support
Advanced End-Point Flashable End-Point (INFO Method) TISPAN Simple End-Point
Service Suspension Simultaneous Ringing Speed Dialing (1 or 2 digit) Star Code Access to Voicemail Voice Messaging Interfaces:
Selective Call Acceptance (SCA) Selective Call Forwarding (SCF) Selective Call Rejection (SCR) Selective Distinctive Alerting Wild Card Characters in Screening List
Call Hold Consultation Call Transfer Features:
Call Transfer with Consultation Call Transfer Blind (Local, Network with Dedicated Access Code, - Multiple Directory Number - Distinctive Ringing with Call Waiting Network from 3-way call) Call Transfer from 3-way Personal Ring Back tone (PRBT) Timed Reminder on Transfer Phone Context
Hotline Intercept Referral Multiple Ring Patterns
Directory Service Fax Local Number Expansion to National Number Lucent Communication Manager User Interface Overlap Digit Sending Shared HSS Data (with Alcatel-Lucent USDS) Terminating Feature Precedence Video Call Point to Point
Incremental Services in Gold Package:

Basic Auto-Attendant Multiple Subscriber Number (MSN) Music on Hold Time of Day/ Day of Week setting for several supplementary services via PCM User Controlled Call Barring via CM
Example 5420 CTS Feature Package Core Business/ Premium Business

-
User Call Services: All supplementary services in the Silver Package, plus: Account Codes Authorization Codes Basic Auto-Attendant Call Park and Call Pick-Up:
Call Park and Retrieve Hard Hold
Additional Supported Services: DID/DOD Communication Manager User Interface Voice VPN via PDP and Closed User Group
Incremental Services in Premium Package:
Directed Call Park and Retrieve

Call Pick-Up Directed Call Pick-Up Directed Call Pick-Up with Barge-In
Music on Hold
Time of Day/ Day of Week settings via CM User Controlled Call Barring More to be added in future releases
Closed User Group

Closed User Group Call Limit
Direct Dial to Voicemail Flexible Calling Line ID/ Group ID Delivery Multi-Line Hunt Groups
Sequential, Circular, Uniform Hunting
Member(s) Make Busy, Group Make Busy, Stop Hunt No Hunt Member
Organizational Support Private Dial Plan

Extension Dialing Private Dialing Extension Display
Sequential Ringing Transfer to Users Voicemail Mobile Extension and Virtual Office
Modified cdc 29 oct 2010 5420 CTS Supports Subscriber Features Provided re-integrate By 3G MSC
Subscriber Features
Calling Line ID Presentation
Subscriber Features CAMEL (see next slide)

Pre-paid VPN Personal Ring Back Tone Smart Limits Abbreviated Dialing
Calling Line ID Restriction

Calling Name Call Forwarding Unconditional Call Forwarding on MS Busy Call Forwarding on No Reply Call Waiting Call Hold Multi-Party Services Call Barring of All Outgoing Calls Call Barring of All Outgoing International Calls Barring of All Outgoing Calls except directed to Home PLMN Country (BOICexHC).
Regulatory Features (see next Section)

Emergency Service (E-CSCF Based)
Support for standard CTM for deaf (Cellular Text Modem) Support for Lawful Intercept (CSCF Based) Support for Mobile Number Portability Malicious call trace
Hotline
Operator Barring Unstructured Supplementary Service Data Subscriber Programming Voice Messaging Location Based Services
Provided fully by 5420 CTS IMS Standards Based Offering
Feature Support For Legacy WIN Features

The following features are traditionally provided in wireless networks using WIN services. In IMS they can be provided using alternative methods as described below:
- Prepaid
- Prepaid services provided using the 3GPP standard Ro interface - 8610 ICC app server can provide the prepaid service logic
- VPN
- CTS can support up to 3,000 private dialing plans in support of VPN service
- Personal ring back tone

- CTS, with the MRF, can provide personal ring back tones when callers call a user. - In addition we have a full-feature 5900 PRBT application server
- Smart Limits
- CTS and PCM have a rich set of services to control calling behavior, including:
Selective call acceptance to block all calls except from certain numbers Selective call rejection to block only certain numbers Ability to set times during which calling is allowed
- Abbreviated dialing
- CTS supports speed dialing (1 or 2 digits). - Can be programmed either through touch tones or the PCM web portal
Subscriber Programming of Supplementary Services

Two methods are currently defined in 3GPP 23.173 (section 4.3) for supporting subscriber configuration (e.g. to configure call forwarding number):
- Use of Ut interface (XCAP/HTTP) - Use of * xy star codes
GSMA VoLTE profile has made support for the Ut option mandatory
- Unlikely they will make support for any other option mandatory
Additionally the spec recognizes that other options are possible, such as the use of a web portal, but these are outside the scope of the specification ALU will need to support the Ut interface when UE are available that support it
- Ut through data connection. Feature updates during a call are buffered until the call releases - Will be supported through PCM - For trials we will use the web portal interfacing to PCM as interim - Continue to use *xy codes for per call features or if Origination Anchoring in IMS
CTS Interworking with Voice Mail Systems

Custom Client
http
5420 PCM
5100 CMS (AnyPath)/ Other VM Systems 5420 CTS Residential + Business TAS 5450 ISC IP Network IP Access Fixed & Mobile
John Bill Susan
SIP-ISC
Published APIs
SIP-ISC
Sh
8650 SDM
John Bill Susan
VoIP Mobile Phone
Custom Client
SIP Endpoint
Soft Client
CTS redirects calls to VM number configured for subscriber CTS forwards MWI status to endpoints MWI status also reported to web portal using PCM APIs Star Code Access to VM CTS interworks with 5100 Converged Messaging System (CMS) as well as many other VM Systems
4. Regulatory Services
Regulatory Services: LI / CALEA
Lawful interception
Requirement
- National requirements to handle lawful interception
Solutions
- CSFB: Visited PLMN MSC based solution
- VoIMS: Home and Visited PLMN IMS solution as per 23.107
Applicable standards:
- 3GPP TS 33.106, Lawful interception requirements, Stage 1 - 3GPP TS 33.107, Lawful interception architecture and functions - 3GPP TS 33.108, Handover interface for lawful interception - ATIS TI.678 LAES for Voice over Packet Technologies in Wireline Telecommunications Networks
Lawful Intercept Architecture

For simplicity, not all interfaces/connections are shown. Bearer & Control 8650 HSS
Provider/LEA
Control Only
eNodeB
HI
9471 MME eNodeB 7750 SGW

5750 PCRF 7750 PDN-GW
IRI
UE
1357 ULIS / SS8
IRI
CSCF IMS SBC

Managed Core Network
NodeB UE
PSTN
RNC
SGSN
GGSN
PDN
---> - Admin (X1) IRI Intercept Related Information (X2) CC Content of Communications (X3) SBC Session Border Controller CSCF - Call Session Control Function
Alcatel-Lucent Solution: 1357 Unified Lawful Interception Suite (ULIS)

Unique Interception Management Center (IMC) handles lawful interception administration function:
Centralizes management of all lawful interception orders, particularly warrants activation or deactivation. Concentrates all IRI received from the LIGs and transmits it to the LEMF/MC. Provides single management across all domains. Distributed Lawful Interception Gateways (LIG) handles IRI & CC mediation functions: Generates and delivers IRI and CC according to the network topology and the LEMF or MC. Number of LIGs depends on the network size and the targeted traffic flows. According to CC delivery type toward LEMF/MC, the LIG architecture can be circuit switched (LIG CS) or IP (LIG IP). Distributed Lawful Interception Probes (LIP) handles Internal Interception Function: Can generate internal IRI or CC when no active solution is available in the Core Network.
Converged IMS Legacy Wireline

Internal Interfaces
LTE
IMC
Administration Function
LIGs
IRI & CC Mediation Function
LIP
Legacy Wireless
Standardized External Interfaces
LEMF/MC
IRI: Interception Related Information CC: Content of Communication LEMF: Lawful Enforcement Monitoring Facility MC: Monitoring Center
Alcatel-Lucent Lawful Interception Solution

Mapping of the main functional entities
Network Operator domain Mediation
IMC
Administration function
LEA domain
HI1
LEA
Network Internal Functions
Intercept Related Information (IRI)
IRI mediation function
HI2
LEMF
Content of Communication (CC)
CC mediation function
HI3
IIF
Internal Interfaces INI
LIG
External Interfaces HI
LIP
1357 ULIS functions are mapped on Standard LI Model

Lawful Intercept General Voice Requirements IMS VOIP

It is a requirement to report forked/spawned calls by application servers or other B2BUAs on behalf of surveillance subject It is a requirement to intercept forwarded calls/redirected calls, transferred calls, 3-way or multi-way calls, conference calls, or any other call scenarios that will be made available to subscribers as part of the service offering SIP URI and tel URI shall be supported as target IDs If reasonably available, a subjects location shall be reported when a call is made or ended Intercept jurisdiction shall be supported
- Jurisdiction shall be either one specific state, multiple states, or nationwide
Regulatory Services: Emergency Services
Emergency Services
Requirement
- National requirements to handle (and route) emergency call and corresponding location mechanism to be supported
Solutions
- CSFB: MSC based with 3G sourced location - VoIMS: As per 23.167 (release 9)
- VPLMN located E-CSCF plus MME and SRVCC extensions in Release 9
- Requires IMS based PSAP database in addition to existing MSC database
CSFB emergency services: 3G1x
LTE-3G1X offers two approaches to CSFB and legacy emergency services. They are:
- Dual transceiver solution; and - Circuit Switching Fallback (CSFB) solution with single transceiver (single transmitter and single/dual receiver)
Emergency Services in LTE (VoIMS) High Level Architecture/Call Flow

5. Request Location Info
Emergency Service Network
GMLC/LRF
8. Location Info Response (x,y)
6. Retrieve Subscriber Location from E-SMLC
E-SMLC
3. Request ESRN from LRF
MME
7. Retrieve Location data from UE or eNB
P-CSCF
E-CSCF
MGCF/MGW
4. Route Call to PSAP
PSAP
2. P-CSCF recognizes emergency call and routes to E-CSCF
eNB
E-UTRAN
1. UE Initiates Emergency Call
SGW
PGW
Map x,y to street information.
Note: As part of the Emergency Attach or Emergency PDN Connectivity Request procedure the MME sends Location Report to GMLC containing UE identity, UE positioning capability and the MME IP address.
Regulatory Services: Number Portability
Number Portability
Requirement
- Support porting out and porting in of LTE subscribers to/from another service provider
Solutions
- CDMA: Current NP solutions in place in CDMA networks
- Triggered at MSC using ANSI-41 NPREQ queries to NP SCP DB
- VoIMS: Current NP solutions in use in IMS based network

- NP data stored in ENUM Servers; Query performed by S-CSCF/IBCF
- NP data stored in regional/country wide NP DB; Query performed by MGCF/IBCF
- Both solutions already supported by ALU products in our LTE solution
Number Portability High Level Flow in IMS using ENUM Server

1.
2. 3. S-CSCF performs ENUM on Terminating DN ENUM returns e2u+pstn with routing information (e.g. RN and NPDI indication or routing prefix) For ported out to IP, ENUM could return e2u+sip S-CSCF routes to i) BGCF or ii) IBCF based on ENUM service e2u+pstn/e2u+SIP BGCF routes based on routing information to i. MGCF for PSTN/PLMN termination ii. IBCF for IP termination (Route header = IBCF, Route header = proxy in IP network) IBCF routes on Route header = proxy in IP network
5,
ENUM
1
2i
3i
S-CSCF
2ii
BGCF
3ii
MGCF
PSTN/PLMN Networks
IBCF
IP Networks
Number Portability High Level Flow in IMS using NP DB

1. 2. 3. 3. 4. S-CSCF performs ENUM on Terminating DN ENUM returns NXDOMAIN S-CSCF routes to BGCF BGCF routes to MGCF MGCF performs NP query if the called number is within range of list of ported out numbers MGCF routes to PSTN/PLMN/IP
NP DB
4 5i 2 3 5ii 6i
PSTN/PLMN Networks MGCF MGCF

5iii 6ii
S-CSCF
1
BGCF
ENUM
IBCF
IP Networks
Regulatory Services: TTY/TDD
TTY/TDD Support in LTE
UPDATE for CDMA
TTY/TDD service will be a regulatory mandate for voice over IMS

The service is of such high priority that 3GPP is working the introduction of standards in TS 23.226 as a set of CRs in 3GPP Release 9 Key capability required for LTE/IMS solution is trans-coding between V.18 and GTT-IP (Global Text Telephony/RTP) in the MGCF and MGW
V.18
GTT-IP
New Transcoding
Regulatory Services: GETS
Regulatory Features GETS - Introduction

GETS standards are in the process of being defined and drafts are available:
- National Security/Emergency Preparedness (NS/EP) Internet Protocol (IP) Multimedia Subsystem (IMS) Core Network Industry Requirements (IR) for Next Generation Network (NGN) Government Emergency Telecommunications Service (GETS), Phase 1, Voice Service - National Security/Emergency Preparedness (NS/EP) LTE Access Network Industry Requirements (IR) for Next Generation Network (NGN) Government Emergency Telecommunications Service (GETS)
Implementation of GETS not planned pending government funding
Regulatory Features GETS Work items

The following enhancements are expected in support of GETS:
- Provide priority treatment to GETS users in LTE
- Mainly affects eNB admission control algorithm, some impact on PCRF
- Support priority paging of UE in LTE when terminating calls from GETS user - IMS TAS and ISC need to recognize specific GETS calls and GETS prefixes and provide GETS treatment, including assuring priority treatment is provided for the call - MGC-8 needs to recognize GETS calls and provide appropriate GETS treatment, including mapping priority from SIP to ISUP
Current view is that GETS is not required for voice introduction

Provisioning and Subscriber Migration
OAM&P Overview
The EMS and NMS in the end-to-end LTE OAM solution can be grouped into three parts:
1. 2. LTE (and IP Router)-specific EMS
5620 SAM
Common NMS
8950 SAM required flow-thru subscriber provisioning 8615 IeCCF for offline charging 8610 ICC for online charging Note 1357 ULIS is managed independently
3.
IMS-specific EMS
1360 COM
The next slides shows the end-to-end architecture and the roles the various EMS/NMS support
OAM&P Management Architecture (Fault, Configuration, Performance Mgmt)

Customer FM/PM OSS FM: SOAP XML/ PM: SFTP JMS
CM FM, PM
8950 SAM/ Customer OSS
FM: SNMPv2c PM: SFTP of XML Files
5620 SAM
1357 ULIS 5110 SMSC-C
CM: SOAP XML/ CORBA

CM
1360 COM
XMC
OMC-P
CM FM, PM
9400s eNB
CM FM, PM
7750 PGW 7750 SGW
FM, PM CM FM, PM
VitalQIP
E-NUM DNS DHCP
FM, PM, CM FM, PM

5900 MRF
FM, CM CTS SCG ISC

5420 PCM
FM, PM, CM
MGC-8
FM FM
8950 AAA
5780 DSC
9471 MME
8650 SDM
IeCCF
HSS/SPR
MRF
Portal
MGCF
7510 MG
8610 ICC
OCS
MGW
5025 SG
VSG
LTE Common
IMS
OAM&P Management Architecture (Accounting)

Customer BSS ftp (CDR) ASN.1 BER (3GPP standard)
8610 ICC
8615 eCCF
Ro Diameter Rf diameter
BTS
CTS SCG ISC

Only from IMS-GWF
7750 SGW
7750 PGW
MGC-8
MGCF
OAM&P Overview
1360 Com (merged OMC-P/XMC) provides:
- Full FCAPS support for CTS, PCM, SCG, and IMS Core components - Centralized operations making it easy to manage
Features Include:
- Fault Management (FM)
- Alarm Display, Forwarding, and Filtering
- Configuration Management (CM)

- Java-based Client GUI and SOAP XML API for flow-thru provisioning
- Performance Monitoring (PM)

- Collect, analyze, display data, and provide interface to northbound OSS
- Security
- Extensive password controls and 5 default user levels - Customizable Node and Switch Access Lists - SSH, SSL, RADIUS Authentication
OMC-P/XMC - Scalability
Current architecture scales with equipment modules
- A new 1360 COM server is added for each 4 million subscribers
Planned enhancements to system scalability:

- Adding provisioning queues per FSDB to increase provisioning rates
- Planning additional tuning to further leverage multiple processors and cores within the system server - Single sign-on will help make multiple 1360 COM systems operate as a cohesive unit - Continue to leverage advances in hardware technologies to increase capacity of a single 1360 COM System
Roadmap
LTE Solution High-level Roadmap

2010
Q1 Q2 LE2.0/2.1 High Speed Data 3GPP Alignment R8 Jun 09
eNB 5,10,20 MHz bandwidths FDD: 700,AWS, 800, 2.6 TDD: 2300,2600 2x2 MIMO: TxDiv, OL, CL VLAN, IPsec, GPS, SyncE MME/SGSN/PCRF: ATCAv2 SGW/PGW/GGSN: 7750SR SON: Plug&Play, ANR
Released In Development Under Plan
2011
Q4 Q1 Q2 Q3 LE4.0 Q4 Q1 LE5.0 LE3.0/3.1
2012
Q2 Q3 Q4 LE6.0+
Q3
Seamless interworking and Capacity management and Mass market VoLTE basic voice VoLTE introduction and service optimization
R8 Dec 09
eNB Additional bands eMCTA ph1 IEEE 1588v2 TDD 8 Tx/Rx beam form. SGW/PGW/GGSN: Converged GGSN/PGW SAM Converged OAM (ePC+ Backhaul + RAN)
R9 Sep 10
eNB Addtnl. bands/bandwidth 4RX div, extended cell Semi-pers. sched., RoHC eMCTA Ph2 SGW/PGW/GGSN: Converged SGW/PGW SON: IRAT ANR SAM conv. OAM (+WCDMA) Mobility ph3 (1x) CSFB Ph2 (eCSFB, GSM, 1x) E2E call trace Use limit ph1 (Gx and QoS) Subs. tiers ph1 (AMBR, QCI) Network Share Ph1 (MOCN) Public Safety Ph2 (Priority) CMAS (Warning system) VoLTE Ph2 (GSMA comply) Local Breakout E2E Validation
R9/10 TBC
eNB enh. MIMO eMCTA Ph3 ICIC Metro cell / SNAP MME/SGSN: Idle signaling reduction Priority paging SON: mobility,outage QoS enhance. (FIR, MBR) Mobility ph4+ (TDD<>FDD) PCMD enhance. (+IMS)
Scalability and cost efficiency
Enriched Quality of Experience
Mobility ph2 (enh.3GPP) Mobility ph1 (Intra LTE, CS Fallback Ph1 (WCDMA) GSM, WCDMA, eHRPD) 8 EPS bearers per UE Guaranteed Bit Rate 4 EPS bearers per UE Per call meas. Data (PCMD) SMS over SGs Voice over LTE Ph1 (VoLTE) Roaming (Home PGW) Public Safety Ph1 (Deploy) eMBMS Ph1 (TDD)
Use limit ph2+ (Sponsor)

Subs. tiers ph2+ (MBR,GBR)
New Business Models & Apps. Enablement
VoLTE Ph3+ (SRVCC, ICS, roam, IRAT) eMBMS ph2 (FDD, CP) Net. Sharing Ph2+ (Core) Pub.Sfty. Ph3+(Pub. Priv.) E2E Validation
Derisk Deploy.
E2E Validation
E2E Validation
130
Supporting Material
Network Element Overview
Network Element Overview Introduction

This section provides an overview of the various network elements added to LTE to support VoIMS Most of the elements are built on the Alcatel-Lucent Linux Control Platform (LCP)
- Used for Session Manager, TAS, and SCC AS - MME and LVI application used in LTE built on same hardware, OS, and OAM infrastructure - 5060 MGC-8 uses same hardware, OS, and OAM infrastructure (2H2010)
Alcatel-Lucent Linux Control Platform (LCP)

with deployed IMS Core network elements. Field proven carrier-grade OAM&P middleware which provides: Alarms Asserts & audits Logging Measurements Realtime performance update
Common OAM&P Infrastructure Session Management Application Servers 2G + 3G MSC Call Processing Device Servers
One Platform, One Code Base, Multiple Real-Time Applications, Multiple Environments Same application software runs on existing cPSB and new ATCA platform; Ensures compatibility
NEW APPLICATIONS
5450 IP Resource Control (PDF, RACF)
WRLS SS7 Device Server
Access Gateway Control Function (H.248)
5450 IP Session Control (I/P/S/E-CSCF/BGCF)
5420 Service Continuity Gateway
H.248 Device Server
MSI Call Processing
Future Application
SS7 Device Server
IOS Device Server
5420 Converged Telephony Server
Management Interface
LVI Application LIF / LAF) MME Application (MIF / MAF)
Database / iHSS
Configuration
5060 MGC-8
CDR / iCCF
Evolved to next generation ATCA hardware for increased performance and capacity
Protocol-Assist Communications Bus Common OAM&P

Switchover, Software update, Audits, Measurements, Data Base, Asserts, Alarms, Security (e.g., IPsec, SSH, Central PW mgt, OS hardening, etc.)
Hardware & OS Interface Wrappers Red Hat Enterprise Linux 5 AdvancedTCA (PICMG3.x) Full-Size Compact MontaVista Linux CGE4.0 cPSB (PICMG2.16) Full Frame Compact
Solid field proven software and middleware on next generation hardware

5450 IP Session Control Function (5450 ISC) Scalable SIP Session Control
Performance & Modularity
- ATCA PICMG 3.1 based solution
Platform used by many ALU products In-house design for most components ~ 5K shelves and 40K blades already deployed
PDU
Grown in 1 pair increments Each blade pair supports ~780K residential subs
Full redundancy (1+1 within shelf)

Automatic switchover to standby blade Hot swappable In-service growth/degrowth ETSI/NEBS compliant
ISC ISC ISC ISC Ethernet Switch Ethernet Switch ISC ISC ISC ISC ISC ISC ATCA Switching Processing Disk-full Processing Disk-less
ShMC ShMC
- Single shelf supports ~3.9M subs - Single cabinet supports ~7.8M residential subs
1 2 3 4 5 6 7 8 9 10 11 12 13 14
OAM
OAM
ISC ISC ISC ISC Ethernet Switch Ethernet Switch ISC ISC ISC ISC ISC ISC ATCA
5450 ICS
ShMC ShMC
Each blade has two Quad-core processors (IMS 9.2) Shelves are independent 1 pair of blades per shelf for high capacity Ethernet switching 1 pair of blades in shelf providing OAM, FSDB and CTS functions 1 to 5 addl blade pairs per shelf providing IMS Session Resource control functionality (P/I/S-CSCF, BGCF)
5450 ICS
1 2 3 4 5 6 7 8 9 10 11 12 13 14
OAM
OAM
5420 Converged Telephony Server (5420 CTS)

PDU
Performance & Modularity

Same ATCA platform as used for 5450 ISC Each blade has two Quad-core processors (IMS 10.0) Shelves are independent 1 pair of blades per shelf for high capacity Ethernet switching 1 pair of blades in shelf providing OAM, FSDB and CTS functions 1 to 5 addl blade pairs per shelf with FSDB and CTS
Each blade pair supports ~850K residential subs
5420 CTS
FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS Ethernet Switch Ethernet Switch FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS ATCA 1 2 3 4 5 6 7 8 9 10 11 12 13 14
OAM + FSDB + CTS OAM + FSDB + CTS
- Single shelf supports ~5M subs - Single cabinet supports ~10M residential subs
Full redundancy (1+1 within shelf)

Automatic switchover to standby blade Dynamic subscriber-to-blade assignment when using Centralized Subscriber DataBase (CSDB) Hot swappable In-service growth/degrowth ETSI/ NEBS compliant
5420 CTS
FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS Ethernet Switch Ethernet Switch FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS FSDB + CTS ATCA Switching Processing Disk-full Processing Disk-less 1 2 3 4 5 6 7 8 9 10 11 12 13 14
OAM + FSDB + CTS OAM + FSDB + CTS
ShMC ShMC
ShMC ShMC
5420 Service Continuity Gateway (5420 SCG)

5420 SCG shares a common software load with 5420 CTS, 5450 ISC, 5060 ICS, etc.
ALU Linux Control Platform (LCP) components
IMS Call Server (Card name: NSCG)
PDU
- B2BUA and call processing

Registered sub DB - Per subscriber registration data SS7 - SCCP/SIGTRAN M3UA interface for ANSI-41/ETSI/WIN/MAP/CAP interfaces OA&M Server - Management interfaces for OA&M - aka Management Interface Agent (MI-Agent)
SCG (ATCARouzic) Subscriber Capacity/ Cabinet Availability ~1.4M (two chassis) 3Q10
SCG R8 (ATCA-Molene) ~7.2M (two chassis) 1H11
OAM Server OAM Server
Traffic Assumption -- 100% of the subscribers are IMS registered

5420 PCM Overview

- Enables end user control and management of CTS based features
- Web browser option
- PC Client option
- Integrates with CTS to expose APIs for user several user interface options
- Also includes APIs to other IMS Apps Servers ( PS/XDMS, MMIM, etc )
- PCM 7.0 Available on commercial rack mount server HP DL380 G6
- Capacity
- 2.0 BHCA: A-node: 600K subs, D-node 1M subs ( est ) - 1M subscribers, geo-redundant
- 4 A + 2 D nodes
- Approx 3M subs per cabinet
- Designed for 99.999% reliability

5020 MGC-8 overview (Today)

Future-Proof Investment
- Multiple Applications Support - NGN Class 4 Local, Access, and Toll Tandems - CDMA Gateway MSC (GMSC) - IMS Media Gateway Control Function (MGCF) - Interconnection Border Control (IBCF) - Multi-Protocol Support for legacy and converged network operation
- Seamless migration from legacy TDM to VoIP to

Highly Scalable Converged IMS on same platform
Up to 7 processor pairs per chassis for call processing Scales up to 4M BHCA for Class 4 configuration No single point of failure In-service SW upgrades Failovers with no loss of standing calls or billing records Geographic redundancy available
AT&T
5 9s Reliability -
5060 MGC-8 overview (2H2010)

Future-Proof Investment
- Multiple Applications Support - NGN Class 4 Local, Access, and Toll Tandems - CDMA Gateway MSC (GMSC) - IMS Media Gateway Control Function (MGCF) - Interconnection Border Control (IBCF) - Multi-Protocol Support for legacy and converged network operation
- Seamless migration from legacy TDM to VoIP to Leveraging ATCA

Converged IMS on same platform
MGC-8 Features on an Industry Standard ATCA Platform Leverages Common Hardware and Procedures with other IMS Network Elements (5450 ISC, 5060 ICS, 5420 CTS, etc) Opportunity for equipment co-residency Planned Capacity Greater than ALGP Platform Mid 2010 for trials, Deployment with IMS 9.0
Availability: -
7510 Media Gateway overview

7510 Media Gateway
1500+ units shipped worldwide 15 MGCs supported 120 32,000 DS0 IP-TDM 32,000 sessions IP-IP
Purpose-built for IP media networking; flexible; low TCO IP-to-TDM, IP-to-IP, TDM-to-TDM (zero latency) Rich CODEC suite (G7xx, AMR, GSM, EVRC-x ,G.728, HDVoIP) Multiprotocol, full standard profiles (H.248 Mn/Ia, SIGTRAN IUA/MxUA, SIP 7515) Strong silicon application accelerators (IPsec, ATCA AMC daughter boards, and so on)
NEBS, CE, MII and national certifications Superior flexibility and cost efficiency to support traffic growth and service innovation
Packet Ports Packet Ports Packet Ports Packet Ports Packet Ports N+1 Media N+1 Media Media IP/TDM switch Control Control Circuit switch Ports IP/TDM Media Media Media Circuit Ports N+1 Circuit Ports Circuit Ports Circuit Ports Circuit Ports CIMs MCMs SCMs, SFMs MCMs PIMs
Sample configuration (TGW)
5900 Media Resource Function (5900 MRF)

Provides advanced media functions such as:
- Fixed audio and video announcements - Variable audio announcements
- IN-type variable parts support (price, duration, date, time, number, integer)
- Channels mixing for audio conferencing purpose - RTP streams duplication for legal intercept (audio and video) - Text-to-speech (option)
- RTSP Audio and Video streaming
DTMF detection Codecs:

- Audio: G.711 a/-law, AMR-NB (all bit rates), G.726, G.729A, EVRC, EVRC .0, G.722.2 (AMR-WB) - Video: H.263, H.264
Various HW platforms to server individual customer need Can be pooled for high availability
VitalQIP IP Address Management Solution
VitalQIP Key Features

Full IP Management Software
Holistic IP Network View Manage DNS domains, DHCP scopes, IP networks, subnets and objects Manage IP network and DHCP scope utilization Millions of IP addresses Hundreds of thousands of domains Highest Performing DHCP Server Exodus Labs certified Administrator access security Secure configuration pushes Secure DNS updates
High Availability
DHCP Failover, DNS master/slaves Audit Manager, Services Manager, SNMP Module, Network Allocator, Usage Billing Interface, API Toolkit, AutoDiscovery, Workflow Manager, Registration Manager, ENUM, DHCP Rules Manager Continuing support of Microsoft W2K DNS/DHCP Servers Active directory support integration Simplifies creation and tracking of DNS and DHCP information Variety of GUIs simplifies information entry and formatting
Extend Management Capabilities

-
Market Proven Scalability

-
Windows 2000/2003 Support

-
Industry Leading Performance

-
Security
-
Usability
-
Charging call flows in SRVCC context Alcatel-Lucent implementation
Scope (1/2)
The subject of this presentation is the call flows for charging (online and offline) in the context of SRVCC with Alcatel-Lucent LTE-IMS solution
When the call is established When the user moves from LTE to CS
The same PGW is considered for data (IMS based data i.e. IM, chat, RCS like applications) and voice
The data like internet, video streaming, without IMS is not considered
In the following call flows, we consider that the Attach procedure has been done. As a consequence, the default bearer (allowing the always on connection) as well as the SIP signalling dedicated bearer has been created. QCI 5 is assigned to this bearer for SIP signalling so that it gets a higher priority than the default bearer carrying the usual traffic for Internet-access.
The Register message is vehiculed on this bearer. In consequence, the following call flow assumes the SIP Registration has been done.
On the IMS APN, a dedicated bearer is established dynamically at voice call setup and released at voice call termination using interactions with the P-CSCF and PCRF (Rx interface) to apply the dynamic PCC rules 3 legs have to be considered:
leg 1 between the calling UE and the SCC AS through the EPC (the user is in LTE network) leg 2 between the SCC AS and the (remote) called party leg 3, after the HO, between the calling UE and the SCC AS through the MSC server/MGCF
Scope (2/2)
3 levels of charging information could be grouped (correlated) to provide a unique CDR for end-to-end session to Billing, by using correlation id exchanged between different levels The same should be applied in online charging using same charging group avoiding to make separated accounts reservation at each different level Here is the list of correlation identifiers exchanged & inserted within CDR:
Intra-level correlation Bearer Domain: LTE Charging (GCID) : GCID is generated by the PGW at bearer Context activation SGW & PGW shares same GCID Session Domain: including Application Servers IMS Charging ID (ICID) transferred all along SIP session between NE. ICID is generated by the P-CSCF, MGCF, AS (Rule : first node creates ICID)
Inter-level correlation : 3GPP provides mechanisms to enable operators for PS domain and IMS Domain CDR doing a correlation: during session establishment PGW and P-CSCF exchange GCID and ICID. Then GCID and ICID are conveyed within the signalling part to feed all IMS NE Inter-network correlation used either for interconnect billing or reconciliation (roaming not shown here): Inter-operator Identifier (IOI): Origin-IOI and Term-IOI
A first ChargingID or GCID is allocated for the access part (LTE). An ICID is created by the P-CSCF for the charging session for the network part (IMS) A second GCID will be created with the dedicated bearer used for the voice traffic Cf 32.260 Chapter 6.3.1.1, GCID is provided from following AVP: 3GPP-Charging-Id AVP included in PS-Information AVP
Voice Call Handling -VoLTE Call establishment MO from LTE user to an IMS-user served by different S-CSCF (1)
eNB
Call setup
MME
SGW
PGW
PCRF
P-CSCF
S-CSCF1/ IMS-GWF
CDF/OFCS
TAS
SCC AS
OCF/OCS
UE2
Service request & authentication
GCID1 created for the signalling
ICID is created for this session (network part)
UL data (SIP Invite)
Invite (caller ID)
Invite
Invite (caller ID) Invite (called ID) Invite Invite Ro: CCR-E for CLIP*
Ro: CCR-I for SIP session
Ro: CCA-E
Ro: CCA-I 180 Ringing
S-CSCF2 not represented, CDR created with this entity
Invite (called ID)

180 Ringing
180 Ringing
Policy decision: QoS and charging (PCC rule)
180 Ringing
180 Ringing
180 Ringing
180 Ringing
Rx: AAR (ICID) Gx: RAR
Allocate S1 and radio Bearer for RTP dedicated bearer
Create Bearer Request

Radio procedures for the creation of the dedicated bearer
Gx: RAA
Rx: AAA
In green: online charging In blue: offline charging
Create Bearer Response
GCID2 created
*other supplementary services are possible

Voice Call Handling -VoLTE Call establishment MO from LTE user to an IMS-user served by different S-CSCF (2)
eNB MME SGW PGW PCRF P-CSCF S-CSCF1/ IMS-GWF CDF/OFCS TAS SCC AS OCF/OCS UE2
All IMS messages not shown (e.g. PRACK)
200 OK Ro: CCR-U for IMS session update Ro: CCA-U

Linked to the remote leg
Rf: ACR Start Rf: ACA
200 OK
Rf: ACR Start 200 OK Rf: ACR Start Rf: ACA 200 OK Rf: ACR Start Rf: ACA 200 OK Rf: ACR Start 200 OK Rf: ACR Start 200 OK 200 OK 200 OK Rf: ACA
Linked to LTE leg
Rf: ACA
Alcatel-Lucent solution is flexible to offer several configurations for the creation of the CDR
Rf: ACA
In green: online charging
In blue: offline charging


Voice Over LTE

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Voice Over LTE

Încărcat de

Drepturi de autor:

Formate disponibile

1 COPYRIGHT 2011 ALCATEL-LUCENT. ALL RIGHTS RESERVED.

ALCATEL-LUCENT INTERNAL PROPRIETARY USE PURSUANT TO COMPANY INSTRUCTION

Voice and SMS in LTE Technical Overview

Voice in LTE Introduction

In an attempt to ease introduction of voice in LTE, phased approaches are available:

Market and network trends impacting voice solution for LTE

LTE rollout will be similar to 3G

SMS solution typically required from day 1

- Voice service may be controlled using IMS servers and applications

- Voice service to be available while roaming on other LTE networks

- Possibly CSFB and/or SRVCC support in MSCs

- No additional requirements imposed on roaming partner networks

Options for Supporting Voice and SMS with LTE

Simultaneous Voice and LTE (SVLTE)

Voice over LTE (VoLTE)

Voice with LTE and CDMA Networks Standards

- C.S0097: E-UTRAN cdma2000 1x Connectivity and Interworking Air Interface

GSMA VoLTE (formerly referred to as OneVoice)

Full range of terminals; earliest test 2H2011; deploy 1H2012

Option for data only devices

VoLTE with DRVCC SRVCC

IMS VoLTE (complete LTE coverage)

IMS VoLTE (complete LTE coverage)

IMS VoLTE/VoIP over eHRPD

IMS VoLTE/VoIP over eHRPD

LTE with Dual Tx CSFB

IMS VoLTE with S102 SRVCC CDMA

IMS VoLTE with S102 SRVCC CDMA

Voice and SMS via S102 CSFB

2a. Solution Architecture Overview: Circuit-Switched Fallback

and SMS over S102

- SMS delivery over LTE using S102 interface

- CSFB client in terminal

CS Fallback - High Level Architecture

New interface S102 from MSC to MME

While carrying data only

No Simultaneous Voice + Data

Circuit Voice Data

CS Fallback: Roaming Considerations

UE stays in current RAT

UE reselects to other RAT

CS Fallback Benefits, Costs, and Limitations

- Applicable to LTE roamers whose home network is not IMS capable

2b. Solution Architecture Overview: Simultaneous Voice and LTE (SVLTE)

Simultaneous (Circuit) Voice and LTE (SVLTE)

Circuit Voice Data

SVLTE is not known to have traction among 3GPP operators

Device Options Two Example Device Solutions

- Simultaneous 1x Voice with eHRPD (EV-DO) Data

- Qualcomm 2-chip initial solution: Fusion

- MSM8655 supporting 1x Voice and Smartphone operating system

CSFB Dual Receiver for LTE data and 1x CS Voice

2c. Solution Architecture Overview: Voice over LTE

VoLTE Required Solution Enhancements

VoLTE Alcatel-Lucent Products

Elements added for IMS

7510 MG 5420 PCM 5060 MGC-8

5420 CTS (TAS)

Enhanced Packet Core (Voice + Data)

94xx eNB 7750 SGW 7750 PGW

VoLTE Required LTE E-UTRAN Enhancements for VoIP Delivery

Delay management for VoIP QoS control

Semi-persistent scheduling for VoIP

IMS core with Telephony Application Server (TAS)