ip backhaul

Flexent® Wireless NetworksIP Backhaul for CDMA Voice and Packet Data

Release 26.0401-710-090

Issue 3March 2006

Lucent Technologies - ProprietaryThis document contains proprietary information of Lucent Technologies and

is not to be disclosed or used except in accordance with applicable agreements.

Copyright © 2006 Lucent TechnologiesUnpublished and Not for Publication

All Rights Reserved

See notice on first age

This material is protected by the copyright and trade secret laws of the United States and other countries. It may not be reproduced,distributed, or altered in any fashion by any entity (either internal or external to Lucent Technologies), except in accordance with applicableagreements, contracts or licensing, without the express written consent of Lucent Technologies and the business management owner of thematerial.

Trademarks

All trademarks and service marks specified herein are owned by their respective companies.

See notice on first age

Lucent Technologies - ProprietarySee notice on first page

Contents

About this information product

Purpose...............................................................................................................................................................................................................xvxv

Reason for reissue.......................................................................................................................................................................................xvxv

Safety information.....................................................................................................................................................................................xvixvi

How to use this information product.............................................................................................................................................xvixvi

Conventions used....................................................................................................................................................................................xviixvii

Related information products...........................................................................................................................................................xviiixviii

Documentation, training and support.............................................................................................................................................xixxix

How to comment..........................................................................................................................................................................................xxxx

1 Introduction to IP Backhaul

IP Backhaul

Overview .........................................................................................................................................................................................................1-11-1

IP Backhaul features.................................................................................................................................................................................1-21-2

Availability .....................................................................................................................................................................................................1-41-4

Prerequisites...................................................................................................................................................................................................1-51-5

IPBH documentation roadmap...........................................................................................................................................................1-91-9

Benefits of IP Backhaul......................................................................................................................................................................1-131-13

IPBH network architecture................................................................................................................................................................1-191-19

IPBH traffic ...............................................................................................................................................................................................1-251-25

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


iii

2 IP Backhaul network overview

Overview .........................................................................................................................................................................................................2-12-1

Reference Diagram....................................................................................................................................................................................2-22-2

Base transceiver station..........................................................................................................................................................................2-42-4

Backhaul routers and switches...........................................................................................................................................................2-62-6

Radio cluster server...............................................................................................................................................................................2-102-10

5ESS DCS....................................................................................................................................................................................................2-122-12

Radio network controller (1X RNC)...........................................................................................................................................2-152-15

User traffic protocols............................................................................................................................................................................2-202-20

Signaling traffic protocols..................................................................................................................................................................2-222-22

DS1s in IPBH............................................................................................................................................................................................2-242-24

Backhaul server assignment and PSU2e/1X RNC engineering..................................................................................2-252-25

IP Addressing.............................................................................................................................................................................................2-272-27

3 IP Backhaul implementation

Overview .........................................................................................................................................................................................................3-13-1

Implement and build the IPBH network

Implementation of IPBH ......................................................................................................................................................................3-33-3

Pre-conversion: Install IP network..................................................................................................................................................3-63-6

IPBH network elements checklist....................................................................................................................................................3-93-9

Pre-conversion: Prepare 5ESS DCS for IPBH

Overview .......................................................................................................................................................................................................3-133-13

Prepare 5ESS DCS for conversion...............................................................................................................................................3-143-14

Pre-conversion: Prepare 1X RNC for IPBH

Overview .......................................................................................................................................................................................................3-173-17

1X RNC implementation overview..............................................................................................................................................3-183-18

Install IPBTS Gateway........................................................................................................................................................................3-203-20

Contents

.................................................................................................................................................................................................................................

iv Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

Pre-conversion: Prepare FMM-AP and RCS for IPBH

Overview .......................................................................................................................................................................................................3-323-32

FMM-RCS implementation...............................................................................................................................................................3-333-33

Provisionecp form ..............................................................................................................................................................................3-343-34

Configure FMM-RCS IP Integrity Manager.........................................................................................................................3-373-37

Provisionapeqp form ..........................................................................................................................................................................3-383-38

Retrieve Backplane Serial Number (BPSN)...........................................................................................................................3-413-41

Provisioncell2 form ..............................................................................................................................................................................3-443-44

Provisioncdmeqp form ......................................................................................................................................................................3-493-49

Provisionbtseqp form ........................................................................................................................................................................3-503-50

Post deployment

Post deployment activities.................................................................................................................................................................3-513-51

Delete DS1/DS0s used with FR-based FMM-RCS............................................................................................................3-523-52

4 OA&M for IP Backhaul

Overview .........................................................................................................................................................................................................4-14-1

Routers and switches

Router/switch OA&M ...........................................................................................................................................................................4-24-2

BTS OA&M

BTS OA&M for IPBH ...........................................................................................................................................................................4-34-3

MSC

FMM-AP OA&M .......................................................................................................................................................................................4-54-5

1X RNC OA&M ........................................................................................................................................................................................4-64-6

5ESS DCS OA&M.................................................................................................................................................................................4-114-11

ECPC OA&M ............................................................................................................................................................................................4-214-21

Input/Output commands and messages.................................................................................................................................... 4-294-29

Status display pages...............................................................................................................................................................................4-384-38

Contents

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


v

OMC-RAN

Monitor IPBH from the OMC-RAN ......................................................................................................................................... 4-484-48

5 Fault management

Overview .........................................................................................................................................................................................................5-15-1

Network monitoring

Fault management......................................................................................................................................................................................5-35-3

General problem solving model........................................................................................................................................................5-55-5

Network monitoring and fault detection...................................................................................................................................... 5-75-7

Sample section: Identified fault......................................................................................................................................................5-105-10

Cable faults

DS1 (T1/E1) cable cut.........................................................................................................................................................................5-145-14

DS1 (T1/E1) cable cut.........................................................................................................................................................................5-175-17

DS1 (T1/E1) cable cut.........................................................................................................................................................................5-205-20

Bad DS1 cable..........................................................................................................................................................................................5-245-24

Cable cut/disconnected between ER and MLS.....................................................................................................................5-275-27

Cable cut on serving IPBTS GW GigE interface - Standby GigE in-service...................................................5-305-30

Cable cut on non-serving IPBTS GW GigE interface.....................................................................................................5-345-34

Cable cut on serving IPBTS GW GigE interface - Standby GigE out-of-service..........................................5-375-37

Cable cut on serving IPBTS GW GigE interface...............................................................................................................5-415-41

Communication faults

IPGW0 is unreachable..........................................................................................................................................................................5-455-45

IPGW1 is unreachable..........................................................................................................................................................................5-485-48

Duplex IPGW access failures..........................................................................................................................................................5-515-51

Only remaining 5E GW goes OOS..............................................................................................................................................5-555-55

No 1st Hop router connectivity......................................................................................................................................................5-595-59

No Ethernet connectivity....................................................................................................................................................................5-635-63

Contents

.................................................................................................................................................................................................................................

vi Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

No 1st Hop router connectivity......................................................................................................................................................5-665-66

No Ethernet connectivity....................................................................................................................................................................5-705-70

Edge router card failure affecting all associated DS1 interfaces.............................................................................5-735-73

Software and configuration faults

BER major threshold crossed..........................................................................................................................................................5-765-76

Active RCS IP goes OOS-F while mate AP is OOS-F...................................................................................................5-795-79

One DS1 in MLG is not configured in ER, or wrong DS1 is assigned to MLG in ER............................5-835-83

Edge router card failure affecting all associated DS1 interfaces.............................................................................5-865-86

6 IPBH performance measures

Service measurements

Overview .........................................................................................................................................................................................................6-16-1

SM for IPBH ................................................................................................................................................................................................6-26-2

5ESS measurement reports...................................................................................................................................................................6-66-6

5ESS DCS TRFM for IPBH...............................................................................................................................................................6-96-9

7 Safety and general information

Overview .........................................................................................................................................................................................................7-17-1

Hazard statements

Overview .........................................................................................................................................................................................................7-27-2

Structure of hazard statements...........................................................................................................................................................7-37-3

General hazard statements....................................................................................................................................................................7-57-5

Glossary

Index

Contents

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


vii

List of tables


1-1 Related network features.....................................................................................................................................................1-31-3

1-2 Network elements in an IPBH network and required changes....................................................................1-61-6

1-3 Document Roadmap of IPBH tasks..............................................................................................................................1-91-9

1-4 Differences between FR and IPBH............................................................................................................................1-141-14


2-1 Router and switch documentation resources...........................................................................................................2-62-6

2-2 Bearer traffic protocols for IPBH network............................................................................................................2-202-20

2-3 Signaling traffic protocols for IPBH network.....................................................................................................2-222-22

2-4 IPBH component IP addressing.................................................................................................................................... 2-272-27


3-1 Phases of IPBH implementation..................................................................................................................................... 3-33-3

3-2 FR to IPBH implementation functions.......................................................................................................................3-43-4

3-3 IPBH new hardware requirements checklist for an existing network.....................................................3-93-9

3-4 IPBH cabling requirements checklist........................................................................................................................3-103-10

3-5 IPBH software requirements checklist.....................................................................................................................3-103-10

3-6 IPBH component IP addressing.................................................................................................................................... 3-113-11

3-7 AP VLAN checklist .............................................................................................................................................................3-113-11

3-8 BHS VLAN IP checklist...................................................................................................................................................3-123-12

3-9 ecp form-IPBH fields .........................................................................................................................................................3-343-34

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


ix

3-10 apeqp form-IPBH fields ...................................................................................................................................................3-383-38

3-11 cell2 form-IPBH fields ......................................................................................................................................................3-443-44

3-12 cdmeqp form-IPBH fields ..............................................................................................................................................3-493-49

3-13 btseqp form-IPBH fields .................................................................................................................................................3-503-50


4-1 Modified 1X RNC I/O commands................................................................................................................................ 4-94-9

4-2 Recent Change Views for 5ESS DCS (NAR and INTL).............................................................................4-124-12

4-3 New inputs by interface....................................................................................................................................................4-304-30

4-4 Modified inputs .....................................................................................................................................................................4-314-31

4-5 New outputs..............................................................................................................................................................................4-334-33

4-6 Modified outputs ..................................................................................................................................................................4-344-34

4-7 5ESS DCS inputs and outputs...................................................................................................................................... 4-364-36

4-8 New and modified SDP pages for IPBH................................................................................................................4-384-38

List of tables

.................................................................................................................................................................................................................................

x Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

List of figures


1-1 Current backhaul network................................................................................................................................................1-161-16

1-2 Typical IP Backhaul network with 5ESS DCS/PSU2e..................................................................................1-171-17

1-3 Typical IP Backhaul network with 5ESS DCS/PSU2e and 1X RNC..................................................1-181-18

1-4 IPBHNetwork ..........................................................................................................................................................................1-191-19

1-5 IPBH architecture..................................................................................................................................................................1-211-21


2-1 IP Backhaul network reference diagram....................................................................................................................2-22-2

2-2 IPBH network topology.......................................................................................................................................................2-72-7

2-3 RCS signaling conversion: simplified view..........................................................................................................2-112-11

2-4 5ESS Switch packet handlers in PSU2e.................................................................................................................2-122-12

2-5 IPBTS GW Sparing.............................................................................................................................................................2-162-16

2-6 1X RNC shelf configuration for IP Backhaul.....................................................................................................2-182-18

2-7 1X RNC BHS processes...................................................................................................................................................2-192-19

2-8 Bearer traffic protocol stacks......................................................................................................................................... 2-202-20

2-9 Signaling traffic protocol stacks................................................................................................................................. 2-222-22


3-1 IPBH network topology.......................................................................................................................................................3-63-6

3-2 5ESS DCS provisioning for IPBH.............................................................................................................................3-153-15

3-3 1X RNC provisioning for IPBH.................................................................................................................................. 3-183-18

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


xi


4-1 RNC Configuration Data...................................................................................................................................................4-74-7

4-2 BHS Level IPBH Parameters......................................................................................................................................... 4-84-8

4-3 RNC Level IPBH Parameters screen...........................................................................................................................4-94-9

4-4 RC View 22.32 (NAR): Protocol Handler Group Definition 1 of 4.....................................................4-134-13




4-8 RC View 33.1 (NAR): IP Processor Assignment 1 of 3..............................................................................4-154-15

4-9 RC View 33.1 (NAR): IP Processor Assignment 2 of 3..............................................................................4-154-15

4-10 RC View 33.1 (NAR): Internet Protocol (IP) Processor Assignment 3 of 3...................................4-164-16

4-11 RC View 33.3 (NAR): IP Processor Routing to Interface...........................................................................4-164-16

4-12 RC View 33.4 (NAR): IP Interface Assignment 1 of 2................................................................................4-164-16

4-13 RC View 33.4 (NAR): Ethernet IP Interface Assignment 2 of 2............................................................4-174-17

4-14 RC View 9.37 (INTL): Protocol Handler Group Definition 1 of 2.......................................................4-184-18

4-15 RC View 9.37 (INTL): Protocol Handler Group Definition 2 of 2.......................................................4-184-18

4-16 RC View 90.5 (INTL): IP Processor Assignment 1 of 2.............................................................................4-194-19

4-17 RC View 90.5 (INTL): IP Processor Assignment 2 of 2.............................................................................4-194-19

4-18 RC View 90.6 (INTL): IP Processor Routing to Interface..........................................................................4-204-20

4-19 RC View 90.7 (INTL): IP Interface Assignment.............................................................................................4-204-20

4-20 RC/V form: ecp......................................................................................................................................................................4-224-22

4-21 RC/V form: btseqp .............................................................................................................................................................4-234-23

4-22 RC/V form: btseqp .............................................................................................................................................................4-244-24

4-23 RC/V form: cell2 ...................................................................................................................................................................4-254-25

4-24 RC/V form: cell2 ...................................................................................................................................................................4-264-26

4-25 RC/V form: cdmeqp ..........................................................................................................................................................4-274-27

4-26 RC/V form: apeqp................................................................................................................................................................4-284-28

List of figures

.................................................................................................................................................................................................................................

xii Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

4-27 SDP 2101....................................................................................................................................................................................4-404-40

4-28 SDP 2131....................................................................................................................................................................................4-414-41

4-29 SDP 2138....................................................................................................................................................................................4-424-42

4-30 Status display page: 2236.................................................................................................................................................4-434-43

4-31 Status display page: 2237.................................................................................................................................................4-444-44

4-32 SDP 2260....................................................................................................................................................................................4-454-45

4-33 SDP 2265....................................................................................................................................................................................4-464-46

4-34 5ESS-DCS PHGRP status page: MCC 1188.......................................................................................................4-474-47

4-35 OMC-RAN BTS Overview -server=Lab# ......................................................................................................4-494-49

4-36 OMC-RAN Network Manager - IPBH Enabled information....................................................................4-504-50

4-37 OMC-RAN Network Manager - IPBH SocList.................................................................................................4-514-51

4-38 OMC-RAN Network Manager - IPBH BPSN....................................................................................................4-524-52

4-39 OMC-RAN Network Manager - IPBH BPSN....................................................................................................4-534-53

5 Fault management

5-1 Network monitoring ...............................................................................................................................................................5-75-7

6 IPBH performance measures

6-1 5E DCS traffic measurement report for IPBH......................................................................................................6-96-9

6-2 IPBHSUP report, section 153........................................................................................................................................ 6-106-10

List of figures

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


xiii

About this information productAbout this information product

Purpose

This document describes the IP Backhaul for CDMA Voice and Packet Data (IPBackhaul) optional feature for 3G1X CDMA in Lucent TechnologiesFlexent®/AUTOPLEX® wireless networks.

Reason for reissue

This issue of this document (Issue 3, March 2006), supersedes Issue 1 (December2005). Issue 2 was an Lucent Technologies internally available document in support ofRelease 25.01 (January 2006).

This issue provides the following new and changed information:

• Addition of Release 25.01 features and information:

– FID 10665.16: BTS conversion from LAPD to IPBH, an optional feature that isdescribed inFlexent®/Autoplex® Wireless NetworksBTS conversion from LAPDto IPBH, 401-612-841.

– Modifications to the following sections that have been replaced by theBTSconversion from LAPD to IPBH,401-612-841: Pre-conversion and Conversionsections. SeeChapter 3, “IP Backhaul implementation”.

• Features in Release 26.0 for North American Region (NAR) and International(INTL) markets:

– FID-10665.1: IP Backhaul for CDMA (99-5E-8530): This feature delivers the5ESS functionality for FID-10665.0 that was delivered in Release 25.0 andincludes updated document references to 5ESS DCS international documents.

– FID 10665.11: IPBH Fault Management Scenarios for IPBH. SeeChapter 5,“Fault management”.

• Addition of a road map to all generally available Lucent Technologies productdocuments that support IPBH. See“IPBH documentation roadmap” (p. 1-9).

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006,


xv

Safety information

This information product contains hazard statements for your safety. Hazard statementsare given at points where safety consequences to personnel, equipment, and operationmay exist. Failure to follow these statements may result in serious consequences.

How to use this information product

The following table briefly describes each chapter and its contents:

Chapter Description

Chapter 1, “Introduction to IP Backhaul” This chapter describes thefeatures that make up IPbackhaul and gives a briefoverview of the feature.

Chapter 2, “IP Backhaul network overview” This chapter provides a lookat the IP backhaul networkand its components.

“Implementation of IPBH ” (p. 3-3) This chapter providesinformation about deploymentof IP backhaul.

Chapter 4, “OA&M for IP Backhaul” This chapter providesinformation about OA&Mactivities for the networkelements in support of IPbackhaul.

Chapter 5, “Fault management” This chapter providestroubleshooting informationfor the IPBH network.

Chapter 6, “IPBH performance measures” This chapter providesinformation about performanceand capacity measurements forIP backhaul.

Chapter 7, “Safety and general information” This chapter provides safetyand hazard information.

Glossary The glossary contains a list ofterminology, acronyms andtheir expansions andabbreviations.


.................................................................................................................................................................................................................................

xvi Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

,

Conventions used

The following conventions are used in this document:

Typographic conventions

This information product presents different types of information in different typefacesto emphasize the nature of the information:

• Literal user input:Keystrokes that are entered character by character exactly asshown in the text appear in monospace type.For example:Enter the following command:apappconfig

• Variable user input:Input values that vary from one execution or instance toanother appear in monospace italic type.For example:cd directorywhere directory = the directory to which to change.

• Literal system output:The names of files, directories, forms, messages, and otherinformation that a system outputs exactly as shown in the text appear in monospacetype.For example:RST SPA=cnam REQUEST ACKNOWLEDGED

• Variable system output:Values that vary from one instance to another in systemoutput appear in monospace type.For example:RST SPA=SPA_NAME REQUEST COMPLETEDwhereSPA_NAME = the name of the Service Package Application (SPA) that issuccessfully restored.

• Key names:The names of keys on a terminal keyboard are indicated by boldletters.For example:Press theF4 (Enter Query) function key.

• Key symbols:The Crtl (Control) key is signified by the caret ( ^ ) symbol. Whenthe ^ symbol precedes the name of another key (as in^e), press theCrtl key andthe other key simultaneously.

• Variable information:Variable data to be entered is identified in monospace type.For example:URCm wherem represents a different type of universal radio control cell.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006,


xvii

Actions for user input

In this information product, the following words specify what action you shouldperform to input data or execute commands:

• The wordentermeans to key in the specified keystrokes (such as a command) andthen press theEnter or Returnkey.For example:Enter the following command:apappconfig

• The wordpressmeans to push down the specified key or keys on the keyboard.For example:Press theF4 (Enter Query) function key.

• The wordtypemeans to key in the specified keystrokes (such as a value in thefield of a form) without pressing theEnter or Returnkey.For example:In the IP address field, type the IP address of the host server.

Related information products

Documentation for Flexent® wireless network products is available in both hardcopyand CD-ROM formats. For descriptions of available documentation, see theFlexent®/AUTOPLEX® Wireless Networks Customer Documentation Catalog(401-610-000).

Documentation

The following documents are either referenced in this document or contain informationthat is related to topics that are covered in this document:

• 5ESS® Switch Flexent®/Autoplex® Wireless NetworksApplications Manual,NAR235-200-100.

• 5ESS® Switch Flexent®/Autoplex® Wireless Networks ApplicationsInput/OutputMessages,235-600-700/750.

• 5ESS® Switch Flexent®/Autoplex® Wireless Networks ApplicationsApplicationsOA&M Manual,5AP

• Flexent®/Autoplex® Wireless NetworksSystem Capacity Monitoring andEngineering Guidelines,401-610-009.

• Flexent®/Autoplex®Wireless NetworksDatabase Update Manual,401-610-036.

• Flexent®/Autoplex® Wireless NetworksInput Messages Manual,401-610-055.

• Flexent®/Autoplex® Wireless NetworksOutput Messages Manual,401-610-057.

• Flexent®/Autoplex® Wireless NetworksService Measurements,401-610-135.

• 5ESS® Switch Flexent®/Autoplex® Wireless Networks Applications5MM -Measurements Manual


.................................................................................................................................................................................................................................

xviii Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

,

• Flexent®/Autoplex® Wireless NetworksECP OA&M and SDP Maintenance ControlProcedures,401-610-160.

• Flexent®/Autoplex® Wireless NetworksBTS conversion from LAPD to IPBH,401-612-841.

• Flexent®/Autoplex® Wireless NetworksOperations and Maintenance Center RadioAccess Network (OMC-RAN) Operations, Administration, and Maintenance(OA&M), 401-662-105.

• Flexent® Wireless Networks Radio Cluster Server (RCS)FMM-RCS OA&M,401-710-102.

• Flexent® Wireless Networks CDMA 1X Radio Network Controller (RNC)Operations, Administration, & Maintenance,401-710-082.

• Flexent®CDMAModular Cell 4.0 and Compact Modular Cell 4.0 Operations,Administration and Maintenance,401-703-407

• Flexent® CDMAModular Cell 1.0, 2.0, 3.0 and Compact Modular Cell 3.0Operations, Administration and Maintenance,401-710-122

Documentation, training and support

The 401-010-001Flexent®/Autoplex® Wireless Networks Systems DocumentationCD-ROM and web site provides the following link to an information document: Toobtain documentation, training, and technical support or send feedback document.

That information document explains how to:

• obtain technical support.

• register as an authorized user of the Lucent Technologies customer technicalsupport web site.

• access the most current AMPS/PCS and related 5ESS® Digital Cellular Switch(DCS) documentation on the site.

• order system and product documentation.

• order training products or register for classroom training courses.

• submit comments and feedback about documentation and training.

For technical support

For technical support, contact your local customer support team. You can reach themvia the web at https://support.lucent.com or the telephone number listed under theTechnical Assistance Center menu at http://www.lucent.com/contact/.

For technical support, call the following numbers:

• From the USA: 1-866-LUCENT8 (1-866-582-3688)

• From all other countries: 1-630-224-4672

Please be prepared to describe the specific problem in your network. An operator willeither transfer your call directly to a customer technical support representative or


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006,


xix

forward your request to a representative, who will return your call as soon as possible.Service-affecting situations are always handled immediately.

How to comment

