IP Backhaul

See notice on first age
Flexent Wireless Networks

IP Backhaul for CDMA Voice and Packet Data
Release 26.0
401-710-090
Issue 3
March 2006
Lucent Technologies - Proprietary

This document contains proprietary information of Lucent Technologies and
is not to be disclosed or used except in accordance with applicable agreements.
Copyright 2006 Lucent Technologies
Unpublished 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 applicable
agreements, contracts or licensing, without the express written consent of Lucent Technologies and the business management owner of the
material.
Trademarks
All trademarks and service marks specified herein are owned by their respective companies.

See notice on first page
Contents
About this information product

Purpose
Reason for reissue
.......................................................................................................................................................................................
xv
Safety information
.....................................................................................................................................................................................
xvi
How to use this information product

Conventions used
...........................................................................................................................................................
Documentation, training and support

How to comment
xvi
.............................................................................................................................................
xvii
....................................................................................................................................................................................
Related information products
xv
...............................................................................................................................................................................................................
xviii
.............................................................................................................................................
..........................................................................................................................................................................................
xix
xx
Introduction to IP Backhaul
IP Backhaul
Overview
.........................................................................................................................................................................................................
.................................................................................................................................................................................
1-2
.....................................................................................................................................................................................................
1-4
IP Backhaul features
Availability
Prerequisites
...................................................................................................................................................................................................
IPBH documentation roadmap

Benefits of IP Backhaul
...........................................................................................................................................................
......................................................................................................................................................................
1-5
1-9
1-13
................................................................................................................................................................
1-19
...............................................................................................................................................................................................
1-25
IPBH network architecture

IPBH traffic
1-1
.................................................................................................................................................................................................................................
401-710-090
iii
Issue 3, March 2006
Contents
IP Backhaul network overview

Overview
.........................................................................................................................................................................................................
Reference Diagram
....................................................................................................................................................................................
Base transceiver station
..........................................................................................................................................................................
Backhaul routers and switches
2-4
2-6
2-10
....................................................................................................................................................................................................
2-12
...........................................................................................................................................
2-15
............................................................................................................................................................................
2-20
Radio network controller (1X RNC)

User traffic protocols
..................................................................................................................................................................
2-22
............................................................................................................................................................................................
2-24
Signaling traffic protocols

DS1s in IPBH
..................................................................................
2-25
.............................................................................................................................................................................................
2-27
Backhaul server assignment and PSU2e/1X RNC engineering

IP Addressing
3
2-2
...............................................................................................................................................................................
Radio cluster server

5ESS DCS
...........................................................................................................................................................
2-1
IP Backhaul implementation
Overview
.........................................................................................................................................................................................................
3-1
Implement and build the IPBH network

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

Overview
.......................................................................................................................................................................................................
Prepare 5ESS DCS for conversion
...............................................................................................................................................
3-13
3-14
Pre-conversion: Prepare 1X RNC for IPBH

Overview
.......................................................................................................................................................................................................
..............................................................................................................................................
3-18
........................................................................................................................................................................
3-20
1X RNC implementation overview

Install IPBTS Gateway
3-17
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
iv
Contents
Pre-conversion: Prepare FMM-AP and RCS for IPBH

Overview
.......................................................................................................................................................................................................
...............................................................................................................................................................
3-33
..............................................................................................................................................................................
3-34
FMM-RCS implementation
Provision ecp form
.........................................................................................................................
3-37
..........................................................................................................................................................................
3-38
Configure FMM-RCS IP Integrity Manager

Provision apeqp form
Retrieve Backplane Serial Number (BPSN)

Provision cell2 form
3-32
...........................................................................................................................
3-41
..............................................................................................................................................................................
3-44
Provision cdmeqp form

Provision btseqp form
......................................................................................................................................................................
3-49
........................................................................................................................................................................
3-50
Post deployment
Post deployment activities
.................................................................................................................................................................
Delete DS1/DS0s used with FR-based FMM-RCS

4
............................................................................................................
3-51
3-52
OA&M for IP Backhaul

Overview
.........................................................................................................................................................................................................
4-1
Routers and switches

...........................................................................................................................................................................
4-2
...........................................................................................................................................................................
4-3
FMM-AP OA&M
.......................................................................................................................................................................................
4-5
1X RNC OA&M
........................................................................................................................................................................................
4-6
Router/switch OA&M
BTS OA&M
BTS OA&M for IPBH
MSC
.................................................................................................................................................................................
4-11
............................................................................................................................................................................................
4-21
5ESS DCS OA&M

ECPC OA&M
....................................................................................................................................
4-29
...............................................................................................................................................................................
4-38
Input/Output commands and messages

Status display pages
.................................................................................................................................................................................................................................
401-710-090
v
Issue 3, March 2006
Contents
OMC-RAN
Monitor IPBH from the OMC-RAN
5
.........................................................................................................................................
4-48
Fault management
Overview
.........................................................................................................................................................................................................
5-1
Network monitoring
Fault management
......................................................................................................................................................................................
General problem solving model
........................................................................................................................................................
Network monitoring and fault detection
......................................................................................................................................
5-3
5-5
5-7
......................................................................................................................................................
5-10
DS1 (T1/E1) cable cut
.........................................................................................................................................................................
5-14
.........................................................................................................................................................................
5-17
.........................................................................................................................................................................
5-20
..........................................................................................................................................................................................
5-24
Sample section: Identified fault

Cable faults
Bad DS1 cable
Cable cut/disconnected between ER and MLS
.....................................................................................................................
...................................................
5-30
.....................................................................................................
5-34
Cable cut on serving IPBTS GW GigE interface - Standby GigE in-service

Cable cut on non-serving IPBTS GW GigE interface
5-27
..........................................
5-37
...............................................................................................................
5-41
IPGW0 is unreachable
..........................................................................................................................................................................
5-45
..........................................................................................................................................................................
5-48
Cable cut on serving IPBTS GW GigE interface - Standby GigE out-of-service

Cable cut on serving IPBTS GW GigE interface
Communication faults
Duplex IPGW access failures
..........................................................................................................................................................
..............................................................................................................................................
5-55
......................................................................................................................................................
5-59
....................................................................................................................................................................
5-63
Only remaining 5E GW goes OOS

No 1st Hop router connectivity
No Ethernet connectivity
5-51
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
vi
Contents

......................................................................................................................................................
5-66
....................................................................................................................................................................
5-70
.............................................................................
5-73
..........................................................................................................................................................
5-76
Edge router card failure affecting all associated DS1 interfaces

Software and configuration faults
BER major threshold crossed
Active RCS IP goes OOS-F while mate AP is OOS-F
...................................................................................................
............................
5-83
.............................................................................
5-86
One DS1 in MLG is not configured in ER, or wrong DS1 is assigned to MLG in ER
6
5-79
IPBH performance measures

Service measurements
Overview
.........................................................................................................................................................................................................
SM for IPBH
................................................................................................................................................................................................
5ESS measurement reports
...................................................................................................................................................................
5ESS DCS TRFM for IPBH

7
...............................................................................................................................................................
6-1
6-2
6-6
6-9
Safety and general information

Overview
.........................................................................................................................................................................................................
7-1
Hazard statements
Overview
.........................................................................................................................................................................................................
...........................................................................................................................................................
7-3
....................................................................................................................................................................
7-5
Structure of hazard statements

General hazard statements
7-2
Glossary
Index
.................................................................................................................................................................................................................................
401-710-090
vii
Issue 3, March 2006
List of tables
1-1
Related network features
1-2
Network elements in an IPBH network and required changes
1-3
1-4
.....................................................................................................................................................
1-3
....................................................................
1-6
Document Roadmap of IPBH tasks
..............................................................................................................................
1-9
Differences between FR and IPBH
............................................................................................................................
1-14

2-1
Router and switch documentation resources
2-2
Bearer traffic protocols for IPBH network
2-3
Signaling traffic protocols for IPBH network
2-4
IPBH component IP addressing
...........................................................................................................
............................................................................................................
2-6
2-20
.....................................................................................................
2-22
....................................................................................................................................
2-27
3-1
Phases of IPBH implementation
3-2
FR to IPBH implementation functions
3-3
IPBH new hardware requirements checklist for an existing network
3-4
IPBH cabling requirements checklist
3-5
IPBH software requirements checklist
3-6
3-7
AP VLAN checklist
3-8
BHS VLAN IP checklist
3-9
ecp form-IPBH fields
.....................................................................................................................................
.......................................................................................................................
.....................................................
........................................................................................................................
3-3
3-4
3-9
3-10
.....................................................................................................................
3-10
....................................................................................................................................
3-11
.............................................................................................................................................................
3-11
...................................................................................................................................................
3-12
.........................................................................................................................................................
3-34
.................................................................................................................................................................................................................................
401-710-090
ix
Issue 3, March 2006
List of tables
3-10
apeqp form-IPBH fields
...................................................................................................................................................
3-38
3-11
cell2 form-IPBH fields
......................................................................................................................................................
3-44
3-12
cdmeqp form-IPBH fields
3-13
btseqp form-IPBH fields
..............................................................................................................................................
3-49
.................................................................................................................................................
3-50

4-1
Modified 1X RNC I/O commands
4-2
Recent Change Views for 5ESS DCS (NAR and INTL)
4-3
New inputs by interface
4-4
Modified inputs
4-5
New outputs
4-6
Modified outputs
4-7
5ESS DCS inputs and outputs
4-8
New and modified SDP pages for IPBH
................................................................................................................................
4-9
.............................................................................
4-12
....................................................................................................................................................
4-30
.....................................................................................................................................................................
4-31
..............................................................................................................................................................................
4-33
..................................................................................................................................................................
......................................................................................................................................
................................................................................................................
4-34
4-36
4-38
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
List of figures
1-1
Current backhaul network
1-2
Typical IP Backhaul network with 5ESS DCS/PSU2e
1-3
Typical IP Backhaul network with 5ESS DCS/PSU2e and 1X RNC
1-4
IPBHNetwork
1-5
IPBH architecture
................................................................................................................................................
..................................................................................
1-16
1-17
..................................................
1-18
..........................................................................................................................................................................
1-19
..................................................................................................................................................................
1-21

....................................................................................................................
2-2
.......................................................................................................................................................
2-7
2-1
IP Backhaul network reference diagram
2-2
IPBH network topology
2-3
RCS signaling conversion: simplified view
2-4
5ESS Switch packet handlers in PSU2e
2-5
IPBTS GW Sparing
2-6
1X RNC shelf configuration for IP Backhaul
2-7
1X RNC BHS processes
2-8
Bearer traffic protocol stacks
2-9
Signaling traffic protocol stacks
..........................................................................................................
2-11
.................................................................................................................
2-12
.............................................................................................................................................................
2-16
.....................................................................................................
2-18
...................................................................................................................................................
2-19
.........................................................................................................................................
.................................................................................................................................
2-20
2-22
3-1
IPBH network topology
3-2
5ESS DCS provisioning for IPBH
3-3
1X RNC provisioning for IPBH
.......................................................................................................................................................
3-6
.............................................................................................................................
3-15
..................................................................................................................................
3-18
.................................................................................................................................................................................................................................
401-710-090
xi
Issue 3, March 2006
List of figures

4-7
4-1
RNC Configuration Data
4-2
BHS Level IPBH Parameters
4-3
RNC Level IPBH Parameters screen
4-4
RC View 22.32 (NAR): Protocol Handler Group Definition 1 of 4
.....................................................
4-13
4-5
.....................................................
4-13
4-6
.....................................................
4-14
4-7
.....................................................
4-14
4-8
RC View 33.1 (NAR): IP Processor Assignment 1 of 3
..............................................................................
4-15
4-9
RC View 33.1 (NAR): IP Processor Assignment 2 of 3
..............................................................................
4-15
4-10
RC View 33.1 (NAR): Internet Protocol (IP) Processor Assignment 3 of 3
4-11
RC View 33.3 (NAR): IP Processor Routing to Interface
4-12
RC View 33.4 (NAR): IP Interface Assignment 1 of 2
4-13
RC View 33.4 (NAR): Ethernet IP Interface Assignment 2 of 2
4-14
RC View 9.37 (INTL): Protocol Handler Group Definition 1 of 2
.......................................................
4-18
4-15
RC View 9.37 (INTL): Protocol Handler Group Definition 2 of 2
.......................................................
4-18
4-16
RC View 90.5 (INTL): IP Processor Assignment 1 of 2
.............................................................................
4-19
4-17
RC View 90.5 (INTL): IP Processor Assignment 2 of 2
.............................................................................
4-19
4-18
RC View 90.6 (INTL): IP Processor Routing to Interface
4-19
RC View 90.7 (INTL): IP Interface Assignment
4-20
RC/V form: ecp
4-21
RC/V form: btseqp
.............................................................................................................................................................
4-23
4-22
RC/V form: btseqp
.............................................................................................................................................................
4-24
4-23
RC/V form: cell2
...................................................................................................................................................................
4-25
4-24
RC/V form: cell2
...................................................................................................................................................................
4-26
4-25
RC/V form: cdmeqp
4-26
RC/V form: apeqp
...................................................................................................................................................
.........................................................................................................................................
...........................................................................................................................
4-8
4-9
...................................
4-16
...........................................................................
4-16
................................................................................
4-16
............................................................
4-17
..........................................................................
4-20
.............................................................................................
4-20
......................................................................................................................................................................
4-22
..........................................................................................................................................................
4-27
................................................................................................................................................................
4-28
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
xii
List of figures
4-27
SDP 2101
....................................................................................................................................................................................
4-40
4-28
SDP 2131
....................................................................................................................................................................................
4-41
4-29
SDP 2138
....................................................................................................................................................................................
4-42
4-30
Status display page: 2236
.................................................................................................................................................
4-43
4-31
Status display page: 2237
.................................................................................................................................................
4-44
4-32
SDP 2260
....................................................................................................................................................................................
4-45
4-33
SDP 2265
....................................................................................................................................................................................
4-46
4-34
5ESS-DCS PHGRP status page: MCC 1188
.......................................................................................................
4-47
4-35
OMC-RAN BTS Overview - server=Lab#
......................................................................................................
4-49
4-36
OMC-RAN Network Manager - IPBH Enabled information
4-37
OMC-RAN Network Manager - IPBH SocList
4-38
4-39
4-50
.................................................................................................
4-51
OMC-RAN Network Manager - IPBH BPSN
....................................................................................................
4-52
OMC-RAN Network Manager - IPBH BPSN
....................................................................................................
4-53
Fault management
5-1
....................................................................
Network monitoring
...............................................................................................................................................................
5-7

6-1
5E DCS traffic measurement report for IPBH
6-2
IPBHSUP report, section 153
......................................................................................................
........................................................................................................................................
6-9
6-10
.................................................................................................................................................................................................................................
401-710-090
xiii
Issue 3, March 2006

Purpose
This document describes the IP Backhaul for CDMA Voice and Packet Data (IP
Backhaul) optional feature for 3G1X CDMA in Lucent Technologies
Flexent /AUTOPLEX wireless networks.
Reason for reissue
This issue of this document (Issue 3, March 2006), supersedes Issue 1 (December
2005). Issue 2 was an Lucent Technologies internally available document in support of
Release 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 is
described in Flexent /Autoplex Wireless Networks BTS conversion from LAPD
to IPBH, 401-612-841.
Modifications to the following sections that have been replaced by the BTS
conversion from LAPD to IPBH, 401-612-841: Pre-conversion and Conversion
sections. See Chapter 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 the
5ESS functionality for FID-10665.0 that was delivered in Release 25.0 and
includes updated document references to 5ESS DCS international documents.
FID 10665.11: IPBH Fault Management Scenarios for IPBH. See Chapter 5,
Fault management.
Addition of a road map to all generally available Lucent Technologies product
documents that support IPBH. See IPBH documentation roadmap (p. 1-9).
.................................................................................................................................................................................................................................
401-710-090
xv
Issue 3, March 2006
,
Safety information
This information product contains hazard statements for your safety. Hazard statements
are given at points where safety consequences to personnel, equipment, and operation
may 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 the

features that make up IP
backhaul and gives a brief
overview of the feature.
Chapter 2, IP Backhaul network overview
This chapter provides a look

at the IP backhaul network
and its components.
Implementation of IPBH (p. 3-3)
This chapter provides

information about deployment
of IP backhaul.
Chapter 4, OA&M for IP Backhaul

information about OA&M
activities for the network
elements in support of IP
backhaul.
Chapter 5, Fault management

troubleshooting information
for the IPBH network.
Chapter 6, IPBH performance measures

information about performance
and capacity measurements for
IP backhaul.
Chapter 7, Safety and general information
This chapter provides safety

and hazard information.
Glossary
The glossary contains a list of

terminology, acronyms and
their expansions and
abbreviations.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
,
xvi
Conventions used
The following conventions are used in this document:

Typographic conventions
This information product presents different types of information in different typefaces

to emphasize the nature of the information:
Literal user input: Keystrokes that are entered character by character exactly as
shown 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 to
another appear in monospace italic type.
For example:
cd directory
where directory = the directory to which to change.

Literal system output: The names of files, directories, forms, messages, and other
information that a system outputs exactly as shown in the text appear in monospace
type.
For example:
RST SPA=cnam REQUEST ACKNOWLEDGED
Variable system output: Values that vary from one instance to another in system
output appear in monospace type.
For example:
RST SPA=SPA_NAME REQUEST COMPLETED
where SPA_NAME = the name of the Service
Package Application (SPA) that is
successfully restored.
Key names: The names of keys on a terminal keyboard are indicated by bold
letters.
For example:
Press the F4 (Enter Query) function key.
Key symbols: The Crtl (Control) key is signified by the caret ( ^ ) symbol. When
the ^ symbol precedes the name of another key (as in ^e), press the Crtl key and
the other key simultaneously.
Variable information: Variable data to be entered is identified in monospace type.
For example:
URCm where m represents a different type of universal radio control cell.
.................................................................................................................................................................................................................................
401-710-090
xvii
Issue 3, March 2006
,
Actions for user input
In this information product, the following words specify what action you should
perform to input data or execute commands:
The word enter means to key in the specified keystrokes (such as a command) and
then press the Enter or Return key.
For example:
Enter the following command:
apappconfig
The word press means to push down the specified key or keys on the keyboard.
For example:
Press the F4 (Enter Query) function key.
The word type means to key in the specified keystrokes (such as a value in the
field of a form) without pressing the Enter or Return key.
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 hardcopy

and CD-ROM formats. For descriptions of available documentation, see the
Flexent/AUTOPLEX Wireless Networks Customer Documentation Catalog
(401-610-000).
Documentation
The following documents are either referenced in this document or contain information
that is related to topics that are covered in this document:
5ESS Switch Flexent /Autoplex Wireless Networks Applications Manual, NAR

235-200-100.
5ESS Switch Flexent /Autoplex Wireless Networks Applications Input/Output
Messages, 235-600-700/750.
5ESS Switch Flexent /Autoplex Wireless Networks Applications Applications
OA&M Manual, 5AP
Flexent /Autoplex Wireless Networks System Capacity Monitoring and
Engineering Guidelines, 401-610-009.
Flexent /Autoplex Wireless Networks Database Update Manual, 401-610-036.
Flexent /Autoplex Wireless Networks Input Messages Manual, 401-610-055.
Flexent /Autoplex Wireless Networks Output Messages Manual, 401-610-057.
Flexent /Autoplex Wireless Networks Service Measurements, 401-610-135.
5ESS Switch Flexent /Autoplex Wireless Networks Applications5MM Measurements Manual
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
,
xviii
Flexent /Autoplex Wireless Networks ECP OA&M and SDP Maintenance Control
Procedures, 401-610-160.
Flexent /Autoplex Wireless Networks BTS conversion from LAPD to IPBH,
401-612-841.
Flexent /Autoplex Wireless Networks Operations and Maintenance Center Radio
Access 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.0
Operations, Administration and Maintenance, 401-710-122
Documentation, training and support
The 401-010-001 Flexent /Autoplex Wireless Networks Systems Documentation

CD-ROM and web site provides the following link to an information document: To
obtain 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 technical
support 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 them
via the web at https://support.lucent.com or the telephone number listed under the
Technical 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 will
either transfer your call directly to a customer technical support representative or
.................................................................................................................................................................................................................................
401-710-090
xix
Issue 3, March 2006
,
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 the Online Comment Form

