IS-41 CDMA to CDMA Inter-Vendor Hard Handoff Application

Issues 0.7 Date: 02 May, 2002 Core RF Engineering

2001 Northern Telecom Ltd. All rights reserved. Information subject to change without notice.
The information disclosed herein is proprietary to Northern Telecom or others and is not to be used by or disclosed to unauthorized persons without the written consent of Northern Telecom. The recipient of this document shall respect the security status of the information.

Table of Contents
1.0 INTRODUCTION ....................................................................................................................... 5 2.0 IS-41 CDMA TO CDMA INTERSYSTEM/INTER-VENDOR HARD HANDOFF DESCRIPTION ......................................................................................................................................................... 5 2.1 Messages Embedded in The FacilityDirective2 IS-41 C Message Protocol................................. 7

3.0 HARD HANDOFF TRIGGER MECHANISMS FOR IS-41 C .................................................... 9 3.1 Pilot Beacon Hard Handoff Trigger Mechanism........................................................................... 9 3.1.1 Datafill Tips for Pilot Beacon Hard Handoff ........................................................................... 10 3.2 Round Trip Delay (RTD) Hard Handoff Trigger Mechanism................................................... 12 3.2.1 RTD Threshold Calculation for Datafill................................................................................... 13 3.2.2 RTD Trigger Delay Due To Pilot Pollution ............................................................................. 13 3.2.3 Datafill Tips for Hard Handoff using RTD Trigger under Pilot Pollution ............................... 14 3.3 Summary of Multi Pilot Hard Handoff Target Cell Selection ................................................... 14 3.3.1 The Reference Sector of RTD Trigger and Its First Target Sector........................................... 14 3.3.2 The Reference Sector of Pilot Beacon Trigger and Its First Target Sector .............................. 15 3.3.3 The MPHHO Target Selection Algorithm................................................................................ 16 3.3.3.1 Example of Target Selection ................................................................................................ 16 3.4 EHHO (RF Link Quality) Trigger Mechanisms.......................................................................... 17

3.5 Pros and Cons of the Hard Handoff Triggers for Inter-vendor Hard Handoff with Same Carrier Frequency and Non Co-located Cell Configuration.................................................................. 20 3.5.1 Pilot Beacon Hard Handoff Trigger for Inter-vendor Hard Handoff with Same Carrier Frequency and with Non Co-located Cell Configuration......................................................................... 20 3.5.2 RTD Hard Handoff Trigger for Inter-vendor Hard Handoff with Same Carrier Frequency and with Non Co-located Cell Configuration ................................................................................................. 22 3.5.3 Recommendations for Optimizing RTD Hard Handoff between Non Co-located Cells with intra-frequency/inter-frequency................................................................................................................ 22 3.6 Enhanced Hard Handoff (EHHO) Trigger for Inter-vendor Hard Handoff with Intrafrequency/Inter-frequency and with Non Co-located Cell Configuration ............................................ 24 3.6.1 Recommendations For Optimizing Enhanced Hard Handoff (EHHO) between Non Co-located Cells with Same Carrier Frequency.......................................................................................................... 25 4.0 A-OPEN INTERFACE (IOS2.2) CDMA TO CDMA INTERSYSTEM HARD HANDOFF ....... 28 4.1 4.2 4.3 4.4 Brief Description of Nortel Networks Open A-interface Product............................................. 28 Hard Handoff functionality supported on Nortel Networks MTX and BSC............................ 30 Hard Handoff Functionality Supported on Nortel Networks MTX and other BSC ................ 30 Hard handoff Deployment Planning and Datafill ....................................................................... 30

5.0 IS-41 CDMA TO CDMA HARD HANDOFF FOR 3G VOICE AND 2G VOICE SERVICE REDIRECTION .............................................................................................................................. 31 5.1 Calls with RateSet1-EVRC on Other Vendor System Hard Handoff to Nortel System supporting RateSet2-13 Kbps and RateSet1-EVRC ............................................................................... 31 5.1.1 Hard handoff Deployment Planning and Datafill..................................................................... 32 5.2 Calls with 3G Voice CDMA to CDMA Hard Handoff................................................................ 33 5.2.1 Hard handoff Deployment Planning and Datafill..................................................................... 33 6.0 HOW TO SET THE HARD HANDOFF TRIGGER AT OPTIMUM LOCATION (POINT) ....... 33 6.1 Overlap Coverage Requirement at Hard Handoff Region for Intersystem/Inter-vendor Hard Handoff........................................................................................................................................................ 35 7.0 NEIGHBOR LIST CONSIDERATIONS................................................................................... 35 7.1 Neighbor List Considerations for Pilot Beacon Trigger ............................................................. 36 7.1.1 PDB Neighbor List ................................................................................................................... 36 7.1.2 BTS Neighbor List ................................................................................................................... 37 7.2 Neighbor List Considerations for RTD Trigger .......................................................................... 39 7.2.1 PDB Neighbor List ................................................................................................................... 39 7.2.2 BTS Neighbor List ................................................................................................................... 41 8.0 HARD HANDOFF OM............................................................................................................. 43 8.1 8.2 Hard Handoff Measurement per OMMTXH02 OM Group ...................................................... 43 Hard Handoff Measurement per CAUCPSCT OM Group........................................................ 44

9.0 IS-41 CDMA TO CDMA INTER-VENDOR HARD HANDOFF DATAFILL............................. 45 9.1 Table SYSCON ............................................................................................................................... 45 9.1.1 Datafilling MSGFMT Field of Table SYSCON....................................................................... 46 9.1.2 Datafilling IHODATA Field of Table SYSCON ..................................................................... 46 9.1.3 Datafill Sample of Table SYSCON of Nortel Networks Switch.............................................. 47 9.2 9.3 Table MSCIDRTE.......................................................................................................................... 48 Table CDMAIMAP ........................................................................................................................ 49

10.0 PROCEDURES TO DATAFILL PDB INTERSYSTEMCELLID AND TABLE CDMAIMAP. 50 10.1 10.2 Procedures to Datafill Nortel CDMA IntersystemCellId field in PilotDatabase ...................... 50 Procedures to Datafill NWKCELL of Table CDMAIMAP.................................................... 53

10.3 What Bit-format Structure For MTX CellId Datafilled in The Other Non-Nortel MSC........ 53 10.3.1 Procedures to Convert Nortel Cell Number that Mapped to Nortel MTX CellId for MTX09 to Be Datafilled in Non-Nortel MSC............................................................................................................ 54 10.3.1.1 Conversion using Manual Method ................................................................................... 55

10.3.1.2 Conversion using MTX CONVCELL tool ................................................................... 56 10.3.2 Restriction and limitations........................................................................................................ 57 11.0 HARD HANDOFF TROUBLESHOOTING TIPS................................................................... 58 11.1 Hard Handoff Trigger but Mobile Not Received Hard Handoff Direction Message ............... 58 11.1.1 Sample of CATRLM_RLMIntersystemHandoffInd NOIS Message ...................................... 60 11.1.2 Sample of ExtendedHandoffDirection message ....................................................................... 61 11.2 11.3 Hard Handoff Delay....................................................................................................................... 61 Hard Handoff Drop due to Search_Win_A Too Narrow ........................................................... 62

12.0 GLOSSARY .......................................................................................................................... 64

1.0 Introduction
This document looks into the entire hard handoff trigger mechanisms supported by Nortel Networks that apply for IS41 CDMA to CDMA inter-vendor hard handoff. The document looks into which hard handoff trigger mechanisms are best suited for the application of IS41 CDMA to CDMA inter-vendor hard handoff with same carrier between source and target system with non co-located cell configuration. The document also provides the readers some hard handoff deployment/application tips, datafill requirements, optimization, and troubleshooting from the RF perspective and also from basic networking perspective. This document addresses only the IS41 CDMA to CDMA hard handoff from Nortel to the other vendor but not vice versa.

2.0 IS-41 CDMA to CDMA Intersystem/Inter-vendor Hard Handoff Description

Prior to MTX 8.0 load, the MTX only supported the following hard handoff scenarios: -CDMA to AMPS (IS-41-A, B and P) -CDMA to CDMA (IS-41-P) IS-41 A and IS-41 B are the protocols that Nortel Networks supports CDMA to AMPS intersystem hard handoff to other vendor. IS-41 P is the Nortel proprietary protocol that Nortel Networks supports CDMA to CDMA Intersystem Hard Handoff or CDMA to AMPS Intersystem Hard Handoff but both MSCs must be Nortel MTX. IS-41 C is implemented in MTX8.0 load, for allowing CDMA to CDMA intersystem hard handoff to another vendor who employs IS-41 C. The CDMA to CDMA Intersystem Hard Handoff feature in MTX08 provides support of the receipt and sending of the CDMA parameters in the messages that are needed to provide intersystem hard handoff between vendors supporting the IS-41 Rev. C protocol. The IS-41 C feature also supports CDMA to AMPS Intersystem Hard Handoff to other Vendor who employs IS-41 C. Since CDMA-CDMA Intersystem Hard Handoff is supported on IS-41-P between MTXs, the software that handles the sending and receipt of the FACDIR and HANDBACK messages already exists. Adding the CDMA/IS-41-C specific parameters is all that is necessary to convert the FACDIR to a FACDIR2 and the HANDBACK to a HANDBACK2, the sending of the message then merges into existing software execution. Since IS-41-P message is superset of IS-41-C message, all the changes and enhancements of IS-41-C FacilitiesDirective2 and HandoffBack2 message also apply to IS-41-P. The reason the FacilityDirective2 and the HandoffBack2 are added to the IS-41 in revision C is to support all air interface standards, including CDMA and narrowband
5

AMPS mobiles; the FacilityDirective and the HandoffBack support only TDMA and AMPS mobiles, but not CDMA or NAMPS mobiles.

network link A signalling network link to switch B in SYSCON defined as IS-41C B

DMS-MTX

non-NORTEL switch

Figure 2.1: IS-41 Link between Nortel MTX and other vendor MSC

Serving System

Target System
InterMSCCircuit

MSC

MSC

FACDIR2 Invoke Message[RequestedServiceInfo, RequestedTargetInfo]

facdir2 Return Message[GrantedServiceInfo, GrantedTargetInfo]

MSONCH[ ]

Figure 2.2: IS-41 C Messaging Flows between two MSCs for Intersystem/Inter-vendor Hard Handoff

2.1 Messages Embedded in The FacilityDirective2 IS-41 C Message Protocol This section describes the primary messages embedded in the FacilityDairective2 IS-41 C message protocol for the Intersystem/Inter-vendor hard handoff case. More details can be found in the IS-41 C standard (TIA/EIA 41.2 C). a. The Serving MSC determines that a call should be handed off to a target system. It sends a FACDIR2 to the Target MSC, directing the Target MSC to initiate a Handoff-Forward task. IS-41-C FacDir2/HandBack2 Invoke Message Parameters Invoke Message Parameter Fields Usage RequestedServiceInfo Set of parameters for Requested Service Information [CDMACallMode] Indicates the acceptable mode of the current call = {AMPS | NAMPS | CDMA}. [CDMAChannelData] Indicates the CDMA Channel Number field, the Frame Offset field and a Long Code Mask field of the serving channel. Three new fields - nominal power, nominal power extension and number preamble are added to the existing parameter. These 3 new fields are hard-coded value. 0 is assigned to nominal power and number preamble, false is assigned to nominal power extension since IS-41 C indicates that these values are not mandated to be provided from Target system. Therefore Nortel uses the Nortel default values. The values are sent on the ExtendedHandoffDirection message. [CDMAStationClass-Mark] Identifies certain characteristics of a dual-mode CDMA MS. [CDMAStationClassMark2] [CDMAMobile-ProtocolRevision] [CDMAPrivateLong-CodeMask] A new parameter replaces the existing CDMAStationClassMark. Contains the Wideband Mobile Protocol Revision number of the MS, if available. Contains the 42-bit CDMA private long code mask. Included if available, if the MS supports CDMA, and if the MS is authorized for voice privacy. Estimated one-way delay from the MS to the serving cell site. Included if available. Provides the estimated location (latitude, longitude) of the MS with corresponding Multiple band handoff is not supported by this
7

[CDMAServingOneWay-Delay]
[MSLocation]

[CDMABandClassList]

feature. [BillingID] [ElectronicSerialNumber] [InterMSCCircuitID] [MobileIdentificationNumber] [ServingCellID] RequestedTargetInfo

Support Support Support Support Support

TargetCellID

Set of parameters for Requested Target Information. Only one of the following may Be used: CDMATargetMAHOList, CDMATargetMeasurementList or TargetCellID. Include the parameter only when an AMPS or TDMA channel is used