To comment on this information product, go to theOnline Comment Form(http://www.lucent-info.com/comments/enus/) or email your comments to theComments Hotline ([email protected]).


.................................................................................................................................................................................................................................

xx Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

,

http://www.lucent-info.com/comments/enus/

http://www.lucent-info.com/comments/enus/

1 1Introduction to IP Backhaul

IP Backhaul

Overview.................................................................................................................................................................................................................................

Purpose

This document describes the CDMA technology IP Backhaul offer that is availablefrom Lucent Technologies. It provides an overview of IP Backhaul and the IP Backhaulnetwork, provides implementation requirements and describes the implementation stepsthat are needed. In addition OA&M functions and processes needed for IPBH aredescribed and performance information about a Lucent Technologies IP Backhaulnetwork are provided.

Internet Protocol (IP) is the standard protocol that forms the basis of the Internet asdefined by the Internet Engineering Task Force (IETF). IP works in networks withnumerous and varied types of hardware and software, and it allows full peer-to-peercommunications between any nodes in the network. Backhaul is the means by whichthe base transceiver stations (BTSs) connect to the mobile switching center (MSC).

Contents

IP Backhaul features 1-2

Availability 1-4

Prerequisites 1-5

IPBH documentation roadmap 1-9

Benefits of IP Backhaul 1-13

IPBH network architecture 1-19

IPBH traffic 1-25

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-1

IP Backhaul features.................................................................................................................................................................................................................................

IP Backhaul FIDs

IP Backhaul was introduced initially in ECP Release 25.0. The individual featureidentifiers (FIDs) that comprise the IP Backhaul offer are listed by release.

• Release 26.0 features

– FID-10665.10: Satellite Satellite RCS AP support for IPBH: This featureprovides IPBH support on Satellite RCS for the 5th slot in the FMM-APplatform.

– FID-10665.1––IP Backhaul for CDMA (99-5E-8530): This feature delivers the5ESS DCS functionality for FID-10665.0 that was delivered in Release 25.0.

– FID-10665.2: IPBH for CMD for INTL Mkt

– FID-10665.6: PHE3 for IP Backhaul (5E INTL)

– FID-10665.7: VPN connection support for RMT Laptoop at TS via IPBH

– FID-10665.9: MLG Sharing in signaling traffic: This feature enables thesignaling traffic to be rerouted to another MLG in a different URC in the caseof the serving MLG’s failure.

– FID-10665.11: IPBH Fault Management: IPBH OA&M Fault Managementscenarios for an IPBH network.

– FID-12143.2: Cell Reliability and Engineering Improvements for IPBH RCSAPs

• Release 25.0 features

– FID 10666.1––IP Backhaul for CDMA Modular Cell 1.0/2.0/3.0/4.0 (Cell, ECPand 5E Development) uses the following FIDs:FID 10665.0/10666.0––IPBackhaul for CDMA (Modular Cells 1, 2, 3): Supports IP Backhaul between thebase transceiver station (BTS) and the mobile switching center (MSC) forCDMA technology applications, is activated through a feature activation file(FAF).

– FID 10665.1––Backhaul for CDMA (99-5E-8530): This feature supports IPBackhaul in the 5ESS DCS in support of FID 10665.0/FID10666.0.

– FID 10665.16––IPBH: BTS Conversion from LAPD to IPBH: This feature wasavailable in Release 25.0, SU4 and converts an existing LAPD network usingframe relay to an IPBH network. See optional feature documentFlexent®Wireless Networks BTS Conversion from LAPD to IPBH,, 401-612-841.

– FID10665.3––OMC-RAN support for IP Backhaul: This feature supportsOMC-RAN for FID10665.0/FID10666.0:

Introduction to IP Backhaul

.................................................................................................................................................................................................................................

1-2 Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

– FID 10674.1–This features introduces the support for IP based connectivityfrom the BTS to the RNC providing the IP Backhaul Server (BHS) function.

– FID 12170.0––RMT capability at the MSC: Supports IP Backhaul FIDs10665.0/10666.0 for remote RMT access from the MSC, allows the remotemaintenance terminal (RMT) to communicate with a cell’s URC via a LANconnection of a particular AP. Reduces the need for a physical cell site visit tochange backplane parameters from frame relay (FR) to IP Backhaul (IPBH) .

Related network features

The following table identifies how specific network features work with IPBH.

Table 1-1 Related network features

Feature Comment

Home location register(HLR)

The IP Backhaul feature is independent of HLR configuration

The Operations andMaintenance Center RadioAccess Network (OMC-RAN)provides OA&M capabilitiesfor a Flexent wirelessnetwork.

The OMC-RAN can be installed in the network either prior to orfollowing the installation of an IPBH network

SeeOperations and Maintenance Center Radio Access Network(OMC-RAN) Operations, Administration, and Maintenance (OA&M),401-662-105 for information on planning and implementation of theOMC-RAN.

Using OMC-RAN with IPBH

SeeOperations and Maintenance Center Radio Access Network (OMC-RAN)Operations, Administration, and Maintenance (OA&M),401-662-105 for informationon planning and implementation of the OMC-RAN.

Introduction to IP Backhaul IP Backhaul features

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-3

Availability.................................................................................................................................................................................................................................

Release availability

The IP Backhaul feature was available in CDMA starting with Release 25.0.

Market availability

The IP Backhaul feature is available in the North American region (NAR) and forInternational markets.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Prerequisites.................................................................................................................................................................................................................................

Supported technologies

The IP Backhaul feature is supported in the following air-interface technologies:

• CDMA cellular

• CDMA Personnel Communication System (PCS)

Related network features

The following table identifies how specific network features work with IPBH.

Feature Comment

HLR The IP Backhaul feature is independent of homelocation register (HLR) configuration

OMC-RAN The OMC-RAN can be installed in the networkeither prior to or following the installation of anIPBH network

SeeFlexent®/Autoplex® Wireless NetworksOperations and Maintenance Center Radio AccessNetwork (OMC-RAN) Operations, Administration,and Maintenance (OA&M),401-662-105 forinformation on planning and implementation of theOMC-RAN.

Hardware requirements

Table 1-2, “Network elements in an IPBH network and required changes” (p. 1-6)displays all of the hardware required for IPBH and identifies required hardwarechanges for IPBH.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-5

IPBH hardware that is required as part of a Flexent®/AUTOPLEX® wireless network,its functions and required changes:

Table 1-2 Network elements in an IPBH network and required changes

NetworkElement

Function Hardware change for IPBH

FMM-AP Holds RCS-APs(BTS controllersin the ECPC)

Only RCSs onFMM-AP aresupported

No hardware changes needed.

Upgrade is required for GNP-AP to FMM-APfor IPBH since the GNP-AP also houses RCSs.

1XRNC(optional)

Holds IPbackhaul servers(BHS).

Requires GICC1.1 cards (2) forEthernet®connection.

Upgrade existing equipment to GICC 1.1.

Grow in additional GICC 1.1 cards.

5ESS®DCS/PSU2e

Holds IPbackhaul servers(BHS).

Requires backhaul protocol handler (BPH)(new) upgrade for PSU2e.

BTS / Modularcell / Modularcell 4.0 withURC or URC-II

Standard cellhardware basedon your system.


BTS / Modularcell / HD 4.0with URC orURC-II

Standard cellhardware basedon your system.


BTS / Modularcell / Modularcell 4.0 Compactwith URC orURC-II

Standard cellhardware basedon your system


BTS / Modularcell / Modularcell 1/2/3 withURCm card

Standard cellhardware basedon your system

Upgrade is required for CRC to URCm forIPBH.

Introduction to IP Backhaul Prerequisites

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 1-2 Network elements in an IPBH network and required changes(continued)

NetworkElement

Function Hardware change for IPBH

Backhaultransport: Edgerouters (ER)

Support DS1transport.

User selected equipment.

Backhaultransport:Layer2/layer 3switches

Provide IPnetworkinterconnectionsbetween IPBHnetwork elements

User selected equipment

Software requirements

The IP Backhaul feature requires the following software:

• Executive cellular processor (ECP) Release 25.0 and higher that contains allFMM-AP, RCS-AP and 1XRNC software.

• 5ESS DCS: 5e19.1 (generic) release for R25.0 NAR5ESS DCS 5ee16.l (generic) release for R26.0 International

• BTS release 25.0 and higher

– Modular cell 4.0, HD 4.0 and Compact 4.0

– Modular cells 1, 2, and 3

• Remote maintenance terminal (RMT) software using either the

– Maintenance version that allows all capabilities of the RMT except settingfacilities backplane memory parameters.

– Self-install version that allows all capabilities of RMT including facilitiesbackplane memory parameters.

RTU QFAF and number of carriers

C E L L 152 - IP Backhaul Support for Right to Usexxx, where the valuexxx is thenumber of IPBH carriers configured This value varies by customer and can be anynumber from 0 to 10,800, or greater, depending on the user. See your LucentTechnologies representative for details.

You will need to know the number of carriers for your configuration prior toimplementing IPBH. This value is the purchased number of IPBH carriers that can beconfigured in an office. During configuration, warnings are built in to notify whencarrier capacity has reached 75% and 90% of capacity. If 100% capacity is reached noadditional configurations can occur. For planning purposes, be sure you know thenumber of carriers you have purchased.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-7

When the IP Backhaul Enabled field is set for a BTS via thecell2 form, a BackhaulServer (BHS) has to be assigned in thecell2 form for each carrier assigned to a radiovia thecdmeqp /btseqp form for the cell. Each carrier that is assigned to a BHS onthe cell2 form is counted as a configured IPBH carrier. The number of currentlyconfigured IPBH carriers for the office is displayed on the ECP form. The number ofcurrently configured IPBH carriers is not allowed to exceed the number of purchasedIPBH carriers designated in the RTU QFAF. When an attempt is made to configuremore IPBH carriers than the RTU QFAF allows, thecell2 form update is denied

Technical industry standards

Lucent IP backhaul is implemented based on several standard protocols defined byIETF and IEEE as follows:

• “The Point-To-Point Protocol (PPP),” STD 51, IETF RFC 1661, July 1994

• “The PPP Multilink Protocol (MP),” IETF RFC 1990

• “User Datagram Protocol,” IETF RFC 768, August 1980

• “Internet Protocol version 4,” IETF RFC 791, September 1981

• IEEE 802.1D/Q Mac Bridges and Virtual LAN

• Differentiated Service, IETF RFC 3317“Differentiated Services Quality of ServicePolicy Information Base”

• The PPP Internet Protocol Control Protocol, IETF RFC1332 & 1877 (Extension forDNS)

• The Multi-Class Extension to Multi-Link PPP, IETF RFC 2686

• PPP Challenge Handshake Authentication Protocol (CHAP) IETF RFC 1994

• HDLC Like Framing for PPP, IETF RFC 1662


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

IPBH documentation roadmap.................................................................................................................................................................................................................................

Related documentation

The following graphic identifies the Lucent Technologies customer documentation thatis available for the network elements that comprise the IPBH network. Note thatnon-Lucent hardware documentation is available through your vendor.

Table 1-3 Document Roadmap of IPBH tasks

Task Description Document name

Implement IPBHnetwork

IPBH overview

IPBH planning

IPBHimplementation

Flexent® Wireless NetworksIP Backhaul for CDMA Voiceand Packet Data,401-710-090


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-9

Table 1-3 Document Roadmap of IPBH tasks (continued)


Convert existingLAPD networkfrom frame Relayto IPBH

Step-by-stepprocedure for cellconversion.

Flexent® Wireless NetworksBTS Conversion from LAPD toIPBH (FID 10665.16),401-612-841

Install packethandlers for IPBH

RC Views

OA&M documentsfor the 5ESSSwitch.

For Internationaldocuments, seelisting at end ofthis table.

5ESS® Switch Flexent® Wireless NetworksApplicationsOA&M Manual, NAR 235-200-100

5ESS® Switch Flexent®Autoplex® Wireless NetworksApplicationsApplications OA&M Manual,5AP

Install packethandlers for IPBH

5ESS® Switch Flexent® Wireless Networks ApplicationsInput/Output Messages,235-600-700/750

Network planningand engineeringguidelines

System planning Flexent®/Autoplex® Wireless NetworksSystem CapacityMonitoring and Engineering Guidelines,401-610-009

Add new URCs Cell OA&M Flexent® CDMAModular Cell 4.0 and Compact ModularCell 4.0 Operations, Administration and Maintenance,401-703-407

Flexent® CDMAModular Cell 1.0, 2.0, 3.0 and CompactModular Cell 3.0 Operations, Administration andMaintenance,401-710-122

RC/V descriptionfor screens, formsand fieldparameters

Database update Flexent®/Autoplex® Wireless NetworksDatabase UpdateManual, 401-610-036

Syntax anddescription ofnetworkcommands

Alarms andmessages

Flexent®/Autoplex® Wireless NetworksInput MessagesManual, 401-610-055

Look up alarmmessage anddetermine statusand purpose ofalarm.

Troubleshoot analarm message

Alarms andmessages

Flexent®/Autoplex® Wireless NetworksOutput MessagesManual, 401-610-057

Introduction to IP Backhaul IPBH documentation roadmap

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 1-3 Document Roadmap of IPBH tasks (continued)


Systemperformance andservicemeasurement data

All ServiceMeasurements forthe network areidentified anddetailed.

Flexent®/Autoplex® Wireless NetworksServiceMeasurements,401-610-135

Monitor thenetwork from theECP complex

ECP and SDPmaintenance andcontrolinformation andprocedures.

Flexent®/Autoplex® Wireless NetworksECP OA&M andSDP Maintenance Control Procedures,401-610-160

Monitor thenetwork from theOMC-RAN

Description ofOMC-RANOA&M formonitoring anetwork.

Flexent®/Autoplex® Wireless NetworksOperations andMaintenance Center Radio Access Network (OMC-RAN),401-662-105

Maintain andprovision theRCS-APs

FMM-RCSOA&M

Flexent® Wireless Networks Radio Cluster Server (RCS)FMM-RCS OA&M,401-710-102

Flexent® Wireless NetworksCell Reliability andEngineering Improvements for IPBH RCS APs - Deliveryof Flexible Sparing Phase 1,401-612-830.

Install/updateGICC card forIPBH

Establish IPBHparameters fordata offload to theRNC

1X RNC OA&M Flexent® Wireless Networks CDMA 1X Radio NetworkController (RNC)Operations, Administration, &Maintenance,401-710-082

Reference TICLIcommands

FMM-TI referencefor TICLIcommands

Flexent® Wireless Networks FMM-TI Reference Guide,401-710-211

Additional 5ESSDCS documents

5ESS® Switch Flexent® Wireless Networks ApplicationsOA&M Manual, 5AP5AP

5ESS® Switch Flexent® Wireless Networks ApplicationsMeasurements Manual,5MM

5ESS® Switch Flexent® Wireless Networks ApplicationsRecent Change Manual,5RC

5ESS® Switch Flexent® Wireless NetworksApplicationscommands and Reports Manual,5CR


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-11

IPBH training course

The course CL5591: IP Backhaul for CDMA Voice and Packet Data is availablestarting with Release 25.0. This course describes IP Backhaul and provides a detailedoverview of the implementation necessary to successfully convert BTSs from LAPD toIPBH.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Benefits of IP Backhaul.................................................................................................................................................................................................................................

IPBH definition

IP Backhaul provides current Lucent Technologies customers a means to increase thecapacity of existing systems with minimal hardware and software updates by switchingfrom frame relay backhaul (FR) to IP Backhaul (IPBH).

IP Backhaul is comprised of a number of individual features that work together tocreate an IPBH network.

New terminology for IPBH

The following terms are new for IP Backhaul:

• Backhaul association (BHA)––A linking or association between a MLG and a BHSto form a logical, semi-permanent path for carrying user traffic between the BTSand the MSC.

• Backhaul server (BHS)––An active/standby pair of Backhaul Protocol Handlers(BPH) in the 5ESS DCS, or an active/standby pair of Gateway Intelligent CarrierCards (GICC) in the Radio Network Controller (1X RNC).

• Service option class (SOC)––Identifies the bearer class for routing purposes asvoice or packet data. Note that when SOC is provisioned in a Lucent Technologiesnetwork, the choices are Voice or Both (voice and packet data).

• Backhaul Protocol Handler (BPH)––A BPH board with fast Ethernet interface on a5ESS DCS PSU2e that terminates the backhaul network interface.

• Multi-link group (MLG)––A Point-to-point-Protocol (PPP) over DS1 or Multi-linkPPP (ML-PPP) link between a BTS and an edge router regardless of the number ofDS1s in the MLG.

• IP network address––Network address used solely for IP network designation. Thisnumber is assigned by the service provider at the time the network is established.

• IPBTS GW––Hardware and software that provide the IP Backhaul gatewayfunctionality.

IP Backhaul from Lucent Technologies

IPBH utilizes multi-link/multi-class PPP (ML/MC-PPP) to group multiple DS1s into asingle large pipe called a multi-link group (MLG) for backhaul transport. Each MLGconsists of one or more DS1 facilities per URC, configurable by the customer.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-13

With IPBH, both signaling and user traffic are multiplexed over IP over unchannelizedDS1s.

• Traffic from the BTS terminates on an edge router.

• The backhaul routers send the signaling traffic to the radio cluster serverapplication processor (RCS-AP).

• The bearer traffic is delivered directly to a Backhaul Server (BHS), located in thePSU2e or 1X RNC, over Ethernet® links.

Frame relay versus backhaul

Current Lucent Technologies backhaul networks utilize frame relay packet pipes.Table1-4, “Differences between FR and IPBH” (p. 1-14)lists the major differences betweenframe relay (FR) and IP Backhaul.

Table 1-4 Differences between FR and IPBH

Frame Relay Packet Pipe IP Backhaul

Trunk Group/ Member End-to-endNxDS0 between URC and PSU2e.

Virtual connections based on provisioned BTSBTS/Carrier/SOC-BHS assignments

FR over fractional DS1 at BTSinterface.

FR requires provisioning of theDS1 channels.

IP over unchannelized DS1 at BTS interface

Utilization of DS1 capacity is part of IP network

Fractional-DS1 through TSI toFRPH: up to 240 voice call legsper FRPH

Ethernet directly to BPH: 2000 call legs per BHS

Control links over dedicated Control and traffic mixed over all DS1s

DS0 grooming for control links No DS0 grooming for control links

DS1 interface to RCS-AP Ethernet interface at RCS-AP

All voice and data is routedthrough the 5ESS DCS

Data traffic can be offloaded to the 1X RNC

Maximum 16 DS0s used MLG provide multiple DS1s

Important! Data off-load to the optional 1X RNC is not available in internationalmarkets, however data can be off-loaded to a specific Backhaul Server (BHS).

Introduction to IP Backhaul Benefits of IP Backhaul

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Advantages of IPBH

IPBH provides the following advantages versus frame relay (FR) backhaul:

• Provides increased and improved capacity

– Frees 5ESS DCS time slot interchange (TSI) capacity for up to 40% more voicecalls per SM

– Improves T1 utilization through the use of unchannelized DS1s and a moreefficient protocol

– Increases voice call leg density per PSU2e slot to 2000 (from 240)TSI ports used for packet pipe trunks are freed because of direct termination ofbackhaul facilities to the BHS. The TSI ports can be used for network trunking,increasing the call capacity of the 5ESS DCS switching module (SM). The framerelay protocol handlers (FRPHs) that are used for frame relay backhaul are notneeded for IPBH.

• Simplifies planning and configuration

– Reduces operating expenses for backhaul provisioning and maintenance

– Simplifies backhaul and switch facilities engineering and provisioning

– Eliminates DS0 grooming

• Enables packet data traffic to be separated from voice traffic ahead of a DCS androuted directly to an RNC

Current CDMA networks

The current FR backhaul network provides the following:

• Signaling links delivered to the ECPC directly from the DACS or via a 5ESS DCSnailup.

• Signaling links delivered to the ECPC via nailup connection to the DS1s

• 5ESS DCS interfaces carry packet pipes (PPs) only or PPs with signaling links(optional)

• PPs are delivered to the frame relay packet handler (FRPH) via TSI and DF2


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-15

The figure below shows the current CDMA network:

For Code Division Multiple Access (CDMA) systems, the BTS backhaul networkcurrently consists of DS1 facilities connecting each BTS to a DS1 transport networkthat terminates in the MSC either on a Digital Access and Cross-connect System(DACS), or directly on the Wireless 5ESS Digital Cellular Switch (5ESS DCS).

User traffic is carried on dedicated multi-DS0 packet pipes (PP) that terminate onFRPHs. Control traffic is carried on dedicated DS0s that terminate on BTS controllers(RCS-APs in the ECPC) over DS1 interfaces.

Figure 1-1 Current backhaul network


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

IP Backhaul network configurations

Figure 1-2, “Typical IP Backhaul network with 5ESS DCS/PSU2e” (p. 1-17)shows atypical configuration for a IP Backhaul network:

The typical IP backhaul network with a 5ESS DCS provides the following:

• Control signaling delivered to the Flexent Mobility Manager (FMM) local areanetwork (LAN) directly from the backhaul router, (No DS0 grooming is required.)

• Traffic is delivered directly to the backhaul server (BHS) freeing up resourcespreviously used for FR overhead.

• The Digital Network Units-SONET (DNU/Ss) and Digital Line Trunk Units(DLTUs) are retired from backhaul usage.

• The recovered Time Slot Interchange (TSI) capacity can be used for trunk growth.

Figure 1-2 Typical IP Backhaul network with 5ESS DCS/PSU2e


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-17

Figure 1-3, “Typical IP Backhaul network with 5ESS DCS/PSU2e and 1X RNC”(p. 1-18)shows a typical configuration for a IP Backhaul network:

The typical IP backhaul network with the 5ESS DCS PSU2e and RNC provides thefollowing:

• Control signaling delivered to the Flexent Mobility Manager (FMM) local areanetwork (LAN) directly from the backhaul router. (No DS0 grooming is required.)

• Traffic is delivered directly to the backhaul server (BHS) on the 5ESS withoutusing resources previously used for FR overhead.

• The Digital Network Units-SONET (DNU/Ss) and Digital Line Trunk Units(DLTUs) are retired from backhaul usage.

• Data offload traffic is delivered to the BHS on the RNC.

• The recovered Time Slot Interchange (TSI) capacity can be used for trunk growth.

Figure 1-3 Typical IP Backhaul network with 5ESS DCS/PSU2e and 1X RNC


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

IPBH network architecture.................................................................................................................................................................................................................................

Attributes

The primary attributes of the IPBH architecture are:

• All traffic and signaling between Base Transceiver Stations (BTS) and the MobileSwitching Center (MSC) is carried over the IP network layer (IP Version 4 only).The network interfaces at the BTSs are un-channelized DS1s.

• At the BTS, traffic on any carrier can be switched to/from any DS1 so DS1s canbe optimally utilized. Bandwidth is added to a BTS in DS1 increments as needed tosupport capacity growth regardless of carrier configuration and carrier load. DS1capacity using the UDPMux protocol is approximately 145 3G1X voice call legsper DS1.

• Traffic and signaling are mixed over the DS1s and separated at the IP switchinglayer.

• On the network side, the DS1s terminate on commercial IP edge routers.Connections to elements at the MSC are all IP over Ethernet, rather than fractionalDS1 time division multiplex (TDM) channels.

Figure 1-4 IPBHNetwork


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-19

Khushbu.Parikh

Bandwidth is added to a BTS in DS1 increments as needed to support capacity growth regardless of carrier configuration and carrier load.

Khushbu.Parikh

Connections to elements at the MSC

Khushbu.Parikh

all IP over Ethernet, rather than fractional DS1 time division multiplex (TDM) channels.

Khushbu.Parikh

are all

• Provisioned data determines which packet switching unit (PSU) will serve thetraffic from a given BTS. Carrier geographic clustering is supported for voice orcombined voice and data traffic carried by the 5ESS DCS.

• BTSs can be provisioned such that voice is served on a PSU (or PSUs) whilepacket data is served on an RNC (or RNCs). This enables packet data to be trulyoff-loaded from PSUs and the inter-PSU soft handoff network. Carrier geographicclustering is not supported for data offload traffic on the RNC.

• IP backhaul is supported on all Modular cell types with Universal RadioControllers (URCm, URC and URC-II). It is not supported on Modular cells withCircuit Radio Controllers (CRC).

• IP backhaul is supported on Radio Cluster Servers (RCS-AP) hosted on FMM-APsand supports a mix of IP and FR BTSs on one RCS-AP.

• IP backhaul cell is either all IP or all frame relay (FR) and cannot be mixed on thesame cell.

• Soft handoff universe can support a mix of IP and FR BTSs. IPBH has no affect onATM SHO network (intra- or inter-MSC).

Introduction to IP Backhaul IPBH network architecture

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Khushbu.Parikh

IP backhaul is supported on all Modular cell types with Universal Radio Controllers (URCm, URC and URC-II). It is not supported on Modular cells with Circuit Radio Controllers (CRC).

Figure 1-5, “IPBH architecture” (p. 1-21)identifies all of the elements in the IPBHnetwork architecture.

Legend:

Abbr. Meaning

BTS 1 Base Transceiver Station 1

has one URC with one MLG over NxDS1

BTS n Base Transceiver Station #

has 2 URCs, each of which has 1 MLG; each MLG isconnected to a different edge router over NxDS1

Figure 1-5 IPBH architecture


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-21

Abbr. Meaning

MLG Multi-link Group

An aggregated grouping of multiple DS1s for transmissionbetween two points.

URC # Universal Radio Controller

UDP User Datagram Protocol

UPDmux User Datagram Protocol Multiplexing

ML-PPP Multi-Link Point-to-Point Protocol

NxDS1 Numberx Digital Service Level 1

TCP IP Transmission Control Protocol - Internet Protocol

ER-# Edge Router - #

are cross-connected to a pair of Multi-layer switches (MLS)over Ethernet

MLS-# Multi-layer Switch #

MSC adjacent switches connect to FMM-APs, PSUs andRNCs on flexible L2 transmission lines

L2-A/L2-B Layer 2 connections A and B

FMM-APs Flexent Mobility Manager Application Processors

FMM-AP (RCS-APs) connected to MLSs over FMM-LAN

TR1/2 Traffic subnets 1 and 2

PSUs Packet Switching Units

connected to MLSs for voice or data traffic and SHO withRNCs

BHS Backhaul Server

1X RNCs Radio Network Controllers

connected to switches for data offload BHS and SHO withPSUs

This figure is referenced in the remainder of this section.

BTS network interface

The physical layer at the BTS continues to be DS1. All user traffic and signaling aremultiplexed onto common DS1s and the IP layer is used to route packets to and fromthe desired MSC destinations.

The DS1s are terminated at the BTS on a universal radio controller (URC) board. Allthe URCs within a BTS are interconnected to enable traffic on any carrier to be


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Khushbu.Parikh

The DS1s are terminated at the BTS on a universal radio controller (URC) board.

Khushbu.Parikh

The physical layer at the BTS continues to be DS1.

transported over any DS1. This enables optimal DS1 utilization. No IP router isrequired at the BTS site.

On the network side, the DS1s terminate on a standard IP edge router. IP edge routerssupport DS1 over a variety of physical interfaces including: T1/E1, T3/E3/STS-1,OC-3/STM-1 and OC-12/STM-4.

Multi-link groups

Multiple DS1s between a URC and an edge router are grouped together into amulti-link group (MLG). The layer 2 protocol between the BTS and the edge router isPPP [1] over DS1 or Multi-Link PPP [2] over NxDS1. ML-PPP enables multiple DS1son the same URC (that terminate on the same router) to be grouped together into aMulti-Link Group (MLG). Each PPP/DS1 link or ML- PPP/NxDS1 link requires aunique IP address. Using MLGs (rather than individual DS1s) minimizes the number ofseparate interfaces that have to be managed by the application, and minimizes thenumber of IP addresses that a BTS requires. MLGs also aggregate bandwidth whichincreases aggregate DS1 efficiency.

Throughout this document, the term MLG is used to refer to a PPP or ML-PPP linkbetween a BTS and an edge router regardless of the number of DS1s in the MLG.Each URC has only one MLG. The BTS with multiple MLGs can have each MLG ona different ER.

Backhaul routers

The edge routers perform IP routing (layer 3); the L2 switches perform Ethernetswitching (layer 2).

Edge routers

The edge routers provide the OC3 terminations toward the BTSs and wide-banduplinks toward the MSC.

Multi-layer switches

The MLSs are optimized to provide economical Ethernet connections to the individualcontrol and traffic servers at the MSC. The MLSs perform both IP routing (layer 3)and Ethernet switching (layer 2).

Router configuration

The expected initial configuration has all the routers at the MSC site. However, it isalso possible to remote edge routers in cases where there is an economic advantage toterminate the DS1s closer to some group of BTSs and carry their aggregated traffic tothe MSC over some type of wide-band facilities. These wide-band facilities areexpected to be either unswitched (layer 2 pipes) or tunneled (layer 2 or 3) withguaranteed bandwidth. In any case their bandwidth must be engineered to meet thevery strict delay and jitter requirements of CDMA backhaul.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-23

RCS network interface

Packets between IP BTSs and RCS-APs are carried over Ethernet links between theMLSs and the FMM-AP Ethernet LAN. There are links between the MLs and eachgrowth frame with RCS-APs. RCS-APs communicate with BTSs over the same twoEthernet interfaces that they use for internal AP-to-AP communications.

DCS/PSU network interface

User traffic is carried over direct 100 Mbps Ethernet links between the MLSs and PSUProtocol Handler boards that are known as Backhaul PHs, or BPHs. Each BPH has 1Ethernet link.

BPHs are deployed in serving or non-serving (active/standby) pairs (1+1) for improvedreliability. A serving (active) BPH can take over from the non-serving (standby) BPHwithout loss of stable calls. When a non-serving BPH takes over, it assumes the IPaddress of the serving BPH so this switchover is transparent to the other networkelements (ECPC and BTSs).

A fault tolerant configuration has the serving and non-serving BPHs of a pairconnected to different MLSs. This implies that the traffic subnets span MLSs (that is,theMLs are connected at Layer 2 for the traffic subnets). A serving and non-servingpair of BPHs is known to other network elements as a single logical entity called aBackhaul Server or BHS. The details of BPH sparing are not visible to other networkelements since the switchover between BPHs in a pair is transparent. A PSU thatterminates IP backhaul traffic is expected to require no more than 3 to 4 BHSs. EachBHS in a PSU can serve approximately 2000 call legs. IP backhaul is supported onlyon PSU2e (PF3, CF3), which requires the Core700 SMP in the host SM.

1X RNC Network Interface

User traffic is carried over Gigabit Ethernet links between the MSC switches and RNCGateway Intelligent Carrier Cards (GICCs). Each GICC that supports IP backhaul has1 Gigabit Ethernet link to an MSC switch.

GICCs that support backhaul are deployed in serving and non-serving (active/standby)pairs (1+1) for improved reliability. A non-serving GICC takes over from the servingGICC without loss of stable calls. When a non-serving GICC takes over, it assumes theIP address of the serving GICC so the L2 switch over is transparent to the othernetwork elements (ECPC and BTSs). SeeSystem Capacity Monitoring and EngineeringGuidelines,401-610-009 for current capacity information for the RNC.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Khushbu.Parikh

User traffic is carried over direct 100 Mbps Ethernet links between the MLSs and PSU Protocol Handler boards that are known as Backhaul PHs, or BPHs. Each BPH has 1 Ethernet link.

IPBH traffic.................................................................................................................................................................................................................................

Purpose

The flow of data through the IP Backhaul network depends on the configuration of thenetwork. This section introduces the traffic protocol layers and describes the flow oftraffic in the IPBH network.

User traffic protocol

User traffic is carried on application layer connections over IP between URCs andBHSs (in PSUs and RNCs).

There are several important considerations in the selection of the user traffic protocollayers:

• compatibility with FR cells

• efficient use of DS1s

– minimization of delay and jitter

– and network performance.

Intra- or inter-MSC

BTSs with IP backhaul can co-exist in the same MSC and in the same Inter-MSCsoft-handoff network as BTSs with FR backhaul. That is, all frame selectors (FSs)must support simultaneous call legs from any combination of FR backhaul and IPbackhaul BTSs. FR backhaul uses the frame relay DLCI to route traffic frames fromthe frame relay PH (FRPH) that terminates the packet pipe to any FS4 in thesoft-handoff network.

Compatibility with FR backhaul cells

The most straightforward way to accomplish IP transport while maintainingcompatibility with FR backhaul is to continue to use DLCI for routing traffic frameswithin the soft-handoff network between BHSs and FSs (intra-PSU, inter-PSU,PSU-to-RNC and inter-RNC). That is, from the point of view of FSs, BHSs look muchlike FRPHs. Toward the BTSs, BHSs have additional protocol processing for IPtransport as is described below.

Efficient use of DS1s

Efficient use of DS1s dictates bundling of small traffic frames into larger IP packets.This spreads the UDP/IP header over many traffic frames. The chosen protocol iscalled “UDPMux” because of the bundling (also called multiplexing) of traffic framesinto UDP datagrams. UDPMux is a proprietary application layer that is transportedover standard UDP/IP. As mentioned above, to preserve compatibility with TDMbackhaul, each traffic frame continues to be routed within the soft-handoff networkbased on DLCI.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


1-25

For IP backhaul, as a further DS1 efficiency improvement, the DLCI of each trafficframe is replaced over the backhaul with a 1 byte value called a CID (Call ID). TheCID is allocated during call leg setup. The BHS performs the mapping between the 1byte CID used between the BHS and BTS and the DLCI used between the BHS andFS (within the soft-handoff network). So a UDPMux bundle is a standard UDP/IPdatagram with a small UDPMux header (application layer) and a sequence of trafficframes each of which includes a CID and length field. For uplink traffic the BTScreates UDPMux bundles from nearly simultaneous traffic frames that are to be sentover a particular MLG to a particular BHS. The receiving BHS parses out theindividual traffic frames, restores the full DLCI for each frame (based on the CID) androutes each frame to the destination FS based on the DLCI (just like an FRPH). Fordownlink traffic a BHS creates UDPMux bundles from nearly simultaneous trafficframes destined to the same BTS and MLG. For each traffic frame it inserts the CIDbased on address information from the FS. The receiving BTS parses out the individualtraffic frames and routes each frame to the destination channel element based on theCID. The expected DS1 capacity using the UDPMux protocol is 145 3G1X voice calllegs per T1.

In a network, latency, a synonym for delay, is an expression of how much time it takesfor a packet of data to get from one designated point to another. In some instanceslatency is measured by sending a packet that is returned to the sender and theround-trip time is considered the latency. Simulations indicate that around 320 bytesper UDPMux data gram (around 15 traffic frames on average) is ideal for optimizingDS1 efficiency while minimizing latency (delay) and jitter.

Introduction to IP Backhaul IPBH traffic

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Khushbu.Parikh

round-trip time is considered the latency.

2 2IP Backhaul network overview

Overview.................................................................................................................................................................................................................................

Purpose

This chapter describes the interfaces and interactions within the IP Backhaul network.

Contents

Reference Diagram 2-2

Base transceiver station 2-4

Backhaul routers and switches 2-6

Radio cluster server 2-10

5ESS DCS 2-12

Radio network controller (1X RNC) 2-15

User traffic protocols 2-20

Signaling traffic protocols 2-22

DS1s in IPBH 2-24

Backhaul server assignment and PSU2e/1X RNC engineering 2-25

IP Addressing 2-27

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-1

Reference Diagram.................................................................................................................................................................................................................................

Network architecture

Figure 2-1, “IP Backhaul network reference diagram” (p. 2-2)is referenced throughoutthis chapter.

Legend:

Abbr. Meaning

BTS 1 Base Transceiver Station 1

has one URC with one MLG over NxDS1

Figure 2-1 IP Backhaul network reference diagram

IP Backhaul network overview

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Abbr. Meaning

BTS n Base Transceiver Station #

has 2 URCs, each of which has 1 MLG; each MLG isconnected to a different edge router over NxDS1

MLG Multi-link Group

An aggregated grouping of multiple DS1s for transmissionbetween two points.

URC # Universal Radio Controller

UDP User Datagram Protocol

UPDmux User Datagram Protocol Multiplexing

ML-PPP Multi-Link Point-to-Point Protocol

NxDS1 Numberx Digital Service Level 1

TCP IP Transmission Control Protocol - Internet Protocol

ER-# Edge Router - #

are cross-connected to a pair of Multi-layer switches (MLS)over Ethernet

MLS-# Multi-layer Switch #

MSC adjacent switches connect to FMM-APs, PSUs andRNCs on flexible L2 transmission lines

L2-A/L2-B Layer 2 connections A and B

FMM-APs Flexent Mobility Manager Application Processors

FMM-AP (RCS-APs) connected to MLSs over FMM-LAN

TR1/2 Traffic subnets 1 and 2

PSUs Packet Switching Units

connected to MLSs for voice or data traffic and SHO withRNCs

BHS Backhaul Server

1X RNCs Radio Network Controllers

connected to MLSs for data offload BHS and SHO withPSUs

IP Backhaul network overview Reference Diagram

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-3

Base transceiver station.................................................................................................................................................................................................................................

Purpose

The BTS manages signals to and from users and call control manager functions in theMSC.

HW/SW requirements

BTS requirements for an IPBH network:

• Standard cell hardware based on your system

• No new or additional hardware needed.

• Current release software for:

– Modular cell 4.10, HD 4.0 and Compact 4.0

• Modular cells 1,2 and 3

See“Prerequisites” (p. 1-5)for specific release requirements.

Enabling IPBH at the BTS

The following guidelines should be considered when implementing IPBH:

• A cell cannot have a mix of FR and IPBH facilities in service. All Universal RadioControllers (URCs) within communication facilities in a cell must be configured foreither FR or IPBH.

• Modular cell 1.0-3.0 supports the configuration of 1 URCm with no T1/E1facilities. For URCms with no facilities, all signaling and traffic are routed throughfacilities on another URCm. CRCs are not supported for IPBH.

• For Modular cell 4.0, each URC or URC-II must be connected to at least one edgerouter.

DS1s

DS1 continues to be the physical layer at the BTS, using full, unchannelized DS1s.The creation of any sub-DS1 rate channels is not required. Instead all user traffic andsignaling are multiplexed onto common DS1s and the IP layer is used to route packetsto and from the desired MSC destinations.

Modular cells

The DS1s are terminated at the BTS on a URC board. IP Backhaul is supported on allModular cells equipped with URCs. Each CRC in a Modular cell 1/2/3 must beupgraded to a URCm prior to conversion of the BTS to IP Backhaul. All the URCswithin a BTS frame are interconnected to enable traffic on any carrier to be transported


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Khushbu.Parikh

Each CRC in a Modular cell 1/2/3 must be upgraded to a URCm prior to conversion of the BTS to IP Backhaul.

over any DS1. This enables optimal DS1 utilization. This is an integrated IP solution atthe BTS. There is no IP router required at the BTS site.

Refer toFlexent®CDMA Modular Cell 4.0 and Compact Modular Cell 4.0 Operations,Administration and Maintenance,401-703-407 andFlexent®/ CDMA Modular Cell1.0, 2.0, 3.0 and Compact Modular Cell 3.0 Operations, Administration andMaintenance,401-710-122 for cell OA&M information.

All IP

The 3G1X carriers and URCs in a BTS are either all IP or all frame relay. A cellcannot have a mix of FR and IPBH facilities in service, except as a transient conditionduring conversion of a cell.

Important! Note that this statement excludes EVDO. A BTS can be configured tosimultaneously support EVDO and 3G1X. A configuration for the EVDO URC canbe IP, while all the 3G1X URCs are frame relay.

BTS to router interfaces

On the network side, the DS1s are terminated on a standard IP edge router. The designof the physical transport of the DS1s is a service provider option. IP edge routerssupport DS1 over a variety of physical interfaces.

Multi-link group (MLG)

Characteristics of MLGs:

• Support one MLG per URC

• Support up to 4 DS1s (URC), 8 DS1s (URCII) per MLG

• Support the signaling traffic of another URC in the same assemblage whose DS1facilities fail

• Support a URC that has no DS1 equipped to share another URC’s MLG in thesame assemblage (Modular cell 1, 2 and 3)

The layer 2 protocol between the BTS and the edge router is PPP over DS1 orML-PPP over NxDS1. ML-PPP enables multiple DS1s on the same URC (thatterminate on the same router) to be grouped together into a multi-link group (MLG).Each PPP/DS1 link or MLPPP/ NxDS1 link requires a unique IP address. Using MLGs(rather than individual DS1s) minimizes the number of separate interfaces that have tobe managed by the application. MLGs also aggregate bandwidth which increasesaggregate DS1 efficiency.

For greater path diversity, a BTS’s MLGs may be spread across a pair of edge routersas shown in“Reference Diagram” (p. 2-2). Each MLG may have one or several DS1s(within the URC capacity limit).

IP Backhaul network overview Base transceiver station

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-5

Backhaul routers and switches.................................................................................................................................................................................................................................

Purpose

This section describes the IPBH transport network.

As part of network architecture, IP Backhaul will use standard IP routers terminatingT1/E1 facilities and Ethernet switches interconnecting to 100 BaseT or GigE Ethernetfacilities.

The following documents provide further information about implementing andengineering backhaul routers:

Table 2-1 Router and switch documentation resources

Document Description

VRAD-5576 This document describes the design of IP Backhaulwith an emphasis on the requirements on the IPswitches and routers

Ask your Lucent Technologies representative for thisinformation.

System Capacity Monitoringand Engineering Guidelines(401-610-009)

This document (available for Release 25.0) providesinformation needed to monitor and engineer networkperformance and capacity.

See your Lucent Technologies account representative for access to these documents.

Transport network configuration

The network transport portion of the IPBH architecture resides between the cell sitesand the Mobile Switching Center (MSC). Its purpose is to transport traffic between thecells and the MSC components.Figure 2-2, “IPBH network topology” (p. 2-7)illustrates the general network topology in a duplex configuration. The AutomaticProtection Switching (APS) mechanism of Synchronous Optical Network (SONET) is


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

used to provide redundancy for router failure and OC3 link failure (Active OC3 andProtect OC3).

Edge routers

The edge routers provide:

• DS1 terminations toward the BTSs over:

– T1/E1

– T3/E3

– OC-3/STM-1

– OC-12/STM-4

• wideband uplinks toward the MSC

The edge router supports DS1 over the following interfaces:

• T1/E1

• T3/E3

• OC-3/STM-1

• OC-12/STM-4

Remote edge routers

The expected initial configuration has all the routers at the MSC site. However, it isalso possible to have remote edge routers.

Figure 2-2 IPBH network topology

IP Backhaul network overview Backhaul routers and switches

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-7

Remote routers are used in cases where there is an economic advantage to terminatethe DS1s closer to some group of BTSs and carry their aggregated traffic to the MSCover some type of wideband facilities. These wideband facilities are expected to beeither unswitched (layer 2 pipes) or tunneled (Layer 2 or Layer 3) with guaranteedbandwidth. In any case their bandwidth must be engineered to meet the very strictdelay and jitter requirements of CDMA backhaul.

Adjacent switches

The MSC adjacent switch becomes part of a private IP network interconnecting APframes, the OMP, edge routers and backhaul servers (BHS). No other network elementsor networks are allowed to connect to this network.

The edge routers are cross-connected to a pair of switches adjacent to the MSC(“MLS-1” and “MLS-2”). This switching layer between the edge routers and the MSCis the expected network design choice because edge routers do not typically provideeconomical, high-density 100 Mbps Ethernet connections as required here to connect tothe control and traffic servers in the MSC. These MSC adjacent switches may bemulti-layer (L2/L3) switches or L2 only switches.

In order to support troubleshooting and problem resolution, Lucent Technologiesrecommends the switches be configured to enable history logging. If the switch in yournetwork does not store this information on the switch, a separate server will be neededto store the data. Lucent Technologies recommends storage of this data on acustomer-controlled network server using the same practices used for other networkdata (for example, SNMP data). See your vendor documentation for specificinformation on logging and file storage.

Router types

Regarding routers and switches, the backhaul network architecture is “vendor neutral.”For the most part only commonly available interfaces and features are required.However, there are some quality of service (QoS) capabilities that are required toachieve high quality voice over DS1, that are standardized but are not widelysupported on edge routers.

IP router requirements

The IP router must support the following standard protocols to be compatible withLucent Technologies’ IP Backhaul:

• PPP and MC/ML-PPP protocols

• DiffServ QoS

• IPCP IP router should also perform the IP address assignment through IPCPprotocol to assign dynamic IP address to the BTS when it is initialized


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

• The Ethernet switch should support the IEEE 802.1D/Q function to be compatiblewith Lucent IP Backhaul

• For DS1 error conditions, the router should report:

– loss of signal

– loss of framing

– receipt of AIS and RAI

– report BER alarms based on configurable BER thresholds and remove a DS1from service when the threshold is exceeded for a configurable interval.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-9

Radio cluster server.................................................................................................................................................................................................................................

Purpose

The radio cluster server (RCS) is an application on an RCS-AP that performs the callprocessing and OA&M functions for the cells.

HW/SW requirements

RCS-AP requirements for an IPBH network:

• No hardware changes needed.

• Current ECP Release software


Note: IP Backhaul is not supported on the GNP-AP platform.

RCS-AP supports LAPD and FR

An RCS-AP can simultaneously support IP and frame relay BTSs. That is, an RCS-APcan run a mix of RCS-Link Access Protocol on the D channel (LAPD) instances (tosupport BTSs in FR mode) and RCS-IP instances (to support BTSs in IP mode).

An RCS-AP that supports only IP BTS does not require DS1 links or a DS1 I/O card.

RCS connectivity to the backhaul network

Each MSC adjacent switch has one 100 Mbps Ethernet link to one of the switches ineach FMM growth frame with RCS-APs. Based on RCS-AP capacity, a frame that isfully equipped with RCS-APs does not require more than one 100 Mbps Ethernet linkto each adjacent switch. The two links to a given FMM frame are redundant, that is,each link can support the full backhaul message load for that frame. RCS-APscommunicate with BTSs over the same two Ethernet interfaces that they use forinternal AP-to-AP communications.

FMM-AP

IP Backhaul is supported only on the FMM-AP platform, and is supported on allFMM-AP types including satellites.

No additional hardware in the FMM complex is required for IP Backhaul.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

RCS in IPBH network

Figure 2-3, “RCS signaling conversion: simplified view” (p. 2-11)shows a simplifiedview of the RCS signaling conversion in the IPBH network.

Note that once the MSC is completely IP, the DACS will no longer be needed.

When all IPBH BTS and network preparations are completed for an IPBH network, thefollowing types of activities can occur for the RCS:

• Provisioning activity associated with converting LAPD-based RCSs to IP-basedRCSs (note that this may be done as part of an automated conversion process)

• Provisioning activity associated with growing or degrowing IP-based RCS

SeeChapter 3, Implementationfor IPBH for RCS-IP provisioning information.

Figure 2-3 RCS signaling conversion: simplified view

IP Backhaul network overview Radio cluster server

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-11

5ESS DCS.................................................................................................................................................................................................................................

Purpose

The 5ESS DCS hosts the backhaul server (BHS) on the packet switching unit (PSU2e)for user traffic.

HW/SW requirements

5ESS DCS requirements for an IPBH network:

• BPH upgrade for PSU2e

• Current release software.


PSU2e diagram

Legend:

UDPMux traffic between the serving IP address on theserving BPH and the MLGs

Figure 2-4 5ESS Switch packet handlers in PSU2e


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Traffic frames between frame selector in PHV/DPHand BPH (transmitted to both BPHs)

Periodic ARP between each BPH and the 1st hoprouter

Serving BPH update of dynamic data in non-servingBPH

PSU2e characteristics:

• BPH 1+1 sparing consists of serving and non-serving BPHs

• The serving BPHs receives and transmits UDPMux traffic to and from a BTS on aserving IP address

• Each BPH has its own fixed IP address

• In the case of a switchover, the serving IP address is moved from the serving BPHto the non-serving BPH

• Both the BPHs do periodic address resolution protocol (ARP) requests to the 1sthop router to verify connectivity to the router.

• The call leg dynamic data is continuously kept the same on both serving andnon-serving BPHs to facilitate switchover and failover to preserve stable calls.

BHAs

The backhaul server association (BHA) is a UDPMux session between a BTS and aBPH. This association is identified by the BTS IP address, the BHS IP address, and theUDP ports. See“5ESS DCS OA&M” (p. 4-11)information about commands to viewall BHA information.

Backhaul protocol handlers (BPH)

User traffic is carried over direct 100 Mbps Ethernet links between the MSC adjacentswitches and PSU2e Protocol Handler (PH) boards that are known as Backhaul PHs, orBPHs. Each BPH has one Ethernet link.

Fault tolerance

BPHs are deployed in serving and non-serving pairs (1+1) for improved reliability.

• A non-serving BPH can take over from the serving BPH without loss of stablecalls.

• BPH failover occurs due to Ethernet failure, loss of connectivity to 1st hop routeror unrecoverable hardware or software faults.

• When a non-serving BPH takes over, it assumes the IP address of the serving BPHso this switchover is transparent to the other network elements, the ExecutiveCellular Processor Cluster (ECPC) and BTSs.

IP Backhaul network overview 5ESS DCS

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-13

A fault tolerant configuration has the serving and non-serving BPHs of a pairconnected to different adjacent switches as shown inFigure 2-4, “5ESS Switch packethandlers in PSU2e” (p. 2-12). This implies that the traffic subnets span the adjacentswitches (that is, the adjacent switches are connected at Layer 2 for the traffic subnets).

BHS

A serving and non-serving pair of BPHs is known to other network elements as asingle logical entity called a Backhaul Server (BHS). The details of BPH sparing donot need to be visible to other network elements since the switchover is transparentbetween BPHs in a pair.

A PSU2e that terminates a fully loaded IP Backhaul configuration is expected torequire no more than 3 to 4 BHSs.

Each BHS in a PSU2e can serve approximately 2000 call legs. IP Backhaul issupported only on PSU2e (PF3, CF3), which requires the Core700 SMP in the hostswitching module.

Note that data offload that is optionally available to the RNC is not available ininternational markets, however data can be offloaded to a specific BHS.

Capacity

IP Backhaul provides a significant improvement in DCS capacity (as compared to FRbackhaul):

• No TSI timeslots or trunk peripheral resources are required––TSI timeslots arefreed up for additional PSTN and speech handler trunks (PHVs), the BHCAcapacity of an SM increases by up to 40% (depending on system configuration andcall characteristics) and the number of PSU2e shelves required per SM decreases.

• High speed packet data traffic can be routed directly to the RNC instead of goingthrough the DCS, allowing the PSUs to handle more voice calls.

IP Backhaul network overview 5ESS DCS

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Radio network controller (1X RNC).................................................................................................................................................................................................................................

Purpose

The 1X radio network controller ( 1X RNC also referred to as RNC) hosts a backhaulserver (BHS) for data offload of user traffic in an IPBH network.

New terms for IPBH in the RNC:

• Internet Protocol base transceiver station gateway (IPBTS GW)–– The hardwareand software functionality in the RNC that provides the IPBH gateway to the BTS.A BTS GW is IP based and interfaces through a GICC external GigE port.

• Backhaul server (BHS)–– The logical representation of the upper and lower IPBTSGW in a pair of GICCs in the RNC.

• There is one IPBTS GW service per GICC pair (not allowed on SC-GICC).

HW/SW requirements

1X RNC requirements for an IPBH network:

• GICC 1.1 required for IPBH.

• Current ECP Release software


IPBTS GW

IPBTS GW characteristics:

• IPBTS GW 1+1 sparing consists of an active and standby IPBTS GW.

• The serving IPBTS GW receives and transmits UDPMux traffic to and from theBTS on a BHS IP address.

• Each IPBTS GICC in a BHS has its own IP address.

• In the case of a switchover, the BHS IP address is moved from the active IPBTSGW to the standby IPBTS GW.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-15

• Both IPBTS GWs send periodic address resolution protocol (ARP) requests to thefirst hop router to verify connectivity to the router

• The call leg dynamic data is synchronized between the GICCs to facilitateswitchover and failover without losing stable call legs.

Legend:

UDPMux traffic between the BHS IP on the active IPBTS GWand the MLGs

Traffic frames between the IPBTS GW and frame selectors inCICCs.

Traffic frames between frame selectors in CICCs and theIPBTS GW.

Periodic ARPs are sent from the fixed IPBTS GW IP addresseson each BPH and the 1st hop router.

Active IPBTS GW updates of dynamic data in the standbyIPBTS GW

Figure 2-5 IPBTS GW Sparing

IP Backhaul network overview Radio network controller (1X RNC)

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

1X RNC shelf configuration

Figure 2-6, “1X RNC shelf configuration for IP Backhaul” (p. 2-18)shows theconfiguration of the TPU shelf in the IP Backhaul RNC. The GICCs in slot 19 in theupper and lower shelves provide backhaul server (BHS) functions:

• The TPU shelf can have a mix of GICC 1.0s and GICC 1.1s

• The SC-GICC (slot 3) always supports the A8/A9 and A10/A11 gateways and canbe equipped with ATM 5ESS DCS gateways

• Slots 4, 19 and 20 can be equipped either as 5ESS DCS GWs or IPBTS GWs:

– GICCs in these slots can support either ATM 5ESS DCS GW or IPBTS GWonly -- they cannot support both simultaneously

– GICCs are equipped in pairs, both GWs in a pair can only support one gatewaytype


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-17

– IPBTS GWs are supported only on GICC 1.1 with a limit of one IPBTS GWper GICC

– ATM 5ESS DCS GWs are supported on GICC 1.0 and GICC 1.1 with a limitof two 5ESS DCS GWs per GICC

GICC

User traffic is carried over Gigabit Ethernet links between the MSC adjacent switchesand RNC gateway intelligent carrier cards (GICCs). Each GICC that supports backhaulhas a single Gigabit Ethernet (GigE) link to an MSC adjacent switch.

BHS

As for BPHs, an active/standby pair of GICCs is also known to other network elementsas a single logical BHS.

Figure 2-6 1X RNC shelf configuration for IP Backhaul


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Figure 2-7, “1X RNC BHS processes” (p. 2-19)shows the BHS server functionalitywithin the 1X RNC.

The BHS represents a pair of IPBTS GWs and hides the internal 1X RNC IP Backhaularchitecture from the BTS and ECPC. The BTS and ECPC communicate only with theBHS, and are not affected by switching between the IPBTS GWs. The RNC forwardsBHS status to the ECPC. This status reflects the status of the active IPBTS GW only.If an IPBTS GW switchover occurs, the RNC BHS status simply represents the statusof the newly active IPBTS GW. The active IPBTS GW uses the BHS service IPaddress to communicate and exchange bearer traffic with the BTSs.

Fault tolerance

GICCs that support backhaul are deployed in serving and non-serving pairs (1+1) forimproved reliability. A non-serving GICC can take over from the serving GICC withoutloss of stable calls. When a non-serving GICC takes over, it assumes the IP address ofthe serving GICC so this switchover is transparent to the other network elements(ECPC and BTSs). A fault tolerant configuration has the serving and non-servingGICCs of a pair connected to different adjacent switches as shown inFigure 2-1, “IPBackhaul network reference diagram” (p. 2-2).

Figure 2-7 1X RNC BHS processes


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-19

User traffic protocols.................................................................................................................................................................................................................................

Purpose

User(bearer) traffic is carried on application layer connections over IP between URCsand BHSs in PSUs and 1X RNCs.

Protocol stacks

Figure 2-8, “Bearer traffic protocol stacks” (p. 2-20)shows the protocol scheme usedfor bearer traffic in IPBH.

Bearer traffic protocols

Table 2-2 Bearer traffic protocols for IPBH network

Name Function

UDP User traffic

Application layer protocol

LAPD User traffic


Negotiates the setup of a particular voice channel

UDPMux Allows several UDP packets to be bundled and sent together and laterde-multiplexed

Transport layer protocol

Lucent proprietary

CEFS L3 (Layer 3) Channel Element (BTS) <-> Frame Selector (5ESS DCS/RNC) L3communication

Sets up voice/data call for a particular CID at L3

Figure 2-8 Bearer traffic protocol stacks


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 2-2 Bearer traffic protocols for IPBH network (continued)

Name Function

T1/E1 Physical layer protocol

UDP Transport layer protocol

IP Network layer protocol

ML-PPP Data-link layer protocol

IP Backhaul network overview User traffic protocols

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-21

Signaling traffic protocols.................................................................................................................................................................................................................................

Purpose

Signaling traffic is carried on application layer connections over IP between URCs andRCS-APs.

Protocol stacks

Figure 2-9, “Signaling traffic protocol stacks ” (p. 2-22)shows the protocol schemeused for control traffic in IPBH.

Signaling traffic protocols

Table 2-3 Signaling traffic protocols for IPBH network

Name Function

CCMS Signaling Traffic

Cell Communication Manager


Runs from RCS-AP to URC

Protocols for message headers, message bodies, and extended messageheaders

Lucent proprietary

TCP Transport layer protocol

TCP Intermediate Layer Includes heartbeat mechanism

Simple BTS Startup Protocol transactions done out of band (but, not trueUNIX out of band)

Lucent proprietary

IP Network layer protocol

Figure 2-9 Signaling traffic protocol stacks


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 2-3 Signaling traffic protocols for IPBH network (continued)

Name Function

ML-PPP Data-link layer protocol

T1/E1 Physical layer protocol

IP Backhaul network overview Signaling traffic protocols

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-23

DS1s in IPBH.................................................................................................................................................................................................................................

Efficient use of DS1s

Efficient use of DS1s dictates bundling of small traffic frames into larger IP packets.Bundling spreads the User Datagram Protocol (UDP)/IP header overhead over manyframes. Of course, only traffic frames that are nearly simultaneous can be bundledtogether.

The chosen protocol is called “UDPMux” because of the bundling (also calledmultiplexing) of traffic frames into UDP datagrams. UDPMux is a proprietaryapplication layer that is transported over standard UDP/IP.

To preserve compatibility with FR backhaul, each traffic frame continues to be routedwithin the soft-handoff network based on DLCI. For IP Backhaul, as a further DS1efficiency improvement, the DLCI of each traffic frame is replaced over the backhaulwith a one byte value called a call identifier (CID). The CID is allocated during callleg setup. The BHS performs the mapping between the one byte CID, which is usedbetween the BHS and BTS, and the data link connection identifier (DLCI), which isused between the BHS and frame selector (FS), within the soft handoff network.

A UDPMux bundle is a standard UDP/IP datagram with a small UDPMux header(application layer) and a sequence of traffic frames, each of which includes a CID andlength field:

• For uplink traffic, the BTS creates UDPMux bundles from nearly simultaneoustraffic frames that are sent over a particular MLG to a particular BHS. Thereceiving BHS parses out the individual traffic frames, restores the full DLCI foreach frame (based on the CID) and routes each frame to the destination FS basedon the DLCI (just like an FRPH).

• For downlink traffic a BHS creates UDPMux bundles from nearly simultaneoustraffic frames destined to the same BTS and MLG. For each traffic frame, the BHSinserts the CID based on address information from the frame selector. Thereceiving BTS parses out the individual traffic frames and routes each frame to thedestination channel element based on the CID.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Backhaul server assignment and PSU2e/1X RNC engineering.................................................................................................................................................................................................................................

Purpose

This section describes how the user traffic of a BTS is assigned to particular PSUs and1X RNCs. To simplify switch engineering and thus minimize the amount ofprovisioning required, data is provisioned at the MSC for each BTS that determines thePSU2e(s) and/or RNC(s) to serve the user traffic of that BTS.

Carrier geographic clustering

“Carrier geographic clustering,” which is the ability to assign a different PSU2e toserve each carrier of a BTS, is supported by IP Backhaul for traffic served on PSUs.Clustering allows all the traffic on a particular carrier in a geographic cluster of BTSsto be served on a particular PSU2e. Carrier geographic clustering minimizesinter-PSU2e soft-handoff traffic by keeping most soft-handoff traffic within ageographic cluster of BTSs within the PSU2e assigned to serve each carrier.

Voice and packet data traffic may be routed independently so that voice traffic can berouted to a PSU2e while packet data traffic from the same BTS is routed directly to anRNC.

Since the RNC is large compared to a packet switch (PS), carrier geographic clusteringis not required for packet data traffic served on an RNC. When data traffic is served onan RNC, all of the carriers of a particular BTS are served on the same RNC and BHS.To provide added reliability, primary and alternate RNC BHSs can be specified foreach BTS. The alternate RNC BHS is used only in the event of a failure of theprimary RNC BHS.

The data provisioned on thecell2 form for each BTS determines the PSU(s) and/orRNC(s) that are to serve the user traffic of that BTS:

• For each BTS carrier, a PSU2e BHS is specified to serve the voice and data trafficof that carrier:

– The PSU2e is identified by its SM number (1-192) and PSU2e number (0 or 1).

– The BHS is identified by its logical number within the PSU2e (1-10).

• For each BTS, a primary and alternate DCS BHS may be specified to serve thepacket data traffic of the BTS for all carriers.

• For each BTS, a primary and alternate RNC BHS may be specified to serve thepacket data traffic of the BTS for all carriers:

– An RNC is identified by a logical number within the MSC (1- 15).

– A BHS is identified by logical number within an RNC (1-3).

The alternate RNC BHS may be a different BHS on the same RNC as the primary, orit may be a BHS on a different RNC than the primary.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-25

If no RNC or DCS BHS is specified for the data traffic, then the data traffic defaultsto the same PSU BHSs that are specified for the voice traffic. The alternate DCS orRNC BHS is used for data traffic when the primary BHS is marked unavailable. Thealternate BHS is not used to relieve overload conditions on the primary BHS.


IP Backhaul network overview Backhaul server assignment and PSU2e/1X RNCengineering

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

IP Addressing.................................................................................................................................................................................................................................

Purpose

This section discusses IP addressing schemes for an IPBH network.

IP address definition

An Internet Protocol (IP) v4 address (IPBH uses the IPv4 address) is a 32-bit binarynumber usually displayed as four octets in decimal, separated by periods.

The Internet is a collection of networks whose users communicate with each other viaaddressing called the IP address (Internet Protocol address).

The IP address has two parts:

• one part identifies the network (with the network number)

• the other part identifies the specific machine or host within the network (with thehost number).

• An organization can use some of the bits in the machine or host part of the addressto identify a specific subnet. Effectively, the IP address then contains three parts:the network number, the subnet number, and the machine number.

• The subnet is a portion of an IP address. In a subnetted network, the host portionof an IP address is split into a subnet portion and a host portion using an addressmask (the subnet mask).

IP address requirements

The addresses used for IPBH are private IP addresses and will be used only betweenthe BTS and router, and the router and MSC. Therefore, the address ranges can beduplicated on different MSCs in an IPBH network. Reserving a large chunk ofaddresses will not affect an existing network if there are not conflicts within thereserved addresses.

Private IP addresses used include:

Table 2-4 IPBH component IP addressing

Network elementMax. # elements

Max. # nodes perelement

Total size Subnet and maskreserved subnet

BTS

600 BTSs

12 URCs per BTS

1 MLG per URC

Static : 2 IPaddresses per MLG

/30 for 2 hostaddresses

RCS-AP

28 Frames

22 RCS-APs perframe

2 IP addresses perAP



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-27

Table 2-4 IPBH component IP addressing (continued)




5ESS DCS

64 SMs per DCS

10 BHS/PSU 2+1 VIP per BHS /26 for 30 hostaddresses

1X RNC

15 RNCs

3 GICC pairs perRNC

2 + 1 VIP perGICC pair


IPBH network addressing details

For IP addresses used in the IPBH network:

• Two IP addresses are used per MLG, with 1 MLG per URC:

– Each MLG requires a unique IP address. The router assigns this addressautomatically during the network protocol negotiation phase of PPP linkinitialization. The PPP Network Control Protocol (NCP) that enables dynamicIP address assignment to a PPP endpoint is the IP Control Protocol (IPCP).

• The router assigns IP addresses to MLGs from an address pool that is provisionedat the router for all the MLGs that the router terminates.

• BHS IP addresses are manually provisioned through the 5ESS DCS and 1X RNCOA&M.

• One IP subnet is used for all RCS-APs (control subnet) where:

– Only the network ID of a control subnet is provisioned (no provisioning perAP).

– Only RCS-APs are addressable from the backhaul network.

BTS IP Address Administration

For IP address administration:

• A pool of IP addresses are assigned to the BTS by the edge router:

– during ML-PPP link initialization

– using the BTS address pools configured at the edge router or an associatedaddress server. This can be a fixed assignment, or a pool of addresses can bereserved for dynamic assignment. Fixed assignments are recommended forredundant edge router configurations.

• The BTS utilizes standard IP protocols for address configuration.

• The BTS address space can be in one or more subnets. Generally each edge routerserves one subnet; depending on the number of routers a BTS communicates with,it may be assigned to one or more subnets. For greater reliability, a BTS withmultiple URCs should be served by multiple edge routers. The static routes in theDCS and RNC need to be configured to include these subnets.

IP Backhaul network overview IP Addressing

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Khushbu.Parikh

BHS IP addresses are manually provisioned through the 5ESS DCS and 1X RNC OA&M.

Khushbu.Parikh

The router assigns IP addresses to MLGs

• During URC initialization, the URC queries the backhaul connection server(BHCS) to discover the RCS-AP addresses:

– The BTS is identified by the backplane serial number (BPSN).

– BPSNs are provisioned at the ECPC.

BHS IP address administration

BHSs can reside either on the 5ESS DCS or the 1X RNC.

For IP address administration:

• IP addresses are manually provisioned through the 5ESS DCS and RNC.

• There are 3 IP addresses per BHS: 1 service address seen by the ECPC and BTSs,and one physical IP address per BPH/GICC.

• 1+1 pair of BHSs may be connected to separate adjacent switches for faulttolerance.

RCS-AP IP addresses

The backhaul IP address of an RCS-AP interface is static and supports fault tolerantnetworking.

No direct provisioning is done for the RCS-AP:

• Each RCS-AP requires two IP addresses for backhaul, one for each of its Ethernetinterfaces:

– One network prefix per MSC is provisioned for the control subnets: 2 controlsubnets, 2 adjacent blocks with 1024 host IDs each.

– The provisioned network ID and the AP’s logical number determine the twoaddresses used by an RCS-AP.

– The MSC requires 2 contiguous subnets with a total size of 2,048 host IDs.

• Each control subnet corresponds to each half of the FMM-AP LAN.

• Each RCS-AP takes two host IDs based on AP location (frame and slot):

– Control subnets are further divided into per-frame subnets.

– Frame subnet offset is determined by frame number.

– Subnets per frame are required to route directly over the links to/from eachframe.

• Only RCS-APs have addresses on the IPBH network.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


2-29

Khushbu.Parikh

The BTS is identified by the backplane serial number (BPSN).

Khushbu.Parikh

provisioned at the ECPC.

Khushbu.Parikh

BPSNs are provisioned

Khushbu.Parikh

There are 3 IP addresses per BHS:

5ESS DCS IP address administration

IP addresses are manually provisioned through DCS OA&M:

• The BPHs are paired in a 1+1 sparing arrangement for fault tolerance.

• Three IP addresses are provisioned:

– Two IP addresses are assigned for the BPHs. Each BPH in a backhaul server(BHS) pair has an IP address. The BPHs in a BHS pair connect to differentMSC adjacent switches for fault tolerance.

– A service address (virtual address) is also provisioned. The service address isowned by the active BPH that is seen by both the ECPC and the BTS.

1X RNC IP address

IP addresses are manually provisioned through 1X RNC OA&M:

• 3 IP addresses are provisioned per BHS:

– 1 service address (virtual address) is seen by the ECP, BTSs. The BHS addressseen by the ECP/BTSs floats between the GICCs; it is automatically assigned tothe serving GICC.

– Each GICC in the pair is assigned one external physical IP address used formonitoring the Ethernet link.

• Internal addresses:

– Note that the BHS service address and the GICC external physical IP addressesmust not overlap with the RNC internal address space:

– The internal IP pool starting address and internal IP subnet mask can be viewedon the TPU-GUI.

• The defaults for the RNC internal addresses are:

– IP pool start: 172.16.128.112

– Shelf InternalIPSubnetMask: 255.255.192.0


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

3 3IP Backhaul implementation

Overview.................................................................................................................................................................................................................................

Purpose

This chapter describes activities and processes needed to implement IP Backhaul.

Contents

Implement and build the IPBH network 3-3

Implementation of IPBH 3-3

Pre-conversion: Install IP network 3-6

IPBH network elements checklist 3-9

Pre-conversion: Prepare 5ESS DCS for IPBH 3-13

Prepare 5ESS DCS for conversion 3-14

Pre-conversion: Prepare 1X RNC for IPBH 3-17

1X RNC implementation overview 3-18

Install IPBTS Gateway 3-20

Pre-conversion: Prepare FMM-AP and RCS for IPBH 3-32

FMM-RCS implementation 3-33

Provision ecp form 3-34

Configure FMM-RCS IP Integrity Manager 3-37

Provision apeqp form 3-38

Retrieve Backplane Serial Number (BPSN) 3-41

Provision cell2 form 3-44

Provision cdmeqp form 3-49

Provision btseqp form 3-50

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-1

Post deployment 3-51

Post deployment activities 3-51

Delete DS1/DS0s used with FR-based FMM-RCS 3-52

IP Backhaul implementation Overview

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Implement and build the IPBH network

Implementation of IPBH.................................................................................................................................................................................................................................

Purpose

This section describes IPBH implementation in an existing Lucent TechnologiesCDMA network.

This document assumes that the RMT capability at the MSC feature is enabled. Whenthe RMT capability at the MSC feature is not enabled, a cell site visit is required.

Implementation phases

All IPBH implementation is done in phases from the MSC when the RMT capability atthe MSC feature is enabled:

Table 3-1 Phases of IPBH implementation

Phase Activity

Pre-conversion Activities that are done without impact onstable/transient calls:

• installation of IP network (routers andswitches).

• update of database parameters.

• installation of new hardware to support Release25 or later software.

• update to Release 25 or later software throughretrofit activities.

• retrieval of backplane serial numbers (BPSN)that are unique in the cell site for IPBHprovisioning.

See theFlexent® Wireless NetworksBTSconversion from LAPD to IPBH,401-612-841 formore information.

IP Backhaul implementation

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-3

Table 3-1 Phases of IPBH implementation (continued)

Phase Activity

Conversion These activities are described in theFlexent®/Autoplex® Wireless NetworksBTSconversion from LAPD to IPBH,401-612-841.

These stages support the conversion of the BTSfrom FR to IPBH:

• Access to the BTS

• When IP connectivity is available through FRor adjacent switches or edge routers in an IPBHnetwork, a cell site visit is not required

• Configures BTS for IPBH mode

• Fallback allows the user to reverse theconversion, and return the BTS to thepre-conversion state of frame relay.

• Commits network for conversion of final URCfrom FR to IPBH.

Post deployment Identifies process to reclaim FR resources andclean up provisioning.

See“Post deployment activities” (p. 3-51).

Minimized outage time for IP conversion

Converting a frame relay (FR) packet pipe backhaul to IP Backhaul requires changes toboth the MSC (ECPC, 5ESS DCS and RNC) and the BTS. Most changes to the IPnetwork, MSC and BTS can be executed before the final cutover, minimizing serviceoutage time.

Important! During conversion a URC will go out of service (OOS) for a time asthe RCS is restored.

During implementation, the following network elements are grown in, modified orreconfigured:

Table 3-2 FR to IPBH implementation functions

Network Element Activity Purpose

IP Backhaul implementation Implementation of IPBH

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 3-2 FR to IPBH implementation functions (continued)

IP network Grow in Edge routers andadjacent switches for IPBackhaul network.

Allows IP connectivity betweenBTS and MSC.

The IP Backhaul transportnetwork is established to allow IPconnectivity between BTS andMSC by adding edge routers andswitches.

ECPC Update parameters. Activates feature and updateshardware configuration.

Provisioning and configurationparameter updates are applied forIP Backhaul.

1X RNC Grow in, if needed, newGICC and configure.

Provides equipment for dataoffload to the RNC BHS.

The RNC is installed andconfigured with hardware andsoftware to include the backhaulserver (BHS) for backhauloffload.

5ESS DCS Grow in and configure PSU. Provides BHS for voice and datain the packet switching unit(PSU).

The 5ESS DCS is installed andconfigured with hardware andsoftware to include the PSU andBHS.

BTS Software upgrade andreconfiguration of URCs.

Converts URCs from FR to IPBH.

IP Backhaul implementation Implementation of IPBH

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-5

Pre-conversion: Install IP network.................................................................................................................................................................................................................................

Purpose

Planning and installation of an IP network is determined by each customer to meetnetwork requirements. The IP network transports traffic between the cells and theMSC. The components of the network. Installation of the IP network is available as aservice from Lucent Worldwide Services. Contact your Lucent Technologiesrepresentative for further information.

Install IP routers and switches

The network transport portion of the IPBH architecture resides between the cell sitesand the Mobile Switching Center (MSC). Its purpose is to transport traffic between thecells and the MSC components. illustrates the general network topology in a duplexconfiguration. The Automatic Protection Switching (APS) mechanism of SynchronousOptical Network (SONET) is used to provide redundancy for router failure and OC3link failure (Active OC3 and Protect OC3).

Configure routers and switches, then verify connectivity for the following interfaces:

• between edge routers and adjacent switches

• between routers and RCS-APs

• between routers and BHSs

• between adjacent switches and BHSs on PSU

• between adjacent switches and BHSs on the RNC, if doing data offload

Figure 3-1 IPBH network topology


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

The following processes are done at the IP routers and switches for installation andconfiguration:

1. Cell IP addressing––done locally on the edge router or on an external addressserver (for example, DHCP)

2. Provision BHS connection IP address information

3. ML-PPP on the DS1 (T1/E1) interfaces

4. Traffic IP gateways (adjacent switches)

5. Control IP gateways (adjacent switches)

6. Interconnectivity between edge routers and adjacent switches.

7. Provision Diffserv properties (Diffserv codepoints and queuing properties)

8. Interface to router management system

9. Set IPBH enabled toy on thecell2 form.

History logging

In order to support troubleshooting and problem resolution, Lucent Technologiesrecommends the switches be configured to enable history logging. If the switch in yournetwork does not store this information on the switch, a separate server will be neededto store the data. Lucent Technologies recommends storage of this data on acustomer-controlled network server using the same practices used for other networkdata (for example, SNMP data). See your vendor documentation for specificinformation on logging and file storage.

Multi-link Groups and DS1 (T1/E1) interfaces

The MLPPP consists of individual DS1s from the URCs aggregated into a Multi-linkGroup (MLG). The MLG allows IP packets to traverse from the URC to the router.The MLGs are concentrated into OC3s, and forwarded to the routers. There aremultiple OC3s that are linked to the routers. MLG size for the URC I varies from 1 to4, for a URC II, the size varies from 1 to 8. Specific MLG size is determined by theuser.

At the DS1 concentrator, the MLGs from the URC are concentrated onto channelizedOC3 interfaces and mapped into a single OC3. The DS1 s that make up an MLG needto be carried on the same OC3. The DS1 concentrator forwards the MLGs to therouters.

The router is provisioned for the size of the MLG. Initial configuration occurs for theMLG, then for the DS1 s.

IP Backhaul implementation Pre-conversion: Install IP network

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-7

The following are general configuration guidelines for router configuration:

Parameter Description Value

Encapsulation Multilink PPP On

PFC, ACFC Packet Headercompression

On

Fragment Delay, Threshold Maximum fragment size >UDPmux packet size, 384bytes is acceptable

Minimum Links Minimum links in DS1 1

IP Source address IP address for routerside of Multilink group

Based on IP addressingscheme

IP Destination add IP address for cell sideof MLG

Based on IP addressingscheme

Automatic protection switching

The Automatic Protection Switching (APS) mechanism of Synchronous OpticalNetwork (SONET) is used to provide redundancy for router failure and OC3 linkfailure. Using APS, one router is configured as the working OC3 and the other as theprotect router. If a failure occurs on the working OC3 link an APS switchover occursto the protect OC3. The failure of the working OC3 can be caused by the physical linkor the hardware on the router associated with the OC3.

The following OC3 APS features are supported by both the DS1 concentrator and therouter:

• Non revertive

• 1+1

• STS

• Bidirectional APS

Reference

Refer to your individual router documentation for details.

IP Backhaul implementation Pre-conversion: Install IP network

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

IPBH network elements checklist.................................................................................................................................................................................................................................

Overview

The elements required for an IPBH network are identified as:

• Hardware requirements

• Cabling requirements

• Software requirements

• Subnetwork and IP addressing requirements

Hardware requirements checklist

The following table lists the new hardware required for IPBH when it is added to anexisting network.

Table 3-3 IPBH new hardware requirements checklist for an existing network

Networkelement

New hardware Check

BTS BTS with one of the following types of cells:

• BTS/Modular cell/Modular cell 4.0 with URC or URC-II

• BTS/Modular cell/HD 4.0 with URC or URC-II

• BTS/Modular cell/Modular cell 4.0 Compact with URC orURC-II

• BTS/Modular cell/Modular cell 1/2/3 with URCm card

5ESS DCS PSU2e, PHE3

FMM-RCSAP

NA

1X-RNC Two backhaul server GICCs for Ethernet connection

Two newrouters

For each router, the following are needed:

• 2 new OC-3c modules

• 2 new AP PICs

TwoSwitches

Varies by configuration as to the type of switch used.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-9

Cabling requirements checklist

The following table lists the cables required for physically connecting IPBH networkelements.

Table 3-4 IPBH cabling requirements checklist

Connection Cable type Check

BTS to patch panel T1

Patch panel to PSAX Centrix (24 T1s)

AP frame to L2 switch Cat5

PHE-3 to L2 switch Cat5e

1X RNC to L2 switch MM fiber

Router to L2 switch MM fiber

Router to PSAX MM fiber

Software requirements checklist

The following lists the software that must be installed on each of the IPBH networkelements.

Table 3-5 IPBH software requirements checklist

Network element Software Check

ECP ECP Release 25.0 and later

5ESS DCS 5e19.1 (generic) release for R25.0 and later NAR

5ee16.l (generic) release for R26.0 International

1X-RNC ECPRelease 26.0 and higher

RCS-AP (FMM-AP) ECP Release 26.0 and higher

BTS BTS release 26.0 and higher:

• Modular cell 4.0, HD 4.0 and Compact 4.0

• Modular cells 1, 2, and 3

IP Backhaul implementation IPBH network elements checklist

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Subnetworks and IP addressing requirements checklist

Table 3-6 IPBH component IP addressing




RCS-AP

28 Frames

3 AP*8 drawers 2 IP addresses perAP

/21 to host 2048

21 subnet addresses,two VLANS per APF

5ESS DCS

64 SMs per DCS(up to 192)

10 BHS/PSU 2+1 VIP per BHS 26 subnet addressesper service module(SM), each SM usesone VLAN

1X RNC

15 RNCs

3 GICC pairs perRNC

2 + 1 VIP perGICC pair

/28 per RNC for upto 15 (subnet 24)

BTS

600 BTSs

12 UrcS/ BTS

1 MLG per URC

Static: 2 IPaddresses per MLG

Dynamic: pool orIP addresses perMLG

Pair of subnetaddresses per URC,30 subnet addressesfor static ML-PPPaddress

AP control VLAN (subnet)

The AP control VLAN supports the signaling traffic between the backhaul cells and theECP. The following table lists the number of IP subnets needed for this VLAN. TheAP control VLAN requiresthreesubnets, with a total offourteenIP addresses.

Table 3-7 AP VLAN checklist

Subnetwork Host IP address Check

xxx.xxx.xx.a BHCS xxx.xxx.xx.a1

Router interface 1 xxx.xxx.xx.a2

Router interface 2 xxx.xxx.xx.a3

Default Gateway xxx.xxx.xx.a4

xxx.xxx.xx.b FMM-RCS AP 1 xxx.xxx.xx.b5

FMM-RCS AP 2 xxx.xxx.xx.b6

Router interface 1 xxx.xxx.xx.b7

Router interface 2 xxx.xxx.xx.b8

Default Gateway xxx.xxx.xx.b9


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-11

Table 3-7 AP VLAN checklist (continued)


xxx.xxx.xx.c FMM-RCS AP 1 xxx.xxx.xx.c10

FMM-RCS AP 2 xxx.xxx.xx.c11

Router interface 1 xxx.xxx.xx.c12

Router interface 2 xxx.xxx.xx.c13

Default Gateway xxx.xxx.xx.c14

BHS VLAN

The BHS VLAN supports the BHSs on both the 5ESS DCS and the 1X-RNC. TheBHS VLAN carries the traffic packets as they are sent to the BHSs from the backhaulcells and to backhaul cells from the BHSs. The BHS VLAN requires one subnet, witha total of nine IP addresses.

The following table lists the IP subnets needed for this VLAN.

Table 3-8 BHS VLAN IP checklist


xxx.xxx.xx.d 5ESS BHS interface 1 to L2switch 1

xxx.xxx.xx.d15

xxx.xxx.xx.e 5ESS BHS interface 1 to L2switch 2

xxx.xxx.xx.e16

xxx.xxx.xx.f 5ESS DCS BHS interface 2 toL2 switch 1

xxx.xxx.xx.f17

xxx.xxx.xx.g 5ESS DCS BHS interface 2 toL2 switch 2

xxx.xxx.xx.g18

xxx.xxx.xx.h 1X-RNC/TPU 1 to L2 switch1

xxx.xxx.xx.h19

xxx.xxx.xx.i 1X-RNC/TPU 2 to L2 switch2

xxx.xxx.xx.i20

xxx.xxx.xx.j Router interface 1 to L2switch 1

xxx.xxx.xx.j21

xxx.xxx.xx.k Router interface 2 to L2switch 2

xxx.xxx.xx.k22

xxx.xxx.xx.l L2 switch 1 to L2 switch 2 xxx.xxx.xx.l23


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Pre-conversion: Prepare 5ESS DCS for IPBH

Overview.................................................................................................................................................................................................................................

Purpose

This section describes the activities required for preparing the 5ESS DCS for IPBHnetwork.

Contents

Prepare 5ESS DCS for conversion 3-14


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-13

Prepare 5ESS DCS for conversion.................................................................................................................................................................................................................................

Install and configure new hardware and software

Installation and configuration on the 5ESS-DCS establishes the backhaul server (BHS)for the IPBH network. Hardware and software installation are described in detail in the5ESS-DCS documentation including the necessary requirements for connectivitybetween the BHS at the 5ESS DCS and the IP Backhaul network.

All PHVs must be on ECP Release 24.0.

The following activities prepare the 5ESS DCS for IPBH configuration:

• DCS software upgrade to R25

• SMP upgrade to Core700

• PSU2 upgrade to PSU2e

Reference

The following 5ESS DCS documents contain step-by-step information:

• See the following sections in the5ESS® Switch Applications Manual,235-200-100(NAR) or :5ESS® Switch Applications OA&M Manual,5AP:

– IPBH (PHE3) Provisioning,

– IPBH (PHE3) Deprovisioning

– PH Growth

– PH Degrowth

• See the following sections in the 5ESS® Switch Flexent®/ AUTOPLEX® WirelessNetworks Applications OA&M Manual (5AP) International:

– PHE3 Provisioning, PHE3 Deprovisioning

– Deprovisioning Channel Groups

– PHE3 Growth

– PHE3 Degrowth


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

5ESS DCS provisioning

Figure 3-2, “5ESS DCS provisioning for IPBH” (p. 3-15)identifies the RC Viewscreens and activities in provisioning the 5ESS DCS.

Provisioning activities at the 5ESS DCS include:

• DCS software update to R25 or later.

• SMP upgrade to Core700.

• PSU2 upgrade to PSU2e

• The BPH pair that runs active/active must be installed across two shelves.

• Install and configure a pair of BPHs in each PSU2e that will terminate IPBH.Enter and update the 5ESS Recent Change View forms:

1. RC View 22.32 (9.37 INTL)––BPH specific data: Define PH group andcommon BPH attributes such as overload thresholds, and 1st hop routerconnectivity checking parameters.

2. RC View 33.1 (90.5 INTL)––BPH IP attributes: For each BPH of the PH group,define IP, ICMP, and UDP parameters.

3. RC View 33.4 (90.7 INTL)––BPH Ethernet link attributes: For each BPH of thePH group, assign the serving and non-serving IP addresses, etc.

Figure 3-2 5ESS DCS provisioning for IPBH

IP Backhaul implementation Prepare 5ESS DCS for conversion

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-15

4. RC View 33.3 (90.6 INTL)––BPH router attributes: For each BPH of the PHgroup, define the router IP address.

5. RC View 22.32 (9.37 INTL)––Assign BPHs to a PH group: Complete the PHgroup definition by populating the BPH position of the 2 BPHs.

PSU growth

Note that the PSU unit must be grown before the protocol handlers.

See PSU Growth in5ESS® Switch Flexent®/Autoplex® Wireless NetworksApplicationsManual,235-105-231.

PHE3 growth

See PHE3 Growth in5ESS® Switch Flexent®/Autoplex® Wireless NetworksApplications Manual,235-200-100.

The PHE is the protocol handler for Ethernet.

PH Provisioning

See PHE3 Provisioning in5ESS® Switch Flexent®/Autoplex® Wireless NetworksApplications Manual,235-200-100.

IP Backhaul implementation Prepare 5ESS DCS for conversion

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Pre-conversion: Prepare 1X RNC for IPBH

Overview.................................................................................................................................................................................................................................

Purpose

This section describes the activities required for preparing the RNC as part of an IPBHnetwork.“OMC-RAN user interface” (p. 4-49)

Contents

1X RNC implementation overview 3-18

Install IPBTS Gateway 3-20


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-17

1X RNC implementation overview.................................................................................................................................................................................................................................

Requirements for setup

All PHVs and RNCs supporting cells in the soft handoff universe must be upgraded toRelease 25 or later.

When the optional RNC is used, the following activities must be completed prior tostarting any conversion activities:

1. If doing data offload, install RNC with R25 or later software.

2. Install and configure primary BHS (GICC pair) and optional secondary BHS onRNC at the TPU-GUI. See“Install and configure IPBTS GW hardware andsoftware ” (p. 3-18).

Install and configure IPBTS GW hardware and software

The RNCn installation and configuraiton for IPBH is done at the the 1X RNC, asillustrated inFigure 3-3, “1X RNC provisioning for IPBH” (p. 3-18). This includesInstallation and configuraiton of the the BHS on the IPBTS GW in the RNC to set upthe connectivity between the BHS (on the BHS GICDC) and the IP Backhaul network.

Figure 3-3 1X RNC provisioning for IPBH

Assign IPBTS GW

GICC

TPU-GUI

Provision BHS IP

attributes

TPU-GUI

Install IPBTS GW

GICC

IPBTS GW-

Upper

IPBTS GW –

Lower

GICC (upper)

GICC (lower)

BHSProvision GICC

IP attributes

TPU-GUI

Assign IPBTS GW

GICC

TPU-GUI

Provision BHS IP

attributes

TPU-GUI

Install IPBTS GW

GICC

IPBTS GW-

Upper

IPBTS GW –

Lower

GICC (upper)

GICC (lower)

BHSProvision GICC

IP attributes

TPU-GUI


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Procedures for GICC card installation and configuration

The following procedures are needed to install the GICC card:

• Installation––install and cable the IPBTS GW GICC pair. See“Physical GICC cardinstallation” (p. 3-21).

• Identify the IPBTS GW GICC at the TPU-GUI–assign the GICC pair that willprovide the IPBTS GW function. See“Add and configure GICC pair on TPU-GUI”(p. 3-22).

• Provision GICC IP attributes at the TPU-GUI–for each LAN port, define its fixedaddress for ARPs with the first hop router and IP address of the first hop router onthe BHS Level IPBH Parameters page.

• Provision BHS IP attributes–assign the BHS IP address and establish BHS loadingthreshold parameters.

See“Install IPBTS Gateway” (p. 3-20)for detailed steps.

IP Backhaul implementation 1X RNC implementation overview

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-19

Install IPBTS Gateway.................................................................................................................................................................................................................................

When to use

Use this procedure to install the GICC for an IPBTS GW in an existing 1X RNCnetwork.

The following separate procedures are included:

1. “Physical GICC card installation” (p. 3-21)

2. “Physically connect the cable” (p. 3-22)

3. “Add and configure GICC pair on TPU-GUI” (p. 3-22)

GICC card redundancy

GICC cards are always grown in pairs.

The main advantages are:

• Simplified GICC card level engineering

• A pair of GICCs use Virtual Switch Redundancy Protocol (VSRP), which is similarto Virtual Router Redundancy Protocol (VRRP like), to provide service redundancy.

Important! IPBH is only supported on the GICC 1.1. Before putting a GICC pairinto service, both GICCs in the pair must be GICC 1.1 for IPBH.

GICC population rules

The GICC cards are grown in pairs starting with slot 20, then slot 4, and finally slot19.

Required materials

The following materials are needed for GICC installation:

• GICC card(s)

• Optical (OC3) fiber cables: OC3 may be Single-Mode Fiber (SMF) or Multi-ModeFiber (MMF), duplex or simplex, and crimp (ST) or push-pull coupling (SC).

Required interface

Access to the TPU-GUI is required for provisioning the GICC.

Before you begin

Prior to IPBTS GW GICC installation, be sure the following has occurred:

• The appropriate switches have been provisioned to accommodate the intendedgateways.

• The GICC cards (slot 3) provide the TPU Shelf Controller (SC) function.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

• Determine the slots to be grown from the available growth slots.

• Ask your network administrator for the values for the RNC Level IPBHparameters, if necessary.

• When replacing a GICC, always verify that the mate GICC to which you intend toswitch is not alarmed.

Physical GICC card installation

CAUTION

ESD hazard

To prevent damage to the integrated circuits on the cards, Electrostatic DischargeProtection (EDP) must always be used.

Electrostatic Discharge (ESD) protective straps, shoes or mats must be used whenworking with these cards.

To physically install a GICC card and connect the cables:

.................................................................................................................................................................................................

1 Run GigE cables from the 1X RNC cabinet to the L2 switch for each GICC in theupper and lower shelf. The cable should be routed through the Frame Interface Panel(FIP).

.................................................................................................................................................................................................

2 Begin installation of the GICCs in the upper shelf after confirming the installation slotlocations in the upper and lower shelves.

.................................................................................................................................................................................................

3 Hold the GICC replacement card vertical, and slide it firmly into the slot between thetwo guides, then lock the upper and lower levers.

Result: The Power/Fault LED light turns green.

.................................................................................................................................................................................................

4 Connect the GICC connector cables. Change the heartbeat target IP address for the oneor two equipped GigE ports on the GICC to the router’s IP address, and submit thechanges.

.................................................................................................................................................................................................

5 Tighten the card retention screw to anchor the card in the chassis.

.................................................................................................................................................................................................

6 Connect the GigE cable for PSU Gateway service. See“Physically connect the cable”(p. 3-22)for instructions.

IP Backhaul implementation Install IPBTS Gateway

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-21

.................................................................................................................................................................................................

7 Perform Step 4 through Step 6 for the GICC in the lower shelf.

Physically connect the cable

Use this procedure to install GigE cable(s) prior to performing provisioning andconfiguration procedures.

To install a GigE cable, do the following:

.................................................................................................................................................................................................

1 Run the GigE cable from the 1X RNC cabinet to the L2 switch. (The cable should berouted through the Frame Interface Panel (FIP).

.................................................................................................................................................................................................

2 Connect the cables for the PSU Gateway service as applicable.

Add and configure GICC pair on TPU-GUI

This procedure adds and configures the GICC card pairs through the TPU-GUIConfiguration Wizard.

To add and configure GICC cards:

.................................................................................................................................................................................................

1 Obtain access to the TPU-GUI either directly or through the EMS.

If using EMS, at the OMP Web page, select1X RNC TPU Web.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

E N D O F S T E P S.................................................................................................................................................................................................

E N D O F S T E P S.................................................................................................................................................................................................

Result: The 1X RNC TPU Web page displays:

.................................................................................................................................................................................................

2 Do one of the following:

• On the OMP Web tool bar on the left side of the page, use the drop-down list inthe upper left corner of the page to select the RNC to be configured.

• On the 1X RNC TPU Web page, selectConfiguration Data .


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-23

The RNC Configuration Data page displays.

.................................................................................................................................................................................................

3 On the RNC Configuration Data page under Wizards, selectGICC Growth .

Result: The Grow GICC - Warning Message page displays the following message:

GICCS should be grown in pairs.

Ensure that the GICCs are placed in the respective slots before proceeding.

Note that if the prerequisites have not been met and you continue to configure theGICCs, alarms will be generated.

.................................................................................................................................................................................................

4 SelectNext.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Result The Grow GICC-GICC Selection page displays.

.................................................................................................................................................................................................

5 To grow in an IPBTS GICC, do the following:

1. FindGICC # area onShelf 1: Working GICCS for the slot being grown in.

2. By GICC Type , use the drop-down list and selectIPBTS.

3. FindGICC # area onShelf 2: Protection GICCS for the slot being grown in.

4. By GICC Type , use the drop-down list and selectIPBTS.

5. ChooseNext to continue.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-25

Result The BHS Level IPBH Parameters page displays.

.................................................................................................................................................................................................

6 ChooseAdd , then enter the BHS IP address, subnet mask and UDP port.

.................................................................................................................................................................................................

7 SelectNext .


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Result The RNC Level IPBH Parameters page displays.

.................................................................................................................................................................................................

8 Enter new critical threshold values for the displayed parameters if desired. If there isno change, proceed toStep 9.

.................................................................................................................................................................................................

9 SelectNext .


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-27

The External IP packet Data Network page displays for you to review the GICCinformation.

.................................................................................................................................................................................................

10 SelectNext .


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

The Summary Page displays all the set up information ready for submission.

.................................................................................................................................................................................................

11 SelectSubmit .

Result The Confirm box displays the question:Are you sure you want to Growselected GICCs?

.................................................................................................................................................................................................

12 SelectYes.

Result The Message box displays:Request to grow GICC(s) processedsuccessfully!

.................................................................................................................................................................................................

13 SelectOK.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-29

Result The RNC Configuration Data page displays.

.................................................................................................................................................................................................

14 Important! Depending on system activity, successful growth of a GICC mayrequire between one and two minutes before the GICC status is updated on theTPU GUI. Wait approximately two minutes before proceeding.

Select theTPU WEB button to return to the main1X RNC TPU Web page, then selectNetwork Elements

Result The Traffic Processing Unit (TPU) page displays.

.................................................................................................................................................................................................

15 At the Filter: box, selectIPBTSto filter the information display.

Result The list for the TPU displays information only for the IPBTS.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

.................................................................................................................................................................................................

16 Determine the state of the new GICC by reviewing the Admin State, Oper State andUsage State.

Result The new GICC could be in any of the following states. The states varydepending on whether the card is factory-new or is being reused.

The GICC comes up as:

Admin State Oper State Usage State

Unlocked Enabled Idle or Active

Locked Enabled Idle or Active

Unlocked Disabled Idle or Active

Locked Disabled Idle or Active

See Flexent® Wireless Networks 1X Radio Network Controller (RNC) Operations,Administration, & Maintenance,401-710-082 for details on the operating states.

.................................................................................................................................................................................................

17 Click in Commands, and selectReset.

Result The GICC should return to:

• Admin State––Locked

• Oper State––Disabled

• Usage State––Idle

.................................................................................................................................................................................................

18 Perform an “unlock” of the GICC via theCommands column of theTPU NetworkElements page

Result The GICC card is now in service.

E N D O F S T E P S........................................................................................................................................................................................................................


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-31

Pre-conversion: Prepare FMM-AP and RCS forIPBH

Overview.................................................................................................................................................................................................................................

Purpose

This section describes the activities required for preparing the FMM-AP and itsassociated processors as part of an IPBH network.

Contents

FMM-RCS implementation 3-33

Provision ecp form 3-34

Configure FMM-RCS IP Integrity Manager 3-37

Provision apeqp form 3-38

Retrieve Backplane Serial Number (BPSN) 3-41

Provision cell2 form 3-44

Provision cdmeqp form 3-49

Provision btseqp form 3-50


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

FMM-RCS implementation.................................................................................................................................................................................................................................

Provision FMM-RCS for IPBH

Provisioning the FMM-RCS to support IPBH involves performing the followingprocedures in the order given:

1. Provision IP Backhaul Control Network ID field on the ecp form.

2. Configure FMM-RCS IM.

3. Provision RCS IP services using theapeqp form.

4. Provision primary and alternative APs on thecmodeqp form.

5. Retrieve BPSNs

6. Provision Carrier/SOC data on thecell2 form.

7. Provisioncdmeqp form.

8. Provisionbtseqp form.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-33

Provisionecp form.................................................................................................................................................................................................................................

Purpose

Use this procedure to provision fields on the ecp form that are associated withconverting the FMM-RCS (AP-RCS) to support IPBH.

ecp form-IPBH fields

Table 3-9, “ecp form-IPBH fields” (p. 3-34)lists all of the IPBH field, describes theirpurpose and lists valid values for that field.

Table 3-9 ecp form-IPBH fields

Field name Description Validvalues

Restriction

IP BackhaulControlNetwork ID

This field identifies the IP Backhauladdress in four parts (octets):

• IP Address part 1




0-255 Indicates the 21-bit networkprefix that determines theaddress space for the IPBHcontrol network. This networkis split in half to create twosubnets: Lan0 and Lan1.

BHCSFailureReportingInterval

The provisionable interval when theMSC will report invalid attemptstatistics regarding BTSauthentication.

0-60minutes;

Default=15minutes

Any change would take effectat the beginning of the nextreporting interval.

DefaultTrafficDiffservCodepoint

This field is the default DiffservCodepoint that will be applied to alltraffic not assigned to the higherpriority traffic classes

0

Default=0

User ClassTrafficDiffservCodepoint

This field is the Diffserv Codepointthat will be applied to all traffic notassigned tot he higher priority trafficclasses.

0-63

Default=46

If you make a change to acodepoint on this screen, youmust make a change in thecorresponding router.

SignalingClass TrafficDiffservCodepoint

This field is the Diffserv Codepointthat will be applied to all signallingclass traffic.

0-63

Default=10

If you make a change to acodepoint on this screen, youmust make a change in thecorresponding router.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 3-9 ecp form-IPBH fields (continued)

Field name Description Validvalues

Restriction

BackhaulConnectionServer Lan0IP address

Identifies the Backhaul ConnectionServer Lan0 IP address.

This address is in four parts (octets:

• LAN0 IP Address part 1




0-255 Populated from IPBH ControlNetwork ID

(Display only field)

BackhaulConnectionServer Lan1IP address

Identifies the Backhaul ConnectionServer Lan1 IP address.








Lan0BackhaulConnectionServerGateway IPAddress

Indicates the Lan0 gateway IPaddress for the BHCS on the IPBHnetwork. This is the IP address wherethe BHCS directs traffic outside ofLan0.








Lan1BackhaulConnectionServerGateway IPAddress

Indicates the Lan1 gateway IPaddress for the BHCS on the IPBHnetwork. This is the IP address wherethe BHCS directs traffic outside ofLan1.








IP Backhaul implementation Provision ecp form

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-35

Before you begin

You must know the fields and valid values needed for converting the AP-RCS tosupport IPBH.

Refer to the frequency and impacts of performing this procedure

Frequency

Lucent Technologies does not recommend changing the IP Backhaul Control NetworkID field except during a scheduled retrofit.

Impacts

Changing the IP Backhaul Control Network ID field while the system is running maycause the IP addressing for the APs, BHCS, and ECP to become out of sync. Tocorrect this problem, a system restart is needed. Lucent Technologies recommendschanging this field only during a scheduled retrofit as a system restart is alreadyplanned.

Procedure

.................................................................................................................................................................................................

1 Launch the RC/Vecp form.

.................................................................................................................................................................................................

2 Advance to theIP backhaul Information Only screen.

.................................................................................................................................................................................................

3 Populate the IPBH fields as given inTable 3-9, “ecp form-IPBH fields” (p. 3-34).

Result

The first step of provisioning the FMM-RCS (AP-RCS) for IPBH is complete. Go to“Configure FMM-RCS IP Integrity Manager ” (p. 3-37)for the next procedure.

IP Backhaul implementation Provision ecp form

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

E N D O F S T E P S.................................................................................................................................................................................................

Configure FMM-RCS IP Integrity Manager.................................................................................................................................................................................................................................

Purpose

Use this procedure to configure the RCS-IP integrity manager (IM). This proceduremust be done before provisioning theapeqp form.

The RCS-IM

• Requests the start/stop of RCS-IP instances

• Promotes/demotes RCS-IP instances

• Maintains status dependent resources

• Allows/disallows Remove and Restore commands

• Enforces preference for primary selection in an RCS-IP pair

• Throttles restarts of RCS-IP instances

• Logs all RCS-IP events

• Validates RCS-IP state management

Before you begin

The IP Backhaul Control Network ID field must be provisioned on theecp form. See“Provision ecp form ” (p. 3-34).

Procedure

.................................................................................................................................................................................................

1 Log into the OMP as root.

.................................................................................................................................................................................................

2 Enter the following command to configure the RCS-IS:

apappconfig -c -a IS -p ap### -s ap###

Result

The RCS-IM has been configured. Continue with“Provision apeqp form” (p. 3-38).


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-37

E N D O F S T E P S.................................................................................................................................................................................................

Provisionapeqp form.................................................................................................................................................................................................................................

Purpose

Use this procedure to provision the IPBH related fields on theapeqp form.

apeqp form-IPBH fields

Table 3-10, “apeqp form-IPBH fields” (p. 3-38)lists all of the IPBH fields used on theform, describes their purpos,e and lists valid values for that field.

Table 3-10 apeqp form-IPBH fields

Field Description Valid values

RCS IP ServicesEnabled

Indicates whether or not IPBH signalingservices are enabled on this AP.

Y or N

Default = n

RCS-IM Exists Indicates whether or not the RCS-IM hasbeen configured.

This field is set to “y” for APs specifiedusing the apappconfig command.

Y or N

Default = n


Interface 0Backhaul IPAddress

Indicates the AP’s IP address on the IPBHControl Network for its interface 0.

This field identifies the IP address in fourparts (octets):





0-255

Default = 0


Interface 1Backhaul IPAddress

Indicates the AP’s IP address on the IPBHControl Network for its interface 1.






0-255

Default = 0



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 3-10 apeqp form-IPBH fields (continued)


Lan0 DefaultGateway IPAddress

Indicates the Gateway IP address for the APLan0.






0-255

Default = 0


Lan1 DefaultGateway IPAddress

Indicates the Gateway IP address for the APLan1.






0-255

Default = 0


Before you begin

Make sure the following have been completed:

• You know the fields and valid values needed for converting the FMM-RCS tosupport IPBH.

• The IP Backhaul Control Network ID field has been provisioned on theecp form

• The RCS IM has been configured.

Procedure

.................................................................................................................................................................................................

1 Launch the RC/Vapeqp form.

.................................................................................................................................................................................................

2 Advance to theIP Backhaul configuration screen.

.................................................................................................................................................................................................

3 EnterY in the field RCS IP Services Enabled.

IP Backhaul implementation Provision apeqp form

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-39

All other fields on theapeqp form are based on data entered on theecp form. See“Provision ecp form ” (p. 3-34)for entry of ecp information for IPBH.

.................................................................................................................................................................................................

4 Save and exit the form. For complete information on all fields on this screen, seeTable3-10, “apeqp form-IPBH fields” (p. 3-38).

Result

This step of provisioning the FMM-RCS for IPBH is complete. Continue on to“Retrieve Backplane Serial Number (BPSN)” (p. 3-41).

IP Backhaul implementation Provision apeqp form

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

E N D O F S T E P S.................................................................................................................................................................................................

Retrieve Backplane Serial Number (BPSN).................................................................................................................................................................................................................................

Purpose

Use this procedure to run the command to retrieve the backplane serial numbers(BPSN) and place it in thecdmeqp database.

The BPSN is on the BTS at the cellsite, and is unique per assemblage. During cellinitialization, an IP-based cell passes this number to the MSC, where the MSCcompares it to the BPSN stored at the MSC.

Before you begin

This procedures requires an active signalling link to cells that are on Release 25 orlater.

User interface

This procedure requires execution of TICLI commands from either the TICLI or theOMC-RAN TICLI.

Procedure

.................................................................................................................................................................................................

1 Log into the TICLI/OMC-RAN TICLI.

.................................................................................................................................................................................................

2 Retrieve the BPSN by entering one of the following commands:

If you need to then enter where

Retrieve the BPSN fromcell numberx

UPDATE:CELL x, BPSN wherex=cellnumber.

Retrieve the BPSN fromall active cells

UPDATE:CELL ALL, BPSN

Retrieve the BPSN fromall active cells on APnumber y

UPDATE:AP y, BPSN wherey=APnumber.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-41

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Result: The valid BPSN of the cell is inserted into thecdmeqpdbfile and thesuccess or failure of the cell update is displayed.

If cell update was then the command output

a failure wasreported

displays only the BPSN information from the database for thecell.

Successful displays the equipped assemblage information, along with theBPSN and an indication of whether the BPSN was changed dueto the update or not.

The following output example is from theUPDATE: AP command. Each character inan invalid BPSN is represented by two hex digits.

UPDATE:AP 31,BPSN! IN PROGRESSCELL ASMB BPSN ACTION PERFORMED144 1 0x0b07090c0b0b0b0b0b0b0b41 RECD INVALID

BPSN FROMCELL, DB NOT UPDATED150 1 sprcs0000150 BPSN READ FROM DB, CELL NOT ACTIVE151 1 sprcs0000151 BPSN READ FROM DB, CELL NOT ACTIVE152 1 sprcs0000152 BPSN READ FROM DB, CELL NOT ACTIVE153 1 sprcs0000153 BPSN READ FROM DB, CELL NOT ACTIVE154 1 sprcs0000154 BPSN READ FROM DB, CELL NOT ACTIVE155 1 sprcs0000155 BPSN READ FROM DB, CELL NOT ACTIVE156 1 sprcs0000156 BPSN READ FROM DB, CELL NOT ACTIVE157 1 0x0b07090c0b0b0b0b0b0b0b41 RECD INVALID BPSN FROM

CELL, DB NOT UPDATED158 1 sprcs00158a1 BPSN READ FROM DB, CELL NOT ACTIVE158 2 sprcs00158a2 BPSN READ FROM DB, CELL NOT ACTIVE159 1 sprcs00159a1 BPSN READ FROM DB, CELL NOT ACTIVE159 2 sprcs00159a2 BPSN READ FROM DB, CELL NOT ACTIVE160 1 sprcs00160a1 BPSN READ FROM DB, CELL NOT ACTIVE160 2 sprcs00160a2 BPSN READ FROM DB, CELL NOT ACTIVE161 1 sprcs00161a1 BPSN READ FROM DB, CELL NOT ACTIVEORIGINATING COMMAND #329979115.32005-04-13 09:56:52 REPORT #000001EXECUTED ON PROCESSOR: AP 35

The following are some of the BPSN update error messages:

IP Backhaul implementation Retrieve Backplane Serial Number (BPSN)

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

BPSN READ FROM DB, CELL DID NOT RESPONDBPSN BLANK IN DB, CELL DID NOT RESPONDBPSN UPDATED IN DBBPSN BLANK IN DB, CELL RELEASE IPBH INCOMPATBPSN BLANK IN DB, CELL NOT ACTIVEBPSN READ FROM DB, CELL NOT ACTIVEBPSN BLANK IN DB, CELL FAILED TO GET BPSNBPSN READ FROM DB, CELL FAILED TO GET BPSNRECD DUP OF BPSN FOR CELL:130, ASM:1, DB NOT UPDATED

The first part of converting the FMM-RCS is now complete. Continueconfiguration with“Provision cell2 form” (p. 3-44).

E N D O F S T E P S........................................................................................................................................................................................................................

IP Backhaul implementation Retrieve Backplane Serial Number (BPSN)

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-43

Provisioncell2 form.................................................................................................................................................................................................................................

Purpose

Use this procedure to provision fields associated with converting the FMM-RCS tosupport IPBH on thecell2 form.

Related information

The user entering information on the cell2 form should be aware of the fields and validvalues needed for converting the FMM-RCS to support IPBH.

To use an RNC: Data offload must be on and a data offload RNC defined. Thebackhaul offload BHS is separate from the BHS defined on the SOC table. Thebackhaul offload BHSs can be provisioned on either RNCs or 5ESS DCSs, but notboth simultaneously.


cell2 form-IPBH fields

Table 3-11, “cell2 form-IPBH fields” (p. 3-44)lists all of the IPBH field, describestheir purpose and lists valid values for that field.

Table 3-11 cell2 form-IPBH fields

Field Description Valid values Restrictions

IP Backhaul Enabled Indicates whether the IPBackhaul feature has beenenabled on this cell.

Y or N All equipped carriersfor the cell must have aBHS assigned and thebackhaul mode must beIP for each equippedURC/CDM in the cellfor this field to beenabled.

Backhaul Offload Assigns all packet datatraffic for the cell to aspecific BHS as specifiedunder Backhaul Offload.

Y or N To set this field to Y,either the Primary RNCor the Primary SM fieldmust be provisioned.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 3-11 cell2 form-IPBH fields (continued)


Primary RNC Number Specifies the logical RNCnumber that will be usedby all packet data callsserved by this cell.

Blank, 1-15,step by 1

The Backhaul Offloadfield must be set to Y,Packet Core Data fieldmust beset to Y, andthe RNC must beequipped on the ecppktform for this field to beused.

Primary RNC BackhaulServer Number

Specifies the BHS numberthat is associated with theRNC GICC card for thePrimary BHS.

BHS 1 is associated withGICC slot 20, BHS 2 isassociated with GICC slot4, and BHS 3 is associatedwith GICC slot 19.

Blank, 1-3 The Primary RNCNumber field must bepopulated for this fieldto be provisionable.

Primary Switching ModuleNumber (SM)

Specifies the SM that willbe used by all packet datacalls served by this cell.

Blank, 1-192 The Backhaul Offloadfield must be set to Yand Packet Core Datafield must be N for thisfield to be used.

Primary Packet SwitchingUnit Number (PSU)

Specifies the PSU wherethe Primary BHS isinstalled.

Blank, 0 or 1 The Primary SM fieldmust be populated forthis field to beprovisionable.

Primary DCS BackhaulServer Number

Specifies the BHS numberthat equates to the DCSPH group for the PrimaryDCS BHS.

Blank, 1 to 10 The Primary SM fieldmust be populated forthis field to beprovisionable.

Alternate RNC Number Specifies the RNC wherethe Alternate RNC BHS isinstalled. The AlternateRNC BHS is used whenthe Primary RNC BHS isunavailable.

Blank, 1 to 15 The Primary RNCNumber field must bepopulated for this fieldto be provisionable.

Alternate RNC BackhaulServer Number

Specifies the BHS numberthat is associated with theRNC GICC card for theAlternate BHS.

Blank, 1-3 The Alternate RNCNumber field must bepopulated for this fieldto be provisionable.

IP Backhaul implementation Provision cell2 form

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-45



Alternate SwitchingModule Number (SM)

Specifies the SM wherethe Alternate DCS BHS isinstalled. The AlternateDCS BHS is used whenthe Primary DCS BHS isunavailable.

Blank, 1 to 192 The Primary SM fieldmust be populated forthis field to beprovisionable.

Alternate Packet SwitchingUnit Number (PSU)

Specifies the PSU wherethe Alternate DCS BHS isinstalled.

Blank, 0 or 1 The Alternate SM fieldmust be populated forthis field to beprovisionable.

Alternate DCS BackhaulServer Number

Specifies the BHS numberthat equates to the DCSPH group for the AlternateDCS BHS.

Blank, 1-10 The Alternate SM fieldmust be populated forthis field to beprovisionable.

MLG Loading BiasTranslation

BIASMLG is used by cellcall processing to computeMulti-Link Group load.When the bias is adjusted,some MLGs will beselected over others. Thisallows the backhaul trafficto be concentrated on theseMLGs and thereforeimproves the transportationefficiency

0 to 100% inincrements of10

CDMA Carrier ServiceOption Class

Specifies the type oftraffic that will be routedto the BHS.

Blank, Voice,Both

(View-only)

When the BackhaulOffload field is set toY, this field displaysVoice for a provisionedcarrier. When theBackhaul Offload fieldis set to N, this fielddisplays Both for aprovisioned CDMACarrier.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006



CDMA Carrier SwitchingModule

Specifies the SM that willbe used by all voice callsserved by this CDMACarrier. Also specifies theSM that will be used forall packet data calls whenthe Backhaul Offload fieldis set to N.

Blank, 1 to 192 This field must beprovisioned when theIP Backhaul Enabledfield is set to Y andthis CDMA Carrier isassigned a channel onthe cgsa form or thecell2 form.

CDMA Carrier PacketSwitching Unit

Specifies the PSU wherethe BHS for this CDMACarrier is installed.

Blank, 0 or 1 The Switching Modulefield for this CDMACarrier must bepopulated for this fieldto be provisionable.

CDMA Carrier BackhaulServer

Specifies the BHS numberthat equates to the DCSPH group where the BHSfor this CDMA Carrier isinstalled.

Blank, 1 to 10 The Switching Modulefield for this CDMACarrier must bepopulated for this fieldto be provisionable.

Before you begin

See the requirements before beginning this procedure.

Requirements

The following must be performed prior to executing this procedure:

• The ecp form has been provisioned with theIP Backhaul Control Network IDfield. See“Provision ecp form ” (p. 3-34).

• The IPBH RTU feature qualifier value must be large enough to add the additionalcarriers equipped for the cell.

• The RCS-IP IM has been configured. See“Configure FMM-RCS IP IntegrityManager ” (p. 3-37).

• The btseqp/cdmeqp form must be set for Backhaul mode. See“Provision btseqpform” (p. 3-50)and“Provision cdmeqp form” (p. 3-49).

• The apeqp form has been provisioned with theRCS-IP Services Enabled andRCS-IM Exists fields. See“Provision apeqp form” (p. 3-38).

• The BPSNs have been retrieved from the cells and thebtseqp/cmdeqp databasehas been updated. See“Retrieve Backplane Serial Number (BPSN)” (p. 3-41)and“Provision cdmeqp form” (p. 3-49).


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-47

Procedure

.................................................................................................................................................................................................

1 Launch the RC/Vcell2 form.

.................................................................................................................................................................................................

2 Advance to theCDMA Cell Site for IP Backhaul Information Only screens.

.................................................................................................................................................................................................

3 Populate the IPBH fields as described inTable 3-11, “cell2 form-IPBH fields”(p. 3-44).

E N D O F S T E P S........................................................................................................................................................................................................................


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Provisioncdmeqp form.................................................................................................................................................................................................................................

Purpose

Use this procedure to provision fields associated with converting the RCS to supportIPBH on thecdmeqp form. This form is used for Modular cells 1, 2, and 3.

Related information

The user entering information on thecdmeqp form should be aware of the fields andvalid values needed for converting the RCS to support IPBH.

cdmeqp form-IPBH fields

Table 3-12, “cdmeqp form-IPBH fields” (p. 3-49)lists all of the IPBH fields, describestheir purpose and lists valid values for each field.

Table 3-12 cdmeqp form-IPBH fields


Backplane Serial Number Indicates the number on theBTS that is unique perassemblage.

This value is stored in thecdmeqpdb.

Backhaul Mode Backhaul mode must be set toIP for each CDM/CRC for thecell.

FR, ATM, IP and SH

Procedure

.................................................................................................................................................................................................

1 Launch the RC/Vcdmeqp form.

.................................................................................................................................................................................................

2 Populate the Backplane Serial Number if it was not previously populated using theUPDATE:CELL x, BPSN TICLI command.

.................................................................................................................................................................................................

3 Enter the valueIP in the Backhaul modefield. SeeTable 3-12, “cdmeqp form-IPBHfields” (p. 3-49)for a list of valid values for IPBH fields.

E N D O F S T E P S........................................................................................................................................................................................................................


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-49

Provisionbtseqp form.................................................................................................................................................................................................................................

Purpose

Use this procedure to provision fields associated with converting the FMM-RCS tosupport IPBH on thebtseqp form. This form is used for One-BTS cells.

Related information

The user entering information on the btseqp form should be aware of the fields andvalid values needed for converting the FMM-RCS to support IPBH.

btseqp form-IPBH fields

Table 3-13, “btseqp form-IPBH fields” (p. 3-50)lists all of the IPBH fieldS, describestheir purpose and lists valid values for each field.

Table 3-13 btseqp form-IPBH fields


Backplane SerialNumber

Indicates the number on the BTS thatis unique per assemblage.

This value is stored in the cdmeqpdb.

Backhaul Mode Backhaul mode must be set to IP foreach CDM/CRC for the cell.

FR, ATM, IP and SH

Procedure

.................................................................................................................................................................................................

1 Launch the RC/Vbtseqp form.

.................................................................................................................................................................................................

2 Enter the valueIP in the Backhaul modefield for each CMD/CRC. SeeTable 3-13,“btseqp form-IPBH fields” (p. 3-50)for a list of valid values for IPBH fields.

.................................................................................................................................................................................................

3 Exit the btseqp form.

.................................................................................................................................................................................................

4 Launch the RC/Vcell2 form.

.................................................................................................................................................................................................

5 Set the IP Backhaul Enabled field toy,

E N D O F S T E P S........................................................................................................................................................................................................................


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Post deployment

Post deployment activities.................................................................................................................................................................................................................................

Reclaiming FR resources

The following fields are automatically cleaned up with the commit.

• Delete all the packet pipe trunk group member records for the cell’s packet pipetrunk group in thecmodpptm form.

• Delete the related record inpptg form.

• Update the record for the cell incdmeqp/btseqp form:

– The fields incdmeqp are:AP Signaling Link Information for Connections atthe AP , Digital Module Link Information for Connections at the CDM, CDMDigital Module DS1 Information (Signaling Type and Signaling/PP Data Rate),andSignaling Link Width .The fields inbtseqp are:Digital Module Signaling Link Information forConnections at the CDM , AP Signaling Link Information for Connections atthe AP, CDM Digital Module DS1 Info (Type and Data Rate), andSignalingLink Width .

• Update thecell2 form to blank theCDMA Packet Pipe Trunk Group field.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


3-51

Delete DS1/DS0s used with FR-based FMM-RCS.................................................................................................................................................................................................................................

Purpose

Use this procedure to delete DS1/DS0s that were associated with a LAPD/FR-basedRCS that has been converted to IPBH. These deleted DS1/DS0s can then be used forother purposes.

Required activities

The apeqp form must be cleaned up manually once all the LAPD-based cells usingDS1s supported by a particular AP have been converted to IP and committed. Thecommit does not do this step.

Before you begin

See the system configuration before beginning this procedure.

System configuration

The FMM-RCS must have been converted to support IPBH.

Procedure

.................................................................................................................................................................................................

1 Launch the RC/Vapeqp form.

.................................................................................................................................................................................................

2 Advance to theDS1 Configuration screen.

.................................................................................................................................................................................................

3 Change theDS1 Status to Unequipped.

.................................................................................................................................................................................................

4 Save and exit the form. For complete information on all fields on this screen, seeTable3-10, “apeqp form-IPBH fields” (p. 3-38).

E N D O F S T E P S........................................................................................................................................................................................................................


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

4 4OA&M for IP Backhaul

Overview.................................................................................................................................................................................................................................

Purpose

This chapter describes the operation, administration and maintenance (OA&M)interfaces and functions that are specific to IP Backhaul (IPBH) for all elements withinthe network.

Contents

Routers and switches 4-2

Router/switch OA&M 4-2

BTS OA&M 4-3

BTS OA&M for IPBH 4-3

MSC 4-5

FMM-AP OA&M 4-5

1X RNC OA&M 4-6

5ESS DCS OA&M 4-11

ECPC OA&M 4-21

Input/Output commands and messages 4-29

Status display pages 4-38

OMC-RAN 4-48

Monitor IPBH from the OMC-RAN 4-48

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-1

Routers and switches

Router/switch OA&M.................................................................................................................................................................................................................................

Purpose

This section describes OA&M activities for routers and mobile switching center (MSC)adjacent switches.

OA&M activities

See your vendor documentation for details on OA&M activities for your selectedrouters and switches. Ask your Lucent representative about “VRAD-5576” for specificrequirements for routers and switches.

OA&M for IP Backhaul

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

BTS OA&M

BTS OA&M for IPBH.................................................................................................................................................................................................................................

Purpose

This section describes OA&M activities for the base transceiver station (BTS).

IPBH within the BTS

The following applies to IPBH and the BTS:

• Some BTS data for IP mode can be entered while the BTS is live on frame relay(FR).

• Each BTS is assigned a primary and alternate radio cluster server applicationprocessor (RCS-AP).

• Each BTS is configured to use the desired set of backhaul servers (BHS).

• BHS IP addresses are provisioned only at the 5ESS DCS and 1X RNC.

• The ECPC selects the BHS that interfaces with a cell.

• BHS re-assignments can be done while a BTS is live.

• RCS-AP and BHS assignments and re-assignments do not require re-configurationof transport facilities.

BTS changes for IPBH

The following OA&M additions and modifications have been made for IPBH:

• IP mode data added to existing RC/V forms: See“ECPC OA&M” (p. 4-21).

• Modified Technician Interface Commands: See“Input/Output commands andmessages ” (p. 4-29).

• New and Modified Status Display Pages: See“Status display pages” (p. 4-38).

• BTS IPBH Service Measurements: SeeChapter 6, “IPBH performance measures”.

• DS1 Monitoring and recovery.

Remote maintenance terminal

The remote maintenance terminal (RMT) is software that runs on a personal computerthat can then communicate to the BTS. The RMT software communicates withsoftware running on the cell, and provides the ability to perform various diagnosticfunctions. This communication occurs through an Ethernet connection. The fullinstallation RMT software version is required to reconfigure a BTS from FR to IPBHremotely. This document assumes that the user is familiar with the use of the RMT forBTS maintenance activities.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-3

Remote access allows the RMT to communicate with a URC in a cell through theLAN connection of any FMM-AP on the same LAN as the AP managing the cellwithout having to make a cell site visit. To communicate remotely via RMT, the userconnects the PC or laptop computer with the RMT software to the LAN of an AP thatserves a particular BTS. When communication is established, RMT commands can beexecuted.

The connection status is logged using existing logging mechanisms. RMT can beconnected to any FMM-AP frame that is configured as an RCS-AP.

DS1 monitoring and recovery

When a major or critical alarm is declared on a particular DS1, an automatic recoveryprocess occurs in which the DS1 is immediately removed from the Multi-Link-Group(MLG) unless the failed DS1 is the last one in the MLG. This ensures that thesignaling links are maintained with minimal loss in capacity.

When a major or critical alarm is cleared, the DS1 must be clear of any other criticalor major alarms for at least 10 seconds before it is put back into the MLG. This isdone to filter out high-frequency transient alarm declare-clear cycles.

The following bit error rate (BER) threshold alarms are reported for the DS1s:

• BER Major Alarm – Indicates that BER exceeds the major threshold(default=5x10^-5)

• BER Minor Alarm – References the major BER alarm threshold for threshold levelfor minor alarm threshold (default threshold equals ten times less than major alarmthreshold)

Important! This threshold is tunable by Lucent Technologies. Contact your accountrepresentative for assistance.

OA&M for IP Backhaul BTS OA&M for IPBH

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

MSC

FMM-AP OA&M.................................................................................................................................................................................................................................

Purpose

This section discusses IPBH changes to OA&M for the FMM-AP.

FMM-AP changes for IPBH

IP Backhaul is supported on RCSs hosted on FMM-APs.

The following additions and modifications have beeen made for IPBH:

• New and modified Technician Interface Commands–See“Input/Output commandsand messages ” (p. 4-29).

• New and Modified Status Display Pages (SDP)––See“Status display pages”(p. 4-38).

• IPBH Service Measurements (SM)––SeeChapter 6, “IPBH performance measures”.

• IP backhaul data added to existing RC/V forms––See“ECPC OA&M” (p. 4-21).The following forms are used for IPBH:

– apeqp

– btseqp

– cell2

– cdmeqp

– cmodeqp

– ecp


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-5

1X RNC OA&M.................................................................................................................................................................................................................................

Purpose

This section discusses IPBH changes to OA&M for the 1X Radio Network Controller(RNC).

IPBTS GW on the 1X RNC

The IP Backhaul BTS gateway (IPBTS GW) is hosted on a GICC pair in the RNC.Each GICC pair hosts the active and standby backhaul servers (BHSs) that providedata offload capability.

The following additions and modifications have been made for IPBH:

• IP mode data is added to existing RC/V forms for RNC provisioning–See“RC/Vforms updated for IP Backhaul” (p. 4-21).

• Modified Technician Interface Commands–See“Input/Output commands andmessages ” (p. 4-29)for information on new 1X RNC output messages that reportBHS traffic overload, BHS port usage limit, and BHS dropped packet thresholdcrossings.

• New and modified traffic processing unit-graphical user interface (TPU-GUI)screens–See“IPBH provisioning at the RNC” (p. 4-6).

• IPBH Service Measurements–See“Service measurements” (p. 6-1).

IPBH provisioning at the RNC

The 1X RNC is provisioned initially using the TPU-GUI “First Time Wizard” thattakes the user step-by-step through RNC provisioning.

New TPU-GUI pages:

• The IPBTS is the selected GICC configuration type on the RNC ConfigurationData Screen.

• BHS Level IPBH Parameters.

• RNC Level IPBH Parameters.

Provisioning order

1X RNC provisioning for IPBH occurs for the IPBTS GW GICC pair:

1. Installation––install and cable the IPBTS GW GICC pair.

2. Identify IPBTS GW GICC at the TPU-GUI–assign the GICC pair that will providethe IPBTS GW function.

3. Provision GICC IP attributes at the TPU-GUI–for each LAN port, define its fixedaddress for ARPs with the first hop router and IP address of the first hop router.

4. Provision BHS IP attributes–assign BHS IP addresses and establish BHS loadingthreshold parameters.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

TPU-GUI screens

IPBH affects only a small number of TPU-GUI screens. For all other TPU-GUIscreens, refer to theFlexent® Wireless Networks 1X RNC OA&M Manual(401-710-082).

1X RNC configuration data

The RNC Configuration Data Screen provides two new links for BHS Level IPBHParameters and RNC Level IPBH Parameters.

Figure 4-1 RNC Configuration Data

OA&M for IP Backhaul 1X RNC OA&M

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-7

BHS Level IPBH Parameters

BHS Level IPBH Parameters allow the user to change the BHS Service IP Address,BHS Service Subnet Mask and BHS Service UDP Port for a configured IPBTS GICCPair.

Figure 4-2 BHS Level IPBH Parameters


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

RNC Level IPBH Parameters

RNC Level IPBH Parameters allow the user to enter and modify:

• Threshold values––such as BHS Loading Threshold, BHS UDP port UsageThreshold

• GigE Port IP Address, Subnet Mask and Target IP Addresses of each IPBTSGICCs.

Input/Output commands

Commands that are specific to the 1X RNC/TPU can be initiated either from theTPU-GUI or TPU-CLI.

Table 4-1 Modified 1X RNC I/O commands

Command Description

GET:RNC-TPU-STATE This command includes an IPBTS gateway option todisplay the IPBTS GW state.

SHUTDOWN:RNC-TPU This command now includes IPBTS gateway option.

GET:RNC-BHS-INFO This command retrieves BHS states, traffic loading,and requests a list of connected BTSs.

Figure 4-3 RNC Level IPBH Parameters screen


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-9

Table 4-1 Modified 1X RNC I/O commands (continued)

Command Description

LOCK-RNC-TPU IPBTS gateway information was added to thisoutput.

See“Input/Output commands and messages ” (p. 4-29)for additional information aboutthese inputs and outputs.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

5ESS DCS OA&M.................................................................................................................................................................................................................................

Purpose

IP Backhaul is supported on BHSs hosted on the 5ESS DCS. This section describesOA&M functions for both NAR and INTL markets.

5ESS DCS changes for IPBH

The following additions and modifications have been made for IPBH:

• New and modified 5ESS DCS status display page–See“Status display pages”(p. 4-38).

• New 5ESS-DCS traffic measurements–See“Service measurements” (p. 6-1).

• Note that the 1X RNC refers to the IPBTS gateway that connects the BTS to thebackhaul server (BHS) in the RNC. The gateway from the the 5ESS to the BTS issimply referred to as the BHS gateway.

BHS gateway OA&M

BHS GW characteristics:

• BHS GW 1+1 sparing consists of an active and standby BHS .

• The serving BHS receives and transmits UDPMux traffic to and from the BTS on aBHS IP address.

• Each BPH in a BHS has its own IP address.

• In the case of a switchover, the BHS IP address is moved from the active BHS GWto the standby BHS GW.

• Both BHS GWs send periodic address resolution protocol (ARP) requests to thefirst hop router to verify connectivity to the router.

• The call leg dynamic data is synchronized between the BPHs to facilitateswitchover and failover without losing stable call legs.


Failover

BPH failover will occur upon

• Ethernet failure

• Loss of connectivity to 1st hop router

• Unrecoverable HW and SW faults

The non-serving BPH, once it becomes the serving BPH, will send a gratuitous ARPfor the serving IP address and start processing the traffic. All the stable call legs arepreserved over the failover.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-11

PH group maintenance states

The BPH maintenance states are reported on MCC 1188 and MCC 118 [0-4].

See“Status display pages” (p. 4-38)to view samples of these pages.

Traffic Measurements

The TRFC30 report has been modified for IPBH:

• Section 154 IP Backhaul measurements (IPBH)

• Section 153 IP Backhaul supplemental measurements (IPBHSUP)

SeeChapter 6, “IPBH performance measures”for details on these modified reports.

5ESS DCS RC Views for IPBH provisioning

The following RC Views are used to provision IP backhaul in the 5ESS DCS:

Table 4-2 Recent Change Views for 5ESS DCS (NAR and INTL)

NAR INTL Description

22.32

BPH specific data

9.37

PHGRP

Defines PH group and common BPHattributes such as overload thresholds, andfirst-hop router connectivity checkingparameters.

33.1

BPH IP attributes

90.5

IPPRC

For each BPH of the PH group, definesits IP, ICMP, and UDP parameters.

33.3

BPH router attributes

90.6

IPRTE

For each BPH of the PH group, definesits router IP address.

RC View 33.4

BPH Ethernet linkattributes

90.7

IPETH

For each BPH of the PH group, assignsthe serving and non-serving IP addresses,etc.

5ESS DCS RC Views for IPBH provisioning (NAR)

The following RC Views are used to provision IP backhaul in the 5ESS DCS.

RC View 22.32

IPBH specific data is defined on this screen:

OA&M for IP Backhaul 5ESS DCS OA&M

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Figure 4-4 RC View 22.32 (NAR): Protocol Handler Group Definition 1 of 4

5ESS SWITCHSCREEN 1 OF 4 RECENT CHANGE 22.32(5892) PROTOCOL HANDLER GROUP DEFINITION

*1. SM ___ GENERAL PARAMETERS*2. PSU _ SECONDARY ADDR ___*3. PH GROUP __ 12. PKT BUS INTRVL ____4. APP TYPE ________ 13. L1 OVRLD THRESHOLD __

14. L2 OVRLD THRESHOLD __5. PROTOCOL HANDLERS (PHLIST) 15. CONN CHK ENABLED _

CHL PH 16. CON CHK HIGH INT __ROW PH SHELF GRP POSITION TYPE 17. CON CHK LOW INT ___1 0 _ __ __ ____ 18. CONN CHK MAX FAIL __2 1 _ __ __ ____ 19. SW OVR TIMER __



GENERAL PARAMETERS cont. IP BACKHAUL PARAMETERS20. DIFF SRV CODE POINT __ 25. BHA BASE UDP PORT _____21. RCV ICMP THRSH ___ 26. BHA PRE PORT _____22. AVG DELAY THRESHOLD ______ 27. BHA QUALITY ___23. PCT DELAY THRESHOLD ______ 28. BHA INACT TIMER __24. DELAY PERCENTAGE ___


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-13

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789



IPSHO PARAMETERS 40. IP TRAFFIC STATE _29. EXT L1 OVRLD THRESHOLD __30. EXT L2 OVRLD THRESHOLD __31. HIGH DSCP __32. LOW DSCP __33. OAM DSCP __

HIGH UDP _____LOW UDP _____OAM UDP _____NETWORK TEST UDP _____

38. HEART BEAT FREQ ____39. HEART BEAT LDI _



NPH PARAMETERS41. UDP START PORT _____42. UDP BLOCK SIZE ____43. NPH QUALITY ___44. BNID ___


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

RC View 33.1

Figure 4-8 RC View 33.1 (NAR): IP Processor Assignment 1 of 3

5ESS SWITCHSCREEN 1 OF 3 RECENT CHANGE 33.1(5987) INTERNET PROTOCOL (IP) PROCESSOR ASSIGNMENT

*1. PROCESSOR ID ___*2. PROCESSOR TYPE ___

(*)3. QUALIFIER 2 ___(*)4. QUALIFIER 3 ___

5. IP ADDRESSROW LOCAL IP ADDR IP SUBNET MASK1 ___.___.___.___ ___.___.___.___2 ___.___.___.___ ___.___.___.___3 ___.___.___.___ ___.___.___.___4 ___.___.___.___ ___.___.___.___5 ___.___.___.___ ___.___.___.___

Figure 4-9 RC View 33.1 (NAR): IP Processor Assignment 2 of 3


IP PARAMETER ASSIGNMENT UDP PARAMETER ASSIGNMENT16. REASSEM TIMER ___ 24. UDP CHKSUM EN _17. ICMP ERR CNT ___ 25. UDP START PORT _____18. MTU ENABLE _ 26. UDP DEF TTL ___19. MTU DISC _____20. OVLD TRIG __ ARP PARAMETER ASSIGNMENT

27. REFRESH INTRVL ___TCP PARAMETER ASSIGNMENT 28. CLEANUP INTRVL ___21. TCP MSS ____22. TCP START PORT _____ 29. PM GROUP ________23. TCP DEF TTL ___


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-15

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Figure 4-10 RC View 33.1 (NAR): Internet Protocol (IP) Processor Assignment 3of 3


#32. ICMP ERR GEN _#33. IP FRAGMENT _#34. MTU INTVL AFT FAIL ____

RC View 33.3

Figure 4-11 RC View 33.3 (NAR): IP Processor Routing to Interface

5ESS SWITCHRECENT CHANGE 33.3

(5989) INTERNET PROTOCOL (IP) ROUTING TO INTERFACE

*1. DEST IP ADDR ___.___.___.___*6. INTERFACE NAME ___________________7. NET OR HOST ____8. IP SUBNET MASK ___.___.___.___

#13. GATEWAY IP ADDR ___.___.___.___18. ROUTE METRIC ___

RC View 33.4

Figure 4-12 RC View 33.4 (NAR): IP Interface Assignment 1 of 2

5ESS SWITCHSCREEN 1 OF 2 RECENT CHANGE 33.4(5995) ETHERNET INTERNET PROTOCOL (IP) INTERFACE

ASSIGNMENT

*1. SM ___*2. PSU _*3. SHELF _*4. CHANNEL GROUP __#5. INTERFACE NAME ___________________6. PHE LINK __


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Figure 4-13 RC View 33.4 (NAR): Ethernet IP Interface Assignment 2 of 2

5ESS SWITCHSCREEN 2 OF 2 RECENT CHANGE 33.4(5995) ETHERNET INTERNET PROTOCOL (IP) INTERFACE

ASSIGNMENT

#7. GATEWAY IP ADDRESS 1 ___.___.___.___#12. IP SUBNET MASK 1 ___.___.___.___17. GATEWAY IP ADDRESS 2 ___.___.___.___22. IP SUBNET MASK 2 ___.___.___.___

27. MCAST ADDR ___.___.___.___32. MTU SIZE ____33. RATE ____34. MODE _

5ESS DCS RC Views for IPBH provisioning (INTL)

The following RC Views are used to provision IP backhaul in the 5ESS DCS.

RC View 9.37

IPBH specific data is defined on this screen:


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-17

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Figure 4-14 RC View 9.37 (INTL): Protocol Handler Group Definition 1 of 2

SCREEN 1 OF 2 RECENT CHANGE - 9.37 PHGRPPROTOCOL HANDLER GROUP DEFINITION

*1. SM ___ #13. L1 OVRLDTHRESHOLD __

*2. PSU _ #14. L2 OVRLDTHRESHOLD __

*3. PH GROUP __ #15. CONN CHKENABLED _

#4. APP TYPE ________ #16. CONN CHKINTRVL __

#17. CONN CHK INTRVLLOW ___5. PROTOCOL HANDLERS #18. CONN CHK MAXFAIL __

SHELF CHL GRP POSITION PH TYPE #19. SW OVRTIMER __

1) _ __ __ ____ #20. DIFF SVR CODEPOINT __

2) _ __ __ ____ #21. RCV ICMP MSGTHRHLD ___

#22. INHIBIT CALLPROC _

&11. SECONDARY ADDR ___ 23. DEBUGFLAGS ________

#12. PKT BUS INTRVL ____

Figure 4-15 RC View 9.37 (INTL): Protocol Handler Group Definition 2 of 2

SCREEN 2 OF 2 RECENT CHANGE - 9.37 PHGRP

PROTOCOL HANDLER GROUP DEFINITION

IP BACKHAUL PARAMETERS24. BHA BASE UDP PORT _____25. BHA PRE UDP PORT _____26. BHA QUALITY ___27. BHA INACT TIMER __28. UDPMUX BUNDLE SZ ____29. UDPMUX BUNDLE TMR 1 ____30. UDPMUX BUNDLE TMR 2 ____


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

RC View 90.5

Figure 4-16 RC View 90.5 (INTL): IP Processor Assignment 1 of 2

SCREEN 1 OF 2 RECENT CHANGE - 90.5 IPPRC

IP PROCESSOR ASSIGNMENT

*1. PROCESSOR ID ___*2. PROCESSOR TYPE __+3. QUALIFIER 2 ___+4. QUALIFIER 3 ___

5. IP ADDRESSLOCAL IP ADDR IP SUBNET MASK

1) ___ ___ ___ ___ ___ ___ ___ ___2) ___ ___ ___ ___ ___ ___ ___ ___3) ___ ___ ___ ___ ___ ___ ___ ___4) ___ ___ ___ ___ ___ ___ ___ ___5) ___ ___ ___ ___ ___ ___ ___ ___

