tan29.00_timing, delay and access parameters

Alcatel-Lucent - Proprietary

This document contains proprietary information of

Alcatel-Lucent and is not to be disclosed or used

except in accordance with applicable agreements.

Copyright © 2007 Alcatel-Lucent

Unpublished and Not for Publication

All rights reserved

Wireless Business Group

subject: CDMA 1xEV Translation Application Note #1

Timing, Delay, and Access Parameters

Version 12.0

date:

December 5, 2007

Abstract

There are several CDMA 1xEV translation parameters that involve timing, delay, and access.

The values of these translation parameters must be set correctly for proper operation of a CDMA

1xEV system. The purpose of this translation application note is to explain the functions of these

important translation parameters, the relationship among them, and to provide their

recommended values.

Version History

Version Changes

1.0 Updated document for CDMA 1xEV Cell Release 1.0





5.0 Updated document for CDMA 1xEV Cell Release 22.01/22.02



8.0 Updated document for CDMA 1xEV Cell Release 25.0 -Updated Section 2.1 – Access Cycle Duration, Transmission Antenna Propagation Delay

-Updated Section 2.3 – Access Preamble Length, Access Capsule Max Length

-Updated Section 3.3.1 – Normal Paging Method

9.0 Updated document for CDMA 1xEV Cell Release 26.0 -Updated Section 2.1 – Transmission/Receive Antenna Propagation Delay, Open Loop Adjustment

CDMA 1xEV RF Translation Application Note #1 Version 12.0

Alcatel-Lucent – Proprietary

See notice on first page 2

-Updated Section 5 – Test Carrier

-Updated Section 7 – Multiple Carriers: Hashing and Traffic Load Balancing

-Updated Section 8 – Session Close feature

10.0 Updated document for CDMA 1xEV Cell Release 27.0 -Updated Section 2.1 – Transmission/Receive Antenna Propagation Delay

-Updated Section 5 – Test Carrier

-Updated Section 8 – Session Close feature

11.0 Updated document for CDMA 1xEV Cell Release 28.0 (RNC Release R28 SU1) -Updated Section 2.1 – Transmission/Receive Antenna Propagation Delay

-Updated Section 2.1 – Access Cycle Duration, Open Loop Adjust

- Updated Section 2.3 – Access Capsule Max Length

- Updated Section 3.2.2 – Distance based Registration

- Updated Section 3.3.1 – Normal Paging method

-Update Sections 7.3,7.4, 7.5 – Traffic Channel Load Balancing Algorithm and Border Carrier

12.0 Updated document for CDMA 1xEV Cell Release 29.0 (RNC Release R29 SU2) -Updated Section 2.1 – TxDelay / RxDelay per Sector-Carrier capability and increase in range of

TxDelay; new recommendation for Open Loop Power Adjust and Access Cycle Duration parameters

- Updated Section 2.3 – New recommendation for Access Capsule Max Length parameter

- Updated Section 3, 3.2.1, 3.3.1 – Default Best-Effort Paging, Subnet based Registration, Default

Best Effort Normal Paging method

-Updated Section 5 – New implementation of Test Carrier with RNC R29

-Update Sections 7.4, 7.5 – Traffic Channel Load Balancing Algorithm with QoS enabled; Traffic

Channel Load Balancing between Border and Non-Border carriers; Important Notes

Update Sections 8 – Session Close Feature




1 Introduction

There are several CDMA 1xEV translation parameters that impact timing, delay, and access. A

correct set of values of these translation parameters is required for the proper operation of a

system. The purpose of this document is to explain the functions of these translation parameters

and to provide their recommended values.

2 Access Channel

Access channel is used by an access terminal (AT) to initiate communication with the access

network (AN) or to respond to the AT directed message when AT does not have a traffic channel

assigned. The access channel consists of a pilot channel and a data channel. The information on

the access channel (Rev0 and Default Access Channel in RevA) is transmitted at a fixed rate of

9.6 kbps.

The reverse link of a CDMA 1xEV system, which uses the CDMA scheme, allows multiple users

to simultaneously share the same frequency band. The demodulator extracts the desired user’s

signal by matching the modulated user-specific PN code. To this end, the demodulator must

exactly match the path delay such that the PN code can be in phase with the transmitted

sequence. The demodulator needs to test many path delay hypotheses to find the best match of

the path delay. The search window (both in the base station and AT) specifies the range for the

path delay hypotheses.

Unlike 3G1x, there is no PN randomization in 1xEV. PN randomization increases the probability

that the base station will be able to separately demodulate transmissions from multiple mobile

stations in the same access channel slot, especially when many mobile stations are at a similar

range from the base station.

In general, there are three goals in optimizing the access translation parameters: minimize

interference to the existing traffic users, minimize delay perceived by the end user, and maximize

access success rate.

2.1 Basic Translation Parameters that Impact Access, Timing, and Delay

There are several access, timing, and delay related translation parameters that are fundamental to

the operation of a CDMA 1xEV system. Their definition and recommended values are included

below.

Sector size (sectorsize): The maximum range of a cell’s desired coverage. It accommodates the

maximum possible air propagation delay (one way). The recommended value is 10 miles.




Maximum number for an access probe sequence (maxprobesequence): Maximum allowable

number of access probe sequences for a single access attempt, either AT initiated or AN initiated.

The recommended value is 2.

Number of access probes (probenumstep): Maximum number of access probes an AT is

allowed to transmit in a single access probe sequence. The recommended value is 5.

Access cycle duration (accesscycleduration): It is the basic time unit of all access channel

activities. It indicates how often base station needs to start a new probe search and when mobile

can transmit a probe. In 3G1x, access probe must be transmitted at the access probe boundary

(equal to access channel slot boundary). In 1xEV, access probe can be transmitted at a time T

such that T modulo access cycle duration equals 0. The 1xEV standard, unlike 3G1x, allows

access cycle duration to be shorter than access probe duration. This is shown in Figure 1.

However, when probe search period is shorter than the probe transmission period, base station

requires multiple access channel elements. The SBEVM (CSM6800) supports multiple access

channel elements (at least 8). Hence, SBEVM implementation allows setting of access cycle

duration such that the search period is less than the probe transmission period (Preamble +

Message Capsule). On the other hand, DBEVM supports only one access channel element.

Therefore, the search period must be greater than or equal to transmission period. The access

cycle duration can only take on the following values: 16, 32, 64, and 128 slots. The

recommended value is 16 slots (26.67 ms), that is, 1 frame. The recommendation was changed

from 64 slots to 16 slots starting with R28.02. This is to reduce call setup latency for Push-to-

Talk (PTT) service and also to increase access channel capacity. This setting is supported for

SBEVM only. The recommended value for DBEVM is still 64 slots.

Figure 1. 1xEV Access Channel Structure

Access channel probe backoff (probebackoff): If the maximum allowable number of access

probes has not been reached, the next access probe is transmitted after TA + RT time. TA is a

fixed waiting time defined by the IS-856 standard as 128 slots (213.376 ms) whereas RT is an




additional random delay, which ranges from 0 to probebackoff in the units of access cycle

duration. The recommended value is 4 (106.67 ms) for SBEVM and 4 (426.67ms) for DBEVM.

Access channel probe sequence backoff (probesequencebackoff): If the maximum allowable

number of access probe sequences has not been reached, the next access probe in the next access

probe sequence is transmitted after TA + RS time. TA is a fixed waiting time defined by the IS-

856 standard as 128 slots (213.376 ms) whereas RS is an additional random delay, which ranges