b. Uses the new BillingID for the new call segment. It then returns a facdir2 to the requesting MSC, and initiates a Handoff-Forward task. IS-41-C facdir2/handback2 Return Message Parameters Return Message Parameter Fields Usage Set of parameters for Granted Service GrantedServiceInfo: Information. [CDMACodeChannel-List] Identifies the code channels in a Forward [CDMASearchWindow] CDMA Channel used for the call. Included if target channel is CDMA. Specifies the number of PN chips that a CDMA MS should use to search for usable multipath components of the pilots in the Active Set and the Candidate Set and also specifies T_ADD, T_DROP, T_COMP, T_TDROP. The values are sent on the ExtendedHandoffDirection message. Set of parameters for Target Service Information. Indicates the CDMA Channel Number field, the Frame Offset field and a Long Code Mask field of the serving channel. Three new fields - nominal power, nominal power extension and number preamble are added to the existing parameter. These 3 new fields are hard-coded value. 0 is assigned to nominal power and number preamble, false is assigned to nominal power extension since IS-41 C indicates that these values are not

GrantedTargetInfo: [CDMAChannelData]

TargetCellID

mandated to be provided from Target system. Therefore Nortel uses the Nortel default values. The values are sent on the ExtendedHandoffDirection message. Include the parameter only when an AMPS or TDMA channel is used

c. After having initiated the Handoff-Forward task, if the MS is received on the designated voice channel, the Target MSC completes the voice path between the voice channel and the inter-MSC trunk and then sends a MSONCH to the initiator of the Handoff-Forward task (the Serving MSC in this scenario).

3.0 Hard Handoff Trigger Mechanisms for IS-41 C

IS-41 C is an Interim Standard 41-network protocol to establish network communications between a DMS-MTX switch and a switch of another vendor. The two different vendors communicate to each other through data links and network circuits when a mobile unit moves across the boundaries of the overlapping RF coverage of the two systems. The data link handles all the handoff messaging required to transfer the mobile while the network circuits handle the voice transmission. Therefore, the three existing hard handoff-triggering mechanisms are still applicable for the inter-vendor hard handoff. The triggering mechanisms are as follows: 1. Pilot Beacon Hard Handoff 2. Round Trip Delay Hard Handoff 3. Enhanced Hard Handoff (Hard Handoff based on FER) The followings are a summary of the three existing hard handoff trigger mechanisms. 3.1 Pilot Beacon Hard Handoff Trigger Mechanism Pilot Beacon hard handoff trigger is based on the Ec/Io of the pilot PN of a sector detailed with CellType = CELL_PILOT_BEACON in the PilotDatase. When the mobile detects the Ec/Io of the pilot PN of the beacon sector > T_ADD, the mobile sends Pilot Strength Measurement message to the SBS via the BTS and then the trigger is activated. The system will then instruct the mobile to hard handoff to the target cell (sector) that is defined in the BeaconTargetCellIdList of the source PilotDataBase on the SBS. The target CDMA cell of the target MSC can be used as a pilot beacon if the hard handoff is performed to the same frequency carrier (inter-frequency) and this target CDMA cell can also serve traffics. A Pilot Beacon Unit (hardware unit) is required to be employed and to be collocated with the target CDMA cell of the target MSC if the intervendor hard handoff is performed to different frequency carrier.

Note: The mobile has no knowledge of the beacon cell concept. It sees the beacon cell is just a normal CDMA cell. A pilot beacon is just a cell/sector defined in the PilotBase for an ExtendedBasedID with the CellType = CELL_PILOT_BEACON. Thus any CDMA cell or a cell equipped with a Pilot Beacon Unit uses as pilot assisting in handoff can be designated as a pilot beacon cell type in the source PilotDataBase. When Pilot Beacon assisted Hard Handoff in NBSS 7.xx load deployed concurrently with Multi Pilot Hard Handoff, a call can perform hard handoff to multiple cells (up to 6 cells). Pilot Hard Handoff feature is introduced in NBSS 7.xx load. More details on this Multi feature can be found in [6]. In order to implement the multi target selection (MPHHO) for the sector implemented the Beacon hard handoff trigger, the MultiPilotHHOEnabled field in the PilotRecord entry of the PilotDataBase must be set to TRUE. Note: Multi Pilot Hard Handoff only support hard handoff between Nortel to Nortel but not support hard handoff between Nortel and other vendor since Multi Pilot Hard Handoff is Nortel Networks feature. More information on Multi Pilot Hard Hardoff target selection can be found in section Figure 3.3 3.1.1 Datafill Tips for Pilot Beacon Hard Handoff This section provides datafill tips for Pilot Beacon Hard Handoff. Figure 3.1 depicts IS41 C CDMA to CDMA inter-vendor Hard Handoff using Pilot Beacon Assisted Handoff mechanism. The following scenario is used as example for datafill tips. A call is established on cell/BTS 431 with f2 carrier. Then it moves towards cell/BTS 70 with f1 carriers. When the mobile detects pilot PN 4 of pilot beacon above T_ADD, it sends PilotStrengthMeasurement Message to serving SBS via serving BTS 431. Since the CellType of PN 4 is defined as CELL_PILOT_BEACON, then hard handoff is triggered. Datafill Tips: 1. Create an ExtendedBaseId record for the target beacon unit in the PilotDataBase of the serving SBS/BSC. 2. PILOT_PN field should be datafilled with pilot PN of the target pilot beacon. For this example is pilot PN 4. 3. CellType = CELL_PILOT_BEACON 4. ACNNodeId should be set to 0 since this Pilot Beacon site is not physical connected to serving system (BSC/SBS) 5. The ReferencePilot field should be datafilled with the pilot PN of the serving cell. For this example is pilot PN 172. 6. The NeighborList field should be left empty. 7. But the NeighborList field of the serving cell/BTS 431 must have the ExtendedBaseId of the target pilot beacon in its neighbor list.

10

PN 172, f2 PN 172, f1 PN 4, f2

PN 4, f1

BTS 431, f2 PBU 431, f1 BSC Serving MSC IS-41 link

BTS 70, f1 PBU 70, f2 Target MSC BSC

Figure 3.1: IS-41 C CDMA to CDMA Inter-vendor Hard Handoff using Pilot Beacon Assisted Handoff Datafill Sample for Pilot Beacon Hard Handoff # # # # # # # # # # # # # # # # # # # # # ExtendedBaseId = 25166944, (ExtendedBaseId of the Pilot beacon unit) PILOT_PN = 4, (Pilot PN number transmitted from Pilot beacon unit) Available = true, MultiPilotHHOEnabled = false, (multi pilot hard handoff is not deployed) CellType = CELL_PILOT_BEACON, QuickRepeat = true, ForwardGain = 0, SRCH_WIN_A = 6, SRCH_WIN_N = 7, SRCH_WIN_R = 8, T_ADD = 28, T_DROP = 32, T_COMP = 2, T_TDROP = 3, NeighborList = ( 0 ), BTS_CRM_ACNAddr = ( ACNNodeId = 0 (The ACNNodeId can be set to 0 since this Pilot Beacon site
11

is not physical connect to Nortel system (SBS). The ACNNodeId is used to let SBS and BTS communicating for allocating resource). # ), # MSCID = # ( # MarketId = 32, (Target MarketId, if the Pilot Beacon is serving system then we need to have with serving Market Id) # SwitchNumber = 4 (SwitchNumber, if the Pilot Beacon is serving system then we need to have with serving SwitchNumber) # ), # BeaconTargetCellIdList = # ( # 1, # 0= # ( # ReferencePilot = 172, (must be datafilled with pilot PN of the serving cell) # TargetCellIdList = # ( # 1, # 0= # ( # MSCID = # ( # MarketId = 32, (Target System MarketId) # # SwitchNumber = 4 (Target System MarketId) # ), # IntersystemCellId = 1120 (Target Cell Number: 70 Omni, Hex 0x0460) # ) # ) # ) # ), 3.2 Round Trip Delay (RTD) Hard Handoff Trigger Mechanism The RTD hard handoff trigger is based the round trip time delay between the BTS to the mobile of the sector datafilled with CellType = CELL_BORDER. When the BTS measures its Round Trip Delay > BorderRefPilotRTDThreshold, the trigger is activated. The system will then instruct the mobile to hard handoff to the target cell (sector) that is datafilled in the PilotDataBase on the SBS. The following two conditions must be satisfied in order for the RTD trigger to be activated [1]. 1. All the sectors in the active set must be of type CELL_BORDER. The trigger will be inhibited if one of the pilots in the Active Set is type CELL_STANDARD.
12

2. From all of the sectors with Cell Type = CELL_BODER in the active set, the algorithm takes the one with the shortest RTD measurement and compares that measurement against the datafilled RTDThreshold for that sector. If the measured RTD > RTDThreshold, the handoff is triggered to the corresponding datafilled target sector. (Note: the other sectors (pilots) in the active set may have measured RTDs that exceed their own RTD thresholds but it is only the sector (pilot) with shortest RTD that matters). The RTD is reported by the system in 1/8th chips units. A report is generated on a per sector basis every time the RTD changes by 2 chips. Therefore the RTD has about 240 meters (one way delay) uncertainties (RTD gray zone). 3.2.1 RTD Threshold Calculation for Datafill Example: What is the datafill value for an RTD hard handoff which triggers when a mobile at a distance D = 5km from the BTS (cell).

RTD Trigger Point

Figure 3.2: Example of RTD Trigger Point Calculation Answers: Round Trip Delay means two times the distant D. The unit of RTD threshold (BorderRefPilotRTDThresh) in PDB is 1/8 of chips. Just to recap, 1 chip ~= 244 m so the RTD Threshold datafill with D = 5km is RTD Threshold datafill = [(2* 5000)/ (244)]*8 = 327 3.2.2 RTD Trigger Delay Due To Pilot Pollution The RTD trigger will not be triggered if one of the pilots in the Active Set has its CellType different than CELL_Type = CELL_BORDER. As a result the hard handoff will be delayed until this pilot in the Active Set is dropped out of the Active Set. This scenario can be occurred due to pilot pollution or due to the spillage energy of the pilot from one of the remote sectors with CELLType = CELL_STANDARD.

13

3.2.3

Datafill Tips for Hard Handoff using RTD Trigger under Pilot Pollution

If this is the case then we need to datafill this remote sector with CELLType = CELL_BORDER and set the BorderRefPilotRTDThresh to a value that has the RTD value greater than the distance delay that the mobile sees that remote sector. For example, if the mobile is about 25 Km way from this remote sector, then the RTD value for BorderRefPilotRTDThresh should be set greater than 25 Km. Let's say 100 Km so the value for the BorderRefPilotRTDThresh will be:

Border Re fPilotRTDThresh =

(100 * 1000) * 2 * 8 = 6557 244

Note: Multi Pilot Hard Handoff only support hard handoff between Nortel to Nortel but not support hard handoff between Nortel and other vendor since Multi Pilot Hard Handoff is Nortel Networks feature. More information on Multi Pilot Hard Hardoff target selection can be found in section Figure 3.3 on page 16 3.3 Summary of Multi Pilot Hard Handoff Target Cell Selection

3.3.1 The Reference Sector of RTD Trigger and Its First Target Sector The sector (PN) among the sectors (PNs) in the mobile Active Set with the shortest RTD measurement is considered as the reference sector by the switch IHM (Intersystem Handoff Manager of switch). This reference sector may not be the same as the reference sector used by the mobile, which is chosen corresponding to the PN with the earliest arrived multi path component, and is used for demodulation. When performing IS95 message analysis, the systems selected reference is treated with the highest priority and placed first in the Extended Handoff Direction Message. The system selected reference sector and its first target sector are key for many aspects of MPHHO when its MultiPilotHHOEnabled is set to true: The first target sector and all the target sectors of the BorderTargetCellIdList of the selected reference sector will get selected for MPPHHO. The target MSCID (MaketId and SwitchNumber) of the first target sector of this sector becomes the target MSCID for the HHO. Any target CellIds that do not have an appearance on this MSCID will not be used in the MPHHO and are not passed to the target MSC. The frequency/band of the first target sector becomes the target frequency. Any target CellIds that do not have this frequency will not be used in the MPHHO.