Figure 4-17 RC View 90.5 (INTL): IP Processor Assignment 2 of 2

SCREEN 2 OF 2 RECENT CHANGE - 90.5 IPPRC

IP PROCESSOR ASSIGNMENT

IP PARAMETER ASSIGNMENT UDP PARAMETER ASSIGNMENT16. REASSEM TIMER ___ 23. UDP CHKSUM EN _17. ICMP ERR CNT ___ 24. UDP START PORT _____18. MTU ENABLE _ 25. UDP DEF TTL ___19. MTU DISC _____

ARP PARAMETER ASSIGNMENTTCP PARAMETER ASSIGNMENT 26. REFRESH INTRVL __20. TCP MSS ____ 27. CLEANUP INTRVL __21. TCP START PORT _____22. TCP DEF TTL ___


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-19

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

RC View 90.6

Figure 4-18 RC View 90.6 (INTL): IP Processor Routing to Interface

SCREEN 1 OF 1 RECENT CHANGE - 90.6 IPRTE

IP ROUTING TO INTERFACE

*1. DEST IP ADDR ___ ___ ___ ___*6. INTERFACE NAME ___________________7. NET OR HOST ____8. IP SUBNET MASK ___ ___ ___ ___

#13. GATEWAY IP ADDR ___ ___ ___ ___18. ROUTE METRIC ___

