36300_CR0276R1_(Rel-10)_R2-106887.doc

5
3GPP TSG-RAN-WG2 Meeting #72 R2-106887 Jacksonville, USA, 15-19 November 2010 CR-Form-v9.6 CHANGE REQUEST 36.300 CR 0276 rev 1 Current version: 10.1 .0 For HELP on using this form look at the pop-up text over the symbols. Comprehensive instructions on how to use this form can be found at http://www.3gpp.org/specs/CR.htm . Proposed change affects: UICC apps ME X Radio Access Network X Core Network Title: CR to 36.300 adding e1xCSFB support for dual Rx/Tx UE Source to WG: Motorola, Hitachi, KDDI, NEC, QUALCOMM Incorporated Source to TSG: R2 Work item code: TEI10 Date: 5/11/2010 Category: B Release: Rel-10 Use one of the following categories: F (correction) A (corresponds to a correction in an earlier release) B (addition of feature), C (functional modification of feature) D (editorial modification) Detailed explanations of the above categories can be found in 3GPP TR 21.900 . Use one of the following releases: R99 (Release 1999) Rel-4 (Release 4) Rel-5 (Release 5) Rel-6 (Release 6) Rel-7 (Release 7) Rel-8 (Release 8) Rel-9 (Release 9) Rel-10 (Release 10) Reason for change: SA2 has agreed to extend the enhanced 1xCSFB procedure in Rel-10 to support dual Rx/Tx UE (see S2-104204). This allows Rel-10 UE which have dual Rx/Tx configuration and enhanced 1xCSFB capability to monitor only the E-UTRAN (i.e. turn on 1x radio only for MO/MT CS calls), resulting in improved battery life. Summary of change: A stage-2 description of “dual receiver/transmitter enhanced 1xCSFB” is added. Rev 1: editorial rephrasing, highlighted in yellow. Consequences if not approved: Networks which have deployed e1xCSFB to enable CS services for single Rx/Tx UE, cannot leverage the deployment to improve battery life of dual Rx/Tx UE which are e1xCSFB capable. Clauses affected: 10.3.2.3.3 Y N Other specs X Other core specifications 23.272, 24.301, 36.331

Transcript of 36300_CR0276R1_(Rel-10)_R2-106887.doc

3GPP Change Request

Page 1

3GPP TSG-RAN-WG2 Meeting #72(R2-106887Jacksonville, USA, 15-19 November 2010CR-Form-v9.6

CHANGE REQUEST