from 0 to probesequencebackoff in the units of access cycle duration. The recommended value is

8 (213.38ms) for SBEVM and 8 (853.44 ms) for DBEVM.

Transmit antenna propagation delay (txdelay): The delay observed in the forward transmit

path between forward link modem (FLM, DBEVM) or SBEVM and the antenna connector.

Receive antenna propagation delay (rxdelay): The delay observed in the receive path between

the antenna connector and the reverse link modem (RLM, DBEVM) or SBEVM. Starting with

Cell/RNC Release R24, this translation parameter is used by the 1xEV system for both access

and handoff.

The recommended values of Txdelay and Rxdelay are shown in Table 1. The Txdelay is

independent of the controller (CRC versus URCm for legacy Mod cells) used.

Prior to RNC R29 SU1, translation parameters Transmit Antenna Propagation Delay (TxDelay)

and Receive Antenna Propagation Delay (RxDelay) parameters were per sector. Also, the range

of TxDelay was restricted to 62us. RxDelay supported range up to 400us. RNC R29 SU1 uses

spare sector-carrier translation parameters, Auxiliary Per-Sector-Carrier Control – 1 and

Auxiliary Per-Sector-Carrier Control – 2, to allow provisioning of TxDelay and RxDelay,

respectively, on a per sector-carrier basis. Additionally, the spare sector-carrier translation also

supports the increase in range of TxDelay from 62us to 400us. This increase in TxDelay range is

only for SBEVM. For DBEVM, it is still restricted to 62us even if the per sector-carrier

translation is set to a higher value. The units of Auxiliary Per-Sector-Carrier Control – 1 and

Auxiliary Per-Sector-Carrier Control – 2 are 0.1us. For example, if TxDelay of 139.5us is

required, then set Auxiliary Per-Sector-Carrier Control – 1 to 1395. If Auxiliary Per-Sector-

Carrier Control – 1 and Auxiliary Per-Sector-Carrier Control – 2 are set to 0, then they are not

used and the current per-sector translation parameters are used. EVM needs to be restored /

rebooted for changes in TxDelay/RxDelay parameters to take effect either at sector or sector-

carrier level. RNC R30 will have new permanent per-sector carrier translations for TxDelay and

RxDelay and will discontinue the use of these spare sector-carrier translation parameters for

TxDelay and RxDelay.

Open loop power adjustment (openloopadjust): The nominal power used by an AT for initial

transmission on the access channel. The value used by the AT is (–1) times the value of

openloopadjust. The recommended values of this parameter are shown in Table 2.

The value of this translation parameter was changed starting with R24 due to increasing number

of deployed access terminals based on MSM6500 chipset. Access terminals based on MSM5500

chipset use Probe Power that is 6 dB below the expected value. This was corrected for the




MSM6500 chipset mobiles. The pre-R24 value of this translation parameter accounted for this 6

dB shortfall.

The recommended value of this parameter is updated starting with R28.02. The updated value

can be used for previous releases. The new recommended value assumes that the majority of the

mobiles in the market are MSM6500 and beyond. If there are still a large number of MSM5500

mobiles in the market, then this parameter can be set 6dB lower (to correct for AT’s probe power

issue) for all band classes.

Table 1. Recommended values of TxDelay and RxDelay

Parameter Recommended Value

MCR � MCR A or MCR B

450 MHz

700 MHz

Cellular band

PCS band

Korea band IMT-2000

Tx_delay (Flexent Mod Cell) 27.7 us 27.7 us 19.9 us

Rx_delay (Flexent Micro/Mod Cell) 14 us 14 us 14 us

Tx_delay (Flexent Mod Cell, SBCBR) 27.7 us 27.7 us 20 us

Rx_delay (Flexent Micro/Mod Cell, SBCBR) 14 us 14 us 14 us

Tx_delay (Flexent OneBTS) 38 us 23.1 us 23.1 us

Rx_delay (Flexent OneBTS) 46 us 19.6 us 19.6 us

Tx_delay (Flexent OneBTS HD) 22.5 us 22.5us

Rx_delay (Flexent OneBTS HD) 19.6 us 19.6 us

Tx_delay (Flexent OneBTS HD MCR) 32.5 us 32.5 us

Rx_delay (Flexent OneBTS HD MCR) 19.6 us 19.6 us

Tx_delay (Flexent OneBTS Compact) 23.1us 23.1us

Rx_delay (Flexent OneBTS Compact) 19.6 us 19.6 us

Tx_delay (Flexent Korea OneBTS) 23.1 us

Rx_delay (Flexent Korea OneBTS) 19.6 us

Tx_delay (Flexent OneBTS MCR) 32.5 us 32.5 us

Rx_delay (Flexent OneBTS MCR) 19.6 us 19.6 us

Tx_delay (Flexent OneBTS Compact MCR) 32.5 us 32.5 us 32.5 us

Rx_delay (Flexent OneBTS Compact MCR) 19.6 us 19.6 us 19.6 us

Tx_delay BS2400 (OneBTS, MCR, SBEVM) 32.5 us 32.5us

Rx_delay BS2400 (OneBTS, MCR, SBEVM) 22.7 us 22.7 us

Tx_delay (OneBTS, UCR) 23.1 us

Rx_delay (OneBTS, UCR) 17.3us

Tx_delay BS4400, TTLNA (OneBTS, MCR) 32.5 us 32.5 us

Rx_delay BS4400, TTLNA (OneBTS, MCR) 19.6 us 19.6 us

Tx_delay BS4400, TTLNA (OneBTS, UCR) 32.5 us 32.5 us

Rx_delay BS4400, TTLNA (OneBTS, UCR) 19.6 us 19.6 us

Tx_delay (OneBTS, MCR, MCPA) 35 us

Rx_delay (OneBTS, MCR, MCPA) 22 us




Parameter

Recommended Value

450 MHz 700 MHz Cellular band PCS band Korea band 2 GHz

Open Loop Power Adjustment 80 dB 81 dB 81 dB 82 dB 81 dB 82 dB

Table 2. Recommended Values of Open Loop Power Adjustment

Initial probe power correction factor (probeinitialadjust): Correction factor to be used by an

AT for open loop transmit power estimation for initial transmission on the access channel. The

recommended value is 0 dB. The allowed values are -16 to 15 dB in steps of 1 dB.

Power increment step (powerstep): Power increment between two consecutive access probes

within one access probe sequence. The recommended value is 8 (4 dB). The allowed values are 0

to 15. The AT uses 0.5 dB times the value set in the database.

2.2 Access Search Window Size

The access search window size should be such that all possible users located in the covered areas

can access the system. Note that the upper limit on air delay is the sector size, and therefore the

translation, sectorsize, must be greater than the actual air delay at any point in the coverage area.

The optimal access search window width is

Access search window width (in PN chips) = 2 * sectorsize (in miles) * 6.6 (1)

The access search window width should ensure that all possible path delays in the coverage areas

are included in the path delay hypotheses tests. For convenience, Table 3 shows the conversion

formula between units. A velocity factor of 0.6 has been assumed for the cable.

Miles in air PN chips Microseconds Miles in cable

Miles in air 1 6.55 5.33 0.6663

PN chips 0.1527 1 0.814 0.1017

Microseconds 0.1876 1.2288 1 0.125

Miles in cable 1.5 9.83 8 1

Table 3. Conversion between different units

Note that there is an upper bound associated with the cell access search window. The maximal