RC View 90.7

Figure 4-19 RC View 90.7 (INTL): IP Interface Assignment

SCREEN 1 OF 1 RECENT CHANGE - 90.7 IPETH

ETHERNET INTERNET PROTOCOL (IP) INTERFACEASSIGNMENT

*1. SM ___ 33. RATE ___*2. PSU _ 34. MODE _*3. SHELF _ #35. APPTYPE _____*4. CHANNEL GROUP __#5. INTERFACE NAME ___________________#6. PHE LINK __#7. GATEWAY IP ADDR 1 ___ ___ ___ ___

#12. IP SUBNET MASK 1 ___ ___ ___ ___17. GATEWAY IP ADDR 2 ___ ___ ___ ___22. IP SUBNET MASK 2 ___ ___ ___ ___27. MCAST ADDR ___ ___ ___ ___32. MTU SIZE ____

Backhaul server associations

A backhaul server association (BHA) is a UDPMux session between a BTS and aBPH. The BHA is identified by the IP addresses of the BTS and BHS and the UDPport number. BHA status can be verified using apoke command.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

ECPC OA&M.................................................................................................................................................................................................................................

Purpose

This section describes Recent Change and Verify forms that are new or have beenmodified for IPBH on the ECP.

RC/V forms updated for IP Backhaul

