Recommended System Selection Requirements for 1X and 1xEV-DO-Capable Terminals_143v1.1

7/31/2019 Recommended System Selection Requirements for 1X and 1xEV-DO-Capable Terminals_143v1.1

1/64

Recommended System SelectionRequirements for 1X and 1xEV-DO-Capable

Terminals

CDG Document 143

Version 1.01

15 March 2007

CDMA Development Group575 Anton Boulevard, Suite 560Costa Mesa, California 92626PHONE +1 888 800-CDMA

+1 714 545-5211FAX +1 714 545-4601

http://[email protected]

Notice

Each CDG member acknowledges that CDG does not review thedisclosures or contributions of any CDG member nor does CDG verifythe status of the ownership of any of the intellectual property rightsassociated with any such disclosures or contributions. Accordingly, eachCDG member should consider all disclosures and contributions as beingmade solely on an as-is basis. If any CDG member makes any use ofany disclosure or contribution, then such use is at such CDG member'ssole risk. Each CDG member agrees that CDG shall not be liable to anyperson or entity (including any CDG member) arising out of any use ofany disclosure or contribution, including any liability arising out ofinfringement of intellectual property rights.


2/64

Recommended System Selection Requirements for 1X and 1xEV-DO-Capable TerminalsContents

Ref Doc. 143, Ver. 0.6 16 Aug 2006 ii


3/64

Contents

Recommended System Selection Requirements for 1X and 1xEV-DO-Capable Terminals ... iCDG Document 143 ..................... ......................... ......................... ......................... .................... iVersion 0.6 ................................................................................................................................. i16 Aug 2006 ...................... ......................... ...................... ............................ ...................... ......... i1. Introduction .................... ......................... ......................... ......................... ....................... ..... 1

1.1 Purpose ......................................................................................................................... 11.2 Scope ............................................................................................................................ 11.3 Terms and Definitions ...................... ......................... ....................... ......................... ..... 11.4 References .................................................................................................................... 2

2. PRL and Selection Preferences ....................... ......................... ......................... ................... 42.1 PRL Versions ................................................................................................................ 42.2 PRL Storage .................................................................................................................. 42.3 Default PRL ................................................................................................................... 52.4 OTA PRL Provisioning ................................................................................................... 52.5 PRL Acquisition Table ...................... ......................... ....................... ......................... ..... 62.6 Roaming Indicator .................... ......................... ...................... ............................ ........... 62.7 PRL Channels ............................................................................................................... 72.8 PRL Enhancements for International Roaming ..................... ......................... ................. 82.9 NAM SID/NID List .......................................................................................................... 92.10 PRL System Matching ................................................................................................. 92.11 Preference Order ....................................................................................................... 122.12 Forbidden Systems .................................................................................................... 13

3. MRU Table ........................................................................................................................... 153.1 MRU Storage ............................................................................................................... 153.2 MRU Logging .............................................................................................................. 15

4. System Selection ................................................................................................................ 174.1 Power-up ..................................................................................................................... 174.2 Better Service Reselection (BSR) ............................. ....................... ........................... . 184.3 System Lost ................................................................................................................. 214.4 Reverse Link Limited System ......................... ....................... ........................ ............... 22


4/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 ii

4.5 Redirection .................................................................................................................. 234.6 Call Release ................................................................................................................ 254.7 Voice and Data Call Origination ..................... ....................... ........................ ............... 254.8 OTASP Call Origination ............................................................................................... 284.9 Emergency Call Origination ......................................................................................... 29

5. DO System Selection Hybrid Mode .............................. ....................... ........................... . 325.1 Collocated List ............................................................................................................. 325.2 Power-up ..................................................................................................................... 355.3 Idle Operation .............................................................................................................. 355.4 DO Better Service Reselection (DBSR) ..................... ....................... ........................... . 365.5 DO System Lost .......................................................................................................... 385.6 Redirection .................................................................................................................. 395.7 Attempt to Open a Connection ..................... ...................... ...................... .................... 405.8 Session Negotiation ..................................................................................................... 425.9 Data Call Origination ...................... ......................... ...................... ......................... ...... 445.10 Idle Digital Mode (IDM) .............................................................................................. 465.11 DO Traffic Operation ...................... ......................... ....................... ......................... ... 46

6. DO System Selection Non-Hybrid .............................. ...................... ......................... ...... 497. Acronyms and Abbreviations ................. ......................... ....................... ......................... ... 51A. Configurable Parameters ........................................ ...................... ............................ ......... 53B. PRL Construction Guidelines ......................... ......................... ......................... ................. 56

B.1 General PRL Construction Guidelines ...................... ....................... ........................... . 56B.2 DO-Specific PRL Construction Guidelines ................................. ...................... ............ 57

List of Tables

Table 1-1 Reference Documents and Standards ...................... ...................... ......................... 2Table 4-1Silent Redial ..................... ......................... ...................... ......................... ............... 28Table 5-1 PRL Acquisition ....................... ......................... ...................... ......................... ...... 33Table 5-2 PRL System Table .................... ......................... ....................... ......................... ... 33Table A-1 Configurable Parameters ..................... ....................... ...................... .................... 53


5/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 iii

Revision History

Date Version Description

9 Aug 2006 0.1 Initial release

10 Aug 2006 0.2 Updated to incorporate CDG template format

11 Aug 2006 0.3 Formatting update

14 Aug 2006 0.4 Incorporate comments

15 Aug 2006 0.5 Add table format

16 Aug 2006 0.6 Updated requirements

16 Feb 2007 1.0 Updated for 1.0 publication

126SepFed 2007 1.0 Updated for 1.10 publication


6/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 iv


7/64

1. Introduction1

1.1 Purpose2

This document specifies recommended system selection requirements. This document3

is intended to capture the system selection requirements of all operators. It is strongly4

recommended that operators use this document for their system selection requirements5

rather than creating their own requirements document. Having all operators using the6 same system selection requirements would help in providing a consistent user7

experience when roaming in and out of the user home country.8

Note: DO, EV-DO, HDR, and HRPD are used interchangeably in this document to refer9to 1xEV-DO (Evolution Data-Optimized) systems.10

1.2 Scope11

This document is intended to be used by 1X and 1xEV-DO operators as their system12

selection requirements document. The target audiences for this document are 1X and13

1xEV-DO operators and their handset vendors.14

1.3 Terms and Definitions15

Four categories of requirements are established:16

(M) Mandatory The handset must support that characteristic in order to achieveapproval.

(HD) Highly Desirable It is highly desirable and recommended that the handset supportsthis characteristic. This feature may become Mandatory insubsequent versions of the document. Supporting thischaracteristic will be valued in the commercial promotion of theterminal.

(O) Optional It is left up to the manufacturer whether or not the terminalsupports this characteristic. The handset may support thischaracteristic.

(D) Discard The manufacturershall not support this feature or function.


8/64

1.4 References1

Reference documents, which may include standards and resource documents, are listed2

in Table 1-1Table 1-1. Reference documents that are no longer applicable are deleted3

from this table; therefore, reference numbers may not be sequential.4

Table 1-1 Reference Documents and Standards5

Ref. DocumentStandards

S1 Band Class Specification for cdma 2000 Spread SpectrumSystems

3GPP2 C.S0057

S2 PRL Enhancements for International Roaming CDG document #86

6

7


9/64

Recommended System Selection Requirements for 1X and 1xEV-DO-Capable Terminals

Ref Doc. 143, Ver. 0.6 16 Aug 2006 3

1


10/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 4

2. PRL and Selection Preferences1

The Preferred Roaming List (PRL) is a data structure set up by the operator and2

programmed into the MSs NV memory or RUIM. The PRL instructs the MS where to3

look for service and, when a system is acquired, whether it is usable. In addition, the4

PRL specifies the roaming indicator to be displayed when providing service on a5

particular system.6