cell access search window size is restricted by hardware. Therefore under any circumstances, the

following inequality for delay budget must be satisfied:

2 * sectorsize * 6.6 < 512 chips (2)




2.3 Access Channel Slot Setup

The access channel slot structure for CDMA 1xEV is similar to that of CDMA IS-95A/B/2000.

The access channel probe consists of two parts: access channel preamble and access channel

message capsule. The access channel structure is shown in Figure 1. The access channel cycle is

the basic time unit of all access channel activities. If the access channel cycle duration can be

minimized, then all access channel activities will speed up proportionally. This can result in

improvement on access delay (probe delay and sequence delay etc.). The sizes of access

preamble and message capsule are controlled by the following two translation parameters.

Access preamble length (preamblelength): The access channel preamble is a series of known

symbols transmitted in the beginning portion of each access channel probe to assist the base

station in detecting AT’s signal through the whole range of delay hypotheses tests.

The access preamble size depends on the access search window width in Equation (1) because

the purpose of this preamble is to allow the base station to detect an AT. Therefore, for each

access channel slot, the preamble must be greater than the time that the base station needs to do

all the hypotheses tests in the access search window. Table 4 shows the relationship between

access search window size and access preamble. For normal operation (sector size of 10 miles or

less), the recommended value of this parameter is 2 frames.

Access preamble length (frames) Access search window size (PN chips)

1 width < 158 PN chips

2 158 PN chips <= width < 391 PN chips

3 391 PN chips <= width

Table 4. Optimal Access Channel Preamble Length

Access capsule max length (capsulelengthmax): The maximum access message capsule length

that will be used for the access message. The capsule length should be large enough to contain at

least two access channel messages because, for any access channel message, the route update

message is always included.

Starting with R28.02 cell, recommendation of Access Capsule Max Length is changed from 2

frames to 4 frames for SBEVM to support Data-Over-Signaling. For existing Rev0 and RevA

mobiles, there shouldn’t be any impact since they will mostly use up to 2 frames. The

recommended value for DBEVM is 2 frames.

It is important to note that ALPHA sector values of Access Channel Parameters (Access

Preamble Length, Access Cycle Duration, and Access Capsule Max Length) dictate the values of

these parameters for BETA and GAMMA sectors. Ensure that these 3 parameters are set the

same across all 3 sectors of the cell. Even though this holds true only for DBEVM, these

parameters should be set the same across all 3 sectors for SBEVM unless needed to address

market specific circumstances.




2.4 Access Probe Power

During system access, closed-loop power control (feedback from the base station) is not possible

since the communication link is not yet set up. Open-loop estimation is used to determine the

power needed by the AT. A higher AT transmit power will allow easier access, but will create

interference to existing users. A lower transmit power will lengthen the duration of the access

process.

An access probe consists of preamble followed by message. During the preamble transmission,

only the pilot channel is transmitted. During the message transmission, both the pilot and the data

channel are transmitted. However, the total power transmitted by the AT during access preamble

transmission and access message transmission is same.

The initial access probe power IP of the AT is defined as

IP = - mean received power (dBm) + openloopadjust + probeinitialadjust, (3)

where openloopadjust and probeinitialadjust are defined in Section 2.1. The power of the

subsequent probe is powerstep dB higher than the previous probe within an access probe

sequence. The initial access probe power should be set high enough such that the first access

probe can be detected at the base station with high probability. On the other hand, usage of

excessive initial access probe power does not improve the access success rate significantly, but

instead creates more interference to the existing traffic users.

2.5 Access Delay Perceived by the End User

The net delay for a user to successfully access the system is governed by the required number of

access probes and sequences. The delay between access probes and between access sequences are

the primary contributing factors to the net delay perceived by the end user. The number of probes

and sequences needed for a successful access attempt is determined by the probe power, the

instantaneous reverse link power level at the base station, the number of simultaneous access

users (or indirectly the access arrival rate), and even the dynamics of pilot change (i.e., fast

shadow fading plus user mobility), etc.

The delay between probes and between sequences is basically a trade-off. A short delay between

probes and between sequences will in general yield shorter user-perceived delay and also will be

more immune to the dynamics of pilot change (i.e., less chance for change in the dominant pilot

between probes and sequences). On the other hand, if a sudden burst arrival of access occurs

(e.g., traffic events, sports events, disaster, etc.), this instantaneous increase in arrival rate will

create large interference to the whole system. Usage of a longer delay between probes and

between sequences will somewhat reduce the interference in such a situation. Since the chance of

this sudden burst arrival is rare compared to the chance of dynamics of pilot change, the idea is to

use shorter delay between access probes and access sequences.




3 1xEV Default Best-Effort Paging

Paging is the mechanism used to inform a dormant access terminal about access network’s

request for a connection when there is pending data. This section only covers the default best-

effort (DBE) paging strategy. In addition to DBE paging, there are several new paging strategies

supported with introduction of RNC Grouping, QoS Paging, and Distance based Paging. Paging

strategy with RNC Grouping enabled is discussed in translation application note #13. QoS

paging including Distance based paging is documented in translation application note #12.

The DBE paging uses synchronous control channel to transmit page messages. The access

network uses two distinct methods of DBE paging when it has pending data to transfer to a

dormant AT:

1) Normal DBE paging method which, conceptually, is very similar to the paging

method used in 3G1x HSPD network

2) Fast connect DBE paging method which is unique to 1xEV

Selection of a paging method depends on whether dormant AT is in suspended mode or slotted

mode when AN has data to transmit.

3.1 Slotted Mode Operation

The 1xEV idle state protocol supports periodic network monitoring by the access terminal. This

results in less processing at access terminal, which reduces power consumption thereby,

increasing battery life. In slotted mode operation, AT monitors only selected synchronous control

channel cycle (Sync CCC), which is transmitted every 426.67ms. The access terminal transitions

to monitor state from sleep state once every 5.12s (one Sync CCC out of every 12 Sync CCC).

Hence, the 1xEV sleep period duration is 5.12, which is defined by the standard and is not

configurable. The access terminal transitions to slotted mode from suspended mode after

expiration of suspend timer. In suspended mode, AT monitors Sync CCC continuously for a

period of time defined by suspend timer at the access terminal.

3.1.1 Paging Slot Determination for EVDO only Mode

The default best-effort paging mechanism in slotted mode requires access network know which

Sync CCC access terminal will transition from sleep state to monitor state. Both AN and AT

determine this Sync CCC using a hash function defined by 1xEV standard. Random Access

Terminal Identifier (RATI), also known as Session Seed, is used as an input to this hash function.

RATI is a 32-bit pseudo-random number which is communicated to the AN by the AT during

initial setup of 1xEV session.




3.1.2 Paging Slot Determination for Hybrid Mode

Hybrid AT in slotted mode is required to periodically monitor both 3G1x paging channel and

1xEV Sync CCC. Hybrid AT knows its 3G1x sleep cycle based on IMSI, maximum slot cycle

index value transmitted OTA, and its own programmed slot cycle value. Hybrid AT will always

negotiate its 1xEV sleep cycle using Preferred Control Channel Cycle (PCCC) attribute. The

access terminal proposes PCCC value such that it will not conflict with its 3G1x tune away.

3.2 Location of Dormant Access Terminal

In 1xEV, there is no centralized database such as HLR/VLR as in 3G1x to keep track of the

access terminal whereabouts. Knowledge at the 1xEV Radio Network Controller (RNC) of

dormant AT’s location will reduce the probability of RNC wide paging. The current