The following forms are updated for IP Backhaul:ecp , apeqp , btseqp , cell2 , andcdmeqp . Views of each form and IPBH screen are shown on subsequent pages.

The following fields are populated for IPBH:

Form Fields for IPBH data

ecp IP Backhaul Control Network ID

BHCS Failure Reporting Interval

Default Traffic Diffeserv Codepoint

User Class Traffic Diffserv Codepoint

Signaling Class Traffic Diffserv Codepoint

Backhaul Connection Server Lan0 IP address

Backhaul Connection Server Lan1 IP address

Lan0 Backhaul Connection Server Gateway IP Address

Lan01 Backhaul Connection Server Gateway IP Address

btseqp Backhaul Mode

Backplane Serial Number


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-21

Form Fields for IPBH data

cell2 IP Backhaul Enabled

Backhaul Offload

Primary RNC Number

Primary RNC Backhaul Server Number

Primary Switching Module Number (SM)

Primary Packet Switching Unit Number (PSU)

Primary DCS Backhaul Server Number

Alternate RNC Number

Alternate RNC Backhaul Server Number

Alternate Switching Module Number (SM)

Alternate Packet Switching Unit Number (PSU)

Alternate DCS Backhaul Server Number

MLG Loading Bias Translation (BIASMLG)

CDMA Carrier Service Option Class

CDMA Carrier Switching Module

CDMA Carrier Packet Switching Unit

CDMA Carrier Backhaul Server

cdmeqp Backplane Serial Number

Backhaul Mode

apeqp RCS IP Services Enabled

RCS-IM Exists

Interface 0 Backhaul IP Address

Interface 1 Backhaul IP Address

Lan0 Default Gateway IP Address

Lan1 Default Gateway IP Address

RCS Flexible Sparing Enabled

SeeText Recent Change and Verify Manual (Text RC/V),401-610-038, andDatabaseUpdate,401-610-036, for complete details about these forms, including populationrules.

ecp form

OA&M for IP Backhaul ECPC OA&M

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

btseqp form

The following fields are used for IPBH: Backhaul Mode per URC and BackplaneSerial Number (BPSN) per frame.

Figure 4-20 RC/V form: ecp

Figure 4-21 RC/V form: btseqp


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-23

cell2 form

The cell2 form activates the IPBH feature, identifies the service option class (SOC),associates the cell’s carriers to the SM/PSU/BHS, specifies data offload and providesthe DCS/BHS or 1X RNC/BHS used for data offload. The service option class (SOC)

Figure 4-22 RC/V form: btseqp


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

is display only. It is set to BOTH when data offload is “n.” It is set to VOICE whendata offload is “y,” since the carriers listed will only handle the voice traffic.

Figure 4-23 RC/V form: cell2


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-25

This screen for CDMA Cell Site IP Backhaul Information identifies IPBH parametersper cell site.

This form identifies when the IPBH feature is enabled for the cell and when datatraffic is off-loaded to a specific BHS on the DCS or RNC.

cdmeqp form

The Backhaul Mode field identifies the backhaul mode of ATM Protocol, Frame Relay,SH or IP per frame. The Back Plane Serial Number (BPSN) is also populated on thisform.

Figure 4-24 RC/V form: cell2


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

This form identifies the CRCs for the Mod 1,2,3 cells:

SeeText Recent Change and Verify Manual (Text RC/V),401-610-038, andDatabaseUpdate,401-610-036, for complete details about these forms, including populationrules.

apeqp form

The apeqp form is used to enable RCS-IP services on a specific AP pair

Figure 4-25 RC/V form: cdmeqp


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-27

RCI-IM Exists is set on a single AP pair with the command script during install usingapappconfig.

The apeqp form is also used to enable RCS Flexible Sparing. SeeFlexent® WirelessNetworksCell Reliability and Engineering Improvements for IPBH RCS APs - Deliveryof Flexible Sparing Phase 1,,401-612-830. for details on that feature.

Figure 4-26 RC/V form: apeqp


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Input/Output commands and messages.................................................................................................................................................................................................................................

Purpose

This section describes the new and modified input and output commands for IPBH.Because of the volume of messages that report on IPBH, this section provides ahigh-level overview of commands that support IPBH and does not cover all IPBHcommands and resulting output. Itemizing all new commands is beyond the scope ofthis document. It is intended to help you identify critical commands to use in managingyour iPBH network. It is assumed that the user is familiar with the purpose ofcommands used in a Lucent Technologies network.

Overview

IPBH input and output messages can be viewed through user interfaces and ROPprintouts.

See the following documents for detailed information on these new and modified I/Omessages for IPBH:

• Flexent®/Autoplex® Wireless NetworksInput Messages Manual,401-610-055

• Flexent®/Autoplex® Wireless NetworksFlexent®/Autoplex® Wireless NetworksOutput Messages Manual,401-610-057

• 5ESS® Switch Flexent®/Autoplex® Wireless Networks ApplicationsInput/OutputMessages,235-600-700/750

• 5ESS® Switch Flexent®/Autoplex® Wireless Networks ApplicationsApplicationsOA&M Manual,5AP

Input commands

IPBH input messages are described in detail in the Input Messages Manual(401-610-055). This section describes the new messages and provides some of the useof variables for the command message.

Important! All LOCK, UNLOCK, SHUTDOWN, andGET commands in are only availablevia TPUCLI from the AP supporting the 1X RNC.

New inputs


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-29

Table 4-3 New inputs by interface

CommandSyntax

TICLI TI

ALW:CELL-MLG

ALW:CELL a, CP, CDM b, MLG

Allow the specified Multi-Link Group (MLG) to resume handlingtraffic.

x x

DUMP:CELL-AUTH-FAIL

DUMP:CELL,AUTH,FAIL

Request Backhaul Connection Server (BHCS) to generate a list of theBase Transceiver System(s) (BTS) that have failed authentication.

x x

INH:CELL-MLG

INH:CELL a, CP, CDM b, MLG c [,UCL]

IP Backhaul groups multiple Digital Signal Level 1 (DS1) signalinglinks into a single large pipe called a Multi-Link Group (MLG) forBackhaul transport of signaling and user traffic packets to a cell. Thisincreases capacity and decreases latency. Each MLG consists of one ormore DS1 facilities per Universal Radio Controller (URC). Thiscommand inhibits traffic for the specified MLG.

x x

OP:AP-IPBHINFO

OP:AP a, IPBHINFO

Requests information for a specific AP such as supported IPBH RCSs,the IP addresses associated with IPBH, the BPSN for each assemblageand each IPBH cell.

x x

OP:BHS-CELL

OP:BHS;CELL a

Requests the status of the Backhaul Servers (BHSs) associated with therequested cell. The report includes status and location information forall BHSs provisioned on the cell2 RC/V form for both voice and datatraffic.

OP:CELL-CSB

OP:CELL a, CSB

Requests the Carrier Service Option Class [SOC] Backhaul Server[BHS] (CSB) connectivity for the specified cell. The informationobtained reflects a summary of the health of the connection betweenthe cell and each BHS used for voice or data traffic on a per-carrierbasis.

x x

OA&M for IP Backhaul Input/Output commands and messages

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 4-3 New inputs by interface (continued)

CommandSyntax

TICLI TI

OP:DCS-BHSSTAT

OP:DCS a [, SM b], BHSSTAT

Requests the status of all or requested Backhaul Server (BHS) units atthe Digital Cellular Switch (DCS). Status includes maintenance state,overload state, blocking state, etc.

x x

OP:RNC-BHSSTAT

OP:RNC a, BHSSTAT

Requests the RNC BHS status from the ecp to be output to the ROP.Status includes maintenance state, overload state, blocking state, etc.

x x

UPDATE:AP-BPSN

UPDATE:AP y,BPSN

Request to update the Back Plane Serial Numbers (BPSNs) for eachcell configured on the specified Application Processor (AP), to beupdated in the database prior to converting to Internet Protocol (IP)Backhaul. If possible, the BPSNs are retrieved from each cell for allthe assemblages in the cell. If the BPSNs cannot be retrieved for a cell,the value from the database will be retrieved. The output will list theBPSNs and the source of the BPSN data (cell or database).

x x

UPDATE:CELL-BPSN

UPDATE:CELL x,BPSN

Requests the BPSNs for the specified cell to be updated in thedatabase.

x x

SeeFlexent®/Autoplex® Wireless NetworksInput Messages Manual,401-610-055 forcomplete details.

Modified inputs

Table 4-4 Modified inputs

CommandSyntax

TICLI TI

ABT:VCA-AUD

ABT:VCA, AUD a

wherea = BHMDB –– BackhaulManager (BHM) database audit

x x


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-31

Table 4-4 Modified inputs (continued)

CommandSyntax

TICLI TI

ALW:VCA-AUD

ALW:VCA, AUD a where a =BHMDB –– Backhaul Manager(BHM) database audit

x x

AUD:VCA-NAME

AUD:VCA, NAME a where a =BHMDB –– Backhaul Manager(BHM) database audit

x x

GET:RNC-TPU-STATE

GET:RNC a, TPU b, GICC i,IPBTSGW, STATE

This command is only available via TPUCLIfrom the AP supporting the RNC.

INH:VCA-AUD

INH:VCA, AUD a where a =BHMDB –– Backhaul Manager(BHM) database audit

x x

INIT:VCA

INIT:VCA:SPP a where a = bhm–– Backhaul Manager (BHM)

x x

LOCK:RNC-TPU

LOCK:RNC a, TPU b, GICC c,IPBTSGW


OP:CELL

OP:CELL xxx CDM a, MLG b

x x

SHUTDOWN:RNC-TPU

SHUTDOWN:RNC a, TPU b, GICCc,IPBTSGW


UNLOCK:RNC-TPU

UNLOCK:RNC a, TPU b, GICC c,IPBTSGW


SeeFlexent®/Autoplex® Wireless NetworksInput Messages Manual,401-610-055 forcomplete details.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Output messages

IPBH output messages are described in detail in the Output Messages Manual(401-610-057). This section describes the new and modified output messages.

SeeFlexent®/Autoplex®Wireless NetworksOutput Messages Manual,401-610-057 forcomplete details on these messages.

New outputs

Table 4-5 New outputs

New output Purpose

ALW-CELL-MLG Reports the completion codes for the allow of a cellsite Multiple Link Group (MLG) unit.

DUMP-CELL-AUTH-FAIL The Backhaul Connection Server (BHCS) generates alist of cells that have failed authentication in responseto the DUMP:CELL-AUTH-FAIL input command.

INH-CELL-MLG Reports the completion codes for the inhibit of a cellsite Multiple Link Group (MLG) unit.

OP-AP-IPBHINFO Reports the IP address and BPSN of an RCS with IPservices enabled.

OP-BHS-CELL Provides the status of the Backhaul Servers (BHSs)associated with the requested cell. The report includesstatus and location information for all BHSsprovisioned on the cell2 RC/V form for both voice anddata traffic.

OP-CELL-CSB Report the Carrier Service Option Class [SOC]Backhaul Server [BHS] (CSB) connectivity for thespecified cell. The information obtained reflects asummary of the health of the connection between thecell and each BHS used for voice or data traffic on aper-carrier basis.

OP-DCS-BHSSTAT Reports on the 5ESS DCS backhaul server (BHS)state.

OP-RNC-BHSSTAT Reports on the RNC backhaul server (BHS) state

REPT-BHS-IPERR The Backhaul Manager (BHM) generates a reportwhen an IP address conflict is detected between two ormore Backhaul Servers (BHSs). BHM will change themaintenance state of the conflicting BHSs tounavailable. The report is generated immediately whenthe IP address conflict is detected and periodicallythereafter until the conflict is resolved.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-33

Table 4-5 New outputs (continued)

New output Purpose

REPT-BHS-STATUS The Backhaul Manager (BHM) generates a reportwhen the status for a Backhaul Server (BHS) changes.The change may result from an update received fromthe RNC or DCS where the BHS is located, or it mayresult from a change in status maintained on the ECPand reported to the appropriate DCS or RNC. Thisreport will reflect a change to the BHS maintenancestate or to the BHS overload state.

REPT-CELL-AUTH-FAIL The Backhaul Connection Server (BHCS) generates alist of cells that have failed authentication. This outputprints at a regularly scheduled interval as determinedby the BHCS Failure Reporting Interval field on theInternet Protocol (IP) Backhaul Information Onlyscreen of the ecp RC/V form.

UPDATE-AP-BPSN This message is generated as a result of the successfulexecution of the UPDATE:AP,BPSN input command.There will be one line of output for each assemblageof each cell equipped on the specified ApplicationProcessor (AP). The output will include the cellnumber, assemblage, Back Plane Serial Number(BPSN) and an explanation of the action that tookplace for that assemblage.

UPDATE-CELL-BPSN This message is generated as a result of the successfulexecution of the UPDATE:CELL-BPSN inputcommand. There will be one line of output for eachassemblage of a cell. The output will include the cellnumber, assemblage, Back Plane Serial Number(BPSN) and an explanation of the action that tookplace for that assemblage.


Modified outputs

Table 4-6 Modified outputs

Command Name

AUD-VCA-NAME-E-C

AUD-VCA-NAME-E-N


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 4-6 Modified outputs (continued)

Command Name

GET-RNC-TPU-STATE

INH-CELL-IN-PROG

LOCK-RNC-TPU

OP-ALARM

OP-AP-ALARM

OP-AP-INFO

OP-CELL

REPT-AP-ALLLAN

REPT-AP-LANFAIL

REPT-CELL-CP-FAIL

REPT-CELL-HEH-2

REPT-DCF-RECOVERY

REPT-DCF-SUMMARY

REPT-VCA-INIT

RESTART-RCS

RMV-AP

RMV-RCS

RST-RCS

SHUTDOWN-RNC-TPU

SWITCHOVER-RCS

UNLOCK-RNC-TPU


5ESS DCS I/O commands for IPBH

This section provides a high-level overview of commands that support IPBH. Itemizingall new commands is beyond the scope of this document. Please refer5ESS® SwitchFlexent®/Autoplex® Wireless Networks ApplicationsInput/Output Messages,235-600-700/750 for complete details on these messages.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-35

Table 4-7 5ESS DCS inputs and outputs

Input Output

ALW:HDW

Allows hardware checks on a packet switch unit(PSU) protocol handler (PH).

None.

EXC:PING

Requests verification of the transmission controlprotocol/internet protocol (TCP/IP) connectionbetween the source internet protocol (SRCIP)address and the internet protocol destination(IPDEST) address.

Outputs PING information that is sent froman SM, PH, or optical interface unit (OIU).

EXC:TRACEROUTE

To trace the route to an IP destination from a givenIP source.

Outputs information to trace the route to anIP destination from a given IP source.

Reports the following:

• PH IMAGE TYPE

• SOURCE IP

• DESTINATION IP

• BYTES SENT

• HOPS

• TIMEOUT DURATION

• TRACE TIMEOUTS

INH:HDWCHK

Inhibits a switch to the standby administrativemodule (AM) control unit when a fault occurs inthe active AM control unit.

Indicates the result of a request to inhibitadministrative module (AM) hardware checks.

OP:BHA,PSU=a-b[,SUM];

Requests the backhaul association (BHA) relatedinformation of a specified backhaul protocol handler(BPH) or summary BHA information of all theBPHs in a packet switch unit (PSU).

Reports the BHA related information of aspecified BPH or summary BHA informationof all the BPHs on a PSU.

OP:CONV-PHGRP

To report protocol handler (PH) group (PHGRP) conversion data.

Reports PHGRP conversion data.

OP:IPCFG

Requests the output of IP address and subnet maskconfiguration information for specified characteristicsprovided in the command.

Reports the IPCFG information collected for anOP:IPCFG request.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 4-7 5ESS DCS inputs and outputs (continued)

Input Output

OP:TCPIP:ARPDMP,CHNG=a-b-c-d;

Requests the TCP/IP address resolution protocol(ARP) cache input message to show the ARP cacheentries of a protocol handler(PH).OP:TCPIP:RTDMP,CHNG=sm-psu-shlf-ph;

Reports the ARP information contained in thePH.

RMV:PSUPH

Requests that a packet switch unit (PSU) protocolhandler (PH) be removed from service.

Indicates the result of anRMV:PSUPH inputmessage to remove a packet switch unit(PSU) protocol handler (PH) from service.

RST:PSUPH

Requests that a packet switch unit be restored toservice.

Indicates the result of anRST:PSUPH inputmessage to restore a packet switching unitprotocol handler (PH) to service.

See5ESS® Switch Flexent®Autoplex® Wireless Networks ApplicationsInput/OutputMessages,235-600-700/750 for complete details on these messages.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-37

Status display pages.................................................................................................................................................................................................................................

ECPC status display pages

This section describes the new and changed status page. It is assumed that you arefamiliar with the use of the SDP pages and the color coding for status: Available =green, Unavailable = red, Degraded = yellow, and Indeterminate = white.

SeeFlexent®/Autoplex® Wireless NetworksECP OA&M and SDP MaintenanceControl Procedures,401-610-160 for detailed information.

Table 4-8 New and modified SDP pages for IPBH

SDP Page New orModified

Description

SDP 2101 New APX Index Page II- New index page added for BHSstatus pages.

SDP 2131 Modified Cell Equipment Status Page modified to addindicator of IPBH feature status.

SDP 2138 Modified Cell CDM Status Page modified to add MLG-BHSAssociation status and remove Packet Pipeinformation.

SDP 2236 New displays carrier/SOC-BHS for both voice and dataconsisting of:

• Carrier ID and channel number.

• SOC type: Voice or Data.

• Voice and Data traffic status.SOC status – Available, Unavailable, Degradedand Indeterminate.

• Blocking state is also displayed: B = block allnew calls and soft handoffs due to criticaloverload, b = block all new calls due to majoroverload.

• BHS ID (DCS) consisting of theDCS/SM/PSU/BHS numbers.

• BHS ID (RNC) consisting of the RNC/BHSnumbers.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Table 4-8 New and modified SDP pages for IPBH (continued)

SDP Page New orModified

Description

SDP 2237 New displays MLG information for each activelydisplayed CRC:

• Bitmap of DS1 to MLG association.

• Bit map of DS1s not associated with any MLG.

• SL on each CRC/MLG.Note, for Modular cell 1,2 or 3, if the CRC doesnot have an equipped DS1, it uses the parentMLG.

SDP 2260 New SDP 2260 is a new page that displays the BHSstatus for each SM on a DCS.

Note: The lower left corner provides a summaryview of the BHS status for each SM. If any BHS inan SM is in an off-normal state (maintenance stateunavailable or load state critical or major), then thespecified SM will be marked TROUBLE (white textwith red background). If not, the SM number will bemarked as NORMAL (white text with blackbackground).

SDP 2265 New SDP 2265 is a new page that displays the BHSstatus for each RNC.

Note: The lower left corner provides a summaryview of the BHS status for each RNC. If any BHSon an RNC is in an off-normal state (maintenancestate unavailable or load state critical), then thespecified RNC will be marked TROUBLE (whitetext with red background). If not, the RNC numberwill be marked as NORMAL (white text with blackbackground).

OA&M for IP Backhaul Status display pages

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-39

SDP 2101 - APX Index Page II

This page has been modified for IPBH.


Figure 4-27 SDP 2101


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

SDP 2131 - Cell Equipment Status Page

This page has been modified to indicate whether or not IP Backhaul is enabled for thecell and MLG sharing (indicated by SH when on).


SDP 2138- Cell CDM Status Page

The SDP 2138 page shows status for IP BHAs which use MLGs that are physicallylocated on the URC.

When IPBH is enabled on thecell2 form, the following information is provided onSDP 2138:

• The “PP STAT” changes to “MLG-BHS ASSOC”