14

 Multi-Carrier Traffic Allocation will be triggered if it is available for the first target sector. Any target CellIds that do not have the resulting frequency will not be used in the MPHHO. Note that MCTA may result in a frequency change across an ISSHO border. All OMs related to the HHO are pegged against the first target sector of the system selected reference sector. Logs, billing and VLR entries use the first target sector of the system selected reference sector. 3.3.2 The Reference Sector of Pilot Beacon Trigger and Its First Target Sector For the case of Pilot Beacon trigger, the switch IHM (Intersystem Handoff Manager of the switch) choose its reference sector based on the forward link Ec/Io of the pilots that are reported from the mobile on the PSMM (Pilot StrengthMeasurement Message). Upon receiving the PSMM, the system will sort the PNs according to their Ec/Io levels in descending order. The PN with the highest Ec/Io (least negative) is chosen as the reference sector. When studying the IS95 messages, one may find that the reference sector reported by the mobile may be different from the reference sector chosen by the algorithm. Since the reference sector decided by the mobile is the one corresponds to the earliest arriving multipath, it may be different from the strongest pilot. The system selected reference sector and its first target sector are key for many aspects of MPHHO when its MultiPilotHHOEnabled is set to true: The first target sector and all the target sectors of the BorderTargetCellIdList of the selected reference sector will get selected for MPPHHO. The frequency/band of the first target sector becomes the target frequency. Any target CellIds that do not have this frequency will not be used in the MPHHO. The target MSCID (MaketId and SwitchNumber) of the first target sector of this sector becomes the target MSCID for the HHO. Any target CellIds that do not have an appearance on this MSCID will not be used in the MPHHO and are not passed to the target MSC. Multi-Carrier Traffic Allocation will be triggered if it is available for the first target sector. Any target CellIds that do not have the resulting frequency will not be used in the MPHHO. Note that MCTA may result in a frequency change across an ISSHO border. All OMs related to the HHO are pegged against the first target sector of the system selected reference sector.

15

 Logs, billing and VLR entries use the first target sector the system selected reference sector. 3.3.3 The MPHHO Target Selection Algorithm With the MPHHO feature, the single pilot HHO restriction is removed and mobile may initiate communication simultaneously over several air links on the HHO target system. For many cases, such as in an area with poor forward link FER or high dropped calls due to the presence of multiple pilots, having the ability to HHO to multiple pilots will help to improve the air link quality and hence have reliable HHOs. The target selection algorithm of the MPHHO is depicted in Figure 3.3. As mentioned in sections: 3.3.1 and 3.3.2 above, for RTD trigger, pilots are sorted according to the RTD value in the ascending order. For the Pilot Beacon trigger, pilots are sorted according to the pilot strength in the descending order. The target selection is then proceeds as follows. First, target cells for the system selected reference pilot are selected in the order as datafilled as depicted in Figure 3.3. Next, if less than six target cells are selected from the system selected reference pilot, the rest of the target cells are selected from other active pilots in the round robin manner, as depicted as circle2 in Figure 3.3.
RTD trigger Pilot Beacon trigger Pilot 0 (VirRef) Ref. Pilot after handoff Pilot 1 Pilot 2 Pilot 3 Pilot 4 Pilot 5 RTD increase Pilot strength decrease

2
1st traverse 2nd traverse 3rd traverse 4th traverse Target List

Figure 3.3: MPHHO Target Selection Algorithm 3.3.3.1 Example of Target Selection Based on the target cell list of each pilot or each sector in the Active Set of the mobile as depicted in Figure 3.4, for MPHHO, the source SES (Selector Element Subsystem) constructs the target cell list as follows: (x1, x2, x3, y1, z1, a1) and send it to the source CAU. This target cell list is passed to the SES in the target system via the source/target CAU and the source/target CM for call and radio link setup. After the multiple radio link

16

setup is completed, the target SES sends the target CAU a response, which is forwarded back to the source SES. If the resource in the target system has been allocated, the source SES sends an IS95 message Extended Handoff Direction Message to instruct the mobile to perform the hard handoff to the target system.

RTD trigger Pilot Beacon trigger Ref. Pilot after handoff

RTD increase Pilot strength decrease

x
x1 x2 x3

y
y1 y2

z
z1 z2 z3

a
a1 a2 a3 a4

b
b1 b2 b3 b4

c 2
c1 c2 c3 1st traverse 2nd traverse 3rd traverse 4th traverse

Target List 1

Figure 3.4: Example of Target Selection for Multi Pilot Hard Handoff 3.4 EHHO (RF Link Quality) Trigger Mechanisms The EHHO triggers are based on the forward and reverse link quality. The EHHO hard handoff originally was designed for CDMA to AMPS (CDMA overlay on AMPS) but its trigger mechanisms can also be applied for CDMA to CDMA. Tests had been conducted successfully for CDMA to CDMA EHHO hard handoff with source cell and target cell that had different carriers. Since the EHHO is designed for CDMA to AMPS handoff, it cannot make use of the Multi target cells handoff from the Multi Pilot Hard Handoff feature (MPHHO).

The EHHO hard handoff is on per carrier sector basis. In order to activate the EHHO hard handoff, the attribute CellType in the PDB record of a sector has to be datafilled with CELL_EHHO (i.e., the reference pilot has to its CellType datafilled as CELL_EHHO). Unlike RTD based HHO, not all pilots in the Active set have to be defined as CELL_EHHO. The EHHO trigger is comprised of 4 conditions. If any one of the four conditions mentioned below is met, the Handoff is triggered. For forward link triggers, the following conditions must be met. 1. EHHO_forwardFER[t] > EHHOFerMaxFwd
17

2.

EHHO_forwardFER[t] > EHHOFerModFwd and TCG[t] > EHHOTCGMax

For reverse link triggers, the following conditions must be met. 3. 4. EHHO_reverseFER[t] > EHHOFerMaxRvs EHHO_reverseFER[t] > EHHOFerModRvs and EHHOEBNOMax

Note: For NBSS10.xx software load, the four trigger conditions of the EHHO is still applied for 2G voice calls (RC1/RateSet1 and RC2/RateSet2) but only the triggers on condition 1 (Max fwd FER trigger) and condition 3 (Max rvs FER trigger) are applied for 3G voice calls (RC3 and above). Table 3.1: EHHO Parameters for PDB record entered in PilotDataBase

Parameter Name CellType

Range CELL_EHHO

Description

EHHOFerMaxFwd1

0 100%

EHHOFerMaxRvs1

0 100%

EHHOFerModFwd1

0 100%

EHHOFerModRvs1

0 100%

EHHOTCGMax2

0 100%

Threshold for the maximum allowable FER on the forward link Threshold for the maximum allowable FER on the reserve link Threshold for the moderate allowable FER on the forward link Threshold for the moderate allowable FER on the reverse link Threshold for the maximum allowable Traffic Channel Gain on the forward link.Traffic channel gain is based on FwdPwrCtrlRefGai n and RateSet3

Comments Need to datafill CellType with CELL_EHHO in order for the BSC to know that sector is EHHO cell. Typical value should use: 12 Typical value should use: 15 Typical value should use: 8 Typical value should use: 11 Typical value should use: 90

18

0 % corresponds to PTXlower 100% corresponds to PTXupper EHHOEBNOMax2 0 100% Threshold for the Typical value maximum allowable should use: 80 Ew/no set point on the reverse link. The range is determined by the PRXlower and PRXupper datafils in the SBS. ( 0% corresponds to PRXlower and 100% to PRXupper) Weighting factor to calculate the forward and reverse EHHO FER values. A small value favors the last FER reading while a large value favors the long term trend. 1268 is an example value of the target market id. 20 is an example value of the target switch id . 0x5f = cell 95 sector 1 Typical value should use: 100

EHHO_Window

1 - 255

EHHOTargetCell

