1. Page 1 Overview of cdma2000 1x Rev E and impact to IOS Notice ©2009. All rights reserved. The contributors 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. The contributors are 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 the contributors 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 the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above. Vikram Gupta (vikramg@qualcomm.com)vikramg@qualcomm.com David Ott (dott@qualcomm.com)dott@qualcomm.com Peerapol Tinnakornsrisuphap (peerapol@qualcomm.com)peerapol@qualcomm.com Ravindra Patwardhan (rpatward@qualcomm.com) Recommendation: FYIrpatward@qualcomm.com

2. Page 2 Introduction Revision E of cdma2000 1x air-interface specification has been baselined and is expected to complete R&F in February This contribution provides overview of air-interface enhancements in C.S0001~6-E and their impacts to 1x IOS New features in 1x Rev E 1.New Radio Configuration Message 2.New Service Option 3.TrFO support in IOS 4.Femto Support Enhancements 5.Flex Duplex 6.GEO_LOC_TYPE Extensions related to C.S0022-B 7.Call Recovery Request Message 8.General Overhead Information Message 9.Location Based Services 10.MEID_ME and ESN_ME query support

3. Page 3 1. New RC Message Flow Support for new RC indicated in Origination / Registration /Page Response message using the RC bitmap RC Parameters message provides non-default RC parameters Current RC in use and Supported RC bitmap are carried transparently in A1 messages via Service Configuration Record and FCH Information This feature has no IOS impact

4. Page 4 Signaling Messages with new RC BS to MS:  ECAM, Service Request Message, Service Response Message, Service Connect Message, General Handoff Direction Message, Universal Handoff Direction Message, RC Parameters Message MS to BS:  Origination Message, Page Response Message, Status Response Message, Extended Status Response Message, Service Request Message, Service Response Message

5. Page 5 2. New Service Option  EVRC-B and EVRC-WB in DTX mode is defined for Packet Switched (PS) network in C.S0076 [1] but not explicitly defined for Circuit Switched (CS) system  CS could borrow the PS smart blanking DTX idea  New SO value will be added to TSB-58  1x IOS Impact  IOS needs to indicate support for the new SO

6. Page 6 3. Interoperability – TrFO TrFO=Transcoder Free Operation  Mechanism to avoid transcoding operation  IOS messaging supports TrFO  TrFO supported only on MSCe IOS changes needed to support TrFO  Add new Bearer Format ID value (Corresponding to new SO)

7. Page 7 TrFO Call Flow (Origination) (A2P BF) = A2P Bearer Format- Specific Parameters

8. Page 8 TrFO Call Flow (Termination) (A2P BF) = A2P Bearer Format- Specific Parameters

9. Page 9 4. 1x Rev E Enhancements for Femto Support Access Point Pilot Info Message  Broadcast from femtocells and /or macro cell  Band, frequencies, and PN offsets allocated for the femto cells Access Point ID Message  Broadcast by femtocell on beacon & normal channels at high frequency schedule.  Contents:  SID, NID, AP_ID, AP_ID mask  Supported association model  MSC_ID, CELL_ID  HRPD band class and channel  Location Information LAT, LONG, ALT, and horizontal and vertical Uncertainty. Access Point ID Text Message  Broadcast by femtocell on paging channel at low frequency schedule These three messages have no IOS impact

10. Page 10 1x Active Hand-In Design in 1x Rev E Macro to Femto handoff follows current intra/inter-MSC handoff procedure on the network side The air-interface is enhanced to minimize impact to macro BS by reusing the existing A1/A1p interface  Two new messages (Handoff Supplementary Information Solicit/Notification) are defined to help provide CELL_ID and MSC_ID to be used in A1/A1p interface Reachability  Currently in 1x, BS maps PN to target CELL_ID and MSC_ID in the A1- Handoff Required message to MSC  In case of hand-in, macro 1x BS just uses mapping reported from MS in Handoff Supplementary Information Notification message  In IMS-based architecture, MFIF needs to be assigned with MSCID and Legacy MSC needs to route to it on IS-41 This is described in A20-20080721-005r0 Femto AP Handoff (QC) Existing IOS interfaces are not impacted in this design

11. Page 11 5. Flex-Duplex support in cdma2000 1x: Air-Interface Requirements Mobiles that support the flex duplex feature, read the new overhead message, Flex Duplex CDMA Channel List Message (FDCCLM), and report band subclass support back to the base station. Legacy mobiles are not impacted as they ignore the FDCCLM. To support flex duplex feature in cdma2000 1x the following air- interface signaling is supported  Flex-duplex capability indication from  base station to mobile and  mobile to base station  Signal reverse channel information from base station to mobile  Paging channel hashing  Traffic assignment  Hard Handoff into flex duplex frequency

12. Page 12 General Extension Message (GEM): Background General Extension Message  This message allows an L3 message to be extended with new records. It is used for supporting various flex duplex requirements.  Message extension can be across all revisions of cdma2000 1x.  This is useful when new information (ex. reverse channel information needed for flex duplex operation) is needed »in multiple messages (ECAM, UHDM, GHDM) or »New information is needed in a message that has been extended across revisions and a standalone implementation approach is needed.

