Title: Type: Arial Bold Size ： 32-36pt Color ： The theme blue Subtitle: Type ： Arial Size ： 24pt Color: The theme gray Title: Dynamic STN-SR /VDN for SRVCC call Source: David Brombal: Ke-Chi Jang: Abstract: Dynamic STN-SR/VDN support for SRVCC call Recommendation: Discussion and adopt. © 2014, Ericsson, All rights reserved. Ericsson grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Ericsson is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non- discriminatory terms and conditions for purpose of practicing an Organizational Partner's standard which incorporates this contribution. This document has been prepared by Ericsson to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Ericsson. Ericsson specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Ericsson other than provided in the copyright statement above.

Reason for the proposal Current SRVCC proposal for X.S0042 is based on static STN-SR. MSC with stored STN-SR is used for translation/verification Not flexible Not very efficient for roaming scenario Static STN-SR configuration may not suitable for load balancing or future growth management Operators implementing IMS network may look into following areas: Implement ATCF/ATGW to allow local anchoring (as defined in 3GPP) of bearer path ATCF/ATGW solution provides an IMS/VoLTE anchor for bearer in regional locations rather than requiring end-to-end renegotiation 2

Proposal Consideration Take advantage of 3GPP defined ATCF/ATGW to allow local anchoring of bearer path Anchor for bearer in regional locations Better efficiency for roaming scenario May be better suited for load balancing and growth management X.S0042 is open for SRVCC development Timing is right to introduce ATCF/ATGW function. Development of new X.S0042 is inline with operators SRVCC deployment schedules Introducing dynamic STN-SR provides operators more flexibility and is more in line with their core IMS network for VoLTE No drastic changes required to include dynamic STN-SR to existing X.S0042 development ATCF is included as a possible anchoring point for IMS. Believe just minor changes are needed to support dynamic STN- SR (investigation/discussion) 3

Options for supporting dynamic STN-SR 3GPP defined method on supporting dynamic STN-SR MME receives dynamically assigned value and passes it to the MSC 3GPP defined method can not be directly proposed to X.S0042 unless changes are made to multiple nodes and interface protocols Options for X.S0042 Goal: Minimal changes if possible and yet be able to support dynamic STN-SR as defined in 3GPP Option 1: ATCF assigns a suitable VDN value during registration and this is propagated to the UE for use. Option 2: VCC AS saves dynamic VDN/STN-SR value assigned by the ATCF and provides it during handover messaging. 4

Option 1: Proposal high level view During registration, ATCF assigns a suitable VDN value (as defined in 3GPP) The value is passed back to UE as part of the 200OK of a successful registration UE use this VDN value received during registration process - instead of default value if provisioned Benefit and modification required This method (e.g. overwrite static value) allows the static and dynamic approaches to coexist with no conflict Support needed by ATCF and UE in X.S0042 5

Option 1 Continued 6

Option 1 - continued Steps 1-14 are normal IMS registration steps (Ref. TS ) The ATCF includes the “Feature-Caps” header at step 15 (per TS24.237). The number included is a value (or one of a set of values) provisioned at the ATCF for this purpose. The UE saves the underlined/italicized value to use as the STN-SR in subsequent SRVCC attempts. Steps for 3 rd Party Registration and SIP Message are maintained to provide the ATU-STI information to the ACTF for use in subsequent SRVCC attempts (e.g. Figure A of TS24.237). Steps are not needed in the CDMA solution. The values provisioned at the ATCFs (second bullet) are “known routes” in MSC’s of the CS network, following existing procedures. 7

Option 2: Proposal high level view VCC AS save a dynamic STN-SR/VDN value assigned by the ATCF (e.g., the value arrives as part of a 3rd party registration message which is consistent with ) The value is saved as part of an association against the UE During SRVCC handover, use WIN trigger approach, and this STN-SR number is used as the IMRN value, returned to the MSC to control the next stage of routing the call Benefit and modification required Consistent with 3GPP standards for “SRVCC enhanced with ATCF” (on initial setup steps) and X.S0042-C call flow (e.g. Would occur as part of Step 6 or 7 of Figures 36,37) Need to update the role of VCC AS defined in X.S0042 8

Option 2 Continued This figure is from X.S0042-A At step 8, the IMRN will be set to the stored dynamic STN-SR for the UE placing the call The MDN and the VDN in step 7 can be used to identify this as an SRVCC call by the specific UE 9 (Using a figure from X.S0042–A version for descriptive purposes)