MSCID=( MarketId=1268, SwitchNumber=20

These value can be found on TABLE MSACON

IntersystemCellId

0x5f1

Note: 1. The EHHOFerMaxFwd, EHHOFerMaxRvs, EHHOFerModFwd, and EHHOFerModRvs are averaged over EHHO_Window. The calculation is sampleed per frame basis 2. The EHHOTCGMax and EHHOEBNOMax are not average over EHHO_Window. The calculation is sampled on a per-frame basis. 3. RateSet here is defined as RateSet1/RC1 or RateSet2/RC2

19

Formulas
Forward _ EHHO _ FER(t ) = N 1 1 forwardFER (t ) + Forward _ EHHO _ FER(t 1) N N

Re verse _ EHHO _ FER(t ) = 1 N t arg etFER( fullrate ) N 1 reverseFER(t ) + N Re verse _ EHHO _ FER(t 1) t arg etFER(t 1)

3.5 Pros and Cons of the Hard Handoff Triggers for Inter-vendor Hard Handoff with Same Carrier Frequency and Non Co-located Cell Configuration This section will look into the pros and cons of the three mentioned hard handoff trigger mechanisms that can be applied for inter-vendor hard handoff using same carrier frequency for non co-located cell hard handoff configuration.

The following cares must be pay attention to when deploying the inter-vendor hard handoff using same carrier frequency for non co-located cell hard handoff configuration. 1. The source cell and the target cell can have the same frequency but has to have different PNs. 2. PN planning along the border between two systems (i.e., Pilot PN of source cells with Nortels clusters and Pilot PN of target cells with Third vendors Cluster) must be carefully reviewed for preventing PN aliasing. 3. Neighbor list of cells along the border between two systems must also be carefully reviewed for avoiding cells having Neighbor list with co-channel PNs, adjacent PNs or aliasing PNs.
3.5.1 Pilot Beacon Hard Handoff Trigger for Inter-vendor Hard Handoff with Same Carrier Frequency and with Non Co-located Cell Configuration

Note: Pilot Beacon hard handoff is not a recommended solution for same frequency
hard handoff. Please see the Cons section below for the explanation.
Pros:

20

Multi target cell selection (Multi Pilot Hard Handoff) can be implemented for the Pilot Beacon hard handoff trigger if the system load is NBSS 7.0 and if the Third vendor software system load also supports the multi target cell selection.
Cons: The trigger location is difficult to control because the Pilot Beacons PN is also a target cells PN. The trigger will be activated either too early or too late due to the effect of the traffic-load noise level or due to the fluctuation of the traffic load. The probability of drop calls is high as a result of the too-early trigger or too-late trigger. Just to recap, the Beacon hard handoff trigger mechanism is based on Ec/Io > T_ADD. Now the Ec/Io of the Beacon cell is Ec/ (In + Im), where In is the Nortel interference and Im is the other vendor interference. Thus it depends on the traffic load of both sectors and their adjacent sectors.

For example: In Figure 3.5 below, when a call is in the overlap region of PN90 and PN120, the call is normally in soft handoff when the two sectors are configured as standard cells and have the same BSC. When the call in soft handoff, the links of the call are improved with the diversity gain even though the call is affected by traffic load. When the call moves to the Y location the Ec/Io of PN90 is below T_Drop and the Ec/Io of PN120 is still above T_ADD, PN90 is dropped from mobile active set. The following is one of the problems that may encountered when deploying the Pilot Beacon Hard handoff to non co-located cells with same frequency. For example, as depicted in Figure 3.5 below, the PN120 configured as PILOT_BEACON_CELL in the PilotDatabase of the source system and configured as Standard Cell in the target system. As the call moves into the overlap region of PN90 and PN120 and reaches the X location, it may detect the PN120 > T_ADD as a result of fluctuated traffic load. Then the handoff trigger is activated and the source system requests the mobile to hard handoff to that specified target cell. At this location X, the RF link of target cell is affected by the interference of the source system. Then the call will be dropped.

21

Source System: DMS-MTX Freq: f1

Target System: other vendor MSC Freq: f1

Standard PN90

Beacon PN120

Mobile

Highway

Figure 3.5: Example of Hard Handoff Trigger with Pilot Beacon Cell 3.5.2 RTD Hard Handoff Trigger for Inter-vendor Hard Handoff with Same Carrier Frequency and with Non Co-located Cell Configuration Pros: Multi target cell selection (Multi Pilot Hard Handoff) can be implemented for the RTD hard handoff trigger if the system load is NBSS 7.0 and if the Third vendor system load also supports the multi target cell selection. The RTD trigger is not affected by traffic load and is the function of time delay distance. The trigger point can be fine tuned with field optimization Cons: The RTD hard handoff should only deploy in the areas have less random reflection delays such as the suburban, rural areas. It requires more time to optimize the RTD trigger points. 3.5.3 Recommendations for Optimizing RTD Hard Handoff between Non Colocated Cells with intra-frequency/inter-frequency

The following are the recommendations for optimizing RTD hard handoff between non co-located cells with same carrier frequency (inra-frequency) or different carrier frequency (inter-frequency). Identify all the major highways and divide the cutover market into several clusters. Make sure the highway across the Nortel cluster and the third vendor cluster are perpendicular

22

the handoff boundary. Figure 3.5 and Figure 3.6 are examples of border cells with highway running across and perpendicular to the handoff boundary.

Nortel Cluster RTD = RTD Border Cell T = Target Cell

RTDD T T RTD T T

Highway Third Vendor Cluster

Figure 3.6: Border cells formed perpendicular to the handoff boundary (Scenario 1)

Highway Nortel Cluster

RTD Border Sector Third Vendor Cluster

Target Sectors

Figure 3.7: Border cells with highway formed perpendicular to the handoff boundary (Scenario 2)

23

Before setting the trigger point of the source cell, the coverage footprints of both source/serving cells (Nortel Networks) and target cells (other vendor) should be surveyed. The RTD trigger point should be set beyond equal power level (or equal Pilot power level) boundary of the source cell. The RF link coverage at the trigger point should be sufficient to maintain the call before handoff and after handoff. Please do not confuse the equal power level boundary to the equal power islands. Figure 3.8 depicts an example of the equal power level boundary and the equal power islands The RTD trigger points of the source cell and the target must be large enough to prevent Ping-Pong handoff, but small enough that the handoff occurs before the target cell interference become to great. Figure 3.8 depicts an example of RTD set points between source cell and target cell. Ensure that the area of the location at the trigger point and the area of the underlying target cells can provide enough link coverage.

Equal Power Level Island Sector with Nortel DMS-MTX

Equal Power Level Boundary

Sector with third vendor MSC

RTD set point from sector with third vendor MSC

Overlap area

RTD set point from sector with Nortel DMS-MTX

Cell Edge

Figure 3.8: Example of Setting RTD Points between target cell and source cell 3.6 Enhanced Hard Handoff (EHHO) Trigger for Inter-vendor Hard Handoff with Intra-frequency/Inter-frequency and with Non Co-located Cell Configuration Pros: The trigger point can be set per the RF link quality, which is based on either forward link FER or reverse link FER Cons:

24

There is no Multi Pilot Hard Handoff available for the EHHO hard handoff trigger mechanism. It is difficult to determine the optimum point for EHHO trigger point because of traffic load fluctuation.

Note: The EHHO hard handoff is recommended as a second solution for same
frequency (intra-frequency) hard handoff if RTD hard handoff cannot be used at some areas. Please refer to section 3.6.1 below for the recommendations on what EHHO trigger conditions should be used for this case. The recommendations on what EHHO trigger conditions should be used is applied for both 2G voice calls (RC1/RateSet1 and RC2/RateSet2) and 3G voice calls (RC3 and above). In the case of inter-frequency hard handoff (different frequency hard handoff), the Pilot Beacon assisted trigger Hard Handoff is recommended as a second solution if RTD hard handoff trigger cannot be used at some areas.
3.6.1 Recommendations For Optimizing Enhanced Hard Handoff (EHHO) between Non Co-located Cells with Same Carrier Frequency The following are the recommendations for optimizing EHHO hard handoff between non co-located cells with same carrier frequency. For this scenario hard handoff configuration, we will use the EHHOFerMaxFwd and EHHOFerMaxRvs parameters as the trigger mechanisms. We may not use the intermediate trigger mechanisms. Please refer to Table 2 for the setting.

Before setting the trigger point of the source cell, the coverage footprints of both source/serving cells (Nortel Networks) and target cells (other vendor) should be surveyed. The trigger point for EHHOFerMaxFwd and EHHOFerMaxRvs, forward link and reverse link, should be set based on the FER value at the location beyond the equal power level boundary of the source and target cells. The RF link coverage at the trigger point should be sufficient to maintain the call before handoff and after handoff. Ensure that the area of the underlying target cells at the trigger point can provide the link coverage with either equal or better link coverage of the source cell. Figure 3.9 depicts serving border and target cell formed perpendicular to the highway with the application of EHHO hard handoff.

25

Highway Nortel Cluster

EHHO Border Sector

Target Sector

Third Vendor Cluster

Figure 3.9: Serving Border cell and Target cell formed perpendicular to the highway with the application of EHHO hard handoff

Table 3.2: EHHO Parameters Setting for Hard Handoff to non co-located Target cell with same frequency

EHHOFerMaxFwd EHHOFerMaxRvs EHHOFerModFwd EHHOFerModRvs EHHOTCGMax EHHOEBNOMax

0 100% 0 100% 0 100% 0 100% 0 100% 0 100%

Typical value should use: depend on field survey Typical value should use: depend on field survey Typical value should use: 100 (i.e., disabled) Typical value should use: 100 (i.e., disabled) Typical value should use: 100 (i.e., disabled) Typical value should use: 100 (i.e., disabled)
26

EHHO_Window

1 - 255

Typical value should use: 100

27

4.0 A-Open Interface (IOS2.2) CDMA to CDMA Intersystem Hard Handoff

This section discusses the A-Open Interface CDMA to CDMA Intersystem hard handoff between Nortel Networks MTX interfaced with Nortel Networks BSC and Nortel Networks MTX A-Opened interfaced with other vendor BSC. The goal of this section is to discuss what types of hard handoff trigger can be supported on Nortel Networks MTX interfaced with Nortel Networks BSC, what types of hard handoff trigger can be supported on Nortel Networks MTX A-Open interfaced with other vendor BSC. This section also discusses what type of IS41 protocols will be used for this case of A-Open Interface CDMA to CDMA Intersystem hard handoff between Nortel Networks MTX interfaced with Nortel Networks BSC and Nortel Networks MTX A-Opened interfaced with other vendor BSC.
4.1 Brief Description of Nortel Networks Open A-interface Product With the release of MTX08 and later, the MTX can support an open A-interface as defined by an interoperability specification generated in a multiple vendor forum. The open A-interface allows the connection of non-Nortel Networks BSCs and BTSs to the Nortel Networks DMS-MTX MSC concurrent operation of Nortel Networks BSCs with up to six A-interface BSCs on the same MTX

Nortel Networks open A-interface product is compliant to the CDMA Development Group interoperability specification (CDG IOS) version 2.2.0 (June 18, 1999). The CDG IOS 2.2.0 specification builds upon the IOS 2.0a specification and the CDG IOS 2.0.1 specification. More details on A-Open Interface topics can be found in the reference [9] DMS-MTX CDMA MTX Open-A Interface Implementation Guide, 411-2131-923. Figure 4.1 depicts the A-Open Interface DMS-MTX product system network architecture connections. Figure 4.2 depicts the coexistence of Nortel Networks proprietary interface and A Open Interface.

28

DMS MTX X DMS MT

IS 41 P

DMS MT X

A-Interface (SS7) BSMAP, DTAP messaging ISO V2.0a

Nortel Networks Proprietary messaging

Other Vendor BSC

Nortel Networks BSC

Air Interface JSTD-008 1900 MHz (PCS)

Figure 4.1: A-Open Interface DMS-MTX product system network architecture connections

Figure 4.2: Coexistence of Nortel Networks proprietary interface and open Ainterface

29

4.2 Hard Handoff functionality supported on Nortel Networks MTX and BSC All the existing hard handoff triggers such as Pilot Beacon assisting trigger, RTD trigger, and Enhanced Hard Handoff (Quality-Link) trigger are still used to support hard handoff trigger.

The Multi Pilot Hard Handoff and Multi Mode hard handoff features are not supported on the A-Open Interface CDMA to CDMA Intersystem hard handoff between Nortel Networks MTX interfaced with Nortel Networks BSC and Nortel Networks MTX AOpened interfaced with other vendor BSC.
4.3 Hard Handoff Functionality Supported on Nortel Networks MTX and other BSC The A-Open Interface is just a messaging protocol that is used for a MSC from one vendor to communicate with other BSC from other vendor. Therefore, all the previous BSC functionality and hard handoff triggers from other vendor should be maintained.

Networks try to maintain all previous DMS-MTX functionality for the A-Interface product. Thus the existing implementation is used whenever is applicable to minimize changes.
4.4 Hard handoff Deployment Planning and Datafill There two cases for the A-Open Interface CDMA to CDMA Intersystem hard handoff.

Case1: The A-Open Interface CDMA to CDMA Intersystem hard handoff between Nortel Networks MTX interfaced with Nortel Networks BSC and Nortel Networks MTX A-Opened interfaced with other vendor BSC. Figure 4.1 depicts case1 hard handoff. Case 2: The A-Open Interface CDMA to CDMA Intersystem hard handoff between Nortel Networks MTX A-Open interfaced with other vendor BSC and another vendor MSC interfaced with their own BSC. Figure 4.2 depicts case2 hard handoff. Case 1: The following things need to be performed when deploying A-Open Interface CDMA to CDMA Intersystem hard handoff between Nortel Networks MTX interfaced with Nortel Networks BSC and Nortel Networks MTX A-Opened interfaced with other vendor BSC. 1. For IS-41 networking, The IS-41 P protocol link is required for this case so the Table SYSCON should be datafilled with IS4P. The information on Table SYSCON can be found in section 9.0 IS-41 CDMA to CDMA Inter-vendor Hard Handoff Datafill.

30

2. Nortel Network cell Id bit format will be used. The information on Nortel Networks cell Id bit format can be found in section 10.0 Procedures To Datafill PDB IntersystemCellId and Table CDMAIMAP. 3. Table CDMAIMAP is not used. 4. A-Open interface networking configuration between Nortel Networks MTX and other vendor Case 2: The following things need to be performed when deploying A-Open Interface CDMA to CDMA Intersystem hard handoff between Nortel Networks MTX A-Open interfaced with other vendor BSC and another MSC interfaced with their own BSC. 1. For IS-41 networking, The IS-41 C protocol link is required for this case so the Table SYSCON should be datafilled with IS4C. The information on Table SYSCON can be found in section 9.0 IS-41 CDMA to CDMA Inter-vendor Hard Handoff Datafill. 2. Nortel Network cell Id bit format will be used. The information on Nortel Networks cell Id bit format can be found in section 10.0 Procedures To Datafill PDB IntersystemCellId and Table CDMAIMAP. 3. Table CDMAIMAP is used to map the target cell number to Cell Id format that is defined by other vendor.

5.0 IS-41 CDMA to CDMA Hard Handoff for 3G voice and 2G Voice Service Redirection
This section discusses what scenarios that Nortel Networks support and what scenarios that Nortel Networks do not support on IS-41 CDMA to CDMA Intersystem/Inter-vendor hard handoff for 3G voice and 2G Voice Service Option redirection.
5.1 Calls with RateSet1-EVRC on Other Vendor System Hard Handoff to Nortel System supporting RateSet2-13 Kbps and RateSet1-EVRC

The Intelligent Voice Service Negotiation (IVSN) is introduced in MTX9.0/NBSS9.0. This feature allows the Telco to force a mobile based on its capability to use a service that is most preferred by the Telco. The service to which a mobile is redirected is datafilled in table SERVNEG. The following are the main functionalities of the feature. Table 5.1 describes a list of Service Option Number corresponding with its call type. 1. Service Redirection can only be initiated by the MSC and can only be performed once during call setup phase. It cannot be performed after the call is setup. 2. Service Redirection during handoffs is not supported. Therefore call that has been established on a Vocoder Rate and performs hard handoff to Nortel target cell/cells with BSC not supporting that Vocoder Rate. This call will be rejected by Nortel target system and the call will be dragged and dropped.

31

In order to solve the issue on number 2 (Service Redirection during handoff not supported), Nortel Networks has introduced the Enhanced Selector card (ESEL). The ESEL can support. Up to 16 Selector Elements (DSP) per card (regular SEL card supports only 8) The voice service EVRC Packet routing the Packet Filter Buffer All the current functionality of the regular Selector card (services: Q13 Voice, SMS and Loopback)

Table 5.1: List of Service Option Number Corresponding with its Call Type CDMA_DEFAULT_VOICE_SERVICE_OPT
NIL_SERVICE_OPTION BASIC_8K_VOICE BASIC_13K_VOICE EVRC IS733_13K_VOICE

Service Option #
0 #1 #8000 #3 #11

5.1.1

Hard handoff Deployment Planning and Datafill

As mentioned above Service Redirection during handoffs is not supported so it is necessary to have all Nortel Networks cells/sectors that involve in intersystem/intevendor CDMA to CDMA hard handoff to be configured with SBS that have ESEL cards. Thus calls with EVRC or 13 K service option hard handoff from other vendor system to Nortel Networks system do not require Service Redirection. The IS-41 C protocol link is required for this case so the Table SYSCON should be datafilled with IS4C. The information on Table SYSCON can be found in section 9.0 IS41 CDMA to CDMA Inter-vendor Hard Handoff Datafill. Table CDMAIMAP is also required to be datafilled if the other vendor CellID bit format is different than Nortel Networks CellId bit format. The information on Table CDMAIMAP can be found can be found in section 9.0 IS-41 CDMA to CDMA Intervendor Hard Handoff Datafill.

32

5.2 Calls with 3G Voice CDMA to CDMA Hard Handoff The 1XRTT Commercial Product does not support 3G voice to 3G voice inter-vendor hard handoff since 3G voice/data to 3G voice/data inter-vendor hard handoff requires IS-41 E and the IS-41 E was not published at the time of development. The 1XRTT commercial product is introduced in the MTX10.xx/NBSS10.xx load.

Inter-vendor 2G-voice CDMA to CDMA hard handoffs are supported by using IS-41 C (ANSI-41 D) protocol/link. The IS-41 Revision C supports only 2G-voice call but does not support 3G voice call and 3G data call so there is not much change from MTX9.xx/NBSS9.xx to MTX10.xx/NBSS10.xx from the inter-vendor CDMA to CDMA hard handoff point of view. Nortel Networks has provided the flexibility that when a 3G voice call hard handoff from other vendor system to Nortel system, this 3G voice call can be allowed to hand down to 2G voice call (for example: RC3 call hands down to RC1-EVRC call) by using IS-41 Revision C.
5.2.1 Hard handoff Deployment Planning and Datafill

As mentioned above 3G voice call hard handoff from other vendor system to Nortel Networks system is allowed to be handed down to 2G voice so it is necessary to have all Nortel Networks cells/sectors that involve in intersystem/inte-vendor CDMA to CDMA hard handoff to be configured with SBS that have ESEL cards. The IS-41 C protocol link is required for this case so the Table SYSCON should be datafilled with IS-41C. Table CDMAIMAP is also required to be datafilled if the other vendor CellID bit format is different than Nortel Networks CellId bit format. The information on Table CDMAIMAP can be found in section 10.2, Procedures to Datafill NWKCELL of Table CDMAIMAP

6.0 How to Set the Hard Handoff Trigger at Optimum Location (Point)
The following are the summary of how to set the hard handoff trigger at optimum location. 1. PN planning along the border between two systems (i.e., Pilot PN of source cells with Nortels clusters and Pilot PN of target cells with Third vendors Cluster) must be carefully reviewed for preventing PN aliasing. 2. Neighbor list of cells along the border between two systems must also be carefully reviewed for avoiding cells having Neighbor list with co-channel PNs, adjacent PNs or aliasing PNs. 3. Use Planet to generate the equal power level boundary between source cells and target cells. 4. Survey the RF footprints of both source cells and target cells.

33

5. Use the Planet result as an aid for locating the equal power level boundary with real field measurements. 6. When the actual equal power level boundary has been located, the hard handoff trigger point should be as follows. For RTD Hard Handoff Trigger: The RTD trigger point should be set beyond equal power level (or equal Pilot power level) boundary of the source cell. The RF link coverage at the trigger point should be sufficient to maintain the call before handoff and after handoff. The RTD trigger points of the source cell and the target must be large enough to prevent Ping-Pong handoff, but small enough that the handoff occurs before the target cell interference become to great. For EHHO Hard Handoff Trigger: The trigger point for forward link and reverse link, EHHOFerMaxFwd and EHHOFerMaxRvs, should be set based on the FER value at the location beyond the equal power level boundary of the source and target cells. The RF link coverage at the trigger point should be sufficient to maintain the call before handoff and after handoff. 7. Figure 6.1 is an example depicting the equal power level boundary and the trigger set point location. Please do not confuse equal power level boundary to the equal power level islands.

Equal Power Level Islands Sector with Nortel DMS-MTX

Equal Power Level Boundary Sector with third vendor MSC

RTD set point from source sector with Nortel DMS-MTX

Equal Power Level Islands

Cell Edge

Figure 6.1: Equal Boundary Power Level Boundary and Trigger Set Point Location

34

6.1 Overlap Coverage Requirement at Hard Handoff Region for Intersystem/Inter-vendor Hard Handoff Intersystem (IS-41) messaging and resource allocation normally take about 5 seconds for the handoff process to complete. Therefore an extra coverage from the source cell of serving system to the target cell of the target system is required. Assuming that a mobile is traveling about 80 mph and the intersystem handoff process takes about 5 second to complete, then an additional distant coverage of 538 feet (179 m) is required to add to the ping-pong preventing distant coverage. Figure 6.2 depicts the overlap requirement for Intersystem/Inter-vendor Hard Handoff.

Equal Power Level Boundary Equal Power Level Islands

Serving Sector with Nortel DMSMTX Target Sector with third vendor MSC

Equal Power Level Islands

Extra distant coverage Requirement for Intersystem handoff messaging delay Trigger set point and ping-pond preventing set point from source sector

Cell Edge

Figure 6.2: Coverage Overlap Requirement for Intersystem/Inter-vendor Hard Handoff

7.0 Neighbor List Considerations

There are two types of neighbor list: neighbor list per sector based at PilotDataBase (PDB) and neighbor list per sector based at BTS. The neighbor list at PDB is used during call in traffic mode for soft handoff and softer handoff. The neighbor list at BTS is used for idle mode handoff. This section looks into whether an adjacent cell/sector or adjacent cells/sectors involving in CDMA to CDMA inter-vendor hard handoff should be datafilled in the neighbor list at PDB or in the neighbor list at BTS for different types of hard handoff trigger. Figure 7.1

35

depicts the cell layout with BTS number involving CDMA to CDMA inter-vendor hard handoff and is used as an example for datafilling for neighbor list selection discussion.
7.1 Neighbor List Considerations for Pilot Beacon Trigger

Figure 7.1 depicts the cell layout (with BTS number) involving in CDMA to CDMA inter-frequency inter-vendor Hard Handoff using Pilot Beacon assisting trigger and is used as an example for datafilling for neighbor list selection discussion. 7.1.1 PDB Neighbor List

The neighbor list of the source sector with PN80 The Pilot beacon unit (i.e., ExtendedBaseId of the Pilot beacon unit datafilled in source PDB) should be in the neighbor list of this source sector (involving in hard handoff) even though this PBU does not provide traffic accommodation. The reason is that if it is in the neighbor list of this sector, this will help the mobile to detect the PN160 of the Pilot Beacon Unit faster and make the hard handoff more reliable since the NeighborListUpdate message that mobiles receive after performing softer handoff with sector with PN76 includes the PN160 of PBU in the neighbor list.

Sample of datafill
ExtendedBaseId = 175178754, (ExtendedBaseId of BTS64, sector Beta) PILOT_PN = 80, Available = true, MultiPilotHHOEnabled = false, CellType = CELL_STANDARD,

. ..
NeighborList = ( 3, 0 = 175178753 (ExtendedBaseId of BTS64, sector Alpha) 1 = 175178755 (ExtendedBaseId of BTS64, sector Gamma) 2 = 175177874 (ExtendedBaseId of PBU 9, sector Beta) ),

The neighbor list of the Pilot Beacon Unit with PN160 Since a beacon is never used in the active set, it requires no neighbor list entries.

Sample of datafill
ExtendedBaseId = 175177874, (ExtendedBaseId of PBU 9, sector Beta) PILOT_PN = 160, Available = true, MultiPilotHHOEnabled = false, CellType = CELL_BEACON_PILOT,

.
36

..
NeighborList = ( 0, ), BTS_CRM_ACNAddr = ( ACNNodeId = 0 (does not require ACNNodeID since this PBU is a logic PBU from the serving PDB point of view) ), MSCID = ( MarketId = 4190, (Target MarketId, if the Pilot Beacon is serving system then we need to have with serving Market Id) SwitchNumber = 12 (SwitchNumber, if the Pilot Beacon is serving system then we need to have with serving SwitchNumber) ), ReferencePilot = 80 (must be datafilled with pilot PN of the serving cell) BeaconTargetCellIdList = ( 1, 0 = ( MSCID = ( MarketId = 4190, (Target System MarketId, this value is get from table MSCIDRTE) SwitchNumber = 12 (Target System MarketId, this value is get from table MSCIDRTE) ), IntersystemCellId = 76 (Target Cell Number: 9 Y, Hex 0x004A) ) ),

. ..
),