(http://www.lucent-info.com/comments/enus/) or email your comments to the
Comments Hotline (comments@lucent.com).
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
,
xx
I ntroduction to IP Backhaul
1
IP Backhaul
Overview
.................................................................................................................................................................................................................................
Purpose
This document describes the CDMA technology IP Backhaul offer that is available
from Lucent Technologies. It provides an overview of IP Backhaul and the IP Backhaul
network, provides implementation requirements and describes the implementation steps
that are needed. In addition OA&M functions and processes needed for IPBH are
described and performance information about a Lucent Technologies IP Backhaul
network are provided.
Internet Protocol (IP) is the standard protocol that forms the basis of the Internet as
defined by the Internet Engineering Task Force (IETF). IP works in networks with
numerous and varied types of hardware and software, and it allows full peer-to-peer
communications between any nodes in the network. Backhaul is the means by which
the base transceiver stations (BTSs) connect to the mobile switching center (MSC).
Contents
1-2
Availability
1-4
Prerequisites
1-5
1-9
1-13
1-19
IPBH traffic
1-25
.................................................................................................................................................................................................................................
401-710-090
1-1
Issue 3, March 2006
IP
Backhaul features
.................................................................................................................................................................................................................................
IP Backhaul FIDs
IP Backhaul was introduced initially in ECP Release 25.0. The individual feature
identifiers (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 feature
provides IPBH support on Satellite RCS for the 5th slot in the FMM-AP
platform.
FID-10665.1IP Backhaul for CDMA (99-5E-8530): This feature delivers the
5ESS 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 the
signaling traffic to be rerouted to another MLG in a different URC in the case
of the serving MLGs failure.
FID-10665.11: IPBH Fault Management: IPBH OA&M Fault Management
scenarios for an IPBH network.
FID-12143.2: Cell Reliability and Engineering Improvements for IPBH RCS
APs
Release 25.0 features
FID 10666.1IP Backhaul for CDMA Modular Cell 1.0/2.0/3.0/4.0 (Cell, ECP
and 5E Development) uses the following FIDs:FID 10665.0/10666.0IP
Backhaul for CDMA (Modular Cells 1, 2, 3): Supports IP Backhaul between the
base transceiver station (BTS) and the mobile switching center (MSC) for
CDMA technology applications, is activated through a feature activation file
(FAF).
FID 10665.1Backhaul for CDMA (99-5E-8530): This feature supports IP
Backhaul in the 5ESS DCS in support of FID 10665.0/FID10666.0.
FID 10665.16IPBH: BTS Conversion from LAPD to IPBH: This feature was
available in Release 25.0, SU4 and converts an existing LAPD network using
frame relay to an IPBH network. See optional feature document Flexent
Wireless Networks BTS Conversion from LAPD to IPBH, , 401-612-841.
FID10665.3OMC-RAN support for IP Backhaul: This feature supports
OMC-RAN for FID10665.0/FID10666.0:
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-2
FID 10674.1This features introduces the support for IP based connectivity

from the BTS to the RNC providing the IP Backhaul Server (BHS) function.
FID 12170.0RMT capability at the MSC: Supports IP Backhaul FIDs

10665.0/10666.0 for remote RMT access from the MSC, allows the remote
maintenance terminal (RMT) to communicate with a cells URC via a LAN
connection of a particular AP. Reduces the need for a physical cell site visit to
change backplane parameters from frame relay (FR) to IP Backhaul (IPBH) .
The following table identifies how specific network features work with IPBH.
Table 1-1
Feature
Comment
Home location register

(HLR)
The IP Backhaul feature is independent of HLR configuration
The Operations and

Maintenance Center Radio
Access Network (OMC-RAN)
provides OA&M capabilities
for a Flexent wireless
network.
The OMC-RAN can be installed in the network either prior to or

following the installation of an IPBH network
See Operations and Maintenance Center Radio Access Network
(OMC-RAN) Operations, Administration, and Maintenance (OA&M),
401-662-105 for information on planning and implementation of the
OMC-RAN.
Using OMC-RAN with IPBH
See Operations and Maintenance Center Radio Access Network (OMC-RAN)

Operations, Administration, and Maintenance (OA&M), 401-662-105 for information
on planning and implementation of the OMC-RAN.
.................................................................................................................................................................................................................................
401-710-090
1-3
Issue 3, March 2006
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 for
International markets.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-4
Prerequisites
.................................................................................................................................................................................................................................
Supported technologies
The IP Backhaul feature is supported in the following air-interface technologies:
CDMA cellular
CDMA Personnel Communication System (PCS)
The following table identifies how specific network features work with IPBH.
Feature
Comment
HLR
The IP Backhaul feature is independent of home

location register (HLR) configuration
OMC-RAN
The OMC-RAN can be installed in the network

either prior to or following the installation of an
IPBH network
See Flexent /Autoplex Wireless Networks
Operations and Maintenance Center Radio Access
Network (OMC-RAN) Operations, Administration,
and Maintenance (OA&M), 401-662-105 for
information on planning and implementation of the
OMC-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 hardware
changes for IPBH.
.................................................................................................................................................................................................................................
401-710-090
1-5
Issue 3, March 2006
Prerequisites
IPBH hardware that is required as part of a Flexent/AUTOPLEX wireless network,

its functions and required changes:
Table 1-2
Network
Element
Function
Hardware change for IPBH
FMM-AP
Holds RCS-APs
(BTS controllers
in the ECPC)
No hardware changes needed.

Upgrade is required for GNP-AP to FMM-AP
for IPBH since the GNP-AP also houses RCSs.
Only RCSs on
FMM-AP are
supported
1XRNC
(optional)
Holds IP
backhaul servers
(BHS).
Upgrade existing equipment to GICC 1.1.

Grow in additional GICC 1.1 cards.
Requires GICC
1.1 cards (2) for
Ethernet
connection.
5ESS
DCS/PSU2e
Holds IP
backhaul servers
(BHS).
Requires backhaul protocol handler (BPH)

(new) upgrade for PSU2e.
BTS / Modular
cell / Modular
cell 4.0 with
URC or URC-II
Standard cell
hardware based
on your system.
BTS / Modular
cell / HD 4.0
with URC or
URC-II
Standard cell
hardware based
on your system.
BTS / Modular
cell / Modular
cell 4.0 Compact
with URC or
URC-II
Standard cell
hardware based
on your system
BTS / Modular
cell / Modular
cell 1/2/3 with
URCm card
Standard cell
hardware based
on your system
Upgrade is required for CRC to URCm for

IPBH.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-6
Table 1-2
Prerequisites

(continued)
Network
Element
Function
Hardware change for IPBH
Backhaul
transport: Edge
routers (ER)
Support DS1
transport.
User selected equipment.
Backhaul
transport:
Layer2/layer 3
switches
Provide IP
network
interconnections
between IPBH
network 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 all
FMM-AP, RCS-AP and 1XRNC software.
5ESS DCS: 5e19.1 (generic) release for R25.0 NAR
5ESS 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 setting
facilities backplane memory parameters.
Self-install version that allows all capabilities of RMT including facilities
backplane memory parameters.
RTU QFAF and number of carriers
C E L L 152 - IP Backhaul Support for Right to Use xxx, where the value xxx is the
number of IPBH carriers configured This value varies by customer and can be any
number from 0 to 10,800, or greater, depending on the user. See your Lucent
Technologies representative for details.
You will need to know the number of carriers for your configuration prior to
implementing IPBH. This value is the purchased number of IPBH carriers that can be
configured in an office. During configuration, warnings are built in to notify when
carrier capacity has reached 75% and 90% of capacity. If 100% capacity is reached no
additional configurations can occur. For planning purposes, be sure you know the
number of carriers you have purchased.
.................................................................................................................................................................................................................................
401-710-090
1-7
Issue 3, March 2006
Prerequisites
When the IP Backhaul Enabled field is set for a BTS via the cell2 form, a Backhaul
Server (BHS) has to be assigned in the cell2 form for each carrier assigned to a radio
via the cdmeqp/btseqp form for the cell. Each carrier that is assigned to a BHS on
the cell2 form is counted as a configured IPBH carrier. The number of currently
configured IPBH carriers for the office is displayed on the ECP form. The number of
currently configured IPBH carriers is not allowed to exceed the number of purchased
IPBH carriers designated in the RTU QFAF. When an attempt is made to configure
more IPBH carriers than the RTU QFAF allows, the cell2 form update is denied
Technical industry standards
Lucent IP backhaul is implemented based on several standard protocols defined by

IETF 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 3317Differentiated Services Quality of Service
Policy Information Base
The PPP Internet Protocol Control Protocol, IETF RFC1332 & 1877 (Extension for
DNS)
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-090
Issue 3, March 2006
1-8
IPBH
documentation roadmap
.................................................................................................................................................................................................................................
Related documentation
The following graphic identifies the Lucent Technologies customer documentation that
is available for the network elements that comprise the IPBH network. Note that
non-Lucent hardware documentation is available through your vendor.
Table 1-3
Task
Description
Document name
Implement IPBH
network
IPBH overview
Flexent Wireless NetworksIP Backhaul for CDMA Voice

and Packet Data, 401-710-090
IPBH planning
IPBH
implementation
.................................................................................................................................................................................................................................
401-710-090
1-9
Issue 3, March 2006
Table 1-3
(continued)
Task
Description
Document name
Convert existing
LAPD network
from frame Relay
to IPBH
Step-by-step
procedure for cell
conversion.
Flexent Wireless NetworksBTS Conversion from LAPD to

IPBH (FID 10665.16), 401-612-841
Install packet
handlers for IPBH
OA&M documents
for the 5ESS
Switch.
5ESS Switch Flexent Wireless Networks

ApplicationsOA&M Manual, NAR 235-200-100
RC Views
For International
documents, see
listing at end of
this table.
5ESS Switch Flexent Autoplex Wireless Networks

Applications Applications OA&M Manual, 5AP
5ESS Switch Flexent Wireless Networks Applications

Input/Output Messages, 235-600-700/750
Install packet
handlers for IPBH
Network planning
and engineering
guidelines
System planning
Flexent /Autoplex Wireless Networks System Capacity

Monitoring and Engineering Guidelines, 401-610-009
Add new URCs
Cell OA&M
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.0 Operations, Administration and
Maintenance, 401-710-122
RC/V description
for screens, forms
and field
parameters
Database update
Flexent /Autoplex Wireless Networks Database Update

Manual, 401-610-036
Syntax and
description of
network
commands
Alarms and
messages
Flexent /Autoplex Wireless Networks Input Messages

Manual, 401-610-055
Look up alarm
message and
determine status
and purpose of
alarm.
Alarms and
messages
Flexent /Autoplex Wireless Networks Output Messages

Manual, 401-610-057
Troubleshoot an
alarm message
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-10
Table 1-3
(continued)
Task
Description
Document name
System
performance and
service
measurement data
All Service
Measurements for
the network are
identified and
detailed.
Flexent /Autoplex Wireless Networks Service

Measurements, 401-610-135
Monitor the
network from the
ECP complex
ECP and SDP

maintenance and
control
information and
procedures.
Flexent /Autoplex Wireless Networks ECP OA&M and

SDP Maintenance Control Procedures, 401-610-160
Monitor the
network from the
OMC-RAN
Description of
OMC-RAN
OA&M for
monitoring a
network.
Flexent /Autoplex Wireless Networks Operations and

Maintenance Center Radio Access Network (OMC-RAN),
401-662-105
Maintain and
provision the
RCS-APs
FMM-RCS
OA&M
Flexent Wireless Networks Radio Cluster Server (RCS)

FMM-RCS OA&M, 401-710-102
Install/update
GICC card for
IPBH
1X RNC OA&M
Flexent Wireless Networks CDMA 1X Radio Network

Controller (RNC) Operations, Administration, &
Maintenance, 401-710-082
FMM-TI reference
for TICLI
commands
Flexent Wireless Networks FMM-TI Reference Guide,

401-710-211
Flexent Wireless NetworksCell Reliability and

Engineering Improvements for IPBH RCS APs - Delivery
of Flexible Sparing Phase 1, 401-612-830.
Establish IPBH
parameters for
data offload to the
RNC
Reference TICLI
commands
Additional 5ESS
DCS documents

OA&M Manual, 5AP5AP
Measurements Manual, 5MM
Recent Change Manual, 5RC
5ESS Switch Flexent Wireless Networks
Applicationscommands and Reports Manual, 5CR
.................................................................................................................................................................................................................................
401-710-090
1-11
Issue 3, March 2006
IPBH training course
The course CL5591: IP Backhaul for CDMA Voice and Packet Data is available
starting with Release 25.0. This course describes IP Backhaul and provides a detailed
overview of the implementation necessary to successfully convert BTSs from LAPD to
IPBH.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-12
Benefits
of IP Backhaul
.................................................................................................................................................................................................................................
IPBH definition
IP Backhaul provides current Lucent Technologies customers a means to increase the

capacity of existing systems with minimal hardware and software updates by switching
from frame relay backhaul (FR) to IP Backhaul (IPBH).
IP Backhaul is comprised of a number of individual features that work together to
create 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 BHS

to form a logical, semi-permanent path for carrying user traffic between the BTS
and 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 Carrier
Cards (GICC) in the Radio Network Controller (1X RNC).
Service option class (SOC)Identifies the bearer class for routing purposes as
voice or packet data. Note that when SOC is provisioned in a Lucent Technologies
network, the choices are Voice or Both (voice and packet data).
Backhaul Protocol Handler (BPH)A BPH board with fast Ethernet interface on a
5ESS DCS PSU2e that terminates the backhaul network interface.
Multi-link group (MLG)A Point-to-point-Protocol (PPP) over DS1 or Multi-link
PPP (ML-PPP) link between a BTS and an edge router regardless of the number of
DS1s in the MLG.
IP network addressNetwork address used solely for IP network designation. This
number is assigned by the service provider at the time the network is established.
IPBTS GWHardware and software that provide the IP Backhaul gateway
functionality.
IP Backhaul from Lucent Technologies
IPBH utilizes multi-link/multi-class PPP (ML/MC-PPP) to group multiple DS1s into a

single large pipe called a multi-link group (MLG) for backhaul transport. Each MLG
consists of one or more DS1 facilities per URC, configurable by the customer.
.................................................................................................................................................................................................................................
401-710-090
1-13
Issue 3, March 2006
With IPBH, both signaling and user traffic are multiplexed over IP over unchannelized
DS1s.
Traffic from the BTS terminates on an edge router.

The backhaul routers send the signaling traffic to the radio cluster server
application processor (RCS-AP).
The bearer traffic is delivered directly to a Backhaul Server (BHS), located in the
PSU2e or 1X RNC, over Ethernet links.
Frame relay versus backhaul
Current Lucent Technologies backhaul networks utilize frame relay packet pipes. Table
1-4, Differences between FR and IPBH (p. 1-14) lists the major differences between
frame relay (FR) and IP Backhaul.
Table 1-4
Differences between FR and IPBH
Frame Relay Packet Pipe
IP Backhaul
Trunk Group/ Member End-to-end

NxDS0 between URC and PSU2e.
Virtual connections based on provisioned BTS

BTS/Carrier/SOC-BHS assignments
FR over fractional DS1 at BTS

interface.
IP over unchannelized DS1 at BTS interface

Utilization of DS1 capacity is part of IP network
FR requires provisioning of the

DS1 channels.
Fractional-DS1 through TSI to
FRPH: up to 240 voice call legs
per 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 routed

through 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 international

markets, however data can be off-loaded to a specific Backhaul Server (BHS).
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-14
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 voice
calls per SM
Improves T1 utilization through the use of unchannelized DS1s and a more
efficient 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 of
backhaul 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 frame
relay protocol handlers (FRPHs) that are used for frame relay backhaul are not
needed 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 and
routed 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 DCS
nailup.
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-090
1-15
Issue 3, March 2006
The figure below shows the current CDMA network:

Figure 1-1 Current backhaul network
For Code Division Multiple Access (CDMA) systems, the BTS backhaul network
currently consists of DS1 facilities connecting each BTS to a DS1 transport network
that 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 on
FRPHs. Control traffic is carried on dedicated DS0s that terminate on BTS controllers
(RCS-APs in the ECPC) over DS1 interfaces.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-16
IP Backhaul network configurations
Figure 1-2, Typical IP Backhaul network with 5ESS DCS/PSU2e (p. 1-17) shows a
typical configuration for a IP Backhaul network:
Figure 1-2 Typical IP Backhaul network with 5ESS DCS/PSU2e
The typical IP backhaul network with a 5ESS DCS provides the following:
Control signaling delivered to the Flexent Mobility Manager (FMM) local area
network (LAN) directly from the backhaul router, (No DS0 grooming is required.)
Traffic is delivered directly to the backhaul server (BHS) freeing up resources
previously 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.
.................................................................................................................................................................................................................................
401-710-090
1-17
Issue 3, March 2006
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:
Figure 1-3 Typical IP Backhaul network with 5ESS DCS/PSU2e and 1X RNC
The typical IP backhaul network with the 5ESS DCS PSU2e and RNC provides the
following:
Control signaling delivered to the Flexent Mobility Manager (FMM) local area
network (LAN) directly from the backhaul router. (No DS0 grooming is required.)
Traffic is delivered directly to the backhaul server (BHS) on the 5ESS without
using 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.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-18
IPBH
network architecture
.................................................................................................................................................................................................................................
Attributes
Figure 1-4 IPBHNetwork
The primary attributes of the IPBH architecture are:
All traffic and signaling between Base Transceiver Stations (BTS) and the Mobile
Switching 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 can
be optimally utilized. Bandwidth is added to a BTS in DS1 increments as needed to
support capacity growth regardless of carrier configuration and carrier load. DS1
capacity using the UDPMux protocol is approximately 145 3G1X voice call legs
per DS1.
Traffic and signaling are mixed over the DS1s and separated at the IP switching
layer.
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 fractional
DS1 time division multiplex (TDM) channels.
.................................................................................................................................................................................................................................
401-710-090
1-19
Issue 3, March 2006
Provisioned data determines which packet switching unit (PSU) will serve the
traffic from a given BTS. Carrier geographic clustering is supported for voice or
combined voice and data traffic carried by the 5ESS DCS.
BTSs can be provisioned such that voice is served on a PSU (or PSUs) while
packet data is served on an RNC (or RNCs). This enables packet data to be truly
off-loaded from PSUs and the inter-PSU soft handoff network. Carrier geographic
clustering is not supported for data offload traffic on the RNC.
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).
IP backhaul is supported on Radio Cluster Servers (RCS-AP) hosted on FMM-APs
and 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 the
same cell.
Soft handoff universe can support a mix of IP and FR BTSs. IPBH has no affect on
ATM SHO network (intra- or inter-MSC).
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-20
Figure 1-5, IPBH architecture (p. 1-21) identifies all of the elements in the IPBH
network architecture.
Figure 1-5 IPBH 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 is
connected to a different edge router over NxDS1
.................................................................................................................................................................................................................................
401-710-090
1-21
Issue 3, March 2006
Abbr.
Meaning
MLG
Multi-link Group
An aggregated grouping of multiple DS1s for transmission
between two points.
URC #
Universal Radio Controller
UDP
User Datagram Protocol
UPDmux
User Datagram Protocol Multiplexing
ML-PPP
Multi-Link Point-to-Point Protocol
NxDS1
Number x 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 and
RNCs 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 with
RNCs
BHS
Backhaul Server
1X RNCs
Radio Network Controllers

connected to switches for data offload BHS and SHO with
PSUs
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 are
multiplexed onto common DS1s and the IP layer is used to route packets to and from
the desired MSC destinations.
The DS1s are terminated at the BTS on a universal radio controller (URC) board. All
the URCs within a BTS are interconnected to enable traffic on any carrier to be
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-22
transported over any DS1. This enables optimal DS1 utilization. No IP router is
required at the BTS site.
On the network side, the DS1s terminate on a standard IP edge router. IP edge routers
support 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 a
multi-link group (MLG). The layer 2 protocol between the BTS and the edge router is
PPP [1] over DS1 or Multi-Link PPP [2] over NxDS1. ML-PPP enables multiple DS1s
on the same URC (that terminate on the same router) to be grouped together into a
Multi-Link Group (MLG). Each PPP/DS1 link or ML- PPP/NxDS1 link requires a
unique IP address. Using MLGs (rather than individual DS1s) minimizes the number of
separate interfaces that have to be managed by the application, and minimizes the
number of IP addresses that a BTS requires. MLGs also aggregate bandwidth which
increases aggregate DS1 efficiency.
Throughout this document, the term MLG is used to refer to a PPP or ML-PPP link
between 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 on
a different ER.
Backhaul routers
The edge routers perform IP routing (layer 3); the L2 switches perform Ethernet
switching (layer 2).
Edge routers
The edge routers provide the OC3 terminations toward the BTSs and wide-band
uplinks toward the MSC.
Multi-layer switches
The MLSs are optimized to provide economical Ethernet connections to the individual
control 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 is
also possible to remote edge routers in cases where there is an economic advantage to
terminate the DS1s closer to some group of BTSs and carry their aggregated traffic to
the MSC over some type of wide-band facilities. These wide-band facilities are
expected to be either unswitched (layer 2 pipes) or tunneled (layer 2 or 3) with
guaranteed bandwidth. In any case their bandwidth must be engineered to meet the
very strict delay and jitter requirements of CDMA backhaul.
.................................................................................................................................................................................................................................
401-710-090
1-23
Issue 3, March 2006
RCS network interface
Packets between IP BTSs and RCS-APs are carried over Ethernet links between the
MLSs and the FMM-AP Ethernet LAN. There are links between the MLs and each
growth frame with RCS-APs. RCS-APs communicate with BTSs over the same two
Ethernet 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 PSU
Protocol Handler boards that are known as Backhaul PHs, or BPHs. Each BPH has 1
Ethernet link.
BPHs are deployed in serving or non-serving (active/standby) pairs (1+1) for improved
reliability. A serving (active) BPH can take over from the non-serving (standby) BPH
without loss of stable calls. When a non-serving BPH takes over, it assumes the IP
address of the serving BPH so this switchover is transparent to the other network
elements (ECPC and BTSs).
A fault tolerant configuration has the serving and non-serving BPHs of a pair
connected 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-serving
pair of BPHs is known to other network elements as a single logical entity called a
Backhaul Server or BHS. The details of BPH sparing are not visible to other network
elements since the switchover between BPHs in a pair is transparent. A PSU that
terminates IP backhaul traffic is expected to require no more than 3 to 4 BHSs. Each
BHS in a PSU can serve approximately 2000 call legs. IP backhaul is supported only
on 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 RNC
Gateway Intelligent Carrier Cards (GICCs). Each GICC that supports IP backhaul has
1 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 serving
GICC without loss of stable calls. When a non-serving GICC takes over, it assumes the
IP address of the serving GICC so the L2 switch over is transparent to the other
network elements (ECPC and BTSs). See System Capacity Monitoring and Engineering
Guidelines, 401-610-009 for current capacity information for the RNC.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-24
IPBH
traffic
.................................................................................................................................................................................................................................
Purpose
The flow of data through the IP Backhaul network depends on the configuration of the
network. This section introduces the traffic protocol layers and describes the flow of
traffic in the IPBH network.
User traffic protocol
User traffic is carried on application layer connections over IP between URCs and
BHSs (in PSUs and RNCs).
There are several important considerations in the selection of the user traffic protocol
layers:
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-MSC
soft-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 IP
backhaul BTSs. FR backhaul uses the frame relay DLCI to route traffic frames from
the frame relay PH (FRPH) that terminates the packet pipe to any FS4 in the
soft-handoff network.
Compatibility with FR backhaul cells
The most straightforward way to accomplish IP transport while maintaining

compatibility with FR backhaul is to continue to use DLCI for routing traffic frames
within 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 much
like FRPHs. Toward the BTSs, BHSs have additional protocol processing for IP
transport 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 is
called UDPMux because of the bundling (also called multiplexing) of traffic frames
into UDP datagrams. UDPMux is a proprietary application layer that is transported
over standard UDP/IP. As mentioned above, to preserve compatibility with TDM
backhaul, each traffic frame continues to be routed within the soft-handoff network
based on DLCI.
.................................................................................................................................................................................................................................
401-710-090
1-25
Issue 3, March 2006
IPBH traffic
For IP backhaul, as a further DS1 efficiency improvement, the DLCI of each traffic
frame is replaced over the backhaul with a 1 byte value called a CID (Call ID). The
CID is allocated during call leg setup. The BHS performs the mapping between the 1
byte CID used between the BHS and BTS and the DLCI used between the BHS and
FS (within the soft-handoff network). So 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 and length field. For uplink traffic the BTS
creates UDPMux bundles from nearly simultaneous traffic frames that are to be sent
over a particular MLG to a particular BHS. The receiving BHS parses out the
individual traffic frames, restores the full DLCI for each frame (based on the CID) and
routes each frame to the destination FS based on the DLCI (just like an FRPH). For
downlink traffic a BHS creates UDPMux bundles from nearly simultaneous traffic
frames destined to the same BTS and MLG. For each traffic frame it inserts the CID
based on address information from the FS. The receiving BTS parses out the individual
traffic frames and routes each frame to the destination channel element based on the
CID. The expected DS1 capacity using the UDPMux protocol is 145 3G1X voice call
legs per T1.
In a network, latency, a synonym for delay, is an expression of how much time it takes
for a packet of data to get from one designated point to another. In some instances
latency is measured by sending a packet that is returned to the sender and the
round-trip time is considered the latency. Simulations indicate that around 320 bytes
per UDPMux data gram (around 15 traffic frames on average) is ideal for optimizing
DS1 efficiency while minimizing latency (delay) and jitter.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
1-26
I P Backhaul network overview

2
Overview
.................................................................................................................................................................................................................................
Purpose
This chapter describes the interfaces and interactions within the IP Backhaul network.
Contents
Reference Diagram
2-2
2-4
2-6
2-10
5ESS DCS
2-12
2-15
2-20
2-22
DS1s in IPBH
2-24
Backhaul server assignment and PSU2e/1X RNC engineering
2-25
IP Addressing
2-27
.................................................................................................................................................................................................................................
401-710-090
2-1
Issue 3, March 2006
Reference
Diagram
.................................................................................................................................................................................................................................
Network architecture
Figure 2-1, IP Backhaul network reference diagram (p. 2-2) is referenced throughout
this chapter.
Figure 2-1 IP Backhaul network reference diagram
Legend:
Abbr.
Meaning
BTS 1
Base Transceiver Station 1

has one URC with one MLG over NxDS1
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-2
Reference Diagram
Abbr.
Meaning
BTS n
Base Transceiver Station #

has 2 URCs, each of which has 1 MLG; each MLG is
connected to a different edge router over NxDS1
MLG
Multi-link Group
An aggregated grouping of multiple DS1s for transmission
between two points.
URC #
UDP
UPDmux
ML-PPP
Multi-Link Point-to-Point Protocol
NxDS1
Number x 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 and
RNCs 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 with
RNCs
BHS
Backhaul Server
1X RNCs
Radio Network Controllers

connected to MLSs for data offload BHS and SHO with
PSUs
.................................................................................................................................................................................................................................
401-710-090
2-3
Issue 3, March 2006
Base
transceiver station
.................................................................................................................................................................................................................................
Purpose
The BTS manages signals to and from users and call control manager functions in the
MSC.
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 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 Radio
Controllers (URCs) within communication facilities in a cell must be configured for
either FR or IPBH.
Modular cell 1.0-3.0 supports the configuration of 1 URCm with no T1/E1
facilities. For URCms with no facilities, all signaling and traffic are routed through
facilities 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 edge
router.
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 and
signaling are multiplexed onto common DS1s and the IP layer is used to route packets
to and from the desired MSC destinations.
Modular cells
The DS1s are terminated at the BTS on a URC board. IP Backhaul is supported on all
Modular cells equipped with URCs. Each CRC in a Modular cell 1/2/3 must be
upgraded to a URCm prior to conversion of the BTS to IP Backhaul. All the URCs
within a BTS frame are interconnected to enable traffic on any carrier to be transported
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-4
over any DS1. This enables optimal DS1 utilization. This is an integrated IP solution at
the BTS. There is no IP router required at the BTS site.
Refer to Flexent CDMA Modular Cell 4.0 and Compact Modular Cell 4.0 Operations,
Administration and Maintenance, 401-703-407 and Flexent / CDMA Modular Cell
1.0, 2.0, 3.0 and Compact Modular Cell 3.0 Operations, Administration and
Maintenance, 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 cell
cannot have a mix of FR and IPBH facilities in service, except as a transient condition
during conversion of a cell.
Important! Note that this statement excludes EVDO. A BTS can be configured to
simultaneously support EVDO and 3G1X. A configuration for the EVDO URC can
be 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 design
of the physical transport of the DS1s is a service provider option. IP edge routers
support 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 DS1
facilities fail
Support a URC that has no DS1 equipped to share another URCs MLG in the
same assemblage (Modular cell 1, 2 and 3)
The layer 2 protocol between the BTS and the edge router is PPP over DS1 or
ML-PPP over NxDS1. ML-PPP enables multiple DS1s on the same URC (that
terminate 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 to
be managed by the application. MLGs also aggregate bandwidth which increases
aggregate DS1 efficiency.
For greater path diversity, a BTSs MLGs may be spread across a pair of edge routers
as shown in Reference Diagram (p. 2-2). Each MLG may have one or several DS1s
(within the URC capacity limit).
.................................................................................................................................................................................................................................
401-710-090
2-5
Issue 3, March 2006
Backhaul
routers and switches
.................................................................................................................................................................................................................................
Purpose
This section describes the IPBH transport network.

As part of network architecture, IP Backhaul will use standard IP routers terminating
T1/E1 facilities and Ethernet switches interconnecting to 100 BaseT or GigE Ethernet
facilities.
The following documents provide further information about implementing and
engineering backhaul routers:
Table 2-1
Router and switch documentation resources
Document
Description
VRAD-5576
This document describes the design of IP Backhaul

with an emphasis on the requirements on the IP
switches and routers
Ask your Lucent Technologies representative for this
information.
System Capacity Monitoring

and Engineering Guidelines
(401-610-009)
This document (available for Release 25.0) provides

information needed to monitor and engineer network
performance 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 sites
and the Mobile Switching Center (MSC). Its purpose is to transport traffic between the
cells and the MSC components. Figure 2-2, IPBH network topology (p. 2-7)
illustrates the general network topology in a duplex configuration. The Automatic
Protection Switching (APS) mechanism of Synchronous Optical Network (SONET) is
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-6
used to provide redundancy for router failure and OC3 link failure (Active OC3 and
Protect OC3).
Figure 2-2 IPBH network topology
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 is
also possible to have remote edge routers.
.................................................................................................................................................................................................................................
401-710-090
2-7
Issue 3, March 2006
Remote routers are used in cases where there is an economic advantage to terminate
the DS1s closer to some group of BTSs and carry their aggregated traffic to the MSC
over some type of wideband facilities. These wideband facilities are expected to be
either unswitched (layer 2 pipes) or tunneled (Layer 2 or Layer 3) with guaranteed
bandwidth. In any case their bandwidth must be engineered to meet the very strict
delay and jitter requirements of CDMA backhaul.
Adjacent switches
The MSC adjacent switch becomes part of a private IP network interconnecting AP

frames, the OMP, edge routers and backhaul servers (BHS). No other network elements
or 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 MSC
is the expected network design choice because edge routers do not typically provide
economical, high-density 100 Mbps Ethernet connections as required here to connect to
the control and traffic servers in the MSC. These MSC adjacent switches may be
multi-layer (L2/L3) switches or L2 only switches.
In order to support troubleshooting and problem resolution, Lucent Technologies
recommends the switches be configured to enable history logging. If the switch in your
network does not store this information on the switch, a separate server will be needed
to store the data. Lucent Technologies recommends storage of this data on a
customer-controlled network server using the same practices used for other network
data (for example, SNMP data). See your vendor documentation for specific
information 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 to
achieve high quality voice over DS1, that are standardized but are not widely
supported on edge routers.
IP router requirements
The IP router must support the following standard protocols to be compatible with
Lucent Technologies IP Backhaul:
PPP and MC/ML-PPP protocols

DiffServ QoS
IPCP IP router should also perform the IP address assignment through IPCP
protocol to assign dynamic IP address to the BTS when it is initialized
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-8
The Ethernet switch should support the IEEE 802.1D/Q function to be compatible
with 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 DS1
from service when the threshold is exceeded for a configurable interval.
.................................................................................................................................................................................................................................
401-710-090
2-9
Issue 3, March 2006
Radio
cluster server
.................................................................................................................................................................................................................................
Purpose
The radio cluster server (RCS) is an application on an RCS-AP that performs the call
processing and OA&M functions for the cells.
HW/SW requirements
RCS-AP requirements for an IPBH network:

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-AP
can run a mix of RCS-Link Access Protocol on the D channel (LAPD) instances (to
support 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 in
each FMM growth frame with RCS-APs. Based on RCS-AP capacity, a frame that is
fully equipped with RCS-APs does not require more than one 100 Mbps Ethernet link
to 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-APs
communicate with BTSs over the same two Ethernet interfaces that they use for
internal AP-to-AP communications.
FMM-AP
IP Backhaul is supported only on the FMM-AP platform, and is supported on all

FMM-AP types including satellites.
No additional hardware in the FMM complex is required for IP Backhaul.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-10
RCS in IPBH network
Figure 2-3, RCS signaling conversion: simplified view (p. 2-11) shows a simplified
view of the RCS signaling conversion in the IPBH network.
Figure 2-3 RCS signaling conversion: simplified view
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, the
following types of activities can occur for the RCS:
Provisioning activity associated with converting LAPD-based RCSs to IP-based

RCSs (note that this may be done as part of an automated conversion process)
Provisioning activity associated with growing or degrowing IP-based RCS
See Chapter 3, Implementation for IPBH for RCS-IP provisioning information.
.................................................................................................................................................................................................................................
401-710-090
2-11
Issue 3, March 2006
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
Figure 2-4 5ESS Switch packet handlers in PSU2e
Legend:
UDPMux traffic between the serving IP address on the

serving BPH and the MLGs
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-12
5ESS DCS
Traffic frames between frame selector in PHV/DPH

and BPH (transmitted to both BPHs)
Periodic ARP between each BPH and the 1st hop
router
Serving BPH update of dynamic data in non-serving
BPH
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 a
serving 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 BPH
to the non-serving BPH
Both the BPHs do periodic address resolution protocol (ARP) requests to the 1st
hop router to verify connectivity to the router.
The call leg dynamic data is continuously kept the same on both serving and
non-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 a
BPH. This association is identified by the BTS IP address, the BHS IP address, and the
UDP ports. See 5ESS DCS OA&M (p. 4-11) information about commands to view
all BHA information.
Backhaul protocol handlers (BPH)
User traffic is carried over direct 100 Mbps Ethernet links between the MSC adjacent
switches and PSU2e Protocol Handler (PH) boards that are known as Backhaul PHs, or
BPHs. 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 stable
calls.
BPH failover occurs due to Ethernet failure, loss of connectivity to 1st hop router
or unrecoverable hardware or software faults.
When a non-serving BPH takes over, it assumes the IP address of the serving BPH
so this switchover is transparent to the other network elements, the Executive
Cellular Processor Cluster (ECPC) and BTSs.
.................................................................................................................................................................................................................................
401-710-090
2-13
Issue 3, March 2006
5ESS DCS
A fault tolerant configuration has the serving and non-serving BPHs of a pair
connected to different adjacent switches as shown in Figure 2-4, 5ESS Switch packet
handlers in PSU2e (p. 2-12). This implies that the traffic subnets span the adjacent
switches (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 a

single logical entity called a Backhaul Server (BHS). The details of BPH sparing do
not need to be visible to other network elements since the switchover is transparent
between BPHs in a pair.
A PSU2e that terminates a fully loaded IP Backhaul configuration is expected to
require no more than 3 to 4 BHSs.
Each BHS in a PSU2e can serve approximately 2000 call legs. IP Backhaul is
supported only on PSU2e (PF3, CF3), which requires the Core700 SMP in the host
switching module.
Note that data offload that is optionally available to the RNC is not available in
international markets, however data can be offloaded to a specific BHS.
Capacity
IP Backhaul provides a significant improvement in DCS capacity (as compared to FR

backhaul):
No TSI timeslots or trunk peripheral resources are requiredTSI timeslots are

freed up for additional PSTN and speech handler trunks (PHVs), the BHCA
capacity of an SM increases by up to 40% (depending on system configuration and
call 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 going
through the DCS, allowing the PSUs to handle more voice calls.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-14
Radio
network controller (1X RNC)
.................................................................................................................................................................................................................................
Purpose
The 1X radio network controller ( 1X RNC also referred to as RNC) hosts a backhaul
server (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 hardware
and 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 IPBTS
GW 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 the
BTS 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 IPBTS
GW to the standby IPBTS GW.
.................................................................................................................................................................................................................................
401-710-090
2-15
Issue 3, March 2006
Both IPBTS GWs send periodic address resolution protocol (ARP) requests to the
first hop router to verify connectivity to the router
The call leg dynamic data is synchronized between the GICCs to facilitate
switchover and failover without losing stable call legs.
Figure 2-5 IPBTS GW Sparing
Legend:
UDPMux traffic between the BHS IP on the active IPBTS GW

and the MLGs
Traffic frames between the IPBTS GW and frame selectors in
CICCs.
Traffic frames between frame selectors in CICCs and the
IPBTS GW.
Periodic ARPs are sent from the fixed IPBTS GW IP addresses
on each BPH and the 1st hop router.
Active IPBTS GW updates of dynamic data in the standby
IPBTS GW
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-16
1X RNC shelf configuration
Figure 2-6, 1X RNC shelf configuration for IP Backhaul (p. 2-18) shows the
configuration of the TPU shelf in the IP Backhaul RNC. The GICCs in slot 19 in the
upper 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 can
be 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 GW
only -- they cannot support both simultaneously
GICCs are equipped in pairs, both GWs in a pair can only support one gateway
type
.................................................................................................................................................................................................................................
401-710-090
2-17
Issue 3, March 2006
IPBTS GWs are supported only on GICC 1.1 with a limit of one IPBTS GW
per GICC
ATM 5ESS DCS GWs are supported on GICC 1.0 and GICC 1.1 with a limit
of two 5ESS DCS GWs per GICC
Figure 2-6 1X RNC shelf configuration for IP Backhaul
GICC
User traffic is carried over Gigabit Ethernet links between the MSC adjacent switches
and RNC gateway intelligent carrier cards (GICCs). Each GICC that supports backhaul
has 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 elements
as a single logical BHS.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-18
Figure 2-7, 1X RNC BHS processes (p. 2-19) shows the BHS server functionality
within the 1X RNC.
Figure 2-7 1X RNC BHS processes
The BHS represents a pair of IPBTS GWs and hides the internal 1X RNC IP Backhaul
architecture from the BTS and ECPC. The BTS and ECPC communicate only with the
BHS, and are not affected by switching between the IPBTS GWs. The RNC forwards
BHS 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 status
of the newly active IPBTS GW. The active IPBTS GW uses the BHS service IP
address 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) for
improved reliability. A non-serving GICC can take over from the serving GICC without
loss of stable calls. When a non-serving GICC takes over, it assumes the IP address of
the serving GICC so this switchover is transparent to the other network elements
(ECPC and BTSs). A fault tolerant configuration has the serving and non-serving
GICCs of a pair connected to different adjacent switches as shown in Figure 2-1, IP
Backhaul network reference diagram (p. 2-2).
.................................................................................................................................................................................................................................
401-710-090
2-19
Issue 3, March 2006
User
traffic protocols
.................................................................................................................................................................................................................................
Purpose
User(bearer) traffic is carried on application layer connections over IP between URCs

and BHSs in PSUs and 1X RNCs.
Protocol stacks
Figure 2-8, Bearer traffic protocol stacks (p. 2-20) shows the protocol scheme used
for bearer traffic in IPBH.
Figure 2-8 Bearer traffic protocol stacks
Bearer traffic protocols

Table 2-2
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 later
de-multiplexed
Transport layer protocol
Lucent proprietary
CEFS L3 (Layer 3)
Channel Element (BTS) <-> Frame Selector (5ESS DCS/RNC) L3

communication
Sets up voice/data call for a particular CID at L3
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-20
Table 2-2
Name
Function
T1/E1
Physical layer protocol
UDP
IP
Network layer protocol
ML-PPP
Data-link layer protocol
(continued)
.................................................................................................................................................................................................................................
401-710-090
2-21
Issue 3, March 2006
Signaling
traffic protocols
.................................................................................................................................................................................................................................
Purpose
Signaling traffic is carried on application layer connections over IP between URCs and
RCS-APs.
Protocol stacks
Figure 2-9, Signaling traffic protocol stacks (p. 2-22) shows the protocol scheme
used for control traffic in IPBH.
Figure 2-9 Signaling traffic protocol stacks

Table 2-3
Name
Function
CCMS
Signaling Traffic
Cell Communication Manager
Runs from RCS-AP to URC
Protocols for message headers, message bodies, and extended message
headers
Lucent proprietary
TCP
TCP Intermediate Layer
Includes heartbeat mechanism

Simple BTS Startup Protocol transactions done out of band (but, not true
UNIX out of band)
Lucent proprietary
IP
Network layer protocol
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-22
Table 2-3
Name
Function
ML-PPP
Data-link layer protocol
T1/E1
Physical layer protocol
(continued)
.................................................................................................................................................................................................................................
401-710-090
2-23
Issue 3, March 2006
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 many
frames. Of course, only traffic frames that are nearly simultaneous can be bundled
together.
The chosen protocol is called UDPMux because of the bundling (also called
multiplexing) of traffic frames into UDP datagrams. UDPMux is a proprietary
application layer that is transported over standard UDP/IP.
To preserve compatibility with FR backhaul, each traffic frame continues to be routed
within the soft-handoff network based on DLCI. For IP Backhaul, as a further DS1
efficiency improvement, the DLCI of each traffic frame is replaced over the backhaul
with a one byte value called a call identifier (CID). The CID is allocated during call
leg setup. The BHS performs the mapping between the one byte CID, which is used
between the BHS and BTS, and the data link connection identifier (DLCI), which is
used 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 and
length field:
For uplink traffic, the BTS creates UDPMux bundles from nearly simultaneous
traffic frames that are sent over a particular MLG to a particular BHS. The
receiving BHS parses out the individual traffic frames, restores the full DLCI for
each frame (based on the CID) and routes each frame to the destination FS based
on the DLCI (just like an FRPH).
For downlink traffic a BHS creates UDPMux bundles from nearly simultaneous
traffic frames destined to the same BTS and MLG. For each traffic frame, the BHS
inserts the CID based on address information from the frame selector. The
receiving BTS parses out the individual traffic frames and routes each frame to the
destination channel element based on the CID.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-24
Backhaul
server assignment and PSU2e/1X RNC engineering
.................................................................................................................................................................................................................................
Purpose
This section describes how the user traffic of a BTS is assigned to particular PSUs and
1X RNCs. To simplify switch engineering and thus minimize the amount of
provisioning required, data is provisioned at the MSC for each BTS that determines the
PSU2e(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 to

serve 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 BTSs
to be served on a particular PSU2e. Carrier geographic clustering minimizes
inter-PSU2e soft-handoff traffic by keeping most soft-handoff traffic within a
geographic 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 be
routed to a PSU2e while packet data traffic from the same BTS is routed directly to an
RNC.
Since the RNC is large compared to a packet switch (PS), carrier geographic clustering
is not required for packet data traffic served on an RNC. When data traffic is served on
an 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 for
each BTS. The alternate RNC BHS is used only in the event of a failure of the
primary RNC BHS.
The data provisioned on the cell2 form for each BTS determines the PSU(s) and/or
RNC(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 traffic
of 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 the
packet data traffic of the BTS for all carriers.
For each BTS, a primary and alternate RNC BHS may be specified to serve the
packet 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, or
it may be a BHS on a different RNC than the primary.
.................................................................................................................................................................................................................................
401-710-090
2-25
Issue 3, March 2006
Backhaul server assignment and PSU2e/1X RNC

engineering
If no RNC or DCS BHS is specified for the data traffic, then the data traffic defaults
to the same PSU BHSs that are specified for the voice traffic. The alternate DCS or
RNC BHS is used for data traffic when the primary BHS is marked unavailable. The
alternate BHS is not used to relieve overload conditions on the primary BHS.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-26
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 binary
number usually displayed as four octets in decimal, separated by periods.
The Internet is a collection of networks whose users communicate with each other via
addressing 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 the
host number).
An organization can use some of the bits in the machine or host part of the address
to 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 portion
of an IP address is split into a subnet portion and a host portion using an address
mask (the subnet mask).
IP address requirements
The addresses used for IPBH are private IP addresses and will be used only between
the BTS and router, and the router and MSC. Therefore, the address ranges can be
duplicated on different MSCs in an IPBH network. Reserving a large chunk of
addresses will not affect an existing network if there are not conflicts within the
reserved addresses.
Private IP addresses used include:
Table 2-4
Network element
Max. # elements
Max. # nodes per

element
Total size
Subnet and mask

reserved subnet
BTS
12 URCs per BTS
600 BTSs
1 MLG per URC
Static : 2 IP
addresses per MLG
/30 for 2 host

addresses
RCS-AP
22 RCS-APs per
frame
2 IP addresses per
AP
/21 for 2048 host

addresses
28 Frames
.................................................................................................................................................................................................................................
401-710-090
2-27
Issue 3, March 2006
Table 2-4
IP Addressing
(continued)
Network element
Max. # elements
Max. # nodes per

element
Total size
Subnet and mask

reserved subnet
5ESS DCS
10 BHS/PSU
2+1 VIP per BHS
/26 for 30 host

addresses
3 GICC pairs per

RNC
2 + 1 VIP per
GICC pair
/28 for 9 host

addresses
64 SMs per DCS

1X RNC
15 RNCs
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 address
automatically during the network protocol negotiation phase of PPP link
initialization. The PPP Network Control Protocol (NCP) that enables dynamic
IP 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 provisioned
at the router for all the MLGs that the router terminates.
BHS IP addresses are manually provisioned through the 5ESS DCS and 1X RNC
OA&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 per
AP).
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 associated
address server. This can be a fixed assignment, or a pool of addresses can be
reserved for dynamic assignment. Fixed assignments are recommended for
redundant 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 router
serves 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 with
multiple URCs should be served by multiple edge routers. The static routes in the
DCS and RNC need to be configured to include these subnets.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
2-28
IP Addressing
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 fault
tolerance.
RCS-AP IP addresses
The backhaul IP address of an RCS-AP interface is static and supports fault tolerant
networking.
No direct provisioning is done for the RCS-AP:
Each RCS-AP requires two IP addresses for backhaul, one for each of its Ethernet
interfaces:
One network prefix per MSC is provisioned for the control subnets: 2 control
subnets, 2 adjacent blocks with 1024 host IDs each.
The provisioned network ID and the APs logical number determine the two
addresses 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 each
frame.
Only RCS-APs have addresses on the IPBH network.
.................................................................................................................................................................................................................................
401-710-090
2-29
Issue 3, March 2006
IP Addressing
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 different
MSC adjacent switches for fault tolerance.
A service address (virtual address) is also provisioned. The service address is
owned 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 address
seen by the ECP/BTSs floats between the GICCs; it is automatically assigned to
the serving GICC.
Each GICC in the pair is assigned one external physical IP address used for
monitoring the Ethernet link.
Internal addresses:
Note that the BHS service address and the GICC external physical IP addresses
must not overlap with the RNC internal address space:
The internal IP pool starting address and internal IP subnet mask can be viewed
on 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-090
Issue 3, March 2006
2-30
I P Backhaul implementation
3
Overview
.................................................................................................................................................................................................................................
Purpose
This chapter describes activities and processes needed to implement IP Backhaul.

Contents
3-3
3-3
3-6
3-9
3-13
3-14
3-17
3-18
3-20
Pre-conversion: Prepare FMM-AP and RCS for IPBH
3-32
3-33
Provision ecp form
3-34
3-37
3-38
3-41
3-44
3-49
3-50
.................................................................................................................................................................................................................................
401-710-090
3-1
Issue 3, March 2006
Overview
Post deployment
3-51
Post deployment activities
3-51
Delete DS1/DS0s used with FR-based FMM-RCS
3-52
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-2

Implementation
of IPBH
.................................................................................................................................................................................................................................
Purpose
This section describes IPBH implementation in an existing Lucent Technologies

CDMA network.
This document assumes that the RMT capability at the MSC feature is enabled. When
the 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 at
the MSC feature is enabled:
Table 3-1
Phase
Activity
Pre-conversion
Activities that are done without impact on

stable/transient calls:
installation of IP network (routers and

switches).
update of database parameters.
installation of new hardware to support Release

25 or later software.
update to Release 25 or later software through

retrofit activities.
retrieval of backplane serial numbers (BPSN)

that are unique in the cell site for IPBH
provisioning.
See the Flexent Wireless Networks BTS

conversion from LAPD to IPBH, 401-612-841 for
more information.
.................................................................................................................................................................................................................................
401-710-090
3-3
Issue 3, March 2006
Table 3-1
(continued)
Phase
Activity
Conversion
These activities are described in the

Flexent /Autoplex Wireless Networks BTS
conversion from LAPD to IPBH, 401-612-841.
These stages support the conversion of the BTS
from FR to IPBH:
Post deployment
Access to the BTS
When IP connectivity is available through FR

or adjacent switches or edge routers in an IPBH
network, a cell site visit is not required
Configures BTS for IPBH mode
Fallback allows the user to reverse the

conversion, and return the BTS to the
pre-conversion state of frame relay.
Commits network for conversion of final URC

from FR to IPBH.
Identifies process to reclaim FR resources and

clean 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 to
both the MSC (ECPC, 5ESS DCS and RNC) and the BTS. Most changes to the IP
network, MSC and BTS can be executed before the final cutover, minimizing service
outage time.
Important! During conversion a URC will go out of service (OOS) for a time as
the RCS is restored.
During implementation, the following network elements are grown in, modified or
reconfigured:
Table 3-2
Network Element
Activity
Purpose
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-4
Table 3-2
IP network
ECPC
(continued)
Grow in Edge routers and

adjacent switches for IP
Backhaul network.
Allows IP connectivity between

BTS and MSC.
Update parameters.
Activates feature and updates

hardware configuration.
The IP Backhaul transport

network is established to allow IP
connectivity between BTS and
MSC by adding edge routers and
switches.
Provisioning and configuration

parameter updates are applied for
IP Backhaul.
1X RNC
Grow in, if needed, new

GICC and configure.
Provides equipment for data

offload to the RNC BHS.
The RNC is installed and
configured with hardware and
software to include the backhaul
server (BHS) for backhaul
offload.
5ESS DCS
Grow in and configure PSU.
Provides BHS for voice and data

in the packet switching unit
(PSU).
The 5ESS DCS is installed and
configured with hardware and
software to include the PSU and
BHS.
BTS
Software upgrade and

reconfiguration of URCs.
Converts URCs from FR to IPBH.
.................................................................................................................................................................................................................................
401-710-090
3-5
Issue 3, March 2006
Pre-conversion:
Install IP network
.................................................................................................................................................................................................................................
Purpose
Planning and installation of an IP network is determined by each customer to meet

network requirements. The IP network transports traffic between the cells and the
MSC. The components of the network. Installation of the IP network is available as a
service from Lucent Worldwide Services. Contact your Lucent Technologies
representative for further information.
Install IP routers and switches
The network transport portion of the IPBH architecture resides between the cell sites
and the Mobile Switching Center (MSC). Its purpose is to transport traffic between the
cells and the MSC components. illustrates the general network topology in a duplex
configuration. The Automatic Protection Switching (APS) mechanism of Synchronous
Optical Network (SONET) is used to provide redundancy for router failure and OC3
link failure (Active OC3 and Protect OC3).
Figure 3-1 IPBH network topology
Configure routers and switches, then verify connectivity for the following interfaces:
between
between
between
between
between
edge routers and adjacent switches

routers and RCS-APs
routers and BHSs
adjacent switches and BHSs on PSU
adjacent switches and BHSs on the RNC, if doing data offload
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-6
The following processes are done at the IP routers and switches for installation and
configuration:
1. Cell IP addressingdone locally on the edge router or on an external address
server (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 to y on the cell2 form.
History logging
In order to support troubleshooting and problem resolution, Lucent Technologies

recommends the switches be configured to enable history logging. If the switch in your
network does not store this information on the switch, a separate server will be needed
to store the data. Lucent Technologies recommends storage of this data on a
customer-controlled network server using the same practices used for other network
data (for example, SNMP data). See your vendor documentation for specific
information 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-link
Group (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 are
multiple OC3s that are linked to the routers. MLG size for the URC I varies from 1 to
4, for a URC II, the size varies from 1 to 8. Specific MLG size is determined by the
user.
At the DS1 concentrator, the MLGs from the URC are concentrated onto channelized
OC3 interfaces and mapped into a single OC3. The DS1 s that make up an MLG need
to be carried on the same OC3. The DS1 concentrator forwards the MLGs to the
routers.
The router is provisioned for the size of the MLG. Initial configuration occurs for the
MLG, then for the DS1 s.
.................................................................................................................................................................................................................................
401-710-090
3-7
Issue 3, March 2006
The following are general configuration guidelines for router configuration:

Parameter
Description
Value
Encapsulation
Multilink PPP
On
PFC, ACFC
Packet Header
compression
On
Fragment Delay, Threshold
Maximum fragment size
>UDPmux packet size, 384

bytes is acceptable
Minimum Links
Minimum links in DS1
IP Source address
IP address for router

side of Multilink group
Based on IP addressing
scheme
IP Destination add
IP address for cell side

of MLG
Based on IP addressing
scheme
Automatic protection switching
The Automatic Protection Switching (APS) mechanism of Synchronous Optical

Network (SONET) is used to provide redundancy for router failure and OC3 link
failure. Using APS, one router is configured as the working OC3 and the other as the
protect router. If a failure occurs on the working OC3 link an APS switchover occurs
to the protect OC3. The failure of the working OC3 can be caused by the physical link
or the hardware on the router associated with the OC3.
The following OC3 APS features are supported by both the DS1 concentrator and the
router:
Non revertive
1+1
STS
Bidirectional APS
Reference
Refer to your individual router documentation for details.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-8
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 an
existing network.
Table 3-3
IPBH new hardware requirements checklist for an existing network
Network
element
New hardware
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 or

URC-II
BTS/Modular cell/Modular cell 1/2/3 with URCm card
5ESS DCS
PSU2e, PHE3
FMM-RCS
AP
NA
1X-RNC
Two backhaul server GICCs for Ethernet connection
Two new
routers
For each router, the following are needed:
Two
Switches
2 new OC-3c modules
2 new AP PICs
Check
Varies by configuration as to the type of switch used.
.................................................................................................................................................................................................................................
401-710-090
3-9
Issue 3, March 2006
Cabling requirements checklist
The following table lists the cables required for physically connecting IPBH network
elements.
Table 3-4
IPBH cabling requirements checklist
Connection
Cable type
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
Check
Software requirements checklist
The following lists the software that must be installed on each of the IPBH network
elements.
Table 3-5
IPBH software requirements checklist
Network element
Software
ECP
ECP Release 25.0 and later
5ESS DCS
5e19.1 (generic) release for R25.0 and later NAR
Check
5ee16.l (generic) release for R26.0 International

1X-RNC
ECP Release 26.0 and higher
RCS-AP (FMM-AP)
ECP Release 26.0 and higher
BTS
BTS release 26.0 and higher:
Modular cells 1, 2, and 3
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-10
Subnetworks and IP addressing requirements checklist

Table 3-6
Network element
Max. # elements
Max. # nodes per

element
Total size
Subnet and mask

reserved subnet
RCS-AP
3 AP*8 drawers
2 IP addresses per
AP
/21 to host 2048
10 BHS/PSU
2+1 VIP per BHS
26 subnet addresses
per service module
(SM), each SM uses
one VLAN
15 RNCs
3 GICC pairs per

RNC
2 + 1 VIP per
GICC pair
/28 per RNC for up

to 15 (subnet 24)
BTS
12 UrcS/ BTS
600 BTSs
1 MLG per URC
Static: 2 IP
addresses per MLG
Pair of subnet
addresses per URC,
30 subnet addresses
for static ML-PPP
address
28 Frames
5ESS DCS
64 SMs per DCS
(up to 192)
1X RNC
Dynamic: pool or
IP addresses per
MLG
21 subnet addresses,
two VLANS per APF
AP control VLAN (subnet)
The AP control VLAN supports the signaling traffic between the backhaul cells and the
ECP. The following table lists the number of IP subnets needed for this VLAN. The
AP control VLAN requires three subnets, with a total of fourteen IP addresses.
Table 3-7
AP VLAN checklist
Subnetwork
Host
IP address
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
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
xxx.xxx.xx.b
Check
.................................................................................................................................................................................................................................
401-710-090
3-11
Issue 3, March 2006
Table 3-7
AP VLAN checklist
(continued)
Subnetwork
Host
IP address
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
Check
BHS VLAN
The BHS VLAN supports the BHSs on both the 5ESS DCS and the 1X-RNC. The
BHS VLAN carries the traffic packets as they are sent to the BHSs from the backhaul
cells and to backhaul cells from the BHSs. The BHS VLAN requires one subnet, with
a total of nine IP addresses.
The following table lists the IP subnets needed for this VLAN.
Table 3-8
BHS VLAN IP checklist
Subnetwork
Host
IP address
xxx.xxx.xx.d
5ESS BHS interface 1 to L2

switch 1
xxx.xxx.xx.d15
xxx.xxx.xx.e
5ESS BHS interface 1 to L2

switch 2
xxx.xxx.xx.e16
xxx.xxx.xx.f
5ESS DCS BHS interface 2 to

L2 switch 1
xxx.xxx.xx.f17
xxx.xxx.xx.g
5ESS DCS BHS interface 2 to

L2 switch 2
xxx.xxx.xx.g18
xxx.xxx.xx.h
1X-RNC/TPU 1 to L2 switch
1
xxx.xxx.xx.h19
xxx.xxx.xx.i
1X-RNC/TPU 2 to L2 switch
2
xxx.xxx.xx.i20
xxx.xxx.xx.j
Router interface 1 to L2
switch 1
xxx.xxx.xx.j21
xxx.xxx.xx.k
Router interface 2 to L2
switch 2
xxx.xxx.xx.k22
xxx.xxx.xx.l
L2 switch 1 to L2 switch 2
xxx.xxx.xx.l23
Check
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-12

Overview
.................................................................................................................................................................................................................................
Purpose
This section describes the activities required for preparing the 5ESS DCS for IPBH
network.
Contents
3-14
.................................................................................................................................................................................................................................
401-710-090
3-13
Issue 3, March 2006
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 the
5ESS-DCS documentation including the necessary requirements for connectivity
between 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 the 5ESS 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 Wireless
Networks Applications OA&M Manual (5AP) International:
PHE3 Provisioning, PHE3 Deprovisioning
Deprovisioning Channel Groups
PHE3 Growth
PHE3 Degrowth
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-14
5ESS DCS provisioning
Figure 3-2, 5ESS DCS provisioning for IPBH (p. 3-15) identifies the RC View
screens and activities in provisioning the 5ESS DCS.
Figure 3-2 5ESS DCS provisioning for IPBH
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 and
common BPH attributes such as overload thresholds, and 1st hop router
connectivity 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 the
PH group, assign the serving and non-serving IP addresses, etc.
.................................................................................................................................................................................................................................
401-710-090
3-15
Issue 3, March 2006
4. RC View 33.3 (90.6 INTL)BPH router attributes: For each BPH of the PH
group, define the router IP address.
5. RC View 22.32 (9.37 INTL)Assign BPHs to a PH group: Complete the PH
group 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 in 5ESS Switch Flexent /Autoplex Wireless Networks Applications
Manual, 235-105-231.
PHE3 growth
See PHE3 Growth in 5ESS Switch Flexent /Autoplex Wireless Networks

Applications Manual, 235-200-100.
The PHE is the protocol handler for Ethernet.
PH Provisioning
See PHE3 Provisioning in 5ESS Switch Flexent /Autoplex Wireless Networks

Applications Manual, 235-200-100.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-16

Overview
.................................................................................................................................................................................................................................
Purpose
This section describes the activities required for preparing the RNC as part of an IPBH
network.OMC-RAN user interface (p. 4-49)
Contents
3-18
3-20
.................................................................................................................................................................................................................................
401-710-090
3-17
Issue 3, March 2006
1X
RNC implementation overview
.................................................................................................................................................................................................................................
Requirements for setup
All PHVs and RNCs supporting cells in the soft handoff universe must be upgraded to
Release 25 or later.
When the optional RNC is used, the following activities must be completed prior to
starting 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 on
RNC at the TPU-GUI. See Install and configure IPBTS GW hardware and
software (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, as
illustrated in Figure 3-3, 1X RNC provisioning for IPBH (p. 3-18). This includes
Installation and configuraiton of the the BHS on the IPBTS GW in the RNC to set up
the connectivity between the BHS (on the BHS GICDC) and the IP Backhaul network.
Figure 3-3 1X RNC provisioning for IPBH
GICC (upper)
Install IPBTS GW
GICC
Assign IPBTS GW
GICC
TPU-GUI
IPBTS GWUpper
Provision BHS IP
attributes
TPU-GUI
Provision GICC
IP attributes
TPU-GUI
BHS
IPBTS GW
Lower
GICC (lower)
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-18
Procedures for GICC card installation and configuration
The following procedures are needed to install the GICC card:
Installationinstall and cable the IPBTS GW GICC pair. See Physical GICC card
installation (p. 3-21).
Identify the IPBTS GW GICC at the TPU-GUIassign the GICC pair that will
provide the IPBTS GW function. See Add and configure GICC pair on TPU-GUI
(p. 3-22).
Provision GICC IP attributes at the TPU-GUIfor each LAN port, define its fixed
address for ARPs with the first hop router and IP address of the first hop router on
the BHS Level IPBH Parameters page.
Provision BHS IP attributesassign the BHS IP address and establish BHS loading
threshold parameters.
See Install IPBTS Gateway (p. 3-20) for detailed steps.
.................................................................................................................................................................................................................................
401-710-090
3-19
Issue 3, March 2006
Install
IPBTS Gateway
.................................................................................................................................................................................................................................
When to use
Use this procedure to install the GICC for an IPBTS GW in an existing 1X RNC
network.
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 similar
to Virtual Router Redundancy Protocol (VRRP like), to provide service redundancy.
Important! IPBH is only supported on the GICC 1.1. Before putting a GICC pair
into 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 slot
19.
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-Mode
Fiber (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 intended

gateways.
The GICC cards (slot 3) provide the TPU Shelf Controller (SC) function.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-20
Determine the slots to be grown from the available growth slots.
Ask your network administrator for the values for the RNC Level IPBH
parameters, if necessary.
When replacing a GICC, always verify that the mate GICC to which you intend to
switch is not alarmed.
Physical GICC card installation
CAUTION
ESD hazard
To prevent damage to the integrated circuits on the cards, Electrostatic Discharge
Protection (EDP) must always be used.
Electrostatic Discharge (ESD) protective straps, shoes or mats must be used when
working with these cards.
To physically install a GICC card and connect the cables:
.................................................................................................................................................................................................
Run GigE cables from the 1X RNC cabinet to the L2 switch for each GICC in the
upper and lower shelf. The cable should be routed through the Frame Interface Panel
(FIP).
.................................................................................................................................................................................................
Begin installation of the GICCs in the upper shelf after confirming the installation slot
locations in the upper and lower shelves.
.................................................................................................................................................................................................
Hold the GICC replacement card vertical, and slide it firmly into the slot between the
two guides, then lock the upper and lower levers.
Result: The Power/Fault LED light turns green.
.................................................................................................................................................................................................
Connect the GICC connector cables. Change the heartbeat target IP address for the one
or two equipped GigE ports on the GICC to the routers IP address, and submit the
changes.
.................................................................................................................................................................................................
Tighten the card retention screw to anchor the card in the chassis.
.................................................................................................................................................................................................
Connect the GigE cable for PSU Gateway service. See Physically connect the cable
(p. 3-22) for instructions.
.................................................................................................................................................................................................................................
401-710-090
3-21
Issue 3, March 2006
.................................................................................................................................................................................................
Perform Step 4 through Step 6 for the GICC in the lower shelf.
E.................................................................................................................................................................................................
ND OF STEPS
Physically connect the cable
Use this procedure to install GigE cable(s) prior to performing provisioning and
configuration procedures.
To install a GigE cable, do the following:
.................................................................................................................................................................................................
Run the GigE cable from the 1X RNC cabinet to the L2 switch. (The cable should be
routed through the Frame Interface Panel (FIP).
.................................................................................................................................................................................................
Connect the cables for the PSU Gateway service as applicable.

E.................................................................................................................................................................................................
ND OF STEPS
Add and configure GICC pair on TPU-GUI
This procedure adds and configures the GICC card pairs through the TPU-GUI
Configuration Wizard.
To add and configure GICC cards:
.................................................................................................................................................................................................
Obtain access to the TPU-GUI either directly or through the EMS.

If using EMS, at the OMP Web page, select 1X RNC TPU Web.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-22
Result: The 1X RNC TPU Web page displays:
.................................................................................................................................................................................................
Do one of the following:
On the OMP Web tool bar on the left side of the page, use the drop-down list in
the upper left corner of the page to select the RNC to be configured.
On the 1X RNC TPU Web page, select Configuration Data.
.................................................................................................................................................................................................................................
401-710-090
3-23
Issue 3, March 2006
The RNC Configuration Data page displays.
.................................................................................................................................................................................................
On the RNC Configuration Data page under Wizards, select GICC 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 the
GICCs, alarms will be generated.
.................................................................................................................................................................................................
Select Next.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-24
Result The Grow GICC-GICC Selection page displays.
.................................................................................................................................................................................................
To grow in an IPBTS GICC, do the following:

1.
2.
3.
4.
5.
Find GICC # area on Shelf 1: Working GICCS for the slot being grown in.
By GICC Type, use the drop-down list and select IPBTS.
Find GICC # area on Shelf 2: Protection GICCS for the slot being grown in.
By GICC Type, use the drop-down list and select IPBTS.
Choose Next to continue.
.................................................................................................................................................................................................................................
401-710-090
3-25
Issue 3, March 2006
Result The BHS Level IPBH Parameters page displays.
.................................................................................................................................................................................................
Choose Add, then enter the BHS IP address, subnet mask and UDP port.
.................................................................................................................................................................................................
Select Next.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-26
Result The RNC Level IPBH Parameters page displays.
.................................................................................................................................................................................................
Enter new critical threshold values for the displayed parameters if desired. If there is
no change, proceed to Step 9.
.................................................................................................................................................................................................
Select Next.
.................................................................................................................................................................................................................................
401-710-090
3-27
Issue 3, March 2006
The External IP packet Data Network page displays for you to review the GICC
information.
.................................................................................................................................................................................................
10
Select Next.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-28
The Summary Page displays all the set up information ready for submission.
.................................................................................................................................................................................................
11
Select Submit.
Result The Confirm box displays the question: Are you sure you want to Grow
selected GICCs?
.................................................................................................................................................................................................
12
Select Yes.
Result The Message box displays: Request to grow GICC(s) processed
successfully!
.................................................................................................................................................................................................
13
Select OK.
.................................................................................................................................................................................................................................
401-710-090
3-29
Issue 3, March 2006
Result The RNC Configuration Data page displays.

.................................................................................................................................................................................................
14
Important! Depending on system activity, successful growth of a GICC may

require between one and two minutes before the GICC status is updated on the
TPU GUI. Wait approximately two minutes before proceeding.
Select the TPU WEB button to return to the main 1X RNC TPU Web page, then select
Network Elements
Result The Traffic Processing Unit (TPU) page displays.
.................................................................................................................................................................................................
15
At the Filter: box, select IPBTS to filter the information display.

Result The list for the TPU displays information only for the IPBTS.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-30
.................................................................................................................................................................................................
16
Determine the state of the new GICC by reviewing the Admin State, Oper State and
Usage State.
Result The new GICC could be in any of the following states. The states vary
depending 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 select Reset.

Result The GICC should return to:
Admin StateLocked
Oper StateDisabled
Usage StateIdle
.................................................................................................................................................................................................
18
Perform an unlock of the GICC via the Commandscolumn of the TPU Network
Elements page
Result The GICC card is now in service.
END OF STEPS
........................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
401-710-090
3-31
Issue 3, March 2006
Pre-conversion: Prepare FMM-AP and RCS for

IPBH
Overview
.................................................................................................................................................................................................................................
Purpose
This section describes the activities required for preparing the FMM-AP and its
associated processors as part of an IPBH network.
Contents
3-33
Provision ecp form
3-34
3-37
3-38
3-41
3-44
3-49
3-50
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-32
FMM-RCS
implementation
.................................................................................................................................................................................................................................
Provision FMM-RCS for IPBH
Provisioning the FMM-RCS to support IPBH involves performing the following

procedures in the order given:
1.
2.
3.
4.
5.
6.
7.
8.
Provision IP Backhaul Control Network ID field on the ecp form.

Configure FMM-RCS IM.
Provision RCS IP services using the apeqp form.
Provision primary and alternative APs on the cmodeqp form.
Retrieve BPSNs
Provision Carrier/SOC data on the cell2 form.
Provision cdmeqp form.
Provision btseqp form.
.................................................................................................................................................................................................................................
401-710-090
3-33
Issue 3, March 2006
Provision
ecp form
.................................................................................................................................................................................................................................
Purpose
Use this procedure to provision fields on the ecp form that are associated with
converting the FMM-RCS (AP-RCS) to support IPBH.
Table 3-9, ecp form-IPBH fields (p. 3-34) lists all of the IPBH field, describes their
purpose and lists valid values for that field.
Table 3-9
Field name
Description
Valid
values
Restriction
IP Backhaul
Control
Network ID
This field identifies the IP Backhaul

address in four parts (octets):
0-255
Indicates the 21-bit network

prefix that determines the
address space for the IPBH
control network. This network
is split in half to create two
subnets: Lan0 and Lan1.
Any change would take effect
at the beginning of the next
reporting interval.
IP Address part 1
IP Address part 2
IP Address part 3
IP Address part 4
BHCS
Failure
Reporting
Interval
The provisionable interval when the

MSC will report invalid attempt
statistics regarding BTS
authentication.
0-60
minutes;
Default
Traffic
Diffserv
Codepoint
This field is the default Diffserv

Codepoint that will be applied to all
traffic not assigned to the higher
priority traffic classes
User Class
Traffic
Diffserv
Codepoint
This field is the Diffserv Codepoint

that will be applied to all traffic not
assigned tot he higher priority traffic
classes.
0-63
Signaling
Class Traffic
Diffserv
Codepoint
This field is the Diffserv Codepoint

that will be applied to all signalling
class traffic.
0-63
Default=15
minutes
Default=0
Default=46
Default=10
If you make a change to a

codepoint on this screen, you
must make a change in the
corresponding router.
If you make a change to a
codepoint on this screen, you
must make a change in the
corresponding router.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-34
Table 3-9
Provision ecp form
(continued)
Field name
Description
Valid
values
Restriction
Backhaul
Connection
Server Lan0
IP address
Identifies the Backhaul Connection

Server Lan0 IP address.
0-255
Populated from IPBH Control

Network ID
Backhaul
Connection
Server Lan1
IP address
Lan0
Backhaul
Connection
Server
Gateway IP
Address
Lan1
Backhaul
Connection
Server
Gateway IP
Address
This address is in four parts (octets:
LAN0 IP Address part 1
Identifies the Backhaul Connection

Server Lan1 IP address.
(Display only field)
0-255
Indicates the Lan0 gateway IP

address for the BHCS on the IPBH
network. This is the IP address where
the BHCS directs traffic outside of
Lan0.

Network ID
0-255

Network ID
Indicates the Lan1 gateway IP

address for the BHCS on the IPBH
network. This is the IP address where
the BHCS directs traffic outside of
Lan1.
0-255

Network ID
.................................................................................................................................................................................................................................
401-710-090
3-35
Issue 3, March 2006
Provision ecp form
Before you begin
You must know the fields and valid values needed for converting the AP-RCS to
support IPBH.
Refer to the frequency and impacts of performing this procedure
Frequency
Lucent Technologies does not recommend changing the IP Backhaul Control Network
ID field except during a scheduled retrofit.
Impacts
Changing the IP Backhaul Control Network ID field while the system is running may
cause the IP addressing for the APs, BHCS, and ECP to become out of sync. To
correct this problem, a system restart is needed. Lucent Technologies recommends
changing this field only during a scheduled retrofit as a system restart is already
planned.
Procedure
.................................................................................................................................................................................................
Launch the RC/V ecp form.

.................................................................................................................................................................................................
Advance to the IP backhaul Information Only screen.

.................................................................................................................................................................................................
Populate the IPBH fields as given in Table 3-9, ecp form-IPBH fields (p. 3-34).
E.................................................................................................................................................................................................
ND OF STEPS
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.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-36
Configure
FMM-RCS IP Integrity Manager
.................................................................................................................................................................................................................................
Purpose
Use this procedure to configure the RCS-IP integrity manager (IM). This procedure
must be done before provisioning the apeqp 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 the ecp form. See
Provision ecp form (p. 3-34).
Procedure
.................................................................................................................................................................................................
Log into the OMP as root.

.................................................................................................................................................................................................
Enter the following command to configure the RCS-IS:

apappconfig -c -a IS -p ap### -s ap###
E.................................................................................................................................................................................................
ND OF STEPS
Result
The RCS-IM has been configured. Continue with Provision apeqp form (p. 3-38).
.................................................................................................................................................................................................................................
401-710-090
3-37
Issue 3, March 2006
Provision
apeqp form
.................................................................................................................................................................................................................................
Purpose
Use this procedure to provision the IPBH related fields on the apeqp form.
Table 3-10, apeqp form-IPBH fields (p. 3-38) lists all of the IPBH fields used on the
form, describes their purpos,e and lists valid values for that field.
Table 3-10
Field
Description
Valid values
RCS IP Services
Enabled
Indicates whether or not IPBH signaling

services are enabled on this AP.
Y or N
RCS-IM Exists
Indicates whether or not the RCS-IM has

been configured.
Y or N
This field is set to y for APs specified

using the apappconfig command.
Indicates the APs IP address on the IPBH

Control Network for its interface 0.
0-255
This field identifies the IP address in four

parts (octets):
Interface 0
Backhaul IP
Address
Interface 1
Backhaul IP
Address
IP Address part 1
IP Address part 2
IP Address part 3
IP Address part 4
Default = n
Default = n
Default = 0
Indicates the APs IP address on the IPBH

Control Network for its interface 1.
0-255

parts (octets):
IP Address part 1
IP Address part 2
IP Address part 3
IP Address part 4
Default = 0
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-38
Table 3-10
(continued)
Field
Description
Valid values
Lan0 Default
Gateway IP
Address
Indicates the Gateway IP address for the AP

Lan0.
0-255

parts (octets):
Lan1 Default
Gateway IP
Address
IP Address part 1
IP Address part 2
IP Address part 3
IP Address part 4
Default = 0
Indicates the Gateway IP address for the AP

Lan1.
0-255

parts (octets):
IP Address part 1
IP Address part 2
IP Address part 3
IP Address part 4
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 to
support IPBH.
The IP Backhaul Control Network ID field has been provisioned on the ecp form
The RCS IM has been configured.
Procedure
.................................................................................................................................................................................................
Launch the RC/V apeqp form.

.................................................................................................................................................................................................
Advance to the IP Backhaul configuration screen.

.................................................................................................................................................................................................
Enter Y in the field RCS IP Services Enabled.
.................................................................................................................................................................................................................................
401-710-090
3-39
Issue 3, March 2006
All other fields on the apeqp form are based on data entered on the ecp form. See
Provision ecp form (p. 3-34) for entry of ecp information for IPBH.
.................................................................................................................................................................................................
Save and exit the form. For complete information on all fields on this screen, see Table
3-10, apeqp form-IPBH fields (p. 3-38).
E.................................................................................................................................................................................................
ND OF STEPS
Result
This step of provisioning the FMM-RCS for IPBH is complete. Continue on to

Retrieve Backplane Serial Number (BPSN) (p. 3-41).
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-40
Retrieve
Backplane Serial Number (BPSN)
.................................................................................................................................................................................................................................
Purpose
Use this procedure to run the command to retrieve the backplane serial numbers
(BPSN) and place it in the cdmeqp database.
The BPSN is on the BTS at the cellsite, and is unique per assemblage. During cell
initialization, an IP-based cell passes this number to the MSC, where the MSC
compares 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 or
later.
User interface
This procedure requires execution of TICLI commands from either the TICLI or the
OMC-RAN TICLI.
Procedure
.................................................................................................................................................................................................
Log into the TICLI/OMC-RAN TICLI.

.................................................................................................................................................................................................
Retrieve the BPSN by entering one of the following commands:

If you need to
then enter
where
Retrieve the BPSN from

cell number x
UPDATE:CELL x, BPSN
where x=cell
number.

all active cells
UPDATE:CELL ALL, BPSN

all active cells on AP
number y
UPDATE:AP y, BPSN
where y=AP
number.
.................................................................................................................................................................................................................................
401-710-090
3-41
Issue 3, March 2006
Result: The valid BPSN of the cell is inserted into the cdmeqpdb file and the
success or failure of the cell update is displayed.

If cell update was
then the command output
a failure was
reported
displays only the BPSN information from the database for the
cell.
Successful
displays the equipped assemblage information, along with the

BPSN and an indication of whether the BPSN was changed due
to the update or not.
The following output example is from the UPDATE: AP command. Each character in
an invalid BPSN is represented by two hex digits.
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
UPDATE:AP 31,BPSN! IN PROGRESS
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
CELL ASMB BPSN
ACTION PERFORMED
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
144 1
0x0b07090c0b0b0b0b0b0b0b41
RECD INVALID
1234567890123456789012345678901212345678901234567890123456789
BPSN
FROM
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
CELL, DB NOT UPDATED
1234567890123456789012345678901212345678901234567890123456789
150 1
sprcs0000150
BPSN READ FROM DB, CELL NOT ACTIVE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
151 1
sprcs0000151
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
152
1
sprcs0000152
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
153 1
sprcs0000153
1234567890123456789012345678901212345678901234567890123456789
154
1
sprcs0000154
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
155 1
sprcs0000155
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
156 1
sprcs0000156
1234567890123456789012345678901212345678901234567890123456789
157 1
0x0b07090c0b0b0b0b0b0b0b41
RECD INVALID BPSN FROM
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
CELL,
DB
NOT
UPDATED
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
158 1
sprcs00158a1
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
158 2
sprcs00158a2
1234567890123456789012345678901212345678901234567890123456789
159
1
sprcs00159a1
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
159
2
sprcs00159a2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
160 1
sprcs00160a1
1234567890123456789012345678901212345678901234567890123456789
160 2
sprcs00160a2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
161
1
sprcs00161a1
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
ORIGINATING COMMAND #329979115.3
1234567890123456789012345678901212345678901234567890123456789
2005-04-13 09:56:52 REPORT #000001
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
EXECUTED ON PROCESSOR: AP 35
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
The following are some of the BPSN update error messages:
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-42
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
BPSN READ FROM DB, CELL DID NOT RESPOND
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
BPSN BLANK IN DB, CELL DID NOT RESPOND
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
BPSN UPDATED IN DB
1234567890123456789012345678901212345678901234567890123456789
BPSN BLANK IN DB, CELL RELEASE IPBH INCOMPAT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
BPSN BLANK IN DB, CELL NOT ACTIVE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
BPSN BLANK IN DB, CELL FAILED TO GET BPSN
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
BPSN READ FROM DB, CELL FAILED TO GET BPSN
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
RECD DUP OF BPSN FOR CELL:130, ASM:1, DB NOT UPDATED
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
The first part of converting the FMM-RCS is now complete. Continue
configuration with Provision cell2 form (p. 3-44).
END OF STEPS
........................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
401-710-090
3-43
Issue 3, March 2006
Provision
cell2 form
.................................................................................................................................................................................................................................
Purpose
Use this procedure to provision fields associated with converting the FMM-RCS to
support IPBH on the cell2 form.
Related information
The user entering information on the cell2 form should be aware of the fields and valid
values needed for converting the FMM-RCS to support IPBH.
To use an RNC: Data offload must be on and a data offload RNC defined. The
backhaul offload BHS is separate from the BHS defined on the SOC table. The
backhaul offload BHSs can be provisioned on either RNCs or 5ESS DCSs, but not
both simultaneously.
Table 3-11, cell2 form-IPBH fields (p. 3-44) lists all of the IPBH field, describes
their purpose and lists valid values for that field.
Table 3-11
Field
Description
Valid values
Restrictions
IP Backhaul Enabled
Indicates whether the IP

Backhaul feature has been
enabled on this cell.
Y or N
All equipped carriers

for the cell must have a
BHS assigned and the
backhaul mode must be
IP for each equipped
URC/CDM in the cell
for this field to be
enabled.
Backhaul Offload
Assigns all packet data

traffic for the cell to a
specific BHS as specified
under Backhaul Offload.
Y or N
To set this field to Y,

either the Primary RNC
or the Primary SM field
must be provisioned.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-44
Table 3-11
(continued)
Field
Description
Valid values
Restrictions
Primary RNC Number
Specifies the logical RNC

number that will be used
by all packet data calls
served by this cell.
Blank, 1-15,
step by 1
The Backhaul Offload

field must be set to Y,
Packet Core Data field
must beset to Y, and
the RNC must be
equipped on the ecppkt
form for this field to be
used.
Primary RNC Backhaul

Server Number
Specifies the BHS number

that is associated with the
RNC GICC card for the
Primary BHS.
Blank, 1-3
The Primary RNC

Number field must be
populated for this field
to be provisionable.
BHS 1 is associated with

GICC slot 20, BHS 2 is
associated with GICC slot
4, and BHS 3 is associated
with GICC slot 19.
Primary Switching Module
Number (SM)
Specifies the SM that will

be used by all packet data
calls served by this cell.
Blank, 1-192
The Backhaul Offload

field must be set to Y
and Packet Core Data
field must be N for this
field to be used.
Primary Packet Switching

Unit Number (PSU)
Specifies the PSU where

the Primary BHS is
installed.
Blank, 0 or 1
The Primary SM field

must be populated for
this field to be
provisionable.
Primary DCS Backhaul

Server Number

that equates to the DCS
PH group for the Primary
DCS BHS.
Blank, 1 to 10

this field to be
provisionable.
Alternate RNC Number
Specifies the RNC where

the Alternate RNC BHS is
installed. The Alternate
RNC BHS is used when
the Primary RNC BHS is
unavailable.
Blank, 1 to 15
The Primary RNC

Alternate RNC Backhaul

Server Number

that is associated with the
RNC GICC card for the
Alternate BHS.
Blank, 1-3
The Alternate RNC

.................................................................................................................................................................................................................................
401-710-090
3-45
Issue 3, March 2006
Table 3-11
(continued)
Field
Description
Valid values
Restrictions
Alternate Switching
Module Number (SM)
Specifies the SM where

the Alternate DCS BHS is
installed. The Alternate
DCS BHS is used when
the Primary DCS BHS is
unavailable.
Blank, 1 to 192

this field to be
provisionable.
Alternate Packet Switching

Unit Number (PSU)

the Alternate DCS BHS is
installed.
Blank, 0 or 1
The Alternate SM field

this field to be
provisionable.
Alternate DCS Backhaul

Server Number

PH group for the Alternate
DCS BHS.
Blank, 1-10
The Alternate SM field

this field to be
provisionable.
MLG Loading Bias

Translation
BIASMLG is used by cell

call processing to compute
Multi-Link Group load.
When the bias is adjusted,
some MLGs will be
selected over others. This
allows the backhaul traffic
to be concentrated on these
MLGs and therefore
improves the transportation
efficiency
0 to 100% in
increments of
10
CDMA Carrier Service

Option Class
Specifies the type of

traffic that will be routed
to the BHS.
Blank, Voice,
Both
(View-only)
When the Backhaul

Offload field is set to
Y, this field displays
Voice for a provisioned
carrier. When the
Backhaul Offload field
is set to N, this field
displays Both for a
provisioned CDMA
Carrier.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-46
Table 3-11
(continued)
Field
Description
Valid values
Restrictions
CDMA Carrier Switching

Module
Specifies the SM that will

be used by all voice calls
served by this CDMA
Carrier. Also specifies the
SM that will be used for
all packet data calls when
the Backhaul Offload field
is set to N.
Blank, 1 to 192
This field must be

provisioned when the
IP Backhaul Enabled
field is set to Y and
this CDMA Carrier is
assigned a channel on
the cgsa form or the
cell2 form.
CDMA Carrier Packet

Switching Unit

the BHS for this CDMA
Carrier is installed.
Blank, 0 or 1
The Switching Module

field for this CDMA
Carrier must be
CDMA Carrier Backhaul

Server

PH group where the BHS
for this CDMA Carrier is
installed.
Blank, 1 to 10
The Switching Module

field for this CDMA
Carrier must be
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 the IP Backhaul Control Network ID
field. See Provision ecp form (p. 3-34).
The IPBH RTU feature qualifier value must be large enough to add the additional
carriers equipped for the cell.
The RCS-IP IM has been configured. See Configure FMM-RCS IP Integrity
Manager (p. 3-37).
The btseqp/cdmeqp form must be set for Backhaul mode. See Provision btseqp
form (p. 3-50) and Provision cdmeqp form (p. 3-49).
The apeqp form has been provisioned with the RCS-IP Services Enabled and
RCS-IM Exists fields. See Provision apeqp form (p. 3-38).
The BPSNs have been retrieved from the cells and the btseqp/cmdeqp database
has been updated. See Retrieve Backplane Serial Number (BPSN) (p. 3-41) and
Provision cdmeqp form (p. 3-49).
.................................................................................................................................................................................................................................
401-710-090
3-47
Issue 3, March 2006
Procedure
.................................................................................................................................................................................................
Launch the RC/V cell2 form.

.................................................................................................................................................................................................
Advance to the CDMA Cell Site for IP Backhaul Information Only screens.
.................................................................................................................................................................................................
Populate the IPBH fields as described in Table 3-11, cell2 form-IPBH fields
(p. 3-44).
END OF STEPS
........................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-48
Provision
cdmeqp form
.................................................................................................................................................................................................................................
Purpose
Use this procedure to provision fields associated with converting the RCS to support
IPBH on the cdmeqp form. This form is used for Modular cells 1, 2, and 3.
Related information
The user entering information on the cdmeqp form should be aware of the fields and
valid values needed for converting the RCS to support IPBH.
Table 3-12, cdmeqp form-IPBH fields (p. 3-49) lists all of the IPBH fields, describes
their purpose and lists valid values for each field.
Table 3-12
Field
Description
Valid values
Backplane Serial Number
Indicates the number on the

BTS that is unique per
assemblage.
This value is stored in the

cdmeqpdb.
Backhaul Mode
Backhaul mode must be set to

IP for each CDM/CRC for the
cell.
FR, ATM, IP and SH
Procedure
.................................................................................................................................................................................................
Launch the RC/V cdmeqp form.

.................................................................................................................................................................................................
Populate the Backplane Serial Number if it was not previously populated using the
UPDATE:CELL x, BPSN TICLI command.
.................................................................................................................................................................................................
Enter the value IP in the Backhaul mode field. See Table 3-12, cdmeqp form-IPBH
fields (p. 3-49) for a list of valid values for IPBH fields.
END OF STEPS
........................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
401-710-090
3-49
Issue 3, March 2006
Provision
btseqp form
.................................................................................................................................................................................................................................
Purpose
Use this procedure to provision fields associated with converting the FMM-RCS to
support IPBH on the btseqp 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 and
valid values needed for converting the FMM-RCS to support IPBH.
Table 3-13, btseqp form-IPBH fields (p. 3-50) lists all of the IPBH fieldS, describes
their purpose and lists valid values for each field.
Table 3-13
Field
Description
Valid values
Backplane Serial
Number
Indicates the number on the BTS that

is unique per assemblage.
This value is stored in the cdmeqpdb.
Backhaul Mode
Backhaul mode must be set to IP for

each CDM/CRC for the cell.
FR, ATM, IP and SH
Procedure
.................................................................................................................................................................................................
Launch the RC/V btseqp form.

.................................................................................................................................................................................................
Enter the value IP in the Backhaul mode field for each CMD/CRC. See Table 3-13,
btseqp form-IPBH fields (p. 3-50) for a list of valid values for IPBH fields.
.................................................................................................................................................................................................
Exit the btseqp form.

.................................................................................................................................................................................................
Launch the RC/V cell2 form.

.................................................................................................................................................................................................
Set the IP Backhaul Enabled field to y,

END OF STEPS
........................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-50
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 cells packet pipe
trunk group in the cmodpptm form.
Delete the related record in pptg form.
Update the record for the cell in cdmeqp/btseqp form:
The fields in cdmeqp are: AP Signaling Link Information for Connections at
the AP, Digital Module Link Information for Connections at the CDM, CDM
Digital Module DS1 Information (Signaling Type and Signaling/PP Data Rate),
and Signaling Link Width.
The fields in btseqp are: Digital Module Signaling Link Information for
Connections at the CDM, AP Signaling Link Information for Connections at
the AP, CDM Digital Module DS1 Info (Type and Data Rate), and Signaling
Link Width.
Update the cell2 form to blank the CDMA Packet Pipe Trunk Group field.
.................................................................................................................................................................................................................................
401-710-090
3-51
Issue 3, March 2006
Delete
DS1/DS0s used with FR-based FMM-RCS
.................................................................................................................................................................................................................................
Purpose
Use this procedure to delete DS1/DS0s that were associated with a LAPD/FR-based
RCS that has been converted to IPBH. These deleted DS1/DS0s can then be used for
other purposes.
Required activities
The apeqp form must be cleaned up manually once all the LAPD-based cells using
DS1s supported by a particular AP have been converted to IP and committed. The
commit 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
.................................................................................................................................................................................................
Launch the RC/V apeqp form.

.................................................................................................................................................................................................
Advance to the DS1 Configuration screen.

.................................................................................................................................................................................................
Change the DS1 Status to Unequipped.

.................................................................................................................................................................................................
Save and exit the form. For complete information on all fields on this screen, see Table
3-10, apeqp form-IPBH fields (p. 3-38).
END OF STEPS
........................................................................................................................................................................................................................
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
3-52
O A&M for IP Backhaul

4
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 within
the network.
Contents
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
4-29
4-38
OMC-RAN
4-48
4-48
.................................................................................................................................................................................................................................
401-710-090
4-1
Issue 3, March 2006

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 selected
routers and switches. Ask your Lucent representative about VRAD-5576 for specific
requirements for routers and switches.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-2
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 application
processor (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-configuration
of 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 and
messages (p. 4-29).
New and Modified Status Display Pages: See Status display pages (p. 4-38).
BTS IPBH Service Measurements: See Chapter 6, IPBH performance measures.
DS1 Monitoring and recovery.
Remote maintenance terminal
The remote maintenance terminal (RMT) is software that runs on a personal computer
that can then communicate to the BTS. The RMT software communicates with
software running on the cell, and provides the ability to perform various diagnostic
functions. This communication occurs through an Ethernet connection. The full
installation RMT software version is required to reconfigure a BTS from FR to IPBH
remotely. This document assumes that the user is familiar with the use of the RMT for
BTS maintenance activities.
.................................................................................................................................................................................................................................
401-710-090
4-3
Issue 3, March 2006
BTS OA&M for IPBH
Remote access allows the RMT to communicate with a URC in a cell through the
LAN connection of any FMM-AP on the same LAN as the AP managing the cell
without having to make a cell site visit. To communicate remotely via RMT, the user
connects the PC or laptop computer with the RMT software to the LAN of an AP that
serves a particular BTS. When communication is established, RMT commands can be
executed.
The connection status is logged using existing logging mechanisms. RMT can be
connected 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 recovery

process 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 the
signaling links are maintained with minimal loss in capacity.
When a major or critical alarm is cleared, the DS1 must be clear of any other critical
or major alarms for at least 10 seconds before it is put back into the MLG. This is
done 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 level
for minor alarm threshold (default threshold equals ten times less than major alarm
threshold)
Important! This threshold is tunable by Lucent Technologies. Contact your account
representative for assistance.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-4
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 CommandsSee Input/Output commands

and messages (p. 4-29).
New and Modified Status Display Pages (SDP)See Status display pages
(p. 4-38).
IPBH Service Measurements (SM)See Chapter 6, IPBH performance measures.
IP backhaul data added to existing RC/V formsSee ECPC OA&M (p. 4-21).
The following forms are used for IPBH:
apeqp
btseqp
cell2
cdmeqp
cmodeqp
ecp
.................................................................................................................................................................................................................................
401-710-090
4-5
Issue 3, March 2006
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 provide
data offload capability.
The following additions and modifications have been made for IPBH:
IP mode data is added to existing RC/V forms for RNC provisioningSee RC/V
forms updated for IP Backhaul (p. 4-21).
Modified Technician Interface CommandsSee Input/Output commands and
messages (p. 4-29) for information on new 1X RNC output messages that report
BHS traffic overload, BHS port usage limit, and BHS dropped packet threshold
crossings.
New and modified traffic processing unit-graphical user interface (TPU-GUI)
screensSee IPBH provisioning at the RNC (p. 4-6).
IPBH Service MeasurementsSee Service measurements (p. 6-1).
IPBH provisioning at the RNC
The 1X RNC is provisioned initially using the TPU-GUI First Time Wizard that
takes the user step-by-step through RNC provisioning.
New TPU-GUI pages:
The IPBTS is the selected GICC configuration type on the RNC Configuration
Data Screen.
BHS Level IPBH Parameters.
RNC Level IPBH Parameters.
Provisioning order
1X RNC provisioning for IPBH occurs for the IPBTS GW GICC pair:
1. Installationinstall and cable the IPBTS GW GICC pair.
2. Identify IPBTS GW GICC at the TPU-GUIassign the GICC pair that will provide
the IPBTS GW function.
3. Provision GICC IP attributes at the TPU-GUIfor each LAN port, define its fixed
address for ARPs with the first hop router and IP address of the first hop router.
4. Provision BHS IP attributesassign BHS IP addresses and establish BHS loading
threshold parameters.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-6
1X RNC OA&M
TPU-GUI screens
IPBH affects only a small number of TPU-GUI screens. For all other TPU-GUI
screens, refer to the Flexent 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 IPBH
Parameters and RNC Level IPBH Parameters.
Figure 4-1 RNC Configuration Data
.................................................................................................................................................................................................................................
401-710-090
4-7
Issue 3, March 2006
1X RNC OA&M
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 GICC
Pair.
Figure 4-2 BHS Level IPBH Parameters
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-8
1X RNC OA&M
RNC Level IPBH Parameters
RNC Level IPBH Parameters allow the user to enter and modify:
Threshold valuessuch as BHS Loading Threshold, BHS UDP port Usage

Threshold
GigE Port IP Address, Subnet Mask and Target IP Addresses of each IPBTS
GICCs.
Figure 4-3 RNC Level IPBH Parameters screen
Input/Output commands
Commands that are specific to the 1X RNC/TPU can be initiated either from the
TPU-GUI or TPU-CLI.
Table 4-1
Command
Description
GET:RNC-TPU-STATE
This command includes an IPBTS gateway option to

display 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.
.................................................................................................................................................................................................................................
401-710-090
4-9
Issue 3, March 2006
Table 4-1
1X RNC OA&M
(continued)
Command
Description
LOCK-RNC-TPU
IPBTS gateway information was added to this

output.
See Input/Output commands and messages (p. 4-29) for additional information about
these inputs and outputs.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-10
5ESS
DCS OA&M
.................................................................................................................................................................................................................................
Purpose
IP Backhaul is supported on BHSs hosted on the 5ESS DCS. This section describes
OA&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 pageSee Status display pages
(p. 4-38).
New 5ESS-DCS traffic measurementsSee Service measurements (p. 6-1).
Note that the 1X RNC refers to the IPBTS gateway that connects the BTS to the
backhaul server (BHS) in the RNC. The gateway from the the 5ESS to the BTS is
simply 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 a
BHS 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 GW
to the standby BHS GW.
Both BHS GWs send periodic address resolution protocol (ARP) requests to the
first hop router to verify connectivity to the router.
The call leg dynamic data is synchronized between the BPHs to facilitate
switchover 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 ARP
for the serving IP address and start processing the traffic. All the stable call legs are
preserved over the failover.
.................................................................................................................................................................................................................................
401-710-090
4-11
Issue 3, March 2006
5ESS DCS OA&M
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)
See Chapter 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
9.37
BPH specific data
PHGRP
Defines PH group and common BPH

attributes such as overload thresholds, and
first-hop router connectivity checking
parameters.
33.1
90.5
BPH IP attributes
IPPRC
33.3
90.6
BPH router attributes
IPRTE
RC View 33.4
90.7
BPH Ethernet link

attributes
IPETH
For each BPH of the PH group, defines

its IP, ICMP, and UDP parameters.
For each BPH of the PH group, defines
its router IP address.
For each BPH of the PH group, assigns
the 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:
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-12
5ESS DCS OA&M
Figure 4-4 RC View 22.32 (NAR): Protocol Handler Group Definition 1 of 4
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN
1
OF
4
RECENT
CHANGE 22.32
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5892)
PROTOCOL HANDLER GROUP DEFINITION
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. SM
___
GENERAL PARAMETERS
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*2.
PSU
_
SECONDARY
ADDR
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*3. PH GROUP __
12. PKT BUS INTRVL
____
1234567890123456789012345678901212345678901234567890123456789
4. APP TYPE ________
13. L1 OVRLD THRESHOLD __
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
14. L2 OVRLD THRESHOLD __
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5. PROTOCOL HANDLERS (PHLIST)
15. CONN CHK ENABLED
_
1234567890123456789012345678901212345678901234567890123456789
CHL
PH
16.
CON
CHK
HIGH
INT
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
ROW PH SHELF GRP POSITION TYPE
17. CON CHK LOW INT
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1
0
_
__
__
____
18. CONN CHK MAX FAIL __
1234567890123456789012345678901212345678901234567890123456789
2
1
_
__
__
____
19. SW OVR TIMER
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN 2 OF 4
RECENT CHANGE 22.32
1234567890123456789012345678901212345678901234567890123456789
(5892)
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
GENERAL PARAMETERS cont.
IP BACKHAUL PARAMETERS
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
20. DIFF SRV CODE POINT __
25. BHA BASE UDP PORT _____
1234567890123456789012345678901212345678901234567890123456789
21. RCV ICMP THRSH
___
26. BHA PRE PORT
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
22. AVG DELAY THRESHOLD ______
27. BHA QUALITY
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
23. PCT DELAY THRESHOLD ______
28. BHA INACT TIMER
__
1234567890123456789012345678901212345678901234567890123456789
24. DELAY PERCENTAGE
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
4-13
Issue 3, March 2006
5ESS DCS OA&M
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
SCREEN
3
OF
4
RECENT
CHANGE 22.32
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5892)
PROTOCOL
HANDLER
GROUP DEFINITION
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IPSHO PARAMETERS
40. IP TRAFFIC STATE _
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
29.
EXT
L1
OVRLD
THRESHOLD
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
30. EXT L2 OVRLD THRESHOLD __
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
31. HIGH DSCP
__
1234567890123456789012345678901212345678901234567890123456789
32. LOW DSCP
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
33.
OAM
DSCP
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
HIGH UDP
_____
1234567890123456789012345678901212345678901234567890123456789
LOW UDP
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
OAM
UDP
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
NETWORK TEST UDP
_____
1234567890123456789012345678901212345678901234567890123456789
38. HEART BEAT FREQ
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
39. HEART BEAT LDI
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
SCREEN 4 OF 4
RECENT CHANGE 22.32
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5892)
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
NPH PARAMETERS
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
41. UDP START PORT _____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
42. UDP BLOCK SIZE ____
1234567890123456789012345678901212345678901234567890123456789
43. NPH QUALITY
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
44.
BNID
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-14
5ESS DCS OA&M
RC View 33.1
Figure 4-8 RC View 33.1 (NAR): IP Processor Assignment 1 of 3
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN
1
OF
3
RECENT
CHANGE 33.1
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5987)
INTERNET PROTOCOL (IP) PROCESSOR ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. PROCESSOR ID
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*2. PROCESSOR TYPE ___
1234567890123456789012345678901212345678901234567890123456789
(*)3. QUALIFIER 2
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(*)4.
QUALIFIER
3
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5. IP ADDRESS
1234567890123456789012345678901212345678901234567890123456789
ROW
LOCAL
IP
ADDR
IP SUBNET MASK
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1
___.___.___.___
___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
2 ___.___.___.___ ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
3 ___.___.___.___ ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
4 ___.___.___.___ ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5 ___.___.___.___ ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
Figure 4-9 RC View 33.1 (NAR): IP Processor Assignment 2 of 3
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
SCREEN
2
OF
3
RECENT
CHANGE 33.1
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5987)
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP PARAMETER ASSIGNMENT
UDP PARAMETER ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
16.
REASSEM
TIMER
___
24. UDP CHKSUM EN _
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
17. ICMP ERR CNT ___
25. UDP START PORT _____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
18. MTU ENABLE
_
26. UDP DEF TTL
___
1234567890123456789012345678901212345678901234567890123456789
19. MTU DISC
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
20. OVLD TRIG
__
ARP PARAMETER ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
27. REFRESH INTRVL ___
1234567890123456789012345678901212345678901234567890123456789
TCP PARAMETER ASSIGNMENT
28. CLEANUP INTRVL ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
21. TCP MSS
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
22.
TCP
START
PORT
_____
29. PM GROUP ________
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
23. TCP DEF TTL
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
4-15
Issue 3, March 2006
5ESS DCS OA&M
Figure 4-10 RC View 33.1 (NAR): Internet Protocol (IP) Processor Assignment 3
of 3
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
SCREEN
3
OF
3
RECENT
CHANGE 33.1
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5987)
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#32. ICMP ERR GEN
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#33.
IP
FRAGMENT
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#34. MTU INTVL AFT FAIL ____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
RC View 33.3
Figure 4-11 RC View 33.3 (NAR): IP Processor Routing to Interface
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
RECENT CHANGE 33.3
1234567890123456789012345678901212345678901234567890123456789
(5989)
INTERNET PROTOCOL (IP) ROUTING TO INTERFACE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. DEST IP ADDR
___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
*6. INTERFACE NAME ___________________
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
7. NET OR HOST
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
8. IP SUBNET MASK ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
#13. GATEWAY IP ADDR ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
18. ROUTE METRIC
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
RC View 33.4
Figure 4-12 RC View 33.4 (NAR): IP Interface Assignment 1 of 2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN
1
OF
2
RECENT
CHANGE 33.4
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5995)
ETHERNET INTERNET PROTOCOL (IP) INTERFACE
1234567890123456789012345678901212345678901234567890123456789
ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. SM
___
1234567890123456789012345678901212345678901234567890123456789
*2. PSU
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*3.
SHELF
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*4. CHANNEL GROUP __
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#5. INTERFACE NAME ___________________
1234567890123456789012345678901212345678901234567890123456789
6. PHE LINK
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-16
5ESS DCS OA&M
Figure 4-13 RC View 33.4 (NAR): Ethernet IP Interface Assignment 2 of 2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5ESS SWITCH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN
2
OF
2
RECENT
CHANGE 33.4
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
(5995)
1234567890123456789012345678901212345678901234567890123456789
ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#7. GATEWAY IP ADDRESS 1 ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
#12. IP SUBNET MASK 1
___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
17.
GATEWAY
IP
ADDRESS
2
___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
22. IP SUBNET MASK 2
___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
27. MCAST ADDR ___.___.___.___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
32. MTU SIZE
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
33. RATE
____
1234567890123456789012345678901212345678901234567890123456789
34. MODE
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
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-090
4-17
Issue 3, March 2006
5ESS DCS OA&M
Figure 4-14 RC View 9.37 (INTL): Protocol Handler Group Definition 1 of 2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN 1 OF 2
RECENT CHANGE - 9.37 PHGRP
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
PROTOCOL
HANDLER
GROUP DEFINITION
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. SM
___
#13. L1 OVRLD
1234567890123456789012345678901212345678901234567890123456789
THRESHOLD
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*2.
PSU
_
#14. L2 OVRLD
1234567890123456789012345678901212345678901234567890123456789
THRESHOLD
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*3. PH GROUP
__
#15. CONN CHK
1234567890123456789012345678901212345678901234567890123456789
ENABLED
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#4. APP TYPE
________
#16. CONN CHK
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
INTRVL
__
1234567890123456789012345678901212345678901234567890123456789
#17. CONN CHK INTRVL
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
LOW
___
1234567890123456789012345678901212345678901234567890123456789
5. PROTOCOL HANDLERS
#18. CONN CHK MAX
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
FAIL
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SHELF CHL GRP POSITION PH TYPE
#19. SW OVR
1234567890123456789012345678901212345678901234567890123456789
TIMER
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1)
_
__
__
____
#20. DIFF SVR CODE
1234567890123456789012345678901212345678901234567890123456789
POINT
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
2)
_
__
__
____
#21. RCV ICMP MSG
1234567890123456789012345678901212345678901234567890123456789
THRHLD
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#22. INHIBIT CALL
1234567890123456789012345678901212345678901234567890123456789
PROC
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
&11. SECONDARY ADDR
___
23. DEBUG
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
FLAGS
________
1234567890123456789012345678901212345678901234567890123456789
#12. PKT BUS INTRVL
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
Figure 4-15 RC View 9.37 (INTL): Protocol Handler Group Definition 2 of 2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN 2 OF 2
RECENT CHANGE - 9.37 PHGRP
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP BACKHAUL PARAMETERS
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
24. BHA BASE UDP PORT
_____
1234567890123456789012345678901212345678901234567890123456789
25. BHA PRE UDP PORT
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
26.
BHA
QUALITY
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
27. BHA INACT TIMER
__
1234567890123456789012345678901212345678901234567890123456789
28. UDPMUX BUNDLE SZ
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
29. UDPMUX BUNDLE TMR 1
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
30. UDPMUX BUNDLE TMR 2
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-18
5ESS DCS OA&M
RC View 90.5
Figure 4-16 RC View 90.5 (INTL): IP Processor Assignment 1 of 2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN 1 OF 2
RECENT CHANGE - 90.5 IPPRC
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP PROCESSOR ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. PROCESSOR ID
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*2. PROCESSOR TYPE
__
1234567890123456789012345678901212345678901234567890123456789
+3. QUALIFIER 2
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
+4.
QUALIFIER
3
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5. IP ADDRESS
1234567890123456789012345678901212345678901234567890123456789
LOCAL IP ADDR
IP SUBNET MASK
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1)
___
___
___
___
___
___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
2) ___ ___ ___ ___ ___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
3) ___ ___ ___ ___ ___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
4) ___ ___ ___ ___ ___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
5) ___ ___ ___ ___ ___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
Figure 4-17 RC View 90.5 (INTL): IP Processor Assignment 2 of 2
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN 2 OF 2
RECENT CHANGE - 90.5 IPPRC
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP PROCESSOR ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP PARAMETER ASSIGNMENT
UDP PARAMETER ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
16.
REASSEM
TIMER
___
23.
UDP CHKSUM EN
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
17. ICMP ERR CNT
___
24. UDP START PORT
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
18. MTU ENABLE
_
25. UDP DEF TTL
___
1234567890123456789012345678901212345678901234567890123456789
19. MTU DISC
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
ARP PARAMETER ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
TCP PARAMETER ASSIGNMENT
26. REFRESH INTRVL
__
1234567890123456789012345678901212345678901234567890123456789
20. TCP MSS
____
27. CLEANUP INTRVL
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
21.
TCP
START
PORT
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
22. TCP DEF TTL
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
4-19
Issue 3, March 2006
5ESS DCS OA&M
RC View 90.6
Figure 4-18 RC View 90.6 (INTL): IP Processor Routing to Interface
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN 1 OF 1
RECENT CHANGE - 90.6 IPRTE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP ROUTING TO INTERFACE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. DEST IP ADDR
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*6.
INTERFACE
NAME
___________________
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
7.
NET
OR
HOST
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
8. IP SUBNET MASK
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
#13. GATEWAY IP ADDR
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
18.
ROUTE
METRIC
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
RC View 90.7
Figure 4-19 RC View 90.7 (INTL): IP Interface Assignment
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SCREEN 1 OF 1
RECENT CHANGE - 90.7 IPETH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
ASSIGNMENT
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*1. SM
___
33. RATE
___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*2. PSU
_
34. MODE
_
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*3. SHELF
_
#35. APP
1234567890123456789012345678901212345678901234567890123456789
TYPE
_____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
*4. CHANNEL GROUP
__
1234567890123456789012345678901212345678901234567890123456789
#5. INTERFACE NAME
___________________
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#6.
PHE
LINK
__
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
#7. GATEWAY IP ADDR 1
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
#12. IP SUBNET MASK 1
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
17.
GATEWAY
IP
ADDR
2
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
22.
IP
SUBNET
MASK
2
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
27. MCAST ADDR
___ ___ ___ ___
1234567890123456789012345678901212345678901234567890123456789
32. MTU SIZE
____
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
Backhaul server associations
A backhaul server association (BHA) is a UDPMux session between a BTS and a