2.1 PRL Versions7

Req. # Requirement Category Remarks Refs PRI Configuration

2.1.1 MS shall supportIS-683-A PRL

M

2.1.2 MS shall supportIS-683-C PRL

HD Mandatory for devices thatsupport 1xEV-DO. Thisrequirement will becomemandatory for all devices inthe future.

Having all MS supporting IS-683-C PRL reduces thenumbers of PRLs an operatorhas to maintain.

2.2 PRL Storage8


2.2.1 MS shall provide aminimum of 8 KB (8000

bypts) for PRL storageper NAM in NV memory

M

2.2.2 MS that support anRUIM shall support PRLread configurations: seeRemarks column

M Read PRL from RUIM only.

Read PRL from NV memoryonly.

Read PRL from RUIM ifavailable (else read PRL from


11/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 5


NV memory).

Exposure of the PRL readconfiguration at UI level isoptional.

2.2.3 When reading the PRLfrom RUIM, MS shallfirst try to read PRLfrom EF-EPRL

HD If the EF-EPRL read orvalidation fails, MS shall try toread the PRL from EF-PRL.

If the PRL read or validation ofboth EF-EPRL and EF-PRLfail, MS shall build a defaultPRL, as defined in Section 2.3

2.3 Default PRL1

The purpose of a default PRL is to enable the MS to acquire service when no PRL is2

programmed into NV memory or RUIM, or when the PRL usage is disabled. Using a3

default PRL ensures that the MS would not enter an offline (or service required) state as4

a result of no PRL being programmed to NV/RUIM. When in offline state, the MS is not5

able to place calls, including emergency and OTASP calls.6


2.3.1 MS shall build a defaultPRL during power-up ifno valid PRL is stored inNV memory or RUIM

M Default PRL shall include allpreferred 1X channels from allthe bands that are supportedby the MS.

Default PRL shall allowoperation on any 1X systems,i.e., the SID field of all systemtable entries should be set towildcard (0).

2.4 OTA PRL Provisioning7


2.4.1 MS shall support IS-683-A-based OTAPRL provisioning

M

2.4.2 MS shall support IS-683-C-based OTAPRL provisioning

HD An R-UIM card thatsupports EF-EPRL isexpected to write an IS-683-C or newer PRL to the


12/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 6


EF-EPRL storage location(as opposed to the EF-PRLstorage location).

Mandatory for devices thatsupport 1xEV-DO

2.5 PRL Acquisition Table1


2.5.1 MS shall support aminimum of 80 uniquemode/band/channelcombinations in thePRL acquisition table

M PRL acquisition records thatlist channels result in onemode/band/channelcombination per listed channel.

PRL acquisition records thatlist blocks result in onemode/band/channelcombination for each preferredchannel that is part of theblock.

Mode/band/channelcombinations that are listedmultiple times are only counted

once.

2.5.2 MS shall support aminimum of 180 uniquemode/band/channelcombinations in thePRL acquisition table

HD

2.5.3 MS with DO capabilityshall support aminimum of 180 uniquemode/band/channelcombinations in the

PRL acquisition table

M

2.6 Roaming Indicator2

The roaming indicator is an 8-bit value that is associated with each system table entry.3

When the MS operates on a system that matches a particular system table entry, the4

roaming indicator (ROAM_IND) field of that entry is displayed to the user. When the MS5

operates on a system that is not listed in the PRL, the default roaming indicator6

(DEF_ROAM_IND) of the PRL is displayed to the user.7


13/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 7

Generally, the roaming indicator is only associated with a visual indication that is to be1

displayed to the user. In some special cases, however, the roaming indicator field is2

used for other purposes, such as determining the relative priority of systems that are not3

listed in the same GEO. Therefore, there is a need to define the relative priority of the4

roaming indicator values.5


2.6.1 MS shall support all 256values of the roamingindicator, i.e., EnhancedRoaming Indicator (ERI)

M

2.6.2 The preference order of

the roaming indicators(most to least) shall beaccording to Home andRoam groups: seeRemarks column

M The preference order shall be

as follows:

1. Home group, whichincludes the value 1and all roamingindicator values thatare defined by anoperator as customhome

2. Roam group, whichincludes all theremaining roamingindicator values thatare not part of the

home group

Note: A system is said to be ahome-system if its remainingroaming indicator valuebelongs to the home group

Roam_mask (as defined inTable A-1) specifies theroaming indicator values thatare defined by an operator ascustom home.

2.7 PRL Channels6

The acquisition table of the PRL lists mode/band/channel combinations that instruct the7

MS where to attempt service acquisition. Some older MS used to perform range checks8

on the channels that are listed in the PRL acquisition table at the time the PRL is pushed9

into the NV memory (or RUIM). If the channels were outside the range that is specified in10

the standard and/or supported by the MS, the PRL would be rejected.11

To allow for the addition of new modes, band classes, and channels, it is expected that12

the MS would be able to accept PRLs with channels they do not support. While13


14/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 8

operating with such PRLs, the MS would skip unsupported mode/band/channel1

combinations.2


2.7.1 MS shall not reject aPRL becauseacquisition recordslistingmode/band/channelcombinations that areoutside the spec rangeor MS capability

HD MS shall ignore the channelnumber when validating a PRL

2.7.2 MS shall skip over

mode/band/channelcombinations that arenot supported by MS

M When trying to acquire service

based on the PRL acquisitiontable, MS shall skip overmode/band/channelcombinations that are notsupported by the MS hardwareor software

The GEO and PRI fields of allsystem records must beaccounted for, regardless ifsuch system records aresupported by the MS (orpointing at supportedacquisition records). This isdone in order to ensure that

the MS correctly interprets thesystem table partitioning intoGEOs and preference tiers.

2.7.3 MS shall support allchannel numbers thatare defined in 3GPP2C.S0057 (as valid or notvalid) for a particularband-class/subclassthat is supported by theMS

M For example, MS capable ofband-class 0, subclass 0 or 1,shall allow and support thefollowing channel numbers:- 1 to 799 (inclusive)- 991 to 1023 (inclusive)

Similarly, MS capable of band-class 1 shall allow and supportthe following channel numbers:

- 0 to 1199 (inclusive)

2.8 PRL Enhancements for International Roaming3

PRL enhancements for international roaming enable substantial compression and4

simplification of the PRL system table. The idea is to use the MCC and IMSI_11_12 that5

come in the Extended System Parameters Message (ESPM) to identify 1X systems.6

Since each operator is expected to have only one MCC/IMSI_11_12 broadcasted7

throughout its network (in a particular country), it is sufficient to list one8

MCC/IMSI_11_12 entry for each one of the international roaming partners.9


15/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 9


2.8.1 MS shall support PRLwith MCC/IMSI_11_12based system recordsas described in CDGdocument #86

M See S2 for referencedocument.

2.9 NAM SID/NID List1

The NAM SID/NID list is an alternate mechanism through which an operator can specify2

SID/NID combinations for which the roaming indicator is set to OFF (i.e., set to 1). Since3

this mechanism does not provide any additional functionality to what is already provided4

by the ROAM_IND field of a PRLs system table entry, it is recommended to not utilize5

the NAM SID/NID list. Saying this, the MS shall support the NAM SID/NID list as follows.6


2.9.1 MS shall only use theNAM SID/NID list for thepurpose of overwritingthe roaming indicator toOFF (1)

M

2.9.2 MS shall not overwritethe roaming indicator ofsystems that are listedin the PRL and theirroaming indicator isother than 0 or 2

HD

2.9.3 MS shall support aminimum of 20 entriesin the NAMSID/NID list

M

2.10 PRL System Matching7

After obtaining the overhead information (SID, NID in the case of a 1X system) from the8

OTA signal, the MS attempts to find a match for the system in the PRL system table.9

The rules for deciding whether the OTA system information matches a particular system10