7.1.2

BTS Neighbor List

The neighbor list of the source sector with PN80 The target sector 9Y with PN160 from the other vendor system should be in the neighbor list of this source sector since it will assist mobiles in idle handoff faster.

Sample of datafill
"O%:CBS1:Cells1:MC1900BTS64:MCBTSSubsystem1:root1:btSCallProcessing1:Adv ancedFA1:AdvancedSector2"

37

 # # # SectorId = Beta, SectorCellId = 1026, PILOT_PN = 80,

# ExtendedNeighbors = # ( # 3, # 0 = # ( # NGHBR_CONFIG = 0, # NGHBR_PN = 76, # SEARCH_PRIORITY = 1, # NeighborFreqValid = true, # NeighborFreqInfo = # ( # NGHBR_BAND = 1_8_2_0GHz, # NGHBR_FREQ = 625 # ) # ), # 1 = # ( # NGHBR_CONFIG = 0, # NGHBR_PN = 84, # SEARCH_PRIORITY = 1, # NeighborFreqValid = true, # NeighborFreqInfo = # ( # NGHBR_BAND = 1_8_2_0GHz, # NGHBR_FREQ = 625 # ) # ), # 2 = # ( # NGHBR_CONFIG = 0, # NGHBR_PN = 160, (Pilot PN of the target sector) # SEARCH_PRIORITY = 1, # NeighborFreqValid = true, # NeighborFreqInfo = # ( # NGHBR_BAND = 1_8_2_0GHz, # NGHBR_FREQ = 650 (Carrier channel number of the target sector 9Y) # ) # ) # ),

38

Source System: DMS-MTX BTS number: 64 F1Carrier = 625

Hard Handoff Trigger Sector

Target System: other vendor MSC BTS number: 9 F2 carrier = 650 Target
Sector

PN80 Mobile direction

PN76

Coverage of Pilot Beacon Unit 9, using f1 channel 625 PN160

PN84 Highway Hard Handoff trigger set point

Figure 7.1: CDMA to CDMA inter-frequency inter-vendor Hard Handoff Using Pilot Beacon assisting trigger

7.2

Neighbor List Considerations for RTD Trigger

Figure 7.2 depicts the cell layout (with BTS number) involving in CDMA to CDMA inter-frequency inter-vendor Hard Handoff using RTD assisting trigger and is used as an example for datafilling for neighbor list selection discussion.
7.2.1 PDB Neighbor List

The neighbor list of the source sector with PN80 There is no need to datafill the target cell 9Y with PN160 to the neighbor list of this source sector (involving in hard handoff) since the target cell 9Y with PN160 can not be in the Active Set.

Only sectors can actually be brought into the active set should be in the neighbor list of this serving/source sector with cell type = CELL_BORDER. Sample of datafill
ExtendedBaseId = 175178754, (ExtendedBaseId of BTS64, sector Beta)

39

PILOT_PN = 80, Available = true, MultiPilotHHOEnabled = false, CellType = CELL_BORDER, .. .. .. .. NeighborList = ( 2, 0 = 175178753 (ExtendedBaseId of BTS64, sector Alpha) 1 = 175178755 (ExtendedBaseId of BTS64, sector Gamma) ), BTS_CRM_ACNAddr = ( ACNNodeId = 1626161 ), MSCID = ( MarketId = 4190, (Serving System MarketId, this value is get from table MSACON) SwitchNumber = 41 (Serving System MarketId, this value is get from table MSACON) NeighborList = ( 3, 0 = 175178753 (ExtendedBaseId of BTS64, sector Alpha) 1 = 175178755 (ExtendedBaseId of BTS64, sector Gamma) 2 = 175177874 (ExtendedBaseId of PBU 9, sector Beta) ), BorderRefPilotRTDThresh = 721, BorderTargetCellIdList = ( 1, 0 = ( MSCID = ( MarketId = 4190, (Target System MarketId, this value is get from table MSCIDRTE) SwitchNumber = 12 (Target System SwitchNumber, this value is get from table MSCIDRTE) ), IntersystemCellId = 76 ) ), (Target Cell Number: 9 Y, Hex 0x004A)

. ..
),

40

7.2.2

BTS Neighbor List

The neighbor list of the source sector with PN80 The target sector 9Y with PN160 from the other vendor system should be in the neighbor list of this source sector since it will assist mobiles in idle handoff faster.

Sample of datafill
"O%:CBS1:Cells1:MC1900BTS64:MCBTSSubsystem1:root1:btSCallProcessing1:Adv ancedFA1:AdvancedSector2" # # # SectorId = Beta, SectorCellId = 1026, PILOT_PN = 80,

# # # # # # # # # # # # # # # # # # # # # # # # # # # # # ExtendedNeighbors = ( 3, 0 = ( NGHBR_CONFIG = 0, NGHBR_PN = 76, SEARCH_PRIORITY = 1, NeighborFreqValid = true, NeighborFreqInfo = ( NGHBR_BAND = 1_8_2_0GHz, NGHBR_FREQ = 625 ) ), 1 = ( NGHBR_CONFIG = 0, NGHBR_PN = 84, SEARCH_PRIORITY = 1, NeighborFreqValid = true, NeighborFreqInfo = ( NGHBR_BAND = 1_8_2_0GHz, NGHBR_FREQ = 625 ) ), 2 = (