BPH. The BHA is identified by the IP addresses of the BTS and BHS and the UDP
port number. BHA status can be verified using a poke command.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-20
ECPC
OA&M
.................................................................................................................................................................................................................................
Purpose
This section describes Recent Change and Verify forms that are new or have been
modified for IPBH on the ECP.
RC/V forms updated for IP Backhaul
The following forms are updated for IP Backhaul: ecp, apeqp, btseqp, cell2, and
cdmeqp. 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
.................................................................................................................................................................................................................................
401-710-090
4-21
Issue 3, March 2006
ECPC OA&M
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

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
See Text Recent Change and Verify Manual (Text RC/V), 401-610-038, and Database
Update, 401-610-036, for complete details about these forms, including population
rules.
ecp form
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-22
ECPC OA&M
Figure 4-20 RC/V form: ecp
btseqp form
The following fields are used for IPBH: Backhaul Mode per URC and Backplane
Serial Number (BPSN) per frame.
Figure 4-21 RC/V form: btseqp
.................................................................................................................................................................................................................................
401-710-090
4-23
Issue 3, March 2006
ECPC OA&M
Figure 4-22 RC/V form: btseqp
cell2 form
The cell2 form activates the IPBH feature, identifies the service option class (SOC),
associates the cells carriers to the SM/PSU/BHS, specifies data offload and provides
the DCS/BHS or 1X RNC/BHS used for data offload. The service option class (SOC)
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-24
ECPC OA&M
is display only. It is set to BOTH when data offload is n. It is set to VOICE when
data offload is y, since the carriers listed will only handle the voice traffic.
Figure 4-23 RC/V form: cell2
.................................................................................................................................................................................................................................
401-710-090
4-25
Issue 3, March 2006
ECPC OA&M
This screen for CDMA Cell Site IP Backhaul Information identifies IPBH parameters
per cell site.
Figure 4-24 RC/V form: cell2
This form identifies when the IPBH feature is enabled for the cell and when data
traffic 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 this
form.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-26
ECPC OA&M
This form identifies the CRCs for the Mod 1,2,3 cells:
Figure 4-25 RC/V form: cdmeqp
See Text Recent Change and Verify Manual (Text RC/V), 401-610-038, and Database
Update, 401-610-036, for complete details about these forms, including population
rules.
apeqp form
The apeqp form is used to enable RCS-IP services on a specific AP pair
.................................................................................................................................................................................................................................
401-710-090
4-27
Issue 3, March 2006
RCI-IM Exists
ECPC OA&M
is set on a single AP pair with the command script during install using
apappconfig.
Figure 4-26 RC/V form: apeqp
The apeqp form is also used to enable RCS Flexible Sparing. See Flexent Wireless
Networks Cell Reliability and Engineering Improvements for IPBH RCS APs - Delivery
of Flexible Sparing Phase 1,, 401-612-830. for details on that feature.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-28
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 a
high-level overview of commands that support IPBH and does not cover all IPBH
commands and resulting output. Itemizing all new commands is beyond the scope of
this document. It is intended to help you identify critical commands to use in managing
your iPBH network. It is assumed that the user is familiar with the purpose of
commands used in a Lucent Technologies network.
Overview
IPBH input and output messages can be viewed through user interfaces and ROP
printouts.
See the following documents for detailed information on these new and modified I/O
messages for IPBH:
Flexent /Autoplex Wireless NetworksInput Messages Manual, 401-610-055