table entry are listed below and should be followed carefully to eliminate any ambiguity11

between the PRL writer and the MS interpretation of the PRL.12

In addition, because of the use of wildcard system IDs (SID=0 in the case of 1X), the MS13

may find a match with more than one system table entry. To resolve this situation, a14

more restrictive match overwrites all less restrictive matches. For example, an explicit15

SID match overwrites a wildcard SID match. Similarly, an explicit SID/NID match16

overwrites explicit SID + wildcard NID match.17


16/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 10


2.10.1 MS shall consider anOTA 1X system tomatch a system tableentry only if one or moreof the conditions listedin the Remarks columnare met. See also:2.10.4.

M a. OTA system matches theSID, NID, mode (1X), andband class of the PRL systemtable entry.

- The mode and band-classmatch are based on theacquisition table entry that isassociated (via the acquisitiontable index) with the systemtable entry. For a match, theassociated acquisition tableentry must contain an elementthat matches the OTA mode

(1X) and band class.

b. OTA system matches theSID, mode, and band class ofthe PRL system table entryand the system table entry NIDis set to wildcard (65535).

- The mode and band-classmatch are based on theacquisition table entry that isassociated (via the acquisitiontable index) with the systemtable entry.

c. OTA system matches themode, band-class, andchannel of the PRL systemtable entry and the systemtable entry SID is set towildcard (0).

- The mode, band-class, andchannels match are based onthe acquisition table entry thatis associated (via theacquisition table index) withthe system table entry


17/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 11


2.10.2 MS shall consider anOTA DO system tomatch a PRL systemtable entry only if one ormore of the conditionsin the Remarks columnare met

M a. OTA system matches theSubnet-ID and mode (DO) ofthe PRL system table entry.

-For the Subnet-ID to match,all the bits of the PRL Subnet-ID must match with the OTASubnet-ID. This implies thatOTA bits that are outside thelength of the PRL listedSubnet-ID are being ignored.

b. OTA system matches themode, band class, and

channel of the PRL systemtable entry. The system tableentry Subnet-ID is set towildcard (Subnet-ID length isset to 0).

Not applicable for devices thatdo not support 1xEV-DO

2.10.3 A more restrictive PRLmatch shall overwrite allless restrictive matches

M The order of the matchinglevels shall be as follows (mostto least restrictive):

1. Explicit SID and explicit NID

(Subnet-ID for DO)

2. Explicit SID and wildcardNID

3. Wildcard SID (wildcardSubnet-ID for DO)

2.10.4 All entries that share themost restrictive matchshall be considered

M In the case where the mostrestrictive match is with morethan one entry, all suchmatches are considered. Thiscondition is called a multi-GEO

SID, i.e., a SID that isrepeated, typically in morethan one GEO.

The roaming indicator to bedisplayed to the user is themost favorable out of allmatches, as defined in Req.2.6.2.

1


18/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 12

2.11 Preference Order1

The most important objective of system selection is to select the most preferred system2

that is available in a particular market. Because more than one system may be present3in a particular market, the MS needs to select among such systems based on their4

relative preference. This section specifies the requirements for determining the relative5

preference of any two systems.6


2.11.1 When comparing twosystems (that areavailable OTA), MSshall step in orderthrough the criteria

listed in the Remarkscolumn to determineand select the morepreferred one.

Once a criteriacriterionis met, MS shall use itand stop going throughthe list.

M 1. If there is a GEO in the PRLthat lists both systems, selectthe one that is listed as themore preferred in this GEO.

- If both systems are listed inmore than one GEO, only lookin the first GEO (from top tobottom of the PRL systemtable) that lists both systems todetermine the priority.

- If both systems are listed atthe same preference,select/stay on the originalsystem (to avoid ping-pongeffect).

2. If only one system is listed

in the PRL system table (as apreferred system), select theone that is listed in the PRL.

3. If the roaming indicator ofone system is more favorablethan the other (as defined inReq. 2.6.2), select the morefavorable one.

4. If one system is listed asmost preferred system in itsGEO, select that system.

5. If the position of channels in

the PRL acquisition table isdifferent, select the system forwhich its channel is listed first.The position of the channel isdetermined by the firstappearance of that channel inthe acquisition table whentraversed from top to bottom.

6. If one system is digital andthe other is not, select thedigital one.

7. Select/stay on the original


19/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 13


system (to avoid ping-pong

effect).

1

2.12 Forbidden Systems2


2.12.1 MS shall avoid selectinga system that isforbidden by the PRL or

user preferences

M A forbidden system is asystem that matches one ofthe following criteria:

A system that is listed asnegative in the PRL

A system that is not listed inthe PRL and the PREF_ONLYfield of the PRL is set to 1

A system that is forbidden byone of the users systemselection preferences, such as:

- Mode preference

- Band preference

- Roaming preference

When looking for service in thecontext of an emergency callorigination, OTASP callorigination, or redirection, MSis allowed to select a systemthat conflicts with thisrequirement, as defined inSections 4.9, 4.8, and 4.5,respectively.

2.12.2 MS shall avoid selectinga system that is lockedout by user

HD The MS shall maintain a list ofall 1X systems (SIDs) thatwere locked out by the usersince the MS was powered on.The MS shall avoid selectingand operating on any SID thatis listed in the users locked-out systems list.

If this feature is exposed at theUI, the currently acquiredsystem (SID) shall be added tothe locked-out system list upon


20/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 14


the user selecting this option.

When looking for service in thecontext of an emergency callorigination, OTASP callorigination, or redirection, theMS is allowed to select asystem that conflicts with thisrequirement, as defined inSections 4.9, 4.8, and 4.5respectively


21/64

3. MRU Table

The Most Recently Used (MRU) table is a mechanism that enables the MS to remember

the most recently used systems (mode, band, and channel) on which service was

provided. This table is ordered from the most recently used system, MRU[0], to the least

recently used system.

Each MRU table entry contains information about the mode (CDMA, AMPS, DO, etc.),band class (Cellular, PCS, etc.), and channel. The MRU, or a portion of which, is saved

into NV memory during power-down to speed up service acquisition the next time the

MS is powering up.

Note: The MS which operates in Hybrid 1x-DO mode, has to maintain two MRU tables:

one for CDMA/AMPS systems and another for DO systems.

3.1 MRU Storage


3.1.1 MS shall store in NV atleast the top 10 entriesof the MRU (MRU[0-9])when being powereddown

M

3.1.2 MS that operates inHybrid 1x-DO modeshall store in NV at leastthe top entry of the DO-MRU table (DO-MRU[0]) when beingpowered down

M

3.2 MRU Logging


3.2.1 MS shall log into theMRUmode/band/channelcombinations overwhich MS performed

M A channel shall only be loggedinto the MRU if, after receivingall overhead information(including 1X SID/NID or DOSubnet-ID), the MS decides to


22/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 16


successful pilot, sync,

and paging channelacquisition

stay and operate on the

acquired system.

3.2.2 During idle/accessoperation MS shall loginto the MRUmode/band/channelcombinations as shownin the Remarks column

M If SID, NID, or band class of a1X system (or the Subnet ID ofa DO system) is changed andthe MS decides to stay on theacquired system, the MS shalllog the currentmode/band/channelcombination.

If only the channel is changedand the MS decides to stay on

the acquired system, the MSshall log the currentmode/band/channelcombinations only if they areexplicitly listed in theacquisition table of the PRL.

During idle/access operation,the MS can get to newmode/band/channelcombinations through channelhashing, idle handoff, orchannel assignment to a newpaging channel.


23/64

4. System Selection1

This section provides information that is specific to 1X (CDMA and AMPS) system2

selection. This section describes the system selection requirements for specific3

conditions, such as power-up acquisition and acquisition after system lost.4

4.1 Power-up5

The power-up algorithms objective is to acquire the most preferred system that is6