41

# # # # # # # # target sector # # ) # ),

NGHBR_CONFIG = 0, NGHBR_PN = 160, (Pilot PN of the target sector) SEARCH_PRIORITY = 1, NeighborFreqValid = true, NeighborFreqInfo = ( NGHBR_BAND = 1_8_2_0GHz, NGHBR_FREQ = 650 (Carrier channel number of the 9Y) )

Source System: DMS-MTX BTS number: 64 F1Carrier = 625

Hard Handoff Trigger Sector

Target System: other vendor MSC BTS number: 9 F2 carrier = 650 Target
Sector

PN80 Mobile direction

PN76

PN160

PN84 Highway Hard Handoff trigger set point

Figure 7.2: CDMA to CDMA inter-frequency inter-vendor Hard Handoff Using RTD assisting trigger

42

8.0 Hard Handoff OM

8.1 Hard Handoff Measurement per OMMTXH02 OM Group

OM group OMMTXHO2 can be used to measure the hard handoff performance for the intersystem/inter-vendor hard handoff. This OM group pegs the hard handoff performance at the CM (Compute Module) level. The registers that belong to this OMMTXHO2 peg both the intra and intersystem hard handoff (CDMA to CDMA and CDMA to AMPS) and peg against the source (primary) cell/sector. Note: The definition of each register of the OMMTXHO2 OM group is provided here just for information. Do not use this OM to measure the hard handoff performance since a CR Q00410125 is opened against this OMMTXH02. The document will be updated this section when this CR is resolved.
CHOSRCAT - Cm Hard handOff SouRCe ATtempts - This OM is pegged when the CM receives a handoff candidate message (indicating that a hard handoff is being requested) from the CAU. CHOSRCSU - Cm Hard handOff SouRCe SUccess - This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from the CAU (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). CHOBLKS - Cm Hard handOff BLocKS - This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. CHOSRCFL - Cm Hard handOff SouRCe FaiL - This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the CAU (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). CHOSRRLS - Cm Hard handOff SouRce ReLeaSe - This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated (after CHOSRCAT). CHONSRCR - Cm Hard handOff No SouRCe Response - CHONSRCR is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the receipt of the

43

Handoff candidate message). CHONSRCR indicates that a handoff never occurred and does not indicate a dropped call.
8.2 Hard Handoff Measurement per CAUCPSCT OM Group

Hard handoff OM registers of OMMTXHO2 is designed to peg at CM level against the source cell/sector (per sector basis). They peg the hard handoff activities for both Intersystem/Inter-vendor MSC/MTX and Intrasystem MTX hard handoff. The hard handoff activities that are pegged by the OMMTXHO2 group can be CDMA to CDMA and CDMA to AMPS. In contrary the hard handoff registers of CAUCPSCT is designed to peg at the CAU level against the target cell/sector (per sector basis). The hard handoff activities that are pegged by the CAUCPSCT group are Intrasystem (CDMA to CDMA and CDMA to AMPS) and intersystem/inter-vendor hard handoff (CDMA to CDMA and CDMA to AMPS). The following is the list of the Hard Handoff OM registers of the CAUCPSCT.
CAUHATTS - CAU Handoff ATTemptS is pegged on a per-sector basis when the CM requests the CAU to prepare a cell for handoff. CAUHSUCC - CAU Handoff SUCCess is pegged on a per-sector basis after the target SBS detects that the mobile is on the new channel. CAUHBLKS - CAU hard Handoff BLocKS - CAUHBLKS is pegged anytime a CDMA-to-CDMA hard handoff setup fails due to resource shortage. It represents all of the hard handoff setup failures into a sector, regardless of resource. This OM is pegged for both inter- and intrasystem hard handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it merely represents the number of times that a hard handoff could not be completed due to resource shortages in the target cell/sector the call in the source cell is still up. CAUHRLFL - CAU Handoff Radio Link FaiLure is pegged on a per-sector basis when the mobile fails to move from the old channel to the new target channel during a handoff. CAUHRSFL - CAU Handoff ReSource FaiLure register is pegged whenever a CAU times out on waiting for a resource request response or when the Resource Manager fails to allocate resources for a handoff on the target CAU. CAUHRLS - CAU Handoff ReLeaSe is pegged whenever the user hangs up while the mobile is handing off.

44

9.0 IS-41 CDMA to CDMA Inter-vendor Hard Handoff Datafill

This section discusses procedures to datafill IS-41 CDMA to CDMA Intersystem/Intervendor Hard Handoff. The procedures provide in this section is just focused on certain of datafill tables or certain fields of some tables that are related to RF from the RF perspectives. The procedures on how to configure the IS-41 Networks is beyond the scope of this document. The information on how to configure the IS-41 Networking can found in Reference [8] IS-41 Overview and Implementation (Course 0884). The following fields and Tables are required to be datafilled for CDMA to CDMA Intervendor hard handoff. 1. The MSGFMT and IHODATA fields of Table SYSCON since it defines what revision of IS-41 messaging protocol is used to communicate between the two systems (Nortel Networks switch and other vendor switch). 2. Table MSCIDRTE is used to define the system identifier and switch number of the beginning and the ending switches, and the route name that is defined in Table SYSCON 3. Table CDMAIMAP is used to map the target cell/sector (BTS) numbers of the target MSC of the other vendor when the bit format that they use to define their cell/sector (BTS) numbers are different than Nortel Networks bit format used to define the cell/sector (BTS) number. The detailed descriptions of this Table are explained in the section below. 4. PBDRecords (PilotDataBase Record) of sectors (ExtendedBaseIds) in PDB (PilotDataBase) of source (serving) SBSs involving in intersystem/inter-vendor CDMA to CDMA hard handoff are required to datafilled with MarketId, SwitchNumber, CellId (IntersystemCellId) of the target cells of the handoff target system. 5. MTX CellId in integer number that is mapped to Nortel MTX CellId bit-format structure is used for datafilling to the non-Nortel MSC.
9.1 Table SYSCON The SYStem CONnection (SYSCON) table defines the logical connection, which is used to route IS-41 messaging to another switch network within the cellular network. The logical connection can be defined by the RTENO (Route Number) and RTENAME (Route Name) parameters of the table. It is also required to define what Revision of IS-41 messaging is used for the communications between two switches (two MSCs). Two switches need to have the same revision of IS-41 messaging protocol for communicating otherwise the communication will fail. We will focus on the following fields of the Table SYSCON: the MSGFMT and the IHODATA. The rest of the other fields are related to IS41 networking configuration for the communications among several MSCs so please consult with Network Integration

45

Engineering or refer to Networking datafill translation documents on how to datafill these fields. 9.1.1 Datafilling MSGFMT Field of Table SYSCON

The MSGFMT (Message Format) field of Table SYSCON defines what revision of the IS-41 message format should be used for message link communication. The range of MSGFMT is {IS41, IS41A, IS41B, IS41C, IS41P} For CDMA to CDMA Inter-vendor hard handoff, the MSGFMT field of Table SYSCON should be datafilled with IS41C value. IS41C message type can also support Inter-vendor CDMA to AMPS hard handoff. The IS41C field has the following subfields described in table below.
Subfields of IS41C field TIMEIDX Range {DEFAULT} Descriptions Enter the index key of the tuple in Table IS41Time. Table IS41Time provides the capability to configure timer values for various {IS41, IS41A, IS41B, IS41C, IS41P}. The Default timer is the recommended value Intersystem Handoff FACDIR2 IHO2 must be set to Y for IS41C to use FACDIR2 and HANDBACK2 message (i.e., for inter-vendor CDMA to CDMA hard handoff, CDMA to ANALOG hard handoff and ANALOG to ANALOG hard handoff between Nortel and the other vendors. Note: for ANALOG to ANALOG hard handoff between Nortel and Motorola, refer to subfield MOTOROLA below). This subfield enables Analog IHOs (Intervendor HandOff) between Nortel and Motorola when link is IS41C and the IHO2 bool = Y. This applies to MTX08 and forward.

IHO2

{N,Y}

MOTOROLA

{N,Y}

Note: IS41P message type is used for hard handoff (CDMA to CDMA, CDMA to AMPS, and AMPS to AMPS) between two Nortel Networks MTXs. The IS41C message type supports not only intersystem handoff protocols but also supports call delivery, automatic roaming, Short Message Service, Billing and etc. 9.1.2 Datafilling IHODATA Field of Table SYSCON The IHODATA field defines the intersystem/inter-vendor handoff link, the incoming trunk group, and the outgoing trunk group. The subfields of the IHODATA are described in table below.

46

Subfields of IHODATA field IHOLINK

Range {N,Y}

TRKGRP (It is required to be datafilled when the IHOLINK is set to Y) GRPNUMIC (It is required to be datafilled when the IHOLINK is set to Y)

Up to 14 alphanumeric characters {0 to 255}

GRPNUMOG (It is required to be datafilled when the IHOLINK is set to Y)

{0 to 255}

Descriptions Intersystem/Inter-vendor Handoff Link It is required to enter Y for when the intersystem/inter-vendor (i.e., between Nortel and Nortel or between Nortel and other vendor MSC) handoff is performed. Trunk Group The trunk group name previously defined in Table TRKGRP, which connects the systems in a networked aread Group Number Incoming This subfield defines the incoming trunk group that is expected (datafilled) in the other the GRPNUMOG of the Table SYSCON in the other (adjacent) Nortel MTX or is expected (datafilled) in the other outgoing trunk group of the other vendor MSC for handoff communication. Group Number Outgoing This subfield defines the outgoing trunk group that is obtained from the GRPNUMIC of the Table SYSCON in the other (adjacent) Nortel MTX or is obtained from the other incoming trunk group of the other vendor MSC.

Note: 1. If the Table SYSCON of the Nortel MTX (lets say MTX1) defines its the GRPNUMIC =254 and GRPNUMOG=255, then the Table SYSCON of the other (adjacent MTX, lets say MTX2) will have its datafilled values as follows: GRPNUMIC=255 and GRPNUMOG=254 and vice versa. 2. The LOCALNET field in Table SYSCON defines Nortel internal lab use only. Its range is {Y, N}. 3. The QUALREQ field in Table SYSCON when it is set to Y, then the Nortel DMS MTX can communicate with the other vendor MSC that support IS41-A Qualification Request Message. When it is set to N, then the Nortel DMS MTX will send a Service Profile Request message instead of the Qualification Request Message to obtain the profile in the HLR. Please consult the Networking Integration Engineering for the datafilling of this field.
9.1.3 Datafill Sample of Table SYSCON of Nortel Networks Switch

Table: SYSCON RTENO RTENAME LINKDATA MSGFMT LOCALNET QUALREQ IHODATA -----------------------------------------------------6 JFC455 TCAP_LINK ANSI7 214 150 10 IS41C DEFAULT Y N Y Y MH0755HHO 255 255

Where: 6 = RTENO = Route Number (the number of a route that belongs to the other/target system)
47

JFC455 = RTENAME = Route Name (the route name that belongs to the other/target system)
Note: The definition of the rest of the parameters of this table can be found in Reference [8] IS-41 Overview and Implementation (Course 0884). 9.2 Table MSCIDRTE This table is used to specify the system identifier and switch number of the beginning and the ending switches of the target switch, and the route name that is defined in Table SYSCON. Therefore the FRMMSCID, TOSID, and TOSWTCH parameters and the RTENAME parameters of the table must be datafilled with correct System Identifier number, Switch number, and route name. Datafill Sample of Table MSCIDRTE
TABLE: MSCIDRTE >list all TOP FRMMSCID TOSID TOSWTCH RTENAME NWKOPTNM TTORIG TTSERV -------------------------------------------------------------4190 12 4190 12 JFC455 DEFAULT NIL NIL

<LUCENT