implementation uses two forms of registration to keep track of dormant AT’s location:

1) Subnet based registration

2) Distance based registration

3.2.1 Subnet based Registration

A subnet can be viewed as geographic coverage area spanned by a group of cells that use same

color code. Color code is associated with the subnet to which Unicast Access Terminal Identifier

(UATI) belongs. For example, all cells on a single RNC will have same color code. The subnet

area is restricted to coverage area spanned by cells on a single RNC and is not currently

configurable. The access terminal re-registers with access network (after crossing RNC

boundaries) when it notices change in color code. After AT registration, information including

Pilots reported in RouteUpdate message and new controlling RNC is stored at access network

and is used for future paging purpose. This process is also called Inter-RNC Idle/Dormant

Handoff.

The above original definition of subnet has changed with introduction of RNC Grouping feature.

With RNC Grouping enabled and subnet mask of 64, AT will not re-register even when it crosses

RNC boundaries within the RNC Group. Please refer to translation application note #13 for more

information.

3.2.2 Distance based Registration

A dormant access terminal re-registers with access network when it is at a distance greater than

the threshold RouteUpdateRadius field in the SectorParameters message from the last accessed

base station. Distance is computed using fields Latitude and Longitude of the SectorParameters

message from last accessed base station and the one AT is currently monitoring. It is important to

note that the distance (angular distance) computed is between two base stations and not between

the last accessed base station and the AT. After registration, information including pilots reported




in RouteUpdate message is stored at access network and is used for future paging purpose. This

form of registration can be used if a RNC coverage area is quite large. To enable distance based

registration, set the translation parameter Radius for Registration Update (angular distance) to

a non-zero value. The current recommendation is 0 (turn off distance based registration).

Additionally, the translation parameters Base Station Antenna Latitude and Base Station

Antenna Longitude need to be appropriately populated in the database.

Below is the information on how to populate Latitude and Longitude information in the database.

Starting with R28, Latitudes have values from -90 to 90 with -90 corresponding to 90-degree

South Latitude (South Pole), and 90 corresponding to 90-degree North Latitude (North Pole).

The equator is 0 degree Latitude.

Starting with R28, Longitudes have values from -180 to 180 with -180 corresponding to 180-

degree West Longitude and 180 corresponding to 180-degree East Longitude. The Prime

Meridian (Greenwich, England) is 0 degree Longitude.

For example, North Latitude of 40:43:28N would be entered as 40 degrees, 43 minutes, 2800

seconds. Please note that seconds are multiplied by 100 when entered in the EMS GUI. Hence,

for 28 seconds, enter 2800. For South Latitude of 65:45:36S, enter it as -65 for degrees, 45

minutes, 3600 seconds in the EMS GUI database.

For example, East Longitude of 74:24:58E would be entered as 74 degrees, 24 minutes, 5800

seconds. For West Longitude of 65:45:36W, enter it as -65 for degrees, 45 minutes, 3600 seconds

in the EMS GUI database.

The current recommendation is to enable distance based registration with RNC R28 SU2 and

beyond.

3.3 1xEV Default Best-Effort Paging Methods

There are two different types of DBE paging methods.

3.3.1 Normal DBE Paging Method

Normal paging method is invoked by access network when suspend timer at dormant access

terminal has expired and access terminal has entered slotted mode operation. This paging method

is implemented via a two-step process:

1) Access network sends page message on all sectors last accessed by access terminal. That

is, page the last known active set

2) If there is no response from the access terminal after executing step 1), page all cells

within the same RNC




Starting with R28, there are two translation parameters associated with normal paging method.

The translation parameter Number of Times to Page the Last Active Set (name change with

R28) governs the number of page attempts for step 1. The translation parameter Number of

Times to Page the Last Seen RNC (name change with R28) governs the number of page

attempts for step 2. The recommended values for both of these parameters are 2. With the above

recommendations, there are a total of 4 page attempts for each page request. The translation

parameter Paging Strategy is obsolete starting with R28.

Prior to RNC R28, RNC sends a page as soon as it receives data from the PDSN. RNC then starts

a repage timer. When the timer expires RNC sends another page attempt and restart the timer.

This process continues till all the page attempts are exhausted. Prior to R28, the repage timer was

hard coded to 5 seconds from the time RNC sends the message to the cell. For example, if the

AT doesn't wake up for next 4 seconds, RNC will only give AT 1s to respond to the page before

the repage timer expires. Starting with RNC R28, the repage timer implementation has changed.

The repage timer starts from the time the page message is sent over the air. In other words in R28

RNC estimates AT’s next wake up time and starts the repage timer accordingly. Additionally, the

repage timer is governed by the translation parameter Minimum Time to wait for a Page or

DoS response (also called Repage Timer under Profile ID). The recommended value for this

translation is 2s. This parameter governs the tradeoff between page success rate and page

response time. If it is set to a higher value (> 5), it will give AT more time to respond by

extending the paging cycle time. However, this will slow down the page response time. The new

repage timer mechanism may change the page attempt distribution (compared to pre-R28)

depending on the repage timer value.

Parameter Recommended value

Paging Strategy Obsolete Starting with R28

Number of Times to Page the Last Active Set 2

Number of Times to Page the Last Seen RNC 2

It is important to note that if the last known active set contained Pilots from different RNCs, only

cells under the RNC governing the AT session (UATI) will be paged when the second step is

executed. If all the page attempts fail, the data packets that generated the page request are

discarded. However, the R-P connection remains intact. If AN receives the page response from

AT (AN-Initiated Connection Request), but the call setup fails, AN will keep paging the mobile.

3.3.2 Fast Connect DBE Paging Method

This form of paging method is used by 1xEV access network to establish traffic channel with

access terminal using fewer signaling messages. It is invoked (as oppose to Normal Paging

method) when AN has data to send while the suspend timer is running at the access terminal.

When Dormancy timer expires, AT may include suspend timer in the ConnectionClose message.

If the AT included suspend timer in the ConnectionClose message then it is running in suspended

mode and is monitoring all Sync CCCs.




If the AN has data to send to a dormant AT while suspend timer is running, it will initiate fast

connect procedure using AT’s last known active set. Access network directly sends

TrafficChannelAssignment message thereby eliminating the need to exchange page and

ConnectionRequest messages. The suspend timer is set to 5s at AT. The access terminal cannot

move a significant distance within 5s (suspend timer) and hence, it is very unlikely that AT’s last

active set will change. There are no translation parameters associated with this paging method.

Mobiles based on MSM5500 chipset support non-zero suspend timer. Mobiles based on

MSM6500 and MSM6800 chipsets, in most cases, do not support non-zero suspend timer.

Hence, Fast Connect method is never invoked for these mobiles.

4 Dormancy State

In CDMA 1xEV packet switched data, when the traffic channel is idle during a data call for time

defined by a translation parameter, Dormancy Timer, the call enters a dormancy state. That is,

the physical channel is teared down. This would help reduce overall call blocking due to system

resources. When the user requests additional data transfer, the physical channel goes through the

routine setup procedure (without the end user knowledge). The end-to-end channel is still active,

that is, the mobile IP address is still the same. The recommended value of this parameter is 10

seconds.

5 Test Carrier Feature

The Test Carrier feature is introduced in 1xEV R23. This feature enables a 1xEV carrier access

to be restricted to a special class of mobiles. In 1xEV, there are up to four mobile classes.

Currently, all ATs are using the default class of '0'. The test mobiles can be programmed to use