available in the location where the MS is powering up and as soon as possible. The7

general assumption is that most of the time the MS is powering up in the same market8

where it was powered down. When this is not the case, i.e., the MS is powering up in a9

different market than the one it was powered down in, the assumption is that the MS is10

likely to be powering up in a market it visited recently. Therefore, the MRU is the main11

mechanism for speeding up service acquisition during power-up.12


4.1.1 MS shall attemptacquisitions on MRUentries (most to leastrecent) followed by PRLacquisition table (first tolast entry) whenpowering-up

M Within each PRL acquisitiontable entry, order should befirst to last channel.

This requirement does notexclude multiple acquisitionattempts on channels, likeMRU[0], before completing apass through the MRU andPRL

4.1.2 MS should indicate touser availability of

service once it found ausable system

M A usable system is one of thefollowing:

- A system that is listed in thePRL and is not marked asnegative

- A system that is not listed inthe PRL, but the PREF_ONLYfield of the PRL is set 0(unchecked); such a system iscalled available system


24/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 18


4.1.3 MS shall only stay andprovide service on anavailable system if nopreferred system wasfound after attemptingacquisition on all MRUand PRL entries and thePREF_ONLY field ofthe PRL is set to 0

M When MS finds an availablesystem, it shall indicate serviceto the user and continue goingthrough MRU and PRLchannels; only after attemptingacquisition (and failing) on allMRU and PRL entries, will MSprovide service on an availablesystems

4.1.4 When acquiring a PRLlisted system that is notthe most preferred in itsGEO, MS shall try to

acquire systems thatare listed as morepreferred in that GEO(top to bottom of GEO)

M If MS fails to acquire a morepreferred system, it shall goback and reacquire the originalsystem (assuming the original

system is not marked asnegative in the PRL).

4.1.5 MS shall stay andprovide service on asystem that is listed asmost preferred in itsGEO

M

4.2 Better Service Reselection (BSR)1

Generally speaking, the MS is required to operate on the most preferred system it is able2

to acquire according to the PRL and the current GEO.3

It is possible, however, that the MS would not be able to acquire the most preferred 1X4

system right after power-up (or later on) because the signal is temporarily blocked (by a5

building for example) or the MS is outside the coverage of the cell. Furthermore, the MS6

may be able to acquire an alternate 1X system that is not listed as the most preferred7

system in its GEO.8

When the MS runs into such a situation, it needs to perform better service reselection9periodically in order to be able to come back to the most preferred system once it10

becomes available (or a short time thereafter).11


4.2.1 MS shall perform betterservice reselectionwhen the PRL indicatesthat a more preferredsystem (compared withthe currently acquiredsystem) is available

M If MS fails to acquire betterservice, it shall go back andreacquire the original system


25/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 19


4.2.2 MS shall not performbetter servicereselection when MS isin Access or Trafficstate.

M This is done in order tominimize interference with useror network initiated activity

4.2.3 MS shall build the list ofchannels (i.e., the BSRlist) to be attemptedacquisition whenlooking for betterservice. See Remarkscolumn.

M If the original system is listedin the PRL system table, onlychannels that are associatedwith system table entries listedas more preferred than theoriginal system in the currentGEO shall be placed into BSRlist. The list should be ordered

according to MRU, thensystem table entries in thecurrent GEO

-If SID/NID/band-class of thecurrent system is matchingmore than one system tableentry, as specified in 2.10 (i.e.multi-GEO SID), the BSR listshould be built out of allmatching entries and theirGEOs.

If the original system is not

listed in PRL system table, allchannels from PRL acquisitiontable (but the currentlyacquired channel) shall beplaced into the BSR list; Thelist should be orderedaccording to MRU, then PRLacquisition table.


26/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 20


4.2.4 MS shall search forbetter service asspecified in the remarkscolumn.

M MS shall maintain twoconfigurable reselectiontimers, T_bsr_dig for periodicreselection when acquired ona digital system (e.g., CDMA)and T_bsr_amps for periodicreselection when acquired onan AMPS system.

- MS shall reset and startT_bsr_dig/T_bsr_amps timerupon acquisition or idlehandoff to a less preferreddigital/AMPS system.

- MS shall clear and stopT_bsr_dig/T_bsr_amps timerupon acquisition or idlehandoff to the most preferredsystem.

MS shall perform the followingalgorithm:

1. Wait forT_bsr_dig/T_bsr_amps timerto expire.

2. Try acquisition attempts onall channels of the BSR listbounded by 10 sec from startof reselection.

3. Reacquire original system.

4. Reset startT_bsr_dig/T_bsr_amps timer.

5. Go back to step 1.

The preference criteria that arespecified in Req. 2.11.1 shallbe used to determine if asystem that is acquired duringreselection is more preferredthan the original system. TheMS shall select the newlyacquired system if and only if itis more preferred according tothe Req. 2.11.1 criteria.

When reselection is cut shortdue to the 10 sec time limit,MS shall ensure that over timeall channels of the BSR list areattempted acquisitions.


27/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 21


See Table A-1 forrecommended value forT_bsr_dig re.

See Table A-1 forrecommended value forT_bsr_amps.

4.2.5 MS shall perform betterservice reselection 5sec after end of call (orcall attempt), asdescribed in 4.2

M Note: This requirement iswaived if 4.2.5b, which is moredesirable, is implemented.

For mobile terminated calls,MS must be released from

Traffic state for activity to beconsidered as a call.

4.2.5b MS shall perform betterservice reselectionT_bsr_call sec after endof call (or call attempt),as described in 4.2

HD For mobile terminated calls,MS must be released fromTraffic state for activity to beconsidered as a call.

See Table A-1 forrecommended value forT_bsr_call.

4.2.6 A SID, NID or band-

class change (duringidle operation) thatresults in a system thatis not the mostpreferred according tothe PRL should triggerreselection (as specifiedin 4.1.3 and 4.1.4) inT_bsr_newsys

M The SID, NID or band-class

can change as a result ofchannel hashing, idle handoff,or channel assignment to anew paging channel.

4.3 System Lost1

System lost is a condition where the MS loses service over a system that was previously2

successfully acquired. During operation, system lost can happen in one of three states,3

idle, access, or in-traffic.4

System lost typically results from a short signal fade, e.g., the signal is being temporarily5

blocked by a building. In more rare cases, system lost is a result of the MS moving6

outside the system coverage area.7


4.3.1 When currentlyacquired system is lost,

M 1. MRU[0]


28/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 22


MS shall attempt

acquisitions accordingto the order that isspecified in theRemarks column.

2. GEO (ordered according toMRU)

3. MRU

4. PRL acquisition table

If MS acquires a system that isnot the most preferredaccording to the PRL, MS shalltry to acquire more preferredservice as specified inRequirements 4.1.3 and 4.1.4.

4.4 Reverse Link Limited System1

In a reverse link limited system, the MS is able to acquire the forward link, but is not able2to reach the tower. For example, the MS is not able to reach the tower when trying to3register with the network. This situation is referred to as max access probes.4


4.4.1 MS shall follow thesesteps when observingmax access probes

failure

M Note: The MS shall follow thesilent redial requirement (as

defined in Table 4-1) if max

access probes is observedwhile the MS is trying tooriginate a call.

The MS shall build a channelslist as follows:

- If the original system is listedin the PRL system table, onlysystem table entries (i.e. theirassociated channels) that arewithin the same GEO shall beplaced into the list. The orderof channels should be

according to the order ofsystem table entries in thecurrent GEO. That is, thechannels that are pointed to bythe first system table entry inthe current GEO should be firstin the list.

- If the reverse link limitedsystem is not listed in the PRLsystem table, all channels fromthe PRL acquisition table shallbe placed into the list. Theorder of channels should be


29/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 23


according to MRU then PRL

acquisition table.

- The channel over whichaccess failed shall be placedlast in the channels list.