Where:
4190 is the datafilled value for FRMSID subfield of FRMMSCID (specifies the target System Indentifier number. This SID number is also datafilled in the MarketID field of the PBDRecords (PilotDataBase Record) of sectors (ExtendedBaseIds) in PDB (PilotDataBase) of source (serving) SBSs involving in intersystem/inter-vendor CDMA to CDMA hard handoff. 12 is the datafilled value for FRMSWTCH subfield of FRMMSCID (specifies) the target switch number. This swicth number is also datafilled in the SwitchNumber field of the PBDRecords (PilotDataBase Record) of sectors (ExtendedBaseIds) in PDB (PilotDataBase) of source (serving) SBSs involving in intersystem/inter-vendor CDMA to CDMA hard handoff. TOSID and TOSWTCH have same explanations FRMSID and FRMSWTCH.

JFC455 is the datafilled value for the RTENAME and this value is corresponding to the datafilled value for RTENAME parameter of Table SYSCON.
Datafill Sample for MSCID corresponding to Table MSCIDRTE
BorderRefPilotRTDThresh = 721, BorderTargetCellIdList = (

48

1, 0 = ( MSCID = ( MarketId = 4190, (Target System MarketId, this value is get from table MSCIDRTE) SwitchNumber = 12 MSCIDRTE) (Target System MarketId, this value is get from table

), IntersystemCellId = 74 (Target Cell Number: (9Y, Hex 0x004A)

9.3 Table CDMAIMAP Table CDMAIMAP is introduced in 8.xx software load. It is used for Inter-vendor CDMA to CDMA and CDMA to AMPS Hard Handoff and is used to map the target cell/sector (BTS CellId) numbers of the target MSC from the other vendor when the bit format that they use to define their cell/sector (BTS CellId) numbers are different than Nortel Networks bit format used to define the cell/sector (BTS) number. The detailed descriptions of this Table are explained in the section below. Table CDMAIMAP is required to be datafilled only when CDMA to CDMA intervendor hard handoff is deployed and the target MSC is a non-NORTEL MSC. When CDMA to CDMA inter-system hard handoff is deployed between two Nortel Networks MTXs, Table CDMAIMAP is not required to be datafilled since the bit format defined the cell/sector (BTS) number of the source MTX is the same as the target MTX. Description of Table CDMAIMAP Field Name Range of Values SEGID {0 To 16 CHARs} {0 To 4095} {X,Y,Z,U,V,W} NWKCELL {0 TO 65535}

route_ name csc_number The target cell id of other vendor for handing-off a from DMS-MTX system

SEGID: This field contains 2 parameters: route_name: The route_name of the target system (other vendor). This can be obtained from Table SYSCON Note: Table SYSCON needs to datafill before Table CDMAIMAP.
csc_number: This field will be datafilled with the target CellID (Cell number + Sector). Also this target CellId is required to convert into a heximal number or integer number that is mapped to the Nortel Networks bit-format definition for cell/sector (BTS CellId) number and is datafilled in the IntersystemCellId field of the ExtendedBaseId Record of the serving/source PilotDataBase of the sector involved in

49

hard handoff. The procedures to datafill this csc_number parameter of Table CDMAIMAP are described in section 10.1.
NWKCELL: This field specifies the target cell/sector number (targetcellID) involving in hard handoff. The target cell/sector number is datafilled as integer number. This integer number is translated from the 16 bit-format that is defined by other vendor. The procedures to datafill this NWKCELL parameters of Table CDMAIMAP are described in section 10.2. Datafill Sample of Table CDMAIMAP TABLE: CDMAIMAP

SEGID

NWKCELL

---------------------------JFC455 9Y 521

10.0 Procedures To Datafill PDB IntersystemCellId and Table CDMAIMAP

10.1 Procedures to Datafill Nortel CDMA IntersystemCellId field in PilotDatabase For NBSS9.0, the maximum CDMA cell number is 2047. Therefore the new IntersystemCellId bit format need to expand from 9 bits to 11 bits. Now the IntersystemCellId bit format (structure) is defined as in Figure 10.1.

bit 14

bit 3

bit 0

2 Band bits

11 Cell number bits

3 Sector id bits

Figure 10.1: IntersystemCellId bit format (structure) defined in NBSS9.0

The bit data fields of the IntersystemCellId are defined in Table 10.1. The Binary mapping of sector name is described in Table 10.2 and the Band Class name is described in Table 10.3.
Table 10.1: Bit data fields of the IntersystemCellId Field name Sector Id Total Bits 3 From Bits 0 To Bits 2

50

Cell Number Band Id (Class)

11 2

3 14

13 15

Table 10.2 : Sector Name with Binary Mapping Sector Name Omni Alpha Beta Gamma Binary mapping 000 001 010 011

Table 10.3: Band Class Name with Binary Mapping Band Class Name Unknown AMPS 800 MHz CDMA 1900 MHz CDMA Binary Mapping 00 01 10 11

Example to convert the target cell/sector number into heximal or integer number that is datafilled in IntesystemCellId

As mentioned above for NBSS9.0, Nortel implements the InterSystemCellId as 11 bits for the cell/BTS number and 3 bits for sector Id so that cell/BTS number can support up to 2048-1 = 2047. The following are the bit format sequence and the mapping conversion. For the Inter-vendor (i.e. non-Nortel MSC to/from Nortel MSC) CDMA to CDMA Hard Handoff, it is not necessary to datafill the Band Class information. Band Class information only requires for multi-mode hard handoff feature. This feature is Nortel proprietary feature, which is introduced in NBSS8.0. Therefore the Band Class information can be datafilled as unknown Band, which is translated to 00.
Procedures 1. Write the Band Class in binary format (2 bits). Use 00. 2. Write the BTS number in binary format (11 bits). 3. Write the Sector number in binary format (3 bits). 4. Concatenate the three binary numbers in the following format.

CCBB BBBB BBBB BSSS Where cc = Bandclasss bit, B = Cell/BTS bit, and S = sector bits. 5. Convert the each group of the concatenated number in to HEX. 6. Datafill the conversion in the IntersystemCellId in the Pilot DataBase.
Example of conversion

51

For example, we want to datafill the target cell/sector number 9Y (BTS 9, Sector 2) with Unknown Band Class in the IntersystemCellId field in the PDB of the serving SBS. 1. 00 (Unknown Band Class is converted to binary) 2. 00000001001 (cell number 9 is converted to binary -> 1001) 3. 010 (Sector Y is converted to binary) 4. 0000 0000 0100 1010 (concatenated and converted each group to Heximal number) 5. 004A (Heximal number) = 74 (interger number) 6. Datafill 0x004A or 74 in the IntersystemCellId in the Pilot DataBase.

# # # # # # # # # # # # # # # # # # # # #

BeaconTargetCellIdList = ( 1, 0= ( ReferencePilot = 80, (must be datafilled with pilot PN of the serving cell) TargetCellIdList = ( 1, 0= ( MSCID = ( MarketId = 4190, (Target System MarketId, this value is get from table MSCIDRTE) SwitchNumber = 12 (Target System MarketId, this value is get from table MSCIDRTE) ), IntersystemCellId = 74 (Target Cell Number: 9Y, Hex 0x004A) ) ) ) ),

Now datafill the csc_number parameter of the SEGID field of the Table CDMAIMAP as follows.
TABLE: CDMAIMAP

SEGID

NWKCELL

---------------------------JFC455 9Y 521

52

10.2 Procedures to Datafill NWKCELL of Table CDMAIMAP

Assume that we have obtained the target cell/sector number and the definition of the 16 bit-format defining cell/sector number from other vendor. Lets say target cell number is 9Y and the 16 bit-format definition is: the first 8 bits is for sector number and the last 8 bits is for cell number.
Procedures 1. Write the Sector number in binary format (8 bits). 2. Write the BTS number in binary format (8 bits). 3. Concatenate the two binary numbers in the following format.

SSSSSSSS BBBBBBBB Where S = sector bits and B = Cell/BTS bits.

Example of conversion

1. 00000010 (Sector number 2 is converted to binary. It is required to fill in the other remaining bits as 0) 2. 00001001 (cell number 9 is converted to binary. It is required to fill in the other remaining bits as 0) 3. 0000001000001001 (concatenated) 4. 521 (converted to integer number) 5. Datafill 521 in the NWKCELL field of table CDMAIMAP

TABLE: CDMAIMAP

SEGID

NWKCELL

---------------------------JFC455 9Y 521 10.3 What Bit-format Structure For MTX CellId Datafilled in The Other NonNortel MSC When a mobile performs CDMA hard handoff from the other non-Nortel MSC to Nortel MTX (Inter-vendor CDMA to CDMA HHO), it is required to provide to the non-Nortel MSC the CellId either in binary number or in integer number that is mapped to Nortels CellId bit format so that the IS-41 C decoder in Nortel MTX can decode the CellId (that it receive) properly when the FACDIR2 message (including CellId and other information) is sent from non-Nortel MSC to Nortel MTX. For MTX9.0, the maximum MTX CDMA cell number is 2047. Therefore the new MSC CellId bit format needs to expand from 9 bits to 11 bits. Now the MSC CellId bit format (structure) is defined as in Figure 10.2

53

Figure 10.2: MTX CellId bit format (structure) defined in MTX9.0 The Binary mapping for sector name is described in Table 10.4
Table 10.4: Sector Name with Binary Mapping Sector Name Omni x y z u v w Binary mapping 000 001 010 011 100 101 110

10.3.1 Procedures to Convert Nortel Cell Number that Mapped to Nortel MTX CellId for MTX09 to Be Datafilled in Non-Nortel MSC

As mentioned in 10.3, for MTX09 the maximum MTX CDMA cell number is 2047. It is also mentioned that when a mobile performs CDMA hard handoff from the other nonNortel MSC to Nortel MTX (Inter-vendor CDMA to CDMA HHO), it is required to provide to the non-Nortel MSC the CellId either in binary number or in integer number that is mapped to Nortels CellId bit format so that the IS-41 C decoder in Nortel MTX can decode the CellId (that it receive) properly when the FACDIR2 message (including CellId and other information) is sent from non-Nortel MSC to Nortel MTX. This section provides two Cell Conversion methods: 1. Conversion using Manual method 2. Conversion using MTX CONVCELL tool

54

10.3.1.1

Conversion using Manual Method

Procedures 1. Write the BTS number in binary format (11 bits). 2. Use the sector bit format described in Table 10.4: Sector Name with Binary Mapping to write the BTS number in binary format (3 bits). 3. Concatenate the two binary numbers in the following 16-bit format.
Pos 15 Pos 14 Pos 13 Pos 12 Pos 11 Pos 10 Pos 9 Pos 8 Pos 7 Pos 6 Pos 5 Pos 4 Pos 3 Pos 2 Pos 1 Pos 0 Bit 15 Bit 14 Bit 13 Bit 12 Bit 11 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 X X S S S B B B B B B B B B B B

Where S = sector bits, B = Cell/BTS bits, and X = dont care (i.e., can be 0). 4. Now move Bit 9 and Bit 10 of the Cell/BTS Bits to the bit positions 12 and 13 and also move Bit 11, Bit 12, and Bit 13 of the Sector Bits to the bit positions 9, 10, and 11 as follows
Pos 15 Pos 14 Pos 13 Pos 12 Pos 11 Pos 10 Pos 9 Pos 8 Pos 7 Pos 6 Pos 5 Pos 4 Pos 3 Pos 2 Pos 1 Pos 0 Bit 15 Bit 14 Bit 13 Bit 12 Bit 11 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 X X S S S B B B B B B B B B B B

Pos 15 Pos 14 Pos 13 Pos 12 Pos 11 Pos 10 Pos 9 Pos 8 Pos 7 Pos 6 Pos 5 Pos 4 Pos 3 Pos 2 Pos 1 Pos 0 Bit 15 Bit 14 Bit 10 Bit 9 Bit 13 Bit 12 Bit 11 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 X X B B S S S B B B B B B B B B

5. Convert this 16-bit binary number to the integer number

Pos 15 Pos 14 Pos 13 Pos 12 Pos 11 Pos 10 Pos 9 Pos 8 Pos 7 Pos 6 Pos 5 Pos 4 Pos 3 Pos 2 Pos 1 Pos 0 Bit 15 Bit 14 Bit 10 Bit 9 Bit 13 Bit 12 Bit 11 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0 X X B B S S S B B B B B B B B B

We then provide this CellId in integer number value to the non-Nortel MSC service provider for datafilling in their system.
Note: The mentioned Cell Conversion procedures is applied for both cell number greater than 511 or less than 511. Example of conversion Figure 10.3 is used as an example for the CellId conversion. As described in Figure 10.3, a mobile IVHHO from Cell 9y to Cell 2047z so Cell 2047z is defined Nortel source cell and is defined as non-Nortel target cell. It is required to convert this cell 2047z to CellId in the integer-number format that is mapped to the correct Nortel definition bit format.

1. Convert 2047 to binary number (11 bits)

1 1 1 1 1 1 1 1 1 1 1

55

2. Use the sector bit format described in Table 10.4: Sector Name with Binary Mapping to convert sector z to binary number (3 bits)
0 1 1

3. Concatenate the two binary as follows

0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1

4. Move the Cell/BTS bits and Sector bits as described in the procedure. The results is as
0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1

result 0 0 1 1 0 1 1 1 1 1 1 1 1 1 1 1

5. Convert 0011011111111111 to the integer number. The result is 14335

DMS MTX Non-Nortel MSC

IS 41 C

DMS MTX Nortel DMS MTX

Other Vendor BSC

Nortel Networks BSC

Cell: 9y

Cell: 2047z

Figure 10.3: Inter-vendor Hard Handoff from non-Nortel MSC (source cell: 9y to Nortel MTX (target cell: 2047z, MTX09) 10.3.1.2 Conversion using MTX CONVCELL tool This MTX CONVCELL tool is applied for both cell number greater than 511or less than 511. The new CONVCELL tool interprets the input given by the user and uses the new algorithm to determine the correct Nortel MTX cell number integer. This number is used in IS41 messaging sent from a non-Nortel MSC to Nortel MTX. Procedures

56

Convert cell 2047z using MTX CONVCELL tool 1. At MXT CI level type convell. Example:
CI:

>>convcell 2. Then type help (help command shows all the commands associated to this tool) Example: >help 3. Then type cti (i.e., Convert cell To Integer) Example: >cti 4. Then enter 2047 z Example: >2047 z 5. The output will be The Target Cell Value: 14335
Entire Example Display: CI: >>convcell CONVCELL : Type HELP to see what you can do with CONVCELL !! >help CONVCELL : This tool converts a Nortel cell into an integer and an integer into a Nortel cell -------------------------------------------------------Available commands are: CONV_TO_INT (CTI) - Convert cell into integer CONV_TO_CELL (CTC) - Convert integer into cell Sector HELP - Display this list QUIT - Quit >cti Next par is: <ENTER CELL NUMBER> {0 TO 2047} Enter: <ENTER CELL NUMBER> <ENTER SECTOR> >2047 z The Target Cell Value: 14335

10.3.2 Restriction and limitations

1. The maximum number of cells supported for A-interface, AMPS and TDMA remains 511. 2. The number of CDMA sectors per cell is not being increased. The maximum number of CDMA sectors per cell remains 3.

57

3. Backwards Compatibility: Networking to/from MTX09 from/to a non-Upgraded MTX08 load: Cell numbers must remain less than 512 when deploying IS-41 hard handoff.

11.0 Hard Handoff Troubleshooting Tips

This section provides some troubleshooting for hard handoff issues that are encountered most of the time when deploying hard handoff. From field experiences, most hard handoff-related issues have been traced to one of the following issues. 1. Incorrect datafill 2. Poor RF coverage control 3. Poor hard handoff trigger point planning
11.1 Hard Handoff Trigger but Mobile Not Received Hard Handoff Direction Message The following problems can be happened when the source SBS triggers the hard handoff but a mobile involving in IS-41 intersystem/inter-vendor hard handoff does not receive ExtendedHandoffDirection message for CDMA to CDMA or AnalogHandoffDirection message for CDMA to AMPS. The following things can happen.

1. IS-41 message format mismatch The IS-41 message format datafilled on the source system must match the message format datafilled on the target system. A message format mismatch will cause the intersystem handoff to fail, but this event will not generate a log. What it means if source system MSC uses IS41C message format then the target system MSC must use IS41C message format. IS-41 message format is defined in Table SYSCON (Nortel Networks system).
Datafill Sample of Table SYSCON of Nortel Networks Switch
Table: SYSCON RTENO RTENAME LINKDATA MSGFMT LOCALNET QUALREQ IHODATA -----------------------------------------------------6 JFC455 TCAP_LINK ANSI7 214 150 10 IS41C DEFAULT Y N Y Y MH0755HHO 255

255

2. Wrong Route Name Datafill in Table SYSCON and Table MSCIDRTE If the target RTENAME (Route Name) is datafilled with wrong value, the IS-41 FACILITYDIRECTIVE2 message may be sent from source MSC to the wrong target MSC or may not be sent. Thus the mobile never receives The ExtendedHandoffDirection Message or AnalogHandoffDirection Message
Sample of Table MSCIDRTE
TABLE: MSCIDRTE >list all

58

TOP FRMMSCID TOSID TOSWTCH RTENAME NWKOPTNM TTORIG TTSERV -------------------------------------------------------------4190 12 4190 12 JFC455 DEFAULT NIL NIL LUCENT

3. IS-41 data link protocol mismatch The source system MSC and the target system MSC must be configured with the same IS-41 data link protocol. What it means if source system MSC is configured with MSC X.25 data link protocol then the target system MSC must be configured with MSC X.25 data link protocol. AIS-41 data link protocol mismatch will cause the intersystem handoff to fail since the source and the target system MSCs use one of the two data link protocols (X.25 or SS7) for communicating. X.25 is based on input/output controller (IOC) high-level data link control (HDLC) modem hardware. SS7 (Signaling System number 7) protocol is based on link peripheral processor (LPP) hardware. Consult reference [8] for troubleshooting on this issue. 3. Wrong PBD Target Cell Id datafill If the IntersystemCellId of the target cell list of a serving sector involving in hard handoff is datafilled with wrong cell number as a result of wrong cell number conversion or wrong cell number information, the ExtendedHardHandoffDirection message or AnalogHardHandoffDirection message will deliver to the wrong target cell or will not be delivered.
Sample Segment of Target Cell List of the serving cell/sector PDB entries
BorderRefPilotRTDThresh = 721, BorderTargetCellIdList = ( 1, 0 = ( MSCID = ( MarketId = 4190, (Target System MarketId, this value is get from table MSCIDRTE) SwitchNumber = 12 (Target System SwitchNumber, this value is get from table MSCIDRTE) ), IntersystemCellId = 76 0x004A) ) ), (Target Cell Number: 9 Y, Hex

4. Wrong target MarketId and SwitchNumber datafill If the target MarketId and the SwithchNumber of the target cell list of a serving sector involving in hard handoff is datafilled with wrong MarketId and wrong SwithchNumber, the ExtendedHardHandoffDirection message or
59

AnalogHardHandoffDirection message may deliver to the wrong target switch or will not be delivered. The 5. Wrong target NWECELL datafill of table CDMAIMAP If the RTENME subfield of the SEGID field is datafilled with wrong target route name and the NWKCELL field is datafilled with wrong target cell number or with wrong target cell number conversion, the mobile will not receive the ExtendedHandoffDirection message (CDMA to CDMA) or AnalogHandoffDirection message (CDMA to AMPS)
Sample of Table CDMAIMAP TABLE: CDMAIMAP

SEGID

NWKCELL

---------------------------JFC455 9Y 521

6. Detail Network Errors Consult reference [8] IS-41 Overview and Implementation (Course 0884), if detail Network errors occurs Note: Ensure that all the required handoff patches are applied and activated on
11.1.1 Sample of CATRLM_RLMIntersystemHandoffInd NOIS Message Below is the sample of CATRLM_RLMIntersystemHandoffInd NOIS message that is from SBS selectorsubsystem log. Note: Ensure that a CATRLM_RLMIntersystemHandoffInd NOIS message is logged on the source system.

The following is an example of a CATRLM_RLMIntersystemHandoffInd message:

Status : OLFLR_OK Record Type : OCC_OUTBOUND_NOIS File Offset : 11563 (octal) Time Stamp : 97/03/14-03:15:24.320 Record Length : 93 Header Length : 34 Source Node Id : 297539 (0x00048a43) Source Port Id : 11105 (0x2b61) Destination Node Id : 15992576 (0x00f40700) Destination Port Id : 12296 (0x3008) Call Id : SID 0x4e4 EntryPoint 0x1008 Count 0x0 Time 0x4140136 PFFlags : 0x03 Secondary Agent Id : 0x8a40 FramingBytes : 0xfaae Sequence Number : 145 LogData object contents: Data Type : OCC_OUTBOUND_NOIS Resource Type : OCC_SBS_RESOURCE TimeStamp : 97/03/14-03:15:24.320 Source Node Id : 297539 (0x48a43) Source Port Id : 11105 (0x2b61) Destination Node Id : 15992576 (0xf40700)

60

Destination Port Id : 12296 (0x3008) MSG_NAME: CATRLM_RLMIntersystemHandoffInd CATRLM_RLMIntersystemHandoffInd 6007 [ LVN 1 MLVN 1 NOIMSG_DISCARD Token 0 ] {SessionId SessionId 0x0017 { SessionId 0xab0058 } CellId CellId 0x01a9 { CellId 0x81 Word16 OneWayDelay 0x0050 { Value 0xb9 } BAND_CLASS BAND_CLASS 0x01a6 { BAND_CLASS ACLPAINF_BAND_18_20_PCS } CDMA_FREQ CDMA_FREQ 0x0082 { CDMA_FREQ 0xe1 } FRAME_OFFSET FRAME_OFFSET 0x0069 { FRAME_OFFSET 0xe } LongCodeMask LongCodeMask 0x0075 {LongCodeMask Hi 792 Lo 2300576914 }TargetCellList TargetCellList 0x01d6 { Count 0x1 TargetCell MarketID 0x4f2 SwitchNumber 0x14 CellId 0x91 OneWayDelay 0xb9PilotStrengt } }

11.1.2 Sample of ExtendedHandoffDirection message Below is a sample of ExtendedHandoffDirection message that is from mobile log and is parsed by using Nortel Networks RFO tool (RF Optimization Tool). Note: the Hard_Included field of this message should indicate a 1 if the handoff is hard handoff. The Hard_Include field should indicates a 0 if the handoff is soft/softer handoff type.

11.2 Hard Handoff Delay Hard handoff Delay can be caused by two main reasons as follows.

1. Call origination or termination is setup at the location exceeding the Hard Handoff Threshold set point. Figure 11.1 depicts this scenario.

61

If a call origination or termination is setup at the location exceeding the Hard Handoff Threshold set point, the hard handoff process will be delayed. Figure below depicted this scenario. The reason is that the CAU will ignore the CATRLM_RLMIntersystemHandoffInd (hard handoff trigger message) if the call processing set up has not been completed. When a hard handoff is triggered, the SBS sends CATRLM_RLMIntersystemHandoffInd message to the CAU and the timer starts. If the serving SBS does not receive the response from the CAU after the timer is expired, the serving SBS resend the CATRLM_RLMIntersystemHandoffInd message. The timer is defined by the IntersystemSystemResponseTimeout in Selectorsubsystem MO, which is the amount of time that the selector will wait for the CAU to respond after sending the CATRLM_RLMIntersystemHandoffInd message. The standard datafill value is 120000000 (i.e., 12 seconds0. The unit of this value is in microsecond. Thus hard handoff overlap coverage should be large enough to overcome this problem. 2. Round Trip Delay (RTD) Trigger problem If the mobile does not release a non-border sector from the active set, the RTD hard handoff trigger will not be triggered. Please refer to section 3.2.2 RTD Trigger Delay Due To Pilot Pollution for more information on how to fix this problem.
Equal Power Level
Serving Sector with Nortel DMS-MTX Target Sector with third vendor MSC

Call origination or termination established at location exceeding hard handoff set point. Trigger set point and pingpond preventing set point from source sector

Cell Edge

Figure 11.1: Call origination or termination is setup at the location exceeding the Hard Handoff Threshold set point 11.3 Hard Handoff Drop due to Search_Win_A Too Narrow Sometimes, it is due to the RF geographic conditions, the hard handoff trigger set points between source and target cells have to set with a great distance (lets say a delta of 5
62

Km). If the Search_Win_A is set too narrow, lets say set to 5 (i.e, +/- 10 chips or 2.5 Km), then the hard handoff may be dropped due to mobile can not change its system time fast enough.

63

12.0 Glossary
ACE A Control Elememt ACN - Application Communication Network AIF - A Interface ASU - Application Specific Unit AMPS - Advanced/Analog Mobile Phone System BCN - Base Station Communications Network BSC - Base Station Controller BSM - Base Station Manager BTS - Base Transceiver Station CAT - Call Transaction Processor CAU - CDMA Application Unit CCLN - CDMA Cellular Land Network CDMA - Code Division Multiple Access CIS - CDMA Interconnect System CI - Command Interpreter CIU - CDMA Interface Unit CRM - Call Resource Manager DSP - Digital Signal Processor EIM - External Interface Manager EHHO - Enhanced Hard HandOff FER - Frame Erasure Rate GRR - Global Resource Register HDLC - High Data Link Control ICP - Intelligent Cellular Peripheral IHM - Intersystem Handoff Manager IOS Inter Operability Stability MDL - Message Definition Library MSC - Mobile Switching Center NOIS - Network Operations Interface Specification OCM - Overhead Channel Manager PAM - Paging and Access Manager PCM - Power Control Management PDB - Pilot Data Base PDL - Parameter Definition Library PSMM - Pilot Strength Measurement Message RLM - Radio Link Manager RLS - Radio Link Services RSR - Reverse Signalling Router RTD - Round Trip Delay SBS - Selector Bank Subsystem SBSC - SBS Controller SCI - Selector Common Interface SE - Selector Element SEC - Selector Element Controller
64

SES - Selector Element Subsystem. SOP - Service option processors SOM - Service Option Manager SRM - Selector Resource Manager SS7 - Signaling System #7 TCE - Traffic Channel Element TPU - Traffic Processing Unit

65