any other class while the system is being integrated and optimized. With only test mobiles

allowed, the optimization process can be carried out in a well-controlled manner and service will

not be provided to the end-users prematurely.

The test carrier feature uses persistence parameter, APersistence field in the

AccessParameterMessage, to restrict 1xEV access. When test carrier feature is ON, the first

occurrence of APersistence field is set to 0x3F. It is set to 0x00 when the test carrier feature is

OFF. AT uses this persistence parameter to compute persistence probability P in the following

manner:

P = 2 ^ (-N/4), where N is the value of the APersistence field

= 0 if N = 0x3F

AT generates a random number X between 0 and 1. If X < P, the persistence test will be

considered successful and AT will be able to send the access probes. Otherwise, AT will not be

able to send access probes on 1xEV system. Hybrid ATs will access 3G1x system subsequently.

A non-test mode AT will be able to perform active mode handoff to a test carrier enabled sector.




Programming of the mobile (for test mode) can be done via Qualcomm CDMA Air Interface

Tester (CAIT) as well as Engineering Menu of the Connection Manager.

The test carrier feature is controlled via the translation parameter Test Carrier. The default value

of this parameter is No.

It is important to note that this feature only works when both RNC and Cell loads are at least

running R23 loads.

Starting with R26, RNC will block all handoffs to a test carrier enabled cell if the call originated

on a non-test carrier cell. If the call originated on a test carrier, access network will allow the

handoffs to a test carrier enabled cell. If a call originated on a test carrier cell, access network

knows that this is a test mobile and will allow handoffs in to a test carrier cell. Active handoffs

from test carrier cells to non-test carrier cells are allowed.

In a multi-carrier cell with test carrier enabled, there are two distinct channel lists: one list

includes channel information for all non-test carrier sector-carriers and the other list only

includes channel information for test carrier enabled sector-carriers. If non-test AT enters the

coverage of this cell either via acquiring 1xEV system (on a non-test carrier sector-carrier) or idle

handoff in to a non-test carrier sector-carrier, AT will be able to access 1xEV system on this cell

(AT will not hash to test carrier enabled sector-carrier since the channel information is not

included in the channel list). If a non-test AT is idling on a sector-carrier, which is later on

marked as test carrier, AT will try to access 1xEV on a non-test carrier sector-carrier if this

carrier channel info is provisioned in Preferred Roaming List (PRL). If a non-test carrier is not

provisioned in the PRL, AT will access 3G1x instead.

Starting with RNC R27 SU2 and Cell R27.01, there is an enhancement to the test carrier feature

implementation. This is to alleviate the rapid mobile battery drain issue when mobiles are trying

to acquire 1xEV system on a test carrier enabled cell. These mobiles try un-successfully to access

the EVDO test carrier because they are programmed to see the System ID (SID) that is being

transmitted over the air by the network. This SID is same for both the test-carrier and the

commercial carrier. These mobiles have a built-in algorithm, which wakes up once a minute and

attempt to access the network but fails. These continuous periodic attempts to access the network

in test carrier mode are causing these mobiles to lose its power rapidly. The workaround solution

is for the network to set the SID to 0 for test-carrier. When the SID is set to 0, the expected

behavior

of these handsets is that they do not acquire the EVDO carrier and will not attempt to access the

network frequently. A new flag (SID override) has been added to the Service Node configuration

database. If this flag is enabled, the network will send the SID as zero over the air only for the

sectors that are in test-carrier mode. (This enhancement is also supported for RNC R26 SU3 CFT

H and Cell R26.02).

IS-856 RevA standard defines APersistence index 2 for test mobile. Starting with R29, Alcatel-

Lucent has updated the test carrier implementation to confirm to this new standard change. With

this change, when test carrier feature is ON, the third occurrence of APersistence field is set to

0x3F. It is set to 0x00 when the test carrier feature is OFF. AT uses this Apersistence parameter




to compute persistence probability P, which is used for access. The test mobiles now need to be

programmed with access overload class to either 12 or 13 so that they can access the test carrier.

A mobile with access overload class set to 10 will not be able to access test carrier with the new

implementation. Access overload class (ACCOLC) is a 4-bit value which is translated to

APersistence index according to the following:

ACCOLC Apersistence index

------------ ------------------------

0 – 9 0

10, 11 1

12, 13 2

14, 15 3

It is important to note that system id (SID) change is accounted for test ATs via Preferred

Roaming List (PRL) if SID is set to 0 when test carrier feature is enabled.

6 PDSN Selection Algorithm

Lucent 1xEV system allows provisioning of multiple PDSNs at the RNC. Currently, RNC uses

either RATI based algorithm or IMSI based algorithm to select one of the PDSNs. For IMSI

based algorithm, RAN authentication needs to be enabled. If IMSI is available, 1xEV system will

select the same PDSN as underlying 3G1x system.

If RAN authentication is disabled, the MNID (Mobile Mode Identifier) is computed based on

RATI instead of IMSI. It is ensured that this number is unique from a valid IMSI. In this case, a

preferred PDSN can be selected for data transfer by repeatedly releasing AT’s UATI (essentially

forcing AT to setup new 1xEV session using RATI) till RNC selects desired PDSN.

If the RAN authentication is ON, MNID = IMSI. MNID is input to the standard defined PDSN

selection algorithm. If RAN is OFF, MNID = 999999 + last 9 digits of RATI. MNID is 15 digits

in decimal value. The standard defined PDSN selection algorithm is:

For initial PDSN assignment and for PDSN reselection, the PCF shall determine which

PDSN to use for a particular MS by the following:

PDSN No. = (truncated MNID) modulo N,

where (truncated MNID) is defined to be the least significant 4 digits of the MNID taken as a

decimal value. N is the number of PDSNs provisioned in the database.

7 Multiple Carriers: Hashing and Traffic Load Balancing

Starting with cell release R26.0, Lucent 1xEV system supports cells with multiple carriers.

Following sections discuss the basic concepts of hashing across carriers, traffic load balancing

between carriers, border carrier and related translation parameters.




7.1 1xEV Mobile Hashing

Mobile hashing distributes mobiles uniformly across multi-carriers. This helps balance

traffic load across carriers reducing the number of cross-carrier traffic channel assignments.

Additionally, it also helps balance Control Channel and Access Channel occupancy among

carriers which leads to better overall access performance.

When multiple carriers are present in a sector, the AT selects a channel to monitor based on the

hash algorithm defined in section 10.4 of IS-856. The inputs to hash algorithm are Random

Access Terminal Identifier (RATI) and number of channels listed in SectorParameters message.

Whenever the number of channels listed within the SectorParameters message changes, the idle

AT will re-execute the hash algorithm. As idle mobile moves around the network from sector to

sector, it may monitor different channels in each sector, depending on the number of carriers

available in each sector.

Call processing maintains two separate channel lists for each sector: non-test carrier channel list

and test carrier channel list. The non-test carrier channel list will not contain any test carriers, and

the test carrier channel list will not contain any non-test carriers. This is due to:

1) Once a test mobile is on a test carrier we want that test mobile to remain on a test carrier.

If the channel list for the test carrier contains non-test carriers, the mobile could hash to a

non-test carrier.

2) Non-test mobiles should be prevented from attempting to access the test carrier. By not

listing any of the test carriers in the channel list of a non-test carrier, we ensure that once

the mobile tunes to a non-test carrier it will not attempt to access a test carrier

7.2 Traffic Channel Selection Algorithm for Call Setup