The MS shall try to acquireservice over the channels list(first to last channel).

4.5 Redirection1

One reason for using redirection is for edge of coverage condition. The idea is for2

network A to redirect the MS to network B as they reach the edge of coverage of3

network A. Network A and B may or may not be owned by the same operator.4

The edge of coverage redirection is typically done through beacon cells that are5

deployed along the edge of coverage of network A solely for the purpose of redirecting6

MS that approach the end of coverage. As the MS hands off to the beacon cell, it is7

being redirected, using Global Service Redirection Message (GSRDM), to network B.8

Another reason for using redirection is to help with load sharing between two networks.9

The idea is for network A to redirect the MS to network B when network A gets10

overloaded. Network A and B may or may not be owned by the same operator.11


4.5.1 Upon receiving invalidGSRDM withRETURN_IF_FAIL=0,MS shall avoid thecurrently acquiredchannel for 30 sec andsearch for service onother channels, asdescribed in theRemarks.

M Invalid GSRDM is one thatdoes not include any channelthat is supported by the MS

MS shall look for alternateservice as follow

1. GEO (ordered according toMRU)

2. MRU


4.5.2 Upon receiving invalidGSRDM withRETURN_IF_FAIL=1,MS shall stay on thecurrently acquiredsystem

HD Invalid GSRDM is one thatdoes not include any channelthat is supported by the MS


30/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 24


4.5.3 Upon failing to acquirethe systems that areincluded in a redirectionwithRETURN_IF_FAIL=0,MS shall avoid theoriginal channel overwhich the redirectionwas received for 30 secand search for serviceon other channels, asdescribed in theRemarks.

M MS shall look for alternateservice as follow

1. GEO (ordered accordingto MRU)

2. MRU


4.5.4 Upon failing to acquirethe systems that areincluded in a redirectionwithRETURN_IF_FAIL=1,MS shall try to reacquirethe original system overwhich the redirectionwas received

M

4.5.5 If, as a result offollowing aGSRDMredirection, MSselects other than themost preferred system(according to the PRL),MS should look forbetter serviceperiodically

M MS shall maintain aconfigurable timer,T_bsr_redir. MS shall resetand start T_bsr_redir whenacquiring a system that is notthe most preferred in its GEOas a result of following aGSRDM.

MS shall clear and stopT_bsr_redir timer upon anacquisition or idle handoff tothe most preferred system orupon losing the currentlyacquired system.

MS shall try to acquire betterservice upon expiration of

T_bsr_redir.

If MS fails to acquire betterservice, it shall go back andreacquire the original systemfrom which it got redirected.

See Table A-1 forrecommended value forT_bsr_redir.

4.5.6 MS shall not select andoperate on a system

M Note: MS is allowed tooperate on a system that is not


31/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 25


that is listed as negative

in the PRL as a result offollowing a redirection

listed in the PRL as a result of

following a redirection (even ifthe PREF_ONLY field of thePRL is set to 1).

Note: MS is allowed tooperate on a system thatconflicts with the users systemselection preferences as aresult of following a redirection(as long as the redirectingsystem is allowed by suchpreferences)

4.6 Call Release1


4.6.1 Upon call release MSshall first try to acquirethe channel that is listedin MRU[0]


If MS fails to acquire MRU[0], itshall perform system lostalgorithm based on MRU[0].

4.6.1b Upon call release MSshall first try to acquirethe last channel beingused in Traffic state

HD If MS fails to acquire the lastchannel being used in Trafficstate, it shall try to acquire thechannel that is listed inMRU[0].

If MS fails to acquire MRU[0], itshall perform system lostalgorithm based on MRU[0].

4.7 Voice and Data Call Origination2

Silent redial is a mechanism that increases the call origination success rate. The idea is3

to silently redial failed call originations, on the same or alternate systems, up to a given4

time limit since the call was originally placed.5


4.7.1 MS shall silently redialfailed call originationsfor a maximum of 30sec

M If more than 30 sec passedsince the original callorigination attempt was made,MS shall avoid silently


32/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 26


redialing a failed call

origination.

Once a call origination issuccessfully connected, itshould not be silently redialeddue to subsequent failures

4.7.2 MS shall follow the

policy in

Error!

Reference source notfound.1 when silentlyredialing voice/data

calls

M


33/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 27


4.7.3 GEO based alternateservice acquisition

M The MS shall build a channelslist to be scanned as follows:

- If the original system is listedin the PRL system table, onlychannels that are associatedwith system table entries thatare within the current GEO andcomply with one of thefollowing criteria shall beplaced into the list:

- System table entries that aresame or more preferred than

the original system

- System table entries thathave a home roaming indicator(as defined in Req. 2.6.2).

The list should be orderedaccording to the MRU, thensystem table entries in thecurrent GEO.

- If the original system is notlisted in the PRL system table,all channels from the PRL

acquisition table shall beplaced into the list. The listshould be ordered according tothe MRU then PRL acquisitiontable.

- The channel over whichorigination failed shall beplaced last in the channels list.

- The channel list should bebuilt only once per origination.

The MS shall try to acquireservice over channels from the

channels list (first to lastchannel).

The MS shall only stay and tryto place the call on systemsthat comply with one of thefollowing criteria:

- Systems that are same ormore preferred than theoriginal system (as defined inReq. 2.11.1)


34/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 28


- Systems have a homeroaming indicator (as definedin Req. 2.6.2)

- The MS is allowed to placethe call on a system from adifferent GEO (i.e., jump aGEO) as long this systemmeets one of the abovecriteria.

Table 4-1Silent Redial1

Call origination failure Silent redial actionNo 1X service Redial call in 4 secMax access probes Try acquiring alternate service as described in Req. 4.7.3; redial call in

4 sec

Reorder order Try acquiring alternate service as described in Req. 4.7.3 if

RSSI -100 dB; redial call in 4 sec

Intercept order Fail call origination

Access denied Try acquiring alternate service as described in Req. 4.7.3; redial call in4 sec

Signal fade in access(T40m) or Traffic state

Try acquiring alternate service as described in Req. 4.7.3 if


Channel assignmenttimeout (T42m)

Try acquiring alternate service as described in Req. 4.7.3 if


Call released by BS Fail call origination

4.8 OTASP Call Origination2


4.8.1 MS shall support allstandard OTASPactivation codes, asdefined by IS-683

M The standard activation codesare *228 and *228xx, wherexx can take on values between00 and 07 (inclusive).


35/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 29


4.8.2 MS shall support aminimum of 5 customOTASP numbers

M Each custom OTASP numbercan be up to 32 digits long.

Custom OTASP numbers shallbe stored in NV memory orRUIM

4.8.3 MS shall use the PRL(rather than theactivation block) toacquire service duringOTASP call if one of theconditions (seeRemarks column) istrue

M PRL is locked, i.e., the ServiceProgramming Code (SPC) isset to a value other than000000.

User dialed *228 or a custom

OTASP number

4.8.4 When performing blockactivation MS shallperform the steps inRemarks column

M 1. Build a list of preferredchannels (OTASP channelslist) that are associated withthe dialed OTASP activationcode, as defined in IS-683.

2. Order the OTASP channelslist according to MRU, thenGEO, then small to largechannel.

3. If the MS is currentlyacquired on a channel thatmatches one of the channelsin the OTASP channels list,place the OTASP call over thatcurrently acquired channel.

4. Else, step through theOTASP channels list and try toacquire service and place theOTASP call. The MS shall tryto place the OTASP call onany system that it is able toacquire, regardless if suchsystem is forbidden by the

PRL (e.g., a negative system)or user preferences.

5. If failing to place the OTASPcall on the entire OTASPchannels list, end the OTASPactivation process

4.9 Emergency Call Origination1

The objective of an emergency call is to connect service as soon as possible. When the2

user is trying to originate an emergency call the MS may need to attempt acquisition of3