Flexent /Autoplex Wireless Networks Flexent/Autoplex Wireless Networks
Output Messages Manual, 401-610-057
5ESS Switch Flexent /Autoplex Wireless Networks Applications Input/Output
Messages, 235-600-700/750
5ESS Switch Flexent /Autoplex Wireless Networks Applications Applications
OA&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 use
of variables for the command message.
Important! All LOCK, UNLOCK, SHUTDOWN, and GET commands in are only available
via TPUCLI from the AP supporting the 1X RNC.
New inputs
.................................................................................................................................................................................................................................
401-710-090
4-29
Issue 3, March 2006
Table 4-3
Command
Syntax
TICLI
TI
ALW:CELL-MLG
ALW:CELL a, CP, CDM b, MLG
Allow the specified Multi-Link Group (MLG) to resume handling

traffic.
DUMP:CELL-AUTH-FAIL
DUMP:CELL,AUTH,FAIL
Request Backhaul Connection Server (BHCS) to generate a list of the

Base Transceiver System(s) (BTS) that have failed authentication.
INH:CELL-MLG
INH:CELL a, CP, CDM b, MLG c [,UCL]
IP Backhaul groups multiple Digital Signal Level 1 (DS1) signaling

links into a single large pipe called a Multi-Link Group (MLG) for
Backhaul transport of signaling and user traffic packets to a cell. This
increases capacity and decreases latency. Each MLG consists of one or
more DS1 facilities per Universal Radio Controller (URC). This
command inhibits traffic for the specified MLG.
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 assemblage
and each IPBH cell.
OP:BHS-CELL
OP:BHS;CELL a
Requests the status of the Backhaul Servers (BHSs) associated with the
requested cell. The report includes status and location information for
all BHSs provisioned on the cell2 RC/V form for both voice and data
traffic.
OP:CELL-CSB
OP:CELL a, CSB
Requests the Carrier Service Option Class [SOC] Backhaul Server