The main purpose of this algorithm is to try to balance traffic load across multiple carriers. There

is a per sector translation parameter, Load Balancing Method, which has two allowable values,

Originating Carrier and Number of Active Users. This parameter allows service providers to

select a particular traffic channel selection algorithm. The traffic channel selection algorithms

based on Originating Carrier and Number of Active Users and are described below. Unlike

CDMA, there is no algorithm based on forward RF loading since in 1xEV forward link is always

transmitting at full power.

Traffic load balancing is not performed between test carriers and non-test carriers. If the

connection request is received on a test carrier then AT will only be assigned to a test carrier.

Similarly if the connection request is received on a non-test carrier then AT will only be assigned

to a non-test carrier.




7.3 Traffic Channel Selection Algorithm based on Originating Carrier

With this algorithm, a mobile will be assigned a carrier based on the origination carrier, i.e., if a

mobile originate on carrier F1, the call will be assigned carrier F1 for traffic. This is useful for a

multi-carrier system when each carrier may have different RF coverage footprint.

Call processing will select the originating carrier for traffic channel assignment if the number of

active users does not exceed the value of the translation parameter Maximum Number of Users

Supported for Rev0. Otherwise, if all the active users are carrying out data transfer, call

processing will select another (least loaded) carrier if possible. If another carrier couldn’t be

selected, and if there are active users that are idling (not carrying out data transfer and dormancy

timer hasn’t expired yet), then after Tforcerelease timer has expired, the longest idle user on the

originating carrier will be forced into dormancy and the new call will be assigned to the

originating carrier. If all fails, the connection request will be denied.

This traffic channel selection algorithm is only supported when all carriers are only Rev0

capable. This algorithm is applied to both session setup connection requests and user initiated

connection requests.

7.4 Traffic Channel Selection Algorithm based on Number of Active Users

This algorithm balances number of users across carriers based on the number of active users on

each carrier. The translation parameter, Load Differential, is used in the traffic channel selection

algorithm and the preference is given to the carrier that the AT originally accessed. For each

carrier in the sector, Call Processing computes the difference between the number of active users

on the originating sector carrier and the other carriers in that sector. If all of the differences are

less than the value of this translation parameter, AT is assigned resources on the originating

carrier. Otherwise, AT is assigned to another (least loaded) sector carrier. Starting with R28, the

recommended value of Load Differential is changed from 10 to 20 to minimize cross-carrier

assignments thereby reducing call setup failure rate due to RF mismatch between carriers.

If the number of active users on the originating sector carrier is less than the translation

parameter, Maximum Number of Users Supported Rev0/RevA, and the number of active users

on the originating sector carrier minus the Load Differential is less than the number of active

users on each of the other carriers in that sector, then the originating carrier is selected.

Otherwise, the call is assigned to the least loaded carrier. If another carrier couldn’t be selected,

and if there are active users that are idling (not carrying out data transfer and dormancy timer

hasn’t expired yet), then after Tforcerelease timer has expired, the longest idle user on the

originating carrier will be forced into dormancy and the new call will be assigned to the

originating carrier. If all fails, the connection request will be denied.

This traffic channel selection algorithm is supported for following configurations and scenarios:

1) All carriers are only Rev0 capable. This algorithm is applied to both session setup

connection requests and user initiated connection requests.




2) All carriers are RevA capable. If all the carriers are RevA capable, then this algorithm is

used regardless of the translation parameter, Load Balancing Method, setting. This

algorithm is applied to both session setup connection requests and user initiated

connection requests. This is only true when QoS is not enabled. When QoS is enabled,

traffic channel load balancing algorithm for RevA calls is based on reverse link RSSI

Rise. This algorithm is documented in translation application note #12.

3) A mix of Rev0 and RevA carriers. Prior to R28 SU1, the traffic channel selection

algorithm is implemented as follows: During session setup phase, the AT’s personality

(capability) is not known. Call processing uses both Number of Active Users and Load

Differential to assign connection request to either one of the carriers, Rev0 or RevA.

Once the session is configured, that is, AT’s personality is known, Rev0 calls are

assigned to the Rev0 carrier and RevA calls are assigned to the Rev A carrier, till the

maximum number of users limit is reached. In presence of current limited RevA mobile

population, this implementation leads to in-efficient use of RevA carrier capacity.

Additionally, this results in significant number of cross-carrier assignments. An idle

mobile will hash to one of carriers based on its RATI. A Rev0 mobile may hash to a

RevA carrier, and then will be assigned to the Rev0 carrier based on this implementation

during user initiated connection request. Cross-carrier assignments may lead to a high call

setup failure rate due to RF mismatch between the carriers.

Starting with R28 SU1, the load balancing algorithm in case of mix Rev0/RevA carriers

is enhanced to mitigate both in-efficient use of RevA carrier as well as possible high call

setup failure rate due to excessive cross carrier assignments. This load balancing

algorithm allows RevA carrier to carry Rev0 traffic. Pre-RNC R29, this is controlled via a

tunable parameter called Rel0RevAloadDifferential threshold. Starting with R29, this is

controlled via a new translation parameter called Rel0 RevA Loading Differential. Rev0

calls originating on a RevA carrier are assigned to the originating RevA carrier till the

number of active users on RevA carrier exceeds the number of active users on Rev0

carrier by this threshold. Once this threshold is exceeded, then the Rev0 calls originating

on RevA carrier will be cross-assigned to the Rev0 carrier. The current recommended

value for this parameter is 15. The valid range of this parameter is -59 to 59. The tunable

parameter can be updated via an OMP script. Refer to the R28 SU1 release letter on the

use of this script. Setting this field either higher or lower than this range will turn OFF

this enhancement and revert back to pre-R28 SU1 load balancing algorithm. The negative

value for this threshold implies carrier selection preference is given to Rev0 carrier for

Rev0 mobiles originating on RevA carrier. If this threshold is set higher than the

translation Maximum Number of Users Supported for RevA and the RevA carrier

reaches this maximum number of users limit, both Rev0 and RevA calls will be assigned

to Rev 0 carrier if possible (Rev0 carrier has resources). Otherwise, if there are active

users that are idling (not carrying out data transfer and dormancy timer hasn’t expired

yet), then after Tforcerelease timer has expired, the longest idle user on the RevA carrier

will be forced into dormancy and the new call will be assigned to the originating carrier.

If all fails, the connection request will be denied. The same holds true if Rev0 carrier

reached Maximum Number of Users Supported for Rev0 limit.

Alcatel-Lucent doesn’t recommend a mix of Rev0/RevA carrier configuration.




7.5 Border Carrier

A border sector carrier, also known as discontinuing carrier, is defined as a sector carrier where

the frequency of that carrier is no longer supported as AT moves away from that sector, but

where other 1xEV carriers are available. The border sector carrier designation should only be

used within the boundaries of 1xEV coverage area, embedded within a larger 1xEV coverage

area with different frequencies (continuing/common carriers), and not along the edge of the

1xEV coverage. The cells along the edge of the 1xEV coverage area, the area where 1xEV is no

longer supported as AT moves further from the cells, should not be marked as border sector

carriers. This is to fully utilize the air interface resources within those sectors as efficiently as

possible. Since there is no Inter-Frequency Handoff (IFHO) at the 1xEV coverage boundary,

there is no advantage in marking these sectors as border sector carriers.

The translation parameter, Border Carrier, designates whether a sector carrier is a border sector

carrier or not. Carriers that are marked as a border sector carrier are excluded from the channel