36/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 30

negative systems or systems that are not listed in the PRL. The assumption is that any1

system the MS is able to acquire would connect an emergency call (regardless of2

whether the MS is a subscriber or roamer of that system).3

Note that the determination of which dial string is considered as emergency origination is4

beyond the scope of system selection. This determination is typically done by the phone-5

book manager, which is in the domain of the UI.6


4.9.1 If an emergency call isplaced when a systemis acquired, MS shall tryto place the emergencycall on that system

M

4.9.2 If an emergency call isplaced when no systemis acquired or iforigination fails on theoriginal system, MSshall follow the steps inthe remarks

HD 1. The MS shall build andorder an emergency channelslist as follows:

- All mode/band/channelcombinations MS acquiredsince power-up (most to leastrecently acquired)

- MRU (most to least recentlyacquired)

- PRL acquisition table (first tolast entry)

- All preferred channels fromall band classes that aresupported by the MS (asdefined in [S1])

- No system (i.e., mode, band,channel combination) shouldbe listed multiple times inemergency list

2. The MS shall traverse theemergency channel list, top tobottom, and try to acquireservice and place the call. TheMS shall try to place theemergency call on any systemthat it is able to acquire,regardless if such system isforbidden by the PRL (e.g., anegative system) or userpreferences.

3. If the MS fails to connect thecall, it should continue


37/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 31


traversing the list. Note that

the MS is allowed to attemptacquisition of a particularchannel multiple times, but itshould not get stuck forever onany one channel.

4. If the MS traversed theentire emergency list withoutbeing able to connect theemergency call, it shouldrestart traversing the list fromthe beginning. The MS shouldonly stop list traversal uponsuccessfully connecting the

emergency call or user endingthe call origination.

4.9.3 After ending anemergency call that wassuccessfully connected,MS shall enterEmergency Callbackmode.

HD In Emergency Callback modethe MS shall only select thesystem over which theemergency call wasconnected. If that system islost, the MS shall try toreacquire it.

The MS shall exit Emergency

Callback mode upon one ofthe following conditions:

- User requested to end theEmergency Callback mode.

- System over which theemergency call was connectedis lost, and the MS is not ableto acquire that system for 15sec.

- User is trying to place a newemergency call.


38/64

5. DO System Selection Hybrid Mode1

In 1x-DO Hybrid mode (Hybrid mode for short) the MS operates as 1X and DO devices2

simultaneously. Therefore, in Hybrid mode, both protocol stacks (1X and DO) are active3

at the same time.4

In Hybrid mode, the DO System selection is limited to systems that are collocated5

(associated) with the most recently acquired 1X system. The association is determined6according to the PRL.7

Note: The requirements in this section are only applicable for MS that are capable of8

1x-DO Hybrid operation. There are no differences in DO system selection9

between Rev 0 and Rev A.10

5.1 Collocated List11

The collocated list is a list of DO systems that are associated with a 1X system in a12

given GEO (or GEOs in the case of a 1x multi-GEO match). The collocated list is used13

for narrowing down the list of DO channels to be attempted acquisition when looking for14

DO service.15

The assumption is that DO service is overlaid on top of a 1X network. Limiting16

acquisition attempts of DO to systems that are collocated (associated) with the acquired17

1X system speeds up the search for DO service, as well as saves on power18

consumption.19

Note that the collocated list is updated whenever a new 1X service, which has a different20

GEO and/or association tag than the previous 1X service, is acquired.21

The following example illustrates the collocated list concept. The acquisition table (Table22

5-1Table 5-1) lists CDMA and HDR channels while the system table (Table 5-2Table 5-2)23

lists CDMA and HDR systems in a given GEO.24

In this GEO, the HDR systems that are listed at indices 0 and 2 are associated with the25

1X system that is listed at index 3. Therefore, once MS acquires service on a 1X system26

that matches system table index 3, the collocated list would contain DO channels27

BC1/150 and BC1/1125.28

Similarly, if MS acquires a 1X system that matches system table index 4, the collocated29

list would contain channel DO BC0/100.30

If MS acquires service on a 1X system that matches system table index 5, the collocated31

list would not contain any DO channels32


39/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 33

Table 5-1 PRL Acquisition1

Index Acq_type Band Num_chans Channels

0 10 (CDMA Generic) BC1 1 2251 11 (HDR Generic) BC1 1 150

2 10( CDMA Generic) BC0 1 25

3 11( HDR Generic ) BC0 1 100

4 10 (CDMA Generic) BC1 1 75

5 11 (HDR Generic) BC1 1 1125

2

Table 5-2 PRL System Table3

Grp Index Type Neg/pref Geo PriAcqindex

RoamInd

Assninc

AssnTag

G1 0 IS-856 Preferred New More 1 1 Yes 1

1 IS-856 Preferred Same More 3 1 Yes 2

2 IS-856 Preferred Same More 5 1 Yes 1

3 95(A,B)/1X Preferred Same More 0 1 Yes 1

4 95(A,B)/1X Preferred Same More 2 1 Yes 2

5 95(A,B)/1X Preferred Same More 4 1 No

4


5.1.1 When first powering up(before 1X service is

acquired), thecollocated list shall bepopulated with all DOchannels that areassociated with a 1Xsystem (any 1X system)

M In other words, collocated listwould be built out of the set of

acquisition table entries thatare pointed to by a DO systemtable entry for which the

ASSOCIATION_INC field isset to 1.

Collocated list shall be orderedfrom top to bottom of PRLsystem table.

5.1.2 After the first time 1Xservice is acquired, thecollocated list shall bepopulated with DOchannels that areassociated with themost recently acquired1X service. See also2.10.4.

M Note that even when 1Xservice is lost, the collocatedlist would still be populatedwith DO channels that areassociated with the mostrecently acquired 1X service.

Collocated list shall be orderedfrom top to bottom of thecurrent GEO.


40/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 34


5.1.3 The collocated list shallbe updated whenever anew 1X service withdifferent GEO and/orassociation tag(compared with theprevious 1X service) isacquired

M

5.1.4 MS shall attempt toacquire DO service onchannels from thecollocated list whenlooking for DO service

M

5.1.5 MS shall only provideservice on a DO systemthat is collocated withthe most recentlyacquired 1X system.See also 2.10.4.

M When acquiring a system fromthe collocated list the MS shallcheck the PRL system table toverify that the DO system isassociated with the mostrecently acquired 1X system.

For a DO system to beassociated with the mostrecently acquired 1X system,there must be a GEO in thePRL system table that containsthe following:

- A 1X system table entry thatmatches the most recentlyacquired 1X system

- A DO system table entry thatmatches the acquired DOsystem

- Within this GEO the 1X andDO system table entries areassociated, i.e., the

ASSOCIATION_INC field ofboth entries is set to 1 and

the ASSOCIATION_TAG fieldof both entries is set to thesame value

If no 1X system is acquiredsince power-up, a DO systemshall be considered associatedwith 1X if its

ASSOCIATION_INC field isset to 1.

1


41/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 35

5.2 Power-up1


5.2.1 When powering up, MSshall first attempt toacquire 1X service

M

5.2.2 MS shall attemptlooking for DO serviceonce a 1X system thatis collocated with one ormore DO systems isacquired

M

5.2.3 When acquiring acollocated DO systemthat is not the mostpreferred collocated DOsystem in its GEO, MSshall try to acquirecollocated DO systemsthat are more preferredin that GEO (top tobottom of GEO)

M If the MS fails to acquire amore preferred collocated DOsystem, it shall go back andreacquire the original system(assuming the original systemis not marked as negative inthe PRL).

5.2.4 MS should indicate touser availability of DOservice once it found a

usable DO system asdescribed in 5.1.5

M

5.3 Idle Operation2

The relationship between 1X and DO is a master-slave. This implies that during idle3

operation, the DO service must be aligned at all times according to the most recently4