• All packet pipe information is blank

• The number of active MLG-BHS Association (i.e. IP_BHAs) for the URC.

• The total number of existing IP_BHAs for the URC, whether or not they are active



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-41

• The status:

– green––if all IP_BHA are available for that URC

– red––if all IP_BHA are unavailable for that URC

– yellow––if at least one IP_BHA is unavailable and at least one IP_BHA isavailable for that URC .


SDP 2236 - Cell Carrier SOC BHS status

The following information is provided on this SDP 2236:

• Carrier ID (1 - 18)

• Channel number (1 - 2047)

• BHS assigned to each Service Option Class type per carrier: Voice or Data

• BHS_ID (PSU) include DCS# (1-16), SM# (1-192), PSU# (0-1), BHS# (1-10)



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

• BHS_ID (RNC) include RNC# (1-15), BHS# (1-3)

• The status of Carrier-SOC-BHS (available - green, unavailable - red, degraded -yellow, indeterminate - black)


SDP 2237 - Cell MLG Status

This page is used for Multi Link Group Status.

Icons are explained as follows:

• CRC: CDMA Radio Controller

• MLG: Multi Link Group

• DS1: Digital Signal Level 1

• SL on MLG: Signal Link on MLG

The following information is provided on this SDP 2237:

• CRC ID (1 - 16)

• The status of CRC (ACTIVE - green, OOS - red)

• MLG ID (1 - 2)

• The status of MLG (active - green, oos - red, inh - white)

• DS1 associated with each MLG

Figure 4-30 Status display page: 2236


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-43

• The status of DS1 (active - green, oos - red)

• The CRC and MLG supporting the active signaling link

• DS1 not associated with any MLG (oos - red)


Figure 4-31 Status display page: 2237


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

SDP 2260 - DCS BHS STATUS

This page displays BHS status for both voice and data for DCS BHSs consisting ofone screen per switching module (SM) for the DCS (1-16).


SDP 2265 - BHS Status

This page displays the status of the BHSs in one RNC.

The left corner gives a summary view of the status of all BHSs in each RNC. If anyBHSs in one RNC are in off-normal state (Maintenance state unavailable or Load statecritical or major), then the specified RNC will be marked as TROUBLE (White text



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-45

with red background). If not, the RNC number will be marked as NORMAL (Whitetext with black background).


5ESS DCS status pages

MCC 1188 is accessed via poke1188,psu,sm

The following information is available:

• The PH group number on the 1188 is the same as the BHS number on the ECPSDP 2260 and 2236 and thecell2 form.

• Each PH group consists of 2 PHs listed by shelf and slot number, horizontallyacross the same row as the PH group number.

• If either PH in the row is listed as having *M (major) or *C (critical) overload,then the entire PH group (BHS) is reported in overload on the ECP 2260 page andBHSSTAT output messages.

• If at least 1 PH in the row is ACT/SERV, then the BHS is reported available in theECP 2260 and BHSSTAT output messages.

• If both PHs in a row are OOS, then the ECP reports the BHS as unavailable.



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

• If a BHS used for data offload is unavailable and there is an alternate BHSprovisioned on thecell2 form for a cell, the alternate BHS will be used for futuredata calls using that cell.

• If a BHS used for data offload is available, but in overload, the primary BHSprovisioned on thecell2 form for a cell will continue to be used for future datacalls.

The MCC 1188 page has been added:

See5ESS® Switch Flexent®/Autoplex® Wireless Networks ApplicationsOA&MManual,NAR 235-200-100 for detailed information.

Figure 4-34 5ESS-DCS PHGRP status page: MCC 1188


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-47

OMC-RAN

Monitor IPBH from the OMC-RAN.................................................................................................................................................................................................................................

OMC-RAN for IPBH

The Operations and Maintenance Center Radio Access Network (OMC-RAN) is acomprehensive Graphical User Interface (GUI)-based Operations, Administration andMaintenance (OA&M) platform that provides OA&M capabilities for a Flexentwireless network.

The OMC-RAN:

• Monitors network elements in multiple configurations simultaneously.

• Provides centralized fault management and configuration management.

• Provides a common user interface.

• Provides enhanced controls over user access.

• Provides a standardized north bound interface (NBI) for sending fault monitoringinformation to a centralized Operations Support System (OSS).

The OMC-RAN uses an existing Internet Protocol (IP) operations network tocommunicate with entities such as the Network Operations Center (NOC), clientterminals, such as desktop PCs, workstations and laptops. A provider’s IP network is aprivate Internet Protocol Wide Area Network (IP-WAN) that links the customer’sCentral Offices (COs) together.

OMC-RAN configuration

SeeFlexent® Wireless Networks Operations and Maintenance Center Radio AccessNetwork (OMC-RAN) Operations, Administration & Maintenance,401-662-105 forinformation on planning for OMC-RAN.

The OMC-RAN can be installed in your network either prior to or following theinstallation of an IPBH network.

When the IPBH network is configured, the IPBH screens and configuration informationappears on the existing screens of the OMC-RAN.

Monitoring IPBH information on the OMC-RAN

The primary purpose of the OMC-RAN is for alarm monitoring and fault clearance.The types of information that is available on the Status Display Page also appears onthe OMC-RAN screens. However, you can also do configuration from the OMC-RAN.SeeFlexent® Wireless Networks Operations and Maintenance Center Radio AccessNetwork (OMC-RAN)Planning Operations, Administration & Maintenance,401-662-105 for complete information about OMC-RAN.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

OMC-RAN user interface

Information is displayed on the existing BTS overview page.

Figure 4-35 OMC-RAN BTS Overview - server=Lab#

OA&M for IP Backhaul Monitor IPBH from the OMC-RAN

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-49

Select “server/Lab#/ORCA/Group.BTSGroup/BTS#/BTS” to display this page:

Figure 4-36 OMC-RAN Network Manager - IPBH Enabled information


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Select “server/Lab#/ORCAGroup/BTSGroup/BTS#/SocList” to display this page:

Figure 4-37 OMC-RAN Network Manager - IPBH SocList


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-51

Select “server/Lab#/ORCAGroup/BTSGroup/AssemblTable” display this page for theselected BTSGroup:

Figure 4-38 OMC-RAN Network Manager - IPBH BPSN


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Select “server/Lab#/ORCAGroup/BTSGroup/AssemblTable” display this page for theselected BTSGroup:

Figure 4-39 OMC-RAN Network Manager - IPBH BPSN


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


4-53

5 5Fault management

Overview.................................................................................................................................................................................................................................

Purpose

This chapter discusses fault management functions in a network using IP backhaul.

Contents

Network monitoring 5-3

Fault management 5-3

General problem solving model 5-5

Network monitoring and fault detection 5-7

Sample section: Identified fault 5-10

Cable faults 5-14

DS1 (T1/E1) cable cut 5-14



Bad DS1 cable 5-24

Cable cut/disconnected between ER and MLS 5-27

Cable cut on serving IPBTS GW GigE interface - Standby GigEin-service

5-30

Cable cut on non-serving IPBTS GW GigE interface 5-34

Cable cut on serving IPBTS GW GigE interface - Standby GigEout-of-service

5-37

Cable cut on serving IPBTS GW GigE interface 5-41

Communication faults 5-45

IPGW0 is unreachable 5-45

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-1

IPGW1 is unreachable 5-48

Duplex IPGW access failures 5-51

Only remaining 5E GW goes OOS 5-55

No 1st Hop router connectivity 5-59

No Ethernet connectivity 5-63

No 1st Hop router connectivity 5-66

No Ethernet connectivity 5-70

Edge router card failure affecting all associated DS1 interfaces 5-73

Software and configuration faults 5-76

BER major threshold crossed 5-76

Active RCS IP goes OOS-F while mate AP is OOS-F 5-79

One DS1 in MLG is not configured in ER, or wrong DS1 is assigned toMLG in ER

5-83

Edge router card failure affecting all associated DS1 interfaces 5-86

Fault management Overview

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Network monitoring

Fault management.................................................................................................................................................................................................................................

Definition

Fault management (FM) is a set of functions that enables the detection, isolation andcorrection of abnormal operation of the telecommunication network and itsenvironment.

FM functions

The fault management functions area:

• Alarm surveillance

• Fault localization

• Fault correction

• Testing

Alarm surveillance

Alarm surveillance detects faults in a network. It monitors and/or interrogates networkelements about events or conditions. Event data is generated by a network element(NE) when an abnormal condition is detected.

Type Description

Hardware faults Malfunction of physical resource.

Software faults Malfunction of software components

Functional faults Failure of a functional resource in the NEand no hardware component has beendetected as faulty.

Overload conditions Loss of some or all of the specifiedcapabilities of an NE due to high resourceusage conditions

Quality of service failures Failures to meet the given thresholdvalues.

Communication failures Communication failures between NEs, orbetween the NE and the operating system(OS), or between OSs.

Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-3

Fault localization

Fault localization determines the root cause of a fault.

Information obtained by additional failure localization routines must be added when theinitial failure information is insufficient for fault localization. The routines can employinternal or external test systems and can be controlled by a Local MaintenanceTerminal (LMT).

Fault correction

Fault correction takes the appropriate action to correct a fault once the root cause hasbeen identified.

It transfers data concerning the repair of a fault and for the control of procedures thatuse redundant resources to replace equipment or facilities that have failed.

Testing

Testing conduct tests to determine the root cause of a fault. Testing can be carried outby directly accessing the relevant functionality of the NE using the LMT to help youanalyze the problem.

Fault management Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

General problem solving model.................................................................................................................................................................................................................................

Description

The general problem solving model represents a model that can be used as a generalapproach for each troubleshooting situation.

Process

The stages for the general problem solving model process are:

Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-5

.................................................................................................................................................................................................

1 Define the problem.

When analyzing a network problem:

• Make a clear problem statement

• Define the problem in terms of a set of symptoms and potential causes.

To properly analyze the problem, identify the general symptoms and then ascertainwhat kinds of problems (causes) could result in these symptoms.

.................................................................................................................................................................................................

2 Gather the facts.

Fact gathering might involve:

• Collecting information from affected users, network administrators, managers, andother key people

• Collecting information from sources such as network management systems,protocol analyzer traces, serial line traces, stack dumps or software release notes.

.................................................................................................................................................................................................

3 Consider the possibilities.

This might involve:

• Eliminating causes.

• Narrowing the number of potential causes.

.................................................................................................................................................................................................

4 Create an action plan.

The action plan will be based on the remaining potential causes.

.................................................................................................................................................................................................

5 Implement the action plan.

.................................................................................................................................................................................................

6 Observe the results.

.................................................................................................................................................................................................

7 If... then...

the problem has not been solved, return to Step 2.

Result

Process complete.

Fault management General problem solving model

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Network monitoring and fault detection.................................................................................................................................................................................................................................

Reference diagram

Figure 5-1, “Network monitoring” (p. 5-7)diagram is referenced throughout thischapter.

Host interfaces

All hosts on the IP backhaul network (URCs, BHSs, and RCS-APs) continuouslymonitor and report the health of all their interfaces through MSC operation,administration and maintenance (OA&M) systems. This information is displayed onSDP pages, NE GUI pages and as output to the ROP. When the OMC-RAN is part ofthe IPBH network, some health events are also reported to the OMC-GUI.

Figure 5-1 Network monitoring

Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-7

URC interfaces

Each URC continuously updates its RCS with the status of all its DS1s. RCS requiresreal-time knowledge of DS1 status in order to perform its call leg admission controlfunction and DS1 alarms and technician output reports.

In addition to admission control, RCS makes the DS1 status information availablethrough status display pages for the following:

• URC n

• BTS n

• Link status via URC

• RCS and BHS status via MSC OA&M

BHS interfaces

Each Backhaul Server (BHS) continuously monitors the health of its Ethernet links andits ability to communicate with its gateway router. The status of each BHS interface isreported and alarmed through 5ESS DCS and 1X RNC OA&M. The ECPC sees onlythe status of a BHS. The ECPC also reports its view of BHS status through alarms,status display and technician output reports.

RCS-AP and FMM LAN interfaces

The status of all Ethernet links within the FMM-AP LAN, and between the FMM LANand the MSC adjacent switches, are continuously monitored and reported throughECPC OA&M. All link faults are alarmed. In addition, each RCS-AP continuouslymonitors its ability to communicate with both gateway routers configured for thecontrol network. Loss of AP connectivity to a gateway router is alarmed.

End-to-end connectivity

URC-RCS connectivity

The end-to-end connectivity between each URC and its primary and alternate RCS-APscontinues to be reported on status display page 2131 (SDP 2131) and associated outputreports. There are multiple physical paths between a URC and an RCS-AP. As long asthere is a healthy connection over any one of the physical paths then the status of theend-to-end connection is green. URC-RCS connectivity is independent of RCSmaintenance state.

URC-BHS connectivity

Each URC monitors end-to-end connectivity to all the BHSs that are assigned to servecall legs on that URC. This URC-BHS connectivity status is available on SDP 2236and associated technician output report.

Fault management Network monitoring and fault detection

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Router status

The status of the backhaul routers, all inter-router links and all host interfaces (fromthe point of view of the routers) is available through the router network managementsystem (RNMS) as indicated inFigure 5-1, “Network monitoring” (p. 5-7).

Fault management Network monitoring and fault detection

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-9

Sample section: Identified fault.................................................................................................................................................................................................................................

Format of sample

The following sample sections identify the layout of the troubleshooting pages anddescribe the contents of each section.

Each fault is described for an environment that assumes the system is in stable andoperational condition and is up and running with no alarms present.

Fault ID: IPBH-FM-NE-#

Service impact

This block will identify any service impacts to the network that can occur with thefault.

The following types of service impacts can occur and will be identified when present:

• Loss of Capacity to/from the URC

• Stable calls are dropped

• Stable calls, but intermittent voice; dropped data packets; failure of new call setups.

• Handoff failures

• Loss of Layer 3

• Loss of Layer 2

Resolution

Text in this block will identify the steps or activities needed to resolve the fault.

Severity

Severity of the faults can be:

• Critical

• Major

• Minor

Fault identification

High-level fault condition.

Fault condition specifics.

Resolution

This is a high-level view of actions needed to resolve the fault and/or an indicator thatno manual intervention is required to resolve the fault.

Other indications

Information in this block lists possible other indicators that may accompany the fault.

Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Fault detection and automatic recovery

The alarms, notifications and automatic recovery actions are identified by networkelement (NE):

• Fault detection: The location where the fault is detected in the network.

• Alarms and notifications: The alarms and outputs that display on the user interfacefor the NE.

• Automatic recovery actions: Automatic actions that are initiated when the fault isdetected.

Network element Fault detection Alarms andnotifications

Automaticrecovery

BTS Identifiable fault on the NE. Alarm or notificationon NE interface.

Automatic recoveryaction on NE.

Transport Network

RouterManagement:

Identifiable fault on the NE. Alarm or notificationon NE interface.


Edge Router Identifiable fault on the NE. Alarm or notificationon NE interface.


MLS Identifiable fault on the NE. Alarm or notificationon NE interface.


Mobile Switching Center

FMM-APs Identifiable fault on the NE. Alarm or notificationon NE interface.


RCS Identifiable fault on the NE. Alarm or notificationon NE interface.


RCS Identifiable fault on the NE. Alarm or notificationon NE interface.

SDP ####:

ROP:


5ESS DCS Identifiable fault on the NE. Alarm or notificationon NE interface.

1188 MCC:

118 [0-4]:

ROP:


1X RNC Identifiable fault on the NE. Alarm or notificationon NE interface.

TPU-GUI:


Fault management Sample section: Identified fault

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-11


Automaticrecovery

OMP-FX Identifiable fault on the NE. Alarm or notificationon NE interface.

EMS:


OMC-RAN Identifiable fault on the NE. Alarm or notificationon NE interface.

OMC-GUI:


Other Indications Message or report throughanother medium than userinterface, such as technicianinterface (TI).

Message or reportthrough anothermedium than userinterface, such astechnician interface(TI).

Message or reportthrough anothermedium than userinterface, such astechnician interface(TI).

Automatic Recovery Actions

Automatic recovery actions result in:

• NE Impacts: Loss of capacity

• Subsequent alarms:DS1 alarm

• Subsequent Other Indications:None

• Subsequent Service Impact:Reduced bandwidth (may not be end-user visible).

• Subsequent states:None.

Fault resolution

Recommended actions to resolve fault. This may include a single action , a series ofactions or an indicator that no manual intervention is required to resolve the fault.

The following results occur on the network elements when a fault is corrected:

Network Element Fault correction results

BTS Fault correction events and notifications

Transport Network

Router Management Fault correction events and notifications

Edge Router Fault correction events and notifications

MLS Fault correction events and notifications


FMM-APs Fault correction events and notifications

RCS Fault correction events and notifications


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


ECP SDP ####:

ROP:

Fault correction events and notifications

5ESS DCS 1188 MCC:

118 [0-4]:

ROP:


1X RNC TPU-GUI:


OMP-FX EMS:


OMC-RAN OMC-GUI:


Other Indications Fault correction events and notifications


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-13

Cable faults

DS1 (T1/E1) cable cut.................................................................................................................................................................................................................................

Fault Description

Incoming DS1 failure to the BTS. Multi-T1 MLG (Partial MLG Failure)

Fault ID: IPBH-FM-BTS-1

Severity

Critical.

Service impact

Loss of Capacity. Some calls may be dropped.

Resolution

Install a new T1 cable between the BTS and edge router.






Network element Fault detection Alarms and notifications Automaticrecovery

BTS Detects DS1 LOS andremoves the DS1 from theMLG.

No impact. Removes DS1from MLG.

Transport Network

RouterManagement

Reflects DS1interface/sub-interfaceOperStatus “down.”

Edge Router Detects loss of Layer 2.

Removes the DS1 from theMLG.

Removes DS1from MLG.

Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Network element Fault detection Alarms and notifications Automaticrecovery

MLS No impact. No impact. No impact.


FMM-APs No impact. No impact. No impact.

RCS Receives bandwidth changenotification from the BTS.

No impact. No impact.

RCS See SDP and ROP ==> SDP 2138: Shows CriticalAlarm.

SDP 2237: Shows that thisDS1 is not in any MLG.

ROP: Shows Critical Alarmfor bandwidth change butnot the type of alarm.

Updates SDP andTI.

5ESS DCS No impact. No impact. No impact.

1X RNC No impact. No impact. No impact.

OMP-FX No impact. No impact. No impact.

OMC-RAN No impact. OMC-GUI: Shows CriticalAlarm on AP detailed view.

No impact.

Other Indications OP:ALARM

OP:CELL

Automatic recovery actions


• NE impacts:Loss of capacity.

• Subsequent alarms:DS1 alarm.

• Subsequent other indications:None.

• Subsequent service impact:Reduced bandwidth.


Fault resolution

Technician repairs cable cut.


Fault management DS1 (T1/E1) cable cut

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-15


BTS Restores DS1 to MLG.

Sends MLG bandwidth change and MLG DS1 associationchange messages sent to RCS.

Transport Network

Router Management Shows the red alarm has cleared.

Edge Router Reflects DS1 interface/sub-interface OperStatus “up.”

MLS No impact.


FMM-APs No impact.

RCS Receives bandwidth and association change.

ECP SDP 2138: DS1 alarm clears.

SDP 2237: Shows DS1 back to MLG, and MLG DS1association change.

ROP: Reports an alarm clear message that shows The MLGBW change and MLG DS1 association change.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN OMC-GUI: Alarm clears on AP Detailed View.

Other Indications None.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

DS1 (T1/E1) cable cut.................................................................................................................................................................................................................................


Yellow alarm on Incoming DS1 failure to the BTS. Multi-T1 MLG.


Service impact


Resolution

install a new T1 cable between the BTS and edge router.

Severity

Critical.






Networkelement

Fault detection Alarms andnotifications

Automatic recovery

BTS Detects yellow alarmcondition.

No impact. Removes DS1 from theMLG.

Removing TI from the MLGensures that performance isnot impacted, but capacity isimpacted.

Transport Network

RouterManagement


Edge Router Detects red alarmcondition.

Removes DS1 from theMLG.



Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-17

Networkelement


Automatic recovery


RCS No impact. Alarm or notification onNE interface.

No impact. See ECP (below).

ECP See SDP and TI ==> SDP 2138: ShowsCritical Alarm.

SDP 2237: Shows DS1snot in any MLG.

ROP: Receives CriticalAlarm. Text showscritical alarm but notalarm type.

Updates to SDP and TI.




OMC-RAN See OMC-GUI ==> OMC-GUI: ShowsCritical Alarm on APDetailed view.

No impact.

OtherIndications

OP:ALARM

OP:CELL




• Subsequent alarms:None.




Fault resolution

Technician corrects DS1 problem.



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


BTS Restore DS1 to MLG.

Sends MLG bandwidth change and MLG-DS1 associationchange messages.

Transport Network

Router Management Router Management: Reflects DS1 interface/sub-interfaceOperStatus “up.”

Edge Router Detects that signal is good, and adds the DS1 back into theMLG.

MLS No impact.


FMM-APs No impact.

RCS Receives bandwidth and association change.

ECP SDP 2138: DS1 alarm clears

SDP 2237: Shows DS1 back to MLG. Alarm clears and showsDS1 back to the MLG.

ROP: Receives alarm clear message, notification of MLGbandwidth change, and MLG DS1 association change.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN OMC-GUI: DS1 alarm clears on AP Detailed View.

Other Indications No impact.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-19

DS1 (T1/E1) cable cut.................................................................................................................................................................................................................................


Incoming DS1 failure to the BTS for a single-T1 MLG.


Severity

Major.

Service impact

Calls will be dropped. Lost capacity.

Resolution

Install a new t1 cable between the BTS and edge router.






Networkelement

Fault detection Alarms and notifications Automatic recovery

BTS Detects LOS on theDS1.

Detects LOS on the DS1. The URC will attemptto re-establish to its ownMLG for up to 3minutes. If it cannot,URC will re-establishwith MLG from anotherURC in the sameassemblage and sendRCS SL bandwidthchange for the parentURC.

Transport Network

Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement


RouterManagement

Reflects DS1interface/sub-interfaceOperStatus “down.” Linestatus reflects loss of signal.

Edge Router Detects loss of Layer 2. Reflects MLG is OOS. Removes DS1 from LGand marks MLG asOOS.




RCS Detects Loss ofHeartbeat after 24seconds and put theURC out of service.Signaling Link will bere-established. OriginalMLG association willchange to use anotherURCs MLG.

No impact. Signaling isre-established. OriginalMLG association willchange to use anotherURCs MLG. After thesignaling link isestablished again to theshared MLG, theinformation will be sentto the RCS. Receive SLbandwidth change fromBTS.

ECP See SDP and ROP ==> SDP 2131: shows SL OOS forURC

SDP 2138: shows CRC OOS

SDP 2237: shows CRC OOS

SDP 2236: shows SOCdegraded for OneBTS andOOS for URC Modular Cell.

ROP: Receives OOS on URCmessage and “NO CRCHEARTBEAT” message.

Updates to SDP and TI -

SDP 2237: R26 andLater showsParent/Childrelationship.

SDP 2131: shows - ChildURC with “SH” forsignaling link status.

5ESS DCS No impact. No impact.

ROP: Will output an assertfor each lost BHA.

No impact.

RNC No impact. No impact. No impact.



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-21

Networkelement


OMC-RAN See OMC-GUI ==> OMC-GUI: Shows URC isOOS on URC Detailed View.

No impact.

OtherIndications

OP:ALARM

OP:CELL

OP:ALARM

OP:CELL




• Subsequent alarms:Alarm sent to HEH is displayed on TI, SDP, ROP. OMC-RANAutomatic Recovery will display the CRC Signaling Link Sharing Status as″shared″, the CRC of the parent and MLG ID of the parent.

• Subsequent other indications:None

• Subsequent service impact:Loss of capacity.


Fault resolution

Technician to repair the cable and correct the DS1 problem.



BTS When MLG comes back it will be used for bearer traffic only.To use the original MLG for signaling traffic, the URC willnot be rebooted.

Transport Network

Router Management Reflects DS1 interface/sub-interface OperStatus “up.”Linestatus reflects no alarm. Reflects MLG is in service.

Edge Router Detects Layer 2, restores DS1 to MLG and restores MLG toservice.

MLS No impact.


FMM-APs No impact.

RCS BTS notifies RCS that URC is available for bearer traffic andthe MLG Association has changed.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


ECP SDP 2138: DS1 alarm clears.

SDP 2237: Shows DS1 back to MLG

SDP 2236: Becomes fully available.

ROP: Receives alarm clear message, shows MLG bandwidthchange and MLG DS1 association change.

5ESS DCS No impact.

RNC No impact.

OMP-FX No impact.

OMC-RAN OMC-GUI: DS1 alarm clears on AP Detailed View.

Other Indications Calls will be completed through the MLG again.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-23

Bad DS1 cable.................................................................................................................................................................................................................................


High BER (>5*10-5) on outgoing DS1 failure to Edge Router (ER). Multi-T1 MLG .

This is the BER towards the router. Current router software versions do not detectBER.

Fault ID: IPBH-FM-ER-1

Severity

Major.

Service impact

Intermittent voice quality problems due to lost voice packets.

Increase in data retransmissions due to lost data packets.

Resolution

Technician corrects DS1 (T1/E1) problem by installing a new DS1 (T1/E1) betweenthe BTS and the ER..






Networkelement


Automatic recovery

BTS No detection. No impact. No impact.

Transport Network

RouterManagement

May displayintermittent failures.

Edge Router No detection. No impact. No impact.




Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement


Automatic recovery

RCS No impact. May displayintermittent signalinglink failures.

No impact.

ECP See SDP and ROP ==> SDP: May receive acritical alarm if theBER becomes worse,for example 10^-3

SDP 2138: showsmajor alarm.

SDP 2237: Showswhich DS1s areoperational, whichDS1 (may) receive acritical alarm andshow that this DS1 isnot in any MLG.

ROP: May receivemajor alarm report.

No impact.




OMC-RAN See OMC-GUI: OMC-GUI: maydisplay anintermittent majoralarm on the APDetailed View.

No impact.

Other Indications 5ESS DCS TRFC30, section153, IPBHSUP reports countsthat can be checked.

5ESS DCS TRFC30,section 153,IPBHSUP reportscounts that can bechecked.



• NE impacts:None.



Fault management Bad DS1 cable

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-25

• Subsequent service impact:None.


Fault resolution

Technician corrects DS1 (T1/E1) problem by installing a new DS1 between the BTSand the ER..



BTS No impact.

Transport Network

Router Management No impact.

Intermittent problems are gone

MLS No impact.


FMM-APs No impact.

RCS No longer receiving any intermittent notifications

ECP SDP 2138: Alarm clears. No intermittent minor alarms shouldbe displayed.

SDP 2237: Alarm clears. No intermittent minor alarms shouldbe displayed.

ROP: After problem is resolved, no additional reports on thisproblem should be received.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN OMC-GUI: Major alarm is cleared on the AP Detailed View.No intermittent minor alarms should be displayed.

Other Indications TRFC30, Section 153 IPBHSUP counts are no longerincrementing at the high rate previously seen.

Service impact No more intermittent problems.

Fault management Bad DS1 cable

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Cable cut/disconnected between ER and MLS.................................................................................................................................................................................................................................


Edge Router detects loss of connectivity to MLS.


Severity

None.

Service impact

None.

Resolution

Install a new T1 cable between the edge router and the MLS.






Networkelement


Automatic recovery

BTS No impact. No impact. No impact.

Transport Network

RouterManagement

No impact.

Edge Router Detect Loss of directconnectivity to MLS.

Shows ER andMLS EthernetinterfacesOperStatus“down.”

ER removes the interface to theMLS from service.

ER removes direct OSPF routethrough the MLS, chooses analternate OSPF route through themate ER, and routes trafficthrough the mate ER.

MLS Detects Loss of directconnectivity to ER.

See RouterManagement.

MLS removes the interface to theER from service. MLS redirectstraffic to the other ER.

Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-27

Networkelement


Automatic recovery



RCS No impact. No impact. No impact.

ECP No impact. No impact. No impact.




OMC-RAN No impact. No impact. No impact.

OtherIndications

ER and MLS send“linkDown” trap.




• NE Impacts:None.



• Subsequent service impact:Change in delay characteristics.


Fault resolution

Technician repairs/reconnects cable.



BTS No impact.

Transport Network

Router Management Reflects ER and MLS Ethernet interfaces OperStatus “up.”

Edge Router Restores original packet routing.

MLS Restores original packet routing.


FMM-APs No impact.

RCS No impact.

ECP No impact.

Fault management Cable cut/disconnected between ER and MLS

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


5ESS DCS No impact.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN No impact.

Other Indications ER and MLS send “linkUp” trap.

Fault management Cable cut/disconnected between ER and MLS

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-29

Cable cut on serving IPBTS GW GigE interface - StandbyGigE in-service.................................................................................................................................................................................................................................


Loss of Layer 2 is detected by the serving IPBTS GICC. (NAR only.)

Fault ID: IPBH-FM-RNC-1

Service impact

Stable calls should remain active, however there may be some loss of data. Also, somenew call setups or reactivations on the affected BTSs may fail before the RNCrecovers.

Severity

Major.

Other indications

There may be some REPT-CPFAIL reports for new call setups on the ROP.

States

RNC Serving IPBTS GW state changes to “disabled/idle.” This can be viewed on theTPU-GUI. State change reports appear on the ROP.

Resolution

Install a new cable from the 1X RNC to the MLS.






Networkelement

Fault detection Alarms and notifications Automaticrecovery

BTS See ROP ==> No impact. No impact.

Transport Network

RouterManagement

Reflects MLS Enternetinterface OperStatus“down.”

Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement


Edge Router No impact. No impact. No impact.

MLS Detects loss of directconnectivity to GICC.

No impact. Receives agratuitous ARPfrom the newlyactive GW andstarts sendingpackets to it




ECP See SDP, OMC-RAN, EMSand ECP ROP ==>

SDP 2121: “TRBL”indication on RNC summaryindicator.

SDP 2236: May showintermittent change in thedata SOC status.″

ROP: Receives RNC reportfor major alarm againstGigE. The BTS may reportloss of heartbeats dependingon how quickly the RNCdetects the failure.

SDP 2236:Mayshow anintermittentchange in theCarrier-SOC-BHSstatus.


1X 1X RNC Detects loss of ARP beating TPU-GUI:

• GigE port alarm (majoralarm).

• TPU alarm (majoralarm).

Performsautomatic failoverto standby IPBTSGW.

OMP-FX No impact. EMS: TPU Major alarm. No impact.

OMC-RAN No impact. OMC-GUI: TRBL indicationon RNC Summary page.Reports major alarmsagainst the TPU and theGICC.

No impact.

Other Indications There may be someREPT-CPFAIL reports fornew call setups on the ROP.

None. None.

Fault management Cable cut on serving IPBTS GW GigE interface - StandbyGigE in-service

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-31

Networkelement


States RNC Serving IPBTS GWstate changes to“disabled/idle.” This can beviewed on the TPU-GUI.State change reports appearon the ROP.



• NE Impacts:BTS begins to receive heartbeats on the affected BHAs.


• Subsequent other indications:ROP receives RNC state change indication.


• Subsequent states:RNC IPBTS gateway is now active. Standby Status attribute is“Providing Service.” This can be viewed on the TPU-GUI. State change reportsappear on the ROP.

Fault resolution

Technician repairs the cable.



BTS No impact.

Transport Network

Router management eflects MLS Ethernet inteface OpersStatus“up.”

Edge Router No impact.

MLS Receives ARPs from non-serving IPBTS GW.


FMM-APs No impact.

RCS No impact.

ECP SDP 2121: RNC summary indicator may change to Normal

ROP: RNC reports GigE port alarm clear.

5ESS DCS No impact.

1X RNC Detects ARP responses on the GigE.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


OMP-FX EMS: TPU alarm indicator may return to Normal.

OMC-RAN OMC-GUI: GigE port alarm clears. RNC summary indicatormay return to Normal.


States Non-serving IPBTS GW operational state returns to“Enabled.”


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-33

Cable cut on non-serving IPBTS GW GigE interface.................................................................................................................................................................................................................................


Loss of Layer 2 detected by the non-serving IPBTS GICC. (NAR only.)


Service impact

None.

Resolution


Severity

Major.






Networkelement


Automatic recovery


Transport Network

RouterManagement

ReflectsMLSEthernetinterface OperStatus“down.”


MLS Detects loss ofdirect connectivityto GICC.





Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement


Automatic recovery

ECP See impacts toSDP, OMC-RAN,EMS and ECPROP.

SDP 2121: “TRBL”indication on RNCsummary indicator.

ROP: Receives RNCreport on majoralarm against GigE.

No impact.


1X RNC Detects loss ofARP beating.

TPU-GUI: GigE portalarm (major alarm)against the GICC.

None.

OMP-FX See EMS ==> EMS: Reports TPU -Major alarm.

No impact.

OMC-RAN See OMC-GUI==>

OMC-GUI: Shows“TRBL” indicationon RNC Summarypage. Reports majoralarms against theTPU and the GICC.

No impact.

OtherIndications


None.

States RNC Non-servingIPBTS GW statechanges to“disabled/idle.”






• Subsequent device impact:None.


Fault resolution

Technician repairs the cable.

Fault management Cable cut on non-serving IPBTS GW GigE interface

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-35



BTS No impact.

Transport Network

Router Management Reflects MLS Ethernet interface OperStatus “up.”


MLS Receives ARPs from Non-serving IPBTS GW.


FMM-APs No impact.

RCS No impact.

ECP See impacts to SDP, ECP ROP, OMC-RAN and EMS.

SDP 2121: RNC summary indicator may change to Normal

ROP: RNC reports GigE port alarm clear.

5ESS DCS No impact.

1X RNC Receives ARPs from Non-serving IPBTS GW.

TPU-GUI: Reports GigE port alarm clear and TPU alarmindicator may return to “normal.”

OMP-FX EMS:TPU alarm indicator may return to Normal.

OMC-RAN OMC-GUI: GigE port alarm clears. RNC summary indicatormay return to Normal.


States Non-serving IPBTS GW operational state returns to Enabled.

Fault management Cable cut on non-serving IPBTS GW GigE interface

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Cable cut on serving IPBTS GW GigE interface - StandbyGigE out-of-service.................................................................................................................................................................................................................................


Loss of Layer 2 detected by the serving IPBTS GICC. Non-serving IPBTS GICC isout-of-service. Alternate BHS has been assigned and is In-Service. (NAR only).


Severity

Critical.

Service impact

Calls will drop. New data call setups or reactivations on the affected BTSs may failbefore the BTSs establish connections with the alternate BHSs.

Resolution






• Automatic recovery actions: Automatic actions that are initiated when the fault isthis fault event, the order of recovery is identified.


Automaticrecovery

BTS BHAs time-out and calls aredropped.

No impact. 3. Establish newBHAs withalternate BHSs.

Transport Network

RouterManagement:

Reflects MLS Ethernetinterface OperStatus“down.”


MLS Detects loss of directconnectivity to GICC.



Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-37


Automaticrecovery

FMM-APs No impact. No impact. None.

RCS No impact. No impact. 2. Forwardinformation fromthe ECP to the BTS

ECP Receives updates to SDP,OMC-RAN and TI. See ==>

SDP 2121: “TRBL”indication on RNCsummary indicator

SDP 2265: BHSindicator shows BHSis “Unavailable.”

ROP: RNC reportsMajor Alarm againstGigE port and CriticalAlarm against BHSservice. The BTS mayreport loss of heartbeatevent.

1. Assigns alternateBHSs to theaffected RCSs.


1X RNC Detects loss of ARP beating onserving IPBTS GW.

TPU-GUI: Reportsmajor “GigE port”alarm, critical TPUalarm and critical BHSalarm.

No impact.

OMP-FX No impact. No impact.

EMS: Shows criticalalarm against bothTPU shelves

No impact.

OMC-RAN See OMC-GUI ==> OMC-GUI: “TRBL”indication on RNCSummary page.Critical alarms againstthe BHS and TPUs aredisplayed. Majoralarms against theaffected GICCS aredisplayed.

No impact.

Fault management Cable cut on serving IPBTS GW GigE interface - StandbyGigE out-of-service

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


Automaticrecovery

Other Indications TI: OP:ALARM

There may be some“REPT-CPFAIL”reports for new callsetups on the ROPfrom the affectedBTSs.

States RNC IPBTS GW andBHS states change to“disabled/idle.”



• NE impacts:BTS starts receiving heartbeats on new BHAs again.


• Subsequent other indications:BTS to BHS mapping shown in SDP changes.

• Subsequent service impact:New data calls can now be established.


Fault resolution

Technician repairs the cable. Network elements respond to fault resolution in the orderidentified.



BTS 4. Notified by RCS to initiate new associations with theprimary BHS.

Transport Network

Router Management Reflects MLS Ethernet interface “OperStatus” up.