lists that are calculated, unless there are no other carriers available in that sector. By excluding

the border sector carrier from the channel list, it prevents access attempts on that carrier. Field

data shows that access attempts are more susceptible to failures on the border carrier. Also, calls

may be handed down to another carrier, via IFHO, immediately following call setup.

If a carrier is marked as border carrier, current implementation (up to R28 SU1) of traffic channel

load balancing algorithm doesn’t assign any calls to the border carrier until resources on all non-

border carriers are exhausted. That is, calls will not be assigned to border carrier till non-border

carrier reaches Maximum Number of Users Supported for Rev0/RevA limit. The traffic

channel load balancing algorithm is enhanced starting with R28 SU2 where calls are assigned to

border carrier based on tunable parameter hdrSNSpare6. The first N connections will be served

on the continuing carrier F1. The subsequent connections will be alternatively assigned between

border (F2) and non-border carrier (F1). The number N is defined by two parameters: Maximum

number of Users Supported for Rev A and tunable parameter hdrSNSpare6.

N = (Maximum number of Users Supported for Rev A) * (hdrSNSpare6 / 100)

Based on the above, the tunable parameter essentially defines percentage of maximum allowed

users active on non-border carrier after which the border and non-border carriers will start

sharing equal traffic. The recommended value for this parameter is 20. This parameter can be

updated via OMP script named borderNonBorderRatioSetup. The script should work for R28,

R29 and R30. There will be a translation parameter in R31 that will control this algorithm.




Important Notes:

1) When multiple carriers are RevA enabled but QoS is not supported, traffic load balancing

for both Rev0 and RevA calls is based on Number of Active Users. However, when QoS

is enabled on both carriers, then Rev0 calls use traffic load balancing based on Number of

Active Users. RevA calls, either Best-Effort (Default Flow Packet Application or Multi-

Flow Packet Application) or QoS (ReservationOnRequest bundled with RouteUpdate and

ConnectionRequest messages) will use traffic load balancing based on RSSI Rise. This

load balancing algorithm is described in translation application note #12. Currently, the

RSSI Rise based traffic load balancing algorithm is not working due to software issue.

This implies that if QoS is enabled either in R28 or R29, RevA calls may not be balanced

between carriers. RevA calls are assigned only to the Originating carrier. The software

issue will be addressed in R29 RNC SU2 CFT C and beyond.

2) When multiple carriers are RevA QoS enabled, traffic channel load balancing algorithm

between Border and Non-Border carriers is not working for QoS (ReservationOnRequest

bundled with RouteUpdate and ConnectionRequest messages) calls. That is, QoS calls

will be assigned only to the continuing Non-Border carrier. This will be addressed in a

future release.

Table 5 summarizes both hashing and traffic channel load balancing algorithms for different

configurations and scenarios.

8 Session Close: Critical System Edge Metric Preservation Feature

Session Close feature, also known as Critical System Edge Metric Preservation feature, allows

service providers an option to deny Session Setup requests from mobiles in poor RF / non-

designated 1xEV coverage areas. Mobiles are very persistent in trying to establish 1xEV session

since that’s what they are designed for. Many ATs are autonomously attempting to start up new

sessions in extremely poor RF conditions outside of the nominal service area. These attempts use

up Reverse Link resources often taking them away from other ATs that have a better chance of

establishing a data connection. Battery life of these ATs is also most often needlessly diminished.

These persistent session setup requests also impacts 3G1x termination performance of these

hybrid mobiles since these ATs do not tune to 3G1x while trying to establish 1xEV session. The

number of such session setup requests is sufficient to skew Service Measurements so that they no

longer provide an accurate account of the service in the valid coverage area.

This feature provides operators with the choice to deny session setup attempts that are in poor RF

conditions and too far away from serving sector (those having a negligible chance of successfully

establishing a data connection). It only impacts ATs that are undergoing session setup in poor RF

conditions at the edge of the service area. Users, with valid 1xEV session, are not impacted.

When the network denies several successive 3 to 4 session setup attempts, hybrid AT avoids

monitoring 1xEV system for a period of about11 minutes. It monitors only 3G1x during this

time. In case of multiple 1xEVcarriers, AT will avoid the carrier it acquired 1xEV and not the

hashed carrier where it received SessionClose message. After all 1xEV carriers are avoided, AT

will monitor 3G1x for about 11 minutes.




There are three parameters associated with this feature. The names of these translation

parameters were changed starting with R27. Setting the translation parameter, RF-Border

Session Setup Deny ( pre-R27 RF-Border Session Setup Connection Deny) to Deny

Connections in Poor Conditions (recommended value), will activate the feature. The RF and

Distance thresholds, used by the feature, are defined by the translation parameters, Signal

Strength Threshold for Session Setup Request Denial (pre-R27 Minimum Initial Signal

Strength Threshold) and Minimum Distance Threshold for Session Setup Request Denial

(pre-R27 Minimum Distance Threshold for Initial Connection Denial), respectively. The

recommended values of these parameters are –9 dB and 2.5 miles, respectively.

Scenario Idle mode hashing (Default Idle State Protocol)

Traffic Channel Load Balancing Algorithm

F1, F2 are Non-Border carriers

F1 is Non-Border

carrier, F2 is Border

carrier

Session Setup Connection Setup

Two Rev 0 carriers

Based on RATI

Always to the Non-Border carrier (F1)

Originating Carrier or Number of Active Users

Two Rev A carriers QoS disabled

Number of Active Users

Two RevA carriers QoS enabled