[BHS] (CSB) connectivity for the specified cell. The information
obtained reflects a summary of the health of the connection between
the cell and each BHS used for voice or data traffic on a per-carrier
basis.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-30
Table 4-3
(continued)
Command
Syntax
TICLI
TI
OP:DCS-BHSSTAT
OP:DCS a [, SM b], BHSSTAT
Requests the status of all or requested Backhaul Server (BHS) units at

the Digital Cellular Switch (DCS). Status includes maintenance state,
overload state, blocking state, etc.
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.
UPDATE:AP-BPSN
UPDATE:AP y,BPSN
Request to update the Back Plane Serial Numbers (BPSNs) for each
cell configured on the specified Application Processor (AP), to be
updated in the database prior to converting to Internet Protocol (IP)
Backhaul. If possible, the BPSNs are retrieved from each cell for all
the 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 the
BPSNs and the source of the BPSN data (cell or database).
UPDATE:CELL-BPSN
UPDATE:CELL x,BPSN
Requests the BPSNs for the specified cell to be updated in the

database.
See Flexent /Autoplex Wireless Networks Input Messages Manual, 401-610-055 for
complete details.
Modified inputs
Table 4-4
Modified inputs
Command
Syntax
TICLI
TI
ABT:VCA-AUD
ABT:VCA, AUD a
where a = BHMDB Backhaul

Manager (BHM) database audit
.................................................................................................................................................................................................................................
401-710-090
4-31
Issue 3, March 2006
Table 4-4
Modified inputs
(continued)
Command
Syntax
TICLI
TI
ALW:VCA-AUD
ALW:VCA, AUD a where a =

BHMDB Backhaul Manager
(BHM) database audit
AUD:VCA-NAME
AUD:VCA, NAME a where a =

GET:RNC-TPU-STATE
GET:RNC a, TPU b, GICC i,
IPBTSGW, STATE
INH:VCA-AUD
This command is only available via TPUCLI

from the AP supporting the RNC.
x
INH:VCA, AUD a where a =

INIT:VCA
INIT:VCA:SPP a where a = bhm
Backhaul Manager (BHM)
LOCK:RNC-TPU
LOCK:RNC a, TPU b, GICC c,
IPBTSGW
OP:CELL

x
OP:CELL xxx CDM a, MLG b

SHUTDOWN:RNC-TPU
SHUTDOWN:RNC a, TPU b, GICC
c,IPBTSGW
UNLOCK:RNC-TPU
UNLOCK:RNC a, TPU b, GICC c,
IPBTSGW

See Flexent /Autoplex Wireless Networks Input Messages Manual, 401-610-055 for
complete details.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-32
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.
See Flexent /Autoplex Wireless Networks Output Messages Manual, 401-610-057 for
complete 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 cell

site Multiple Link Group (MLG) unit.
DUMP-CELL-AUTH-FAIL
The Backhaul Connection Server (BHCS) generates a

list of cells that have failed authentication in response
to the DUMP:CELL-AUTH-FAIL input command.
INH-CELL-MLG
Reports the completion codes for the inhibit of a cell

site Multiple Link Group (MLG) unit.
OP-AP-IPBHINFO
Reports the IP address and BPSN of an RCS with IP

services enabled.
OP-BHS-CELL
Provides the status of the Backhaul Servers (BHSs)

associated with the requested cell. The report includes
status and location information for all BHSs
provisioned on the cell2 RC/V form for both voice and
data traffic.
OP-CELL-CSB
Report the Carrier Service Option Class [SOC]

Backhaul Server [BHS] (CSB) connectivity for the
specified cell. The information obtained reflects a
summary of the health of the connection between the
cell and each BHS used for voice or data traffic on a
per-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 report

when an IP address conflict is detected between two or
more Backhaul Servers (BHSs). BHM will change the
maintenance state of the conflicting BHSs to
unavailable. The report is generated immediately when
the IP address conflict is detected and periodically
thereafter until the conflict is resolved.
.................................................................................................................................................................................................................................
401-710-090
4-33
Issue 3, March 2006
Table 4-5
New outputs
(continued)
New output
Purpose
REPT-BHS-STATUS
The Backhaul Manager (BHM) generates a report

when the status for a Backhaul Server (BHS) changes.
The change may result from an update received from
the RNC or DCS where the BHS is located, or it may
result from a change in status maintained on the ECP
and reported to the appropriate DCS or RNC. This
report will reflect a change to the BHS maintenance
state or to the BHS overload state.
REPT-CELL-AUTH-FAIL
The Backhaul Connection Server (BHCS) generates a

list of cells that have failed authentication. This output
prints at a regularly scheduled interval as determined
by the BHCS Failure Reporting Interval field on the
Internet Protocol (IP) Backhaul Information Only
screen of the ecp RC/V form.
UPDATE-AP-BPSN
This message is generated as a result of the successful

execution of the UPDATE:AP,BPSN input command.
There will be one line of output for each assemblage
of each cell equipped on the specified Application
Processor (AP). The output will include the cell
number, assemblage, Back Plane Serial Number
(BPSN) and an explanation of the action that took
place for that assemblage.
UPDATE-CELL-BPSN
This message is generated as a result of the successful

execution of the UPDATE:CELL-BPSN input
command. There will be one line of output for each
assemblage of a cell. The output will include the cell
number, assemblage, Back Plane Serial Number
(BPSN) and an explanation of the action that took
place for that assemblage.
Modified outputs
Table 4-6
Modified outputs
Command Name
AUD-VCA-NAME-E-C
AUD-VCA-NAME-E-N
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-34
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. Itemizing
all new commands is beyond the scope of this document. Please refer 5ESS Switch
Flexent /Autoplex Wireless Networks Applications Input/Output Messages,
235-600-700/750 for complete details on these messages.
.................................................................................................................................................................................................................................
401-710-090
4-35
Issue 3, March 2006
Table 4-7
Input
Output
ALW:HDW
None.
Allows hardware checks on a packet switch unit

(PSU) protocol handler (PH).
EXC:PING
Requests verification of the transmission control

protocol/internet protocol (TCP/IP) connection
between the source internet protocol (SRCIP)
address and the internet protocol destination
(IPDEST) address.
EXC:TRACEROUTE
To trace the route to an IP destination from a given

IP source.
INH:HDWCHK
Inhibits a switch to the standby administrative

module (AM) control unit when a fault occurs in
the active AM control unit.
OP:BHA,PSU=a-b[,SUM];
Requests the backhaul association (BHA) related

information of a specified backhaul protocol handler
(BPH) or summary BHA information of all the
BPHs in a packet switch unit (PSU).
OP:CONV-PHGRP
Outputs PING information that is sent from

an SM, PH, or optical interface unit (OIU).
Outputs information to trace the route to an

IP destination from a given IP source.
Reports the following:
PH IMAGE TYPE
SOURCE IP
DESTINATION IP
BYTES SENT
HOPS
TIMEOUT DURATION
TRACE TIMEOUTS
Indicates the result of a request to inhibit

administrative module (AM) hardware checks.
Reports the BHA related information of a

specified BPH or summary BHA information
of all the BPHs on a PSU.
Reports PHGRP conversion data.
To report protocol handler (PH) group (PHGRP) conversion data.

OP:IPCFG
Requests the output of IP address and subnet mask

configuration information for specified characteristics
provided in the command.
Reports the IPCFG information collected for an

OP:IPCFG request.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-36
Table 4-7
(continued)
Input
Output
OP:TCPIP:ARPDMP,CHNG=a-b-c-d;
Reports the ARP information contained in the

PH.
Requests the TCP/IP address resolution protocol

(ARP) cache input message to show the ARP cache
entries of a protocol handler
(PH). OP:TCPIP:RTDMP,CHNG=sm-psu-shlf-ph;
RMV:PSUPH
Requests that a packet switch unit (PSU) protocol

handler (PH) be removed from service.
RST:PSUPH
Requests that a packet switch unit be restored to

service.
Indicates the result of an RMV:PSUPH input

message to remove a packet switch unit
(PSU) protocol handler (PH) from service.
Indicates the result of an RST:PSUPH input
message to restore a packet switching unit
protocol handler (PH) to service.
See 5ESS Switch Flexent Autoplex Wireless Networks Applications Input/Output

Messages, 235-600-700/750 for complete details on these messages.
.................................................................................................................................................................................................................................
401-710-090
4-37
Issue 3, March 2006
Status
display pages
.................................................................................................................................................................................................................................
ECPC status display pages
This section describes the new and changed status page. It is assumed that you are
familiar with the use of the SDP pages and the color coding for status: Available =
green, Unavailable = red, Degraded = yellow, and Indeterminate = white.
See Flexent /Autoplex Wireless Networks ECP OA&M and SDP Maintenance
Control Procedures, 401-610-160 for detailed information.
Table 4-8
SDP Page
New or
Modified
Description
SDP 2101
New
APX Index Page II- New index page added for BHS
status pages.
SDP 2131
Modified
Cell Equipment Status Page modified to add

indicator of IPBH feature status.
SDP 2138
Modified
Cell CDM Status Page modified to add MLG-BHS

Association status and remove Packet Pipe
information.
SDP 2236
New
displays carrier/SOC-BHS for both voice and data

consisting of:
Carrier ID and channel number.
SOC type: Voice or Data.
Voice and Data traffic status.

SOC status Available, Unavailable, Degraded
and Indeterminate.
Blocking state is also displayed: B = block all

new calls and soft handoffs due to critical
overload, b = block all new calls due to major
overload.
BHS ID (DCS) consisting of the

DCS/SM/PSU/BHS numbers.
BHS ID (RNC) consisting of the RNC/BHS

numbers.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-38
Table 4-8
(continued)
SDP Page
New or
Modified
Description
SDP 2237
New
displays MLG information for each actively

displayed CRC:
SDP 2260
New
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 does
not have an equipped DS1, it uses the parent
MLG.
SDP 2260 is a new page that displays the BHS

status for each SM on a DCS.
Note: The lower left corner provides a summary
view of the BHS status for each SM. If any BHS in
an SM is in an off-normal state (maintenance state
unavailable or load state critical or major), then the
specified SM will be marked TROUBLE (white text
with red background). If not, the SM number will be
marked as NORMAL (white text with black
background).
SDP 2265
New
SDP 2265 is a new page that displays the BHS

status for each RNC.
Note: The lower left corner provides a summary
view of the BHS status for each RNC. If any BHS
on an RNC is in an off-normal state (maintenance
state unavailable or load state critical), then the
specified RNC will be marked TROUBLE (white
text with red background). If not, the RNC number
will be marked as NORMAL (white text with black
background).
.................................................................................................................................................................................................................................
401-710-090
4-39
Issue 3, March 2006
SDP 2101 - APX Index Page II
This page has been modified for IPBH.

Figure 4-27 SDP 2101
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-40
SDP 2131 - Cell Equipment Status Page
This page has been modified to indicate whether or not IP Backhaul is enabled for the
cell 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 physically
located on the URC.
When IPBH is enabled on the cell2 form, the following information is provided on
SDP 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-090
4-41
Issue 3, March 2006
The status:
greenif all IP_BHA are available for that URC
redif all IP_BHA are unavailable for that URC

yellowif at least one IP_BHA is unavailable and at least one IP_BHA is
available 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-090
Issue 3, March 2006
4-42
BHS_ID (RNC) include RNC# (1-15), BHS# (1-3)
The status of Carrier-SOC-BHS (available - green, unavailable - red, degraded yellow, indeterminate - black)
Figure 4-30 Status display page: 2236
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
.................................................................................................................................................................................................................................
401-710-090
4-43
Issue 3, March 2006
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-090
Issue 3, March 2006
4-44
SDP 2260 - DCS BHS STATUS
This page displays BHS status for both voice and data for DCS BHSs consisting of
one 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 any
BHSs in one RNC are in off-normal state (Maintenance state unavailable or Load state
critical or major), then the specified RNC will be marked as TROUBLE (White text
.................................................................................................................................................................................................................................
401-710-090
4-45
Issue 3, March 2006
with red background). If not, the RNC number will be marked as NORMAL (White
text with black background).
5ESS DCS status pages
MCC 1188 is accessed via poke 1188,psu,sm

The following information is available:
The PH group number on the 1188 is the same as the BHS number on the ECP
SDP 2260 and 2236 and the cell2 form.
Each PH group consists of 2 PHs listed by shelf and slot number, horizontally
across 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 and
BHSSTAT output messages.
If at least 1 PH in the row is ACT/SERV, then the BHS is reported available in the
ECP 2260 and BHSSTAT output messages.
If both PHs in a row are OOS, then the ECP reports the BHS as unavailable.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-46
If a BHS used for data offload is unavailable and there is an alternate BHS
provisioned on the cell2 form for a cell, the alternate BHS will be used for future
data calls using that cell.
If a BHS used for data offload is available, but in overload, the primary BHS
provisioned on the cell2 form for a cell will continue to be used for future data
calls.
The MCC 1188 page has been added:

Figure 4-34 5ESS-DCS PHGRP status page: MCC 1188
See 5ESS Switch Flexent /Autoplex Wireless Networks Applications OA&M

Manual, NAR 235-200-100 for detailed information.
.................................................................................................................................................................................................................................
401-710-090
4-47
Issue 3, March 2006
OMC-RAN
Monitor
IPBH from the OMC-RAN
.................................................................................................................................................................................................................................
OMC-RAN for IPBH
The Operations and Maintenance Center Radio Access Network (OMC-RAN) is a