MLS 1a. Will clear down indication for Interface“Oper Status.”


FMM-APS No impact.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-39


RCS 3. Establishes associations with Primary BHS. Establishes allnew data calls on these associations. Terminates associationswith Alternate BHS after all calls on those associations havedrained.

ECP 2. Assigns Primary BHS to the RCSs.

SDP 2121: RNC summary indicator may still show trouble ifonly one IPBTS GW is fixed.

SDP 2265: BHS indicator shows BHS is available.

ROP: RNC reports GigE port alarm clear for the GICC andfor the BHS.

5ESS DCS No impact.

1X RNC 1b. GICC detects working GigE and reports BHS is“enabled/unlocked/idle.”

TPU-GUI: Critical BHS alarm clears and a Major alarm againstone of the GICCs will clear.

OMP-FX EMS: TPU alarm indicator may return to Normal. (or at leastdown to Major dependent on other alarm conditions existing)

OMC-RAN OMC-GUI: Show that the GigE port alarm has been cleared.

Other indications “Link up” trap coming from the router.

Service impact None.

States BHS is available. IPBTS GW is “enabled/unlocked/active.”


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Cable cut on serving IPBTS GW GigE interface.................................................................................................................................................................................................................................


Loss of Layer 2 detected by the serving IPBTS GICC (NAR only.)

Fault ID: IPBH-RNC-7

No alternate BHS has been configured for the BTSs.

Pre-conditions

The following conditions are present for this fault:

• The cable cut on the non-serving IPBTS GW.

• Only the serving IPBTS GW is “unlocked” and “enabled.”

Service impact

Calls served through this BHS will fail.

Resolution

Install a new cable from the 1XRNC to the MLS.

Severity

Critical.






Networkelement


Automatic recovery

BTS All BHS heartbeats willbe lost. BHAs timeoutand calls are dropped.

No impact.

Transport Network

Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-41

Networkelement


Automatic recovery

RouterManagement

Reflects interfaceOperStatus“down.” Layer 2will report thefailure.

Edge Router No impact.. No impact.

MLS Reports the interface asdown.



FMM-APs No impact.. No impact. No impact.

RCS Receives loss of heartbeatalarms from the BTS.

Since there is no alternate BHS,data call originations and datapage responses are not forwardedto the ECPC. The RCS also doesnot send data traffic channelrequests (TP_REQ) to the RNC.

ECP Receives BHS disabledindication from the RNC.

“TRBL”indication onRNC summaryindicator.

SDP 2265: BHSindicator showsBHS isUnavailable.

ROP:RNC reportsMajor alarmagainst GigE portand critical alarmagainst BHSservice. The BTSmay report lossof heartbeatevents, dependingon how quicklythe RNC detectsthe failure.

No impact.

5ESS DCS No impact. No impact. No impact..

Fault management Cable cut on serving IPBTS GW GigE interface

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement


Automatic recovery

1X RNC Detects loss of ARPbeating on serving IPBTSGW.

TPU-GUI:GigEport alarm (majoralarm). TPUalarm indicator isCritical. BHSalarm is critical.

No impact.

OMP-FX No impact. EMS:TPU -Critical alarm.

None.

OMC-RAN OMC-GUI:“TRBL”indication onRNC Summarypage. ReportsTPU criticalalarm.

No impact.

States RNC IPBTS GWand BHS stateschange to“disabled/idle.”

OtherIndications

There may besomeREPT-CPFAILreports for newcall setups fromthe affectedBTSs.



• NE impacts:None

• Subsequent alarms:None


• Subsequent service impact:No new data calls can be established on the impactedBTSs.


Fault resolution

Technician repairs the cable


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-43



BTS 5. Notified by RCS to initiate new associations with the primary BHS.

Transport Network

Router ManagementInterface on MLS will report an OperStatus of up


MLS 1a. Interface OperStatus “down” clears.


FMM-APs No impact.

RCS 3. Establishes associations with Primary BHS. Establishes all new data calls onthese associations.


SDP 2138: Alarms clear.


ROP: RNC reports GigE port alarm clear for the GICC and for the BHS.

5ESS DCS No impact.

1X RNC 1b. GICC detects working GigE and reports BHS is enabled/unlocked/idle

RNC summary indicator may still show trouble if only 1 IPBTS GW is fixed.

TPU-GUI: Critical BHS alarm clears, and a major alarm against one of theGICCs will clear

OMP-FX EMS: TPU alarm indicator may return to Normal. (or at least down to Majordependent on other alarm conditions existing)

OMC-RAN OMC-GUI:Displays show that the GigE port alarm has been cleared. TPU alarmindicator may return to Normal. (or at least down to Major dependent on otheralarm conditions existing)


Service impact: No calls are dropped (stable and transient)

States BHS is available. IPBTS GW is “enabled/unlocked/active.”


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Communication faults

IPGW0 is unreachable.................................................................................................................................................................................................................................


MLS-1 Failure (or L2-A Failure or L2-A to MLS-1 Path Failure)

Fault ID: IPBH-FM-FMMAP-2

Service impact

None

Resolution

Repair MLS-1.

Severity

Major.







Automaticrecovery

BTS Detects Loss of Layer 2. No impact. No impact.

Transport Network


MLS No impact. No impact. Assumes MLS-1and MLS-2,connections will berouted to MLS-2instead of going toMLS-1 until theproblem isresolved.

Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-45


Automaticrecovery


FMM-APs Major alarm will be set againstthe local AP.

Major alarm will beset against the localAP.

Verify the Majoralarm is clearedand verify that theRCS-AP is inactive state.

RCS Receives notification of MLSFailure

Receive Notification ofMLS Failure.

No impact.

ECP See SDP and ROP ==> SDP 2131: ShowsMajor Alarm.

ROP: Reports MajorAlarm.

SDP 2131: Themajor alarm iscleared.

ROP: Major alarmclear message isreported.




OMC-RAN See OMC-GUI ==> OMC-GUI: Major alarmis displayed on the APDetailed View.

OMC-GUI: Majoralarm is cleared onthe AP DetailedView.

Other Indications None. None. None.








Fault resolution

Repair MLS-1.


Fault management IPGW0 is unreachable

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


BTS Re-established socket connection to AP.

Transport Network



MLS Traffic goes through MLS-1 again.


FMM-APs If the path is repaired (ping tests to the GW address succeedor new TCP connections associated with the affected networkopen), then alarm clears.

No impact.

ECP SDP 2131: Major Alarm is cleared.

ROP: Major alarm being cleared is reported.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX EMS: Major Alarm is cleared.

OMC-RAN OMC-GUI: Major Alarm is cleared



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-47

IPGW1 is unreachable.................................................................................................................................................................................................................................


MLS-2 Failure (or L2-B Failure or L2-B to MLS-2 Path Failure).


Severity

Major.

Service impact

None.

Resolution

Repair MLS-2.







Automaticrecovery

BTS Detect Loss of Layer 2. No impact. No impact.

Transport Network


MLS No impact. No impact. Assuming MLS-1and MLS-2,connections will berouted to MLS-1instead of going toMLS-2 until theproblem isresolved.


Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006


Automaticrecovery

FMM-APs Major alarm will be set againstthe local AP. See ECP ==>

Major alarm will beset against the localAP.

Verify the Majoralarm is clearedand verify that theRCS-AP is in anactive state.

RCS Receives Notification of MLSfailure.


ECP See SDP and ROP ==> SDP 2131: ShowsMajor Alarm.

ROP:: Receives MajorAlarm.

SDP 2131: MajorAlarm is cleared.

ROP: Major Alarmcleared message isreceived.

5ESS DCS No Impact, unless the MLS/L2switch failure also impacts theFE interface to the 5ESS DCS.

Alarm or notificationon NE interface.

No impact.



OMC-RAN See OMC-GUI ==> OMC-GUI: Major alarmdisplays on the APDetailed View

OMC-GUI: Majoralarm is cleared onthe AP DetailedView.

Other Indications None. None. None.








Fault resolution

Repair MLS-2.



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-49


BTS Re-established socket connection to AP.

Transport Network


Router Management No. impact.

MLS Traffic goes through MLS-1 again.


FMM-APs If the path is repaired (ping tests to the GW address succeedor new TCP connections associated with the affected networkopen), then BHGmon will clear the alarm.

RCS No impact.

ECP See updates under SDP, ECP ROP and OMC-RAN sections.

SDP 2131: Major Alarm will be cleared.

ROP: Major alarm being cleared will be reported to ROP.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX EMS: Major Alarm will be cleared on GUI

OMC-RAN OMC-GUI: Major Alarm will be cleared on AP detailed view.



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Duplex IPGW access failures.................................................................................................................................................................................................................................


Both IPGWs are unreachable,


Severity

Critical and 2 Major Alarms.

Service impact

None.

Resolution

Repair one or both IPGWs. If the problem is a cable that is bad or was inadvertentlydisconnected, the technician should either connect a new cable or re-connect theexisting cables. In the worst case, cables between the FMM-AP frame and the IPGateways would need to be replaced with new cables.






Networkelement


BTS Detects loss of Layer 2. No impact. BTS will lose thesignaling link andwill attempt toreboot.

Transport Network

RouterManagement

No impact. No impact. No impact.

EdgeRouter




Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-51

Networkelement


FMM-APs If BHGmon determines thatboth the path to IPGW-0 isunreachable, and the path toIPGW-1 is unreachable, itraises a critical alarm againstthe RCS-AP indicating thatthe paths to both IPGW-0 andIPGW-1 are unreachable.

This condition causes afailover of all the activeRCS-IP Backhaul processesrunning on this RCS-AP.

RCS Integrity Services arenotified that a failure hasoccurred. If this AP frame isassociated with that BHCS inthe router, BHCS service willnot be available even if theBHCS process has restartedon another IPBH-enabled APpair.


RCS RCSs will go OOS. No impact. No impact.

ECP See columns on SDP andROP

SDP 2121: shows Critical andMajor Alarms

SDP 2131: displays Critical andMajor Alarms.

ROP: Critical and Major alarmsare reported.

No impact.



OMP-FX Identifiable fault on the NE. EMS: Displays critical, major,and minor alarms.

No impact.

OMC-RAN Identifiable fault on the NE. OMC-GUI: Displays criticalalarm on the AP Detailed View

No impact.

OtherIndications

None. None. None.

Fault management Duplex IPGW access failures

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006




• Subsequent alarms:No impact.


• Subsequent service impact:No impact.


Fault resolution

Repair one or both IPGWs.

If the problem is a cable that is bad or was inadvertently disconnected:

• The technician should either connect a new cable or re-connect the existing cables.

• The cables between the FMM-AP frame and the IP Gateways may need to bereplaced with new cables.

If the problem is resolved by connecting these new cables or re-connecting the cables,the system software will automatically recover the links. See the fault correction resultsbelow.

If the problem is not in the cabling, the contact Lucent Wireless Services (LWS) forfurther diagnosis.



BTS BTS signaling link will be re-established.

Transport Network



MLS No impact.


FMM-APs Verify that the critical alarm is cleared and verify that theRCS-AP is in an active state.

RCs No impact.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-53


ECP SDP 21: critical and major alarms are cleared as follows

• If both IPGWs are now reachable, all critical and majoralarms for these faults are cleared.

• If just one IPGW is now reachable, the critical alarm andone of the major alarms are cleared.

ROP: Receives critical and major alarm clear messages.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN OMC-GUI: If both IPGWs are now reachable, all critical andmajor alarms for these faults are cleared on the AP detailedview. If just one IPGW is now reachable, the critical alarmand one of the major alarms are cleared on the AP detailedview.



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Only remaining 5E GW goes OOS.................................................................................................................................................................................................................................


The 1X RNC is not available and causes the BHS to be disabled. (NAR only.)

An alternate BHS has been configured.


Severity

Critical.

Service impact

When the PSUGW is OOS, all data handoffs being served by BTSs that do not havetheir BHS on the current RNC will fail. This scenario assumes an alternate BHS isavailable. If an alternate BHS is not available, new data calls and reactivations on theBTSs that are served by this BHS will fail until the problem is resolved since the BHSis declared disabled when the PSUGW is OOS.

Resolution

Technician repairs SHO network problem.







Automatic recovery

BTS No impact. No impact. Recovery occurs inthe order shown:

4. Notified by RCSto initiate newassociations with thealternate BHS.

Transport Network

RouterManagement


Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-55


Automatic recovery





RCS No impact. No impact. 3. Establish newBHAs with newBHS.

ECP See impacts to SDP, ECPROP and OMC-RAN ==>

SDP 2121: RNCsummary indication =“TRBL.”

SDP 2265: BHS indicatorshows BHS isunavailable.

ROP: RNC reportscritical alarm (RNC isnot available).

2. Assigns alternateBHSs to the affectedRCSs.


1X RNC RNC detects loss 5E GWsthat are OOS

TPU-GUI: Reports RNCis not available. TPUalarm is Critical.

1. RNC report BHSis disabled.

OMP-FX EMS ==> EMS: Critical alarmagainst both TPUshelves.

No impact.

OMC-RAN OMC-GUI ==> OMC-GUI: “TRBL”indication on RNCSummary page. TPUalarm indicator showscritical alarm.

No impact.

Other Indications RNC call processingstatus indicator on GUIshows not available.

States RNC BHS state ischanged to“disabled/idle.”

Fault management Only remaining 5E GW goes OOS

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006



• NE impacts:BTS Starts receiving heartbeats on new BHAs.


• Subsequent other indications:BTS to BHS mapping shown in SDP changes. RCSreports to IP-BHA changes to the ROP.

• Subsequent service impact:New data calls can now be established.


Fault resolution

Technician repairs SHO network problem.

See Flexent® Wireless Networks 1X RNC OA&M(401-710-082) for repairs to SHOnetwork problems.


Network Element Fault correction resultsNumbers show order of results.

BTS 4. Notified by RCS to initiate new associations with theprimary BHS.

Transport Network

Router Management No Impact

Edge Router No Impact

MLS No Impact


FMM-APs None

RCS 3. Establishes associations with Primary BHS and establishesall new data calls on these associations. Terminatesassociations with Alternate BHS after all calls on thoseassociations have drained.


SDP 2121: RNC summary indicator may change to Norma.

SDP 2265: BHS indicator shows BHS is available.

ROP: RNC reports RNC N/A alarm clear.

5ESS DCS No impact


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-57

Network Element Fault correction resultsNumbers show order of results.

1X RNC 1. RNC detects GWs are OK. Reports BHS enabled to ECP.

TPU-GUI: RNC reports RNC N/A alarm clears; TPU alarmsmay clear.

OMP-FX EMS: TPU alarm indicator may return to Normal. (or at leastdown to Major dependent on other alarm conditions existing).

OMC-RAN OMC-GUI: GigE port alarm clears.


State change BHS returns to “Enabled” state.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

No 1st Hop router connectivity.................................................................................................................................................................................................................................


.

Loss of Layer 3 detected on Serving BPH 0 (If duplex router configuration, then bothfail).

Fault ID: IPBH-FM-DCS-1

Severity

Minor Alarm (Simplex PH Group).

Service impact

Loss of Layer 3.

Resolution

The fault is caused by incorrect provisioning of the IP address for the 1st HopRouter(s). To resolve the problem, provision the correct IP address.

See IPBH Provisioning section, in5ESS® Switch Flexent®/Autoplex®WirelessNetworks ApplicationsOA&M Manual,235-200-100 orOA&M Manual,5APInternational.






Networkelement



Transport Network

RouterManagement


EdgeRouter



Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-59

Networkelement





ECP See impacts to SDP andECP ROP in separatesections.

SDP: Minor alarm will be displayed.

ROP: Minor Alarm messages arereceived.

No impact.

5ESS DCS High Priority ARP-beatfails and there is notraffic reception due to aprovisioning error(incorrect IP addressassignment for the 1sthop router).

1188 MCC: The affected BPH Link Statusis OOS-GW and the Service Status isUNAV; PH Group becomesBPHGRPOFN

118[0-4]MCC: The PH Status of theaffected BPH is ACT-DGR - active,degraded.

ROP: outputs the following:

• REPT SM=sm PSELINK=sm-psu-linkOLD_STAT=ACT NEW_STAT=OOS-GWRATE=NOT APPLICABLE

• REPT SM=sm PHGRP=sm-psu-phgrpOFFNORM NEW STAT POS 1=UNAV POS0=SERVINGOVERLOAD SUMMARY=NORMALOLD STAT POS 1=SERVING

Fail-over - theNon-ServingBPH1 becomesServing andBPH 0becomesUNAV.




OtherIndications

None. None. None.






• Subsequent service impact:No service impact since switched to the other BPH. Nodropped calls.


Fault management No 1st Hop router connectivity

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Fault resolution


See IPBH Provisioning section, 6.11.7 in 5ESS® Switch Flexent®/ AUTOPLEX®Wireless Networks Applications OA&M Manual (NAR 235-200-100) NAR or 5ESS®Switch Flexent®/ AUTOPLEX® Wireless Networks Applications OA&M Manual(5AP) International.

Do the following to correct the fault:

1. Provision the correct IP address for the 1st hop router(s) on the 5ESS DCS RecentViews form 22.32 (NAR) or 9.37 (INTL).

2. Verify connectivity from the BPH to the 1st hop router, enter the commandEXC:PING (NAR) or , EXC-PING(INTL)

3. Verify connectivity from the BPH to the 1st hop router, enter the commandEXC:TRACERT,CHNG=cg# (NAR) or EXC-TRACERT:UNIT=a-b-c-d (INTL)

4. Check physical connection to the router (between L2 switch and router).

5. If router specific debugging tools are available, verify that router ARP policing isnot dropping ARPs received by the router.

6. If in a duplex L2 switch configuration, verify that the interswitch trunk isphysically connected and operational.



BTS No impact.

Transport Network



MLS No impact.


FMM-APs No impact.

RCS No impact.

ECP No impact.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-61


5ESS DCS 1188 MCC: Displays minor alarm (Simplex PH Group).

ROP: reports the following:

• REPT SM=sm PSELINK=sm-psu-link OLD_STAT=OOS-GWNEW_STAT=ACT RATE=NOT APPLICABLE

• REPT SM=sm PHGRP=sm-psu-phgrp NORMAL NEW STATPOS 1=NONSERV POS 0=SERVINGOVERLOAD SUMMARY=NORMALOLD STAT POS 1=UNAV

1X RNC No impact.

OMP-FX No impact.

OMC-RAN No impact.



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

No Ethernet connectivity.................................................................................................................................................................................................................................


Loss of Ethernet Link detected on Serving BPH 0.


Severity


Service impact

None.

Resolution

Technician will fix the problem (cable cut, etc.).

Other indications

None.

Fault detection automatic recovery





Networkelement



Transport Network

RouterManagement



MLS MLS will detectLayer 1 goingaway.

Router Management: Reflects Ethernetinterface OperStatus “down.”

No impact.




Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-63

Networkelement



5ESS DCS Loss of Ethernetconnectivitybetween the BPHand the directlyconnected L2switch/MLS

1188 MCC: The affected BPH LinkStatus is OOS-LK, and the ServiceStatus is UNAV; PH Group becomesBPHGRPOFN

118[0-4]: The PH Status of the affectedBPH is ACT-DGR - active degraded


• REPT SM=sm PSELINK=sm-psu-linkOLD_STAT=ACT NEW_STAT=OOS-LKRATE=NOT APPLICABLE

• REPT SM=sm PHGRP=sm-psu-phgrpOFFNORM NEW STAT POS 1=UNAVPOS 0=SERVINGOVERLOAD SUMMARY=NORMALOLD STAT POS 1=SERVING

Fail-over - theNon-Serving BPH1becomes Servingand BPH 0 becomesUNAV.




OtherIndications

None. None. None.






• Subsequent service impact:No service impact since switched to the other BPH. Nodropped calls.


Fault management No Ethernet connectivity

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Fault resolution

Technician will fix the problem (cut cable, etc.).

Do the following to check success:

1. Execute theOP:IPCFG (NAR) or OP-IPCFG (INTL) command.



4. Check physical connection to the router (between L2 switch and router).

5. If router specific debugging tools are available, verify that router ARP policing isnot dropping ARPs received by the router.

6. If in a duplex L2 switch configuration, verify that the interswitch trunk isphysically connected and operational.



BTS No impact.

Transport Network

Router Management Interface Oper Status “up.”


MLS Reports interface OperStatus “up.”.


FMM-APs No impact.

RCS No impact.

ECP No impact.

5ESS DCS ROP: Event history reported to the ROP.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN No impact.



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-65

No 1st Hop router connectivity.................................................................................................................................................................................................................................



Loss of Layer 3 detected on Non-Serving BPH 0 (If duplex router configuration, thenboth fail).

Severity


Service impact

Loss of Layer 3.

Resolution



Other indications

None.






Networkelement


BTs No impact. No impact. No impact.

Transport Network

RouterManagement




Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement




R CS No impact. No impact. No impact.


5ESS DCS Detects the loss ofheartbeat. HighPriority ARP-beatfails due toprovisioning error(incorrect IP addressassignment for the1st hop router)

1188 MCC: The affectedBPH Link Status isOOS-GW, and the ServiceStatus is UNAV; PH Groupbecomes BPHGRPOFN

118[0-4]: The PH Status ofthe affected BPH isACT-DGR - activedegraded


• REPT SM=smPSELINK=sm-psu-linkOLD_STAT=ACTNEW_STAT=OOS-GWRATE=NOT APPLICABLE

• REPT SM=smPHGRP=sm-psu=phgrpOFFNORM NEW STATPOS 1=UNAV POS0=SERVINGOVERLOADSUMMARY=NORMALOLD STAT POS1=NONSERV

The Non-Serving BPH0becomes UNAV.




OtherIndications

None. None. None.

Automatic recovery actions





.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-67




Fault resolution

The fault is caused by provisioning the incorrect IP address for the 1st Hop Router(s).To resolve the problem, provision the correct IP address.



Use EXC: PING (NAR), EXC-PING (INTL) command to verify connectivity from thisBPH to the 1st hop router. Or use the IP network command EXC:TRCRT,CHNG=cg#(NAR), EXC-TRCRT:UNIT=a-b-c-d (INTL); Check physical connection to the router(between L2 switch and router). If this document should mention router specificdebugging tools then -i.e. verify that router ARP policing is not dropping ARPsreceived by the router. If in a duplex L2 switch configuration, then verify that theinterswitch trunk is physically connected and operational.

Do the following to correct the fault:

1. Provision the correct IP address for the 1st hop router(s) on the 5ESS DCS RecentViews form 22.32 (NAR) or 9.37 (INTL).



4. Check physical connection to the router (between L2 switch/MLS and the router).

5. If this document should mention router specific debugging tools then -i.e. verifythat router ARP policing is not dropping ARPs received by the router.

6. If in a duplex L2 switch configuration, then verify that the interswitch trunk isphysically connected and operational.



BTS No impact.

Transport Network



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006



MLS No impact.


FMM-APs No impact.

RCS No impact.

ECP No impact.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN No impact.



.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-69

No Ethernet connectivity.................................................................................................................................................................................................................................


Loss of Ethernet Link detected on Non-Serving BPH 0.

Ethernet cable has been disconnected or cut.


Severity


Service impact

Loss of Layer 2.

Resolution

To resolve, re-connect the cable or fix the cable.

Other indications

None.






Networkelement

Faultdetection

Alarms and notifications Automatic recovery

BTs No impact. No impact. No impact.

Transport Network

RouterManagement

No impact. Reflects MLS Ethernetinterface OperStatus “down.”

No impact.


MLS Detects loss oflayer 2.




Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement

Faultdetection




5ESS DCS Low PriorityARP-beat failsand no trafficreception

1188 MCC: The affected BPHLink Status is OOS-LK, andthe Service Status is UNAV;PH Group becomesBPHGRPOFN

118[0-4] : The PH Status of theaffected BPH is ACT-DGR -active degraded

ROP outputs the following:

• REPT SM=smPSELINK=sm-psu-linkOLD_STAT=ACTNEW_STAT=OOS-LKRATE=NOT APPLICABLE

• REPT SM=smPHGRP=sm-psu-phgrpOFFNORM NEW STAT POS1=UNAV POS 0=SERVINGOVERLOADSUMMARY=NORMALOLD STAT POS 1=NONSERV

The Non-Serving BPH0 becomesUNAV.




OtherIndications

None. None. None.









.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-71

Fault resolution

Ethernet cable has been disconnected or cut.

To resolve the fault

1. Re-connect the cable or fix the cable.

2. Check the physical connection between BPH and L2 switch/MLS.

3. ExecuteOP:IPCFG (NAR), or OP-IPCFG (INTL) to check the physical connectionbetween BPH and L2 switch/MLS.

4. Check rate on mode on RC/V 33.4/90.7 view and compare it to the rate and duplexmode on the L2 switch/MLS. The rate should be set to 100 Mbps, and the modeshould be FULL

5. Make sure that there are no mismatches.

6. Check IPBHSUP measurements report for Ethernet related problems.

7. Make sure cabling is good at the interfaces.



BTS No impact.

Transport Network

Router Management Reflects MLS interface OperStatus “up.”


MLS No impact.


FMM-APs No impact.

RCS No impact.

ECP No impact.

5ESS DCS See Resolution (above).

1X RNC No impact.

OMP-FX No impact.

OMC-RAN No impact.



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Edge router card failure affecting all associated DS1 interfaces.................................................................................................................................................................................................................................


Edge Router failure (one interface card), no APS

Fault ID: IPBH-ER-5

Service impact

Stable calls will be dropped.

Resolution

Technician replaces the faulty edge router component.

Severity

Major.






Networkelement


Automatic recovery

BTS Detect loss of Layer 2(caused by no LCPheartbeat).

URC reboot. If there is anotheractive CDMA 1X-URC withinthe same cabinet, then automaticrecovery will occur with MLGsharing. If this URC is the parentfor a DO-URC, then theDO-URC will be OOS.

Transport Network

RouterManagement

Showsvendor-specifichardware fault forthe card thatfailed.

Edge Router Detects hardware failure. No recovery.


Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-73

Networkelement


Automatic recovery



RCS Will detect the loss ofheartbeat from RCS toURC and update the SDPpage.

If MLG sharing is invoked, willupdate the SDP page. If notusing MLG sharing, the URCwill still be OOS.

ECP Updates to SDP,OMC-RAN and TI.

SDP 2138:ShowsURC ACT

SDP 2237:ShowsMLG OOS

ROP: ReceivesURC and MLGACT messages.

No impact.

5ESS DCS BHAs associated with thefaulty router card are lost.

5E MCC:Noimpact.

ROP: If the debugflag is turned on,will report loss ofBHA due to arouter cardfailure.

No impact.

RNC BHAs associated with thefaulty router card are lost.

TPU-GUI:Noimpact.

No impact.

OMP-FX No impact. EMS:No impact. None.

OMC-RAN OMC-GUI:OMC-RAN willdisplay a majoralarm on the APDetailed View.

OMC-GUI: Major alarm clears onAP Detailed View.

States None

OtherIndications

SNMP traps forvendor-specificalarms aredisplayed atNMS.

Fault management Edge router card failure affecting all associated DS1interfaces

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006



• NE impacts:None



• Subsequent service impact:Loss of capacity .


Fault resolution




BTS If MLG sharing, restore the links to the MLG. If no MLG sharing, theURC will resume using the local MLG when it finds that it has beenreplaced while going through reboot.

Transport Network

Edge Router Clears the vendor-specific hardware alarms and restores the links to theMLG.

Router Management Clear the vendor-specific hardware alarms

MLS No impact.


FMM-APs No impact.

RCS BTS will notify RCS that the link is back in service. If the RCS hadreported the URC OOS, it is now in service.

ECP SDP 2138: Alarms clear.


ROP:Alarm clears will be reported

5ESS DCS No impact.

RNC No impact.

OMP-FX No impact.

OMC-RAN No impact.


Service impact: Capacity is restored.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-75

Software and configuration faults

BER major threshold crossed.................................................................................................................................................................................................................................


BER Major Threshold crossed (BER = 5 * 10^-5).

High BER on Incoming DS1 failure to BTS. Multi-T1 MLG.


Severity

Major.

Service impact


Resolution

Technician corrects DS1 problem






Networkelement

Faultdetection


BTS Detects BER inexcess of majoralarmthreshold.

No impact. Removes DS1 from MLG.Removing DS1(if is not a last DS1in the MLG) from MLG ensures thatperformance will not be impacted byremoving the T1 from the MLG.DS1 capacity will be impacted.

Sends MLG bandwidth change andMLG DS1 association change whenthe T1 is removed from MLG.

Transport Network

Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement

Faultdetection


RouterManagement


EdgeRouter

Detects loss ofDS1 followingBTS removal.

No impact. Removes DS1 from MLG.




RCS No impact. No impact. See ECP section for report on RCS.

ECP See SDP ==> SDP 2138: shows Major Alarm

SDP 2237: shows DS1 is notin any MLG.

ROP: receives Major Alarm.Text shows major alarm butnot alarm type.

Updates to SDP and TI.




OMC-RAN See OMC-GUI==>

OMC-GUI: shows Major Alarmon AP Detailed view.

No impact.

OtherIndications

OP:ALARM OP:ALARM

OP:CELL



• NE impacts:Loss of capacity





Fault resolution

Technician corrects DS1 problem.


Fault management BER major threshold crossed

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-77

Network element Fault correction results

BTS Restores DS1 to MLG.

Sends MLG bandwidth change and MLG DS1 association changemessages.

Transport Network


Edge Router DS1 is added back into the multi-link.

MLS No impact.


FMM-APs No impact.

RCS Receive bandwidth and association change.

ECP SDP 2138: Alarm clears.

SDP 2237: displays DS1 back to MLG.

ROP: Receives alarm clear message. Text shows MLG bandwidth changeand MLG DS1 association change.

5ESS DCS ROP: Receives notification of possibility of BHA connection lost.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN OMC-GUI: Alarm clears on AP Detailed View.


Fault management BER major threshold crossed

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Active RCS IP goes OOS-F while mate AP is OOS-F.................................................................................................................................................................................................................................


The active RCS IP goes Out of Service - Fault (OOS-F) while the mate AP is OOS-F.

RCS IP Services Failure: resources on the AP are not available - CCMip failure,BHGmon alarm “no path to backhaul network” or Ethernet Interface node (EIN)failure.


Service impact

None.

Severity

Critical.

Resolution

Restore the IP Services on the RCS.

Other indications

None.







Automaticrecovery

BTS Detects loss of signaling link. No impact. No impact.

Transport Network

RouterManagement

No impact.



Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-79


Automaticrecovery


FMM-APs Critical alarm will be setagainst the RCS-IP on both APswhere the IP services failurehas occurred.

No impact. RCS IP processeswill attempt torestart.

If RCS-IM processis still running, theRCS IP serviceswill restart.

If RCS-IM processare not running, theRCS IP serviceswill not restart.

RCS RCS cannot failover No impact. No impact.

ECP See SDP and ROP ==> SDP 2121: showsCritical Alarm

SDP 2131: showsCritical Alarm.

ROP: receives CriticalAlarm notification.

When automaticrecovery issuccessful and RCSIP services comeback, the criticalalarm is cleared.

When automaticrecovery is notsuccessful, thecritical alarmremains.

5ESS DCS No impact. 5E MCC: Will outputan assert on each lostBHA.

No impact.



OMC-RAN See OMC-GUI ==> OMC-GUI: A criticalalarm displays on APDetailed View.

No impact.

Other Indications





Fault management Active RCS IP goes OOS-F while mate AP is OOS-F

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006




Fault resolution

To restore IP service on the RCS:

1. From TICLI, execute the commandRST:RCS # to move the RCS state to active.

2. From TICLI, execute the commandOP:AP #,STATUS or OP:AP#,RCS #,STATUS toverify that the RCS is promoted to the active/standby state .

3. Check the AP ADMIN log file for the messages such as “RCSXX promoted toactive on APYY,”whereXX is the RCS that is restored, andYY the AP number thatis hosting that RCS



BTS BTS signaling link will be re-established.

Transport Network



MLS No impact.


FMM-APs Critical alarm are cleared when one of the RCS-IP’stransitions to the active state. Major alarm are cleared whenboth the Active and Mate AP are in the active state.

RCS No impact.

ECP SDP 2131: Critical Alarm is cleared. Major alarm displays ifthe mate AP is still OOS-F. Major alarm clears when the mateAP is back in the active state.

ROP outputs the following:

• Critical Alarm is cleared.

• Major alarm will still be reported as the Mate AP will stillbe OOS-F.

• Major alarm will be cleared when the Mate AP is back inthe active state.

The same information is also sent to the ADMIN log.

5ESS DCS 5E MCC: If the debug flag is turned on, an assert will beoutput on each lost BHA.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-81


1X RNC No impact.

OMP-FX EMS: Critical Alarm is cleared.

OMC-RAN OMC-GUI: Critical Alarm is cleared on AP Detailed view.

Major alarm displays if the mate AP is still OOS-F.

Major alarm is cleared when the mate AP is back in the activestate.



.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

One DS1 in MLG is not configured in ER, or wrong DS1 isassigned to MLG in ER.................................................................................................................................................................................................................................


One DS1 (T1/E1) in MLG is not configured in edge router (ER), or wrong DS1 isassigned to MLG in ER, this DS1 will not be in the MLG. Remove it from MLG isnot needed.

No PPP Connection on one DS1 in an MLG (other DS1s have PPP connections).


Severity

Minor.

Service impact

Loss of capacity to/from URC.

Resolution

Technician corrects the configuration error in the edge router.







Automaticrecovery

BTS Detects loss of Layer 2 in DS1. No impact. Removes DS1 fromthe MLG

Transport Network

RouterManagement


Edge Router If DS1 is not configured at all,then no effect.

No impact. If wrong DS1 isconfigured, it isremoved from theMLG.

Fault management

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-83


Automaticrecovery



FMM-APs No impact. Alarm or notificationon NE interface.

No impact.

RCS Receives Bandwidth ChangeNotification from the BTS.


ECP See SDP and , ROP ==> SDP 2138: Showsminor alarm

SDP 2237: Shows showwhich DS1s areoperational and showthat this T1 is not inany MLG.

ROP: Receives minoralarm for Bandwidthchange.

No impact.




OMC-RAN See OMC-GUI ==> OMC-GUI: shows minoralarm on AP DetailedView.

No impact.

Other Indications Router sends “linkDown” trapif enabled.

TI: OP:ALARM

Router sends“linkDown” trap ifenabled.

TI: OP:ALARM



• NE impact.s: None.

• Subsequent alarms:None..




Fault management One DS1 in MLG is not configured in ER, or wrong DS1is assigned to MLG in ER

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Fault resolution

Technician corrects the configuration error in the edge router.



BTS Restores the DS1 to the MLG and reports the BandwidthChange Notification to the RCS.

Transport Network

Router Management Shows DS1 interface OperStatus is “up.”

Edge Router Case 1: No DS1 is provisioned. ER will add the DS1 to theconfiguration.

Case 2: Incorrect DS1 is provisioned. Add the correct DS1 tothe MLG.

MLS No impact.


FMM-APs No impact.

RCS No impact.

ECP SDP 2138: Alarms will be cleared.

SDP 2237: Alarms will be cleared

ROP: Receives the alarm clear message and shows MLGbandwidth change.

5ESS DCS No impact.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN OMC-GUI: Alarm is cleared on the AP Detailed view.

Other Indications “Link up” trap comes from the router.

Service impact Capacity is restored.

Fault management One DS1 in MLG is not configured in ER, or wrong DS1is assigned to MLG in ER

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-85

Edge router card failure affecting all associated DS1 interfaces.................................................................................................................................................................................................................................


Edge Router failure (one interface card). APS configured.


Severity

Major.

Service impact

Stable calls may be dropped

Resolution


Fault detection automatic recovery





Networkelement


Automatic recovery

BTS Receive AIS alarm on all DS1sin the MLG.

AIS alarm. No impact if APSswitchover iscompleted before theend of 5 seconds.

Transport Network

RouterManagement

Shows vendor-specifichardware fault.

Edge Router Detects hardware failure. Performs switchoverto the standby router.




Fault management

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Networkelement


Automatic recovery

RCS Detects the loss of heartbeatfrom RCS to URC.


ECP See ROP ==> SDP: No impact.

ROP: May receive BHAloss messages.

No impact.

5ESS DCS No impact. 5E MCC: Will report lossof BHA, if there are isBHA loss due to amultiplexer failure.

ROP: When the debugflag is turned on, ROPwill report loss of BHAif there is BHA lossduring APS switchover.

5E MCC No impact.



OMC-RAN See OMC-GUI ==> No impact. No impact.

OtherIndications

SNMP traps forvendor-specific alarms aredisplayed at NMS.

SNMP traps forvendor-specific alarmsare displayed at NMS.

None.



• NE impacts :None.





Fault resolution

The technician replaces the faulty edge router component and then forces a switchback.



BTS No impact if APS switchover is completed before the end of 5seconds.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