Rev0 – Number of Active Users RevA – RSSI Rise (described in translation application note # 12)

Mixed Rev0/RevA carriers


Pre R28 SU1

Rev0 AT assigned to Rev0 carrier, RevA AT assigned to RevA carrier,

R28 SU1

RevA carrier allowed to carry Rev0 traffic via tunable parameter (R28) Rel0RevAloadDifferential and translation parameter (R29) Rel0 RevA Loading Differential RevA calls assigned to RevA carrier

Table 5. Summary of Hashing and Traffic Channel Load Balancing Algorithms




9 Summary of Translation Parameters

EMS Field Label EMS GUI Page Recommended Values

Note

Sector Size Sectors - General / Service Node - General section 2

10 miles

Access Cycle Duration**,***

Sectors - Access Control / Service Node - General section 2

16 slots

Access Capsule Max Length**, ***

Sectors - Configuration / Service Node - General section 2

4 frames

Access Preamble Length**


2 frames

Access Channel Probe Backoff


4 Units of Access Cycle Duration

Access Channel Probe Sequence Backoff


8 Units of Access Cycle Duration

Number of Access Probes


5

Maximum Number for an Access Probe Sequence


2

Open Loop Power Adjustment*


82 dB (PCS) Max Tx Pwr per Carrier PCS – 16W Cellular – 20W Korea – 20W 450 MHz – 26W 700 MHz – 20W 2 GHz – 16W

81 dB (Cellular)

81 dB (Korea)

80 dB (450 MHz)

81 dB (700 MHz)

82 dB (2 GHz)

Initial Probe Power Correction Factor


0 dB

Power Increment Step Sectors - Configuration / Service Node - General section 2

8 (4 dB)

Transmit Antenna Propagation Delay****

Sectors – General 19.9 us (pcs) MCR � MCR-A or MCR-B 27.7 us (cellular)

27.7 us (450 MHz)

23.1 us (pcs, OneBTS)

32.5us (pcs, OneBTS, MCR)

23.1 us (cellular, OneBTS)

32.5us (cellular, OneBTS, MCR)

23.1 us (Korea, OneBTS)




22.5 us (cellular, OneBTS HD)

22.5 us (pcs, OneBTS HD)

23.1 us (pcs, OneBTS Compact)

32.5us (pcs, MCR, OneBTS Compact)

23.1us (cellular, OneBTS Compact)

32.5us (cellular, MCR OneBTS Compact)

32.5us (cellular, MCR, OneBTS, HD)

32.5us (IMT-2000, MCR, OneBTS

Compact)

32.5us (pcs, MCR, OneBTS, HD)

38us (450 MHz, OneBTS)

20us (pcs, SBCBR)

27.7us (cellular, 450, SBCBR)

32.5us BS2400 (MCR, SBEVM, pcs,

cellular)

23.1us 700MHz (OneBTS, UCR)

35.0us (OneBTS, MCPA, MCR,

cellular)

32.5us BS4400, TTLNA (OneBTS,

MCR, pcs, cellular)

23.1us BS4400, TTLNA (OneBTS,

UCR, pcs, cellular)

Receive Antenna Propagation Delay****

Sectors - General 14us (Legacy Modcell),

19.6 us (OneBTS), 46us (OneBTS, 450

MHz) 22.7us BS2400

(MCR, SBEVM, pcs, cellular)

17.3us 700MHz (OneBTS, UCR)

22.0us (OneBTS, MCPA, MCR,

cellular)

RxDelay is used starting with RNC/Cell R24. MCR � MCR-A or MCR-B




Dormancy Timer Sectors - General / Service Node - General section 2

10s

Paging Strategy Service Node – Paging Parameters

1 Starting with R28, this parameter is not used. To disable RNC wide paging, set Number of Times to Page the Last seen RNC to 0.

Number of Times to Page the Last Active set

Service Node – Paging Parameters

2 Parameter name change in R28

Number of Times to Page the Last seen RNC


2 Parameter name change in R28

Minimum Time to wait for a Page or DoS response (in steps of 0.1 seconds)


2.0s

Load Balancing Method Sectors – Configuration / Service Node - General section 3


Only method of choice for Traffic Load Balancing across Multiple Carriers when both carriers are RevA capable.

Load Differential Sectors – Configuration / Service Node - General section 3

20 New in R26. Applies only when Number of Active Users based Load Balancing algorithm is used

Rel0 RevA Loading Differential

Service Node II-QoS/Sector Carrier – General

15 Used for traffic load balancing between Rev0 and RevA carriers. New in R29.

Border Carrier Sector Carriers - General

N/A

Default value is No. Set it to Yes if it is a Border Carrier. 1, 2, 3, are different carriers

Radius for Registration Update

Service Node - General section 1

N/A

Needed for Distance based Paging. 0 means distance based registration is OFF. Recommendation is to enable Distance based Registration.

Base Station Antenna Latitude

Sectors - Base Station Antenna Latitude N/A

Base Station Antenna Longitude

Sectors - Base Station Antenna Longitude N/A

Test Carrier***** Sector Carriers - General / Service Node - General section 1

No

Yes, No. Default value is No. Set it to Yes if there is a need to block non-test mobiles from accessing the network.




RF-Border Session Setup Deny

Sectors – Access Control / Service Node – Pilot Values Deny Connections in

Poor Conditions

Session Close Implementation. Parameter name change in R27.0.

Signal Strength Threshold for Session Setup Request Denial

Sectors – Pilot Values / Service Node – Pilot Values 18 (-9.0 dB)

Parameter name change in R27.0.

Minimum Distance Threshold for Session Setup Request Denial

Sectors – Pilot Values / Service Node – Pilot Values 2.5 miles

Parameter name change in R27.0.

* - The recommended value of this parameter is updated starting with R28.02. The updated value

can be used for previous releases. The new recommended value assumes that the majority of the

mobiles in the market are MSM6500 and beyond. If there are still a large number of MSM5500

mobiles in the market, then this parameter can be set 6dB lower for all band classes.

** - Need to set these 3 parameters the same across all 3 sectors. Refer to Lucent Alert 05-0518.

Even though this holds true only for DBEVM, these parameters should be set the same across all

3 sectors for SBEVM unless needed to address market specific circumstances.

*** - Recommendation of Access Capsule Max Length is changed from 2 frames to 4 frames

starting with R28.02 to support Data-Over-Signaling. For existing Rev0 and RevA mobiles, there

shouldn’t be any impact since they will mostly use up to 2 frames. Recommendation of Access

Cycle Duration is changed from 64 slots to 16 slots to reduce call setup latency for Push-to-Talk

(PTT) service and also to increase access channel capacity. These settings are supported for

SBEVM only. DBEVM will still use the default settings of 2 frames and 64 slots, respectively

even with these settings enabled in the database.

**** - Prior to RNC R29 SU1, translation parameters Transmit Antenna Propagation Delay

(TxDelay) and Receive Antenna Propagation Delay (RxDelay) parameters were per sector. Also,

the range of TxDelay was restricted to 62us. RxDelay supported range up to 400us. RNC R29

SU1 uses spare sector-carrier translation parameters, Auxiliary Per-Sector-Carrier Control – 1

and Auxiliary Per-Sector-Carrier Control – 2, to allow provisioning of TxDelay and RxDelay,

respectively, on a per sector-carrier basis. Additionally, the spare sector-carrier translation also

supports the increase in range of TxDelay from 62us to 400us. This increase in TxDelay range is

only for SBEVM. For DBEVM, it is still restricted to 62us even if the per sector-carrier

translation is set to a higher value. The units of Auxiliary Per-Sector-Carrier Control – 1 and

Auxiliary Per-Sector-Carrier Control – 2 are 0.1us. For example, if TxDelay of 139.5us is

required, then set Auxiliary Per-Sector-Carrier Control – 1 to 1395. If Auxiliary Per-Sector-

Carrier Control – 1 and Auxiliary Per-Sector-Carrier Control – 2 are set to 0, then they are not

used and the current per-sector translation parameters are used. EVM needs to be restored /

rebooted for changes in TxDelay/RxDelay parameters to take effect either at sector or sector-

carrier level. RNC R30 will have new permanent per-sector carrier translations for TxDelay and

RxDelay and will discontinue the use of these spare sector-carrier translation parameters for

TxDelay and RxDelay.




***** - IS-856 RevA standard defines APersistence index 2 for test mobile. Starting with R29,

Alcatel-Lucent has updated the test carrier implementation to confirm to this new standard

change. With this change, when test carrier feature is ON, the third occurrence of APersistence

field is set to 0x3F. It is set to 0x00 when the test carrier feature is OFF. AT uses this

Apersistence parameter to compute persistence probability P, which is used for access. The test

mobiles now need to be programmed with access overload class to either 12 or 13 so that they

can access the test carrier. A mobile with access overload class set to 10 will not be able to

access test carrier with the new implementation. Access overload class (ACCOLC) is a 4-bit

value which is translated to APersistence index according to the following:

ACCOLC Apersistence index

------------ ------------------------

0 – 9 0

10, 11 1

12, 13 2

14, 15 3

It is important to note that system id (SID) change is accounted for test ATs via Preferred

Roaming List (PRL) if SID is set to 0 when test carrier feature is enabled.

tan29.00_timing, delay and access parameters

Documents

updated document

xev cell release

test carrier updated

xev translation parameters

xev system

open loop adjustment

access parameters version

access preamble length