comprehensive Graphical User Interface (GUI)-based Operations, Administration and
Maintenance (OA&M) platform that provides OA&M capabilities for a Flexent
wireless 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 monitoring
information to a centralized Operations Support System (OSS).
The OMC-RAN uses an existing Internet Protocol (IP) operations network to

communicate with entities such as the Network Operations Center (NOC), client
terminals, such as desktop PCs, workstations and laptops. A providers IP network is a
private Internet Protocol Wide Area Network (IP-WAN) that links the customers
Central Offices (COs) together.
OMC-RAN configuration
See Flexent Wireless Networks Operations and Maintenance Center Radio Access
Network (OMC-RAN) Operations, Administration & Maintenance, 401-662-105 for
information on planning for OMC-RAN.
The OMC-RAN can be installed in your network either prior to or following the
installation of an IPBH network.
When the IPBH network is configured, the IPBH screens and configuration information
appears 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 on
the OMC-RAN screens. However, you can also do configuration from the OMC-RAN.
See Flexent Wireless Networks Operations and Maintenance Center Radio Access
Network (OMC-RAN)Planning Operations, Administration & Maintenance,
401-662-105 for complete information about OMC-RAN.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-48
OMC-RAN user interface
Information is displayed on the existing BTS overview page.

Figure 4-35 OMC-RAN BTS Overview - server=Lab#
.................................................................................................................................................................................................................................
401-710-090
4-49
Issue 3, March 2006
Select server/Lab#/ORCA/Group.BTSGroup/BTS#/BTS to display this page:

Figure 4-36 OMC-RAN Network Manager - IPBH Enabled information
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-50
Select server/Lab#/ORCAGroup/BTSGroup/BTS#/SocList to display this page:

Figure 4-37 OMC-RAN Network Manager - IPBH SocList
.................................................................................................................................................................................................................................
401-710-090
4-51
Issue 3, March 2006
Select server/Lab#/ORCAGroup/BTSGroup/AssemblTable display this page for the

selected BTSGroup:
Figure 4-38 OMC-RAN Network Manager - IPBH BPSN
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
4-52
Select server/Lab#/ORCAGroup/BTSGroup/AssemblTable display this page for the

selected BTSGroup:
Figure 4-39 OMC-RAN Network Manager - IPBH BPSN
.................................................................................................................................................................................................................................
401-710-090
4-53
Issue 3, March 2006
F ault management
5
Overview
.................................................................................................................................................................................................................................
Purpose
This chapter discusses fault management functions in a network using IP backhaul.

Contents
Network monitoring
5-3
Fault management
5-3
5-5
5-7
5-10
Cable faults
5-14
5-14
5-17
5-20
Bad DS1 cable
5-24
5-27
Cable cut on serving IPBTS GW GigE interface - Standby GigE

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

out-of-service
5-37
5-41
5-45
5-45
.................................................................................................................................................................................................................................
401-710-090
5-1
Issue 3, March 2006
Fault management
Overview
5-48
5-51
5-55
5-59
5-63
5-66
5-70
5-73
5-76
5-76
5-79
One DS1 in MLG is not configured in ER, or wrong DS1 is assigned to

MLG in ER
5-83
5-86
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-2
Fault management
Network monitoring
Fault
management
.................................................................................................................................................................................................................................
Definition
Fault management (FM) is a set of functions that enables the detection, isolation and
correction of abnormal operation of the telecommunication network and its
environment.
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 network

elements 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 NE

and no hardware component has been
detected as faulty.
Overload conditions
Loss of some or all of the specified

capabilities of an NE due to high resource
usage conditions
Quality of service failures
Failures to meet the given threshold

values.
Communication failures
Communication failures between NEs, or

between the NE and the operating system
(OS), or between OSs.
.................................................................................................................................................................................................................................
401-710-090
5-3
Issue 3, March 2006
Fault management
Fault management
Fault localization
Fault localization determines the root cause of a fault.

Information obtained by additional failure localization routines must be added when the
initial failure information is insufficient for fault localization. The routines can employ
internal or external test systems and can be controlled by a Local Maintenance
Terminal (LMT).
Fault correction
Fault correction takes the appropriate action to correct a fault once the root cause has
been identified.
It transfers data concerning the repair of a fault and for the control of procedures that
use 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 out
by directly accessing the relevant functionality of the NE using the LMT to help you
analyze the problem.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-4
Fault management
General
problem solving model
.................................................................................................................................................................................................................................
Description
The general problem solving model represents a model that can be used as a general
approach for each troubleshooting situation.
Process
The stages for the general problem solving model process are:
.................................................................................................................................................................................................................................
401-710-090
5-5
Issue 3, March 2006
Fault management
.................................................................................................................................................................................................
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 ascertain
what kinds of problems (causes) could result in these symptoms.
.................................................................................................................................................................................................
Gather the facts.

Fact gathering might involve:
Collecting information from affected users, network administrators, managers, and

other key people
Collecting information from sources such as network management systems,
protocol analyzer traces, serial line traces, stack dumps or software release notes.
.................................................................................................................................................................................................
Consider the possibilities.

This might involve:
Eliminating causes.
Narrowing the number of potential causes.
.................................................................................................................................................................................................
Create an action plan.

The action plan will be based on the remaining potential causes.
.................................................................................................................................................................................................
Implement the action plan.

.................................................................................................................................................................................................
Observe the results.

.................................................................................................................................................................................................
If...
then...
the problem has not been solved,
return to Step 2.
Result
Process complete.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-6
Fault management
Network
monitoring and fault detection
.................................................................................................................................................................................................................................
Reference diagram
Figure 5-1, Network monitoring (p. 5-7) diagram is referenced throughout this
chapter.
Figure 5-1 Network monitoring
Host interfaces
All hosts on the IP backhaul network (URCs, BHSs, and RCS-APs) continuously
monitor and report the health of all their interfaces through MSC operation,
administration and maintenance (OA&M) systems. This information is displayed on
SDP pages, NE GUI pages and as output to the ROP. When the OMC-RAN is part of
the IPBH network, some health events are also reported to the OMC-GUI.
.................................................................................................................................................................................................................................
401-710-090
5-7
Issue 3, March 2006
Fault management
URC interfaces
Each URC continuously updates its RCS with the status of all its DS1s. RCS requires
real-time knowledge of DS1 status in order to perform its call leg admission control
function and DS1 alarms and technician output reports.
In addition to admission control, RCS makes the DS1 status information available
through 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 and
its ability to communicate with its gateway router. The status of each BHS interface is
reported and alarmed through 5ESS DCS and 1X RNC OA&M. The ECPC sees only
the 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 LAN
and the MSC adjacent switches, are continuously monitored and reported through
ECPC OA&M. All link faults are alarmed. In addition, each RCS-AP continuously
monitors its ability to communicate with both gateway routers configured for the
control 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-APs
continues to be reported on status display page 2131 (SDP 2131) and associated output
reports. There are multiple physical paths between a URC and an RCS-AP. As long as
there is a healthy connection over any one of the physical paths then the status of the
end-to-end connection is green. URC-RCS connectivity is independent of RCS
maintenance state.
URC-BHS connectivity
Each URC monitors end-to-end connectivity to all the BHSs that are assigned to serve
call legs on that URC. This URC-BHS connectivity status is available on SDP 2236
and associated technician output report.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-8
Fault management
Router status
The status of the backhaul routers, all inter-router links and all host interfaces (from
the point of view of the routers) is available through the router network management
system (RNMS) as indicated in Figure 5-1, Network monitoring (p. 5-7).
.................................................................................................................................................................................................................................
401-710-090
5-9
Issue 3, March 2006
Fault management
Sample
section: Identified fault
.................................................................................................................................................................................................................................
Format of sample
The following sample sections identify the layout of the troubleshooting pages and
describe the contents of each section.
Each fault is described for an environment that assumes the system is in stable and
operational 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 the
fault.
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 that
no manual intervention is required to resolve the fault.
Other indications
Information in this block lists possible other indicators that may accompany the fault.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-10
Fault management
Fault detection and automatic recovery
The alarms, notifications and automatic recovery actions are identified by network
element (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 interface
for the NE.
Automatic recovery actions: Automatic actions that are initiated when the fault is
detected.
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
BTS
Identifiable fault on the NE.
Alarm or notification
on NE interface.
Automatic recovery
action on NE.
Router
Management:
on NE interface.
Automatic recovery
action on NE.
Edge Router
on NE interface.
Automatic recovery
action on NE.
MLS
on NE interface.
Automatic recovery
action on NE.
Transport Network
Mobile Switching Center

FMM-APs
on NE interface.
Automatic recovery
action on NE.
RCS
on NE interface.
Automatic recovery
action on NE.
RCS
on NE interface.
Automatic recovery
action on NE.
SDP ####:
ROP:
5ESS DCS
on NE interface.
Automatic recovery
action on NE.
1188 MCC:
118 [0-4]:
ROP:
1X RNC
on NE interface.
Automatic recovery
action on NE.
TPU-GUI:
.................................................................................................................................................................................................................................
401-710-090
5-11
Issue 3, March 2006
Fault management
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
OMP-FX
on NE interface.
Automatic recovery
action on NE.
EMS:
OMC-RAN
on NE interface.
Automatic recovery
action on NE.
OMC-GUI:
Other Indications
Message or report through

another medium than user
interface, such as technician
interface (TI).
Message or report
through another
medium than user
interface, such as
technician interface
(TI).
Message or report
through another
medium than user
interface, such as
technician 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 of
actions 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
Edge Router
MLS

FMM-APs
RCS
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-12
Fault management
Network Element
ECP
SDP ####:
ROP:

5ESS DCS
1188 MCC:
118 [0-4]:
ROP:

1X RNC
TPU-GUI:

OMP-FX
EMS:

OMC-RAN
OMC-GUI:

Other Indications
.................................................................................................................................................................................................................................
401-710-090
5-13
Issue 3, March 2006
Fault management
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.

element (NE):
for the NE.
detected.
Network element
Fault detection
Alarms and notifications
Automatic
recovery
BTS
Detects DS1 LOS and

removes the DS1 from the
MLG.
No impact.
Removes DS1
from MLG.
Transport Network
Reflects DS1
interface/sub-interface
OperStatus down.
Router
Management
Edge Router
Detects loss of Layer 2.

Removes the DS1 from the
MLG.
Removes DS1
from MLG.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-14
Fault management
Network element
Fault detection
Automatic
recovery
MLS
No impact.
No impact.
No impact.

FMM-APs
No impact.
No impact.
No impact.
RCS
Receives bandwidth change

notification from the BTS.
No impact.
No impact.
RCS
See SDP and ROP ==>
SDP 2138: Shows Critical
Updates SDP and

TI.
Alarm.
SDP 2237: Shows that this
DS1 is not in any MLG.

ROP: Shows Critical Alarm
for bandwidth change but

not the type of alarm.
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 Critical
No impact.
Alarm on AP detailed view.

OP:ALARM
Other Indications
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.

.................................................................................................................................................................................................................................
401-710-090
5-15
Issue 3, March 2006
Fault management
Network Element
BTS
Restores DS1 to MLG.

Sends MLG bandwidth change and MLG DS1 association
change 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 DS1
association change.
ROP: Reports an alarm clear message that shows The MLG
BW 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-090
Issue 3, March 2006
5-16
Fault management
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.
element (NE):
for the NE.
detected.
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
BTS
Detects yellow alarm

condition.
No impact.
Removes DS1 from the

MLG.
Removing TI from the MLG
ensures that performance is
not impacted, but capacity is
impacted.
Transport Network
Reflects DS1
OperStatus down.
Router
Management
Edge Router
Detects red alarm

condition.
MLS
No impact.
Removes DS1 from the

MLG.
No impact.
No impact.

.................................................................................................................................................................................................................................
401-710-090
5-17
Issue 3, March 2006
Fault management
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
Alarm or notification on
NE interface.
No impact. See ECP (below).
ECP
See SDP and TI ==>
SDP 2138: Shows

Critical Alarm.
Updates to SDP and TI.
SDP 2237: Shows DS1s
not in any MLG.

ROP: Receives Critical
Alarm. Text shows

critical alarm but not
alarm type.
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
See OMC-GUI ==>
OMC-GUI: Shows
No impact.
Critical Alarm on AP
Detailed view.
OP:ALARM
Other
Indications
OP:CELL

Subsequent alarms: None.
Fault resolution
Technician corrects DS1 problem.

.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-18
Fault management
Network Element
BTS
Restore DS1 to MLG.

Sends MLG bandwidth change and MLG-DS1 association
change messages.
Transport Network
Router Management
Router Management: Reflects DS1 interface/sub-interface
OperStatus up.
Edge Router
Detects that signal is good, and adds the DS1 back into the
MLG.
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 shows
DS1 back to the MLG.
ROP: Receives alarm clear message, notification of MLG
bandwidth 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-090
5-19
Issue 3, March 2006
Fault management
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.

element (NE):
for the NE.
detected.
Network
element
Fault detection
Automatic recovery
BTS
Detects LOS on the

DS1.
Detects LOS on the DS1.
The URC will attempt

to re-establish to its own
MLG for up to 3
minutes. If it cannot,
URC will re-establish
with MLG from another
URC in the same
assemblage and send
RCS SL bandwidth
change for the parent
URC.
Transport Network
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-20
Fault management
Network
element
Fault detection
Automatic recovery
Reflects DS1
OperStatus down. Line
status reflects loss of signal.
Router
Management
Edge Router
Reflects MLG is OOS.
Removes DS1 from LG

and marks MLG as
OOS.
MLS
No impact.
No impact.
No impact.

FMM-APs
No impact.
No impact.
No impact.
RCS
Detects Loss of
Heartbeat after 24
seconds and put the
URC out of service.
Signaling Link will be
re-established. Original
MLG association will
change to use another
URCs MLG.
No impact.
Signaling is
re-established. Original
MLG association will
change to use another
URCs MLG. After the
signaling link is
established again to the
shared MLG, the
information will be sent
to the RCS. Receive SL
bandwidth change from
BTS.
ECP
See SDP and ROP ==>
SDP 2131: shows SL OOS for
Updates to SDP and TI -
URC
SDP 2237: R26 and

Later shows
Parent/Child
relationship.
SDP 2138: shows CRC OOS

SDP 2237: shows CRC OOS
SDP 2236: shows SOC
degraded for OneBTS and

OOS for URC Modular Cell.
ROP: Receives OOS on URC
message and NO CRC
HEARTBEAT message.
5ESS DCS
No impact.
No impact.
SDP 2131: shows - Child

URC with SH for
signaling link status.
No impact.
ROP: Will output an assert
for each lost BHA.

RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-21
Issue 3, March 2006
Fault management
Network
element
Fault detection
Automatic recovery
OMC-RAN
See OMC-GUI ==>
OMC-GUI: Shows URC is
No impact.
OOS on URC Detailed View.

Other
Indications
OP:ALARM
OP:ALARM
OP:CELL
OP:CELL

Subsequent alarms: Alarm sent to HEH is displayed on TI, SDP, ROP. OMC-RAN
Automatic 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.

Network Element
BTS
When MLG comes back it will be used for bearer traffic only.
To use the original MLG for signaling traffic, the URC will
not be rebooted.
Transport Network
Router Management
Reflects DS1 interface/sub-interface OperStatus up.Line

status reflects no alarm. Reflects MLG is in service.
Edge Router
Detects Layer 2, restores DS1 to MLG and restores MLG to

service.
MLS
No impact.

FMM-APs
No impact.
RCS
BTS notifies RCS that URC is available for bearer traffic and
the MLG Association has changed.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-22
Fault management
Network Element
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 bandwidth
change 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-090
5-23
Issue 3, March 2006
Fault management
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 detect
BER.
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) between
the BTS and the ER..
element (NE):
for the NE.
detected.
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
BTS
No detection.
No impact.
No impact.
Transport Network
May display
intermittent failures.
Router
Management
Edge Router
No detection.
No impact.
No impact.
MLS
No impact.
No impact.
No impact.
No impact.
No impact.

FMM-APs
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-24
Fault management
Bad DS1 cable
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
RCS
No impact.
May display
intermittent signaling
link failures.
No impact.
ECP
See SDP and ROP ==>
SDP: May receive a
No impact.
critical alarm if the

BER becomes worse,
for example 10^ -3
SDP 2138: shows
major alarm.
SDP 2237: Shows
which DS1s are

operational, which
DS1 (may) receive a
critical alarm and
show that this DS1 is
not in any MLG.
ROP: May receive
major alarm report.
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
See OMC-GUI:
OMC-GUI: may
No impact.
display an
intermittent major
alarm on the AP
Detailed View.
Other Indications
5ESS DCS TRFC30, section

153, IPBHSUP reports counts
that can be checked.
5ESS DCS TRFC30,

section 153,
IPBHSUP reports
counts that can be
checked.
NE impacts: None.
.................................................................................................................................................................................................................................
401-710-090
5-25
Issue 3, March 2006
Fault management
Bad DS1 cable
Subsequent service impact: None.
Fault resolution
Technician corrects DS1 (T1/E1) problem by installing a new DS1 between the BTS
and the ER..
Network Element
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 should
be displayed.
SDP 2237: Alarm clears. No intermittent minor alarms should
be displayed.
ROP: After problem is resolved, no additional reports on this
problem 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 longer

incrementing at the high rate previously seen.
Service impact
No more intermittent problems.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-26
Fault management
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.
element (NE):
for the NE.
detected.
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
BTS
No impact.
No impact.
No impact.
Transport Network
No impact.
Router
Management
Edge Router
MLS
Detect Loss of direct

connectivity to MLS.
Detects Loss of direct

connectivity to ER.
Shows ER and
MLS Ethernet
interfaces
OperStatus
down.
ER removes the interface to the

MLS from service.
See Router
Management.
MLS removes the interface to the

ER from service. MLS redirects
traffic to the other ER.
ER removes direct OSPF route

through the MLS, chooses an
alternate OSPF route through the
mate ER, and routes traffic
through the mate ER.
.................................................................................................................................................................................................................................
401-710-090
5-27
Issue 3, March 2006
Fault management
Network
element
Fault detection
Alarms and
notifications
Automatic recovery

FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
No impact.
No impact.
ECP
No impact.
No impact.
No impact.
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.
No impact.
No impact.
Other
Indications
ER and MLS send

linkDown trap.
ER and MLS send

linkDown trap.
NE Impacts: None.
Subsequent service impact: Change in delay characteristics.
Fault resolution
Technician repairs/reconnects cable.

Network Element
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.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-28
Fault management
Network Element
5ESS DCS
No impact.
1X RNC
No impact.
OMP-FX
No impact.
OMC-RAN
No impact.
Other Indications
ER and MLS send linkUp trap.
.................................................................................................................................................................................................................................
401-710-090
5-29
Issue 3, March 2006
Fault management
Cable cut on serving IPBTS GW GigE interface - Standby

GigE
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, some
new call setups or reactivations on the affected BTSs may fail before the RNC
recovers.
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 the
TPU-GUI. State change reports appear on the ROP.
Resolution
Install a new cable from the 1X RNC to the MLS.

element (NE):
for the NE.
detected.
Network
element
Fault detection
Automatic
recovery
BTS
See ROP ==>
No impact.
No impact.
Transport Network
Router
Management
Reflects MLS Enternet

interface OperStatus
down.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-30
Fault management

GigE in-service
Network
element
Fault detection
Automatic
recovery
Edge Router
No impact.
No impact.
No impact.
MLS
Detects loss of direct

connectivity to GICC.
No impact.
Receives a
gratuitous ARP
from the newly
active GW and
starts sending
packets to it

FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
No impact.
No impact.
ECP
See SDP, OMC-RAN, EMS

and ECP ROP ==>
SDP 2121: TRBL

indication on RNC summary
indicator.
SDP 2236:May
show an
intermittent
change in the
Carrier-SOC-BHS
status.
SDP 2236: May show
intermittent change in the

data SOC status.
ROP: Receives RNC report
for major alarm against
GigE. The BTS may report
loss of heartbeats depending
on how quickly the RNC
detects the failure.
5ESS DCS
No impact.
No impact.
No impact.
1X 1X RNC
Detects loss of ARP beating
TPU-GUI:
Performs
automatic failover
to standby IPBTS
GW.
GigE port alarm (major

alarm).
TPU alarm (major

alarm).
OMP-FX
No impact.
EMS: TPU Major alarm.
No impact.
OMC-RAN
No impact.
OMC-GUI: TRBL indication

on RNC Summary page.
Reports major alarms
against the TPU and the
GICC.
No impact.
Other Indications
There may be some

REPT-CPFAIL reports for
new call setups on the ROP.
None.
None.
.................................................................................................................................................................................................................................
401-710-090
5-31
Issue 3, March 2006
Fault management

GigE in-service
Network
element
Fault detection
States
RNC Serving IPBTS GW

state changes to
disabled/idle. This can be
viewed on the TPU-GUI.
State change reports appear
on the ROP.
Automatic
recovery
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 reports
appear on the ROP.
Fault resolution
Technician repairs the cable.

Network Element
BTS
No impact.
Transport Network
Router management
eflects MLS Ethernet inteface OpersStatusup.
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-090
Issue 3, March 2006
5-32
Fault management

GigE in-service
Network Element
OMP-FX
EMS: TPU alarm indicator may return to Normal.
OMC-RAN
OMC-GUI: GigE port alarm clears. RNC summary indicator
may return to Normal.

Other Indications
None.
States
Non-serving IPBTS GW operational state returns to

Enabled.
.................................................................................................................................................................................................................................
401-710-090
5-33
Issue 3, March 2006
Fault management
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.
element (NE):
for the NE.
detected.
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
BTS
No impact.
No impact.
No impact.
Transport Network
Reflects
MLSEthernet
down.
Router
Management
Edge Router
No impact.
No impact.
No impact.
MLS
Detects loss of
direct connectivity
to GICC.
No impact.
No impact.

FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
No impact.
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-34
Fault management
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
ECP
See impacts to
SDP, OMC-RAN,
EMS and ECP
ROP.
SDP 2121: TRBL
No impact.
indication on RNC
summary indicator.
ROP: Receives RNC
report on major
alarm against GigE.
5ESS DCS
No impact.
No impact.
No impact.
1X RNC
Detects loss of
ARP beating.
TPU-GUI: GigE port
None.
alarm (major alarm)

against the GICC.
OMP-FX
See EMS ==>
EMS: Reports TPU Major alarm.
No impact.
OMC-RAN
See OMC-GUI
==>
OMC-GUI: Shows
No impact.
TRBL indication
on RNC Summary
page. Reports major
alarms against the
TPU and the GICC.
Other
Indications
ER and MLS send

linkDown trap.
States
RNC Non-serving
IPBTS GW state
changes to
disabled/idle.
None.
NE impacts: None.
Subsequent device impact: None.
Fault resolution
Technician repairs the cable.

.................................................................................................................................................................................................................................
401-710-090
5-35
Issue 3, March 2006
Fault management
Network Element
BTS
No impact.
Transport Network
Router Management
Reflects MLS Ethernet interface OperStatus up.
Edge Router
No impact.
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 alarm
indicator may return to normal.

OMP-FX
EMS:TPU alarm indicator may return to Normal.
OMC-RAN
OMC-GUI: GigE port alarm clears. RNC summary indicator
may return to Normal.

Other Indications
None.
States
Non-serving IPBTS GW operational state returns to Enabled.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-36
Fault management

GigE
out-of-service
.................................................................................................................................................................................................................................
Loss of Layer 2 detected by the serving IPBTS GICC. Non-serving IPBTS GICC is
out-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 fail
before the BTSs establish connections with the alternate BHSs.
Resolution

element (NE):
for the NE.
this fault event, the order of recovery is identified.
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
BTS
BHAs time-out and calls are

dropped.
No impact.
3. Establish new
BHAs with
alternate BHSs.
Transport Network
Router
Management:
Reflects MLS Ethernet

down.
Edge Router
No impact.
No impact.
No impact.
MLS
Detects loss of direct

connectivity to GICC.
No impact.
No impact.

.................................................................................................................................................................................................................................
401-710-090
5-37
Issue 3, March 2006
Fault management

GigE out-of-service
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
FMM-APs
No impact.
No impact.
None.
RCS
No impact.
No impact.
2. Forward
information from
the ECP to the BTS
ECP
Receives updates to SDP,

OMC-RAN and TI. See ==>
SDP 2121: TRBL

indication on RNC
summary indicator
1. Assigns alternate
BHSs to the
affected RCSs.
SDP 2265: BHS
indicator shows BHS

is Unavailable.
ROP: RNC reports
Major Alarm against
GigE port and Critical
Alarm against BHS
service. The BTS may
report loss of heartbeat
event.
5ESS DCS
No impact.
No impact.
No impact.
1X RNC
Detects loss of ARP beating on

serving IPBTS GW.
TPU-GUI: Reports
major GigE port
alarm, critical TPU
alarm and critical BHS
alarm.
No impact.
OMP-FX
No impact.
No impact.
No impact.
EMS: Shows critical

alarm against both
TPU shelves
OMC-RAN
See OMC-GUI ==>
OMC-GUI: TRBL
indication on RNC
Summary page.
Critical alarms against
the BHS and TPUs are
displayed. Major
alarms against the
affected GICCS are
displayed.
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-38
Fault management

GigE out-of-service
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
TI: OP:ALARM
Other Indications
There may be some

REPT-CPFAIL
reports for new call
setups on the ROP
from the affected
BTSs.
RNC IPBTS GW and
BHS states change to
disabled/idle.
States
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 order
identified.
Network Element
BTS
4. Notified by RCS to initiate new associations with the

primary BHS.
Transport Network
Router Management
Reflects MLS Ethernet interface OperStatus up.
Edge Router
No impact.
MLS
1a. Will clear down indication for InterfaceOper Status.

FMM-APS
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-39
Issue 3, March 2006
Fault management

GigE out-of-service
Network Element
RCS
3. Establishes associations with Primary BHS. Establishes all

new data calls on these associations. Terminates associations
with Alternate BHS after all calls on those associations have
drained.
ECP
2. Assigns Primary BHS to the RCSs.

SDP 2121: RNC summary indicator may still show trouble if
only one IPBTS GW is fixed.