5-87


Transport Network

Router Management Clears the vendor-specific hardware alarms.

Edge Router Switches back to the original router and re-establishes links tothe MLG.

MLS No impact.


FMM-APs No impact.

RCS No impact if APS switchover is completed before the end of 5seconds.

ECP SDP: No impact.

ROP: ROP may receive BHA loss messages.

5ESS DCS ROP: When the debug flag is turned on, ROP reports loss ofBHA if APS switchover can’t completed after 5 seconds.

1X RNC No impact.

OMP-FX No impact.

OMC-RAN No impact.

Other Indications SNMP traps for vendor specific hardware alarms clear.

Service impact None.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

6 6IPBH performance measures

Service measurements

Overview.................................................................................................................................................................................................................................

Purpose

This section describes the tools and information that are available for evaluating andimproving performance in an IP backhaul network using Service Measurements (SM).

Contents

SM for IPBH 6-2

5ESS measurement reports 6-6

5ESS DCS TRFM for IPBH 6-9

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


6-1

SM for IPBH.................................................................................................................................................................................................................................

New counts

Service Measurements (SM) provide counts on equipment within the ECPC.

SM counts

New counts have been added to ECP-SM in support of the RCS/SM to report new cellcounts.

Cell Backhaul (MLG) related counts

Important! Please note that PP blocking in the IP backhaul world implies thatnone of the MLGs (including shared MLGs, if any) are available.

These counts may be used for engineering backhaul facilities at the cell.

Call blocking due to MLG capacity limits

The following SM parameters are expanded to include IP backhaul:

• CDMA Origination/Termination Overflow due to PP or ATM PP blocking––Thiscount is pegged at the cell site whenever the cell site cannot allocate traffic CE fora CDMA call because of packet pipe or ATM packet pipe blocking.This count is pegged even if a cell site allocates traffic CE to a subsequent carrierfor the CDMA call. This event may occur if the variable bandwidth is too small.This count is a subset of CDMA carrier 2 (CDMA Origination/Terminationsoverflow).This count can be used to engineer the backhaul bandwidth. Theorigination/termination overflow is due to no available channel element (CE) andcan be derived by subtracting this count along with CDMA voiceorigination/termination overflow due to BHS blocking and CDMA Packet dataorigination/termination overflow due to BHS blocking from CDMA carrier 2.

• CDMA Handoff Overflow due to packet pipe or ATM packet pipe blocking

• 2G Origination Failures Caused by Inability to Establish a Packet Pipe or ATMPacket Pipe Connection

• 2G Termination Failures Caused by Inability to Establish a Packet Pipe or ATMPacket Pipe Connection

• 3G Origination Denied Due to No Packet Pipe or ATM Packet Pipe Connection

• 3G Termination Denied Due to No Packet Pipe or ATM Packet Pipe Connection

• 2G CDMA CN Termination Failure due to PP/ATM PP Connection

• 3G CDMA CN Termination Failed due to PP or ATM PP Connection Failure

• 3G Origination Assigned 2G Channel - Packet Pipe or ATM Packet Pipe Overflow

• 3G Termination Assigned 2G Channel - Packet Pipe or ATM Packet Pipe Overflow

IPBH performance measures

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

DS1 related counts

The following are new counts for IPBH:

• Average DS1 Occupancy––This count represents the average occupancy of DS1(T1) backhaul link when the BTS is running in IPBH mode. This measurementreports counts for peak occupancy and for average occupancy.Each equipped DS1 is sampled & averaged every 10 seconds, and the averagehourly value is reported. The count helps to monitor the backhaul utilization on aper DS1 basis in terms of throughput by counting the number of bytes transmittedper second and comparing it to the maximum bandwidth of unchannelized DS1 todetermine the ’Average DS1 Occupancy’ percentage.

• Peak DS1 Occupancy––This count represents the peak occupancy of DS1 (T1/E1)backhaul link when the BTS is running in IP Backhaul mode. Each equipped DS1is sampled every 10 seconds, and the hourly count is reported. For a given DS1,the DS1 occupancy is compared with the previous maximum number. If the newmaximum (or peak) has been reached (regardless of forward or reverse direction),the new value is saved.The count allows monitoring of backhaul utilization per DS1 in terms ofthroughput by counting the number of bytes transmitted, and determining thepercentage of peak occupancy for each hourly service-monitoring window bycomparing it with the maximum bandwidth of an unchannelized DS1.

URC signaling counts

Counts for URC signaling are:

• Average Signaling Traffic Load (downlink) per URC––This count provides ameasure of the average signaling traffic load (in the downlink) per URC, which isan aggregation of loading offered by all the signaling links, for a given controller.

• Peak Signaling Traffic Load (downlink) per URC––This count provides a measureof Peak Signaling Traffic load (in the downlink) per URC, which is an aggregationof loading offered by all the signaling links, for a given Controller.

• Average Signaling Traffic Load (uplink) per URC––This count provides a measureof the average signaling traffic load (in the uplink direction) per URC, which is anaggregation of signaling loading offered to all the signaling links for a givencontroller.

• Peak Signaling Traffic Load (uplink) per URC––This count provides a measure ofPeak Signaling Traffic load (in the uplink direction) per URC, which is anaggregation of loading offered to all the signaling links for a given controller.

IPBH performance measures SM for IPBH

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


6-3

AP-related counts

The following are AP-related counts:

• Total RCS Messages Transmitted from the AP per URC––This count reports thetotal number of RCS messages per URC transmitted from an AP to the BTS on thesignaling links. The counts may be used as a critical trigger for AP engineering.The counts are based on the number of messages from/to the base station that aredirectly correlated with AP capacity (processor occupancy) and used forengineering of RCS instances per AP.

• Total RCS Messages Received from the BTS Per URC––This count reports thetotal number of RCS messages per URC received from the BTS on the signalinglinks. The counts may be used as a critical trigger for AP engineering. The countsare based on the number of messages from/to the base station that are directlycorrelated with AP capacity (processor occupancy) and used for engineering ofRCS instances per AP.

• Peak Signaling Traffic Load (downlink) per AP––This count provides a measure ofthe peak signaling traffic load (in the downlink) per AP, which is the sum total ofloading offered (total bytes transmitted over an individual LAN) at a given AP overthe Ethernet link. The loading is obtained by calculating the volume of Ethernettraffic transmitted per second. For a given AP, for every 10 seconds, the trafficloading is compared with the previous maximum number. If the new maximum (orpeak) has been reached, the new value is saved.

• Average Signaling Traffic Load (downlink) per AP––This count provides a measureof the average signaling traffic load (in the downlink) per AP, which is the sumtotal of loading offered (total bytes transmitted over an individual LAN) at a givenAP over the Ethernet link. The loading is obtained by calculating the volume ofEthernet traffic transmitted per second sampled over every 10 seconds.

BHS-related counts

The following are new counts to assist in BHS (at either a PSU or a 1X RNC)engineering:

• CDMA Voice Origination/Termination Overflow due to BHS Blocking––This countis pegged at the RCS AP whenever a BHS cannot be assigned to a CDMA voicecall due to BHS blocking for a given carrier. This count is pegged even if a cellsite allocates traffic CE to a subsequent carrier for the CDMA call.

• CDMA Packet Data Origination/Termination Overflow due to BHS BlockingID––This count is pegged at the RCS AP whenever a BHS cannot be assigned to aCDMA packet data call due to BHS blocking for a given carrier. This count ispegged even if a cell site allocates traffic CE to a subsequent carrier for the CDMAcall.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

• CDMA Voice Handoff Overflow due to BHS Blocking––This count is pegged atthe RCS when the RCS call processing for a CDMA Voice call cannot allocate aBHS for a CDMA Handoff due to BHS Blocking.

• CDMA Packet Data Handoff Overflow due to BHS Blocking––This count ispegged at the RCS when the RCS CP for a CDMA packet data call cannot allocatea BHS for a CDMA handoff due to BHS blocking. This count is not pegged forsemi-soft or hard handoffs; only for soft handoffs.

Current ECPC SM reports that report IPBH

These counts are based on unavailability of packet pipe resources whether it is framerelay packet pipe (FR) or ATM packet pipe or IP (MLG).

The following existing SM parameters can be referenced when evaluating performancefor IP backhaul:

• CDMA Maintenance Busy Usage including:

– CDMA Origination/Termination Overflow Count

– CDMA Handoff Overflow Count

– CDMA Origination/Termination Overflow with Handoff Reserved ChannelsAvailable

• CAMSHO Request denied - Overflow at Secondary

• CAMSHO Degrade to Simplex

• 2G Origination Failed - due to DCS Error

• CDMA Handoff Overflow

• 2G CDMA Origination / Termination Overflow

• Issue On Separating SMS from Voice Call

• CDMA Handoff Overflow Count

• 3G Termination Failed due to DCS Error

• 3G Origination/Termination Overflow

• 3G-only Mobile Origination / Termination Overflow

• Total Origination Attempts Discarded

• Origination Attempts Discarded with MSC Overload


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


6-5

5ESS measurement reports.................................................................................................................................................................................................................................

IPBH –– Backhaul Measurement Report

This report is generated using theOP-TFPHG command for real-time reports or theOP-TRPHG command to retrieve stored reports.

The counts reported include:

• UDPMUX Datagrams Received

• UDPMUX Datagrams Transmitted

• UDPMUX Segments Received

• UDPMUX Segments Transmitted

• UDPMUX Bytes Received

• UDPMUX Bytes Transmitted

• UDPMUX Bundles Transmitted Full

• UDPMUX Bundles Transmitted Packing Timer

• UDPMUX Bundles Transmitted Low Packing Timer

• Backhaul PH Packet Bus Occupancy Percentage

• Maximum Packet Bus Bytes Per PB Occupancy Sampling Period

• Maximum Backhaul PH Packet Bus Occupancy Percent

• Number of 3 Second Intervals in Major Overload

• Number of 3 Second Interval in Critical Overload

• Errored or Unexpected Ethernet Frames Received

• Errored or Unexpected Internet Protocol Datagrams Received

• Errored or Unexpected IP Backhaul Datagrams Received

The following counts are reported separately for each BPH associated with the PHGroup. The BPH isidentified by SM-PSU-SHELF-PH:

• Frames Received on Ethernet Link

• Frames Transmitted on Ethernet Link

• Bytes Received on Ethernet Link

• Bytes Transmitted on Ethernet Link

• Ethernet Pause Frames Received

• Ethernet Pause Frames Transmitted

• Loss of Ethernet Count

• First Hop Router Connectivity Check Failures

• Total Bi-Directional Packet Bus Packets

• Total Bi-Directional Packet Bus Bytes


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

• Messages Received at Application Processor from the Network Processor

• Messages Transmitted from Application Processor to the Network Processor

• ICMP Messages Received

• ICMP Messages Transmitted

• BPH Serving Interval Count

IPBHSUP — IP Backhaul Supplemental Measurement Report

This report is generated using theOP-TFPHG command for real-time reports or theOP-TRPHG command to retrieve stored reports. This report provides IP BACKHAULPH supplemental measurements. The measurements on this report enhance and providegreater detail beyond what is available on the IPBH report.

The counts reported include:

• BackHaul Server Association Connections

• Backhaul Server Association Heartbeat Timeouts

• Maximum BackHaul Server Associations

The following counts shall be reported separately for each BPH associated with the PHGroup. The BPH shall be identified by SM-PSU-SHELF-PH:

• Ethernet Frames Too Short

• Ethernet Frames Too Longt

• Ethernet CRC Errors

• Ethernet Frames Misaligned

• Not Supported Ethernet Type

• IP datagrams with broadcast/multicast address

• Internet Protocol Datagram Too Short

• Bad Internet Protocol Header Checksum

• Bad Internet Protocol Length

• Bad Internet Protocol Header Length

• Destination BPH IP Address Mismatch

• Not Supported Internet Protocol Version

• Not Supported IP Protocol

• IP Fragmented Packets Received

• UDP Datagram Too Short

• Bad UDP Checksum

• Bad UDP Length

• Destination UDP Port Number Out of Range

• Unassigned BHA Frames Received

IPBH performance measures 5ESS measurement reports

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


6-7

• Source Base Station to BHA IP Address Mismatch

• Source Base Station to BHA UDP Port Mismatch

• UDPMUX Too Short

• UDPMUX Length Mismatch

• UDPMUX datagram sequence number mismatch

IPBH performance measures 5ESS measurement reports

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

5ESS DCS TRFM for IPBH.................................................................................................................................................................................................................................

Purpose

Refer to5ESS® Switch Flexent®/Autoplex® Wireless Networks ApplicationsMeasurements Manua,5MM for complete information on 5ESS DCS servicemeasurements

Traffic Measurements

The following sections have been added to the TRFC30 report:

• Section 154 IP backhaul measurements (IPBH)

• Section 153 IP backhaul supplemental measurements (IPBHSUP)

Figure 6-1 5E DCS traffic measurement report for IPBH

OP TRFC30 IPBH TIME 05:59:30SECTION 154: IP BACKHAUL MEASUREMENTS (IPBH)IP BACKHAUL PH GROUP SUMMARY REPORT:SM PSU PHGRP RXUDPMDG TXUDPMDG RXUDPMSEG TXUDPMSEG RXUDPMBYTE3 0 1 3530 3530 3530 3530 203

SM PSU PHGRP TXUDPMBYTE TXUDPMBF TXUDPMPT TXUDPMLT BPHPBOCC3 0 1 203 0 0 3530 0

SM PSU PHGRP MAXPBBYTE MAXBPHOCC MAJOVLD CRITOVLD RXERREFRM3 0 1 1364 4 0 0 14828

SM PSU PHGRP RXERRIPDG RXERRIPBH3 0 1 0 0

IP BACKHAUL PH GROUP REPORT:SM PSU SHLF PH RXEFRM TXEFRM RXBYTE TXBYTE RXEPAUSE3 0 0 6 8025 60 524 3 03 0 1 1 11555 3590 789 269 0

SM PSU SHLF PH TXEPAUSE ENETLOSS ROUTERFC TOTPBPKTS TOTPBBYTE3 0 0 6 0 0 0 98534 82793 0 1 1 0 0 0 98529 8279

SM PSU SHLF PH RXAPMSG TXAPMSG RXICMP TXICMP BPHSERV3 0 0 6 611 60 0 0 03 0 1 1 4141 60 0 0 1800


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


6-9

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Figure 6-2 IPBHSUP report, section 153

OP TRFC30 IPBHSUP TIME 06:29:30SECTION 153: IP BACKHAUL SUPPLEMENTAL MEASUREMENTS (IPBHSUP)IP BACKHAUL PH GROUP SUMMARY REPORT:SM PSU PHGRP BHACON BHAHBTO MAXBHA3 0 10 0 0 0

IP BACKHAUL PH GROUP REPORT:SM PSU SHLF PH ENET2SHRT ENET2LONG ENETCRC ENETMISANSENETTYPE3 0 0 3 0 0 0 0 1503 0 1 10 0 0 0 0 150

SM PSU SHLF PH INVIPMAC IPTOOSHRT IPCHKSUM BADIPLEN IPHDRLEN3 0 0 3 7265 0 0 0 03 0 0 3 7265 0 0 0 03 0 0 3 0 0 0 0 03 0 1 10 0 0 0 0 0

SM PSU SHLF PH UDPCHKSUM BADUDPLEN OORUDPPORT UNASSBHASRCIPMIS3 0 0 3 0 0 0 0 03 0 1 10 0 0 0 0 0

SM PSU SHLF PH SRCUDPMIS UDPMXSHRT UDPMUXLEN UDPMUXMSEQ3 0 0 3 0 0 0 03 0 1 10 0 0 0 0

IPBH performance measures 5ESS DCS TRFM for IPBH

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

7 7Safety and general information

Overview.................................................................................................................................................................................................................................

Purpose

This chapter provides information on hazards, which may arise in the course of yourwork.

Contents

Hazard statements 7-2

Structure of hazard statements 7-3

General hazard statements 7-5

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


7-1

Hazard statements

Overview.................................................................................................................................................................................................................................

Purpose

This section provides information on the structure of hazard statements as well asgeneral and specific hazards, which may arise in the course of your work.

Contents

Structure of hazard statements 7-3

General hazard statements 7-5

Safety and general information

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Structure of hazard statements.................................................................................................................................................................................................................................

Overview

Hazard statements describe the safety risks relevant while performing tasks on LucentTechnologies products during deployment and/or use. Failure to avoid the hazards mayhave serious consequences.

General structure

Hazard statements include the following structural elements:

Item Structure element Purpose

1 Personal injury symbol Indicates the potential for personal injury(optional)

2 Hazard type symbol Indicates hazard type (optional)

3 Signal word Indicates the severity of the hazard

4 Hazard type Describes the source of the risk of damage orinjury

5 Damage statement Consequences if protective measures fail

6 Avoidance message Protective measures to take to avoid the hazard

7 Identifier The reference ID of the hazard statement(optional)


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


7-3

Signal words

The signal words identify the hazard severity levels as follows:

Signal word Meaning

DANGER Indicates an imminently hazardous situation (high risk) which, ifnot avoided, will result in death or serious injury.

WARNING Indicates a potentially hazardous situation (medium risk) which,if not avoided, could result in death or serious injury.

CAUTION When used with the personal injury symbol:

Indicates a potentially hazardous situation (low risk) which, ifnot avoided, may result in personal injury.

When used without the personal injury symbol:

Indicates a potentially hazardous situation (low risk) which, ifnot avoided, may result in property damage, such as serviceinterruption or damage to equipment or other materials.

Safety and general information Structure of hazard statements

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

General hazard statements.................................................................................................................................................................................................................................

Purpose

Provides information on general hazard statements that may arise in the course of yourwork, but are not necessarily related to a specific procedure.

DANGER

Electric shock hazard

This equipment generates high leakage current. This can lead to high voltages withrespect to ground for accessible parts of the installation. Contact with these parts cancause serious health effects, possibly including death, even hours after the event.

This equipment is only suited for permanent connection. Before connecting the powersupply, establish a grounding connection.

WARNING


Contact with energized parts can cause serious injury.

At least one other trained person must be in attendance, who can immediately andsafely disconnect the system if necessary.

This second person must be trained in first aid for emergency purposes.

WARNING


There is a danger of electric shock if the grounding system is inadequate.

You must comply with the grounding requirements for the grounding system.

WARNING


Contact with energized parts can cause serious injury.

Work on energized equipment is only permitted if you are usinginsulated connectionterminals, are adequately trained and follow safe work practices.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


7-5

WARNING


Contact with energized parts can cause serious personal injury.

Seal off the installation area (warning tape, signs) to prevent untrained orunauthorized persons from entering.

Follow safe work practices and lockout/tagout procedures.

WARNING


Some parts of all electrical installations are energized. Failure to follow safe workpractices and the safety warnings may lead to bodily injury and property damage.

For this reason, only trained and qualified personnel (electrical workers as defined inIEC 60215 or EN 60215 + A1 or in the National Electrical Code or in ANSI/NFPANo. 10) may install or service the installation.

WARNING

Laser hazard

The light from laser and high-radiance LED’s may cause eye damage if absorbed bythe retina.

In the US consult ANSI Z136.2, in Europe consult IEC-60825 Safety of laser products,for guidance on the safe use of optical fiber communication systems in the workplace.

WARNING

Falling object hazard

Cabinet may tip when it is moved if an obstacle or a downward step is encountered.

Do not use dolly wheels if the installation location has an uneven surface, steps etc.

WARNING

Overhead load hazard

Cabinet eyebolts can break, severely damaging the cabinet, if a crane is used to lift thecabinet into an upright position.

Ensure that the cabinet is in an upright position before transportation by crane.

Safety and general information General hazard statements

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

WARNING

Inhalation hazard

Inhalation of asbestos fibers can result in serious illness or death.

Buildings constructed before 1980 MAY contain asbestos. Buildings constructed before1970 OFTEN contain asbestos. Potential exposure could occur during routing of cableor wires, removing cables, removing transite or asbestos cement boards, drillingwallboard, transite panels, or floor tiles, removing sprayed on fireproofing, moving orremoving ceiling tiles, installing cable hangers.

Do not disturb asbestos. When asbestos is present ensure potential expose is controlledby adhering to local asbestos management regulations and follow safe work practices.

CAUTION

Service disruption hazard

Condensation can occur in the network element during transport, especially on movingfrom outside to closed rooms. Condensation can cause malfunctioning of the circuitpacks.

Ensure that circuit packs and shelves have reached room temperature and are drybefore taking them into operation.

CAUTION

Service disruption hazard

Tools left in the work area can cause short circuits during operation which can lead tothe destruction of units.

Make sure after finishing your work that no tools, testing equipment, flashlights, etc.,have been left in or on the equipment.

CAUTION

Lifting hazard

Lifting this equipment by yourself can result in injury due to the size and weight of theequipment.

Always use three people or a lifting device to transport and position this equipment.


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


7-7

CAUTION

Flammable material hazard

The heat vent (grill) at the top of the cabinet can become obstructed, preventingventilation of the cabinet.

Make sure that the airvent is not obstructed and remains clear at all times.

CAUTION

ESD hazard

Semiconductor components can be damaged by static discharges.

The following rules must be followed when handling any module containingsemiconductor components:

• Wear conductive or antistatic working clothes (for example, a coat made of 100%cotton).

• Wear the grounded wrist strap.

• Wear shoes with conductive soles on a conductive floor surface or conductive workmat.

• Leave the modules in their original packaging until ready for use.

• Make sure there is no difference in potential between yourself, the workplace, andthe packaging before removing, unpacking, or packing a module.

• Hold the module only by the grip without touching the connection pins, tracks, orcomponents.

• Place modules removed from the equipment on a conductive surface.

• Test or handle the module only with grounded tools on grounded equipment.

• Handle defective modules exactly like new ones to avoid causing further damage.


.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

Glossary

.................................................................................................................................................................................................................................

Numerics

1X RNCRadio Network Controller

.................................................................................................................................................................................................................................

A Adjacent MSC SwitchAn Ethernet/IP Switch

APApplication Processor

APSAutomatic Protection Switch

ARPAddress Resolution Protocol

ASAdaptive Service

ATMAsynchronous Transfer Modes

.................................................................................................................................................................................................................................

B BERBit Error Rate

BHBackhaul

BHABackhaul Association

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


GL-1

BHCABusy Hour Call Attempts

BHCSBackhaul Connection Server

BHSBackhaul ServerA server which bridges bearer path traffic from the IP messages from the BTS onto theinternal busses and protocols of the PSU or RNC for delivery to cards providing frameselection service.

BHSPHBackhaul Server Protocol Handler

BPHBackhaul Protocol Handler

BPSNBackPlane Serial Number

BTSBase Transceiver Station

.................................................................................................................................................................................................................................

C CCMCell Communications Manager

CDMCDMA Digital Module

CF3Control Fanout

CICCCommon Intelligent Carrier Card

CIDCall Identifier

CRCCDMA Radio Controller (Modular cell 1,2, &3 network interface/controller)

CSBCommon System Bus

Glossary

.................................................................................................................................................................................................................................

GL-2 Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

.................................................................................................................................................................................................................................

D DACSDigital Access and Cross-connect System

DCSDigital Cellular Switch (Wireless 5ESS DCS)

DLCIData Link Connection Identifier

DNSDomain Name Server

DNUDigital Network Unit

DS0Digital Service level 0

DS1Digital Service level 1

DSCPDiffServ Code Point

.................................................................................................................................................................................................................................

E E1European Digital signal level 1 transmission rate 2.048 Mbps. Each E1 frame has 32time slots

ECPExecutive Cellular Processor

ECPCExecutive Cellular Processor Complex (Flexent MSC Controller)

EDPElectrostatic Discharge Protection

EREdge RouterA network element that terminates the PPP and ML-PPP protocol stacks from the URCand interchanges packets with IP/Ethernet.

ESDElectrostatic discharge

Glossary

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


GL-3

EVDOEvolution - Data Only (3G1X Wireless)

.................................................................................................................................................................................................................................

F FAFFeature Activation File

FGWFrame Gateway

FIDFeature Identifier

FMMFlexent Mobility Manager

FRFrame Relay

FRPHFrame Relay Protocol Handler

FSFrame Selector

.................................................................................................................................................................................................................................

G GEGigabit Ethernet

GICCGateway Intelligent Carrier Card (RNC)An RNC card connecting Ethernet and ATM facilities with internal RNC busses. IPBHGICC cards are configured as a pair, with one card actively providing BHS service andthe other running standby.

GNP-APGNP Application Processor

GUIGraphical User Interface

GWGateway

.................................................................................................................................................................................................................................

H HDHigh Density

Glossary

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

HSRPHigh-Speed Routing Protocol

.................................................................................................................................................................................................................................

I ICMPInternet Control Message Protocol

IETFInternet Engineering Task Force

IPInternet Protocol

IPBHIP Backhaul

IPBTSIP Backhaul Base Transceiver Station

IPBTSGWIP Backhaul Base Transceiver Station Gateway

IPCPInternet Protocol Control Protocol

.................................................................................................................................................................................................................................

L LAGLink Aggregration Group

LANLocal Area Network

LAPDLink Access Protocol D

.................................................................................................................................................................................................................................

M MbpsMillibits per second

MC ML-PPPMulti-Class Multi-Link Point-to-Point Protocol

ML-PPPMulti-link Point-to-Point Protocol

Glossary

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


GL-5

MLGMulti-Link Group (ML-PPP)A set of 1 to 4 digital facilities grouped into a single logical facility.

MLSMulti-Layer Switch

MSCMobile Switching Center

MTUMaximum Transfer Unit

.................................................................................................................................................................................................................................

N NARNorth American Region

NMSNetwork Management System

NVMNonvolatile Memory

.................................................................................................................................................................................................................................

O OMCOperations & Maintenance Center

OMPOperations and Management Platform

OOSOut of service

OSNOperations Support Network

.................................................................................................................................................................................................................................

P PCFPacket Control Function

PCSPersonnel Communication System

PDSNPacket Data Service Node

Glossary

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

PF3Packet Fanout

PHPacket Handler

PHEPacket Handler for Ethernet

PHGPacket Handler Group

PHVProtocol Handler for Voice

PPPoint-to-point

PPPPoint-to-Point Protocol

PSPacket Switch

PSUPacket Switching Unit (5ESS DCS)

.................................................................................................................................................................................................................................

Q QoSQuality of Service

.................................................................................................................................................................................................................................

R RANRadio Access Network

RCDRelease Configuration Document

RCSRadio Cluster Server

RCVRecent Change and Verify

RMTRemote Maintenance Terminal

Glossary

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


GL-7

RNCRadio Network Controller

RNMSRouter Network Management System

.................................................................................................................................................................................................................................

S SDPStatus Display Page

SHOSoft Handoff

SLSignaling Link

SMService Measurements5ESS Switch Module

SMP5ESS Switch Module Processor

SMSShort Messaging Services

SOCService Option Class

SPSBSimple BTS Startup Protocol

SUSoftware Update

SWSwitch

.................................................................................................................................................................................................................................

T T1A standard digital transmission facility with 24 DS0 channels

TCPTransmission Control Protocol

TGWTraffic Gateway

Glossary

.................................................................................................................................................................................................................................


401-710-090Issue 3, March 2006

TITechnician Interface

TPUTraffic Processing Unit

TSITime Slot Interchange

.................................................................................................................................................................................................................................

U UDPUser Datagram Protocol

UDPMuxUser Datagram Protocol Multiplexing

URCUniversal Radio Controller

.................................................................................................................................................................................................................................

V VRRPVirtual Router Redundancy Protocol

Glossary

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


GL-9

Index

Numerics

1X RNC, 2-15

1XRNC, 4-6Also see: RNC

1X RNC

TPU GUI, 4-7

1X RNCs

hardware requirements,1-5

1X RNC

network interface,1-24

1X1X RNC


5ESS DCS,2-12

5ESS DCS implementation,3-14

5E GW goes OOS,5-55

5ESS DCS

IP address,2-30

OA&M, 4-11

RC Views, 4-12

configure,3-14

install, 3-14


software requirements,1-7

.............................................................

A Active RCS IP goes OOS-Fwhile mate AP is OOS-F,5-76, 5-79

Add

GICC to TPU GUI,3-22

Adjacent switches,2-8

Alarm types,5-3

apeqp

provision, 3-38, 3-39

Architecture,1-19, 2-2

Availability, 1-4

.............................................................

B Backhaul network

current,1-15

IP Backhaul,1-16

Backhaul protocol handler,2-13

Backhaul routers


Backhaul server,2-14, 2-18

Backhaul server association,2-13

Backhaul server associations,4-20

Backplane serial number

retrieve,3-41, 3-41

Base transceiver station,2-4

BER threshold crossed,5-76

BHA, 2-13, 4-20

BHS, 2-14, 2-18

IP address,2-29

BHS GW

5ESS DCS,4-11

BPH, 2-13

BTS, 2-4


IP address,2-28

IPBTS gateway,2-15


OA&M, 4-3

btseqp


Build IPBH network,3-3

.............................................................

C Cable

Fault, 5-30

Cable cut,5-27

fault, 5-17

Calls dropped,5-86

cdmeqp


.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


IN-1

cell2


Commands

I/O, 4-29

Configuration

HLR, 1-3, 1-5

OMC-RAN, 1-3, 1-5

RNC, 2-16

Configure

5ESS DCS,3-14

GICC, 3-18, 3-20, 3-22

IPBTS GW, 3-18

RCS-AP,3-37

RCS-IM, 3-37

Convert

FR to IPBH, 3-4

to IPBH, 3-3

.............................................................

D Data packets

lost, 5-24

Delete

DS1/DS0,3-52

Documentation roadmap,1-9

Dropped calls,5-14, 5-17,5-30, 5-30, 5-37, 5-73, 5-76

DS1, 2-24, 5-24Also see: T1

monitoring, 4-4

DS1 (T1/E1) cable cut,5-17

DS1/DS0

delete after conversion,3-52

DS1s,2-4

.............................................................

E ECP

provision, 3-34

ECPC

OA&M, 4-21, 4-38


status display pages,4-38

Edge router

Fault, 5-24

Edge router card failureaffecting all associated DS1interfaces,5-73, 5-86

Edge routers,2-7


remote,2-7

EIN failure, 5-79

ER failure, 5-73

Ethernet connectivity,5-63

.............................................................

F Fault, 5-30

cable,5-14

Cable,5-24

DS1 (T1/E1) cable cut,5-17, 5-17

T1, 5-24

Feature identifiers,1-2

FIDs, 1-2

FMM-AP, 2-10


OA&M, 4-5

FMM-RCS, 3-33

Forms

apeqp,3-38

btseqp,3-50, 3-50

cdme1p,3-49

cdmeqp,3-49

cell2, 3-44, 3-48

ecp, 3-34

RC/V, 4-21

Frame relay,1-14

.............................................................

G Gateway

IPBTS, 2-15

Gateway intelligent carreircard, 2-18

general hazard statements,7-5

General problem solving mode,5-5

Geographic clustering,2-25

GICC, 2-18

add to TPU GUI,3-22

configure,3-18, 3-20, 3-22

GigE cable,3-22

install, 3-18, 3-20, 3-21

GigE cable

install, 3-22

GigE interface,5-30

Growth

PHE3, 3-16

PSU, 3-16

.............................................................

H Hardware requirements,1-5

HLR configuration,1-3, 1-5

.............................................................

I I/O, 4-29

I/O commands

RNC, 4-9

Index

.................................................................................................................................................................................................................................

IN-2 Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

Implementatin

RNC, 3-18

Implementation,3-1

5ESS DCS,3-14

IPBH network,3-3

phases,3-3

Inputs, 4-29, 4-29

Install

5ESS DCS,3-14

GICC, 3-18, 3-20, 3-21

IPBTS gateway,3-20

IPBTS GW, 3-18

Integrity Manager,3-37

IP address,2-27

5ESS DCS,2-30

BHS, 2-29

BTS, 2-28

IPBH network,2-28

RCS-AP,2-29

requirements,2-27

RNC, 2-30

IP Backhaul architecture,2-2

IP Backhaul network,1-16, 2-1

IP conversion,3-3

IP network

install, 3-6

IPBH

benefits and advantages,1-13

IPBH network

build, 3-3

implementation,3-3

IPBH network architecture,1-19

IPBH network elementschecklist

IP addressing,3-9

IPBH traffic, 1-25

IPBTS GW, 2-15, 4-6

fault, 5-30

State change,5-30

IPBTS GW down,5-34, 5-37

IPGW access failures,5-51

IPGW unreachable,5-45, 5-48

.............................................................

L Layer 3, 5-59

Loss of capacity,5-14, 5-17,5-76

URC, 5-83

Loss of communicationbetween ER and MSL,5-27

Loss of Layer 2,5-34, 5-37,5-70

Loss of Layer 3,5-59, 5-66

Lost data packets,5-24

.............................................................

M Messages

I/O, 4-29

MLG, 2-5

Modular cells,2-4

Monitor

network, 5-3

Multi-link group, 2-5

.............................................................

N Network architecture,1-19, 2-2

Network fault management

General problem solvingmodel, 5-5

Network monitoring,5-3

No 1st Hop router connectivity,5-59, 5-66

No Ethernet connectivity,5-63,5-70

No path to backhaul network,5-79

.............................................................

O OA&M

5ESS DCS,4-11

BTS, 4-3

ECPC,4-21, 4-38

FMM-AP, 4-5

RNC, 4-6

routers and switches,4-2

OMC-RAN, 1-3, 1-3, 1-5, 4-48

One DS1 in MLG is notconfigured in ER, or wrongDS1 is assigned to MLG inER, 5-83

Outputs,4-29, 4-32

.............................................................

P Performance,6-1

PH provisioning,3-16

PHE3 growth,3-16

Post deployment,3-51, 3-51

delete DS1/DS0,3-52

PPP connection,5-83

Pre-conversion

5ESS DCS,3-13

AP-RCS,3-32

FMM-AP, 3-32

RNC, 3-17

Prerequisites,1-5

Protocols

traffic, 2-22

Index

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


IN-3

user traffic,2-20

Provision

apeqp,3-38, 3-39

btseqp,3-50, 3-50

cdmeqp,3-49, 3-49

cell2, 3-44, 3-48

ecp, 3-34, 3-36

RCS-AP,3-33

RNC, 4-6

Provisioning

PH, 3-16

PSU growth,3-16

PSU2e,2-12

PSUGW OOS,5-55

.............................................................

R Radio cluster server,2-10

Radio network controller,2-15

RC View 22.32,4-12

RC View 33.1,4-12

RC View 33.3,4-12

RC View 33.4,4-12

RC View 9.37 (INTL), 4-17




RC Views

22.32,4-12

33.1, 4-12

33.3, 4-12

33.4, 4-12, 4-17

9.37, 4-17

90.5, 4-17

90.6, 4-17

RC.V forms,4-21

RCS, 2-10


RCS-AP,2-10, 3-33

configure,3-37

IP address,2-29

RCS-IM

configure,3-37

Remote maintenance tool,4-3

Remote routers,2-7

Requirements,1-5

hardware,1-5

IP address,2-27

router, 2-8

software,1-7

Retrieve

BPSN, 3-41, 3-41

RMT, 4-3


RNC, 2-15, 3-18Also see: 1XRNC

configuration,2-16

I/O commands,4-9

IP address,2-30

OA&M, 4-6

Router requirements,2-8

Routers,2-6, 2-7, 4-2

install, 3-6

remote,2-7

.............................................................

S Safety and general information,7-3, 7-5

SDP, 4-38

SDP 2101,4-38, 4-40

SDP 2131,4-38, 4-41

SDP 2138,4-38, 4-41, 4-41

SDP 2236,4-38, 4-42

SDP 2237,4-38, 4-43

SDP 2260,4-38, 4-45

SDP 2265,4-38, 4-45

Service measurements,6-1

5ESS DCS,6-9

ECPC,6-2

Signaling traffic,2-22

Software requirements,1-7

Status display pages,4-38

5ESS DCS,4-46

structure of hazard statements,7-3

Supported technologies,1-5

Switches,2-6, 4-2

adjacent,2-8

install, 3-6

.............................................................

T T1

fault, 5-14

Fault, 5-24

Technologies,1-5

Terminology,1-13Also see: Glossary

TPU GUI

screens,4-7

Traffic

signaling,2-22

user,2-25

Traffic flow, 1-25

.............................................................

U User traffic, 2-20

User traffic protocol,1-25

Index

.................................................................................................................................................................................................................................

IN-4 Lucent Technologies - ProprietarySee notice on first page

401-710-090Issue 3, March 2006

.............................................................

V Voice quality problems,5-24

Index

.................................................................................................................................................................................................................................401-710-090Issue 3, March 2006


IN-5

ip backhaul

Documents

lucent technologiesunpublished

information productpurpose

xvxvsafety information

ip backhaulip backhauloverview

trademarksall trademarks

cdma voice

agethis material

united states