(

36.300CR0276(

rev1(

Current version:10.1.0(

For HELP on using this form look at the pop-up text over the ( symbols. Comprehensive instructions on how to use this form can be found at http://www.3gpp.org/specs/CR.htm.

Proposed change affects:(

UICC apps(

MEXRadio Access NetworkXCore Network

Title:(

CR to 36.300 adding e1xCSFB support for dual Rx/Tx UE

Source to WG:(

Motorola, Hitachi, KDDI, NEC, QUALCOMM Incorporated

Source to TSG:(

R2

Work item code:(

TEI10Date: (

5/11/2010

Category:(

BRelease: (

Rel-10

Use one of the following categories:F (correction)A (corresponds to a correction in an earlier release)B (addition of feature), C (functional modification of feature)D (editorial modification)

Detailed explanations of the above categories canbe found in 3GPP TR 21.900.Use one of the following releases:R99(Release 1999)Rel-4(Release 4)Rel-5(Release 5)Rel-6(Release 6)Rel-7(Release 7)Rel-8(Release 8)Rel-9(Release 9)Rel-10(Release 10)

Reason for change:(

SA2 has agreed to extend the enhanced 1xCSFB procedure in Rel-10 to support dual Rx/Tx UE (see S2-104204). This allows Rel-10 UE which have dual Rx/Tx configuration and enhanced 1xCSFB capability to monitor only the E-UTRAN (i.e. turn on 1x radio only for MO/MT CS calls), resulting in improved battery life.

Summary of change:(

A stage-2 description of dual receiver/transmitter enhanced 1xCSFB is added.Rev 1: editorial rephrasing, highlighted in yellow.

Consequences if (

not approved:Networks which have deployed e1xCSFB to enable CS services for single Rx/Tx UE, cannot leverage the deployment to improve battery life of dual Rx/Tx UE which are e1xCSFB capable.

Clauses affected:(

10.3.2.3.3

YN

Other specs(

X Other core specifications(

23.272, 24.301, 36.331

affected:X Test specifications

X O&M Specifications

Other comments:(

* * * First Change * * *

10.3.2.3.31xRTT CS Fallback

CS fallback to 1xRTT enables the delivery of CS-domain services when a UE is being served by the E-UTRAN [23].

The UE initiates 1xCSFB (e.g. to perform a 1xCS call origination or accept a 1xCS call termination) by using NAS signalling to send a CSFB indication to the MME. The MME then indicates to the eNB that 1xCSFB is required, which triggers the eNB to execute one of the following 1xCSFB procedures depending on network support and UE capability:

-Rel-8 1xCSFB, characterized by RRC connection release with redirection to 1xRTT;

-enhanced 1xCSFB, characterized by 1xRTT handover signalling tunnelled between the UE and 1xRTT network;-dual receiver 1xCSFB, characterized by RRC connection release without redirection information; or

-dual receiver/transmitter enhanced 1xCSFB, characterized by either 1xRTT handover signalling tunnelled between the UE and 1xRTT network, or redirection of the UEs second radio to 1xRTT.The network advertises its support for Rel-8 1xCSFB by broadcasting 1xRTT pre-registration parameters in system information (SIB8). The Rel-8 1xCSFB procedure is the default procedure, when neither enhanced 1xCSFB nor dual receiver 1xCSFB can be performed (i.e. because neither are supported by both network and UE). If Rel-8 1xCSFB is to be performed, the eNB optionally solicits 1xRTT measurements from the UE, and then sends an RRC Connection Release message with redirection to 1xRTT. The UE then performs the normal 1xCS call origination or termination procedure in the 1xRTT access network.

A network which advertises support for Rel-8 1xCSFB may also support enhanced 1xCSFB, in which case the eNB determines to perform enhanced 1xCSFB based on UE capability. If enhanced 1xCSFB is to be performed, the eNB optionally solicits 1xRTT measurements from the UE, and then sends it a Handover From EUTRA Preparation Request message. This triggers the UE to send the UL Handover Preparation Transfer message containing 1xRTT dedicated information. The 1xRTT information is contained inside RRC and S1-AP messages between the UE and MME and in a generic "transfer" message between MME and 1xRTT network. The response from the 1xRTT network triggers the eNB to send a Mobility From EUTRA Command message which includes a 1xRTT channel assignment message that causes the UE to acquire a traffic channel in the 1xRTT access network. In addition to enhanced 1xCSFB, the eNB may determine to perform concurrent mobility to HRPD based on UE capability; if so, then two separate UL Handover Preparation Transfer messages are triggered from the UE containing 1xRTT and HRPD dedicated information, respectively. The concurrent HRPD handover procedure is handled independently from the e1xCSFB procedure, except that responses from the 1xRTT and HRPD networks shall be combined by the eNB into a single Mobility From EUTRA Command message.

The network advertises support for dual receiver 1xCSFB by broadcasting the dual receiver 1xCSFB support indicator in system information (SIB8). The eNB determines to perform dual receiver 1xCSFB if the UE has a dual Rx configuration according to UE capability, and enhanced 1xCSFB cannot be performed (i.e. because enhanced 1xCSFB is not supported by both network and UE). If dual receiver 1xCSFB is to be performed, the eNB sends an RRC Connection Release message without including redirection information. The UE then performs the normal 1xCS call origination or termination procedure in the 1xRTT access network. A UE with dual Rx configuration may initiate 1xCSFB to a network broadcasting 1xRTT pre-registration parameters but not broadcasting the dual receiver 1xCSFB support indicator; in this case, the UE may receive an RRC Connection Release message with redirection to 1xRTT. The network advertises support for dual receiver/transmitter enhanced 1xCSFB (dual Rx/Tx e1xCSFB) by broadcasting the dual Rx/Tx e1xCSFB support indicator in system information (SIB8). The eNB determines to perform dual Rx/Tx e1xCSFB if the UE has a dual Rx/Tx configuration, supports enhanced 1xCSFB according to UE capability, and belongs to Release-10 or later. If the network does not advertise support for dual Rx/Tx e1xCSFB, UE which have dual Rx/Tx configuration may decide to keep the 1xRTT receiver/transmitter turned on in order to continuously operate in both 1xRTT and E-UTRAN. If dual Rx/Tx e1xCSFB is to be performed, the eNB optionally solicits 1xRTT measurements from the UE, and then sends a Handover From EUTRA Preparation Request message. This triggers the UE to perform one of the following:

-send the UL Handover Preparation Transfer message containing 1xRTT dedicated information. The 1xRTT information is contained inside RRC and S1-AP messages between the UE and MME and in a generic "transfer" message between MME and 1xRTT network. The response from the 1xRTT network triggers the eNB to send a DL Information Transfer message which includes a 1xRTT channel assignment message that causes the UE to acquire a traffic channel in the 1xRTT access network while continuing to be served by the E-UTRAN (for PS-domain services).

-direct its second radio to 1xRTT, where it performs the 1xCS call origination or termination procedure in the 1xRTT access network while continuing to be served by the E-UTRAN (for PS-domain services).The following table summarizes the various CS fallback options for 1xRTT, necessary UE capabilities and FGI index which should be set to 1. The meaning of FGI index is specified in [16, Annex B].

Table 10.3.2.3.3-1: CS fallback options

Target RATSolutionsReleaseUE CapabilityFGI Index

CS fallback to 1xRTTRRC Connection Release with RedirectionRel-8(NOTE 1)

Mandatory for UEs supporting CS fallback to 1xRTT

enhanced 1xCSFBRel-9(NOTE 1)

e-CSFB-1XRTT

enhanced 1xCSFB with concurrent HRPD handover

Rel-9(NOTE 1)

e-CSFB-ConcPS-Mob1XRTT, Support of HRPD, supportedBandListHRPDFGI12, FGI26

dual receiver 1xCSFB (RRC Connection Release without Redirection)Rel-9(NOTE 1)

rx-Config1XRTT (set to dual)

dual receiver/transmitter enhanced 1xCSFBRel-10(NOTE 1)

e-CSFB-1XRTT, rx-Config1XRTT (set to dual), tx-Config1XRTT (set to dual)

NOTE 1: All CS fallback to 1xRTT capable UE shall indicate that it supports 1xRTT and supported band list in the UE capability.

NOTE 2: The measurement may be performed before any of the above CS fallback solution is triggered to select the target cell or frequency layer more accurately based on eNB decision. eNB may trigger any of above CS fallback solutions blindly.

PAGE \# "'Page: '#''" HYPERLINK "http://www.3gpp.org/ftp/Information/DocNum_FTP_structure_V3.zip" Document numbers are allocated by the Working Group Secretary. Use the format of document number specified by the HYPERLINK "http://www.3gpp.org/About/WP.htm" 3GPP Working Procedures.

PAGE \# "'Page: '#''" Enter the specification number in this box. For example, 04.08 or 31.102. Do not prefix the number with anything . i.e. do not use "TS", "GSM" or "3GPP" etc.

PAGE \# "'Page: '#''" Enter the CR number here. This number is allocated by the 3GPP support team. It consists of at least four digits, padded with leading zeros if necessary.

PAGE \# "'Page: '#''" Enter the revision number of the CR here. If it is the first version, use a "-".

PAGE \# "'Page: '#''" Enter the version of the specification here. This number is the version of the specification to which the CR was written and (normally) to which it will be applied if it is approved. Make sure that the latest version of the specification (of the relevant release) is used when creating the CR. If unsure what the latest version is, go to HYPERLINK "http://www.3gpp.org/3G_Specs/3G_Specs.htm" HYPERLINK "http://www.3gpp.org/specs/specs.htm" http://www.3gpp.org/specs/specs.htm.

PAGE \# "'Page: '#''" For help on how to fill out a field, place the mouse pointer over the special symbol closest to the field in question.

PAGE \# "'Page: '#''" Mark one or more of the boxes with an X.

PAGE \# "'Page: '#''" SIM / USIM / ISIM applications.

PAGE \# "'Page: '#''" Enter a concise description of the subject matter of the CR. It should be no longer than one line, but if this is not possible, do not enter hard new-line characters. Do not use redundant information such as "Change Request number xxx to 3GPP TS xx.xxx".

One or more organizations (3GPP Individual Members) which drafted the CR and are presenting it to the Working Group.

For CRs agreed at Working Group level, the identity of the WG. Use the format "xn" where x = "C" for TSG CT, "R" for TSG RAN, "S" for TSG SA, "G" for TSG GERAN; PAGE \# "'Page: '#''" n = digit identifying the Working Group; for CRs drafted during the TSG meeting itself, use "P". Examples: "C4", "R5", "G3new", "SP".

PAGE \# "'Page: '#''" Enter the acronym for the work item which is applicable to the change. This field is mandatory for category F, A, B & C CRs for Release 4 and later. A list of work item acronyms can be found in the 3GPP work plan. See HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/WI-List.htm" http://www.3gpp.org/ftp/Specs/html-info/WI-List.htm .

PAGE \# "'Page: '#''" Enter the date on which the CR was last revised. Format to be interpretable by English version of MS Windows applications, e.g. 19/02/2006.

PAGE \# "'Page: '#''" Enter a single letter corresponding to the most appropriate category listed. For more detailed help on interpreting these categories, see Technical Report HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/21900.htm"21.900 "TSG working methods".

PAGE \# "'Page: '#''" Enter a single release code from the list below.

PAGE \# "'Page: '#''" Enter text which explains why the change is necessary.

PAGE \# "'Page: '#''" Enter text which describes the most important components of the change. i.e. How the change is made.

PAGE \# "'Page: '#''" Enter here the consequences if this CR were to be rejected. It is mandatory to complete this section only if the CR is of category "F" (i.e. correction), though it may well be useful for other categories.

PAGE \# "'Page: '#''" Enter the number of each clause which contains changes. Be as specific as possible (ie list each subclause, not just the umbrella clause).

PAGE \# "'Page: '#''" Tick "yes" box if any other specifications are affected by this change. Else tick "no". You MUST fill in one or the other.

PAGE \# "'Page: '#''" List here the specifications which are affected or the CRs which are linked.

PAGE \# "'Page: '#''" Enter any other information which may be needed by the group being requested to approve the CR. This could include special conditions for it's approval which are not listed anywhere else above.