acquired 1X service.5

For example, when a new 1X service is acquired, the DO/1X association must be6

checked. If the DO system is no longer associated with the newly acquired 1X system,7

the MS must look for a new DO service (that is associated with the 1X system) by8

attempting acquisitions over the channels that are in the collocated list.9

If the newly acquired 1X system is not associated with any DO system, the collocated list10

would not contain any DO channels. In such a case, no DO service will be acquired.11


42/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 36


5.3.1 During idle operationMS shall align the DOservice according to themost recently acquired1X service at all times

M DO may become unassociatedwith the most recently acquired1X service due to one of thefollowing conditions:

- A new 1X service withdifferent GEO and/orassociation tag (compared withthe previous 1X service) isacquired

- MS received a new Subnet-ID OTA, and this Subnet-ID isnot associated with the most

recently acquired 1X service

5.4 DO Better Service Reselection (DBSR)1

Generally speaking, the MS is required to operate on the most preferred collocated DO2

system it is able to acquire according to the PRL and the current GEO.3

It is possible, however, that the MS would not be able to acquire the most preferred4

collocated DO system right after power-up (or later on) because the signal is temporarily5

blocked (by a building, for example) or the MS is outside the coverage of the DO cell.6

Furthermore, the MS may be able to acquire an alternate DO system that is not listed as7

the most preferred collocated DO system.8

When the MS runs into such a situation, it needs to perform better DO service9

reselection periodically in order to be able to come back to the most preferred system10

once it becomes available (or sometime thereafter).11


5.4.1 MS shall perform betterservice reselectionwhen the system tableindicates that a morepreferred collocated DO

system (compared withthe currently acquiredsystem) is available inthe current GEO

M If the MS fails to acquire amore preferred system, it shallgo back and reacquire theoriginal system


43/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 37


5.4.2 MS shall not performbetter servicereselection when MS isin Access or Trafficstate

M This is done in order tominimize interference with useror network-initiated activity.

If the reselection timer expireswhen MS is in Access orTraffic state, MS shall delayreselection until such time MSis back in Idle state (and inaccordance with Req. 5.4.3and 5.4.5)

5.4.3 MS shall not performbetter servicereselection immediatelyafter transitioning backto DO Idle from DOConnected state

HD This is done in order tominimize interference with useror network initiated activity.

The MS shall maintain aconfigurable T_dbsr_holdtimer. The MS shall reset andstart T_dbsr_hold (regardlessif it is already running) upontransitioning back to idle fromConnected state.

The MS shall not performbetter service reselectionbefore T_dbsr_hold expires.

See Table A-1 forrecommended value forT_dbsr_hold.

5.4.4 MS shall build the list ofchannels (i.e., DBSR

list) to be attemptedacquisition whenlooking for better DOservice as explained inthe Remarks column.

M Only DO systems (and theirassociated channels) that areassociated with the mostrecently acquired 1X serviceand are more preferred thanthe currently acquired DOsystem shall be placed into theDBSR list.

The DBSR list should beordered according to thecurrent GEO (top to bottom ofGEO).


44/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 38


5.4.5 MS shall search forperiodic better DOservice as explained inthe Remarks column.

M The MS shall maintain twoconfigurable better DO servicereselection timers: T_dbsr forperiodic DO reselection andT_dbsr_call for reselectionafter end of user originated DOcall.

- MS shall reset and start theT_dbsr timer (if it is not alreadyrunning) upon acquisition oridle handoff to a less preferredsystem.

- MS shall reset and start theT_dbsr_call timer (regardless ifit is already running) upon endof user originated DO call on aless preferred system.

- MS shall clear and stop theT_dbsr and T_dbsr_call timersupon an acquisition or idlehandoff to the most preferredsystem.

MS shall perform the followingalgorithm:

1. Wait for T_dbsr_hold timerto expire if it is currentlyrunning.

2. Wait for T_dbsr orT_dbsr_call (if currentlyrunning) timer to expire.

3. Try full acquisition attemptson all channels that are in theDBSR list.

4. Reacquire the originalsystem.

5. Reset and start the T_dbsrtimer.

6. Go back to step 1.

See Table A-1 forrecommended values forT_dbsr and T_dbsr_call.

5.5 DO System Lost1


45/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 39

System lost is a condition where the MS loses service over a system that was previously1

successfully acquired. During operation, system lost can happen in one of three states:2

idle, access, or in-traffic.3

System lost typically results from a short signal fade, e.g., the signal is being temporarily4

blocked by a building. In more rare cases, system lost is a result of the MS moving5

outside the system coverage area.6


5.5.1 After DO system lostMS shall attempt toreacquire service fromcollocated list accordingto MRU order

M MS may try to acquire serviceover MRU[0] multiple times

5.5.2 If MS experiences 3consecutive fades onthe same system, itshall avoid the lostchannel for 60 sec

HD A consecutive system lost isone that is not separated bymore than 20 sec from theprevious system lost

5.5.3 When acquiring acollocated DO systemthat is not the mostpreferred collocated DOsystem in its GEO, MSshall try to acquire

collocated DO systemsthat are more preferredin that GEO (top tobottom of GEO)

HD If the MS fails to acquire amore preferred collocated DOsystem, it shall go back andreacquire the original system(assuming the original systemis not marked as negative in

the PRL)

5.6 Redirection7

Redirect message allows the network to instruct the MS to move to a different channel.8

One reason for using redirection is for edge of coverage condition. The idea is for9

network A to redirect the MS to network B as they reach the edge of coverage of10

network A. Network A and B may or may not be owned by the same operator.11

The edge of coverage redirection is typically done through beacon cells that are12 deployed along the edge of coverage of network A solely for the purpose of redirecting13

the MS that approach the end of coverage. As the MS handoff to the beacon cell it is14

being redirected using Global Service Redirection Message (GSRDM) to network B.15

Another reason for using redirection is to help with load sharing between two networks.16

The idea is for network A to redirect MS to network B when network A gets overloaded.17

Network A and B may or may not be owned by the same operator.18


46/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 40


5.6.1 MS shall leave thecurrent DO channel ifredirect is received inQuickConfig duringsystem acquisition

M Quick redirect instructs themobile to move away from thecurrent system/channel. IfQuickConfig indicatesRedirection while MS is in theprocess of acquiring a DOsystem, MS shall skip thechannel and look for DOservice on other channels

5.6.2 MS shall follow thesesteps upon receiving aredirection

M 1. Try to acquire DO serviceover the DO channels that areincluded in the redirection.

2. If acquisition fails on allchannels (or no channels wereincluded), the MS shall avoidthe original channel over whichthe redirection was receivedfor 30 sec.

- MS is allowed to select andoperate on a DO system that isnot collocated with the mostrecently acquired 1X systemas a result of following aredirection from a collocatedsystem.

- MS shall not select andoperate on a DO system that isforbidden (as defined inSection 2.12) as a result offollowing a redirection

5.6.3 If as a result of followinga redirection, MSselects other than themost preferredcollocated DO system(according to the PRL),MS should look for

better DO serviceperiodically (as definedin Section 5.4)

M The timer that specifies thereselection period in thecontext of redirection isT_dbsr_redir (rather thanT_dbsr).

See Table A-1 for

recommended value forT_dbsr_redir

5.7 Attempt to Open a Connection1

Even though the MS is able to acquire a particular DO network, it may still experience2

difficulties to open a connection on this network for a variety of reasons.3

As a general guideline, the MS should not get stuck on a network where it is not able to4

open a connection.5


47/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 41

Note: Some of the failures below are treated differently if they happen as a result of MS1

trying to negotiate a session. In other words, such failures would be considered2

as session negotiation related failures (as defined in Section 5.8) if they happen3

while MS is trying to negotiate a session.4


5.7.1 MS shall avoid the DOchannel for 7 min ifaccess attempt failsbecause of persistencetest failure

