143 System SelectionRecommended System Selection Requirements.doc

Recommended System Selection Requirements for 1X and 1xEV-DO-Capable TerminalsCDG Document 143Version 1.115 March 2007CDMA Development Group575 Anton Boulevard, Suite 560Costa Mesa, California 92626PHONE +1 888 800-CDMA+1 714 545-5211FAX +1 714 545-4601http:/www.cdg.orgcdgcdg.orgNoticeEach CDG member acknowledges that CDG does not review the disclosures or contributions of any CDG member nor does CDG verify the status of the ownership of any of the intellectual property rights associated with any such disclosures or contributions. Accordingly, each CDG member should consider all disclosures and contributions as being made solely on an as-is basis. If any CDG member makes any use of any disclosure or contribution, then such use is at such CDG member's sole risk. Each CDG member agrees that CDG shall not be liable to any person or entity (including any CDG member) arising out of any use of any disclosure or contribution, including any liability arising out of infringement of intellectual property rights. <page left blank intentionally>ContentsRecommended System Selection Requirements for 1X and 1xEV-DO-Capable TerminalsiCDG Document 143iVersion 0.6i16 Aug 2006i1. Introduction11.1 Purpose11.2 Scope11.3 Terms and Definitions11.4 References22. PRL and Selection Preferences42.1 PRL Versions42.2 PRL Storage42.3 Default PRL52.4 OTA PRL Provisioning52.5 PRL Acquisition Table62.6 Roaming Indicator62.7 PRL Channels72.8 PRL Enhancements for International Roaming82.9 NAM SID/NID List92.10 PRL System Matching92.11 Preference Order122.12 Forbidden Systems133. MRU Table153.1 MRU Storage153.2 MRU Logging154. System Selection174.1 Power-up174.2 Better Service Reselection (BSR)184.3 System Lost214.4 Reverse Link Limited System224.5 Redirection234.6 Call Release254.7 Voice and Data Call Origination254.8 OTASP Call Origination284.9 Emergency Call Origination295. DO System Selection Hybrid Mode325.1 Collocated List325.2 Power-up355.3 Idle Operation355.4 DO Better Service Reselection (DBSR)365.5 DO System Lost385.6 Redirection395.7 Attempt to Open a Connection405.8 Session Negotiation425.9 Data Call Origination445.10 Idle Digital Mode (IDM)465.11 DO Traffic Operation466. DO System Selection Non-Hybrid497. Acronyms and Abbreviations51A. Configurable Parameters53B. PRL Construction Guidelines56B.1 General PRL Construction Guidelines56B.2 DO-Specific PRL Construction Guidelines57List of TablesTable 11  Reference Documents and Standards2Table 41Silent Redial28Table 51  PRL Acquisition33Table 52  PRL System Table33Table A1  Configurable Parameters53Revision HistoryDateVersionDescription9 Aug 20060.1Initial release10 Aug 20060.2Updated to incorporate CDG template format11 Aug 20060.3Formatting update14 Aug 20060.4Incorporate comments15 Aug 20060.5Add table format16 Aug 20060.6Updated requirements16 Feb 20071.0Updated for 1.0 publication12 Sep 20071.0Updated for 1.1 publication<page left blank intentionally>1. Introduction1.1 PurposeThis document specifies recommended system selection requirements. This document is intended to capture the system selection requirements of all operators. It is strongly recommended that operators use this document for their system selection requirements rather than creating their own requirements document. Having all operators using the same system selection requirements would help in providing a consistent user experience when roaming in and out of the user home country.Note:DO, EV-DO, HDR, and HRPD are used interchangeably in this document to refer to 1xEV-DO (Evolution Data-Optimized) systems.1.2 ScopeThis document is intended to be used by 1X and 1xEV-DO operators as their system selection requirements document. The target audiences for this document are 1X and 1xEV-DO operators and their handset vendors.1.3 Terms and DefinitionsFour categories of requirements are established:(M) MandatoryThe handset must support that characteristic in order to achieve approval.(HD) Highly DesirableIt is highly desirable and recommended that the handset supports this characteristic. This feature may become Mandatory in subsequent versions of the document. Supporting this characteristic will be valued in the commercial promotion of the terminal.(O) OptionalIt is left up to the manufacturer whether or not the terminal supports this characteristic. The handset may support this characteristic.(D) DiscardThe manufacturer shall not support this feature or function. 1.4 ReferencesReference documents, which may include standards and resource documents, are listed in Table 11. Reference documents that are no longer applicable are deleted from this table; therefore, reference numbers may not be sequential.Table 11  Reference Documents and StandardsRef.DocumentStandardsS1Band Class Specification for cdma 2000 Spread Spectrum Systems3GPP2 C.S0057S2PRL Enhancements for International RoamingCDG document #86<page left blank intentionally>2. PRL and Selection PreferencesThe Preferred Roaming List (PRL) is a data structure set up by the operator and programmed into the MSs NV memory or RUIM. The PRL instructs the MS where to look for service and, when a system is acquired, whether it is usable. In addition, the PRL specifies the roaming indicator to be displayed when providing service on a particular system.2.1 PRL VersionsReq. #RequirementCategoryRemarksRefsPRI Configuration2.1.1MS shall support IS-683-A PRLM2.1.2MS shall support IS-683-C PRLHDMandatory for devices that support 1xEV-DO. This requirement will become mandatory for all devices in the future.Having all MS supporting IS-683-C PRL reduces the numbers of PRLs an operator has to maintain.2.2 PRL StorageReq. #RequirementCategoryRemarksRefsPRI Configuration2.2.1MS shall provide a minimum of 8 KB (8000 bypts) for PRL storage per NAM in NV memoryM2.2.2MS that support an RUIM shall support PRL read configurations: see Remarks columnMRead PRL from RUIM only.Read PRL from NV memory only.Read PRL from RUIM if available (else read PRL from NV memory).Exposure of the PRL read configuration at UI level is optional.2.2.3When reading the PRL from RUIM, MS shall first try to read PRL from EF-EPRLHDIf the EF-EPRL read or validation fails, MS shall try to read the PRL from EF-PRL.If the PRL read or validation of both EF-EPRL and EF-PRL fail, MS shall build a default PRL, as defined in Section 2.32.3 Default PRLThe purpose of a default PRL is to enable the MS to acquire service when no PRL is programmed into NV memory or RUIM, or when the PRL usage is disabled. Using a default PRL ensures that the MS would not enter an offline (or service required) state as a result of no PRL being programmed to NV/RUIM. When in offline state, the MS is not able to place calls, including emergency and OTASP calls.Req. #RequirementCategoryRemarksRefsPRI Configuration2.3.1MS shall build a default PRL during power-up if no valid PRL is stored in NV memory or RUIMMDefault PRL shall include all preferred 1X channels from all the bands that are supported by the MS.Default PRL shall allow operation on any 1X systems, i.e., the SID field of all system table entries should be set to wildcard (0).2.4 OTA PRL ProvisioningReq. #RequirementCategoryRemarksRefsPRI Configuration2.4.1MS shall support IS-683-A-based OTA PRL provisioningM2.4.2MS shall support IS-683-C-based OTA PRL provisioningHDAn R-UIM card that supports EF-EPRL is expected to write an IS-683-C or newer PRL to the EF-EPRL storage location (as opposed to the EF-PRL storage location).Mandatory for devices that support 1xEV-DO2.5 PRL Acquisition TableReq. #RequirementCategoryRemarksRefsPRI Configuration2.5.1MS shall support a minimum of 80 unique mode/band/channel combinations in the PRL acquisition tableMPRL acquisition records that list channels result in one mode/band/channel combination per listed channel.PRL acquisition records that list blocks result in one mode/band/channel combination for each preferred channel that is part of the block.Mode/band/channel combinations that are listed multiple times are only counted once.2.5.2MS shall support a minimum of 180 unique mode/band/channel combinations in the PRL acquisition tableHD2.5.3MS with DO capability shall support a minimum of 180 unique mode/band/channel combinations in the PRL acquisition tableM2.6 Roaming IndicatorThe roaming indicator is an 8-bit value that is associated with each system table entry. When the MS operates on a system that matches a particular system table entry, the roaming indicator (ROAM_IND) field of that entry is displayed to the user. When the MS operates on a system that is not listed in the PRL, the default roaming indicator (DEF_ROAM_IND) of the PRL is displayed to the user.Generally, the roaming indicator is only associated with a visual indication that is to be displayed to the user. In some special cases, however, the roaming indicator field is used for other purposes, such as determining the relative priority of systems that are not listed in the same GEO. Therefore, there is a need to define the relative priority of the roaming indicator values.Req. #RequirementCategoryRemarksRefsPRI Configuration2.6.1MS shall support all 256 values of the roaming indicator, i.e., Enhanced Roaming Indicator (ERI)M2.6.2The preference order of the roaming indicators (most to least) shall be according to Home and Roam groups: see Remarks columnMThe preference order shall be as follows:1. Home group, which includes the value 1 and all roaming indicator values that are defined by an operator as custom home2. Roam group, which includes all the remaining roaming indicator values that are not part of the home groupNote: A system is said to be a home-system if its remaining roaming indicator value belongs to the home groupRoam_mask (as defined in Table A-1) specifies the roaming indicator values that are defined by an operator as custom home.2.7 PRL ChannelsThe acquisition table of the PRL lists mode/band/channel combinations that instruct the MS where to attempt service acquisition. Some older MS used to perform range checks on the channels that are listed in the PRL acquisition table at the time the PRL is pushed into the NV memory (or RUIM). If the channels were outside the range that is specified in the standard and/or supported by the MS, the PRL would be rejected.To allow for the addition of new modes, band classes, and channels, it is expected that the MS would be able to accept PRLs with channels they do not support. While operating with such PRLs, the MS would skip unsupported mode/band/channel combinations.Req. #RequirementCategoryRemarksRefsPRI Configuration2.7.1MS shall not reject a PRL because acquisition records listing mode/band/channel combinations that are outside the spec range or MS capabilityHDMS shall ignore the channel number when validating a PRL2.7.2MS shall skip over mode/band/channel combinations that are not supported by MSMWhen trying to acquire service based on the PRL acquisition table, MS shall skip over mode/band/channel combinations that are not supported by the MS hardware or softwareThe GEO and PRI fields of all system records must be accounted for, regardless if such system records are supported by the MS (or pointing at supported acquisition records). This is done in order to ensure that the MS correctly interprets the system table partitioning into GEOs and preference tiers.2.7.3MS shall support all channel numbers that are defined in 3GPP2 C.S0057 (as valid or not valid) for a particular band-class/subclass that is supported by the MSMFor example, MS capable of band-class 0, subclass 0 or 1, shall allow and support the following channel numbers:- 1 to 799 (inclusive)- 991 to 1023 (inclusive)Similarly, MS capable of band-class 1 shall allow and support the following channel numbers:- 0 to 1199 (inclusive)2.8 PRL Enhancements for International RoamingPRL enhancements for international roaming enable substantial compression and simplification of the PRL system table. The idea is to use the MCC and IMSI_11_12 that come in the Extended System Parameters Message (ESPM) to identify 1X systems.Since each operator is expected to have only one MCC/IMSI_11_12 broadcasted throughout its network (in a particular country), it is sufficient to list one MCC/IMSI_11_12 entry for each one of the international roaming partners.Req. #RequirementCategoryRemarksRefsPRI Configuration2.8.1MS shall support PRL with MCC/IMSI_11_12 based system records as described in CDG document #86MSee S2 for reference document.2.9 NAM SID/NID ListThe NAM SID/NID list is an alternate mechanism through which an operator can specify SID/NID combinations for which the roaming indicator is set to OFF (i.e., set to 1). Since this mechanism does not provide any additional functionality to what is already provided by the ROAM_IND field of a PRLs system table entry, it is recommended to not utilize the NAM SID/NID list. Saying this, the MS shall support the NAM SID/NID list as follows.Req. #RequirementCategoryRemarksRefsPRI Configuration2.9.1MS shall only use the NAM SID/NID list for the purpose of overwriting the roaming indicator to OFF (1)M2.9.2MS shall not overwrite the roaming indicator of systems that are listed in the PRL and their roaming indicator is other than 0 or 2HD2.9.3MS shall support a minimum of 20 entries in the NAMSID/NID listM2.10 PRL System MatchingAfter obtaining the overhead information (SID, NID in the case of a 1X system) from the OTA signal, the MS attempts to find a match for the system in the PRL system table.The rules for deciding whether the OTA system information matches a particular system table entry are listed below and should be followed carefully to eliminate any ambiguity between the PRL writer and the MS interpretation of the PRL.In addition, because of the use of wildcard system IDs (SID=0 in the case of 1X), the MS may find a match with more than one system table entry. To resolve this situation, a more restrictive match overwrites all less restrictive matches. For example, an explicit SID match overwrites a wildcard SID match. Similarly, an explicit SID/NID match overwrites explicit SID + wildcard NID match.Req. #RequirementCategoryRemarksRefsPRI Configuration2.10.1MS shall c