SDP 2265: BHS indicator shows BHS is available.
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.
TPU-GUI: Critical BHS alarm clears and a Major alarm against
one of the GICCs will clear.
OMP-FX
EMS: TPU alarm indicator may return to Normal. (or at least
down 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-090
Issue 3, March 2006
5-40
Fault management
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.
element (NE):
for the NE.
detected.
Network
element
Fault detection
BTS
All BHS heartbeats will

be lost. BHAs timeout
and calls are dropped.
Alarms and
notifications
Automatic recovery
No impact.
Transport Network
.................................................................................................................................................................................................................................
401-710-090
5-41
Issue 3, March 2006
Fault management
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
Reflects interface
OperStatus
down. Layer 2
will report the
failure.
Router
Management
Edge Router
No impact..
MLS
Reports the interface as

down.
No impact.
No impact.
No impact.
No impact.
No impact.

FMM-APs
No impact..
RCS
Receives loss of heartbeat

alarms from the BTS.
ECP
Receives BHS disabled

indication from the RNC.
Since there is no alternate BHS,

data call originations and data
page responses are not forwarded
to the ECPC. The RCS also does
not send data traffic channel
requests (TP_REQ) to the RNC.
TRBL
indication on
RNC summary
indicator.
No impact.
SDP 2265: BHS
indicator shows
BHS is
Unavailable.
ROP:RNC reports
Major alarm
against GigE port
and critical alarm
against BHS
service. The BTS
may report loss
of heartbeat
events, depending
on how quickly
the RNC detects
the failure.
5ESS DCS
No impact.
No impact.
No impact..
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-42
Fault management
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
1X RNC
Detects loss of ARP

beating on serving IPBTS
GW.
TPU-GUI:GigE
No impact.
No impact.
OMP-FX
OMC-RAN
port alarm (major

alarm). TPU
alarm indicator is
Critical. BHS
alarm is critical.
EMS:TPU Critical alarm.
None.
OMC-GUI:
No impact.
TRBL
indication on
RNC Summary
page. Reports
TPU critical
alarm.
States
RNC IPBTS GW
and BHS states
change to
disabled/idle.
Other
Indications
There may be
some
REPT-CPFAIL
reports for new
call setups from
the affected
BTSs.
NE impacts: None
Subsequent alarms: None
Subsequent service impact:No new data calls can be established on the impacted
BTSs.
Fault resolution
Technician repairs the cable

.................................................................................................................................................................................................................................
401-710-090
5-43
Issue 3, March 2006
Fault management
Network Element
BTS
5. Notified by RCS to initiate new associations with the primary BHS.
Transport Network
Router Management
Interface on MLS will report an OperStatus of up
Edge Router
No impact.
MLS
1a. Interface OperStatus down clears.

FMM-APs
No impact.
RCS
3. Establishes associations with Primary BHS. Establishes all new data calls on
these associations.
ECP

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 the
GICCs will clear

OMP-FX
EMS: TPU alarm indicator may return to Normal. (or at least down to Major
dependent on other alarm conditions existing)
OMC-RAN
OMC-GUI:Displays show that the GigE port alarm has been cleared. TPU alarm
indicator may return to Normal. (or at least down to Major dependent on other
alarm conditions existing)
Other Indications
No impact.
Service impact:
No calls are dropped (stable and transient)
States
BHS is available. IPBTS GW is enabled/unlocked/active.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-44
Fault management
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.
element (NE):
for the NE.
detected.
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
BTS
Detects Loss of Layer 2.
No impact.
No impact.
Edge Router
No impact.
No impact.
No impact.
MLS
No impact.
No impact.
Assumes MLS-1
and MLS-2,
connections will be
routed to MLS-2
instead of going to
MLS-1 until the
problem is
resolved.
Transport Network
.................................................................................................................................................................................................................................
401-710-090
5-45
Issue 3, March 2006
Fault management
Network element
Fault detection
Alarms and
notifications
Automatic
recovery

FMM-APs
Major alarm will be set against

the local AP.
Major alarm will be

set against the local
AP.
Verify the Major

alarm is cleared
and verify that the
RCS-AP is in
active state.
RCS
Receives notification of MLS

Failure
Receive Notification of
MLS Failure.
No impact.
ECP
See SDP and ROP ==>
SDP 2131: Shows
SDP 2131: The
Major Alarm.
major alarm is
cleared.
ROP: Reports Major
Alarm.
ROP: Major alarm

clear message is
reported.
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
See OMC-GUI ==>
OMC-GUI: Major alarm

is displayed on the AP
Detailed View.
OMC-GUI: Major
alarm is cleared on
the AP Detailed
View.
Other Indications
None.
None.
None.
NE impacts: None.
Fault resolution
Repair MLS-1.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-46
Fault management
Network Element
BTS
Re-established socket connection to AP.
Transport Network
Edge Router
No impact.
Router Management
No impact.
MLS
Traffic goes through MLS-1 again.

FMM-APs
If the path is repaired (ping tests to the GW address succeed

or new TCP connections associated with the affected network
open), 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
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-47
Issue 3, March 2006
Fault management
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.
element (NE):
for the NE.
detected.
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
BTS
Detect Loss of Layer 2.
No impact.
No impact.
Edge Router
No impact.
No impact.
No impact.
MLS
No impact.
No impact.
Assuming MLS-1
and MLS-2,
connections will be
routed to MLS-1
instead of going to
MLS-2 until the
problem is
resolved.
Transport Network
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-48
Fault management
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
FMM-APs
Major alarm will be set against

the local AP. See ECP ==>
Major alarm will be

set against the local
AP.
Verify the Major

alarm is cleared
and verify that the
RCS-AP is in an
active state.
RCS
Receives Notification of MLS

failure.
No impact.
No impact.
ECP
See SDP and ROP ==>
SDP 2131: Shows
SDP 2131: Major
Major Alarm.
Alarm is cleared.
ROP:: Receives Major
ROP: Major Alarm
Alarm.
cleared message is
received.
5ESS DCS
No Impact, unless the MLS/L2

switch failure also impacts the
FE interface to the 5ESS DCS.
on NE interface.
No impact.
1X RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
OMC-RAN
See OMC-GUI ==>
OMC-GUI: Major alarm

displays on the AP
Detailed View
OMC-GUI: Major
alarm is cleared on
the AP Detailed
View.
Other Indications
None.
None.
None.
NE impacts: None.
Fault resolution
Repair MLS-2.
.................................................................................................................................................................................................................................
401-710-090
5-49
Issue 3, March 2006
Fault management
Network Element
BTS
Re-established socket connection to AP.
Transport Network
Edge Router
No impact.
Router Management
No. impact.
MLS
Traffic goes through MLS-1 again.

FMM-APs
If the path is repaired (ping tests to the GW address succeed

or new TCP connections associated with the affected network
open), 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.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-50
Fault management
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 inadvertently
disconnected, the technician should either connect a new cable or re-connect the
existing cables. In the worst case, cables between the FMM-AP frame and the IP
Gateways would need to be replaced with new cables.
element (NE):
for the NE.
detected.
Network
element
Fault detection
Automatic
recovery
BTS
No impact.
BTS will lose the

signaling link and
will attempt to
reboot.
No impact.
Router
Management
No impact.
No impact.
Edge
Router
No impact.
No impact.
No impact.
MLS
No impact.
No impact.
No impact.
Transport Network

.................................................................................................................................................................................................................................
401-710-090
5-51
Issue 3, March 2006
Fault management
Network
element
Fault detection
Automatic
recovery
FMM-APs
If BHGmon determines that

both the path to IPGW-0 is
unreachable, and the path to
IPGW-1 is unreachable, it
raises a critical alarm against
the RCS-AP indicating that
the paths to both IPGW-0 and
IPGW-1 are unreachable.
No impact.
No impact.
This condition causes a

failover of all the active
RCS-IP Backhaul processes
running on this RCS-AP.
RCS Integrity Services are
notified that a failure has
occurred. If this AP frame is
associated with that BHCS in
the router, BHCS service will
not be available even if the
BHCS process has restarted
on another IPBH-enabled AP
pair.
RCS
RCSs will go OOS.
No impact.
No impact.
ECP
See columns on SDP and

ROP
SDP 2121: shows Critical and

Major Alarms
No impact.
SDP 2131: displays Critical and

Major Alarms.
ROP: Critical and Major alarms
are reported.
5ESS DCS
No impact.
No impact.
No impact.
1X RNC
No impact.
No impact.
No impact.
OMP-FX
EMS: Displays critical, major,

and minor alarms.
No impact.
OMC-RAN
OMC-GUI: Displays critical
No impact.
alarm on the AP Detailed View

Other
Indications
None.
None.
None.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-52
Fault management
NE impacts: None.
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 be
replaced 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 results
below.
If the problem is not in the cabling, the contact Lucent Wireless Services (LWS) for
further diagnosis.
Network Element
BTS
BTS signaling link will be re-established.
Transport Network
Router Management
No impact.
Edge Router
No impact.
MLS
No impact.

FMM-APs
Verify that the critical alarm is cleared and verify that the
RCS-AP is in an active state.
RCs
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-53
Issue 3, March 2006
Fault management
Network Element
ECP
SDP 21: critical and major alarms are cleared as follows
If both IPGWs are now reachable, all critical and major

alarms for these faults are cleared.
If just one IPGW is now reachable, the critical alarm and

one 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 and
major alarms for these faults are cleared on the AP detailed

view. If just one IPGW is now reachable, the critical alarm
and one of the major alarms are cleared on the AP detailed
view.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-54
Fault management
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 have
their BHS on the current RNC will fail. This scenario assumes an alternate BHS is
available. If an alternate BHS is not available, new data calls and reactivations on the
BTSs that are served by this BHS will fail until the problem is resolved since the BHS
is declared disabled when the PSUGW is OOS.
Resolution
Technician repairs SHO network problem.

element (NE):
for the NE.
detected.
Network element
Fault detection
Alarms and
notifications
Automatic recovery
BTS
No impact.
No impact.
Recovery occurs in
the order shown:
4. Notified by RCS
to initiate new
associations with the
alternate BHS.
Transport Network
Router
Management
No impact.
No impact.
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-55
Issue 3, March 2006
Fault management
Network element
Fault detection
Alarms and
notifications
Automatic recovery
Edge Router
No impact.
No impact.
No impact.
MLS
No impact.
No impact.
No impact.

FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
No impact.
3. Establish new
BHAs with new
BHS.
ECP
See impacts to SDP, ECP

ROP and OMC-RAN ==>
SDP 2121: RNC
2. Assigns alternate
BHSs to the affected
RCSs.
summary indication =
TRBL.
SDP 2265: BHS indicator
shows BHS is
unavailable.
ROP: RNC reports
critical alarm (RNC is

not available).
5ESS DCS
No impact.
No impact.
No impact.
1X RNC
RNC detects loss 5E GWs

that are OOS
TPU-GUI: Reports RNC

is not available. TPU
alarm is Critical.
1. RNC report BHS

is disabled.
OMP-FX
EMS ==>
EMS: Critical alarm

against both TPU
shelves.
No impact.
OMC-RAN
OMC-GUI ==>
OMC-GUI: TRBL
indication on RNC
Summary page. TPU
alarm indicator shows
critical alarm.
No impact.
Other Indications
RNC call processing

status indicator on GUI
shows not available.
States
RNC BHS state is

changed to
disabled/idle.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-56
Fault management
NE impacts: BTS Starts receiving heartbeats on new BHAs.

Subsequent other indications: BTS to BHS mapping shown in SDP changes. RCS
reports 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 SHO
network problems.
Network Element

Numbers show order of results.
BTS
4. Notified by RCS to initiate new associations with the

primary 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 establishes

all new data calls on these associations. Terminates
associations with Alternate BHS after all calls on those
associations have drained.
ECP

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-090
5-57
Issue 3, March 2006
Fault management
Network Element

Numbers 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 alarms
may clear.
OMP-FX
EMS: TPU alarm indicator may return to Normal. (or at least
down to Major dependent on other alarm conditions existing).

OMC-RAN
OMC-GUI: GigE port alarm clears.
Other Indications
None.
State change
BHS returns to Enabled state.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-58
Fault management
No
1st Hop router connectivity
.................................................................................................................................................................................................................................
.
Loss of Layer 3 detected on Serving BPH 0 (If duplex router configuration, then both
fail).
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 Hop
Router(s). To resolve the problem, provision the correct IP address.
See IPBH Provisioning section, in 5ESS Switch Flexent /Autoplex Wireless
Networks Applications OA&M Manual, 235-200-100 or OA&M Manual, 5AP
International.
element (NE):
for the NE.
detected.
Network
element
Fault detection
Automatic
recovery
BTS
No impact.
No impact.
No impact.
No impact.
Router
Management
No impact.
No impact.
Edge
Router
No impact.
No impact.
No impact.
MLS
No impact.
No impact.
No impact.
Transport Network
.................................................................................................................................................................................................................................
401-710-090
5-59
Issue 3, March 2006
Fault management
Network
element
Fault detection
Automatic
recovery

FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
No impact.
No impact.
ECP
See impacts to SDP and

ECP ROP in separate
sections.
SDP: Minor alarm will be displayed.
No impact.
5ESS DCS
High Priority ARP-beat

fails and there is no
traffic reception due to a
provisioning error
(incorrect IP address
assignment for the 1st
hop router).
ROP: Minor Alarm messages are
received.
1188 MCC: The affected BPH Link Status
is OOS-GW and the Service Status is
UNAV; PH Group becomes
BPHGRPOFN
118[0-4]MCC: The PH Status of the
affected BPH is ACT-DGR - active,
degraded.
Fail-over - the
Non-Serving
BPH1 becomes
Serving and
BPH 0
becomes
UNAV.
ROP: outputs the following:
REPT SM=sm PSELINK=sm-psu-link

OLD_STAT=ACT NEW_STAT=OOS-GW
RATE=NOT APPLICABLE
REPT SM=sm PHGRP=sm-psu-phgrp

OFFNORM NEW STAT POS 1=UNAV POS
0=SERVING
OVERLOAD SUMMARY=NORMAL
OLD STAT POS 1=SERVING
1X RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
OMC-RAN
No impact.
No impact.
No impact.
Other
Indications
None.
None.
None.
NE impacts: None.
Subsequent service impact: No service impact since switched to the other BPH. No
dropped calls.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-60
Fault management
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 Recent
Views form 22.32 (NAR) or 9.37 (INTL).
2. Verify connectivity from the BPH to the 1st hop router, enter the command EXC:
PING (NAR) or , EXC-PING(INTL)
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 is
not dropping ARPs received by the router.
6. If in a duplex L2 switch configuration, verify that the interswitch trunk is
physically connected and operational.
Network Element
BTS
No impact.
Transport Network
Router Management
No impact.
Edge Router
No impact.
MLS
No impact.

FMM-APs
No impact.
RCS
No impact.
ECP
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-61
Issue 3, March 2006
Fault management
Network Element
5ESS DCS
1188 MCC: Displays minor alarm (Simplex PH Group).

ROP: reports the following:
REPT SM=sm PSELINK=sm-psu-link OLD_STAT=OOS-GW

NEW_STAT=ACT RATE=NOT APPLICABLE
REPT SM=sm PHGRP=sm-psu-phgrp NORMAL NEW STAT
POS 1=NONSERV POS 0=SERVING
OLD STAT POS 1=UNAV
1X RNC
No impact.
OMP-FX
No impact.
OMC-RAN
No impact.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-62
Fault management
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
element (NE):
for the NE.
detected.
Network
element
Fault detection
Automatic
recovery
BTS
No impact.
No impact.
No impact.
Transport Network
Router
Management
No impact.
No impact.
No impact.
Edge Router
No impact.
No impact.
No impact.
MLS
MLS will detect

Layer 1 going
away.
Router Management: Reflects Ethernet

interface OperStatus down.
No impact.

FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
No impact.
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-63
Issue 3, March 2006
Fault management
Network
element
Fault detection
Automatic
recovery
ECP
No impact.
No impact.
No impact.
5ESS DCS
Loss of Ethernet
connectivity
between the BPH
and the directly
connected L2
switch/MLS
1188 MCC: The affected BPH Link
Fail-over - the
Non-Serving BPH1
becomes Serving
and BPH 0 becomes
UNAV.
Status is OOS-LK, and the Service

Status is UNAV; PH Group becomes
BPHGRPOFN
118[0-4]: The PH Status of the affected
BPH is ACT-DGR - active degraded

REPT SM=sm PSELINK=sm-psu-link

OLD_STAT=ACT NEW_STAT=OOS-LK
RATE=NOT APPLICABLE
REPT SM=sm PHGRP=sm-psu-phgrp
OFFNORM NEW STAT POS 1=UNAV
POS 0=SERVING
OLD STAT POS 1=SERVING
1X RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
OMC-RAN
No impact.
No impact.
No impact.
Other
Indications
None.
None.
None.
NE impacts: None.
Subsequent service impact: No service impact since switched to the other BPH. No
dropped calls.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-64
Fault management
Fault resolution
Technician will fix the problem (cut cable, etc.).

Do the following to check success:
1. Execute the OP:IPCFG (NAR) or OP-IPCFG (INTL) command.
2. Verify connectivity from the BPH to the 1st hop router, enter the command
EXC:PING (NAR) or , EXC-PING(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 is
not dropping ARPs received by the router.
6. If in a duplex L2 switch configuration, verify that the interswitch trunk is
Network Element
BTS
No impact.
Transport Network
Router Management
Interface Oper Status up.
Edge Router
No impact.
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.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-65
Issue 3, March 2006
Fault management
No
1st Hop router connectivity
.................................................................................................................................................................................................................................

Loss of Layer 3 detected on Non-Serving BPH 0 (If duplex router configuration, then
both fail).
Severity

Service impact
Loss of Layer 3.
Resolution
International.
Other indications
None.
element (NE):
for the NE.
detected.
Network
element
Fault detection
Automatic recovery
BTs
No impact.
No impact.
No impact.
Router
Management
No impact.
No impact.
No impact.
Edge Router
No impact.
No impact.
No impact.
MLS
No impact.
No impact.
No impact.
Transport Network
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-66
Fault management
Network
element
Fault detection
Automatic recovery

FMM-APs
No impact.
No impact.
No impact.
R CS
No impact.
No impact.
No impact.
ECP
No impact.
No impact.
No impact.
5ESS DCS
Detects the loss of

heartbeat. High
Priority ARP-beat
fails due to
provisioning error
(incorrect IP address
assignment for the
1st hop router)
1188 MCC: The affected

BPH Link Status is
OOS-GW, and the Service
Status is UNAV; PH Group
becomes BPHGRPOFN
The Non-Serving BPH0

becomes UNAV.
118[0-4]: The PH Status of
the affected BPH is

ACT-DGR - active
degraded
REPT SM=sm
PSELINK=sm-psu-link
OLD_STAT=ACT
NEW_STAT=OOS-GW
RATE=NOT APPLICABLE
REPT SM=sm
PHGRP=sm-psu=phgrp
OFFNORM NEW STAT
POS 1=UNAV POS
0=SERVING
OVERLOAD
SUMMARY=NORMAL
OLD STAT POS
1=NONSERV
1X RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
OMC-RAN
No impact.
No impact.
No impact.
Other
Indications
None.
None.
None.
Automatic recovery actions
NE impacts: None.
.................................................................................................................................................................................................................................
401-710-090
5-67
Issue 3, March 2006
Fault management
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.
International.
Use EXC: PING (NAR), EXC-PING (INTL) command to verify connectivity from this
BPH 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 specific
debugging tools then -i.e. verify that router ARP policing is not dropping ARPs
received by the router. If in a duplex L2 switch configuration, then verify that the
interswitch 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 Recent
Views form 22.32 (NAR) or 9.37 (INTL).
PING (NAR) or , EXC-PING(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. verify
that 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 is
Network Element
BTS
No impact.
Transport Network
Router Management
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-68
Fault management
Network Element
Edge Router
No impact.
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.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-69
Issue 3, March 2006
Fault management
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.
element (NE):
for the NE.
detected.
Network
element
Fault
detection
Automatic recovery
BTs
No impact.
No impact.
No impact.
Transport Network
Router
Management
No impact.
Reflects MLS Ethernet

interface OperStatus down.
No impact.
Edge Router
No impact.
No impact.
No impact.
MLS
Detects loss of
layer 2.
No impact.
No impact.
No impact.
No impact.

FMM-APs
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-70
Fault management
Network
element
Fault
detection
Automatic recovery
RCS
No impact.
No impact.
No impact.
ECP
No impact.
No impact.
No impact.
5ESS DCS
Low Priority
ARP-beat fails
and no traffic
reception
1188 MCC: The affected BPH
The Non-Serving BPH0 becomes

UNAV.
Link Status is OOS-LK, and

the Service Status is UNAV;
PH Group becomes
BPHGRPOFN
118[0-4]: The PH Status of the
affected BPH is ACT-DGR active degraded

ROP outputs the following:
REPT SM=sm
PSELINK=sm-psu-link
OLD_STAT=ACT
NEW_STAT=OOS-LK
RATE=NOT APPLICABLE
REPT SM=sm
PHGRP=sm-psu-phgrp
OFFNORM NEW STAT POS
1=UNAV POS 0=SERVING
OVERLOAD
SUMMARY=NORMAL
OLD STAT POS 1=NONSERV
1X RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
OMC-RAN
No impact.
No impact.
No impact.
Other
Indications
None.
None.
None.
NE impacts: None.
.................................................................................................................................................................................................................................
401-710-090
5-71
Issue 3, March 2006
Fault management
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. Execute OP:IPCFG (NAR), or OP-IPCFG (INTL) to check the physical connection
between 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 duplex
mode on the L2 switch/MLS. The rate should be set to 100 Mbps, and the mode
should 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.
Network Element
BTS
No impact.
Transport Network
Router Management
Reflects MLS interface OperStatus up.
Edge Router
No impact.
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.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-72
Fault management
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.
element (NE):
for the NE.
detected.
Network
element
Fault detection
BTS
Detect loss of Layer 2

(caused by no LCP
heartbeat).
Alarms and
notifications
Automatic recovery
URC reboot. If there is another
active CDMA 1X-URC within
the same cabinet, then automatic
recovery will occur with MLG
sharing. If this URC is the parent
for a DO-URC, then the
DO-URC will be OOS.
Transport Network
Shows
vendor-specific
hardware fault for
the card that
failed.
Router
Management
Edge Router
Detects hardware failure.
MLS
No impact.
No recovery.
No impact.
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-73
Issue 3, March 2006
Fault management
Network
element
Edge router card failure affecting all associated DS1

interfaces
Fault detection
Alarms and
notifications
Automatic recovery
No impact.
No impact.

FMM-APs
No impact.
RCS
Will detect the loss of

heartbeat from RCS to
URC and update the SDP
page.
ECP
Updates to SDP,
OMC-RAN and TI.
If MLG sharing is invoked, will

update the SDP page. If not
using MLG sharing, the URC
will still be OOS.
SDP 2138:Shows
No impact.
URC ACT
SDP 2237:Shows
MLG OOS
ROP: Receives
URC and MLG

ACT messages.
5ESS DCS
BHAs associated with the

faulty router card are lost.
5E MCC:No
No impact.
impact.
ROP: If the debug
flag is turned on,

will report loss of
BHA due to a
router card
failure.
RNC
OMP-FX
OMC-RAN
BHAs associated with the

faulty router card are lost.
TPU-GUI:No
impact.
No impact.
EMS:No impact.
None.
OMC-GUI:
OMC-GUI: Major alarm clears on
OMC-RAN will
display a major
alarm on the AP
Detailed View.
AP Detailed View.
States
None
Other
Indications
SNMP traps for

vendor-specific
alarms are
displayed at
NMS.
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-74
Fault management

interfaces
NE impacts: None
Subsequent service impact: Loss of capacity .
Fault resolution

Network Element
BTS
If MLG sharing, restore the links to the MLG. If no MLG sharing, the
URC will resume using the local MLG when it finds that it has been
replaced while going through reboot.
Transport Network
Edge Router
Clears the vendor-specific hardware alarms and restores the links to the
MLG.
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 had
reported the URC OOS, it is now in service.
ECP

ROP:Alarm clears will be reported
5ESS DCS
No impact.
RNC
No impact.
OMP-FX
No impact.
OMC-RAN
No impact.
Other Indications
No impact.
Service impact:
Capacity is restored.
.................................................................................................................................................................................................................................
401-710-090
5-75
Issue 3, March 2006
Fault management

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

element (NE):
for the NE.
detected.
Network
element
Fault
detection
Automatic recovery
BTS
Detects BER in
excess of major
alarm
threshold.
No impact.
Removes DS1 from MLG.

Removing DS1(if is not a last DS1
in the MLG) from MLG ensures that
performance will not be impacted by
removing the T1 from the MLG.
DS1 capacity will be impacted.
Sends MLG bandwidth change and
MLG DS1 association change when
the T1 is removed from MLG.
Transport Network
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-76
Fault management
Network
element
Fault
detection
Router
Management
Automatic recovery
No impact.
No impact.
Edge
Router
Detects loss of
DS1 following
BTS removal.
No impact.
Removes DS1 from MLG.
MLS
No impact.
No impact.
No impact.

FMM-APs
No impact.
No impact.
No impact.
RCS
No impact.
No impact.
See ECP section for report on RCS.
ECP
See SDP ==>
SDP 2138: shows Major Alarm
Updates to SDP and TI.
SDP 2237: shows DS1 is not
in any MLG.
ROP: receives Major Alarm.
Text shows major alarm but

not alarm type.
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
See OMC-GUI
==>
OMC-GUI: shows Major Alarm
No impact.
on AP Detailed view.
OP:ALARM
OP:ALARM
Other
Indications
OP:CELL
NE impacts: Loss of capacity

Fault resolution
Technician corrects DS1 problem.

.................................................................................................................................................................................................................................
401-710-090
5-77
Issue 3, March 2006
Fault management
Network element
BTS
Restores DS1 to MLG.

Sends MLG bandwidth change and MLG DS1 association change
messages.
Transport Network
Router Management
No impact.
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 change
and 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.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-78
Fault management
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.
element (NE):
for the NE.
detected.
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
BTS
Detects loss of signaling link.
No impact.
No impact.
Transport Network
No impact.
Router
Management
Edge Router
No impact.
No impact.
No impact.
MLS
No impact.
No impact.
No impact.
.................................................................................................................................................................................................................................
401-710-090
5-79
Issue 3, March 2006
Fault management
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
No impact.
RCS IP processes
will attempt to
restart.
Critical alarm will be set

against the RCS-IP on both APs
where the IP services failure
has occurred.
FMM-APs
If RCS-IM process
is still running, the
RCS IP services
will restart.
If RCS-IM process
are not running, the
RCS IP services
will not restart.
RCS
RCS cannot failover
No impact.
No impact.
ECP
See SDP and ROP ==>
SDP 2121: shows

Critical Alarm
When automatic
recovery is
successful and RCS
IP services come
back, the critical
alarm is cleared.
SDP 2131: shows

Critical Alarm.
ROP: receives Critical
Alarm notification.
When automatic
recovery is not
successful, the
critical alarm
remains.
No impact.
5ESS DCS
5E MCC: Will output
No impact.
an assert on each lost

BHA.
1X RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
OMC-RAN
See OMC-GUI ==>
OMC-GUI: A critical
alarm displays on AP
Detailed View.
No impact.
Other Indications
NE impacts: None.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-80
Fault management
Fault resolution
To restore IP service on the RCS:

1. From TICLI, execute the command RST:RCS # to move the RCS state to active.
2. From TICLI, execute the command OP:AP #,STATUS or OP:AP#,RCS #,STATUS to
verify that the RCS is promoted to the active/standby state .
3. Check the AP ADMIN log file for the messages such as RCS XX promoted to
active on AP YY,where XX is the RCS that is restored, and YY the AP number that
is hosting that RCS
Network Element
BTS
BTS signaling link will be re-established.
Transport Network
Router Management
No impact.
Edge Router
No impact.
MLS
No impact.

FMM-APs
Critical alarm are cleared when one of the RCS-IPs

transitions to the active state. Major alarm are cleared when
both the Active and Mate AP are in the active state.
RCS
No impact.
ECP
SDP 2131: Critical Alarm is cleared. Major alarm displays if

the mate AP is still OOS-F. Major alarm clears when the mate
AP 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 still

be OOS-F.
Major alarm will be cleared when the Mate AP is back in

the 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 be

output on each lost BHA.
.................................................................................................................................................................................................................................
401-710-090
5-81
Issue 3, March 2006
Fault management
Network Element
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 active
state.
Other Indications
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-82
Fault management
One DS1 in MLG is not configured in ER, or wrong DS1 is

assigned
to MLG in ER
.................................................................................................................................................................................................................................
One DS1 (T1/E1) in MLG is not configured in edge router (ER), or wrong DS1 is
assigned to MLG in ER, this DS1 will not be in the MLG. Remove it from MLG is
not 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.

element (NE):
for the NE.
detected.
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
BTS
Detects loss of Layer 2 in DS1.
No impact.
Removes DS1 from

the MLG
Transport Network
Reflects DS1
OperStatus down.
Router
Management
Edge Router
If DS1 is not configured at all,

then no effect.
No impact.
If wrong DS1 is
configured, it is
removed from the
MLG.
.................................................................................................................................................................................................................................
401-710-090
5-83
Issue 3, March 2006
Fault management
One DS1 in MLG is not configured in ER, or wrong DS1

is assigned to MLG in ER
Network element
Fault detection
Alarms and
notifications
Automatic
recovery
MLS
No impact.
No impact.
No impact.

FMM-APs
No impact.
on NE interface.
No impact.
RCS
Receives Bandwidth Change

Notification from the BTS.
No impact.
No impact.
ECP
See SDP and , ROP ==>
SDP 2138: Shows

minor alarm
No impact.
SDP 2237: Shows show

which DS1s are
operational and show
that this T1 is not in
any MLG.
ROP: Receives minor
alarm for Bandwidth

change.
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
See OMC-GUI ==>
OMC-GUI: shows minor
No impact.
alarm on AP Detailed
View.
Other Indications
Router sends linkDown trap

if enabled.
TI: OP:ALARM
Router sends
linkDown trap if
enabled.
TI: OP:ALARM
NE impact.s: None.
Subsequent alarms: None..
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-84
Fault management
One DS1 in MLG is not configured in ER, or wrong DS1

is assigned to MLG in ER
Fault resolution
Technician corrects the configuration error in the edge router.

Network Element
BTS
Restores the DS1 to the MLG and reports the Bandwidth

Change 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 the

configuration.
Case 2: Incorrect DS1 is provisioned. Add the correct DS1 to
the 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 MLG
bandwidth 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.
.................................................................................................................................................................................................................................
401-710-090
5-85
Issue 3, March 2006
Fault management
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
element (NE):
for the NE.
detected.
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
BTS
Receive AIS alarm on all DS1s

in the MLG.
AIS alarm.
No impact if APS
switchover is
completed before the
end of 5 seconds.
Transport Network
Shows vendor-specific
hardware fault.
Router
Management
Edge Router
Detects hardware failure.
MLS
No impact.
Performs switchover
to the standby router.
No impact.
No impact.
No impact.
No impact.

FMM-APs
No impact.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
5-86
Fault management

interfaces
Network
element
Fault detection
Alarms and
notifications
Automatic recovery
RCS
Detects the loss of heartbeat

from RCS to URC.
No impact.
No impact.
ECP
See ROP ==>
SDP: No impact.
No impact.
ROP: May receive BHA
loss messages.
No impact.
5ESS DCS
5E MCC: Will report loss
5E MCC No impact.
of BHA, if there are is

BHA loss due to a
multiplexer failure.
ROP: When the debug
flag is turned on, ROP

will report loss of BHA
if there is BHA loss
during APS switchover.
1X RNC
No impact.
No impact.
No impact.
OMP-FX
No impact.
No impact.
No impact.
OMC-RAN
See OMC-GUI ==>
No impact.
No impact.
Other
Indications
SNMP traps for

vendor-specific alarms are
displayed at NMS.
SNMP traps for

vendor-specific alarms
are displayed at NMS.
None.
NE impacts : None.
Fault resolution
The technician replaces the faulty edge router component and then forces a switchback.
Network Element
BTS
No impact if APS switchover is completed before the end of 5

seconds.
.................................................................................................................................................................................................................................
401-710-090
5-87
Issue 3, March 2006
Fault management
Network Element

interfaces
Transport Network
Router Management
Clears the vendor-specific hardware alarms.
Edge Router
Switches back to the original router and re-establishes links to

the MLG.
MLS
No impact.

FMM-APs
No impact.
RCS
No impact if APS switchover is completed before the end of 5

seconds.
ECP
SDP: No impact.
ROP: ROP may receive BHA loss messages.
5ESS DCS
ROP: When the debug flag is turned on, ROP reports loss of
BHA if APS switchover cant 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-090
Issue 3, March 2006
5-88
I PBH performance measures

6
Service measurements
Overview
.................................................................................................................................................................................................................................
Purpose
This section describes the tools and information that are available for evaluating and
improving performance in an IP backhaul network using Service Measurements (SM).
Contents
SM for IPBH
6-2
6-6
6-9
.................................................................................................................................................................................................................................
401-710-090
6-1
Issue 3, March 2006
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 cell
counts.
Cell Backhaul (MLG) related counts
Important! Please note that PP blocking in the IP backhaul world implies that
none 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 blockingThis

count is pegged at the cell site whenever the cell site cannot allocate traffic CE for
a 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 carrier
for 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/Terminations
overflow).
This count can be used to engineer the backhaul bandwidth. The
origination/termination overflow is due to no available channel element (CE) and
can be derived by subtracting this count along with CDMA voice
origination/termination overflow due to BHS blocking and CDMA Packet data
origination/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 ATM
Packet Pipe Connection
2G Termination Failures Caused by Inability to Establish a Packet Pipe or ATM
Packet 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
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
6-2
SM for IPBH
DS1 related counts
The following are new counts for IPBH:
Average DS1 OccupancyThis count represents the average occupancy of DS1

(T1) backhaul link when the BTS is running in IPBH mode. This measurement
reports counts for peak occupancy and for average occupancy.
Each equipped DS1 is sampled & averaged every 10 seconds, and the average
hourly value is reported. The count helps to monitor the backhaul utilization on a
per DS1 basis in terms of throughput by counting the number of bytes transmitted
per second and comparing it to the maximum bandwidth of unchannelized DS1 to
determine the Average DS1 Occupancy percentage.
Peak DS1 OccupancyThis count represents the peak occupancy of DS1 (T1/E1)
backhaul link when the BTS is running in IP Backhaul mode. Each equipped DS1
is 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 new
maximum (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 of
throughput by counting the number of bytes transmitted, and determining the
percentage of peak occupancy for each hourly service-monitoring window by
comparing it with the maximum bandwidth of an unchannelized DS1.
URC signaling counts
Counts for URC signaling are:
Average Signaling Traffic Load (downlink) per URCThis count provides a

measure of the average signaling traffic load (in the downlink) per URC, which is
an aggregation of loading offered by all the signaling links, for a given controller.
Peak Signaling Traffic Load (downlink) per URCThis count provides a measure
of Peak Signaling Traffic load (in the downlink) per URC, which is an aggregation
of loading offered by all the signaling links, for a given Controller.
Average Signaling Traffic Load (uplink) per URCThis count provides a measure
of the average signaling traffic load (in the uplink direction) per URC, which is an
aggregation of signaling loading offered to all the signaling links for a given
controller.
Peak Signaling Traffic Load (uplink) per URCThis count provides a measure of
Peak Signaling Traffic load (in the uplink direction) per URC, which is an
aggregation of loading offered to all the signaling links for a given controller.
.................................................................................................................................................................................................................................
401-710-090
6-3
Issue 3, March 2006
SM for IPBH
AP-related counts
The following are AP-related counts:
Total RCS Messages Transmitted from the AP per URCThis count reports the
total number of RCS messages per URC transmitted from an AP to the BTS on the
signaling 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 are
directly correlated with AP capacity (processor occupancy) and used for
engineering of RCS instances per AP.
Total RCS Messages Received from the BTS Per URCThis count reports the
total number of RCS messages per URC received from the BTS on the signaling
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 are directly
correlated with AP capacity (processor occupancy) and used for engineering of
RCS instances per AP.
Peak Signaling Traffic Load (downlink) per APThis count provides a measure of
the peak signaling traffic load (in the downlink) per AP, which is the sum total of
loading offered (total bytes transmitted over an individual LAN) at a given AP over
the Ethernet link. The loading is obtained by calculating the volume of Ethernet
traffic transmitted per second. For a given AP, for every 10 seconds, the traffic
loading is compared with the previous maximum number. If the new maximum (or
peak) has been reached, the new value is saved.
Average Signaling Traffic Load (downlink) per APThis count provides a measure
of the average signaling traffic load (in the downlink) per AP, which is the sum
total of loading offered (total bytes transmitted over an individual LAN) at a given
AP over the Ethernet link. The loading is obtained by calculating the volume of
Ethernet 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 BlockingThis count

is pegged at the RCS AP whenever a BHS cannot be assigned to a CDMA voice
call due to BHS blocking for a given carrier. This count is pegged even if a cell
site allocates traffic CE to a subsequent carrier for the CDMA call.
CDMA Packet Data Origination/Termination Overflow due to BHS Blocking
IDThis count is pegged at the RCS AP whenever a BHS cannot be assigned to a
CDMA packet data call due to BHS blocking for a given carrier. This count is
pegged even if a cell site allocates traffic CE to a subsequent carrier for the CDMA
call.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
6-4
SM for IPBH
CDMA Voice Handoff Overflow due to BHS BlockingThis count is pegged at

the RCS when the RCS call processing for a CDMA Voice call cannot allocate a
BHS for a CDMA Handoff due to BHS Blocking.
CDMA Packet Data Handoff Overflow due to BHS BlockingThis count is

pegged at the RCS when the RCS CP for a CDMA packet data call cannot allocate
a BHS for a CDMA handoff due to BHS blocking. This count is not pegged for
semi-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 frame
relay packet pipe (FR) or ATM packet pipe or IP (MLG).
The following existing SM parameters can be referenced when evaluating performance
for IP backhaul:
CDMA Maintenance Busy Usage including:

CDMA Origination/Termination Overflow Count
CDMA Handoff Overflow Count
CDMA Origination/Termination Overflow with Handoff Reserved Channels
Available
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-090
6-5
Issue 3, March 2006
5ESS
measurement reports
.................................................................................................................................................................................................................................
IPBH Backhaul Measurement Report
This report is generated using the OP-TFPHG command for real-time reports or the
OP-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 PH
Group. 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-090
Issue 3, March 2006
6-6
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 the OP-TFPHG command for real-time reports or the
OP-TRPHG command to retrieve stored reports. This report provides IP BACKHAUL
PH supplemental measurements. The measurements on this report enhance and provide
greater 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 PH
Group. 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
.................................................................................................................................................................................................................................
401-710-090
6-7
Issue 3, March 2006
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
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
6-8
5ESS
DCS TRFM for IPBH
.................................................................................................................................................................................................................................
Purpose
Refer to 5ESS Switch Flexent /Autoplex Wireless Networks Applications

Measurements Manua, 5MM for complete information on 5ESS DCS service
measurements
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
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
OP TRFC30 IPBH
TIME 05:59:30
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SECTION 154: IP BACKHAUL MEASUREMENTS (IPBH)
1234567890123456789012345678901212345678901234567890123456789
IP BACKHAUL PH GROUP SUMMARY REPORT:
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SM PSU PHGRP RXUDPMDG TXUDPMDG RXUDPMSEG TXUDPMSEG RXUDPMBYTE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
3530
3530
3530
3530
203
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SM PSU PHGRP TXUDPMBYTE TXUDPMBF TXUDPMPT
TXUDPMLT BPHPBOCC
1234567890123456789012345678901212345678901234567890123456789
3
0
1
203
0
0
3530
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SM
PSU
PHGRP
MAXPBBYTE
MAXBPHOCC
MAJOVLD
CRITOVLD
RXERREFRM
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
1364
4
0
0
14828
1234567890123456789012345678901212345678901234567890123456789
SM
PSU
PHGRP
RXERRIPDG
RXERRIPBH
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
0
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP BACKHAUL PH GROUP REPORT:
1234567890123456789012345678901212345678901234567890123456789
SM PSU SHLF PH RXEFRM
TXEFRM
RXBYTE
TXBYTE
RXEPAUSE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
0
6 8025
60
524
3
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
1 11555
3590
789
269
0
1234567890123456789012345678901212345678901234567890123456789
SM
PSU
SHLF
PH
TXEPAUSE
ENETLOSS
ROUTERFC
TOTPBPKTS
TOTPBBYTE
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
0
6
0
0
0
98534
8279
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
1 0
0
0
98529
8279
1234567890123456789012345678901212345678901234567890123456789
SM PSU SHLF PH RXAPMSG TXAPMSG
RXICMP
TXICMP
BPHSERV
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
0
6 611
60
0
0
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
1 4141
60
0
0
1800
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
6-9
Issue 3, March 2006
Figure 6-2 IPBHSUP report, section 153
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
OP TRFC30 IPBHSUP
TIME 06:29:30
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SECTION 153: IP BACKHAUL SUPPLEMENTAL MEASUREMENTS (IPBHSUP)
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP BACKHAUL PH GROUP SUMMARY REPORT:
1234567890123456789012345678901212345678901234567890123456789
SM PSU PHGRP BHACON
BHAHBTO
MAXBHA
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
10
0
0
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
IP BACKHAUL PH GROUP REPORT:
1234567890123456789012345678901212345678901234567890123456789
SM PSU SHLF PH ENET2SHRT ENET2LONG ENETCRC ENETMISA
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
NSENETTYPE
1234567890123456789012345678901212345678901234567890123456789
3
0
0
3 0
0
0
0
150
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
10 0
0
0
0
150
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SM
PSU
SHLF
PH
INVIPMAC
IPTOOSHRT
IPCHKSUM
BADIPLEN
IPHDRLEN
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
0
3 7265
0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
3
0
0
3
7265
0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
0
3 0
0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
1
10 0
0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
SM PSU SHLF PH UDPCHKSUM BADUDPLEN OORUDPPORT UNASSBHA
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SRCIPMIS
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
0
3 0
0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
3
0
1
10
0
0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
SM PSU SHLF PH SRCUDPMIS UDPMXSHRT UDPMUXLEN UDPMUXMSEQ
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
3
0
0
3 0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
3
0
1
10 0
0
0
0
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
1234567890123456789012345678901212345678901234567890123456789
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
6-10
S afety and general information

7
Overview
.................................................................................................................................................................................................................................
Purpose
This chapter provides information on hazards, which may arise in the course of your
work.
Contents
Hazard statements
7-2
7-3
7-5
.................................................................................................................................................................................................................................
401-710-090
7-1
Issue 3, March 2006
Hazard statements
Overview
.................................................................................................................................................................................................................................
Purpose
This section provides information on the structure of hazard statements as well as

general and specific hazards, which may arise in the course of your work.
Contents
7-3
7-5
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
7-2
Structure
of hazard statements
.................................................................................................................................................................................................................................
Overview
Hazard statements describe the safety risks relevant while performing tasks on Lucent
Technologies products during deployment and/or use. Failure to avoid the hazards may
have serious consequences.
General structure
Hazard statements include the following structural elements:
Item
Structure element
Purpose
Personal injury symbol
Indicates the potential for personal injury

(optional)
Hazard type symbol
Indicates hazard type (optional)
Signal word
Indicates the severity of the hazard
Hazard type
Describes the source of the risk of damage or

injury
Damage statement
Consequences if protective measures fail
Avoidance message
Protective measures to take to avoid the hazard
Identifier
The reference ID of the hazard statement

(optional)
.................................................................................................................................................................................................................................
401-710-090
7-3
Issue 3, March 2006
Signal words
The signal words identify the hazard severity levels as follows:

Signal word
Meaning
DANGER
Indicates an imminently hazardous situation (high risk) which, if

not 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, if
not avoided, may result in personal injury.
When used without the personal injury symbol:
Indicates a potentially hazardous situation (low risk) which, if
not avoided, may result in property damage, such as service
interruption or damage to equipment or other materials.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
7-4
General
hazard statements
.................................................................................................................................................................................................................................
Purpose
Provides information on general hazard statements that may arise in the course of your
work, 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 with
respect to ground for accessible parts of the installation. Contact with these parts can
cause serious health effects, possibly including death, even hours after the event.
This equipment is only suited for permanent connection. Before connecting the power
supply, 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 and
safely 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 using insulated connection
terminals, are adequately trained and follow safe work practices.
.................................................................................................................................................................................................................................
401-710-090
7-5
Issue 3, March 2006
WARNING
Contact with energized parts can cause serious personal injury.
Seal off the installation area (warning tape, signs) to prevent untrained or
unauthorized persons from entering.
Follow safe work practices and lockout/tagout procedures.
WARNING
Some parts of all electrical installations are energized. Failure to follow safe work
practices and the safety warnings may lead to bodily injury and property damage.
For this reason, only trained and qualified personnel (electrical workers as defined in
IEC 60215 or EN 60215 + A1 or in the National Electrical Code or in ANSI/NFPA
No. 10) may install or service the installation.
WARNING
Laser hazard
The light from laser and high-radiance LEDs may cause eye damage if absorbed by
the 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 the
cabinet into an upright position.
Ensure that the cabinet is in an upright position before transportation by crane.
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
7-6
WARNING
Inhalation hazard
Inhalation of asbestos fibers can result in serious illness or death.
Buildings constructed before 1980 MAY contain asbestos. Buildings constructed before
1970 OFTEN contain asbestos. Potential exposure could occur during routing of cable
or wires, removing cables, removing transite or asbestos cement boards, drilling
wallboard, transite panels, or floor tiles, removing sprayed on fireproofing, moving or
removing ceiling tiles, installing cable hangers.
Do not disturb asbestos. When asbestos is present ensure potential expose is controlled
by 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 moving
from outside to closed rooms. Condensation can cause malfunctioning of the circuit
packs.
Ensure that circuit packs and shelves have reached room temperature and are dry
before taking them into operation.
CAUTION
Service disruption hazard
Tools left in the work area can cause short circuits during operation which can lead to
the 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 the
equipment.
Always use three people or a lifting device to transport and position this equipment.
.................................................................................................................................................................................................................................
401-710-090
7-7
Issue 3, March 2006
CAUTION
Flammable material hazard
The heat vent (grill) at the top of the cabinet can become obstructed, preventing
ventilation 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 containing
semiconductor 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 work
mat.
Leave the modules in their original packaging until ready for use.
Make sure there is no difference in potential between yourself, the workplace, and
the packaging before removing, unpacking, or packing a module.
Hold the module only by the grip without touching the connection pins, tracks, or
components.
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-090
Issue 3, March 2006
7-8
Glossary
.................................................................................................................................................................................................................................
Numerics
1X RNC
Radio Network Controller

.................................................................................................................................................................................................................................
Adjacent MSC Switch
An Ethernet/IP Switch
AP
Application Processor
APS
Automatic Protection Switch

ARP
Address Resolution Protocol

AS
Adaptive Service
ATM
Asynchronous Transfer Modes

.................................................................................................................................................................................................................................
BER
Bit Error Rate

BH
Backhaul
BHA
Backhaul Association
.................................................................................................................................................................................................................................
401-710-090
GL-1
Issue 3, March 2006
Glossary
BHCA
Busy Hour Call Attempts

BHCS
Backhaul Connection Server

BHS
Backhaul Server
A server which bridges bearer path traffic from the IP messages from the BTS onto the
internal busses and protocols of the PSU or RNC for delivery to cards providing frame
selection service.
BHSPH
Backhaul Server Protocol Handler

BPH
Backhaul Protocol Handler

BPSN
BackPlane Serial Number

BTS
Base Transceiver Station

.................................................................................................................................................................................................................................
CCM
Cell Communications Manager

CDM
CDMA Digital Module

CF3
Control Fanout
CICC
Common Intelligent Carrier Card

CID
Call Identifier
CRC
CDMA Radio Controller (Modular cell 1,2, &3 network interface/controller)

CSB
Common System Bus
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
GL-2
Glossary
.................................................................................................................................................................................................................................
DACS
Digital Access and Cross-connect System

DCS
Digital Cellular Switch (Wireless 5ESS DCS)

DLCI
Data Link Connection Identifier

DNS
Domain Name Server

DNU
Digital Network Unit

DS0
Digital Service level 0

DS1
Digital Service level 1

DSCP
DiffServ Code Point

.................................................................................................................................................................................................................................
E1
European Digital signal level 1 transmission rate 2.048 Mbps. Each E1 frame has 32
time slots
ECP
Executive Cellular Processor

ECPC
Executive Cellular Processor Complex (Flexent MSC Controller)

EDP
Electrostatic Discharge Protection

ER
Edge Router
A network element that terminates the PPP and ML-PPP protocol stacks from the URC
and interchanges packets with IP/Ethernet.
ESD
Electrostatic discharge
.................................................................................................................................................................................................................................
401-710-090
GL-3
Issue 3, March 2006
Glossary
EVDO
Evolution - Data Only (3G1X Wireless)

.................................................................................................................................................................................................................................
FAF
Feature Activation File

FGW
Frame Gateway
FID
Feature Identifier
FMM
Flexent Mobility Manager

FR
Frame Relay
FRPH
Frame Relay Protocol Handler

FS
Frame Selector
.................................................................................................................................................................................................................................
GE
Gigabit Ethernet
GICC
Gateway Intelligent Carrier Card (RNC)

An RNC card connecting Ethernet and ATM facilities with internal RNC busses. IPBH
GICC cards are configured as a pair, with one card actively providing BHS service and
the other running standby.
GNP-AP
GNP Application Processor

GUI
Graphical User Interface

GW
Gateway
.................................................................................................................................................................................................................................
HD
High Density
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
GL-4
Glossary
HSRP
High-Speed Routing Protocol

.................................................................................................................................................................................................................................
ICMP
Internet Control Message Protocol

IETF
Internet Engineering Task Force

IP
Internet Protocol
IPBH
IP Backhaul
IPBTS
IP Backhaul Base Transceiver Station

IPBTSGW
IP Backhaul Base Transceiver Station Gateway

IPCP
Internet Protocol Control Protocol

.................................................................................................................................................................................................................................
LAG
Link Aggregration Group

LAN
Local Area Network

LAPD
Link Access Protocol D

.................................................................................................................................................................................................................................
Mbps
Millibits per second

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

ML-PPP
Multi-link Point-to-Point Protocol
.................................................................................................................................................................................................................................
401-710-090
GL-5
Issue 3, March 2006
Glossary
MLG
Multi-Link Group (ML-PPP)

A set of 1 to 4 digital facilities grouped into a single logical facility.
MLS
Multi-Layer Switch
MSC

MTU
Maximum Transfer Unit

.................................................................................................................................................................................................................................
NAR
North American Region

NMS
Network Management System

NVM
Nonvolatile Memory
.................................................................................................................................................................................................................................
OMC
Operations & Maintenance Center

OMP
Operations and Management Platform

OOS
Out of service
OSN
Operations Support Network

.................................................................................................................................................................................................................................
PCF
Packet Control Function

PCS
Personnel Communication System

PDSN
Packet Data Service Node
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
GL-6
Glossary
PF3
Packet Fanout
PH
Packet Handler
PHE
Packet Handler for Ethernet

PHG
Packet Handler Group

PHV
Protocol Handler for Voice

PP
Point-to-point
PPP
Point-to-Point Protocol
PS
Packet Switch
PSU
Packet Switching Unit (5ESS DCS)

.................................................................................................................................................................................................................................
QoS
Quality of Service
.................................................................................................................................................................................................................................
RAN
Radio Access Network

RCD
Release Configuration Document

RCS
Radio Cluster Server

RCV
Recent Change and Verify

RMT
Remote Maintenance Terminal
.................................................................................................................................................................................................................................
401-710-090
GL-7
Issue 3, March 2006
Glossary
RNC
Radio Network Controller

RNMS
Router Network Management System

.................................................................................................................................................................................................................................
SDP
Status Display Page

SHO
Soft Handoff
SL
Signaling Link
SM
Service Measurements
5ESS Switch Module
SMP
5ESS Switch Module Processor

SMS
Short Messaging Services

SOC
Service Option Class

SPSB
Simple BTS Startup Protocol

SU
Software Update
SW
Switch
.................................................................................................................................................................................................................................
T1
A standard digital transmission facility with 24 DS0 channels

TCP
Transmission Control Protocol

TGW
Traffic Gateway
.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
GL-8
Glossary
TI
Technician Interface
TPU
Traffic Processing Unit

TSI
Time Slot Interchange

.................................................................................................................................................................................................................................
UDP

UDPMux

URC

.................................................................................................................................................................................................................................
VRRP
Virtual Router Redundancy Protocol
.................................................................................................................................................................................................................................
401-710-090
GL-9
Issue 3, March 2006
Index
Numerics
1X RNC, 2-15
1XRNC, 4-6
Also see: RNC
1X RNC
TPU GUI, 4-7
1X RNCs
hardware requirements, 1-5
1X RNC
network interface, 1-24
1X1X RNC
.............................................................
Base transceiver station, 2-4
A Active RCS IP goes OOS-F
BER threshold crossed, 5-76
while 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
5ESS DCS, 2-12
.............................................................
5ESS DCS implementation,

3-14
B Backhaul network
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
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
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
OA&M, 4-3
btseqp
Build IPBH network, 3-3
.............................................................
C Cable
Fault, 5-30
Cable cut, 5-27
fault, 5-17
Backhaul server associations,

4-20
Calls dropped, 5-86
Backplane serial number
cdmeqp
retrieve, 3-41, 3-41
.................................................................................................................................................................................................................................
401-710-090
IN-1
Issue 3, March 2006
Index
cell2
Commands
I/O, 4-29
Configuration
.............................................................
cdme1p, 3-49
E ECP
cdmeqp, 3-49
OMC-RAN, 1-3, 1-5
status display pages, 4-38
5ESS DCS, 3-14

GICC, 3-18, 3-20, 3-22
RC/V, 4-21
OA&M, 4-21, 4-38

Configure
ecp, 3-34
ECPC
HLR, 1-3, 1-5
RNC, 2-16
cell2, 3-44, 3-48
provision, 3-34
Edge router
Frame relay, 1-14

.............................................................
G Gateway
IPBTS, 2-15
Fault, 5-24
Gateway intelligent carreir

card, 2-18
Edge router card failure

affecting all associated DS1
interfaces, 5-73, 5-86
general hazard statements, 7-5
IPBTS GW, 3-18

Edge routers, 2-7
General problem solving mode,

5-5
remote, 2-7
Geographic clustering, 2-25
RCS-AP, 3-37
RCS-IM, 3-37
Convert
GICC, 2-18
EIN failure, 5-79

FR to IPBH, 3-4
ER failure, 5-73
add to TPU GUI, 3-22
Ethernet connectivity, 5-63
configure, 3-18, 3-20, 3-22
to IPBH, 3-3
.............................................................
.............................................................
GigE cable, 3-22
F Fault, 5-30
install, 3-18, 3-20, 3-21
D Data packets
lost, 5-24
Delete
DS1/DS0, 3-52
DS1 (T1/E1) cable cut,

5-17, 5-17
Dropped calls, 5-14, 5-17,

5-30, 5-30, 5-37, 5-73, 5-76
T1, 5-24
monitoring, 4-4
FIDs, 1-2
FMM-AP, 2-10
DS1/DS0
OA&M, 4-5
DS1s, 2-4
GigE interface, 5-30

Growth
PHE3, 3-16
Feature identifiers, 1-2
DS1 (T1/E1) cable cut, 5-17
delete after conversion, 3-52
install, 3-22
Cable, 5-24
Documentation roadmap, 1-9
DS1, 2-24, 5-24

Also see: T1
GigE cable
cable, 5-14
FMM-RCS, 3-33
Forms
apeqp, 3-38
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
btseqp, 3-50, 3-50

.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
IN-2
Index
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
IPBH network elements

checklist
No 1st Hop router connectivity,

5-59, 5-66
IP addressing, 3-9
No Ethernet connectivity, 5-63,

5-70
IPBH traffic, 1-25

IPBTS GW, 2-15, 4-6
fault, 5-30
O OA&M
IPBTS GW down, 5-34, 5-37

5ESS DCS, 4-11
IPGW access failures, 5-51
BTS, 4-3
IPGW unreachable, 5-45, 5-48
.............................................................
Loss of capacity, 5-14, 5-17,

5-76
5ESS DCS, 2-30

Loss of communication
between ER and MSL, 5-27
IPBH network, 2-28
Loss of Layer 2, 5-34, 5-37,

5-70
RCS-AP, 2-29
Loss of Layer 3, 5-59, 5-66
requirements, 2-27
Lost data packets, 5-24
RNC, 2-30
IP Backhaul architecture, 2-2
IP Backhaul network, 1-16, 2-1
I/O, 4-29
Modular cells, 2-4

Monitor
network, 5-3
Multi-link group, 2-5
.............................................................
IPBH network
N Network architecture, 1-19, 2-2
build, 3-3
Network fault management
implementation, 3-3
IPBH network architecture,
1-19
OMC-RAN, 1-3, 1-3, 1-5, 4-48

One DS1 in MLG is not
configured in ER, or wrong
DS1 is assigned to MLG in
ER, 5-83
Outputs, 4-29, 4-32
.............................................................
PH provisioning, 3-16
M Messages
IP network
benefits and advantages,

1-13
routers and switches, 4-2
P Performance, 6-1
MLG, 2-5
IPBH
RNC, 4-6
.............................................................
IP conversion, 3-3
install, 3-6
ECPC, 4-21, 4-38

FMM-AP, 4-5
L Layer 3, 5-59
URC, 5-83
BTS, 2-28
.............................................................
State change, 5-30
IP address, 2-27
BHS, 2-29
No path to backhaul network,

5-79
General problem solving

model, 5-5
Network monitoring, 5-3
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
.................................................................................................................................................................................................................................
401-710-090
IN-3
Issue 3, March 2006
Index
user traffic, 2-20

Provision
apeqp, 3-38, 3-39
RCS, 2-10
RCS-AP, 2-10, 3-33
SDP 2138, 4-38, 4-41, 4-41

SDP 2236, 4-38, 4-42
SDP 2237, 4-38, 4-43
btseqp, 3-50, 3-50
configure, 3-37
SDP 2260, 4-38, 4-45
cdmeqp, 3-49, 3-49
IP address, 2-29
SDP 2265, 4-38, 4-45
cell2, 3-44, 3-48

ecp, 3-34, 3-36
RCS-IM
Service measurements, 6-1

5ESS DCS, 6-9
configure, 3-37
ECPC, 6-2
RCS-AP, 3-33
Remote maintenance tool, 4-3
RNC, 4-6
Remote routers, 2-7
Signaling traffic, 2-22
Requirements, 1-5
Software requirements, 1-7
Provisioning
PH, 3-16
hardware, 1-5
PSU growth, 3-16
IP address, 2-27
PSU2e, 2-12
router, 2-8
PSUGW OOS, 5-55
software, 1-7
.............................................................
R Radio cluster server, 2-10
Radio network controller, 2-15

RC View 22.32, 4-12
RC View 33.1, 4-12
Retrieve
BPSN, 3-41, 3-41
RNC, 2-15, 3-18

Also see: 1XRNC
Switches, 2-6, 4-2

adjacent, 2-8
install, 3-6
.............................................................
T T1
fault, 5-14
I/O commands, 4-9
Fault, 5-24
IP address, 2-30
Technologies, 1-5
OA&M, 4-6
Router requirements, 2-8
Terminology, 1-13
Also see: Glossary
Routers, 2-6, 2-7, 4-2
TPU GUI
RC View 90.5 (INTL), 4-17

RC Views
install, 3-6
22.32, 4-12
remote, 2-7
33.1, 4-12
.............................................................
33.3, 4-12
90.6, 4-17
Supported technologies, 1-5
configuration, 2-16
90.5, 4-17
structure of hazard statements,

7-3
RC View 33.4, 4-12
9.37, 4-17
5ESS DCS, 4-46
RMT, 4-3
RC View 33.3, 4-12
33.4, 4-12, 4-17
Status display pages, 4-38
S Safety and general information,
7-3, 7-5
screens, 4-7
Traffic
signaling, 2-22
user, 2-25
Traffic flow, 1-25
SDP, 4-38
.............................................................
SDP 2101, 4-38, 4-40
U User traffic, 2-20
SDP 2131, 4-38, 4-41
User traffic protocol, 1-25
RC.V forms, 4-21

.................................................................................................................................................................................................................................
401-710-090
Issue 3, March 2006
IN-4
Index
.............................................................
V Voice quality problems, 5-24
.................................................................................................................................................................................................................................
401-710-090
IN-5
Issue 3, March 2006

IP Backhaul

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IP Backhaul

Uploaded by

Copyright:

Available Formats

See notice on first age

Flexent Wireless Networks

Lucent Technologies - Proprietary

See notice on first age

Lucent Technologies - Proprietary

About this information product

Reason for reissue

How to use this information product

Documentation, training and support

Related information products

IPBH documentation roadmap

IPBH network architecture

IP Backhaul network overview

Base transceiver station

Backhaul routers and switches

Radio network controller (1X RNC)

Signaling traffic protocols

Backhaul server assignment and PSU2e/1X RNC engineering

Radio cluster server

Implement and build the IPBH network

Pre-conversion: Install IP network

IPBH network elements checklist

Pre-conversion: Prepare 5ESS DCS for IPBH

Prepare 5ESS DCS for conversion

Pre-conversion: Prepare 1X RNC for IPBH

1X RNC implementation overview

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

Configure FMM-RCS IP Integrity Manager

Retrieve Backplane Serial Number (BPSN)

Provision cdmeqp form

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

OA&M for IP Backhaul

Routers and switches

5ESS DCS OA&M

Input/Output commands and messages

General problem solving model

Network monitoring and fault detection

DS1 (T1/E1) cable cut

DS1 (T1/E1) cable cut

DS1 (T1/E1) cable cut

Sample section: Identified fault

Bad DS1 cable

Cable cut/disconnected between ER and MLS

Cable cut on serving IPBTS GW GigE interface - Standby GigE in-service

Cable cut on serving IPBTS GW GigE interface - Standby GigE out-of-service

Duplex IPGW access failures

Only remaining 5E GW goes OOS

No 1st Hop router connectivity

Edge router card failure affecting all associated DS1 interfaces

Active RCS IP goes OOS-F while mate AP is OOS-F

IPBH performance measures

5ESS measurement reports

5ESS DCS TRFM for IPBH

Safety and general information

Structure of hazard statements

Related network features

Network elements in an IPBH network and required changes

Document Roadmap of IPBH tasks

Differences between FR and IPBH

IP Backhaul network overview

Router and switch documentation resources

Bearer traffic protocols for IPBH network

Signaling traffic protocols for IPBH network

IPBH component IP addressing