M

5.7.2 MS shall avoid the DOchannel for 1 min if DO

observes max accessprobes failure

M Note: This requirement iswaived if 5.7.2b, which is more

desirable, is implemented.

5.7.2b MS shall avoid the DOchannel according to a2, 4, 8, 8, 8, 16 minschedule if DOobserves max accessprobes failure

HD The MS shall maintain a maxaccess probes failure counter.The MS shall increment thecounter upon a max accessprobes failure. The MS shallreset the counter to 0 uponcompleting successful accessattempt.

Upon max access probesfailure, the MS shall avoid thecurrent channel for:

- 2 min if the counter is 1


- 8 min if the counter is 3 to 5

- 16 min if the counter is 6 orgreater

5.7.4 MS shall avoid the DOchannel for 10 min if

access attempt failsbecause of connectiondeny withreason=Authenticationor billing

M Note: The MS shall follow thesession negotiation failure

requirement (as defined inReq. 5.8.2) if Connection Denywith reason=Authentication orbilling is received from thenetwork while the MS is tryingto negotiate a session


48/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 42


5.7.5 MS shall avoid the DOchannel for 1 min ifaccess attempt failsbecause of connectiondeny withreason=Network-Busyor General

HD Note: This requirement iswaived if 5.7.5b, which is moredesirable, is implemented.

Note: The MS shall follow thesession negotiation timeoutrequirement (as defined inReq. 5.8.1) if Connection Denywith reason=Network-Busy orgeneral is received from thenetwork while the MS is tryingto negotiate a session

5.7.5b MS shall avoid the DOchannel for 1 min ifaccess attempt fails 3consecutive timesbecause of connectiondeny withreason=Network-Busyor General

HD Note: The MS shall follow thesession negotiation timeoutrequirement (as defined inReq. 5.8.1) if Connection Denywith reason=Network-Busy orgeneral is received from thenetwork while the MS is tryingto negotiate a session

5.7.7 MS shall move awayfrom the DO channel if itobserves 3 consecutiveTraffic Channel

Assignment (TCA orRTCAck) timeouts

HD Note: The MS shall follow the

session negotiation timeoutrequirement (as defined inSection 5.8) if it observes TCAor RTCAck timeouts whiletrying to negotiate a session.

The MS shall declare a TCAtimeout upon failure to acquirethe forward traffic channel afterTCA.

The MS shall maintain aTCA/RTCAck counter. The MSshall increment the counterupon TCA or RTCAck timeout.The MS shall reset the counterto 0 upon successful TCA orSubnet-ID change.

Upon TCA or RTCAck timeout,the MS shall move away fromthe current channel if counteris 3 or greater.

5.8 Session Negotiation1

Session negotiation is performed between the MS and the network. Session negotiation2

enables the MS to obtain UATI, exchange various air interface protocol parameters, etc.3

A session is a shared state maintained between the MS and the network.4


49/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 43

As a general guideline, the MS should not get stuck in a network where session1

negotiations are not successful.2

Session negotiation is done in a network where there is no open session or the session3keep-alive timer has expired.4


5.8.1 MS shall avoid the DOchannel according to a1, 2, 4, 8, 16 minschedule if sessionnegotiation times out

HD Session negotiation timeoutoccurs when the MS fails toopen/negotiate a session dueto poor RF or network overload(i.e., network is not respondingto the MS request to open asession). For example, thefollowing failures are

considered a sessionnegotiation timeout if theyhappen repeatedly (typically 5or more times) when the MS istrying to open/negotiate asession:

- Traffic Channel Assignment(TCA or RTCAck) timeouts

- Connection deny withreason=Network-Busy orGeneral

The MS shall maintain asession negotiation timeoutcounter. The MS shallincrement the counter upon asession negotiation timeout.The MS shall reset the counterto 0 upon successful sessionnegotiation or Subnet-IDchange.

Upon session negotiationtimeout, the MS shall avoid thecurrent channel for:




- 8 min if the counter is 4 to 6

- 16 min if counter is 7 orgreater

5


50/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 44


5.8.2 MS shall avoid the DOchannel for 10 min ifsession negotiation fails

M Session negotiation failureoccurs when MS is explicitlybeing rejected by the networkwhen trying to open/negotiatea session. For example, thefollowing failures areconsidered a sessionnegotiation failure if theyhappen repeatedly when theMS is trying to open/negotiatea session:

- Repeated UATI assignmentfailures (typically 5 failures)

- Network repeatedly sendsConnection Deny withreason=Authentication-or-Billing (typically 5 or moretimes)

- Network repeatedly closesthe session before negotiationis completed (typically 3 ormore times). Note that networkis expected to close thesession if AN authenticationfails.

- Any other repeated protocolnegotiation failure, such asnoncompliant signalingmessage fields or messageexchange timeout

5.9 Data Call Origination1

Generally, data call originations are preferred over DO. Under certain failure conditions,2

however, data call shall be placed over 1X. This section lists the requirements for data3

call origination and various call failure handling scenarios.4


51/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 45


5.9.1 MS shall first try toplace a data call on DO

M If only 1X service is acquiredat the time the call is placed(and the collocated listcontains DO channels), theMS shall try quick acquisitionon the most recently acquiredcollocated DO channel (if nocollocated channel is in theMRU, the MS shall try quickacquisition on first collocatedDO channel according to thecurrent GEO). If successful,the MS shall first try to placethe call over DO. Else, the MS

shall try to place the call on1X.

5.9.2 MS shall silently redialfailed data calloriginations for amaximum of 30 sec

M If more than 30 sec passedsince the original attempt wasmade, the MS shall not silentlyredial a failed call origination.

The 30 sec limit includes DOand 1X redials.

5.9.3 When silently redialinga DO call, MS shallfallback to 1X ifattempts on allcollocated DO channelsfailed


If 1X service is availableand the MS fails twoorigination attempts on DO,the MS shall try to place thecall on 1X (even ifacquisition/origination wasnot attempted on allcollocated DO channels)

The MS shall attemptacquisition and originationon other collocated DOchannels if the currentchannel is to be avoided asa result of a failure, such asmax access probes,connection deny,RTC/RTCAck failure, orsignal fade. If the MS failsacquisition/origination on allcollocated DO channelsand 1X service is acquired,the MS shall try to place thecall on 1X at once.


52/64


Ref Doc. 143, Ver. 0.6 16 Aug 2006 46


5.9.3b When silently redialinga DO call, MS shallfallback to 1X ifattempts on allcollocated DO channelsfailed

HD The MS shall attemptacquisition and originationon other collocated DOchannels if the currentchannel is to be avoided as aresult of a failure, such as maxaccess probes, connectiondeny, RTC/RTCAck failure, orsignal fade. If the MS failsacquisition/origination on allcollocated DO channels and1X service is acquired, the MSshall try to place the call on 1X

5.10 Idle Digital Mode (IDM)1

Idle Digital mode is a mechanism that enables the MS to inform the network over which2

mode (1X or DO) the network should page the MS with incoming data calls. Generally3

IDM would be set to DO, indicating that data pages should come over the DO network.4

Under certain failure conditions, however, IDM would be set to 1X.5

It is implicitly assumed that IDM is aligned with the mode (DO or 1X) on which a data call6

is currently connected.7


5.10.1 MS shall set IDM to DOwhen DO service isacquired

M If IDM is changed from 1X toDO during a PPP session, theMS shall send DO locationnotification to inform thenetwork that incoming pagesshould come over DO

5.10.2 MS shall set IDM to 1Xif DO service is lost for5 or more sec

M If IDM is changed from DO to1

Recommended System Selection Requirements for 1X and 1xEV-DO-Capable Terminals_143v1.1

Documents

Transcript of Recommended System Selection Requirements for 1X and 1xEV-DO-Capable Terminals_143v1.1