13. Page 13 Reverse Channel Record Signaling for Handoff and Channel Assignment using GEM New records defined with the GEM message for flex duplex support:  Reverse channel information record.  Band class subclass supported information record. Handoff:  GEM containing UHDM / GHDM along with Reverse Channel Information Record is transmitted to the mobile when hard handoff into a flex duplex frequency is required. Channel Assignment:  GEM containing CAM / ECAM with Reverse Channel Information Record is transmitted to the mobile when channel assignment into flex duplex channel is made. Band Subclass support during access  MS reports band class – subclass supported when the CAND_BAND_INFO_REQ is set to ‘1’ in the FDCCLM.  GEM containing Origination/Page Response/Registration message along with band class - subclass supported record can be transmitted by the mobile during access.  The mobile will only include a subset of the band subclasses supported by the base station as indicated in the FDCLM overhead message.

14. Page 14 1x IOS Considerations for Flex Duplex In Hard Handoff into flex duplex frequency, for each flex duplex frequency that the target BS supports, it needs to include one occurrence of each of the following fields:  11 bit REV_CHAN field,  11 bit FWD_CHAN field, and the  5 bit BAND_CLASS

15. Page 15 7. GEO_LOC_TYPE Optionally included in the Registration message Optionally included in the Origination Message Included in Geo-Location Capability information record Defined Values based on IS-801-1  000 = No mobile station assisted geo-location capabilities  001 = IS-801 capable (AFLT)  010 = IS-801 capable (AFLT and GPS)  011 = GPS only  100-111 = Reserved Used by MPC and PDE to initiate optimized IS-801-1 session IS-801-B adds support for GNSS, UMB, and HDP so new values should be added to allow for MPC and PDE to continued optimal support

16. Page 16 1x Rev E changes for new GEO_LOC_TYPE Fields added to Registration and Origination Messages  ADD_GEO_LOC_INCL  If ADD_GEO_LOC_INCL is set to 1, then  ADD_GEO_LOC_TYPE_LEN_IND (Indicates length of next field)  ADD_GEO_LOC_TYPE0 or 16 or 24 Additional Geo-Location Capability Information Record  Carries ADD_GEO_LOC ADD_GEO_LOC/ADD_GEO_LOC_TYPE fields are bitmap  See bitmap definition on next slide

17. Page 17 ADD_GEO_LOC Bitmap 1x IOS Impact: Need to add fields to indicate mobile support of these new GEO_LOC types

18. Page 18 8. Call Recovery Request Message ‘Call Recovery Request Message’ Message  New message on r-csch from MS to BS to recover dropped call.  No L3 information needed  MS allowed to send this message within 20 seconds after call drop due to fade timer, as long as no other access channel message is sent after the call drop.  If BS that understands this message receives it, then the BS will perform channel assignment if resources (air link and backhaul) for the dropped call are still allocated at BS. »Call will reconnect as long as one of the BSC in active set (from network perspective) receives the new message. IOS impact  This feature does not have IOS impact

19. Page 19 9. General Overhead Information Message Motivation:  Operators may need to broadcast non-access related information. Ex:  Region name  Operator name  Other examples could be list of all operators available in the region. Proposed solution  Create new overhead message: General Overhead Information Message.  Transmission of this message is indicated in the SPM / MC-RR message.  Message frequency is configurable:  GEN_OVHD_CYCLE_INDEX is a 3 bit field and may be carried in the SPM or MC-RR. Default value is assumed to be 0. Allowed vales are from 0 to 5.  Base station will transmit GOIM at least once during the 16 paging slots that stisfy SYS_TIME / 16 mod 2 GEN_OVHD_CYCLE_INDEX = 0.  Base station can set the frequency depending on the load of the paging channel.

20. Page 20 General Overhead Information Message Processing  Mobile station is not required to receive GOI message for access.  Base station will indicate change in GOI contents by changing the config message sequence number.  If the mobile station does not support the record type included in the GOI message it can discard the record.  Otherwise it can use the record for non-access purposes.  Typically mobile will process and display this information. Contents  Currently 2 records are defined (Region Name, Operator Name)  Other record types may be defined in TSB-58. This feature has no IOS impact

21. Page 21 10. LBS Extensions to CDMA Overhead Messages The System Parameters Message (SPM) and the MC- RR Parameters Message (MC-RR PM) contain:  BASE_LAT - Base station latitude  BASE_LONG - Base station longitude Emergency Services and LBS benefit from:  BASE_LAT and BASE_LONG can be trusted  The inclusion the following new information elements in the SPM and the MC-RR PM  Horizontal Position Uncertainty  Altitude and Altitude Uncertainty This would provide the MS with a useable reference location improving accuracy, yield, and time to fix results and in some cases allowing for IS-801 sessions to be avoided

22. Page 22 LBS related Air Interface Changes Additional fields in SPM and MC-RRPM  ADD_LOC_INFO_INCL (1 bit)  If ADD_LOC_INFO_INCL is set to 1, then following field are included »LOC_UNC_H(4 bits) »HEIGHT(14 bits) »LOC_UNC_V(4 bits) Clarification added for BASE_LAT and BASE_LONG fields  BS shall set these fields to all ‘0’s if LAT/LONG is not known This feature has no IOS impact

23. Page 23 11. MEID_ME and ESN_ME Query 1x Rev E changes  MEID_ME information record introduced (carries MEID from shell) ESN_ME or MEID_ME can be queried and stored in MSC/VLR –One query needed each time new MS registers with MSC/VLR –BS can decide to query ESN_ME or MEID_ME based on SCM bit 4 This feature has no IOS impact