Ipbh CL

IP Backhaul for CDMA Voice and Packet Data
IPBH Intoduction (3G1x and 1xEVDO)

CL1301
Student Guide
CL1301
Issue/Version 1.3 November 2007

Table of Contents
Introduction
Technical Support .................................................................................................................. 2i
PC Minimum Requirements ................................................................................................... 3i
Terms of Use and Legal Notices............................................................................................ 4i
How to use Adobe Presenter Controls................................................................................... 8i
Knowledge Check .................................................................................................................. 9i
Final Assessment ................................................................................................................ 10i
Course Outline ..................................................................................................................... 11i
Welcome .............................................................................................................................. 12i
Documentation..................................................................................................................... 13i
Lesson 1: IPBH Overview
Course Outline .................................................................................................................... 2L1
Lesson Objectives............................................................................................................... 3L1
New Terminolgy .................................................................................................................. 4L1
Topic 1: FR vs. IPBH........................................................................................................... 6L1
Topic 2: IPBH Architecture................................................................................................ 13L1
Lesson 2: 1xEV-DO MLPPP overview
Course Outline .................................................................................................................... 2L2
New Terminology ................................................................................................................ 4L2
Topic 1: HDLC vs. MLPPP.................................................................................................. 6L2
Topic 2: 1xEV-DO Architecture......................................................................................... 12L2
Lesson 3: Implementation overview
Couse Outline ..................................................................................................................... 2L3
Documentation.................................................................................................................... 4L3
Topic 1: Implementation Phases......................................................................................... 5L3
Topic 2: IP Network (Pre-conversion) .............................................................................. 11L3
Topic 3: T1 or E1 (Pre-conversion) ................................................................................... 25L3
Topic 4: BTS, 5ESS DCS, RNCs and ECPC MM-RCS AP (Pre-conversion).................. 29L3
Topic 5: Conversion 3G1x and 1xEV-DO ......................................................................... 58L3
Topic 6: Post deployment.................................................................................................. 74L3
Continued

Table of Contents
Lesson 4: IP Backhaul OA&M
Course Outline .................................................................................................................... 2L4
Topic 1: OA&M Overview.................................................................................................... 4L4
Topic 2: BTS OA&M.......................................................................................................... 24L4
Topic 3: 5ESS DCS AO&M............................................................................................... 31L4
Topic 4: ECPC OA&M Includes MM-RCS AP and RNC................................................ 40L4
Topic 5: ER and MLS OA&M ............................................................................................ 49L4
Lesson 5: Backhaul Server (BHS) Provisioning (FR/LAPD to IPBH Only)
Course Outline .................................................................................................................... 2L5
Topic 1: Cable Failures ....................................................................................................... 4L5
Topic 2: Communication Failures...................................................................................... 25L5
Topic 3: Software, Hardware and Configuration Failures ................................................. 44L5
Course Summary .............................................................................................................. 56L5

1i
All Rights Reserved Alcatel-Lucent 2007
CL1301
Release 28.0
IP Backhaul for CDMA Voice
and Packet Data
CL1301 Release 28
Introduction
11i
Course Outline
Introduction
IP Backhaul overview
- FR vs. IPBH
- IPBH Architecture
1xEV-DO overview
- HDLC vs. HDLC
- 1xEV-DO Architecture
Implementation overview
- Implementation Phases
- IP Network (Pre-conversion)
- T1/E1 (Pre-conversion)
- BTS, 5ESS DCS, RNCs and ECPC-
RCS-AP (Pre-conversion)
- Conversion 3G1X and 1XEV-DO
- Post deployment
OA&M
- OA&M Overview
- BTS OA&M
- 5ESS DCS OA&M
- ECPC OA&M Includes MM-RCS AP
and RNC
- ER and MLS OA&M
Fault management
- Fault types
- Monitoring tools
- Cable fault scenarios
- Communication fault scenarios
- Software/configuration fault
scenarios
The course outline screen appears at the beginning of each lesson. The red rectangle
borders the lesson and the major topics presented.
12i
Welcome!
This course is designed to enable the
student to:
Define IPBH in the 3G1x Voice and
Data Network
Define MLPPP in the 1xEVDO
Network
Define the activities performed
during implementation
Locate and perform basic OA&M
procedures
Locate and perform corrective
action procedures on basic faults
The duration of the course is
approximately 16 hours.
Welcome again to CL1301-IP Backhaul for CDMA Voice and Packet Data.
This course is designed to enable the student to:
Define IPBH in the 3G1X Voice Network
Define MLPPP in the 1XEVDO Network
Locate and perform basic OA&M procedures
Locate and perform corrective action procedures on basic faults
The duration of the course is approximately 8 hours.You can pause and replay the
course as often as necessary. However, maximum effectiveness comes from a
complete session.
13i
The primary documents* used in this course are the:
401-710-090 Flexent
Wireless Networks IP Backhaul for CDMA Voice and

Packet Data: This document describes the CDMA Backhaul Networks for
Flexent
/AUTOPLEX
wireless 3G1X Voice and Data and 1xEVDO networks.

401-710-094 Flexent
Wireless Networks IP Backhaul Transport Network:

This document defines the network configurations, physical connectivity and
router and MLS configurations for 3G1x Voice and Data and 1xEVDO.
Documents located on the Alcatel-Lucent OLCS web site:
http://support.lucent.com (OLCS Site)
If not logged on, logon and follow path below: (Customer Login and Password
required.)
- Select Documentation under Technical Support heading.
- Select CDMA IP Backhaul (IPBH) in Alphabetical Listing.
- Select Manuals and Guides under Documentation and downloads heading.
*Note: All other pertinent documents are shown in the tables in
- 401-710-090
- Chapter: CDMA Backhaul Networks
- Section: Backhaul documentation roadmap
Documentation
The primary documents used in this course are:
401-710-090 document describes the C-D-M-A Backhaul Networks for Flexent
or AUTOPLEX wireless 3-G-1-X and 1-X E-V-D-O networks
401-710-094 document defines the network configurations, physical connectivity
and router and M-L-S configurations.
1L1
and Packet Data
CL1301
Lesson 1 IP Backhaul overview
CL1301: IP Backhaul for CDMA Voice and Packet Data
Lesson 1 IP Backhaul overview
2L1
Course Outline
Introduction
- FR vs. IPBH
- IPBH Architecture
1xEV-DO overview
- HDLC vs. HDLC
- Post deployment
OA&M
- OA&M Overview
- BTS OA&M
- 5ESS DCS OA&M
and RNC
- ER and MLS OA&M
Fault management
- Fault types
- Monitoring tools
scenarios
IP Backhaul overview topics:
FR vs. IPBH
IPBH Architecture
3L1
After completing this lesson, you should be able to:
Describe the differences between backhaul network using Frame
Relay with Packet Pipe protocol and IPBH with Internet Protocol
List the benefits of IPBH over FR
Identify and describe the functions of the IPBH network elements
List the IPBH hardware and software requirements
Lesson 1 Objectives
*Note: A Glossary of Acronyms is an attachment to this lesson.
Describe the differences between backhaul network using Frame Relay with
Packet Pipe protocol and IPBH with Internet Protocol
List the benefits of IPBH over FR
Identify and describe the functions of the IPBH network elements
List the IPBH hardware and software requirements
A Glossary of Acronyms is included as an attachment with this lesson. (Click on the
attachments button .
4L1
Backhaul Association (BHA) Association between the Multi-link Group
(MLG) and the Backhaul Server (BHS) that forms a logical semi-permanent
path for carrying user traffic from the Base Transceiver Station (BTS) to the
Mobile Switching Center (MSC).
Backhaul Connection Server (BHCS): An IP Address in the routers and a
process in the Mobility Manager-Application Processor (MM-AP). The IP
Address is derived for the Control Subnetwork of an MSC. The router
provides this address to the BTS URC each time a MLG is initiated. The BTS
URC uses this address to query the BHCS process running on one of the
Mobility Manager-Application Processors (MM-APs) to obtain MSC resource
locations.
Backhaul Protocol Handler (BPH): IPBH interface (Ethernet) board
equipped in pairs in the Packet Switch Unit (PSU) of a Flexent Packet Switch
(FPS). A pair of BPHs are grouped as a BHS and operate in a Serving/Non-
serving configuration.
Backhaul Server (BHS): The logical representation of a pair of Backhaul
Protocol Handlers (BPHs) in the Packet Switch Unit (PSU) of a Flexent Packet
Switch (FPS) or the upper and lower IPBTS Gateway (IPBTS GW) GICC pair in
a Radio Network Controller (RNC).
New Terminology
IP Backhaul introduces the following new terms shown on this slide and the next.
Please review the new terms.
5L1
IP Base Transceiver Station Gateway (IPBTS GW): The hardware and
software functionality in the RNC that provides the IPBH gateway to the
BTS. A IPBTS GW is IP based and interfaces through a GICC external GigE
port.
Multi-Link Point-to-Point Protocol (MLPPP): A bandwidth-on-demand
protocol that has the ability to connect multiple links to increase or
decrease bandwidth as needed.
Multi-Link Group (MLG): A point-to-point interface between the BTS and
the router. An MLG has an IP address for both ends (BTS and router) of the
point-to-point interface.
User Datagram Protocol Mutiplexing (UDPmux): IPBH proprietary protocol
that multiplexes the bearer traffic into a single UDP datagram.
Note: A Glossary of Acronyms is an attachment to this lesson.
For a complete list of terms and acronyms, Refer to the 401-710-090
document Chapter: CDMA Backhaul networks; Topic: Industry and
network terminology
New Terminology
IPBH terms, please review.
For a complete list of terms and acronyms refer to the:
401-710-090 document
Chapter/Part: CDMA Backhaul networks
Topic: Industry and network terminology
6L1
IP Backhaul Overview
Topic 1: Frame Relay (FR) vs. IP Backhaul (IPBH)
Lesson 1: IP Backhaul Overview
Topic 1: Frame Relay versus IP Backhaul
7L1
Frame Relay
*Note: Packet Pipe (PP) protocol is a proprietary protocol.
MSC
Grooming
T1/E1
Multiplexer
5ESS DCS
P
H
A
DF2
MCTSI
OIU/
DNUS/
DLTU
FMM AP
Complex
PPs* + SLs on
T1s(NAR)/
E1s(International)
PSU
PPs delivered
to FRPH via
nailed up TSs in
the TSI
PPs delivered
to FRPH via
nailed up TSs in
the TSI
RCS
AP
RCS
AP
Signaling Links (SLs) delivered
to ECPC directly from DACS or
via 5ESS nail-up
Signaling Links (SLs) delivered
to ECPC directly from DACS or
via 5ESS nail-up
SLs on
DS0s over
T1/E1
Handoffs
PPs and SLs on
(NAR) OC3/STS1/T1
(Int.) STM1/E1
5ESS interface
units carry PPs
only or optionally
PPs with SLs
5ESS interface
units carry PPs
only or optionally
PPs with SLs
SLs delivered to
ECPC via
nailed up
connection
SLs delivered to
ECPC via
nailed up
connection
ATM
Network
F
R
P
H
F
R
P
H
F
R
P
H
F
R
P
H
SM
ECPC
FR vs. IPBH
In the current 3G1X voice and data wireless networks, traffic is transported between
the base stations and the MSC using Frame Relay. Frame Relay uses Packet Pipes to
transport the traffic. Packet Pipes are comprised of a DS0 bundle, a bundle can be
from 1 to 16 DSOs on a DS1 (NAR).
Traffic flow:
T1s or E1s carry the packet pipes and signaling links between the base station and
the multiplexer, for example a DACS.
The interface type between the multiplexer and 5ESS DCS depends on the type of
interface unit that is equipped in the switching module.
The packet pipes are delivered to Frame Relay Protocol Handlers over nailed up
time slots in the TSI.
On one of the DS1s from each digital shelf at a cell site, two DS0s are designated as
signaling links to the ECPC.
Signaling links either connect directly from the multiplexer to the ECPC or (7)via
nailed up times slots in the TSI.
8L1
Frame Relay
FR vs. IPBH
Packet Pipe - PP
Packet Pipes carry packetized voice or data between the Base Station and the DCS. At
the DCS they terminate at a DLTU, DNU-S or OIU where individual time slots
(DS0s) are separated onto individual channels. The channels pass through nailed-up
time slots in the TSIU and are then sent to the PSU2 where they are received on a
particular packet pipe channel group member at a FRPH (Frame Relay Packet
Handler).
Signaling Link SL
Signaling links carry signaling information between the Base Station and the DCS,
ECPC or MM. At the DCS signaling links terminate at the DLTU or DNU-S. where
individual time slots (DS0s) are separated onto individual channels. The channels pass
through nailed-up time slots in the TSIU and are then sent to the PSU2 where they are
received on a particular packet pipe channel group member at a Signaling Link PH.
Nailed-up time slots in the TSIU may also direct specific signaling links to the
ECPC/MM via a DLTU/DNU-S.
9L1
FR vs. IPBH
Frame Relay (FR) poses the following problems:
OAM&P
DS1s not well utilized
PPs require frequent re-engineering, re-sizing and re-provisioning
PPs and signaling links require fractional DS1 grooming
OPEX
Equipment required to terminate PPs at MSC
PPs consume TSI resources
Even when an RNC is deployed PSU SHO resources are consumed
Frame Relay - FR
Frame relay poses the following problems:
OAM&P:
DS1s are not well utilized.
Packet pipes require frequent re-engineering, re-sizing and re-provisioning
Signaling links require fractional DS1 grooming.
OPEX:
Cost of terminating equipment at MSC
TSI resources are consumed
Even if an RNC is deployed, PSU Soft Handoff resources are consumed.
10L1
OC3/
SDM1
RNC
5ESS DCS
D
F
I
D
F
I
TSI
DNU-S-
PSU2e
Edge
Routers
RCS
AP
FMM AP
Complex
Recovered fabric
capacity
Recovered fabric
capacity
FR vs. IPBH
F
R
P
H
DF2
F
R
P
H
F
R
P
H
T
I
C
C
T
I
C
C
T
I
C
C
T
I
C
C
T
I
C
C
T
I
C
C
T
I
C
C
RNC-AP
G
I
C
C
OIU
PSTN
ATM
SHO
T1s(NAR)/
E1s(Int.)
T1s(NAR)/
E1s(Int.)
(NAR) OC3/OC12
(Int.) STM1/STM4
(NAR) OC3/OC12
(Int.) STM1/STM4
FMM
LAN
Backhaul
Transport
Network
iPS
C
F
4
F
R
P
H
F
R
P
H
B
P
H
Gigabit
Ethernet
100BaseT
Ethernet
Multi-Layer
Switches
B
P
H
G
I
C
C
P
H
A
Other
DCSs
IPSHO
I
P
S
H
O
Other
DCSs
G
I
C
C
C
F
4
P
F
4
P
F
4
Bearer Traffic
and
Signaling
Signaling Links delivered
directly to RCS-APs via
Ethernet
Signaling Links delivered
directly to RCS-APs via
Ethernet
DNU-S/DLTUs
can be retired
from backhaul
usage
DNU-S/DLTUs
can be retired
from backhaul
usage
FRPHs can be
retired from
use.
FRPHs can be
retired from
use.
IP Backhaul - IPBH
With IP Backhaul signaling traffic is delivered to the MM LAN directly from the edge
router, eliminating DS0 grooming. User traffic is delivered directly to the Backhaul
Server equipped in the PSU2e or iPS cabinet at the 5ESS DCS, freeing up trunk
interface hardware, frame relay PHs and TSI resources. And data traffic is delivered
directly to the BHS on the 1xRNC for data offload, freeing up soft handoff resources.
11L1
FR vs. IPBH
IPBH provides the following:
OAM&P
DS1s fully utilized
Traffic from any carrier can utilize any DS1. DS1s are an increment of
bandwidth and added at a BTS as needed to support capacity growth.
Traffic and signaling are mixed over DS1s and separated at the IP
switching layer
OPEX
Connection at MSC elements is over Ethernet, rather than fractional
DS1 eliminating equipment and freeing up TSI resources
Voice and Data traffic is separated at the IP layer and sent directly
over Ethernet to DCS and RNC, freeing up SHO resources
IPBH provides the following.
OA&M:
The DS1s are fully utilized. Traffic from any carrier can utilize any DS1 and DS1s are
added to increase bandwidth. Traffic and signaling are mixed over DS1s and
separated at the IP switching layer.
OPEX:
The connections at MSC elements is over Ethernet eliminating interface equipment
and freeing up TSI resources. Voice and data traffic is separated at the IP layer and
sent directly over Ethernet to the DCS or RNC, freeing up Soft Handoff resources.
12L1
FR vs. IPBH
Data traffic from the MLS to the (optional)
1xRNC without involving 5ESS elements
Data traffic terminates on FRPH, then
routes to 1xRNC via PHA connection
Separation of
voice and data
traffic
IP over unchannelized DS1 at BTS
interface.
Utilization of DS1 capacity is part of IP
network, unlike FR that required
provisioning of the DS1 channels.
FR over fractional DS1 at BTS interface BTS interface
Ethernet interface at FMM-RCS DS1 interface to FMM-RCS FMM-RCS
interface
MLG provide multiple DS1s Maximum 24 (T1) DS0s used DS0/DS1 limit
No DS0 grooming for control links DS0 grooming for control links DS0 grooming
Control and traffic mixed over all DS1s Control links over dedicated DS0s Control links
2000 voice call legs per BHSPH Up to 240 voice call legs per FRPH
(depends on packet pipe occupancy)
Supported call
legs
Virtual connections based on provisioned
BTS/carrier/SOC-BHS assignments
Physical trunk group/member end-to-end
NxDS0 between URC and PSU2e
Connection
IP Backhaul FR packet pipe Category
The displayed table highlights the main differences between FR and IP Backhaul.
13L1
IP Backhaul Overview
Topic 2: IPBH Architecture
Lesson 1: IP Backhaul Overview
Topic 2; IPBH Architecture.
14L1
IPBH Architecture
The IPBH Network is comprised of the following components: (2 pgs.)
BTS Base Transceiver Station: Contains the radio equipment for the cell site. This
equipment processes and transmits and receives control and bearer information
between the antenna and the MSC. The following BTS Modcells support IP Backhaul:
- Modcell 4.0 with URC/URC-II card; H.D. 4.0 with URC/URC-II card; Modcell 4.0
Compact with URC/URC-II card and Modcell 1/2/3 with URCm card
URC-Universal Radio Controller: The URC provides the interface between the cell
site and the backhaul facilities. The following URCs with IP Transport support IP
Backhaul: URCm, URC or URC-II
ER-Edge Router: Interface between the WAN (BTS) and the LAN (MSC). They
determine the destination and then route the packets between the BTSs and the MSC.
The ERs are vendor neutral. However because of QoS issues Alcatel-Lucent has list
of recommended vendors.
MLS-Multi-Layer Switch: Interface between the LAN (ERs) and the MM-APs (RCS-
APs), the PSU2e (BHS BPHs) and the RNC (GICCs). They may be multi-layer
(L2/L3) switches or L2 only switches. The SWs (MLS) are vendor neutral. However
because of QoS issues Alcatel-Lucent has a list of recommended vendors.
RCS-Radio Cluster Server: Receives/transmits control signaling ISUP information
between the BTSs, RNCs and DCSs associated with the MSC. The RCS-AP has an
Ethernet interface to the SWs to provide this function in IPBH.
15L1
IPBH Architecture
The IPBH Network is comprised of the following components: (cont.)
BHS-Backhaul Server: Two (2) BPHs (Backhaul Protocol Handlers that operate in the
Server/Non-server 1+1 configuration for improved reliability. The BPHs have an
Ethernet interface to the SWs. They transport bearer traffic using a proprietary
application layer protocol, User Datagram Protocol Multiplexer (UDPMux).
GICC- Gateway Intelligent Carrier Card: Provides the Ethernet interface between the
RNC and the SWs (MLSs) for IPBH. Like the BPHs, two GICCs are equipped.
16L1
IPBH Architecture
No hardware change
Note: IP Backhaul supported on RCS operating on:
R1 FMM-APs
R1SR Host
R1SR Satellite
FMM-RCS
Hardware type Transport equipment
Edge routers Edge routers
Layer 2 or Layer 3 Multi-Layer Switch (MLS)
Upgrade URC card to URCm card BTS: Modcell 1/2/3 with URCm card
No hardware change BTS: Modcell 4.0 includes the following
with URC or URC-II
HD with URC or URC-II
Compact with URC or URC-II
MCTSI - Existing: Upgrade to Core700 or New: SMU6,
PSU2e - Backhaul Protocol Handler (BPH) based on PHE3
iPS BPH based on PHE4
5ESS DCS
Upgrade GICC card to GICC 1.1
Note: 1xRNC is an optional network element in NAR
market, and is not supported in International market.
1xRNC
New hardware Network element
The table lists the hardware needed to implement IP Backhaul in a network.
17L1
IPBH Architecture
IP Backhaul Network interfaces:
BTS to Router - BTS Physical Layer: Unchannelized DS1
DS1 terminations toward Edge Router: T1/T3/OC-3/OC-12
All traffic and signaling/control is multiplexed onto DS1s (DS1/NxDS1) and the IP
layer routes packets to and from the MSC elements.
Router to Switch - The interface between the ERs and SWs is flexible L1/L2
wideband uplinks. The VRD-5576 contains the requirements for the Routers and
Switches. Ask your Lucent Technologies representative for this information.
Switch to RCS-AP/BPH/GICC
RCS-AP: 100 Mbps Ethernet link between Switches and each MM Growth Frame.
The two links are redundant. RCS-APs communicate with BTSs over the same two
Ethernet interfaces used for internal AP-to-AP communications.
BPH: 100 Mbps Ethernet link between Switches and the BPHs. The links to the two
BPHs that make up a BHS are redundant. One BPH is serving (ACT) and the other is
non-serving (STBY).
GICC: GigE Ethernet link between Switches and the GICCs. Like the BPHs, two
GICCs (ACT & STBY) make up a BHS.
18L1
IPBH Transport Network Topology (Example using OC3)
IPBH Architecture
IPBH transport network:
T1 concentrator: Network interface between the BTSs and the ERs. It converts
between the T1 and OC3 or 12 and provides the T1 clock source and Automatic
Protection Switching.
ERs: Operate active-active and are provisioned so that the T1s carrying traffic are
distributed equally.
GigE links: Connect between the MLSs and the ERs to provide full redundancy.
19L1
IPBH Architecture
IP Backhaul Protocol Stacks (2 pgs.)
The IPBH protocol stacks are displayed above.
Application Layers:
User Datagram Protocol Multiplexer: UDPMux is a Lucent Technologies proprietary
protocol. It allows several UDP Packets to be bundled and sent together and later de-
multiplexed. (Used at BTS URCs, RCS-APs, BPHs and GICCs.)
User Datagram Protocol: UDP protocol, at a higher level than IP, provides basic
datagram transmission service between hosts; Layer 4 - Transport; it is at the same
level as TCP. (Part of protocol stacks for Bearer Traffic at BTS URCs and DSC BPHs
and RNC GICCs.)
Internet Protocol: IP is a network layer protocol specifying the format of packets
(datagrams) and the addressing scheme. (Part of protocol stacks for all elements of the
IPBH network.)
Point-to-Point and Multi-Link Point-to-Point Protocol: Point-to-Point Protocol (PPP -
DS1) and ML-PPP (NxDS1) is an encapsulation protocol for transporting IP traffic
over point-to-point links. (Used at the BTS URCs, ERs and MLSs.)
Digital Signal Level 1: DS1 is 24 8KHz channels (DS0s) at an aggregate 1.544Mbps
(aka T-1). Carries the bearer, signaling or control information. (Multiplexed at BTS
URCs converted between DS1 and Ethernet at MLSs.)
20L1
IPBH Architecture
Application Layers: (cont.)
Ethernet: International standard networking technology for wired implementations.
(Physical layer between MLSs and RCS-APs, BPHs or GICCs.) Ethernet bit rates:
- 100 Base T (100Mbps)
- GigE (1000 mbps)
(Carries bearer, signaling or control information between MLSs and RCS-APs, BPHs
or GICCs.)
Transmission Control Protocol/IP: TCP is a major Internet protocol, at higher level
than IP; enables two hosts to establish a connection and reliably exchange
information. (Used for Signaling/Control packets at BTS URCs and MM-RCS APs.)
21L1
IPBH Architecture
IP Backhaul Redundancy:
To provide reliability, the IP Backhaul network is duplicated in all areas.
At the BTSs, multiple URCs have MLGs that interface to the ERs. There is also a
diverse geographic R-F coverage across URCs.
Automatic protection switching for the SONET interfaces exists between transmission
network equipment and the ERs.
OSPF provides link protection between the ERs and the SWs (MLSs). VRRP provides
redundancy protection between the ERs and the MM-RCS AP and the DCS for RNC
BHSs.
The multi-layer switches are redundant as is the cross-coupling between them in the
ERs. The Ethernet interface to the MM-RCS APs and the BHSs is redundant.
The MM-RCS AP site has access to both LANs, and the RCS APs are equipped in
pairs and operate in an active/standby configuration. The BPHs and GICCs are
equipped in pairs and operate in a serving/non-serving 1+1 sparing configuration.
22L1
IPBH Architecture
Cisco 6509e (M40e/10K)
Alcatel-Lucent 7750 (M40e only
MLS
Juniper M40e (MS100 PICs Juniper Only)
Cisco 10K
Riverstone 8600
Edge Routers (ER)
GICC 1.1 cards (SC-GICC cards do not support IPBH) 1XRNC
No change. RCS AP
PSU2e: PHE3 packs equipped in pairs as a BHS
iPS: PHE4
Alcatel-Lucent Packet
Switch
Formerly (FPS)
Modular cell 4.0 with URC or URC-II
Modular cell HD 4.0 with URC or URC-II
Modular cell 4.0 Compact with URC or URC-II
Modular cell 1/2/3 with URCm only
BTS
Hardware Network Element
The displayed table shows the network hardware required for IPBH.
23L1
5ESS DCS
Release 26.0 or later MM-RCS AP
Release 26.0 or later
Cell (BTS)
Software Network Element
IPBH Architecture
Required software:
IOS 12.3(7) x 18b or later approved* release Cisco 10K
CATOS 12.2918 or later approved* release Cisco 6509e
TiMOS 4.0.R11 or later approved* release Alcatel-Lucent 7750
Release 26.0 or later 1x RNC
5E19.1 SR or later
JUNOS 8.1 R2.4 or later approved* release Juniper M40e
*Note: All vendor software has to be tested and approved by Alcatel-Lucent for the
application.
The displayed table shows the required software for MLPPP.
As noted all vendor products software has to be tested an approved by Alcatel-Lucent
before it can be used.
24L1
*Note: For a complete list of IPBH documentation refer to the
Backhaul documentation roadmap section in the CDMA Backhaul
Networks chapter of the 401-710-090 document.
IPBH Architecture
IP Backhaul Transport Network (401-710-094)
Vendor documentation
Multi-Layer Switch
Edge router
IP Backhaul and Ethernet Backhaul (401-710-090)
1xRNC OA&M (401-710-082)
1X-Radio Network Controller
(RNC) (optional)
5ESS DCS OA&M (235-200-100)
5ESS Digital Cellular Switch
(DCS)
RCS OA&M (401-710-102)
FMM-Radio Cluster Server
(RCS)
Modcell 4.0 OA&M (401-703-407)
Modcell 1.0, 2.0, 3.0 OA&M (401-710-422)
Base Transceiver Station
(BTS)
Documentation* Hardware
The table displayed shows the documentation for the different hardware elements of
the IPBH network.
For a complete documentation list, refer to:
Chapter/Part: CDMA Backhaul Networks
Topic/Section: Backhaul documentation roadmap
1L2
and Packet Data
CL1301
Lesson 2 1xEV-DO MLPPP overview
CL1301
Lesson 2, 1xEV-DO MLPPP overview
2L2
Course Outline
Introduction
- FR vs. IPBH
- IPBH Architecture
1xEV-DO overview
- HDLC vs. MLPPP
- Post deployment
OA&M
- OA&M Overview
- BTS OA&M
- 5ESS DCS OA&M
and RNC
- ER and MLS OA&M
Fault management
- Fault types
- Monitoring tools
scenarios
1xEV-DO MLPPP overview topics:
HDLC vs. MLPPP
1xEV-DO Architecture
3L2
Describe the differences between 1xEV-DO using HDLC and MLPPP
List the benefits of MLPPP over HDLC
Identify and describe the functions of the 1xEV-DO network
elements
List the 1xEV-DO MLPPP hardware and software requirements
Lesson 2 Objectives
Describe the differences between 1xEV-DO using HDLC and MLPPP
List the benefits of MLPPP over HDLC
Identify and describe the functions of the 1xEV-DO network elements
List the 1xEV-DO MLPPP hardware and software requirements
attachments button .)
4L2
Backhaul Connection Server (BHCS): An IP Address in the routers
and a process in the Mobility Manager-Application Processor (MM-
AP). The IP Address is derived for the Control Subnetwork of an MSC.
The router provides this address to the BTS URC each time a MLG is
initiated. The BTS URC uses this address to query the BHCS process
running on one of the Mobility Manager-Application Processors (MM-
APs) to obtain MSC resource locations.
Backhaul Server (BHS): The logical representation of a pair of
Backhaul Protocol Handlers (BPHs) in the Packet Switch Unit (PSU) of
a Flexent Packet Switch (FPS) or the upper and lower IPBTS Gateway
(IPBTS GW) GICC pair in a Radio Network Controller (RNC).
IP Base Transceiver Station Gateway (IPBTS GW): The hardware
and software functionality in the RNC that provides the IPBH
gateway to the BTS. A IPBTS GW is IP based and interfaces through a
GICC external GigE port.
Multi-Link Group (MLG): A point-to-point interface between the BTS
and the router. An MLG has an IP address for both ends (BTS and
router) of the point-to-point interface.
New Terminology
1xEV-DO Multi Link Point-to-Point protocol introduces the following new terms that
are shown on this and the next slide. Please review the new terms.
5L2
Multi-Link Point-to-Point Protocol (MLPPP): A bandwidth-on-
demand protocol that has the ability to connect multiple links to
increase or decrease bandwidth as needed.
User Datagram Protocol Mutiplexing (UDPmux): IPBH proprietary
protocol that multiplexes the bearer traffic into a single UDP
datagram.
Refer to the 401-710-090 document for a complete list of
terms/acronyms:
Chapter: CDMA Backhaul networks
New Terminology
IPBH terms, please review.
For a complete list of terms and acronyms refer to the:
Chapter/Part: CDMA Backhaul networks
6L2
1xEVDO MLPPP Overview
Topic 1: HDLC vs. MLPPP
Lesson 2: 1xEV-DO MLPPP Overview
Topic 1: High-level Data Link Control (HDLC) Protocol versus Multi-Link
Point-to-Point Protocol (MLPPP)
7L2
HDLC vs. MLPPP
HDLC (High-level Data Link Control) Protocol:
Layer 2 data link layer protocol
Encapsulates data on synchronous serial data links
Requires a /30 subnet per T1 to form a PPP (Point-to-Point
Protocol) connection
Cells with many T1s (N) will require N
*
/30 addresses
EVDO BTS also has /27 subnet addresses for LIU, MCC, etc.
HDLC T1s evenly distributed between URCs and two routers
(Normal Practice)
DO-RNC
T1s
URC 2 T1-1
URC 2 T1-2
URC 2 T1-3
URC 2 T1-4
10.33.4.11
10.33.4.12
10.33.4.13
10.33.4.14
MLS
MLS AR
AR
OC3/
OC12
T1
Concentrator
10.33.4.11
10.33.4.12
10.33.4.13
10.33.4.14
DHCP
HDLC
High-level Data Link Control (HDLC) Protocol:
Layer 2 data link layer protocol
Encapsulates data on synchronous serial data links
Requires a /30 subnet per T1 to form a PPP (Point-to-Point Protocol) connection
Cells with many T1s (N) will require N * /30 addresses
EVDO BTS also has /27 subnet addresses for LIU, MCC, etc.
HDLC T1s evenly distributed between URCs and two routers (Normal Practice)
8L2
HDLC vs. MLPPP
MLPPP (Multi-Link PPP) and MLG (Multi-Link Group):
MLPPP: Group of physical links (T1s) combined into a single logical
link between BTS and AR to increase bandwidth availability on
demand
MLG: MLPPP logical link identifier. Only one /30 subnet address is
needed per MLG*, not per T1
*Note: T1s assigned to an MLG must be from same URC. (R28)
DO-RNC
T1s
MLS
MLS AR
AR
OC3/
OC12
T1
Concentrator
URC 2 T1-1
URC 2 T1-2
URC 2 T1-3
URC 2 T1-4
10.33.4.11
10.33.4.11
DHCP
MLG
MLPPP
10.33.4.11
10.33.4.12
10.33.4.13
10.33.4.14
10.33.4.11
10.33.4.12
10.33.4.13
10.33.4.14
HDLC
MLPPP and MLG
Multi Link Point-to-Point Protocol groups the physical T-1 links into a single logical
link between the B-T-S and the A-R to increase bandwidth availability on demand.
The Multi Link Group is the logical link identifier. Only one slash 30 subnet address
is needed per MLG, eliminating the need for a per T-1 address.
9L2
HDLC vs. MLPPP
DO-RNC
URC 1 T1-1
URC 1 T1-2
URC 1 T1-3
URC 1 T1-4
URC 1 T1-5
URC 1 T1-6
URC 1 T1-7
URC 1 T1-8
10.33.4.1
10.33.4.2
10.33.4.3
10.33.4.4
10.33.4.5
10.33.4.6
10.33.4.7
10.33.4.8
URC 2 T1-1
URC 2 T1-2
URC 2 T1-3
URC 2 T1-4
10.33.4.11
10.33.4.12
10.33.4.13
10.33.4.14
MLS
MLS AR
AR
OC3/
OC12
T1
Concentrator
10.33.4.1
10.33.4.2
10.33.4.3
10.33.4.4
10.33.4.5
10.33.4.6
10.33.4.7
10.33.4.8
10.33.4.11
10.33.4.12
10.33.4.13
10.33.4.14
DHCP
HDLC
T1s
Example of an HDLC configuration with:
URCII with 8 T1s assigned
URC/URCm with 4 T1s assigned
IP Addresses:
HDLC configuration showing IP address assignments at BTS URCs and DHCP.
10L2
DO-RNC
T1s
URC 1 T1-1
URC 1 T1-2
URC 1 T1-3
URC 1 T1-4
URC 1 T1-5
URC 1 T1-6
URC 1 T1-7
URC 1 T1-8
1
0
.
3
3
.
4
.
1
URC 2 T1-1
URC 2 T1-2
URC 2 T1-3
URC 2 T1-4
10.33.4.11
MLS
MLS AR
AR
T1
Concentrator
10.33.4.1
10.33.4.11
DHCP
MLPPP-MLG
OC3/
OC12
Example of an MLPPP-MLG configuration with:
URCII* with 2-8 T1s assigned
URC/URCm* with 2-4 T1s assigned
*Note: In R28 up to 4 T1s can be assigned per MLG. In R29 up to 8 T1s can be assigned
per MLG.
1
0
.
3
3
.
4
.
2
1
0
.
3
3
.
4
.
1
HDLC vs. MLPPP
IP Addresses:
MLPPP configuration showing IP address assignments at BTS URCs and DHCP after
conversion.
11L2
HDLC vs. MLPPP
Benefits of MLPPP:
Bundling of T1s under the same MLG simplifies IP address
management per BTS
Improves throughput and reduces latency
MLPPP is an industry standard that is tuned to support EV-DO QoS
capabilities
Future:
Shared DS1: Support of both EV-DO and 3G1X voice traffic on same
T1
Benefits of MLPPP:
M-L-P-P-P bundles T-1s under the same M-L-G, which simplifies IP address
management. It improves throughput and reduces latency. Unlike H-D-L-C, M-L-P-P-
P is and industry standard that is tuned to support EV-DO quality of service
capabilities.
In the future M-L-P-P-P will support both EV-DO and 3-G-1-X voice traffic on the
same T-1.
12L2
1xEVDO MLPPP Overview
Topic 2: 1xEV-DO Architecture
Lesson 2: 1xEV-DO MLPPP Overview
Topic 2; 1xEV-DO Architecture.
13L2
The following graphic displays the Standalone EVDO
configuration. There is no change to configuration for MLPPP.
Active
Protect
T1s
DO-RNC
MLS
MLS AR
AR
OC3/
OC12
T1
Concentrator
BTS
BTS
BTS
BTS-Base Transceiver Station:
Provides the air interface to the
end users access terminal (AT)
and converts the IS895 air
interface to the IP format for the
backhaul part of the RAN.
T1s connect
between the BTS
URCs and the T1
Concentrator.
AR-Aggregation Router:
Routes the packets
between the BTSs and
the DO-RNCs
MLS-Multi-Layer Switch:
Performs the L3/L2
switching between the
DO-RNC and the ARs.
1xEV-DO RNC: Consists
of application processors
(APs) and traffic processors
(TPs) that control the
1xEV-DO system and
interface to the 1xEV-DO
BTS, 1xEV-DO EMS, and
PDSN.
The T1 Concentrator
packages the T1s from
the BTSs into designated
OC3s/12s to the ARs and
unpacks from AR to BTS.
Standalone 1xEV-DO Architecture:
There is no change to the EV-DO radio access network configuration for MLPPP.
There is also no change to the functions of the elements in the configuration.
14L2
EV-DO can also be configured in the IPBH network.
Active
Protect
T1s
MLS
MLS ER
ER
OC3/
OC12
T1
Concentrator
BTS
BTS
BTS
FMM-AP
(RCS-AP)
1x-RNC
DCS (5ESS)
iPS/PSU2e
DO-RNC
Shared 1xEV-DO Architecture:
The EV-DO RNC can also be configured in the IPBH network.
15L2
The changes for HDLC to MLPPP are primarily at the BTSs and
the ARs. The change may also require reconfiguration of the
T1s.
Active
Protect
T1s
DO-RNC
MLS
MLS AR
AR
OC3/
OC12
T1
Concentrator
BTS
BTS
BTS
MLPPP changes in 1xEV-DO Network:
The changes for HDLC to MLPPP are primarily at the BTSs and the ARs. In existing
networks, conversion to MLPPP, may also require reconfiguration of the T1s.
16L2
Cisco 6509e (M40e/10K)
Alcatel-Lucent 7750 (M40e only)
Multi-Layer Switch
(MLS)
Juniper M40e (MS100 PICs Juniper Only)
Cisco 10K
Aggregation Routers
(AR)
No changes needed. 1xEV-DO RNC
BTS with one of the following types of cells:
BTS
Required hardware:
Required Hardware:
The displayed table shows the required hardware for MLPPP.
17L2
JUNOS 8.1 R2.4 or later approved* release Juniper M40e (AR)
Release 28.0 or later 1xEV-DO RNC
Cell (BTS)
Required software:
IOS 12.3(7) x 18b or later approved* release Cisco 10K (AR)
CATOS 12.2918 or later approved* release Cisco 6509e (MLS)
TiMOS 4.0.R11 or later approved* release Alcatel-Lucent 7750
(MLS)
*Note: All vendor software has to be tested and approved by Alcatel-Lucent for the
application.
Required Software:
The displayed table shows the required software for MLPPP. As noted all vendor
products software has to be tested an approved by Alcatel-Lucent before it can be
used.
1L3
and Packet Data
CL1301
Lesson 3 Implementation overview
Lesson 3 Implementation overview
2L3
Introduction
- FR vs. IPBH
- IPBH Architecture
1xEV-DO overview
- HDLC vs. HDLC
- Post deployment
OA&M
- OA&M Overview
- BTS OA&M
- 5ESS DCS OA&M
and RNC
- ER and MLS OA&M
Fault management
- Fault types
- Monitoring tools
scenarios
Course Outline
Implementation overview topics:
This lesson addresses the topics shown in the bordered area.
3L3
List the implementation phases and the associated activities
Identify the activities performed for pre-conversion
Identify the activities performed for conversion
Identify the activities performed during post deployment
Lesson 3 Objectives
Lesson 1 Objectives:
After completing this lesson, you should be able to list the implementation phases and
associated activities. Identify the activities performed for pre-conversion. Identify the
activities performed for conversion. And, identify the activities performed during post
conversion.
4L3
This lesson is an overview of the implementation process. For detailed
information refer to the IP Backhaul implementation chapter in the
following document*.
401-710-090: Document located on the Alcatel-Lucent OLCS web site:
required.)
Documentation
*Note: Documentation and training required for specific functions will be referenced
where used in this lesson.
Document:
This lesson is an overview of the implementation process. Detailed information is in
the IP Backhaul Implementation chapter of the 401-710-090 document.
5L3
Implementation Overview
Topic 1: Implementation Phases
Lesson 3 - Implementation overview
Topic 1 - Implementation Phases
6L3
Implementation Phases
Implementation Phases:
1. Pre-conversion: Activities that are performed without impact on
stable/transient calls.
2. Conversion: Activities performed during the conversion of the BTS
from FR/LAPD or HDLC to ML-PPP.
3. Post Deployment: Activities performed to reclaim FR/HDLC
resources and clean up provisioning.
Implementation Phases:
The implementation phases are Pre-conversion, Conversion and Post deployment.
Descriptions of the function of each is shown above.
7L3
Pre-conversion:
Installation of IP Network hardware if required (ERs and MLSs)*
Installation of new hardware to support feature/release
Update/retrofit to new release
Update of database parameters
Retrieval of backplane serial numbers (BPSN) for each BTS
assemblage
Pre-conversion:
The pre-conversion implementation phase includes the following activities:
Installation of IP Network hardware if required (ERs and MLSs)*
Installation of new hardware to support feature/release
Update/retrofit to new release
Update of database parameters
Retrieval of backplane serial numbers (BPSN) for each BTS assemblage
8L3
Conversion:
Run conversion tools to convert BTSs to IP backhaul
Run Fallback to return BTSs to previous state (optional used only if
required)
Run Commit program (Optional: IPBH only)
Conversion:
The Conversion implementation phase includes the following activities:
Run conversion tools to convert BTSs to IP backhaul
Run Fallback to return BTSs to previous state (optional used only if required)
Run Commit program (Optional: IPBH only)
9L3
Post Deployment:
Activities required to reclaim FR resources and clean up
provisioning
Post deployment:
The Post Deployment implementation phase activities reclaim FR resources and clean
up provisioning.
10L3
CDMA Engineering
*Note: Packet switch (PS) Alcatel-Lucent Packet Switch
Formerly Flexent Packet Switch
CDMA2000 IP Backhaul Engineering Guidelines
Capabilities
Provision Internet Protocol (IP) Backhaul Services for
Protocol Handler for Ethernet Model 3 (PHE3)
Provisioning
Protocol Handler (PH) Growth Growth
Topic/Sub-topic Chapter/Section
401-610-009 System Capacity Monitoring and Engineering Guidelines (SCME) for
CDMA
Engineering document:
Engineering information for the IP Backhaul conversion is located in the
401-610-009 document.
11L3
Topic 2: IP Network (Pre-conversion)
Topic 2 - IP Network (Pre-conversion)
12L3
This Topic overviews the installation of the IP Network. For detailed
information on whats presented in this topic refer to the following
document*.
401-710-094: Document located on the Alcatel-Lucent OLCS web site:
required.)
Documentation
Document:
This topic provides an overview of the installation of the IP Network. For detailed
information on whats presented in this topic refer to the 401-710-094 document.
13L3
Installation of IP Network (IPBH first time).
Grow in ERs and MLSs to provide IP connectivity between the BTSs
and the MSC*.
IP Network (Pre-conversion)
T1s
T1
Concentrator
BTS
BTS
BTS
MM-AP
(RCS-AP)
1x-RNC
DCS (5ESS)
iPS/PSU2e
DO-RNC
MLS
MLS
Active
Protect
ER
ER
OC3/
OC12
*Note: If IP Network exists, new hardware may be required to support the
addition of Cells, URCs or adding 1xEV-D0 MLPPP in the network.
Installation of IP Network (IPBH 1st time):
The ERs and MLSs are installed to provide IP connectivity between the
BTSs and the MSC components.
14L3
Installation of IP Network:
Prior to beginning the installation of the IP Network the following
or equivalent should be completed and available*:
IPBH/DO-MLPPP Customer Questionnaire
Customer Network Design Document (CNDD)
*Note: The completion of the IPBH/DO-MLPPP Customer Questionnaire is
completed by the customer and Alcatel-Lucent representative to
determine required hardware, provisioning and the IP Addresses used. The
questionnaire is used to produce the Customer Network Design Document
- CNDD. For more information on this contact your Alcatel-Lucent
representative.
Prior to beginning the installation of the IP network the following or an equivalent
should be completed and available:
IPBH or DO MLPPP Customer Questionaire
Customer Network Design Document (CNDD)
For the initial startup of IPBH in an MSC it is recommended that you contact your
Alcatel-Lucent representative to set up the integration of the IPBH network into your
existing FR or EV-DO network.
15L3
Hardware installation and cabling
It is recommended that this work be done by LWS Installation.
Equipment is either 3
rd
party vendor or Alcatel-Lucent*
Riverstone 8600
Multi-Layer Switch (MLS)
Alcatel-Lucent 7750
Cisco 6509e
Cisco 10K
Edge Router (ER)
Juniper M40e
*Note: Detailed descriptions of the ERs/ARs and MLSs are found in vendor product
documentation. Cabinet layouts and example equipage tables are found in
the 401-710-094 document. A copy of this information is in the
ER and MLS.pdf attachment to this lesson.
Routers (ERs/ARs) and Multi-Layer Switches (MLSs):
Recommended products for the ERs and MLSs are shown in table above. Detailed
information is found in the 401-710-094 document. For OA&M information refer to
the Alcatel-Lucent 7750SR documentation or the vendor product documentation.
16L3
Interconnections between components
IPBH
EV-DO
5ESS DCS PS 5ESS DCS PS FastE copper/fiber GigE Fiber (iPS) FastE copper/fiber GigE Fiber (iPS)
Interconnections between IPBH network elements:
The tables displayed show the interconnections between the components of the IPBH
network.
17L3
IP Addressing
Cell URCs, MSC components, ERs and MLSs are considered IP
endpoints for signal and traffic routing.*
Each has a unique IP address associated with it.
The IP addresses for the Cell URCs are manually configured in the
ERs (3G1X or Shared) or ARs (EVDO Standalone).
The MSC components derive their IP addresses from either:
A Control Subnetwork address, or
Are manually provisioned
The IP addresses used are in a set range and:
Class B address range used: 172.16.0.0 through 172.21.255.255
IP Addresses are private within an MSC
Can be duplicated on different MSCs
*Note: For more detailed information refer to:
- 401-710-094 IP Backhaul Transport Network
- 401-710-090 IP Backhaul and Ethernet Backhaul
Part: IP Backhaul network overview
Section: IP Addressing
IP Addressing:
Cell URCs, MSC Components, ERs and MLSs are considered IP endpoints. Each has
a unique IP address associated with it. The IP addresses for the Cell URCs are
manually configured in the ERs or ARs. The MSC components derive the IP
Addresses from either a control sub-network address or are manually provisioned.
The IP addresses used are in a set range as shown.
Detailed information is found in the following documents:
Chapter/Part: IP Backhaul and Ethernet Backhaul
Topic/Section: Backhaul documentation roadmap
18L3
IP Addressing
The following graphic shows the IP addressing endpoints.
MLS
ER MLS
ER
MM-AP
(RCS-AP)
T1
Concentrator
1x-RNC
Active OC3
Protect OC3
T1s
DCS (5ESS)
iPS/PSU2e
IP Address Endpoints:
The graphic displays the IP addressing endpoints in the network.
19L3
MLS
ER
DCS (5ESS)
iPS/PSU2e
MLS
ER
T1
Concentrator
MM-RCS AP
Active OC3
Protect OC3
T1 MLGs
IP Address for
each MLG (within
BTS subnet).
Provisioned in ER.
IP traffic Gateway
Address for each
ER (within each
traffic subnet)
3 IP addresses
per BHS (within
FPS traffic
subnet)
3 IP addresses
per BHS (within
RNC traffic
subnet)
Block of 2048
addresses (/21) for the
control subnet.
Includes RCS-APs,
BHCS, and Gateways.
Control and BHCS
Gateway IP Addresses
for each ER (within
each control subnet)
IP Addressing
The following graphic describes
some of the primary IPBH IP
addresses.
1x-RNC
IP Addresses:
The graphic describes the IP addresses for the URC MLGs, ER Gateway, Control and
BHCS, RNC, 5ESS DCS and the MM-RCS AP.
20L3
VLAN Virtual LAN: Configured to maintain isolation of traffic
between the various MSC components.
3G1X Voice: Alcatel-Lucent Packet Switch
3G1X Data: 1xRNC
1xEV-DO: DO-RNC
QoS Quality of Service
Due to the sensitive nature of Voice Bearer traffic, prioritization of
traffic flow is required.
Traffic originated at URCs and MSC components mark egress traffic
packets with differentiated code points.
Routers classify the packets based on these markings.
DiffServ code point values are defined as follows (IEEE 802.1P):
Installation of the IP Network:
VLANs are configured to maintain isolation of traffic between the MSC components
listed. Quality of Service is required in the ERs or ARs to prioritize traffic due to the
sensitive nature of Voice Bearer traffic (3G1x and 1xEV-DO[VOIP]). Traffic
originated at URCs and MSC components mark egress traffic packets with
differentiated code points. Routers classify the packets based on these markings.
DiffServ code point values are defined in the table above.
21L3
To provide detection of failures in the transport network and
reconvergence of routing paths due to these failures, routing
protocols will run on the ERs/ARs and MLS.
Layer 3 protocols:
OSPF Open Shortest Path First
Maintains a connection map between routers and MLSs in the network
Propagates routing information that allows the BTSs and MSC components
to communicate with each other
BFD Bidirectional Forward Detect
Uses sub-second hello packets to detect route between two peers, and
Works in conjunction with a routing protocol (i.e. OSPF) to remove the
route
VRRP Virtual Router Redundancy Protocol or
HSRP Cisco: Hot Standby Router Protocol
Allows one of the MLSs to act as the master for the BHS gateway
addresses
If master fails or path to MLS fails, gateway addresses will move to the
backup MLS
Layer 3 Protocols used to maintain connection maps and detect failures:
To provide detection of failures in the transport network and reconvergence of the
routing paths due to these failures, routing protocols will run on the ERs or ARs and
the MLS. The required Layer 3 protocols are OSPF, BFD and VRRP or HSRP.
Descriptions of each are shown above.
22L3
To provide detection of failures in the transport network and
reconvergence of routing paths due to these failures, routing
protocols will run on the ERs/ARs and MLS.
Layer 2 protocols*:
RST Rapid Spanning Tree
Protects against unwanted routing loops in the domain
Operational within the MM-AP network
PVRST Per VLAN RST (Optional)
Blocks loops at a VLAN granularity
Operational within the FPS-BHS, RNC-BHS and MLS to MLS interfaces
LACP Link Aggregation Control Protocol
Protects links if they are erroneously misconfigured
Operational for the GigE links between the tow MLSs
*Note: Detailed descriptions and setup information for the Layer 3 and 2 protocols
is found in the 401-710-094 document.
Layer 2 Protocols used for detection of failures:
The required Layer 2 protocols are Rapid Spanning Tree, Per VLAN RST, which is
optional and Link Aggregation Control Protocol.
Descriptions of Layer 2 protocols are shown above.
23L3
T1/E1 Configuration (ER/AR)
BTS URC T1s/E1s grouped into MLGs
MLG size
1 to 4 (URC/URCm)
1 to 8 (URCII)
MLG is configured first and then the T1s/E1s are configured as an
MLPPP bundle
APS Automatic Protection Switching
To provide redundancy for router failure and OC-3/STM-1 link failure
the SONET APS capability is used.
The following OC-3/STM-1 APS features should be supported by the
T1/E1 concentrator and the routers:
Non revertive
1 + 1
STS - Synchronous Transport Signal
Bidirectional APS
K1, K2 messaging
To support failover MLGs and MLPPP bundles are duplicated on the:
Primary Router, and
Secondary
T1/E1 configuration requirements in the ERs or ARs:
URC T1s or E1s are grouped in MLGs, which can be from 1 to 8 T1s/E1s per MLG.
The MLG is configured first on the routers and then the T1s or E1s are configured as
an MLPPP bundle.
APS provides redundancy for router or link failures. The APS features listed should
be supported by the concentrator and the routers.
MLGs and MLPPP bundles are duplicated on the routers to support failover.
24L3
Master Clock Source
Source can be either the router (internal) or the T1/E1
Concentrator (external)
URCs are not a viable clock source
Preference: T1/E1 Concentrator provide
a BITS/GPS (Stratum1) reference clock
source to both the URCs and the routers
Option: If necessary, router can
provide Stratum 3 clock source
Note: IPBH supports router source
clocking in the dual router
configuration because all
T1s/E1s from a URC are
connected to the same
router.
Master Clock:
A master clock is required for the T1 and OC3 or OC12 transport and for the
international E1 and STM-1 transport. The source of this timing can be either the
router or the T1 or E1 concentrator. The URC is not a viable clock source.
The preferred configuration has the T1 or E1 concentrator providing a BITS or GPS
reference clock source to both the URCs and the routers. If this configuration is not
available, the router can provide a sufficient clock source at a Stratum 3 level.
IPBH supports router source clocking in the dual router configuration because all T1s
or E1s from a URC are connected to the same router.
25L3
Topic 3: E1 (Pre-conversion)
Topic 3: T1 or E1 (Pre-conversion)
26L3
E1 (Pre-conversion)
E1 Configuration
BTS URC E1s are grouped as an MLGs
Parameter settings need to be consistent between the:
BTSs
E1 Concentrator and
ERs or ARs
Tables listing the parameters and detailed information on the
E1s are located in the 401-710-094 document:
Chapter 1: Transport Configuration Definition
Topic: E1s (International Configuration)
T-1 or E-1 configuration:
For each equipped BTS URC the T1s or E1s are grouped as an M-L-G. The
parameter settings need to be consistent between the BTSs, concentrators and routers.
Tables in the 401-710-094 list the parameters and provide detailed information on
configuring the T1s or E1s
Table locations:
401-710-094
Chapter/Part: Transport Configuration Definition
Topic/Section: T1s (Domestic Configuration)
Topic/Section: E1s (International Configuration)
27L3
E1 (Pre-conversion)
E1 Concentrator
Maps the E1s of MLGs from multiple URCs onto multiple
channelized OC3/12 or STM-1 links
URC E1s (MLGs) must be mapped onto the same channelized
link
Tables listing the requirements and detailed information on the
T1s/E1s are located in the 401-710-094 document:
Topic: E1s (International Configuration
E1 Concentrator:
The concentrator maps the interfaces from multiple URCs on channelized links. T1
and E1s of an MLG must be mapped onto the same channelized link.
Detailed information on this is found in the document shown.
401-710-094
Topic/Section: E1s (International Configuration)
28L3
E1 (Pre-conversion)
Channelized Links
All E1s from BTS URCs will be concentrated onto
channelized OC3/12 or STM-1 links at the E1 Concentrator and
forwarded to the routers.
APS is used to provide redundancy for link or router failures
Interface parameter tables and detailed information on the
interfaces is located in the 401-710-094 document:
Topic: OC3 Interface (Domestic Configuration) or
Topic: STM-1 Interface (International Configuration)
Channelized Links:
All interfaces from the BTS URCs will be concentrated on dedicated links and
forwarded to the routers. APS provides redundancy for link failures.
Detailed information on this is found in the document shown.
401-710-094
Topic/Section: OC3 or OC12 Interface (Domestic Configuration)
Topic/Section: STM-1 Interface (International Configuration)
29L3
Topic 4: BTS, 5ESS DCS and ECPC MM-RCS AP
(Pre-conversion)
Topic 4 - BTS, 5ESS DCS and ECPC MM-RCS AP (Pre-conversion)
30L3
No change. RCS AP
PSU2e: PHE3 packs equipped in pairs as a BHS
iPS: PHE4
Alcatel-Lucent Packet
Switch
Formerly (FPS)
BTS
IPBH hardware and software:
5ESS DCS
Release 26.0 or later FMM-AP
Release 26.0 or later Cell (BTS)
Release 26.0 or later 1x RNC
5E19.1 SR or later
BTS, 5ESS DCS, and ECPC MM-RCS AP (Pre-conversion)
3G1x (IPBH) Hardware and Software requirements:
The displayed table shows the network hardware required for I-P-B-H.
31L3
BTS with one of the following types of cells:
BTS
1XEV-DO hardware and software:
Release 28.0 or later 1xEV-DO RNC
Cell (BTS)
BTS, 5ESS DCS and ECPC MM-RCS AP (Pre-conversion)
1xEV-DO (MLPPP) Hardware and Software requirements:
The displayed table shows the required hardware for 1XEV-DO.
32L3
BTS: Configure BTS
Pre-conversion activities:
For Modcells 1.0, 2.0 or 3.0 replace the equipped URC circuit packs
with URCm circuit packs in the digital shelf
After CRC/URC to URCm replacement is complete the transition from FR
to IPBH can be completed without visiting the cell sites
Update cell site software to R26 or later (IPBH), R28 or later (1xEV-DO
MLPPP)
BTS, 5ESS DCS, RNCs and ECPC MM-RCS AP (Pre-conversion)
The following are configuration requirements for a BTS (Base Transceiver Station).
The BTS URC in modular cells 1.0, 2.0 and 3.0 must be equipped with URCm circuit
packs. A cell site being converted to IPBH must be updated to Release 26 or later.
And for a 1xEV-DO cell site being converted to MLPPP, it must be updated to
Release 28 or later.
33L3
BTS: BPSN (Backplane Serial Number) Tool
For IPBH signaling to work properly, the BPSNs must be provisioned
correctly (be the same) on the URCs equipped in a BTS assemblage and
on the associated cdmeqp and btseqp ECP forms. The BPSN tool:
Executes from the OMP via CLI commands
Performs a series of tests to determine if the URC BPSNs are
provisioned correctly
Duplicate BPSNs across assemblages or null BPSNs (total assemblage)
must be corrected at the cell using the RMT terminal, and the BPSN
Tool rerun until successful completion
If the assemblages is not duplicated or null and URC and/or ECP form
mismatches exist the tool updates these with correct BPSN
(Field: Backplane Serial Number- Located on 1
st
screen of both ECP
forms)
BPSN (Backplane Serial Number) Tool:
For IPBH signaling to work properly, the BPSNs must be provisioned correctly on the
URCs equipped in a BTS assemblage and on the associated cdmeqp and btseqp ECP
forms.
The Alcatel-Lucent BPSN tool executes from the OMP via CLI commands. Upon
execution, it performs a series of tests to determine if the URC BPSNs are provisioned
correctly. Duplicate or null BPSNs must be corrected. If BPSN is not duplicated or
null, and URC and or ECP form mismatches exist the tool updates these with the
correct BPSN.
34L3
BTS: Documentation (NAR)
401-614-404 1xEV-DO Network Base Station Release 29.0
Universal Radio Controller (URC and URC-II)
PCS and Cellular Modular Cell 4.0
signal flow and component
descriptions RF signal flow and
components description
Universal Radio Controller (URCm) Signal flow and component
descriptions RF Signal flow and
components description - Flexent
High Density 3.0
Universal Radio Controller II (URC-II)
401-710-122 CDMA and PCS CDMA Modular Cell 1.0, 2.0, 3.0 and Compact Modular
Cell 3.0 OA&M
BTS conversion preperation IP Backhaul Implementation
Backhaul server assignment and PSU/1X RNC engineering
Base transceiver station
IP Backhaul Network Overview
401-710-090 IP Backhaul and Ethernet Backhaul
BTS Documentation Table:
For more information on the material just covered refer to the document topics shown
in the table.
35L3
5ESS DCS: Pre-conversion activities
Installation and configuration at the 5ESS-DCS packet switch* (PS),
establishes the 3G1X voice traffic* backhaul servers (BHSs) in the IPBH
network. (*If 1XRNC not equipped this would be data traffic also.)
(The following work is normally completed by LWS Installation.)
Retrofit to 5E19.1 or later Software Release
SMP SM-XC (SMU6) or SM-2000 upgrade to CORE700 + MHPPC
Install and grow BPH (Backhaul Protocol Handler) pair
PHE3 PSU2e shelf/iPS-2e shelf
PHE4 iPS-h shelf
Configure BPH pair as a BHS
Configure BHS on the MLS
*Note: Packet switch (PS) Alcatel-Lucent Packet Switch
Formerly Flexent Packet Switch
5ESS DCS (Digital Cellular Switch) pre-conversion activities:
Installation and configuration of the 5ESS DCS packet switch establishes the 3G1x
voice traffic backhaul servers in the IPBH network. The pre-conversion activities
include retrofitting the DCS to software release 5E19.1 or later. Upgrading exiting
SMs to Core700 plus MHPPC or installing an SM-XC cabinet with an SMU6 SMP.
Installing and growing PHE3s or PHE4s in the PSU2e or iPS cabinet and then
configuring (provisioning) the BPH pair as a BHS. Finally configuring the BHS on
the MLS.
36L3
5ESS DCS: PSU2e
and iPS Cabinets
PSU2e (PHE3s)
Shelves 0-4
iPS
iPS-2e
Shelves 0-3
(PHE3s)
iPS-h Shelf 4
(PHE4s)
PS (Packet Switch) cabinets and shelves:
PHE3 BPHs can be equipped in the PSU2e cabinet in shelves 0 through 4 and in the
iPS cabinet on the iPS-2e shelves (0-3). PHE4 BPHs can be equipped in the iPS
cabinet on the iPS-h shelf (4)
(Future equipment configurations of the SM-XC SMP cabinet will allow for the
mounting of iPS-2e and iPS-h shelves in the SMP cabinet. This will allow for a one
cabinet SM.)
37L3
5ESS DCS: BHS Equipage
2 BPHs equipped as a mated pair to provide 1+1 sparing for
reliability
PSU2e/iPS: PHE3s equipped on different shelves and power groups
iPS: PHE4s equipped in shelf 4
The 2 BPHs are grouped as a
BHS and operate in a Serving
Non-serving configuration
5ESS DCS BHS (backhaul server) equipage:
BPHs are equipped as a mated pair to provide 1+1 sparing for reliability. The two
BPHs are grouped (provisioned) as a BHS and operate in a serving, non-serving
configuration.
38L3
5ESS DCS: Provisioning
(1) Define BPH
Specific Data
RC View 22.32 (NAR)
RC Form 9.37 (INTL)
(4) Provision BPH
Router attributes
RC View 33.3 (NAR)
RC Form 90.6 (INTL)
BPH
PH Group (BHS)
BPH BPH
MLS
PF3
PH Group (BHS)
BPH
(3) Provision BPH
Ethernet
link attributes
RC View 33.4 (NAR)
RC Form 9.37 (INTL)
(5) Assign BPHs to
PH Group
RC View 22.32 (NAR)
RC Form 9.37 (INTL)
100 Mps Ethernet
BTS, 5ESS DCS, RNCs and ECPC (RCS-AP) (Pre-conversion)
(2) Provision BPH IP
attributes
RC View 33.1 (NAR)
RC Form 90.5 (INTL)
5ESS DCS provisioning for IPBH:
To provision the BPHs the following is provisioned in the order shown above.
46L3
ECPC (RCS-AP): Pre-conversion activities
Installation and provisioning at the ECPC, for the IPBH Network.
Install R26 or later
Provision required ecp forms
ECPC (Executive Cellular Processor Complex) RCS-AP (Radio Cluster Server
Application Processor) pre-conversion activities:
ECPC RCS-AP pre-conversion activities performed for IPBH include
updating/retrofitting to Release 26 or later and provisioning/updating the required
ECP forms.
47L3
ECPC (RCS-AP): ECP forms
The ECP forms provisioned for IPBH are listed on this slide and
the next:
The following forms are verified*:
ecp form IPBH Control Network
apeqp form RCS-IP services enabled
The BPSN tool updates the following form/s:
cdmeqp/btseqp form/s: Backplane Serial Number field
The following information is set automatically when the
aprcsconfig program is run:
cdmeqp/btseqp form Backhaul mode changed from FR to IP
cell2 form IPBH enabled changed to Y
(*These ecp forms on this slide are provisioned at initial startup, normally this
is completed by ALU LWS team.)
BTS, 5ESS DCS and ECPC (RCS-AP) (Pre-conversion)
ECPC required ECP Forms:
The ECP Forms affected by IPBH are shown above and on the next page. Please
review.
48L3
ECPC (RCS-AP): ECP forms
The ECP forms provisioned for IPBH are listed on this slide and
the next: (cont.)
The following cell2 form information has to provisioned:
IPBH fields on the IP Backhaul Information screen
CDMA Carrier fields on the CDMA Cell Site for IP Backhaul Information
Only screen/s
Note: For detailed information on these and all ECP Forms refer to
the current release of the 401-610-036; Database Update
Manual, Volumes 1-5.
ECPC required ECP Forms:
The ECP Forms affected by IPBH are shown above and on the previous page. Please
review.
Detailed information on ECP Forms is found in the following document:
401-610-036
49L3
ecp: Example of IP Backhaul Information Only screen (R28).
Required ECP Forms:
Example of the IPBH fields on the ecp form is shown above.
50L3
apeqp: Example of IP Backhaul configuration screen (R29).
Required ECP Forms:
Example of the IPBH fields on the apeqp form is shown above.
51L3
Example of cdmeqp screen 1 (R29).
Required ECP Forms:
Example of the IPBH fields on the cdmeqp form is shown above.
52L3
Example of btseqp screen 1, Backplane Serial Number (R29).
Required ECP Forms:
Example of the IPBH fields on the btseqp form is shown above and on the next slide.
53L3
Example of btseqp screen 2, Backhaul Mode.
Required ECP Forms:
Example of the IPBH fields on the btseqp form is shown above and on the previous
slide.
54L3
cell2: Example of IP/Ethernet Backhaul Information screen
(R29).
Required ECP Forms:
Example of the IPBH fields on the cell2 form is shown above.
55L3
cell2: Example of CDMA Cell Site For IP Backhaul Information
Only screens (4 Screens: Common Carriers 1-33 [R29]).
Required ECP Forms:
Example of the IPBH fields on the cell2 form IPBH CDMA Carrier fields is shown
above. Note, there are 4 screens for this CDMS Carrier.
56L3
ECPC (RCS-AP): Documentation (NAR)
a2tg - ctm Volume 2
Daypg - nrsuz Volume 3
401-610-036 Database Update Manual (Volumes 1-5)
ECPC OA&M OA&M for IP Backhaul
Backhaul server assignment and PSU/1X RNC engineering
RCS implementation
IP Backhaul Network Overview
ECPS (RCS-AP) Documentation:
For more information on the material just covered refer to the document topics shown
in the table.
57L3
This topic provided an overview of the hardware and
provisioning performed. It is only an overview. Detailed
procedures and training on pre-conversion activities are located
in the following documents and courses.*
IPBH Conversion
401-612-841 CDMA Wireless Networks BTS Conversion from LAPD to ML-
PPP over T1/E1
CL5592W IP Backhaul Conversion
1xEV-DO HDLC to MLPPP Conversion
401-710-104 CDMA Wireless Networks BTS Conversion from HDLC to ML-
PPP over T1/E1
CL5594W 1xEV-DO HDLC to MLPPP Conversion
*Note: This documentation and training is only available to customers who
have purchased a LWS Service Level Agreement for the
conversion. For more information contact you Alcatel-Lucent
Customer Representative or your Training Coordinator.
3G1x implementation overview:
This topic provided an overview of the hardware and provisioning performed for
IPBH. Detailed procedures and training on pre-conversion activities are located in the
documents and course shown above.
As noted this documentation and training is only available to customers who have
purchased an LWS Service Level Agreement for the conversion.
58L3
Topic 5: Conversion 3G1X and 1XEV-DO
Topic 5 - Conversion 3-G-1-X and 1-X-E-V-D-O.
59L3
Considerations and conditions prior to conversion:
3G1X only:
A cell site can only have one backhaul connection type (LAPD[FR]
or IP)
Cell and MSC components installed, operational and on the correct
software release
ER and MLS provisioning is completed for MSC components
3G1X and 1XEV-DO:
All URCs must be active
Cell cannot be operating on a spare URC
No alarms exist at the cell
All recommended hardware installation, software loads and
provisioning on ERs/ARs and MLSs are completed
Alcatel-Lucent recommends that once conversion is started, it
must be completed
Conversion 3G1X and 1XEV-DO
Considerations and conditions prior to starting the conversion:
3G1X only:
A cell site can only have one backhaul connection type (LAPD[FR] or IP)
Cell and MSC components installed, operational and on the correct software
release
ER and MLS provisioning is completed for MSC components
3G1X and 1XEV-DO:
All URCs must be active
Cell cannot be operating on a spare URC
No alarms exist at the cell
All recommended hardware installation, software loads and provisioning on
ERs/ARs and MLSs are completed
Alcatel-Lucent recommends that once conversion is started, it must be completed
60L3
4. Verify successful conversion
3. Execute convert program
2. Check Network Elements
Conversion procedures: 3G1X network from LAPD(FR) to IP
1. Activate FAF/QFAF
3G1x Conversion Procedures
The conversion procedures for 3G1x include activating required FAFs and/or QFAFs,
checking the network elements, executing the Convert program, and verifying that the
conversion completed successfully.
61L3
3G1X: FAF/QFAF Activation
The following features must be activated before attempting the
conversion:
FAF/QFAF 1096 CELL 152 - IP Backhaul Support for Right to Use,
which supports the following FIDs:
IP Backhaul for CDMA
IP Backhaul support for RTU
FAF 1584: IPBH BTS Conversion: Cell Conversion Feature ID:
BTS conversion from LAPD (Link Access Protocol over
D-channel) to IPBH.
Conversion (3G1X and 1XEV-DO)
FAFs and QFAFs Activation:
The required FAFs/QFAFs are shown above.
62L3
3G1X: FAF/QFAF Activation
The IPBH Support for RTU QFAF contains the purchased
number of IPBH carriers available for configuration. The
following applies:
The number of currently configured IPBH carriers for an office is
displayed on the ecp form (Field: Configured IPBH Carrier
Bandwidth).
The number of configured IPBH carriers must not exceed the
number of purchased IPBH carriers.
When an attempt is made to configure more IPBH carriers than the
RTU QFAF allows, the cell2 form update will be denied.
3G1x FAF/QFAF activation:
The IPBH Support for Right-to-Use QFAF contains the purchased number of IPBH
carriers available for configuration. Review the listed restrictions above.
63L3
3G1X: Check Network Elements
The following is performed to check the network elements:
Verify that the appropriate ECP forms, ERs, MLSs and BHSs
information is set up correctly
Display SDPs or enter TICLI commands to verify:
Status of MM-RCS AP pairs
Status of the BTS URCs
Status of the BHSs assigned to cell
Conversion (3G1X and 1x EV-DO)
3G1x checking of the network elements:
The following summarizes the procedures performed to check the network elements:
Verify that the appropriate ECP forms, ERs, MLSs and BHSs information is set
up correctly
Status of MM-RCS AP pairs
Status of the BTS URCs
Status of the BHSs assigned to cell
64L3
3G1X: Execute convert program
The following is performed to execute the Convert program:
Command entered to run the aprcsconfig Convert program, which
will:
Opens a socket connection to each URC in the cell
Create a Network File Descriptor (NFD) record with IPBH information
so the next URC boot is performed with IPBH parameters
Create an IPBH RCS process on the RCS AP for the cell
Update specific ECP forms pertaining to the cell
Check whether ECP information exists to support IPBH
Restart the RCS AP with the new RCS-IP process
The aprcsconfig Convert program prompts the user:
After all CDMs and URCs have been updated
To perform the DS1 facility swing
3G1x: Executing the Convert program:
Executing the Convert is done by entering the command to run the aprcsconfig
Convert program. The convert program opens a socket connection to each U-R-C at
the cell site and creates an NFD (network file descriptor) record with IPBH
information. This NFD is used the next time the URC boots. It also creates the IPBH
RCS process on an RCS AP, updates specific ECP form fields, checks that the ECP
form information exists to support IPBH and restarts a RCS-AP with the new process.
During the running of the Convert program the user is prompted after all CDMs and
URCs have been updated and also when it is time to perform the DS1 facility swing.
65L3
3G1X: Verify successful conversion
The following is performed to verify success of conversion:
Sanity of cell and that URC signaling links are IP
Status of the MM-RCS APs
Status of Carriers/SOCs and MLGs
3G1X: Commit (Optional) Frees up FR resources.
If all 3G1X URCs at the BTS were converted successfully and you
want to finalize (optional) the conversion:
Enter command to run the aprcsconfig Commit program
Once run, there is no going back
3G1x: Verifying successful completion of conversion:
To verify the successful completion of the conversion the status of key components
are verified by displaying SDPs or by entering TICLI commands.
Once its determined that the conversion was successful the aprcsconfig Commit
program can be run to finalize the conversion and free up the frame relay resources.
This is optional, and once run, there is no going back.
66L3
3G1X: Fallback to LAPD(FR) mode
The aprcsconfig Fallback program is run when:
Conversion was not successful
Decision is made to not proceed with IBPH conversion at this time
The following procedures are part of the Fallback process:
Pre-checks of system prior to executing fallback
Execute Fallback program and perform the T1/E1 facility swings
Post-Fallback checks for sanity and performance verification
3G1x: Running the Fallback program:
The aprcsconfig Fallback program is run if the conversion was not successful or it is
determined not to proceed with IPBH conversion at this time.
Execute Fallback program and perform the T1/E1 facility swings
67L3
Conversion procedures: 1XEV-DO network from HDLC to MLPPP
4. Verify successful conversion
3. Execute convert program
2. Prepare for conversion
1. Activate FAF
1xEV-DO: Conversion procedures:
The conversion procedures for 1XEVDO are shown above.
68L3
1XEVDO: FAF Activation
The following feature must be activated before attempting the
conversion:
FAF 1180: MLPPP DO conversion:
BTS conversion from HDLC (Link Access Protocol over
D-channel) to MLPPP.
1xEV-DO: Activation of the FAF
FAF 1180 must be activated before attempting the conversion. Details of the FAF are
shown above.
69L3
1XEV-DO: Prepare for conversion
The following is performed to check the network elements:
Site is healthy
Status of cell
mlppp-upd tool is run to modify:
DHCP tab
T1 network and
netmask files
1xEV-DO: Preparation for the Conversion:
Network elements are checked by displaying SDPs or entering TICLI commands to
verify that the site is healthy and (3) the status of the cell.
The mlppp-upd is then run to modify the DHCP tab, the T-1 network and the netmask
files.
70L3
1XEV-DO: Execute convert
The following is performed to execute the convert:
Enter command to run the aprcsconfig Convert program. It:
Opens a socket connection to each URC in the cell and creates NFD
record
Restarts the RCS AP with the new RCS-IP process
When the Convert program has completed, the user will be
prompted to:
Reconfigure the PSAX and router for the EVDO URCs
Verify BTS/cell connectivity to MM-RCS AP
Perform BTS/cell sanity and performance verification tests
After the successful execution of the mlppp-upd and the Convert
program, required Router and/or DACS modifications should be
performed
1xEV-DO: Execution of the Convert program:
To execute the 1XEVDO convert a command is entered to run the aprcsconfig
Convert program. It open a socket connection to each URC in the cell and creates
NFD record. It also restarts the RCS AP with the new RCS IP process.
When the Convert program has completed the user is prompted to reconfigure the
PSAX and router for EVDO URCs, to verify BTS connectivity to MM-RCS APs and
to perform BTS sanity and performance verification tests.
After the mlppp-upd and the Convert program have completed successfully the
required router and DACS modifications should be performed.
71L3
1XEV-DO: Verify successful conversion
The following is performed to verify success of conversion:
1X/DO is displayed and
Status of the MLGs
1xEV-DO: Verify conversion has completed successfully:
Successful completion is determined by displaying SDPs and entering TICLI
commands to verify that 1X/DO is displayed on SDP and to verify the status of the
MLGs.
72L3
1XEV-DO: Fallback to HDLC mode
The aprcsconfig Fallback program is run when:
Conversion was not successful
Decision is made to not proceed with IBPH conversion at this time
Execute Fallback program and reconfigure ARs and/or DACs
Preparation and Conversion
1xEV-DO: Running the Fallback program:
The aprcsconfig Fallback program is run if the conversion was not successful or it is
determined not to proceed with the conversion at this time.
The Fallback process procedures are show above.
73L3
This topic provided an overview of the conversion. It is only an
overview. Detailed procedures and training on the conversion
are located in the following documents and courses.*
IPBH Conversion
401-612-841 CDMA Wireless Networks BTS Conversion from LAPD to ML-
PPP over T1/E1
CL5592W IP Backhaul Conversion
1xEV-DO HDLC to MLPPP Conversion
401-710-104 CDMA Wireless Networks BTS Conversion from HDLC to ML-
PPP over T1/E1
CL5594W 1xEV-DO HDLC to MLPPP Conversion
*Note: This documentation and training is only available to customers who
have purchased a LWS Service Level Agreement for the
conversion. For more information contact you Alcatel-Lucent
Customer Representative or your Training Coordinator.
1xEV-DO implementation overview:
This topic provided an overview of the hardware and provisioning performed for
MLPPP. Detailed procedures and training on pre-conversion activities are located in
the documents and course shown above.
As noted this documentation and training is only available to customers who have
purchased an LWS Service Level Agreement for the conversion.
74L3
Topic 6: Post deployment
Topic 6 - Post deployment.
75L3
Post deployment activities
Reclaim FR resources
Commit program run during conversion and/or
Perform procedures to remove resource
Add new hardware to IP Backhaul network
URCs at BTS
BHS at 5ESS DCS
RCS AP at MM (ECPC)
Post Deployment
Post deployment activities
Post deployment activities include reclaiming of the frame relay resources and adding
new hardware to the IP Backhaul network.
76L3
Reclaim FR resources Procedures
Protocol Handler (PH) Degrowth Degrowth Procedures
235-200-100 Packet Switch for CDMA Network Operations, Administration, and
Maintenance Issue 13.01
Delete DS1/DS0s used with FR-based RCS IP Backhaul Implementation
Post deployment
Documentation on reclaiming FR resources.
The table above lists the location in the documents where detailed information on
reclaiming FR resources are located.
77L3
Add URCs at BTS Procedures
Add a new OneBTS URC for IP Backhaul cell Replace Components and
Repair a Modular Cell
401-703-407 Alcatel-Lucent CDMA Base Stations 4.0, 4.0B, 8400, 4400 and 2400
Series OA&M
Adding a new OneBTS URC for IP Backhaul cell
Replace Components and
Repair a Modular Cell
401-710-122 CDMA and PCS CDMA Modular Cell 1.0, 2.0, 3.0 and Compact Modular
Cell 3.0 OA&M
Post deployment
Adding URCs at the BTS:
The table above lists the locations in documents where detailed information on adding
URCs are located.
78L3
Add BHS at 5ESS DCS Procedures
Protocol Handler (PH) Growth Growth Procedures
Provisioning
235-200-100 Packet Switch for CDMA Network Operations, Administration, and
Maintenance Issue 13.01
Post deployment
Adding a BHS at the 5ESS DCS:
The table above lists the locations in documents where detailed information on adding
BHSs at the 5ESS DCS are located.
1L4 All Rights Reserved Alcatel-Lucent 2007
IP Backhaul for CDMA Voice and Packet
Data
CL1301
Lesson 4 IP Backhaul OA&M
CL1301 Release 28
Lesson 4 - IP Backhaul OA&M
Course Outline
Introduction
- FR vs. IPBH
- IPBH Architecture
1xEV-DO overview
- HDLC vs. HDLC
- Post deployment
OA&M
- OA&M Overview
- BTS OA&M
- 5ESS DCS OA&M
and RNC
- ER and MLS OA&M
Fault management
- Fault types
- Monitoring tools
scenarios
OA&M topics:
OA&M Overview
BTS OA&M
5ESS DCS OA&M
ECPC OA&M Includes MM-RCS AP and RNC
ER and MLS OA&M
Lesson 4 objectives
Perform OA&M on network elements
Perform OA&M on transport equipment
Perform OA&M on network elements
Perform OA&M on transport equipment
Data
Topic 1: OA&M Overview
Topic 1 - OA&M Overview
OA&M Overview
The following network elements are discussed as part of
this lesson.
Base Transceiver Station (BTS)
Edge Routers
Multi-Layer Switch
MM RCS-AP
5ESS DCS Packet Switch Backhaul Server (BHS)
1xRNC Backhaul Server (BHS)
OA&M Overview:
The following network elements will be discussed as part of this lesson.
Edge Router
Multi-Layer Switch
MM RCS-AP
5ESS DCS Packet Switch Backhaul Server
1xRNC Backhaul Server
OA&M Overview
The IPBH Network is comprised of the following components: (2 pgs.)
BTS Base Transceiver Station: Contains the radio equipment for the cell site. This
equipment processes and transmits and receives control and bearer information
between the antenna and the MSC. The following BTS Modcells support IP Backhaul:
- Modcell 4.0 with URC/URC-II card; H.D. 4.0 with URC/URC-II card; Modcell 4.0
Compact with URC/URC-II card and Modcell 1/2/3 with URCm card
URC-Universal Radio Controller: The URC provides the interface between the cell
site and the backhaul facilities. The following URCs with IP Transport support IP
Backhaul: URCm, URC or URC-II
ER-Edge Router: Interface between the WAN (BTS) and the LAN (MSC). They
determine the destination and then route the packets between the BTSs and the MSC.
The ERs are vendor neutral. However because of QoS issues Alcatel-Lucent has list of
recommended vendors.
MLS-Multi-Layer Switch: Interface between the LAN (ERs) and the MM-APs (RCS-
APs), the PSU2e (BHS BPHs) and the RNC (GICCs). They may be multi-layer
(L2/L3) switches or L2 only switches. The SWs (MLS) are vendor neutral. However
because of QoS issues Alcatel-Lucent has a list of recommended vendors.
RCS-Radio Cluster Server: Receives/transmits control signaling ISUP information
between the BTSs, RNCs and DCSs associated with the MSC. The RCS-AP has an
Ethernet interface to the SWs to provide this function in IPBH.
OA&M Overview
The IPBH Network is comprised of the following components: (cont.)
BHS-Backhaul Server: Two (2) BPHs (Backhaul Protocol Handlers that operate in the
Server/Non-server 1+1 configuration for improved reliability. The BPHs have an
Ethernet interface to the SWs. They transport bearer traffic using a proprietary
application layer protocol, User Datagram Protocol Multiplexer (UDPMux).
OA&M Overview
Failures between NEs or between the NE and the operating system,
or between OSs
Communication
Failure to meet the given threshold values. Quality of Service
Loss of some or all of the specified capabilities of a NE due to
overload conditions.
Overload condition
Failure of a functional resource in the NE and no hardware
component has been detected as faulty.
Functional
Malfunction of software components. Software
Malfunction of physical resource (this includes cable problems). Hardware
Description Fault type
IP Backhaul fault types:
Hardware fault is a malfunction of physical resource
Software fault is a malfunction of software components
Functional fault is a failure of a functional resource in the Network Element (NE)
and no hardware component has been detected as faulty
Overload condition fault is a loss of some or all of the specified capabilities of a
NE due to overload conditions.
Quality of Service fault is a failure to meet the given threshold values
Communication fault is the failure between network elements or between the
network element and the operating system.
Monitoring Network
Detailed information is located in Chapter/Part: OA&M for IP Backhaul; Topic: New
and modified SDP pages for IPBH of the 401-710-090 document.
OA&M Overview
BHS interface
OMP-FX
OMP-FX
MCC (for the 5ESS DCS)
TPU GUI (for the 1X/DO RNC)
SDP 2260
SDP 2265
MCC 1188
BHS Statistics Information
Monitors the health of Ethernet links
and ability to communicate with its
gateway router.
OMP-FX
SDP 2131
SDP 2237
URC updates FMM-RCS with status of
all its DS1s.
Each URC MLG and equipped DS1s
and the Signaling Link connectivity.
URC interface
OMP-FX
SDP 2131
SDP 2238
Monitor end-to-end connectivity
between:
Each URC and its primary andalternate
FMM-RCS
Each URC MLG to all the BHSs that
are assigned to serve call legs on that
URC.
End-to-end connectivity
How is it accessed? Tool Task
Monitoring the Network:
The IP backhaul network is monitored using a variety of tools and interfaces. The
tables on this page and the next provide information on this. Please review.
Detailed information is located in the following document:
401-710-090
Chapter/Part: OA&M for IP Backhaul
Topic/Section: New and modified SDP pages for IP Backhaul
OA&M Overview
MM-RCS and MM LAN interface
OMP-FX SDP 2236
Monitors status of carrier channel
SOCs and the associated BHS
information
Router management interface
ROP
Router Network Management
System (RNMS)
Output message (if no RNMS)
Monitors status of backhaul
routers, all inter-router links and
all host interfaces.
Router status
OMP-FX SDP 2138
Monitors MM-RCS LAN, and
between the MM-LAN and the
MSC adjacent switches.
Carrier Channels Status
How is it accessed? Tool Task
Monitoring Network (cont.)
Monitoring the Network:
The IP backhaul network is monitored using a variety of tools and interfaces. The
tables on this page and the previous provide information on this. Please review.
OA&M Overview
New/Modified SDPs: 2101 APX INDEX2
APX Index Page 2 - New index page added for IPBH status display pages.
2101 - APX INDEX2
Displays the command and page title for the IPBH status display pages (SDPs).
Detailed information on Status Display Pages (SDPs) is found in the:
OA&M Overview
New/Modified SDPs: 2131 CELL (RCS) EQUIP STAT
Line - IPBH: Enabled (3G1X)
Detailed SDP information located in 401-610-166 document
3G1x: 2131, # CELL (RCS) # EQUIP STAT (# = Cell Site Number)
When a cell has been converted/installed as an IP Backhaul cell IPBH enabled is
displayed.
OA&M Overview
New/Modified SDPs: 2131 CELL (RCS) EQUIP STAT
Standalone: DO: line is set to IPoMLPPP
Shared: 1x/DO: line is set to FR/IPoMLPPP or IPoMLPPP/IPoMLPPP
1xEV-DO: 2131, # CELL (RCS) # EQUIP STAT (# = Cell Site number)
When cell is converted/installed as MLPPP:
Standalone DO: IPoMLPPP
Shared 1x/DO: FR/IPoMLPPP or IPoMLPPP/IPoMLPPP
OA&M Overview
New/Modified SDPs: 2138 CELL CDM EQUIP STATUS
Command 2237
2138-CELL a#, CDM b#, EQUIP STATUS
(a# = Cell Site number, b# = CDM number)
Displays Command and Description for the Cell Assemblage MLG Status page.
OA&M Overview
New/Modified SDPs: 2236 CELL CARR-SOC-BHS STATUS
Displays CRC#, CHNL#, SOC, DCS/SM/PSU/BHS, RNC/BHS
2236-CELL #, CARR-SOC-BHS STATUS (# = Cell Site number)
Displays the status of equipped carriers of an IPBH cell site and provides a command
to output status the cells CARR-SOC-BHS status. For IPBH displays the following:
Carrier number
Channel number
SOC - Service Option Class
DCS# (Digital Cellular Switch)/SM# (Switching Module)/PSU# (Packet Switch
Unit)/BHS# (Backhaul Server)
RNC# (Radio Network Controller)/BHS#
OA&M Overview
New/Modified SDPs: 2237 CELL ASSM MLG STATUS
Displays CRC#, MLG#, DS1# IN MLG, SL ON MLG and DS1# NOT IN
MLG
2237-CELL a#, ASSM b#, MLG STATUS
(a# = Cell Site number, b# = Assemblage number)
Provides Cell Assemblage MLG Status and commands to Inhibit, Allow and Output
MLGs.
Each CRC (URC) is displayed with associated:
MLG
DS1s in MLG
Signaling Link on MLG
DS1s not in MLG
OA&M Overview
New/Modified SDPs: 2238 CELL MLG-BHS ASSOC STATUS
Displays CRC#, MLG#, DCS/SM/PSU/BHS, MLG-BHS ASSO STATE,
RNC/BHS and MLG-BHS ASSOC STATE
2238-CELL #, MLG-BHS ASSOC STATUS (# = Cell Site number)
Displays the status of the MLG BHS associations for a cell.
OA&M Overview
New/Modified SDPs: 2260 DCS BHS STATUS
Displays PSU#, BHS#, BHS MS (Mtce. State) and BHS LS (Load State)
Displays summary of SMs equipped with BHSs and 2260 Screen#
2260, #-DCS # BHS STATUS (# = DCS number)
Displays BHS status for both voice and data for DCS BHSs consisting of
one screen per switching module.
OA&M Overview
New/Modified SDPs: 2265 RNC BHS STATUS
Displays RNC#, BHS#, BHS MS (Mtce. State) and BHS LS (Load State)
Displays summary of RNCs equipped with BHSs
2265, # - RNC # BHS STATUS (# = RNC number)
Displays the BHS status for RNCs.
OA&M Overview
New/Modified MCC Pages: MCC 1188: PH GRP STAT
BPHs can only be equipped in PH GRP 1 -10 (Screen 1)
Corresponding RC/V view 22.32: Protocol Handler Group View
Detailed information on 5ESS DCS MCC pages is located in the
CMD< - 1188 - SM 001 LSM - PSU 0 PH GRP STAT
SM 001 STAT SCREEN 1 OF 2
NORMAL
PH APP PH LINK SERV PH LINK SERV
SITE 000 GRP TYP # STAT STAT # STAT STAT
REMOVE
2YZZ PH Y-ZZ 2 NPH 1-00 41 ACT SERV 0-07 42 ACT NONSERV
RESTORE
3YZZ PH Y-ZZ
SWITCH 5 SHO 4-03 37 ACT NONSERV 4-10 36 ACT SERV
4XX PHGRP XX
OUTPUT
90XX OP BHA XX
91XX OP IPCON XX
92XX OP NPH XX 10 BPH 0-04 03 ACT NONSERV 1-09 48 ACT SERV
93XX OP STAT PHGRP XX
DISPLAY &=IP CONNECTIVITY LOSS, *M = MAJOR OVERLOAD
1186,W PSU W NETWORK Y=SHELF, ZZ=POSITION, *C = CRITICAL OVERLOAD
1188 SM a# LSM PSU b# PH GRP STAT
(a# = SM number, b# = PSU number)
The 5ESS DCS MCC 1188 page displays the Protocol Handler Group status of the
equipped IP protocol handlers.
OA&M Overview
New/Modified TPU GUI: TPU Network Elements
Displays all configured TPU GICCs for an RNC
IPBTSGW designation identifies BHS GICC
Detailed information located in the 401-710-110 document
TPU Network Elements:
This is an sample of the RNC TPU Network Elements page with GICC 20 equipped
for IPBH.
OA&M Overview
New/Modified TPU GUI: BHS Statistics Information
Displays specifics on the RNC GICC BHS status as regards to usage
state, loading status and UDP port usage status
Detailed information located in the 401-710-110 document
BHS Statistics Information:
This is an sample of the RNC TPU BHS Statistics Information page for IPBH.
OA&M Overview
New/Modified OMC-RAN GUI Page: BTS Overview
IPBH network elements are indicated with a blue box and the word IP in
the lower right hand corner (For 1XEV-DO DO IP)
BTS Overview:
The OMC Ran BTS Overview page has been modified.
Data
Topic 2: BTS OA&M
Topic 2 - BTS OA&M
BTS OA&M
ML-PPP enables multiple DS1s to be grouped on the same
URC into a Multi-Link Group
Each MLG has a unique IP address
IPv4 is only supported (v6 not supported)
UDPMux is a Alcatel-Lucent proprietary bearer frame
multiplexing technique into a single IP datagram to gain DS1
efficiency
Sets up the Backhaul Server Association with the BHS for
transporting user traffic
Provides the ability to split the voice and 3G1X data traffic
Information on the Base Transceiver Station (BTS) for ML-PPP:
ML-PPP enables multiple DS1s to be grouped on the same URC into a Multi-
Link Group
Each MLG has a unique IP address
IPv4 is only supported (v6 not supported)
UDPMux is a lucent proprietary bearer frame multiplexing technique into a
single IP datagram to gain DS1 efficiency
Sets up the Backhaul Server Association with the BHS for transporting user
traffic
Provides the ability to split the voice and 3G1X data traffic
BTS OA&M
IP Addresses at the BTSs and a DCS.
The layer 2 protocol used between the BTS URCs and the ERs is either Point-to-
Point Protocol or Multi-Link Point-to-Point Protocol. PPP is a single DS1 and MLPPP
is from 2 to 4 DS1s (Up to 8 for a URCII). Each PPP or MLPPP has a Multi-Link
Group Number associated with it. URCs can support one or two MLGs with each
MLG having a unique IP Address.
At the DCS, each B P H that is equipped in a PSU2e or iPS and each has a unique I P
address. There is also a BHS Serving IP Address which is associated with BHS BPH
that is serving.
Point-to-Point Packet: A single DS1 (a.k.a. T1/E1) between a URC and the ERs.
Multi-Link Point-to-Point Packet is multiple DS1s between a URC and the ERs.
DS1s per URC: URCm - 4 DS1s, URC - 4 DS1s, URC2 - 8 DS1s
MLG: In the IPBH Network a M LG is associated with each PPP/ML-PPP of a URC.
A URC can support 1 or 2 MLGs and each M LG has a unique IP Address. An M LG
can be from 1 to 8 DS1s.
BPH: Equipped in a PSU2e or iPS. A BPH provides the "muxing/demuxing" of traffic
frames in the UDPMux packets. Each BPH has a unique IP Address for control
messaging. Equipped in pairs and operate in a Serving, Non-Serving configuration. A
unique "Serving IP Address" is assigned to the Serving BPH when initialized. This
IP address is used for call processing.
BTS OA&M
UPDATE-CELL-BPSN UPDATE:CELL-BPSN
OP-BHS-CELL OP:BHS-CELL
DUMP-CELL-AUTH FAIL DUMP:CELL-AUTH FAIL
OP-ALARM OP:ALARM
ALW-CELL-MLG ALW:CELL-MLG
UPDATE-CELL-BSPN UPDATE:CELL-BSPN
OP-CELL a, CDM b, CRC
OP-CELL-CSB
INH-CELL-MLG
Output messages
OP:CELL a, CDM b, CRC
OP:CELL-CSB
INH:CELL-MLG
Input messages
New/Modified Input/Output messages
BTS New/Modified Input/Output messages:
The above provides a list the Input and associated Output messages for the BTS.
BTS OA&M
401-610-036 X
Recent Change/Verify
(RC/V)
No impact
Automatic Message
Accounting (AMA)
X
X
X
Modified for IP
Backhaul?
401-610-035
401-610-160
401-610-055 (Input messages)
401-610-057 (Output messages)
Document
Service Measurements
(SM)
Status Display Page
(SDP)
Input/Output (I/O)
BTS OA&M
Refer to IP Backhaul for CDMA Voice and Packet Data (401-710-090)
for complete information.
Modified documentation
BTS modified documentation:
This table above lists the BTS OA&M documents that have changes for the IPBH.
Provides cell equipment status 2131
Provides Multi-Link Group (MLG) status 2237
Provides Carrier/Service Option Class (SOC)-BHS
connectivity status
2236
Provides CDMA Digital Module (CDM) status 2138
Purpose SDP
New/Modified Status Display Pages (SDPs)
BTS OA&M
New/Modified SDPs for the BTS:
Table above lists the BTS Status Display Page changes for IP Backhaul
BTS OA&M
IP Backhaul Information Only ecp
IP Backhaul configuration apeqp
CDMA OneBTS MODCELL ASSEMBLAGE EQUIPAGE btseqp
CDMA Cell Site For IP Backhaul Information ONLY cell2
CDMA DIGITAL MODULE EQUIPAGE cdmeqp
Screen RC/V form
Modified RC/V forms
ECP Forms that have modified for IPBH:
The table above lists the ECP Forms that have been modified for IPBH.
Data
Topic 3: 5ESS DCS OA&M
Topic 3 - 5ESS DCS OA&M
5ESS DCS OA&M
Backhaul Server (BHS)
BHS is a logical entity comprised of 2 Backhaul Protocol Handlers (BPHs)
BPHs equipped in pairs for 1+1 sparing
Operate in a Serving/Non-serving configuration
Serving BPH receives and transmits UDPMux traffic to and from the
BTS on a serving IP address
BPH: PHE3
TN113 circuit pack + LLE Paddleboard (100BaseT Copper/Optical)
PSU2e cabinet: Equipped on different shelves and power groups
iPS cabinet: Equipped on different iPS-2e shelves and power groups
BPH: PHE4
PHP100 circuit pack + LLE Paddleboard (GigE)
iPS cabinet: Equipped on iPS-h shelf
The MSC Soft-handoff universe can support mix of IP and FR BTSs
Both BPHs send periodic ARP messages to the 1
st
Hop Router to verify
connectivity
5ESS DCS BHS:
The BHS is a logical entity comprised of a pair BPHs to provide 1+1 sparing. The
BPHs operate in a serving, non-serving configuration with the serving B-P-H
receiving and transmitting the UPDMux traffic from and to the
BTSs.
The PHE3, TN113 BPH has a 100BaseT Ethernet interface and is equipped in a
PSU2e or iPS cabinet as shown above.
The PHE4, PHP100 BPH has GigE Ethernet Interface and is equipped in an iPS
cabinet as shown.
The MSC soft handoff universe can support a mix of IP and FR BTSs.
5ESS DCS OA&M
Operation: IPBH 5ESS DCS
PHE4 operates the same.
GigE interface to MLS.
5ESS DCS: IPBH (BPH: PHE3)
At a DCS, Backhaul Protocol Handlers are equipped to provide IP Backhaul. In a
DCS with IP backhaul bearer traffic is transported as I-P packets between the
DCS and base transceiver stations. Edge routers and multi-level switches provide IP
routing and Ethernet interfaces. BPHs are equipped in pairs to provide 1+1 sparing for
reliability. The BPHs operate in a serving, non-serving configuration. One of the
benefits is the freeing up of DCS resources by eliminating the need for peripheral
interface units and frame relay protocols handlers for calls within a cellular systems
that uses IP Backhaul.
PHE4 BPH operates the same as stated above.
5ESS DCS OA&M
Operation: Backhaul Association - BHA
Operation: BHA
In the IP Backhaul network, logical semi-permanent paths carry user traffic between
the URCs and the BPHs. These logical paths are called Backhaul Associations. A
BHA is identified by the source IP Address and UDP port and the destination IP
Address and UDP port. Multiple BHAs between a URC MLG and a BPH are
supported. Multiple BHAs between different URC MLGs and a BPH are supported.
And BHAs between multiple URC MLGs and multiple BPHs are supported.
5ESS DCS OA&M
RST:PSUPH RST-PSUPH RST:PSUPH
TST-IPNET
RMV-PSUPH
OP-ARP
OP-IPCFG
OPCNV-PSUPH
OP-BHA
INHHC-PSUPH
EXC-TRCRT
EXC-PING
ALWHC-PSUPH
INTL Input message
INH:HDWCHK, PSU INH:HDWCHK, PSU
EXC:TRCRT, CHNG EXC:TRCRT, CHNG
TST:IPNET TST:IPNET
RMV:PSUPH RMV:PSUPH
OP:TCPIP OP:TCPIP:ARPDMP
OP:IPCFG OP:IPCFG
OP:CONV, PSELNK OP:CONV, PSELNK
OP:BHA OP:BHA
EXC:PING EXC:PING
ALW:HDWCHK ALW:HDWCHK
Output message NAR Input message
New or modified input/output message for the 5ESS DCS:
The table above lists the new or modified input and output messages for NAR and
International. Output message are the same for both versions.
5ESS DCS OA&M
Provides Switching Module
(SM) status
1188
Purpose MCC
New/Modified MCC Pages
New/modified MCC pages for the 5ESS DCS:
The table above shows the page for the 5ESS DCS.
5ESS DCS OA&M
Provides Gigabit Backhaul
Protocol measurement for
the PHE4
OP:TRFC30,GBIPBH
NAR: Gigabit IP
Backhaul
Measurements
Report-Section 131
OP-TRPHG
OP:TRFC30,IPBH=SM-PSU-PHGRP
OP-TFPHG
OP:TRFC30,IPBH;
Command
Stored reports
On-demand IPBH
supplemental reports
Real-time reports
BPH associated with the
PH Group reports
Report
NAR: IPBH
Supplemental
Measurement
Report-Section 154
INTL: IPBH C-
interval
NAR: IPBH
Backhaul
Measurement
Report-Section 153
INTL: IPBHSUP C-
interval
Service
Measurement
New/Modified Service Measurements
Detailed Service Measurement information is located in 235-600-700
document in the APP:TRFC-SECTION.
New or modified service measurements for the 5ESS DCS:
The table above lists the new or modified service measurements, output command and
report.
Provision BPH Router attributes 90.6 IPRTE 33.3
90.7 IPETH
90.5 IPPRC
9.37 PHGRP
INTL RC Form
Provision BPH Ethernet link attributes 33.4
Provision BPH IP attributes 33.1
Define BPH specific data
Assign BPHs to PH Group
22.32
Screen NAR RC View
New/Modified RC/V forms
5ESS DCS OA&M
New or modified RC/V Views/Forms for the 5ESS DCS:
The table above lists the new or modified RC/V Views/Forms for NAR/International.
Topic 4: ECPC OA&M - Includes MM-RCS AP and RNC
Data
Topic 4 - ECPC OA&M includes MM-RCS AP and 1x RNC
ECPC OA&M - Includes MM-RCS AP and 1XRNC
The RCS-AP performs call processing and OA&M
functions
IP Backhaul is only supported on the MM platform for
the RCS-AP
Both IP and Frame Relay BTS can be supported on
one RCS-APS
An RCS-AP that supports only IP BTS does not
require DS1 links or DS1 I/O card
Release 27.0 provides a new tool aplanconfig
RCS-AP IPBH information:
The Radio Cluster Server (RCS) application runs on an application processor (AP) in
a CDMA wireless network performing the call processing and OA&M functions for
the Flexent cell sites.
IP backhaul is only supported on the MM platform for RCS. IP Backhaul is not
supported on the GNP-AP platform.
For IP Backhaul, both IP and Frame Relay BTS can be supported on one RCS-AP.
Starting with Release 27.0 a new tool is provided for verifying the network
connections and the configuration of the Ethernet switches. It is a combination of two
commands, Apcablecheck and Aphubconfig into a single command aplanconfig. The
new tool can be run manually, whenever changes are made (growth/degrowth) and
will be part of the SUA pre-checks where it runs automatically.
ECPC OA&M - Includes MM-RCS AP and 1XRNC
Operation: Backhaul Connection Server (BHCS)
IPBH eliminates the T1 nailed up connection between a
BTS and RCS-AP
A new service, BHCS, resides on all IP enabled RCS-APs
with only one being the active as the BHCS RCS-AP at a
time
The active BHCS RCS-AP listens for BTS identification
messages and then responds with RCS-AP IP connectivity
information, which includes IP addressing and port
information
Virtual BHCS IP Address for URC initialization is configured
on the ERs
BHCS (Backhaul Connection Server) Operation:
IPBH eliminates the T1 nailed up connection between a BTS and RCS-AP and
adds a new service, B H C S on all IP enabled R C S A Ps. Only one R C S A P at a
time is the active B H C S server. It listens for B T S identification messages and
then responds with R C S A P I P connectivity information, which includes the IP
addressing and port information.
A virtual B H C S I P address for BTS URC initializations is configured on the ERs.
ECPC OA&M - Includes MM-RCS AP
Refer to IP Backhaul for CDMA Voice and Packet Data (401-710-090) for
complete information.
401-610-036 X Recent Change/Verify
No impact
Automatic Message
Accounting (AMA)
X
X
X
Modified for IP
Backhaul?
401-610-135
401-610-160
401-610-055 (Input messages)
401-610-057 (Output messages)
Document
(SM)
Status Display Page
(SDP)
Input/Output (I/O)
ECP OA&M
Modified documents
Modified documents for the ECPC:
This table above presents ECP OA&M overview of changes for IP Backhaul
LOCK-RNC-TPU * LOCK:RNC-TPU *
OP-DCS-BHSSTAT OP:DCS-BHSSTAT
UPDATE:AP-BPSN UPDATE: AP-BPSN
GET-RNC-BHS-INFO* GET:RNC-BHS INFO*
GET-RNC-TPU-STATE* GET:RNC-TPU-STATE*
OP-AP-IPBHINFO OP:AP-IPBHINFO
SHUTDOWN-RNC-TPU * SHUTDOWN:RNC-TPU *
UNLOCK-RNC-TPU* UNLOCK:RNC-TPU*
OP-RNC-BHSSTAT
Output messages
OP:RNC-BHSSTAT
Input commands
* Applies to 1X RNC only
New/Modified Input/Output messages:
New or modified input and output messages for the ECPC are listed in the table
above.
Provides RNC BHS status 2265
Provides DCS BHS status 2260
Displays all configured TPU GICCs for
an RNC
TPU GUI: TPU Network Elements
Displays specifics on the RNC GICC
BHS status
TPU GUI: BHS Statistics Information
Purpose SDP/TPU GUI
New/Modified Status Display Pages (SDPs) and TPU GUI
pages.
New/Modified SDPs and TPU GUI pages:
The table above lists the ECPC Status Display Page changes for IP Backhaul and the
TPU GUI pages for the RNC.
Total RCS Messages Transmitted from the AP per URC
Total RCS Messages Received from the BTS per URC
Peak Signaling Traffic Load (downlink) per AP
Average Signaling Traffic Load (downlink) per AP
AP related counts
CDMA Voice Origination/Termination Overflow due to BHS Blocking
CMDA Packet Data Origination/Termination Overflow due to BHS
Blocking ID.
BHS related counts
Call blocking due to MLG capacity limits
DS1 related counts
URC signaling counts
Cell Backhaul (MLG)
related counts
Counts include
Service
Measurement
New or modified service measurements for the ECPC are listed in the table above.
Data
Topic 5: Edge Router (ER) and Multi-Layer Switch
(MLS) OA&M
Topic 5 - E-R and M-L-S OA&M
ER and MLS OA&M
Edge Router (ER)
The IP router must support the following standard protocols to
be compatible with IP Backhaul:
PPP and MC/ML-PPP protocols
DiffServ QoSs
IPCP protocol to assign dynamic IP address to the BTS when
initialized
IEEE 802.1 D/Q functionality supported by the routers Ethernet
switch
For DS1 error conditions, the router should report:
Loss of signal
Loss of framing
Receipt of AIS and RAI
BER alarms based on configurable BER thresholds and remove
DS1 from service when the threshold is exceeded for a
configurable interval
Edge Router (ER) information:
The IP router must support the following standard protocols to be compatible with
IP Backhaul:
PPP and MC/ML-PPP protocols
DiffServ QoS
IPCP protocol to assign dynamic IP address to the BTS when it is initialized
IEEE 802.1D/Q functionality supported by the routers Ethernet switch
For DS1 error conditions, the router should report:
Loss of signal
Loss of framing
Receipt of AIS an RAI
BER alarms based on configurable BER thresholds and remove a DS1 from
service when the threshold is exceeded for a configurable interval.
ER and MLS OA&M
Edge Router (ER) Quality of Service (QoS)
Three classes of traffic need to be configured:
Bearer traffic as EF (Expedited Forwarding) class, which enjoys
the highest priority.
Signaling and high-priority OAM traffic as AF (Assured
Forwarding) class, which has lower transport priority than the
EF traffic above but higher priority than the BE traffic below.
Default traffic (e.g. NVM downloading, other OAM traffic) as BE
(Best Effort) class, which has lowest priority within the bear
traffic.
ER QoS:
In particular, there are three classes of traffic that need to be configured:
Bearer traffic class as EF (Expedited Forwarding) class, which enjoys the highest
priority within the bearer traffic
Signaling and high-priority OAM traffic class as AF (Assured Forwarding) class,
which has lower transport priority than EF traffic above but higher priority over
BE traffic below
Default traffic class (e.g. NVM downloading, other OAM traffic) as BE (Best
Effort) class, which has lowest priority within the bearer traffic
ER and MLS 0A&M
Interconnects the AP frames, the OMP, edge routers and
backhaul servers.
Edge routers are cross-connected to a pair of switches adjacent
to the MSC (SW-1 and SW-2).
Interface from SW to 5ESS DCS PS is 100Base-TX/FX
Ethernet (PSU2e/iPS-2e shelves) or 1000Base-FX/SX Ethernet
GigE (iPS-h shelves)
Interface from SW to RNC is 1000Base-FX/SX Ethernet (GigE)
For full path diversity, it is highly recommended to provision two
MSC adjacent switches, both connecting to the backhaul
routers and the MSC.
Multi-Layer Switch (MLS) information:
The MSC adjacent MLS becomes part of a private IP network interconnecting
AP frames, the OMP, edge routers and backhaul servers
The edge routers are cross-connected to a pair of MLSs that are adjacent to the
MSC (SW-1 and SW-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.)
The interface from the SW (MLS) to the 5ESS DCS PS is 100Base-TX/FX or
1000Base-FX/SX Ethernet and the interface to the RNC is 1000BaseFX/SX
Ethernet
(To achieve full path diversity it is highly recommended to provision two MSC
adjacent switches, both connecting to the backhaul routers and the MSC.)
ER and MLS OA&M
Operation: Reliability
IP Backhaul Redundancy:
To provide reliability, the IP Backhaul network is duplicated in all areas.
At the BTSs, multiple URCs have MLGs that interface to the ERs. There is also a
diverse geographic R-F coverage across URCs.
Automatic protection switching for the SONET interfaces exists between transmission
network equipment and the ERs.
OSPF provides link protection between the ERs and the SWs (MLSs). VRRP provides
redundancy protection between the ERs and the MM-RCS AP and the DCS for RNC
BHSs.
The multi-layer switches are redundant as is the cross-coupling between them in the
ERs. The Ethernet interface to the MM-RCS APs and the BHSs is redundant.
The MM-RCS AP site has access to both LANs, and the RCS APs are equipped in
pairs and operate in an active/standby configuration. The BPHs and GICCs are
equipped in pairs and operate in a serving/non-serving 1+1 sparing configuration.
ER and MLS OA&M
For detailed information on how to perform OA&M on the
ER and MLS, refer to the:
ER and MLS documents:
For detailed information on how to perform OA&M on the ER or MLS, refer to the IP
Backhaul Transport Network (401-710-094) and the vendors documentation
ER and MLS OA&M
The next slides provide examples* of commonly used
administration and maintenance troubleshooting commands
for the Alcatel-Lucent and vendor products used as ERs
and MLSs in the IPBH network.
Riverstone 8600
Alcatel-Lucent SR7750
Cisco 6509e
Cisco 10K
Edge Router (ER)
Juniper M40e
*Note: More examples of commonly used commands can be found in the
ER-MLS Commands attachment.
These are examples, consult the ER and MLS vendor documents
for a complete list and detailed information on how and when to
use.
ER and MLS OA&M commands:
The next slides provide troubleshooting commands for the Alcatel-Lucent and vendor
products used as ERs and MLSs in the IPBH network.
ER and MLS OA&M
The traceroute command can be used on router CLI to trace the path
that a packet will take from any point A to any other point B in the
network.
The output of this command will show the IP addresses of all the
intermediate IP routing hops that a packet traverses to reach the
destination.
traceroute (ip address)
Manually switches OC3/12 between routers. Moves the active side
from protect to working
aps manual 0
no aps manual 0
Forces a switchover to the other supervisor card force-switchover main-cpu
Checks the supervisor cards are in redundancy mode. show redundancy
View status of OC3 interfaces. show aps
Manually switches OC3/12 between routers. Moves the active side
from working to protect
aps manual 1
no aps manual 1
Pings from route to MSC components, validating routing. ping <ip address>
Views the flow of traffic into the allocated traffic classes.
show policy-map interface multilink
<x>
Identifies OSPF neighbors. The router should have a neighbor to
each MLS.
show ip ospf neighbor
Purpose
Command using the
Router/MLS CLI
Cisco router debug commands
Cisco ER debug commands:
Cisco edge router debug commands are provided here as an example of commonly
used debug commands on an edge router.
ER and MLS OA&M
Shows BFD neighbors. admin save <optional-file-name>
Checks supervisor cards are in redundancy mode.
admin redundancy force-switchover
now
Identifies the HSRP sessions.
admin redundancy synchronize {boot-
env|config}
Forces a switchover to the other supervisor card. admin display-config
Reboot the Chassis admin reboot now
Purpose Command
Alcatel-Lucent MLS administrative commands
Alcatel-Lucent MLS administrative commands:
Alcatel-Lucent MLS administration commands are provided here as an example of
some commonly used commands.
ER and MLS OA&M
Shows BFD neighbors. show bfd neighbors
Checks supervisor cards are in redundancy mode. show redundancy
Identifies the HSRP sessions. show standby brief
Displays any interfaces in an error state.
show interfaces port-channel 1 status
err-disabled
Provides for loop prevention on the MLS. show spanning-tree
Forces a switchover to the other supervisor card. force-switchover
Identifies OSPF neighbors. The router should have a
neighbor to each MLS.
show ip ospf neighbor
Purpose Command
Cisco MLS debug commands
Cisco MLS debug commands:
Cisco MLS debug commands are provided here as an example of commonly used
debug commands on an edge router.
CL1301
Lesson 5 - IP Backhaul Fault Management
Data
CL1301 Release 28
Lesson 5: IP Backhaul Fault Management
Course Outline
Introduction
- FR vs. IPBH
- IPBH Architecture
1xEV-DO overview
- HDLC vs. HDLC
- Post deployment
OA&M
- OA&M Overview
- BTS OA&M
- 5ESS DCS OA&M
and RNC
- ER and MLS OA&M
Fault management
- Fault types
- Monitoring tools
- Software, Hardware and Configuration
fault scenarios
Fault Management topics:
Fault types
Monitoring tools
Cable fault scenarios
Communication fault scenarios
Software, Hardware and Configuration fault scenarios
Lesson 5 objectives
Identify IP Backhaul failure types
Correct IP Backhaul failure types
Clear IP Backhaul alarms
Identify IP Backhaul failure types
Correct IP Backhaul failure types
Clear IP Backhaul alarms
Data
Topic 1: Cable Failures
Topic 1: Cable Failures
Cable Failures
PSU 1
BHS 2
BHS 2
BHS 3
BHS 3
ER-2
ER-1 MLS-0
MLS-1
MSC
complex
L2-A
L2-B
RCS-AP 1
RCS-AP 2
RCS-AP x
BHS 4
BHS 4
BHS 1
BHS 1
RNC 1
BHS 2
BHS 2
BHS 3
BHS 3
SHO
URC 1
BTS 1
URC 1
BTS n
URC 2
5ESS DCS
RNCs
Edge
routers
Growth Frame
MM-APs
BHS 1
BHS 1
BTS to edge
router cable
fault
Edge router
to MLS cable
fault
MLS to BHS
on the 1X
RNC cable
fault
MLS to BHS
on the 5ESS
cable fault
Cable Failures:
Before presenting the cable fault scenarios, it will be helpful to keep the following in
mind. Cable faults can occur between:
BTS and edge router
Edge router and MLS
MLS and BHS on the Flexent Packet Switch
MLS and BPH on the 1X RNC
These cable faults can be physical in nature (that is, cable is disconnected or cut) or a
Bit-Error Rate problem on the cable.
FM Scenario 1 DS1 cable cut BTS-1
Some calls are dropped or there may be
loss of capacity
RNMS: DS1
interface operating
status=DOWN
SDP 2138
Critical Alarm
SDP 2237:
Critical alarm;
DS1 not in
MLG
ROP: Critical alarm
for bandwidth
change
OMC-RAN
Critical Alarm -
AP detailed view
FAULT: Incoming DS1 failure to
BTS. Multi-DS1 MLG
configuration (partial MLG failure)
1. Problem
2. Facts
3. Possibility
Continue on next page
Alarm
notification
BTS: Detects DS1 LOS and
removes DS1 from MLG
ER: Notified of DS1 LOS and
NE detection
CRITICAL
Cable Failures
FM scenario 1:
In this scenario, an incoming DS1 failure occurs at the BTS in a multi-DS1 MLG
configuration (partial MLG). This fault causes calls to be dropped or a loss of
capacity (depending on the number of DS1s) and a Critical alarm to be raised.
Repair cut DS1 cable
4-5. Action
6. Observe results
FAULT: Incoming DS1 failure at the
BTS. Multi-DS1 MLG configuration
(partial MLG failure)
RNMS
Red alarm clears
SDP 2138
DS1 alarm clears
SDP 2237
DS1 back to MLG and MLG
DS1 association change
OMC-RAN
DS1 alarm clears -
AP detailed view
BTS: Restores DS1 to MLG; Sends MLG bandwidth
change and MLG DS1 association change message to
RCS
ER: Restores DS1 to
MLG
Problem solved?
Yes No
Go back to
Step 2
Alarm clearance
NE action
STOP
FM Scenario 1 DS1 cable cut (cont.) BTS-1
Cable Failures
FM scenario 1: (cont.)
The critical alarm raised by incoming DS1 failure at the BTS (in a Multi-DS1 MLG)
is cleared by repairing the cut DS1 cable.
FM Scenario 2 DS1 High Error Failure BTS-4
RNMS
DS1 interface operating
status=DOWN
SDP 2138
Critical Alarm
SDP 2237
DS1s not in MLG
ROP
Critical Alarm for
bandwidth change
OMC-RAN
Critical Alarm -
AP detailed view
Some calls are dropped or there may be a
loss of capacity
FAULT: Incoming DS1
failure at the BTS-High BER
on incoming DS1 in a Multi-
DS1 MLG configuration
1. Problem
2. Facts
3. Possibility
BTS: Removes DS1 from
MLG
ER: Removes DS1 from MLG
Alarm
notification
NE detection
CRITICAL
Cable Failures
FM Scenario 2:
In this scenario, incoming DS1 failure at the BTS is the result of a HIGH Bit Error
Rate in a Multi-DS1 MLG configuration. This fault causes calls to be dropped or loss
of capacity and a Critical alarm to be raised.
Install new DS1 cable between ER
and BTS
4-5. Action
6. Observe results
RNMS: DS1
interface Oper
Status=UP
SDP 2138
DS1 alarm clears
SDP 2237: DS1 back
to MLG and MLG DS1
association change
OMC-RAN
Alarm clears - AP
detailed view
Go back to
Step 2
FAULT: Incoming DS1 failure at the
BTS-High BER on incoming DS1 in a
Multi-DS1 MLG configuration
BTS: Restores DS1 to MLG; Sends MLG
bandwidth change and MLG-DS1 association
change messages. DS1 is removed from MLG
to ensure that performance will not be
impacted, even though capacity is impacted
ER: Detects
signal is good and
restores DS1 to
MLG
RCS: Receives
bandwidth and
association
change
Alarm
clearance
NE action
Yes No
STOP
Problem solved?
ROP: Critical alarm
clear; notification of
MLG bandwidth
change
Cable Failures
FM Scenario 2 DS1 High Error Failure (cont.) BTS-4
FM Scenario 2: (cont.)
The critical alarm raised by high Bit Error Rate on incoming DS1 is cleared by
installing a new DS1 cable between the Edge router and BTS.
FM Scenario 3 Loss of Only DS1 on URC BTS-5
Some calls are dropped or there
may be a loss of capacity
FAULT: Incoming DS1 failure
at the BTS-Single DS1 MLG
1. Problem
2. Facts
3. Possibility
BTS: Detects
LOS on DS1
ER: Notified by BTS of
loss of L1 and L2 for the
original MLG and
RCS: Detects loss of heartbeat after 24
sec. and places URC OOS. SL is re-
established. Orig. association will
change to use another URCs MLG
RNMS
DS1 interface
operating
status=DOWN
SDP
2131
SL OOS
for URC
SDP 2138
& 2237
CRC OOS
ROP
OOS on URC
message-NO
CRC heartbeat
OMC-RAN
URC OOS-
URC view
SDP 2236
SOC
degraded for
OneBTS and
OOS for URC
Modcell
Alarm
notification
NE detection
MAJOR
Cable Failures
FM Scenario 3:
In this scenario, there is Incoming DS1 failure at the BTS. There is only one DS1 in
this MLG configuration.
This fault causes calls to be dropped or loss of capacity and a Major alarm to be
raised.
Note: When the DS1 is lost, the URC is removed and the MLG is moved to another
URC (i.e. MLG sharing is active).
Install a new DS1 cable between ER
and BTS
4-5. Action
6. Observe results
Yes No
Go back to
Step 2
FAULT: Incoming DS1
failure-Single DS1 MLG
RNMS
DS1 interface
operating
status=UP
SDP
2138
Alarm
clears
SDP 2237
Restores
DS1 back
to MLG
ROP: Alarm clears;
Shows MLG
bandwidth change and
MLG DS1 assoc.
change
OMC-RAN
Alarm clears-
AP detailed
view
SDP 2236
AVAILABLE
BTS: Restores MLG used for
bearer traffic only. To use orig.
MLG for signaling traffic, reboot
URC
ER
Detects Layer
2; Restores
DS1 to MLG
RCS: Notified that URC is
available for bearer traffic
and MLG association has
changed
Alarm
clearance
NE action
STOP
Problem solved?
Cable Failures
FM Scenario 3 Loss of Only DS1 on URC (cont.) BTS-5
The Major alarm raised by Incoming DS1 failure at the BTS (in a single DS1 MLG) is
cleared by installing a new DS1 cable between the edge router and BTS.
Cable Failures
SDP
2131May
receive
intermittent
alarms
SDP 2138
Major
alarm
ROP
May receive
major alarm
report
OMC-RAN
May display intermittent
major alarm-AP detailed
view
Intermittent voice quality problems due to lost voice
packets; Increase in data transmissions due to lost
data packets
FAULT: High BER (>5*10-5) on
outgoing DS1 failure to ER (that
is, BER towards router). Multi-
DS1 MLG configuration
1. Problem
2. Facts
3. Possibility
SDP 2237
Displays operational
DS1s and DS1s not
in any MLG
RCS: May display
intermittent signaling
link failures
DCS: TRF30 section 153-
Check IPBHSUP counts
Alarm
notification
NE detection
MAJOR
FM Scenario 4 Bad DS1 cable ER-1
FM Scenario 4:
In this scenario, HIGH Bit Error Rate on outgoing DS1 failure to ER in a Multi-DS1
MLG configuration causes intermittent voice quality problems due to lost voice
packets as well as an increase in data transmission due to lost data packets. This fault
cause a Major alarm to be raised.
Cable Failures
Install new DS1 between ER and BTS 4-5. Action
6. Observe results
Yes No
Go back to
Step 2
SDP 2138
Alarm
clears
ROP
No more
reports
received
OMC-RAN
Major alarm
cleared
SDP 2237
Alarm clears
RCS: No longer receives
intermittent alarms.
DCS: TRFC30 counts are no
longer incrementing.
FAULT: High BER (>5*10-5) on outgoing DS1 failure to
ER (that is, BER towards router). Multi-DS1 MLG
configuration
Alarm
clearance
NE action
STOP
Problem solved?
FM Scenario 4 Bad DS1 cable (cont.) ER-1
The Major alarm raised by High Bit Error Rate on outgoing DS1 failure to the edge
router is cleared by installing a new DS1 between the router and BTS.
Cable Failures
RNMS
ER and MLS Ethernet
operating
status=DOWN
None
FAULT: ER detects loss of connectivity to
MLS
1. Problem
2. Facts
3. Possibility
ER: Removes interface to MLS from
service. ER removes direct OSPF
route thru MLS, chooses an
alternate route thru mate ER
MLS: Removes interface to ER
from service. MLS redirects traffic
to other ER
Alarm
notification
NE detection
MAJOR
FM Scenario 5 Cable cut between ER and MLS ER-2
FM Scenario 5:
In this scenario, the edge routers loss of connectivity to the Multi-Layer Switch does
not cause any service impact. However, a Major alarm is raised.
Cable Failures
Install new cable connecting ER and
MLS
4-5. Action
6. Observe results
Yes No
Go back to
Step 2
MLS: Restores original
packet routing
ER: Restores original packet
routing
FAULT: ER detects loss of connectivity to
MLS
RNMS
ER and MLS Ethernet
operating status=UP
Alarm
clearance
NE action
STOP
Problem solved?
FM Scenario 5 Cable cut between ER and MLS (cont.) ER-2
The Major alarm raised by loss of connectivity between the edge router and MLS is
cleared by installing a new cable between the edge router and MLS.
Cable Failures
Stable calls are active, however there may
be loss of data. Also, some new call
setups or reactivations on the affected
BTSs may fail before the RNC recovers
FAULT: Loss of L2 is detected by the serving
IPBTS GICC (on the RNC). No alternate IPBTS
GICC has been configured. Cable is cut on
serving IPBTS GW GigE interface
1. Problem
2. Facts
3. Possibility
RNMS: MLS
ethernet
Oper Status=
DOWN
SDP 2121
TRBL-RNC
summary
indicator
ROP: RNC report against GigE.
BTS may report loss of heartbeats
depending on how quickly the
RNC detects the failure. Report of
RNC IPBTS GW state change to
DISABLED/IDLE
OMC-RAN
TRBL-RNC
summary
page. Major
alarm
TPU-GUI
GigEport-
Major alarm
TPU-Major
alarm
SDP 2236
Intermittent
change in
the data
SOC status
A
l
a
r
m

n
o
t
i
f
i
c
a
t
i
o
n
NE detection
MAJOR
FM Scenario 6 Cable cut on serving IPBTS GW GigE interface
Standby GigE in-service RNC-1
RNC: Detects loss of ARP beating.
Serving IPBTS GW changes to
disabled/idle on TPU-GUI
MLS
Interface=DOWN
FM Scenario 6:
In this scenario, loss of Layer 2 detected by the serving IPBTS GICC causes stable
calls to remain active, however, there may be loss of data. Also some new call setups
or reactivation on the affected BTSs may fail before the RNC recovers. This fault is
the result of a cable cut in the serving IPBTS GW GigE interface and raises a Major
alarm.
Cable Failures
Repair cut cable 4-5. Action
6. Observe Results
Yes No
Go back to
Step 2
FAULT: Loss of Layer 2 is detected
by the serving IPBTS GICC (on the
RNC). Cable is cut on serving IPBTS
GW GigE interface
Alarm
clearance
NE action
SDP 2121
NORMAL-RNC
summary
indicator
ROP
RNC report GigE
port alarm clear
OMP-FX: GigEport
alarm clears; TPU
alarm may return to
NORMAL
OMC-RAN
GigEport
alarm clears
MLS: Receives ARPs from
non-serving IPBTS GW
RNC: Detects ARP
responses on GigE
STOP
Problem solved?
FM Scenario 6 Cable cut on serving IPBTS GW GigE interface
Standby GigE in-service (cont.) RNC-1
The Major alarm raised by the loss of Layer 2 detected by the serving IPBTS GICC is
cleared by repairing cut cable on serving IPBTS gateway GigE interface.
Cable Failures
RNMS
MLS interface
operating
status=DOWN
SDP 2121
TRBL-RNC
summary
indicator
ROP
RNC report of
Major alarm
against GigE
OMC-RAN
Major alarm
against TPU
TPU-GUI
GigEport-Major
alarm
FAULT: ER detects loss of
connectivity to the MLS. Loss of
Layer 2 is detected by the non-
serving IPBTS GW GigE
interface.
1. Problem
2. Facts
3. Possibility
OMP-FX
Major alarm
against TPU
MLS: Detects loss of
direct connectivity to
MLS
ER: Detects loss of
direct connectivity to
MLS
RNC: Detects loss
ARP beating
Alarm
notification
NE detection
MAJOR
None
FM Scenario 7 Cable cut on non-serving IPBTS GW GigE interface
RNC-2
FM Scenario 7:
In this scenario, there is no service impact when a loss of layer 2 is detected by the
non-serving IPBTS GW GigE interface. However a Major alarm is raised.
Cable Failures
Install a new cable between RNC
and MLS
4-5. Action
6. Observe results
MLS: Receives ARPs
from non-serving
IPBTS GW.
Yes No
Go back to
Step 2
FAULT: ER detects loss of
connectivity to the MLS. Loss of
Layer 2 is detected by the non-
serving IPBTS GICC.
Alarm
clearance
NE action
SDP 2121
NORMAL-RNC
summary
indicator
ROP:
Alarm clears
against GigE
port
OMP-FX
Alarm clears
against GigE
port
OMC-RAN
Alarm clears
against GigE
port
RNMS
DS1
interface
operating
status=UP
TPU-GUI
GigE port alarm
clears. TPU
alarm=NORMAL
RNC: Detects ARP responses on
GigE. Receives ARP from non-
serving IPBTS GW.
STOP
Problem solved?
FM Scenario 7 Cable cut on non-serving IPBTS GW GigE interface (cont.)
RNC-2
FM scenario 7:(cont.)
The Major alarm raised by Loss of layer 2 detected by the non-serving IPBTS GICC
is cleared by installing a new cable between the 1X RNC and MLS.
Cable Failures
Calls are dropped. New data call setups or
reactivations on the affected BTSs may fail
before the BTSs establish connections
with the alternate BHSs.
FAULT: Loss of Layer 2 is
detected by the serving IPBTS
GICC. Non-serving IPBTS GICC
is OOS; Alternate BHS assigned
and is In-Service (NAR only)
1. Problem
2. Facts
3. Possibility
RNMS
MLS
ethernet
Operating
status=
DOWN
SDP 2121
TRBL-RNC
summary
indicator
ROP: RNC report Major alarm
against GigE and Critical alarm
against BHS service. BTS may
report loss of heartbeats
RNC detects the failure.
OMC-RAN
TRBL-RNC
summary
page. Major
alarm
TPU-GUI
GigEport-
Major alarm
TPU-Major
alarm
SDP 2265
BHS=
UNAVAILABLE
A
l
a
r
m

n
o
t
i
f
i
c
a
t
i
o
n
NE detection
BTS: BHA
timeout & calls
are dropped
RNC: Detects loss of
ARP beating on
serving IPBTS GW
MLS
Interface=DOWN
ER
Interface=DOWN
CRITICAL
FM Scenario 8 Cable cut on serving IPBTS GW GigE interface Standby
GigE out-of-service RNC-3
FM Scenario 8:
In this scenario, loss of Layer 2 detected by the serving IPBTS GICC causes calls to
be dropped. This fault may also cause new data call setups or reactivations to fail on
the affected BTSs before the BTSs establish connections with the alternate BHSs.
This fault raises a Critical alarm.
Yes No
Go back to
Step 2
STOP
Problem solved?
Cable Failures
Install new cable between RNC
and MLS
4-5. Action
6. Observe results
SDP 2121:
RNC summary
indicate TRBL if
one IPBTS GW
is fixed
ROP:
Alarm clears
against GigE
port
OMP-FX
May return to
NORMAL-TPU
(or Major)
OMC-RAN
Alarm clears
against
GigEport
FAULT: Loss of Layer 2 is detected by
the serving IPBTS GICC. Non-serving
IPBTS GICC is OOS; Alternate BHS
assigned and is In-Service (NAR only)
RNMS
Operating
status=
UP
TPU-GUI:
Critical alarm clears
against BHS; Major
alarm against one of
GICCs clears
Alarm
clearance
NE action
BTS: Notified by
RCS to initiate new
associations with the
primary BHS
RCS: Establishes assoc. with primary BHS.
Est. all new data calls on these assoc.
Terminate assoc. with alternate BHS after all
calls on those assoc. have drained
RNC: BHS
enabled/unlocked
/ idle
FM Scenario 8 Cable cut on serving IPBTS GW GigE interface Standby
GigE out-of-service (cont.) RNC-3
The Critical alarm raised by loss of Layer 2 detected by the serving IPBTS GICC
(where the non-serving IPBTS GICC is out-of-service) is cleared by installing a new
cable between the 1X RNC and MLS.
Cable Failures
Calls served through this BHS will fail.
FAULT: Loss of Layer 2 is
detected by the serving IPBTS
GICC. No alternate BHS has been
configured for the BTSs (NAR
only)
1. Problem
2. Facts
3. Possibility
A
l
a
r
m

n
o
t
i
f
i
c
a
t
i
o
n
NE detection
BTS: BHA
timeout & all calls
are dropped
RNC: Detects loss of
ARP beating on
serving IPBTS GW
MLS
Interface=DO
WN
ER
Interface=DOWN
RNMS
Operating
status=
DOWN
SDP 2121
TRBL-RNC
summary
indicator
ROP: RNC report Major alarm
against GigE and Critical alarm
against BHS service. BTS may
report loss of heartbeats
RNC detects the failure.
OMC-RAN
TRBL-RNC
summary
page. TPU-
Critical alarm
TPU-GUI
GigEport-Major
alarm
TPU/BHS-
Critical alarm
SDP 2265
BHS=
UNAVAILABLE
CRITICAL
FM Scenario 9 Cable cut on serving IPBTS GW GigE interface RNC-7
FM Scenario 9:
In this scenario, loss of Layer 2 detected by the IPBTS GICC (where no alternate BHS
has been configured) causes calls served through this BHS to fail. This fault raises a
Critical alarm.
Cable Failures
Install new cable between RNC
and MLS
4-5. Action
6. Observe results
FAULT: Loss of Layer 2 is detected by
the serving IPBTS GICC. No alternate
BHS has been configured for the BTSs
(NAR only)
SDP 2138 & 2237:
Alarm clear
ROP:
Alarm clears
against GigE
port
OMP-FX
May return to
NORMAL-TPU
(or Major)
OMC-RAN
Alarm clears
against
GigEport
(or Major)
RNMS
Operating
status=
UP
TPU-GUI: Critical
alarm clears against
BHS; Major alarm
against one of
GICCs clears
A
l
a
r
m

c
l
e
a
r
a
n
c
e
NE action
BTS: Notified by
RCS to initiate new
associations with
the primary BHS
RCS: Establishes associations
with Primary BHS. Establishes
all new data calls on these
associations
RNC: GICC detects
working GigE and
reports BHS is
enabled/unlocked/idle
Yes No
Go back to
Step 2
STOP
Problem solved?
FM Scenario 9 Cable cut on serving IPBTS GW GigE interface (cont.)
RNC-7
The Critical alarm raised by loss of Layer 2 detected by the IPBTS GICC (where no
alternate BHS has been configured) is cleared by installing a new cable between the
1X RNC and MLS.
Cable Failures
MLS and one of
the following:
1X RNC
Edge router
MLS and one of
the following:
5ESS DCS
MM-RCS AP
BTS
Usually
involves
The MLS provides Gige Ethernet interface and
interconnects edge routers and BPHs (on the
1xRNC). User traffic is transported using GigE
links. If the TPU-GUI is displaying alarms, the
fault is between the MLS and 1X RNC.
The MLS provides Fast Ethernet interface and
interconnects AP frames,and BHSs (on the
5ESS).
Pay attention to the monitoring tools. For
example, if the MCC is displaying alarms, the
fault is between the MLS and 5ESS.
The BTS network interface has DS1 as the
physical transport layer. DS1 terminates at the
BTS URC. User and signaling traffic is
multiplexed onto common DS1s. Multiple
DS1s between the URC and edge router are
grouped together into an MLG.
Why
Gigabit Ethernet interface
Ethernet interface
DS1 or MLG
Monitoring tools
indicate problems
with
Topic Summary
Cable failure summary:
This table above provides a summary of IP Backhaul cable faults.
The following should be considered when isolating and correcting IP Backhaul-
related faults, consider:
If monitoring tools indicate problems with the DS1 or MLG, the BTS is usually
involved. This is because the BTS network interface has DS1 as the physical
transport layer. DS1 terminates at the BTS URC. User and signaling traffic is
multiplexed onto common DS1s. Multiple DS1s between the URC and edge router
are grouped together into an MLG.
If the monitoring tools indicate problems with the Ethernet interface, the MLS is
usually involved. This is because the MLS provides fast Ethernet interface and
interconnects AP frames, edge routers, BHS on the 5ESS, and BPH on the RNC.
Note: Pay attention to the monitoring tools. For example, if the MCC is displaying
alarms, the fault is between the MLS and 5ESS. If the TPU-GUI is displaying alarms,
the fault is between the MLS and 1X RNC.
If the monitoring tools indicate a problem with the Gigabit Ethernet interface, the 1X
RNC and MLS are usually involved. This is because the MLS provides Gigabit
Ethernet interface and interconnects edge routers and BPHs (on the 1xRNC). User
traffic is transported using GigE links. If the TPU-GUI is displaying alarms, the fault
is between the MLS and 1X RNC.
Topic 2: Communication Failures
Data
Topic 2: Communication Failures
Communication Failures
PSU 1
BHS 2
BHS 2
BHS 3
BHS 3
ER-2
ER-1 MLS-0
MLS-1
L2-0
L2-1
RCS-AP 1
RCS-AP 2
RCS-AP x
BHS 4
BHS 4
BHS 1
BHS 1
RNC 1
BHS 2
BHS 2
BHS 3
BHS 3
SHO
URC 1
BTS 1
URC 1
BTS n
URC 2
5ESS DCS
RNCs
Edge
routers
Growth Frame
MM-APs
BHS 1
BHS 1
MLS and MM-LAN
communication fault
1X RNC unavailable;
Handoffs from 5ESS
not possible
No Ethernet
connectivity between
5ESS and MLS;
Communication fault
between 5ESS and
ER.
Communication Failures:
Before presenting the communication fault scenarios, it will be helpful to keep the
following in mind. Communication lapses can occur with the following:
MLS cannot communicate with the MM-LAN (hence MM-RCS APs)
1X RNC BHS is not available for handoffs from the 5ESS DCS
No Ethernet connectivity between the 5ESS DCS and MLS
SDP 2131
Major alarm
ROP
Major alarm
OMC-RAN
Major alarm-AP
detailed view
None
FAULT: MLS-1 failure (or L2-A
failure or L2-A to MLS-1 path
failure)
1. Problem
2. Facts
3. Possibility
MM-AP
Major alarm set against
local AP
BTS
Detects loss of L2
RCS
Receives notification of
MLS failure
Alarm notification
NE detection
MAJOR
FM Scenario 10 IPBW0 is unreachable MMAP-2
FM Scenario 10:
This scenario can be the result of one of three things:
MLS-1 failure
L2-A failure or
L2-A to MLS-1 path failure
This fault does not have service impact, however, a Major alarm is raised.
Repair MLS-1
4-5. Action
6. Observe results
FAULT: MLS-1 failure (or L2-A
failure or L2-A to MLS-1 path
failure
SDP 2131
Major alarm
cleared
ROP
Reports Major
alarm cleared
OMC-RAN
Major alarm
cleared
OMP-FX
Major alarm
cleared
Alarm clearance
NE action
MM-AP: Clears alarms if ping tests
to the GW address succeed or new
TCP connections associated with the
affected network open
MLS
Traffic goes
through MLS-2
BTS: Socket
connection to AP
established
Yes No
Go back to
Step 2
STOP
Problem solved?
FM Scenario 10 IPBW0 is unreachable (cont.) MMAP-2
The Major alarm raised by:
MLS-1 failure
L2-A failure
L2-A to MLS-1 path failure is cleared by repairing MLS-1. To make sure the fault has
been corrected, ping the gateway address
SDP 2131
Major alarm
ROP
Major alarm
OMC-RAN
Major alarm-AP
detailed view
FAULT: MLS-2 failure (or L2-B
failure or L2-B to MLS-2 path
failure)
1. Problem
2. Facts
3. Possibility
Alarm notification
NE detection
MLS: Assuming MLS-1
and MLS-2 connections will
be routed to MLS-1 instead
of going to MLS-2 until
problem is resolved
MM-AP
Major alarm set
against local AP
BTS
Detects loss
of L2
DCS
If MLS/L2 switch
failure, impacts
FE interface to
DCS
None
MAJOR
FM Scenario 11 IPBW1 is unreachable MMAP-3
FM Scenario 11:
This scenario can be the result of one of three things:
MLS-2 failure
L2-B failure or
L2-B to MLS-2 path failure
This fault does not have service impact, however, a Major alarm is raised.
Repair MLS-2 4-5. Action
6. Observe results
FAULT: MLS-2 failure (or L2-B
failure or L2-B to MLS-2 path
failure)
SDP 2131
Major alarm
cleared
ROP
Reports
Major alarm
cleared
OMC-RAN
Major alarm
cleared
OMP-FX
Major alarm
cleared
Alarm clearance
NE action
MM-AP: Clears alarms if ping tests
to the GW address succeed or new
TCP connections associated with the
affected network open
BTS
Reestablishes socket
connection to AP
Yes No
Go back to
Step 2
STOP
Problem solved?
FM Scenario 11 IPBW1 is unreachable (cont.) MMAP-3
The Major alarm raised by:
MLS-2 failure
L2-B failure or
L2-B to MLS-2 path failure is cleared by repairing MLS-2. To make sure the fault has
been corrected, ping the gateway address.
FAULT: Both IPGWs are
unreachable
1. Problem
2. Facts
3. Possibility
SDP 2131
Critical and
Major alarms
ROP
Critical and
Major alarms
OMC-RAN
Critical alarm-AP
detailed view
SDP 2121
Critical and
Major alarms
OMP-FX
Critical, major,
and minor alarms
Alarm
notification
NE detection
MM-AP: BHGmon determines both paths to IPGW-0 and
IPGW-1 are unreachable and raises a Critical alarm against
RCS-APs. Condition results in a failover of all active RCS-IP
Backhaul processes running on RCS-AP. RCS-IM services
are notified and if this AP frame is associated with that BHCS
in the ER, BHCS service will not be available even if the BHCS
process has restarted on another IPBH-enabled AP pair.
BTS
Detects
loss of
Layer 2
RCS
OOS
None
CRITICAL and 2 Major
FM Scenario 12 Duplex IPGW access failure MMAP-4
FM Scenario 12:
In this scenario, service is not impacted when both IP gateways are unreachable.
However, a Critical alarm and two Major alarms are raised.
4-5. Action
6. Observe results
Repair one or both IPBWs. 1)Connect a new cable or
reconnect the existing cables; 2) If 1 fails, replace cable
between MM-AP frame and IP Gateways
FAULT: Both IPGWs are
unreachable
MM-AP: Verifies Critical alarm is
cleared and that the RCS-AP is
ACTIVE
BTS: Signaling link
re-established
Alarm
clearance
NE action
Yes No
Go back to
Step 2
STOP
Problem solved?
ROP
Alarms
cleared
OMC-RAN: If both IPGWs are
reachable, both Critical and Major
alarms are cleared.
If one IPGW is reachable, Critical alarm
and one of major alarm are cleared.
SDP 2131: If both IPGWs are
reachable, both Critical and Major
alarms are cleared.
If one IPGW is reachable, Critical alarm
and one of major alarms are cleared.
FM Scenario 12 Duplex IPGW access failure (cont.) MMAP-4
FM Scenario 12:
The Critical alarm and two Major alarms raised by both IP gateways becoming
unreachable can be cleared by doing the following:
Connect a new cable or reconnect existing cable
If connecting a new cable or reconnecting the existing cable does not clear an
alarm, replace the cable between the MM-AP frame and IP Gateways
When PSUGW is OOS, all handoffs being served by the BTSs that do not
have their BHS on the current RNC will fail (assumes 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.
FAULT:The RNC is not available
and causes the BHS to be
disabled (NAR only)
1. Problem
2. Facts
3. Possibility
RNC
Detects loss
of 5E GW
OOS
Alarm
notification
NE detection
CRITICAL
SDP 2121
TRBL-RNC
summary
indicator
ROP
RNC report
Critical alarm
(RNC is not
available)
OMC-RAN
TRBL-RNC
summary page-
Major alarm
TPU-GUI
RNC not
available;
Critical alarm
against TPU
OMP-FX
Major alarm
against both
TPU shelves
SDP 2265
BHS
unavailable
FM Scenario 13 Only remaining 5E GW goes OOS RNC-6
FM Scenario 13:
In this scenario, the RNC is not available and causes the Backhaul Server to be
disabled (applies to NAR market only). As a result, all handoffs being served by the
BTSs that do not have their BHS on the current RNC will fail and raise a Critical
alarm.
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.
Yes No
Go back to
Step 2
STOP
Problem solved?
Repair SHO network problem 4-5. Action
6. Observe
results
FAULT:The RNC is not available
and causes the BHS to be
disabled (NAR only)
SDP 2121
NORMAL-RNC
summary
indicator
ROP
RNC
alarm
clear
OMC-RAN
GigE port
alarm clears
TPU-GUI
RNC alarm
clear; TPU
alarm may
clear
OMP-FX
NORMAL-TPU
indicator (or
Major alarm)
Alarm
clearance
NE action
RCS-AP: Establishes associations with Prim.
BHS and est. new data calls on these
associations. Terminates associations with Alt.
BHS after all calls on those associations have
drained
BTS: Notified by
RCS to initiate
new associations
with Prim. BHS
RNC
BHS enabled
SDP
2265
BHS
available
FM Scenario 13 Only remaining 5E GW goes OOS (cont.) RNC-6
The critical alarm raised when the RNC is not available and the BHS is disabled is
cleared by repairing the soft handoff network problem. See 401-710-082 for details
on repairing SHO network problems.
FAULT: Loss of Layer 3 detected
on serving BPH 0 at the DCS (if
duplex router configuration, then
both fail). Incorrect provisioning
of 1
st
hop router
1. Problem
2. Facts
3. Possibility
MCC 1188: BPH link
status=OOS-GW, Service
status=UNAV; PH group
becomes BPHGRPOFN
ROP
Minor alarm
SDP
Minor
alarm
5E ROP: REPT SM
PSELINK=OOS-GW; REPT
PHGRP=OFFNORMAL
Alarm
notification
NE detection
DCS
High priority ARP beat fails and no traffic
reception due to provisioning error
Loss of Layer 3
MINOR-Simplex PH group
FM Scenario 14 No 1
st
hop router connectivity (serving BPH) DCS-2
FM Scenario 14:
In this scenario, the serving BPH-0 detects loss of Layer 3 at the DCS (if it is a duplex
router configuration, then both fail) causing loss of Layer 3 and a Minor alarm to be
raised.
Yes No
Go back to
Step 2
STOP
Problem solved?
Provision correct IP address for the
1
st
hop router. See 235-200-100
4-5. Action
6. Observe results
FAULT: Loss of Layer 3 detected on serving
BPH 0 at the DCS (if duplex router
configuration, then both fail). Incorrect
provisioning of 1
st
hop router
MCC
Minor
alarm
5E ROP
REPT SM PSELINK=ACT; REPT
PHGRP=NORMAL
Alarm
clearance
FM Scenario 14 No 1
st
hop router connectivity (serving BPH) (cont.)
DCS-2
The Minor alarm raised when Loss of Layer 3 is detected on serving BPH-0 at the
DCS is cleared by provisioning correct IP address for the 1st hop router. See 235-
200-100 for detailed information on provisioning the correct IP address for the 1st hop
router.
MCC 1188: BPH link
status=OOS-LK, Service
becomes BPHGRPOFN
Loss of Ethernet link
detected on serving BPH-0
(at the DCS)
FAULT: Loss of Ethernet Link
detected on serving BPH-0 (at
DCS)
1. Problem
2. Facts
3. Possibility
5E ROP: REPT SM
PSELINK=OOS-LK; REPT
PHGRP=OFFNORMAL
RNMS
Ethernet Operating
Status=DOWN
Alarm
notification
NE detection
DCS
Loss of Ethernet
connectivity between BPH
and directly connected L2
switches
FM Scenario 15 No Ethernet connectivity (serving BPH) DCS-2
FM Scenario 15:
In this scenario, loss of Ethernet link detected by the serving BPH-0 (at the 5ESS
DCS) causes a Minor alarm to be raised.
4-5. Action
6. Observe results
FAULT: Loss of Ethernet link
detected on serving BPH-0 (at
DCS)
Reconnect cable or fix cable
Alarm
clearance
NE action
MLS
Interface=UP
DCS
Event history reported to
ROP
Yes No
Go back to
Step 2
STOP
Problem solved?
RNMS
Ethernet Operating
Status=UP
FM Scenario 15 No Ethernet connectivity (serving BPH) (cont.) DCS-2
The Minor alarm raised by Loss of Ethernet link detected by the serving BPH-0 is
cleared by reconnecting or fixing the Ethernet cable.
Loss of Layer 3
FAULT: Loss of Layer 3 detected
on non-serving BPH 0 at the DCS
(if duplex router configuration,
then both fail). Incorrect
provisioning of 1
st
hop router
1. Problem
2. Facts
3. Possibility
MCC 1188: BPH0 link
status=OOS-GW, BPHx
becomes BPHGRPOFN
5E ROP
REPT SM PSELINK=OOS-GW;
REPT PHGRP=OFFNORMAL
DCS
Loss of
heartbeat
Alarm notification
NE detection
FM Scenario 16 No 1
st
hop router connectivity (non-serving BPH)
DCS-3
FM Scenario 16:
In this scenario, loss of Layer 3 (if it is a duplex router configuration, then both fail) is
detected by the non-serving BPH-0 (at the 5ESS DCS) and raises a Minor alarm.
Yes No
Go back to
Step 2
STOP
Problem solved?
Provision correct IP address for
the 1
st
hop router. See 235-200-100
4-5. Action
6. Observe results
FAULT: Loss of Layer 3 detected on non-
serving BPH 0 at the DCS (if duplex
router configuration, then both fail).
Incorrect provisioning of 1
st
hop router
Alarm
clearance
NE action
None
None
FM Scenario 16 No 1
st
hop router connectivity (non-serving BPH) (cont.)
DCS-3
The Minor alarm raised by Loss of Layer 3 detected by non-serving BPH-0 (at the
5ESS DCS) is cleared by provisioning the correct IP address for the 1st hop router.
See 235-200-100 for detailed information on provisioning the correct IP address for
the 1st hop router.
Loss of Ethernet link detected
on non-serving BPH-0 (at DCS)
detected on non-serving BPH-0
(at DCS). Ethernet cable has
been disconnected or cut
1. Problem
2. Facts
3. Possibility
MCC 1188: BPH link
status=OOS-LK, Service
becomes BPHGRPOFN
5E ROP: REPT SM
PSELINK=OOS-LK; REPT
PHGRP=UNAV
RNMS
Ethernet Operating
Status=DOWN
Alarm
clearance
NE action
MLS
Interface=DOWN
DCS: Low priority
ARP beat fails and
no traffic reception
MINOR
FM Scenario 17 No Ethernet connectivity (non-serving BPH) DCS-4
FM Scenario 17:
In this scenario, loss of Ethernet link detected by the non-serving BPH-0 (at the 5ESS
DCS) causes a Minor alarm to be raised. This fault is the result of the Ethernet cable
being disconnected or cut.
Yes No
Go back to
Step 2
STOP
Problem solved?
Reconnect cable or fix cable 4-5. Action
6. Observe results
detected on non-serving BPH-0
(at DCS); Ethernet cable has
been disconnected or cut
RNMS
Ethernet Operating
Status=UP
Alarm
clearance
NE action
MLS
Interface=UP
DCS: See 401-710-090 for
information
FM Scenario 17 No Ethernet connectivity (non-serving BPH) (cont.)
DCS-4
The minor alarm raised by Loss of Ethernet link detected by the non-serving BPH-0 is
cleared by reconnecting or fixing the Ethernet cable.
The 1X RNC uses GigE connections to transport
user traffic from the MLS to the BPH in the GICC
card of the 1X RNC.
1X RNC BHS IPBH GICC on the TPU-
GUI
5ESS DCS BPH
MLS and one of the
following:
5ESS DCS
1X RNC
MM-RCS APs
Edge routers
Either:
MLS-0
MLS-1
L2-0
L2-1
Usually
involves
The 5ESS DCS/PSU2e network interface uses Fast
Ethernet connections to transport user traffic from
the MLS to the BPH in the PSU2e of the 5ESS.
The MLS provides fast Ethernet interface and
interconnects AP frames, edge routers, and BHSs
(on the 5ESS and RNC).
Pay attention to the monitoring tools. For example, if
the MCC is displaying alarms, the fault is between
the MLS and 5ESS. If the TPU-GUI is displaying
alarms, the fault is between the MLS and 1X RNC.
The MM-RCS network interfaces uses Ethernet
connections between the MLS and MM-LAN.
Ethernet links are used to transport packets between
the BTS and the MM-RCS.
Why
BPH on the MCC
Ethernet interface
IPGW
Monitoring tools
indicate
problems with
Communication Faults Summary
Communication Faults summary:
The table above provides a summary of IP Backhaul communication faults.
If monitoring tools indicate problems with the IPGW, the MLS-0, MLS-1, L2-0, or
L2-1 is usually involved. This is because the MM-RCS network interfaces uses
Ethernet connections between the MLS and MM-LAN. Ethernet links are used to
transport packets between the BTS and the MM-RCS.
If the monitoring tools indicate problems with the Ethernet interface, the MLS is
usually involved. This is because the MLS provides fast Ethernet interface and
interconnects AP frames, edge routers, BHS on the 5ESS, and BPH on the RNC.
Note: Pay attention to the monitoring tools. For example, if the MCC is displaying
alarms, the fault is between the MLS and 5ESS. If the TPU-GUI is displaying alarms,
the fault is between the MLS and 1X RNC.
If the monitoring tools indicate a problem with the IPBH GICC on the TPU-GUI, then
the 1X RNC BPH is involved. This is because the 1X RNC uses GigE connections to
transport user traffic from the MLS to the BPH in the GICC card of the 1X RNC.
If the monitoring tool indicate a problem with the BPH on the MCC, then the 5ESS
DCS BPH is involved. This is because the 5ESS DCS/PSU2e network interface uses
Fast Ethernet connections to transport user traffic from the MLS to the BPH in the
PSU2e of the 5ESS.
Data
Topic 3: Software, Hardware and Configuration
Failures
Topic 3: Software, Hardware and Configuration Failures
Software, Hardware and Configuration Failures
1. Problem
2. Facts
3. Possibility
SDP 2138
Major Alarm
SDP 2237
DS1s not in MLG
ROP
Major Alarm
OMC-RAN
Major Alarm -
AP detailed
view
Some calls are dropped or there may be
a loss of capacity
FAULT: BER major threshold
crossed at BTS (BER=5 * 10^-5);
High BER on incoming DS1
failure. Multi-DS1 MLG
Alarm
notification
MAJOR
BTS: Detects BER
in excess of major
alarms threshold
FM Scenario 18 BER major threshold crossed BTS-2
NE detection
FM Scenario 18:
In this scenario, some calls are dropped or there may be a loss of capacity when the
BER major threshold has been crossed on the incoming DS1 at the BTS. This
condition raises a Major alarm.
Yes No
Go back to
Step 2
STOP
Problem solved?
Correct DS1 problem 4-5. Action
6. Observe results
BTS
Restores DS1 to
MLG
Edge router
Restores DS1 to
MLG
SDP 2138
Alarm clears
SDP 2237
DS1 back to
MLG
OMC-RAN
Alarm clears - AP
detailed view
ROP: Alarm clears
MLG bandwidth change
and DS1 association
change
Alarm
clearance
NE action
FAULT: BER major threshold
crossed at BTS (BER=5 * 10^-5);
High BER on incoming DS1
failure. Multi-DS1 MLG
5E-ROP
Possibility of BHA
connection lost
FM Scenario 18 BER major threshold crossed (cont.) BTS-2
The Major alarm raised by BER major threshold being crossed is cleared by
correcting the DS1 problem.
FAULT: Active RCS IP goes OOS-F while 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 EIN.
1. Problem
2. Facts
3. Possibility
SDP 2121
Critical
alarm
ROP
Critical alarm
OMC-RAN
Critical alarm-AP
detailed view
MCC
Output an
assert on each
lost BHA
SDP 2131
Critical alarm
MM-APs: Critical alarm set against RCS-
IP on both APs where the IP services
failure has occurred.
BTS
Loss of
Signaling Link
RCS
Cannot failover
Alarm
notification
NE detection
CRITICAL
None
FM Scenario 19 Active RCS-AP goes OOS-F while mate AP is OOS-F
MMAP-1
FM Scenario 19:
In this scenario, there is no service impact when the active RCS-IP goes OOS-F while
mate AP is OOS-F. This means that the RCS IP services will fail and there is no path
to the backhaul network. This condition raises a Critical alarm.
Yes No
Go back to
Step 2
STOP
Problem solved?
4-5. Action
6. Observe results
FAULT: Active RCS IP goes OOS-F while 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 EIN
SDP 2131: Critical
alarm cleared; Major
alarm if mate AP is still
OOS-F
ROP: Critical alarm cleared;
Major alarm if mate AP is still
OOS-F.
OMC-RAN
Critical alarm cleared; major
alarm if mate AP is still
OOS-F
OMP-FX
Critical alarm
cleared
A
l
a
r
m

c
l
e
a
r
a
n
c
e
NE action
MM-APs: Critical alarm cleared when
one of the RCS-IPs transition to ACTIVE.
Major alarm cleared when Active and
Mate AP=ACTIVE
BTS
Signaling Link re-
established
DCS: If debug flag is
turned on, an assert
will be output on each
lost BHA
FM Scenario 19 Active RCS-AP goes OOS-F while mate AP is OOS-F
(cont.) MMAP-1
Restore IP services on RCS-See 401-710-090
The Critical alarm raised when the active RCS-IP goes OOS-F while mate AP is
OOS-F is cleared by restoring IP services on the RCS. See 401-710-090 for for
information on restoring RCS-IP services.
Loss of capacity to/from the URC
FAULT: One DS1 in MLG is not
configured in ER, or wrong DS1
is assigned to MLG in ER, this
DS1 will not be in the MLG. No
PPP connection on one DS1 in
an MLG (other DS1s have PPP
connections).
1. Problem
2. Facts
3. Possibility
RNMS: Verify ER detects loss
of heartbeat from the BTS or
notifies of Loss of Layer 2 and
SDP
2138
Minor
alarm
ROP
Minor alarm
for bandwidth
change
OMC-RAN
Minor alarm-AP
detailed view
Alarm
notification
MINOR
BTS
Detects loss
of Layer 2 in
DS1
FM Scenario 20 One DS1 in MLG is not configured in ER, or wrong DS1 is
assigned to MLG in ER MMAP-2
SDP 2237:
Displays
operational DS1s
and shows T1 not
in an MLG
NE action
FM Scenario 20:
In this scenario, when one DS1 in MLG is not configured in ER, or wrong DS1 is
assigned to MLG in ER, this DS1 will not be in the MLG (that is, no PPP connection on
one DS1 in an MLG) and causes loss of capacity to/from the URC. This causes a
Minor alarm to be raised.
Yes No
Go back to
Step 2
STOP
Problem solved?
Correct configuration error in the edge
router
4-5. Action
6. Observe results
ER: Case 1=No DS1 is provisioned. ER adds
DS1 to configuration
Case 2=Incorrect DS1 provisioned. Add correct
DS1 to MLG.
BTS
Restores DS1 to MLG
and reports bandwidth
change to RCS
RNMS
DS1 operating
status = UP
SDP 2138
Alarm
cleared
ROP
Major alarm cleared
and shows MLG
bandwidth change
OMC-RAN
Alarm cleared-
AP detailed view
SDP 2237
Alarm
cleared
Alarm clearance
NE action
FAULT: Edge router configuration error-No PPP connection
on one DS1 in an MLG (other DS1s have PPP connections).
One DS1 in MLG is not configured in ER or wrong DS1 is
assigned to MLG in ER
FM Scenario 20 One DS1 in MLS is not configured in ER, or wrong DS1 is
assigned to MLG in ER (cont.) MMAP-2
The Minor alarm set by Edge router configuration error is cleared by correcting the
configuration error in the edge router. See 401-710-094 for more information or
vendor documentation.
RNMS
Router
specific
hardware fault
ROP
BHA loss
messages
Stable calls are dropped
FAULT: Edge router failure
(that is, one interface card);
APS configured
1. Problem
2. Facts
3. Possibility
Alarm
notification
NE detection
BTS
Receive AIS
alarm on all
DS1s in the
MLG
ER
Vendor
specific
alarms
RCS
Loss of
heartbeat
from RCS
to URC
5ESS: BHAs
associated
with the faulty
router card
are lost
RNC: BHAs
associated
with the faulty
router card
are lost.
MAJOR
FM Scenario 21 Edge router card failure affecting all associated DS1
interfaces ER-4
FM Scenario 21:
In this scenario, an edge router (with Automatic Protection Switching configured)
failure causes stable calls to be dropped and a major alarm to be raised.
Yes No
Go back to
Step 2
STOP
Problem solved?
Replace faulty edge router component
and force a switchback
4-5. Action
6. Observe results
FAULT: Edge router failure (that is,
one interface card); APS configured
ROP
BHA loss
messages
Alarm
clearance
NE action
RCS: No impact if
APS switchover is
completed before end
of 5 sec.
BTS: No impact if
APS switchover is
completed before
end of 5 sec.
ER: Switch
back to the
original router
and re-establish
links to the
MLG
interfaces (cont.) ER-4
The Major alarm raised by edge router failure (with APS configured) is cleared by
replacing faulty edge router component and forcing a switchback.
FAULT: Edge router failure
(that is, one interface card).
No APS
MAJOR
Stable calls are dropped
1. Problem
2. Facts
3. Possibility
RNMS
Router
specific
hardware fault
SDP 2138
URC OOS
ROP: URC
and MLG OOS
message; BHA
message loss
OMC-RAN
Minor alarm-AP
detailed view
SDP 2237
MLG OOS
MCC
Report loss of BHA, if
there is BHA loss due
to a multiplexer failure
A
l
a
r
m

n
o
t
i
f
i
c
a
t
i
o
n
NE detection
BTS
Detects loss of L2
(caused by no LCP
heartbeat)
ER: Detects hardware
failure
RCS
Loss of heartbeat
from RCS to URC
interfaces ER-5
FM Scenario 22:
In this scenario, an edge router failure affecting all associated DS1 interfaces (with no
Automatic Protection Switching configured) causes stable calls to be dropped and a
Major alarm to be raised.
Yes No
Go back to
Step 2
STOP
Problem solved?
Replace faulty edge router component 4-5. Action
6. Observe results
RCS: BTS notifies RCS that the link is
back in service. If the RCS had reported
the URC OOS, it is now in service.
BTS: Restores links to MLG. If no MLG
sharing, the URC resumes using local
MLG when it finds that it has been
replaced while going through reboot.
FAULT: Edge router failure (that
is, one interface card). No APS
RNMS:Router
specific
hardware fault
is cleared
SDP 2138
Alarm
cleared
ROP
Alarm clears
reported
OMC-RAN
Alarm
cleared-AP
detailed view
SDP 2237
Alarm
cleared
Alarm
clearance
NE action
interfaces ER-5
The Major alarm raised by edge router failure (with no APS) is cleared by replacing
faulty edge router component.
The BTS network interface has DS1 as the
physical transport layer. DS1 terminates at
the BTS URC. User and signaling traffic is
multiplexed onto common DS1s. Multiple
DS1s between the URC and edge router are
grouped together into an MLG.
BTS DS1 or MLG
The edge router terminates DS1 facilities. Edge router and
BTS
Loss of layer 2 (data
link), DS1, and MLG
MM-RCS APs and
BTS
Usually involves
The MM-RCS APs provides coordination and
control of the individual cell sites associated
with it.
Why
AP and loss of
signaling link
Monitoring tools
indicate problems
with
Topic Summary
Software, Hardware and Configuration Failures summary:
This table above provides a summary of IP Backhaul software and configuration
faults.
If monitoring tools indicate problems with the DS1 or MLG, the BTS is usually
involved. This is because the BTS network interface has DS1 as the physical
transport layer. DS1 terminates at the BTS URC. User and signaling traffic is
multiplexed onto common DS1s. Multiple DS1s between the URC and edge router
are grouped together into an MLG.
If the monitoring tools indicate a problem with the AP and signaling link, the MM-
RCS APs and BTS are usually involved. This is because the MM-RCS APs provides
coordination and control of the individual cell sites associated with it.
If the monitoring tools indicate a loss of layer 2 (which is the data link), DS1, and the
MLG, the edge router and BTS are usually involved. This is because the edge router
terminates DS1 facilities.
Course summary
You should be able to:
Define Internet Protocol (IP) Backhaul
Define the IP Backhaul network elements and transport
equipment
Correct basic IP Backhaul faults
Congratulations! You have completed CL1301; IP Backhaul for CDMA Voice and
Packet Data. You should now be able to:
Define Internet Protocol (IP) Backhaul
Define the IP Backhaul network elements and transport equipment
Correct basic IP Backhaul faults
CL1301 CDMA Wireless Networks
System Capacity Monitoring
and Engineering for IP Transport
IP Backhaul TrFO/RTO
Release 28
All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 1:2
IP transport
IP transport introduction
IP transport for the bearer path has been introduced to the
CDMA Wireless Networks (CWN) over the course of Releases 26,
27, and 28. Enhancements and new features will continue to be
added from Release 29 forward.
IP transport features
For this seminar, IP transport consists of three feature sets:
Internet Protocol backhaul (IPBH)
Transcoder-free operation (TrFO) and remote transcoder
operation (RTO) in the core network
Seminar objectives
Engineer a cell site for IP backhaul (IPBH)
Engineer an office for:
IP backhaul
Transcoder-free operation (TrFO)
Remote transcoder operation (RTO)
Use critical triggers and key service measurements to
monitor the capacity loading of IPBH systems and facilities
Use critical triggers and key service measurements to
monitor the capacity loading of core network IP transport
systems and facilities
Students who have successfully completed this seminar will be
able to:
Seminar sessions
Understand IP
transport in
the core network
Engineer
TrFO/RTO
Monitor IP
transport in the
core network
Understand IP
backhaul
Engineer
IP backhaul
Monitor IP
backhaul
Day1 schedule
Break
Monitor capacity loading for an IP backhaul
network
Engineer a cell site for IP backhaul (continued)
Understand IP backhaul
Engineer a cell site for IP backhaul
Seminar introduction
Instructor and student introductions
Day2 schedule
Monitor capacity loading of core network IP
transport systems and facilities
Break
Engineer TrFO and RTO components for an
office
Final questions and seminar evaluations
Engineer IP soft handoff components for an
office
Break
Understand IP transport in the core network
Customer documentation
CDMA Wireless Networks SCME
For detailed
information
about CDMA
Wireless
Networks system
capacity
monitoring and
engineering, see
the SCME
Guidelines
customer
document
Flexent
/ AUTOPLEX
Executive Cellular Processor (ECP)

System Capacity Monitoring and
Engineering Guidelines (SCME)
Release 28.0
401-610-009
Introduction to IP Backhaul
An overview of IP
backhaul is
provided in this
customer
document
CDMA Backhaul Networks
IP Backhaul
Release 28.0
401-710-090
Session 1
Understand IP Backhaul
CDMA Wireless Networks
CL1301 SCME for IP Transport
Seminar topic map
Current session
Understand IP
transport in
the core network
Engineer
TrFO/RTO
Monitor IP
transport in the
core network
Understand IP
backhaul
Engineer
IP backhaul
Monitor IP
backhaul
Session objectives
Describe the differences between IP backhaul (IPBH)
and frame relay (packet pipe) backhaul
Describe the system requirements for IP transport on
the backhaul
Explain the role of multi-link groups (MLG) in IPBH
Explain what must be done to offload IPBH data traffic
from the Alcatel-Lucent Packet Switch to the 3G-1x RNC
Identify the IPBH backhaul servers and describe the
transmission facilities that terminate to each
Identify the hardware components used in IP backhaul,
and describe the function of each component
At the end of this session you should be able to:
Concept
IP backhaul
Definition
IP backhaul (IPBH) is a term that describes the use of
an Internet Protocol transport network for signaling,
bearer, and OA&M communication between the Base
Transceiver Station (BTS) and the Mobile Switching
Center (MSC)
Concept
IP backhaul (continued)
Improvements over FR backhaul
IP backhaul offers a number of significant
improvements over frame relay (FR) backhaul, the
traditional method for communication between the
BTS and the MSC
Concept
Compare IP backhaul and FR backhaul
Signaling multiplexed with bearer traffic
over shared DS1. Dynamic recovery and
rerouting when a signaling path fails
Dedicated signaling channels
(DS0, or DS1 with Link Access
Protocol D Channel (LAPD)
Signaling
Option to offload data traffic from the ALU
PS PSU to the RNC, conserving time slots
and other resources at the switch
Packet pipes carrying both
voice and data terminate
either to the ALU PS PSU: PSU
resources are consumed for
data traffic
Data
offload
Former packet pipe time slots are available
for circuit voice calls
Packet pipes use timeslots at
the Switching Module and for
distribution to frame relay
packet handlers
Timeslots
Fractional DS1 TDM channels
requiring grooming and nail-
up terminations at the MSC
Packet Switching Unit
Frame relay backhaul
BTS to edge router or access concentrator
Unchannelized DS1 with IP addressing and
ML-PPP multi-link groups
Edge device to MSC terminations
IP over Ethernet facilities deployed in a
multi-path IP transport network
Backhaul
transport
Internet Protocol backhaul
Concept
IP backhaul scalability and migration
Scalable
IP backhaul is highly scalable with the use of
commercial switches and aggregation routers
Transition to an all-IP network
IP backhaul provides a direct migration path to an
all-IP radio access network and core network
Concept
Multi-link groups
Multi-link group 1
Multi-link group 2
Note This example shows T1 facilities. E1 facilities are also supported for
IP backhaul.
Configurations
Multi-link groups for Modcells 1.0, 2.0, & 3.0
Rules
URCm is required for IPBH
CRC is not supported
A cell must be configured for IP backhaul or FR backhaul
No mixed configurations
Each URCm can open up to one MLG
It is a valid configuration for a URCm to have no MLG
URCm traffic is directed over other MLGs in the BTS
Each MLG can contain up to 2 or 4 DS1, depending upon
the ModCell version and the URCm location in the frame
URCm
Configurations
URCm configurations
URCm
Radio
controller
4
2
4
2
Maximum DS1
per MLG
Modcell 3.0
Modcell 2.0, first CDMA digital module
(CDM) in frame
Modcell 2.0, remaining CDM(s) in frame
Modcell 1.0
ModCell
Rules
URC and URC-II both support IP backhaul
Up to two MLG supported on a URC or URC-II
One MLG required for each URC and URC-II
Each URC MLG can contain up to 4 DS1
Each URC-II MLG can contain up to 8 DS1
Configurations
Multi-link groups for Modcell 4.0
URC URC-II
Loadsharing and signaling homing
Operators have the option to loadshare bearer traffic
across all MLG in a BTS
Loadsharing can provide better capacity utilization in some
deployment scenarios
Signaling traffic to a given URC(-II) is routed by
default to its own MLG(s)
If the MLG(s) for a URC(-II) fail, signaling traffic is
automatically rerouted to a MLG terminating to
another URC(-II) in the cabinet
Loadsharing and signaling homing
Multi-link groups for Modcell 4.0 (continued)
URC URC-II
Configurations
URC and URC-II configurations
1
1
Minimum
Number of MLG
URC-II
URC
Radio
controller
4 2
Modcell 4.0
(OneBTS)
8 2
Maximum DS1
per MLG
Maximum
ModCell
IPBH protocol stacks: URC to edge device
UDP
UDPmux (proprietary)
ML-PPP
PPP
NxDS1 (T1 | E1)
IP
Voice frame or RLP data frame
TCP
ML-PPP
PPP
NxDS1 (T1 | E1)
IP
Control
Bearer Signaling
Concept
Backhaul servers
Backhaul endpoints in the core network
Multi-link groups are the IP backhaul endpoints in the
radio access network (RAN). IP backhaul endpoints in
the core network are called backhaul servers (BHS).
Definition
A backhaul server is a bearer traffic gateway in the
core network Mobile Switching Center. It consists of:
Two bearer path termination packs equipped in
a 1+1 sparing configuration
IP backhaul server software
Concept
Backhaul servers
Two backhaul server types
There are two backhaul server types:
Backhaul Packet Handlers (BPH) at the Alcatel-
Lucent Packet Switch (ALU-PS) PSU2e
Internet protocol BTS gateway (IPBTS GW) packs at
the 3G-1x RNC
3G-1x RNC
IPBTS GW
ALU PS PSU2e
BPH
Voice and data calls Data calls only
IP backhaul BHS configuration options
Configure IPBH
Operators can specify the destination BHS for each
traffic type on each carrier in a cell. Options are:
For voice traffic, a primary and alternate BHS
(BPH pair)
For data traffic, a primary and alternate IPBTS GW
(GICC 1.1 pair)
For both voice & data traffic, a primary and alternate BHS
(BPH pair)
By default, all data calls are routed through BPH servers
on the Alcatel-Lucent Packet Switch
Offloading data calls to the IPBTS GW server at the RNC
removes the data call load from the Alcatel-Lucent
Packet Switch
BHS hardware
GICC 1.1
PHE3
Hardware
pack
3G-1x RNC
ALU PS
Network
element
TPU
PSU2e or
iPS-2e
Component
Fast Ethernet
Voice &
Data
BPH
Gigabit
Ethernet
Data only IPBTS GW
Network
connectivity
Traffic BHS
MSC signaling endpoint for IPBH
Radio cluster server
The MSC signaling endpoint for IP backhaul is a radio
cluster server (RCS) instance running on a MM application
processor (AP) in the ECPC
Signaling
MM-AP
RCS
RCS-AP BHCA capacity
MM-APs that host RCS instances are
known as RCS-APs
When supporting IPBH cells only,
RCS-AP BHCA capacity is comparable
to its capacity for FR BH cells
When supporting IPBH and FR BH
cells, RCS-AP capacity is ~20% less
IPBH protocol stacks: MSC side
UDP
IP
Ethernet
UDPmux
TCP
IP
Ethernet
Control
Bearer Signaling
Backhaul transport topology
VLAN switching
IP termination L2 VLAN termination
Standards employed for IP backhaul
IEEE 802.1Q
RFC-3317
RFC-1990
RFC-2686
Standard
Edge router
Differentiated services
(DiffServ)
Edge router
MSC switch
Layer 2 VLAN tagging
(802.1Q)
BTS URC
Edge router
Multi-link point-to-point
proctocol (ML-PPP)
Application Required for
IPBH network overview
ALU-PS IPBH platform requirements
PSU2e (PF3/CF3) in a
single or double
configuration, or
iPS-2e shelf in an iPS
Packet switching unit
CORE700 SMP
Symmetric multiprocessor
PHE3 (TN113) pair
(minimum) equipped with
the LLE2 (Electrical) or LLE3
(Optical) Ethernet
paddleboard
Packet handler
Alcatel-
Lucent
Packet
Switch
NE
ALU PS or Standalone ALU PS
(VCDX)
CM3, CM2, or VCDX
3B21D or VCDX
Version(s) required Module or component
Switching module
Configuration module
Administrative module
IP backhaul summary
Multi-link group (MLG): 1 to 8 DS1 pipes (maximum
depends upon URC version)
MLG assembly/disassembly, sequencing, and load
balancing provided at the link layer by ML-PPP
Backhaul server (BHS): backhaul bearer path endpoint
Key concepts
IP transport between the BTS and the MSC What it is
Modcell 1.0, 2.0, or 3.0 with URCm
Modcell 4.0 with URC or URC-II
BTS-facing edge routers with support for
ML-PPP, differentiated services, 802.1q
Multi-layer switches facing the MSC network elements
(ECPC, ALU-PS, and 3G-1x RNC)
BPH cards equipped on the ALU-PS PSU2e/iPS-2e with
BHSPH software
GICC 1.1 packs equipped on the 3G-1x RNC TPU with
IPBTS GW software
What you need
Review
Distinguish between IP backhaul (IPBH) and frame relay
(packet pipe) backhaul
Describe the system requirements for IP transport on
the backhaul
Explain the role of multi-link groups (MLG) in IPBH
Explain what must be done to offload IPBH data traffic
from the Alcatel-Lucent Packet Switch to the 3G-1x RNC
Identify the IPBH backhaul servers and describe the
transmission facilities that terminate to each
Identify the hardware components used in IP backhaul,
and describe the function of each
You should now be able to:
www.alcatel-lucent.com
Session 2
Engineer IP Backhaul
Seminar topic map
Current session
Understand IP
transport in
the core network
Engineer
TrFO/RTO
Monitor IP
transport in the
core network
Understand IP
backhaul
Engineer
IP backhaul
Monitor IP
backhaul
Objectives
Estimate signaling bandwidth for a cell site
Estimate bearer bandwidth for a cell site
Calculate the number of DS1 facilities required for
a cell site backhaul server
Describe the considerations and capacity guidelines
used to engineer the IP backhaul Ethernet facilities
used to engineer the IP backhaul transport facilities
Engineer BPH packs for the Alcatel-Lucent Packet
Switch
Engineer GICC 1.1 packs for the 3G-1x RNC
1. Engineer IP backhaul facilities for a cell site
2. Engineer the IP backhaul transport network
3. Engineer IP backhaul termination packs
~SECTION 0 Section summary
Topics in this session
Engineer IP backhaul facilities
for a cell site
1
~SECTION 1 Engineer IPBH for a cell site
Goal and tasks
Engineer IPBH for a cell site
1 Engineer IP Backhaul
for the cell site
1.1 Estimate
signaling bandwidth
for a URC
1.3 Calculate the
number of DS1
facilities required
1.2 Estimate MLG call
leg bandwidth
Assumptions and capacity tables
Estimate signaling bandwidth
Signaling traffic on bearer facilities
In an IP backhaul network, signaling traffic is multiplexed
over bearer facilities. For this reason it is necessary to
take signaling throughput into account when engineering
bearer facilities for IPBH.
Two approaches
We will consider two approaches for estimating signaling
bandwidth at the URC [ URC | URC-11 | URCm ]:
1.1.a - Apply a formula based upon standard
assumptions and MSC BHCA
1.1.b - Apply a formula based upon service
measurements (throughput for an operational URC)
Task 1.1.a - Assumptions
Estimate DL signaling bandwidth for a cell site
for the cell site
1.1.a Estimate
signaling bandwidth
for a URC (BHCA)
For this task we will use a formula that reflects these standard assumptions:
50% (SMS used to transmit) Message waiting indicator per BHCA
1.3 Average no.of paging messages per paging
event
0.1 Average no. of SMS messages per BHCA
Approximately equal Traffic loading across cell carriers
Less than 10% Data call penetration
Enabled SHAPCARR feature
Average call holding time
UL/DL distribution of signaling traffic
System attribute
Downlink signaling traffic is dominant
100 seconds
Assumption
Task 1.1.a - Equation
( ) kbps 10 CE _ Tot kbps 35 . 0
ell Carriers_c
Carriers BHCA_MSC
kbps 04 . 0
B
(i)
(i)
(i)
sig
+ +
=
Number of traffic channel elements controlled by URC
(i)
Tot_CE
Total number of carriers supported by the cell site Carriers_cell
(i)
MSC busy hour call attempts (units = 1,000) BHCA_MSC
Number of carriers with overhead channels assigned to
a channel card controlled by URC
(i)
(anchor carriers)
Carriers
Bandwdth margin to allow for bursty nature of signaling 10 kbps
Signaling bandwidth for URC
i
[ URCm | URC | URC-II ] B
sig(i)
Where:
Task 1.1.a - Example
( )
( )
kbps 189
10 460 35 . 0 457 04 . 0
kbps 10 460 kbps 35 . 0
7
4 800
kbps 04 . 0 B (i)
sig
=
+ + =
+ +

=
460 Tot_CE
7 Carriers_cell
(i)
800,000 BHCA_MSC
4 Carriers
Assume:
Then:
Task 1.1.b Constitutive service measurements
Uplink
Downlink
Link
Average signaling
throughput
CDMA-SUBCELL/CRC/URC:Field 11
Service measurement
Peak signaling throughput
Peak signaling throughput
Average signaling
throughput
Description
for the cell site
1.1.b Estimate
signaling bandwidth for
a cell site (SvcMeas)
Task 1.1.b Equation
( ) ( ) 5 . 0 1 Peak_UL , Peak_DL max
B
sig
+
=
50% overhead to account for the bursty nature of signaling
traffic
0.5
Peak signaling throughput in the downlink (based on sampling
of service measurement CDMA-SUBCELL/CRC/URC:Field 12)
Peak_DL
Peak signaling throughput in the uplink (based on sampling of
service measurement CDMA-SUBCELL/CRC/URC:Field 14)
Peak_UL
Estimated signaling bandwidth for a URC (BHS) B
sig
Where:
Task 1.2 Concepts
Estimate MLG call leg bandwidth for a cell site
for the cell site
1.2 Estimate
MLG call leg
bandwidth
Signaling path dynamically selected
In an IP backhaul network the signaling path is
dynamically selected by the system based on the
availability states of multi-link groups (MLG)
No need to engineer dedicated standby bandwidth
One consequence of this architecture is that it is not
necessary to engineer dedicated signaling for standby
signaling traffic
Task 1.2 Equation
n
sig sig
s
n
C
nB
B B
1 C
0

=
or
Baseline MLG capacity with n DS1 C
n
Physical layer bandwidth of the MLG with n DS1 nB
0
Signaling bandwidth to the URC/BHS as calculated in
1.1.a or 1.1.b
B
sig
3G-1x EVRC call leg capacity, taking signaling traffic
into consideration
C
s
n
Where:
Task 1.3 Overview
for the cell site
1.3 Calculate the
number of DS1
facilities required
Two parts
Our discussion of this task has two parts:
Engineering principles and capacity tables
Calculations and equations
Task 1.3 Principles and capacity tables
IPBH capacity reference unit
Before IP backhaul
Packet pipe (PP) capacity engineering employs
IS-95 EVRC call legs as the reference capacity unit
With IP backhaul
IPBH capacity engineering employs 3G-1X EVRC
voice call legs as the reference capacity unit
Map 3G-1x EVRC voice call legs to MLGs
810 E1 4
1012 E1 5
1214 E1 6
1416 E1 7
MLG facilities
8
3
2
1
Qty.
392 E1
1620 E1
598 E1
192 E1
Type
Capacity in
3G-1x EVRC VCL
Capacity for E1 facilities:
Note These are bearer capacities only; signaling overhead is not included
Call capacity increases are non-linear
602 E1 4
752 E1 5
902 E1 6
1052 E1 7
MLG facilities
8
3
2
1
Qty.
292 E1
1204 E1
446 E1
142 E1
Type
Capacity in
3G-1x EVRC VCL
Two multi-link groups,
each configured for a
single E1 pipe, have a call
leg capacity of 284 (142*2)
Explanation Call leg capacity increases in a non-linear manner when MLG
facilities are grown. This is because trunking efficiency increases with
transport bandwidth.
One multi-link group
configured for two E1
pipes has a call leg
capacity of 292
IP loading coefficients for service types
Different bandwidth
Call legs consume different
amounts of backhaul
bandwidth depending upon
the type of traffic they
carry. The table shows IPBH
loading coefficients for
different call service types.
1.09 3G 8 kbps SCH
1.00 3G EVRC voice
1.36 2G 8 kbps data FCH
2G 13 kbps voice
2G EVRC voice
Service types
0.90
1.35
IP loading
coefficient
Reference capacity unit
Because 3G EVRC voice is the reference unit for IPBH capacity,
it has an IP loading coefficient of 1.00
Task 1.3 Calculations and equations
Summary of calculations
Caculate required DS1 facilities for each BHS 1.3.4
Calculate estimated total signaling, based on the
URC/BHS signaling bandwidth B
sig
estimated in task
1.2.a or 1.2.b
1.3.3
Estimate the total bandwidth for all bearer traffic on
the backhaul
1.3.2
1.3.1 Estimate the total bandwidth for bearer traffic for
each BHS (URC, URC-II, or URCm)
Task 1.3.1 Equation
Estimate bearer bandwidth for a BHS
i
i
m , i m
IPLC N W =

The set of channel elements tied to the BHS m, where i
is the service type
{N,i,m}
The IP loading coefficient for service type i IPLC
The bearer traffic attached to a backhaul server (the
reference capacity unit is a 3G-1x EVRC voice call leg)
Wm
Where:
Task 1.3.2 Equation
Estimate total BW for all bearer traffic on the backhaul
Bearer total backhaul bandwidth is the summation of the
bandwidth for all backhaul servers in the BTS frame:
=
=
S
1 m
m
W
W
Where S is the number of backhaul servers in the frame and
m
is
the bearer bandwidth estimation for each BHS
Task 1.3.3 Equation
Calculate estimated signaling BW to each BHS
URC signaling bandwidth as estimated in 1.2.a or 1.2.b B
sig
The number of backhaul servers (URC, URC-II, or URCm)
in the BTS frame
M
Estimated signaling bandwidth to each BHS at the cell
site
B
s
Where:
=
=
M
1 i
sig s ) i ( B B
Task 1.3.4 Equation
Calculate required DS1 facilities for a cell site
W
B n
B
1 C
0
sig
n
The total bandwidth of the DS1:

1.536 Mbps for a T1 facility
2.048 Mbps for an E1 facility
B
0
URC signaling bandwidth as estimated in 1.2.a or 1.2.b B
sig
Total backhaul bandwidth as calculated in 1.3.2 W
The baseline capacity (in call legs) for n DS1 facilities C
n
Where:
The number of DS1 facilities is the smallest number that satisfies:
Task 1.3 Example
Inputs to an example DS1 calculation
3 DS0 Signaling configuration
for URCs
Bursting for 25% of the call duration at an
average of 2 times the fundamental rate,
or the equivalent of 24 average bursting
levels
HSPD bursts
2 Number of BHS
(URC) at the site
46 Busy average of 3 sectors at 15
Erlangs per sector
HSPD calls
450 Busy average of 3 sectors at 150
Erlangs per sector
3G EVRC voice calls
E1 DS1 facilities
Assume a cell with these characteristics
Task 1.3.1 Example
Estimate bearer bandwidth for a BHS
1.09 3G 8 kbps SCH
1.00 3G EVRC voice
Call leg type IPLC
( ) ( ) ( )
272
13 34 225
09 . 1 12 46 . 1 23 1 225 W
m
=
+ + =
+ + =
And the calculation with our sample inputs:
i
i
m , i m
IPLC N W =

The 1.3.1 base equation:
Reference: IP loading
coefficient table
Explanation
Each service type
is multiplied by its
corresponding IP
loading coefficient
and the results
summed
Explanation
Each service type
is multiplied by its
corresponding IP
loading coefficient
and the results
summed
Task 1.3.2 Example
Estimate total BW for all bearer traffic on the backhaul
=
=
S
1 m
m
W
W
544
272 272 W
=
+ =
Explanation
There are 2 BHS
at the site, so the
summation is twice
the bearer
bandwidth of each
BHS (or twice 272,
as found in 1.3.1)
Explanation
There are 2 BHS
at the site, so the
summation is twice
the bearer
bandwidth of each
BHS (or twice 272,
as found in 1.3.1)
Task 1.3.3 Example
Calculate total estimated signaling bandwidth
=
=
M
1 i
) i ( sig s B B
kbps 378
kbps 189 2 B
s
=
=
How do we know that?
The B
sig
value
(estimated signaling
bandwidth to each
URC/BHS) of 189 kbps
was calculated in 1.2
above
How do we know that?
The B
sig
value
(estimated signaling
bandwidth to each
URC/BHS) of 189 kbps
was calculated in 1.2
above
Task 1.3.4 Example
Estimate signaling bandwidth for a BHS
W
B n
B
1 C
0
sig
n
( )
272 274
274 94 . 0 292
W 06 . 0 1 292
W
Mbps 536 . 1 2
kbps 189
1 292

And the calculation with our inputs:
MLG facilities
3
2
1
Qty.
292 E1
446 E1
142 E1
Type
Capacity in
3G-1x EVRC VCL
Reference:
DS1 capacity table
Explanation Two E1, with a
capacity of 292 EVRC 3G voice
calls, is a likely C
n
because we
know from 1.3.1 that the
required bearer capacity is 272.
When we apply the equation to
subtract the signaling overhead,
we confirm that 2 E1s provide a
bearer capacity of 274 EVRC
voice calls, which exceeds the
required bearer capacity
Explanation Two E1, with a
capacity of 292 EVRC 3G voice
calls, is a likely C
n
because we
know from 1.3.1 that the
required bearer capacity is 272.
When we apply the equation to
subtract the signaling overhead,
we confirm that 2 E1s provide a
bearer capacity of 274 EVRC
voice calls, which exceeds the
required bearer capacity
Review: goal and tasks
Engineer IPBH for a cell site
1 Engineer
IP backhaul
for the cell site
1.1 Estimate
signaling bandwidth
per URC (BHS)
1.3 Calculate the
number of DS1
facilities required
1.2 Estimate MLG
call leg bandwidth
1.1.a DL, BHCA
1.1.b Peak, SM
1.3.1 BHS BW
1.3.2 IPBH BW
1.3.3 Total Sig. BW
1.3.4 No. of DS1
Engineer the IP backhaul
transport network
2
~SECTION 2 Engineer IPBH transport
facilities
Goal and tasks
Engineer IPBH transport network
transport network
2.1 Engineer Ethernet
facilities
2.3 Engineer transport
facilities
IP backhaul transport topology
Edge router
Edge router basics
The edge router is the cell site access point to the
IP backhaul core network
Terminates DS1 links ( E1) from the BTS URC
In place of DS1, any SDH facility may be used
Definitions
Router standards support
RFC-3317 Differentiated services (DiffServ)
RFC-1990
RFC-2686
Multilink point-to-point proctocol (ML-PPP)
Application Standard
IEEE 802.1Q Layer 2 VLAN tagging (802.1Q)
Application Standard
Edge routers must support these standards:
Backhaul routers must support this standard:
Traffic classes for IP backhaul
Lowest priority
Default traffic
class
Secondary priority
Highest priority
Description
IPBH signaling
High-priority OA&M
traffic (OA&M control)
Assured forwarding
(AF)
Low-priority OAM traffic
(OA&M downloads such
as software updates)
Best effort (BE)
IPBH bearer Expedited forwarding
(EF)
DiffServ traffic class Used for
Task 2.1 Ethernet facility engineering
Two cases for Ethernet facility engineering
Case 1 - Multiplexing
3G-1x packet data is multiplexed with voice
Data and voice both terminate at backhaul protocol
handlers in the Alcatel-Lucent Packet Switch
Case 2 Data offloading
3G-1x packet data is offloaded to dedicated
backhaul servers in the 3G-1x RNC
Voice terminates at BPHs in the ALU PS
Data terminates at GICC 1.1 cards in the 3G-1x RNC
Case 1 assumptions and guidelines
55,000 5,500 Packet data case 1
Packet data case 2
EVRC voice
3G-1x call
leg type
Ethernet rate
40,000 4,000
75,000 7,500
100BaseTX
Fast Ethernet
1000BaseFX/SX
Gigabit Ethernet
Assumptions
3G-1x packet data is 10% of all traffic
Multiplexing performance on the backhaul is 70% of
optimal performance
Average 3G-1x packet FCH activity is ~50%
Packet data calls generate SCH bursts for ~25% of call duration on
the forward link
Case 2 assumptions and guidelines
55,000 5,500 Packet data case 1
Packet data case 2
EVRC voice
3G-1x call
leg type
Ethernet rate
40,000 4,000
75,000 7,500
100BaseTX
Fast Ethernet
1000BaseFX/SX
Gigabit Ethernet
Assumptions
Multiplexing performance on the backhaul is 30% of optimal
performance
Lower efficiency is due to lower penetration of data traffic and
therefore fewer multiplexing efficiency gains
Average 3G-1x packet FCH activity is ~50%
Packet data calls generate SCH bursts for ~25% of call duration on
the forward link
Engineer IP backhaul termination
packs
3
~SECTION 3 Engineer IPBH termination
packs
Goal and tasks
Engineer IPBH termination packs
3 Engineer
IP Backhaul
termination packs
3.1 Engineer
BPH pairs
3.2 Engineer
IPBTS GW pairs
Task 3.1 Engineer Backhaul Protocol Handler pairs
Basics
Backhaul Protocol Handlers (BPH) are a pooled
resource
A PSU2e supports up to 10 BPH pairs
The individual cards in each pair run in-service and
standby
Because these packs are a pooled resource, the
measure of BPH demand is the average aggregate
traffic on the backhaul
Each BPH has a capacity of 2,000 3G-1x RNC call
legs
Task 3.1 Calculations and equations
Calculate total backhaul traffic 3.1.4
Adjust SCH demand figure to reflect larger SCH
packet size
3.1.3
Estimate SCH traffic demand 3.1.2
3.1.5
3.1.1 Estimate primary FCH traffic demand
Calculate required number of BPH pairs
Task 3.1.1 Equation
Estimate primary FCH traffic demand
+ =
k
k k p
D V E ) (
Average data traffic in Erlang from cell k D
K
Average voice traffic in Erlang from cell k V
k
Primary FCH traffic demand to PSU p E
p
Where:
Erlang basis Erlang averages for both voice and data are based on FCH
holding at the busy hour
Task 3.1.2 Equation
Estimate SCH traffic demand
=
k
k p
D S 25 . 0
Average data traffic in Erlang from cell k D
K
Each primary packet data FCH Erlang is assumed to
generate 0.25 SCH Erlang on the forward link
0.25
SCH traffic demand to PSU p S
p
Where:
Task 3.1.3 Equation
Adjust SCH traffic demand for packet size
SCH traffic demand to PSU p, as calculated in 3.3.2 S
p
Relative size of SCH packets as compared to FCH packets 2.5
SCH traffic demand, adjusted for packet size, to PSU p S
e
p
Where:
p
e
p
S S = 5 . 2
Task 3.1.4 Equation
Calculate total backhaul traffic
Soft handoff overhead on the backhaul. 50% is the
default value.
SHO_OH
SCH traffic demand, adjusted for packet size, to PSU
p, as calculated in 3.3.3
S
e
p
Primary FCH traffic demand to PSU p, as calculated in
3.3.1
E
p
Total IP backhaul traffic to PSU p T
p
Where:
e
p p p
S SHO_OH E T + + = ) 1 (
Refine SHO_OH Service measurements can be used to refine the SHO_OH
default overhead of 50%
Task 3.1.5 Equation
Calculate the number of BPH pairs
3G-1x EVRC voice call capacity of a BPH. Capacity is
2,000 voice calls.
C
p
Total IP backhaul traffic to PSU p, as calculated in 3.3.4 T
p
Number of BPH pairs required to support IP backhaul
traffic demand to PSU p
N
p
Where:
=
p
p
p
C
T
N
Task 3.2 Engineer IPBTS GW pairs
Basics
IPBTS GW are a pooled resource
A PSU2e supports up to 2 IPBTS GW pairs
The individual cards in each pair run in-service and
standby
Because these packs are a pooled resource, the
measure of IPBTS GW demand is the average
aggregate data call traffic on the backhaul
Each IPBTS GW has a capacity of 12,500 data call
legs
Task 3.2 Calculations
Calculate required number of IPBTS GW pairs 3.2.4
Adjust SCH demand figure to reflect larger SCH
packet size
3.2.3
Estimate SCH traffic demand 3.2.2
3.2.1 Estimate primary FCH traffic demand
Task 3.2.1 Equation
Estimate primary data FCH traffic demand
Average packet data traffic in Erlang from cell j D
j
Primary data FCH traffic demand to RNC g E
g
Where:
=
j
j g
D E
Task 3.2.2 Equation
Estimate SCH traffic demand
Primary data FCH traffic demand to RNC g, as calculated
in 3.4.1
E
g
Each primary packet data FCH Erlang is assumed to
generate 0.25 SCH Erlang on the forward link
0.25
SCH traffic demand to RNC g S
g
Where:
g g
E S = 25 . 0
SCH packet size SCH packet size does not have a significant effect on
IPBTS GW capacity and need not be taken into account
Task 3.2.3 Equation
Calculate total backhaul traffic
Soft handoff overhead on the backhaul. 50% is the
default value.
SHO_OH
SCH traffic demand, adjusted for packet size, to RNC
g, as calculated in 3.4.2
S
g
Primary FCH traffic demand to RNC g, as calculated in
3.4.1
E
g
Total backhaul traffic to RNC g T
g
Where:
g g g
S SHO_OH E T + + = ) 1 (
Task 3.2.4 Configurations
Calculate number of IPBTS GW pairs
Equipped on TPUs
IPBTS GW cards (GICC 1.1 cards) are equipped on
Traffic Processor Unit shelves (cPSB shelves) in the
RNC frame. There are two TPU shelves in a frame.
0 pair
1 pair
2 pair
Valid TPU configurations
There are 3 valid configurations of IPBTS GW (GICC
1.1 pairs) for a RNC:
Task 3.2.4 Equation
Calculate number of IPBTS GW pairs
Call leg capacity of the IPBTS GW. Capacity is 12,500
data call legs.
C
g
Engineering utilization for the IPBTS GW. Utilization is
0.90, or 90%.
g
Total IP backhaul traffic to RNC g, as calculated in 3.4.3 T
g
Number of GICC 1.1 pairs required to support backhaul
traffic demand to RNC g
N
g
Where:
=
g g
g
g
C
T
N
Backhaul associations
Two types
There are three types of backhaul association (BHA):
Logical backhaul association
IP backhaul association
UDP backhaul association
Logical backhaul associations
Logical backhaul association
Logical association between the IPBTS GW and a
BTS multi-link group (MLG)
A maximum of 512 logical BHA are supported on a
GICC 1.1 card
IP backhaul associations
IP backhaul association
An IP BHA is the instantiation of a logical BHA
An IP BHA links the IP address of a BTS MLG to the
IP address of a BHS in the core network
Each IP BHA contains one or two UDP backhaul
associations
UDP backhaul associations
UDP backhaul association
A UDP backhaul association is the functional
analogue of a packet pipe
Each UDP BHA belongs to exactly one IP BHA
A UDP BHA consists of the IP address endpoints of
the MLG and BHS, and UDP port assignments
Each UDP BHA supports up to 240 call legs
Up to 2 UDP BHAs are supported for an IP BHA
Review: goal and tasks
Engineer IPBH termination packs
3 Engineer
IP Backhaul
termination packs
3.1 Engineer
BPH packs
3.2 Engineer
IPBTS GW packs
3.1.1 FCH traffic
3.1.2 SCH traffic
3.1.3 Adjust SCH
3.1.4 Total BH
3.1.5 No. BPHpairs
3.2.1 SCH traffic
3.2.2 FCH traffic
3.2.3 Adjust SCH
3.2.4 NoIPBTSGW
Review
Estimate bearer bandwidth for a cell site
Calculate the number of DS1 facilities required for
a cell site backhaul server
used to engineer the IP backhaul Ethernet facilities
used to engineer the IP backhaul transport facilities
Engineer BPH packs for the Alcatel-Lucent Packet
Switch
Engineer GICC 1.1 packs for the 3G-1x RNC
Supplementary materials
~SUPPLEMENTARY MATERIALS
IPBH protocol stacks: URC to edge device
UDP
UDPmux (proprietary)
ML-PPP
PPP
NxDS1 (T1 | E1)
IP
TCP
ML-PPP
PPP
NxDS1 (T1 | E1)
IP
Control
Bearer Signaling
IPBH protocol stacks: MSC side
UDP
IP
Ethernet
UDPmux
TCP
IP
Ethernet
Control
Bearer Signaling
GICC 1.1 address space capacity
IP connection capacity
IPBTS GW cards also have an IP address capacity limit.
Not capacity limited by IP addresses
It is expected that GICC 1.1 pools in IP backhaul
deployments will not be capacity limited by IP address
availability
In Release 28, a GICC 1.1 card can open up to 896 IP
connections with multi-link groups (MLG) in the radio
access network
In Release 28 SU2, this increases to 1024 IP connections
Session 3
Monitor an IP Backhaul
Network
Seminar topic map
Current session
Understand IP
transport in
the core network
Engineer
TrFO/RTO
Monitor IP
transport in the
core network
Understand IP
backhaul
Engineer
IP backhaul
Monitor IP
backhaul
Objectives
Identify the events that trigger switch alarms for a
multi-link group (MLG) DS1 bit error rate (BER)
Describe what happens when a DS1 BER major
alarm is raised
Monitor MLG utilization
Identify cell site critical triggers for IP backhaul
(IPBH)
Identify PSU critical triggers for IPBH
Identify 3G-1x RNC critical triggers and service
measurements for IPBH
Identify signaling link measurements for IPBH
At the end of this lesson you should be able to:
Service measurements
For detailed
information
about CDMA
Wireless Network
service
measurements,
see Service
Measurements,
Volumes 1 and 2
Flexent
/ AUTOPLEX
Executive Cellular Processor (ECP)

Service Measurements, Volume 1
Release 28.0
401-610-135
Service measurements overview
A summary list of
IPBH service
measurements
and traffic
measurements is
found in this
customer
document
CDMA Backhaul Networks
IP Backhaul
Release 28.0
401-710-090
1. Understand system monitoring of MLG DS1 bit
error rates
2. Monitor MLG utilization
3. Monitor cell site critical triggers
4. Monitor PSU packet bus critical triggers
5. Monitor RNC critical triggers and service
measurements
6. Monitor IPBH signaling links
Understand system monitoring of
MLG DS1 bit error rates
1
IP backhaul block error rates
Voice quality
Like other transport networks, IP backhaul networks
are subject to random transmission errors and
unstable facilities. Error rates in the backhaul
network degrade the quality of the speech
connection.
Perceived quality
The perceived quality of the voice stream (as defined
by the PESQ standard) declines as the backhaul bit
error rate increases
Definitions
BER and PESQ
Bit error ratio (BER)
The ratio of bits incorrectly received to the total number of
bits received
Perceptual evaluation of speech quality (PESQ)
An ITU-T standard (P.862) for assessing the perceived quality of
speech in telecommunications systems. PESQ is intended for
applications in which there is a variable delay between
reference and test signals, including (but not limited to) voice
over IP. PESQ combines a time alignment algorithm with the
cognitive model defined in the earlier standard Perceptual
Speech Quality Measure (PSQM, PSQM+).
Alarms generated for BER thresholds
The system generates a major alarm when the
BER level reaches 1.0e-03
The system generates a minor alarm when the
BER level reaches 1.0e-06
Minor alarm
If more than one DS1 are associated with the
MLG, the system removes the problem DS1
If only one DS1 is associated with the MLG,
the DS1 is not removed
Major alarm
Note Both alarm thresholds can be adjusted upon customer request
The system monitors the BER of DS1 pipes assigned to multilink
groups. Two alarms are tied to the BER level:
Alarms appear on the switch Status Display Page (SDP) and the
Read-Only Printer (ROP)
2
Multilink groups and DS1 facilities
MLG and DS1
One or more DS1 facilities are associated with each IP
backhaul multilink group (MLG)
Load sharing
The ML-PPP layer distributes signaling and bearer
traffic across the set of DS1 facilities associated with
a given MLG. For this reason, occupancy levels for the
DS1 within a MLG should be comparable.
MLG DS1 the likely transport bottleneck
Other segments have greater capacity
Initial engineering for IP backhaul networks should
ensure that other transport segments have greater
capacity than the DS1 pipes between the BTS and the
backhaul access concentrator or edge router
Bottleneck
This means that an IP backhaul network is capacity
limited by its DS1 segment
MLG utilization measures
N
_Occupancy 1 Average_DS
ion G_Utilizat Average_ML
N
1 i
(i)
=
=
N
_Occupancy 1 Peak_DS
tilization Peak_MLG_U
N
1 i
(i)
=
=
MLG average utilization is modeled with this formula:
MLG peak utilization is modeled with this formula:
Where N is the number of DS1 assigned to the MLG
DS1 occupancy thresholds
Thresholds
A DS1 (and by extension a MLG) is highly loaded when:
Peak occupancy approaches 80% and average occupancy
approaches 50%, or
Average occupancy approaches 70%
Recommendation The Alcatel-Lucent recommendation is to
add DS1 facilities when either of these thresholds is reached
Measuring DS1 occupancy
_speed 1 DS
) UL _ hput Ave_Throug , DL _ ghput (Ave_Throu max
_speed 1 DS
) UL _ ghput Peak_Throu , DL _ ughput (Peak_Thro max
Note DS1 occupancy measurements only count traffic in the expedited
forwarding and assured forwarding traffic classes; counting the OAM downloads
and other episodic network traffic found in the best effort class would skew
capacity engineering
Find DS1 average occupancy:
Find DS1 peak occupancy:
The occupancy service measurements are CDM-URC-DS1,
Field 1 and Field 2
Critical trigger
CDMA_IPBH_UTIL_URC average occupancy
Add DS1 facilities to the URC Action
Every 10 seconds during the measurement
interval
Sampling
CDMA-URC-DS1 Field 1 Measurement
70% Trigger
Average occupancy service measurement
averaged for all DS1 on the URC
Transmitted bytes as a percentage of DS1
total capacity
Method
(SubCell) TREND CDMA_IPBH_UTIL_URC_AVG PROSPECT
Average IP backhaul utilization for all DS1 on
the Universal Radio Controller
Description
Critical trigger
CDMA_IPBH_UTIL_URC peak occupancy
Add DS1 facilities to the URC Action
interval
Sampling
CDMA-URC-DS1 Field 2 Measurement
85% Trigger
Peak occupancy service measurement
averaged for all DS1 on the URC
Transmitted bytes as a percentage of DS1
total capacity
Method
(SubCell) TREND CDMA_IPBH_UTIL_URC_PK PROSPECT
Peak IP backhaul utilization for all DS1 on the
Universal Radio Controller
Description
Customer document 401-610-135
CDMA-URC-DS1
Description (CDMA-URC-DS1) Field #
Average DS1 Occupancy: This count represents the average occupancy
of DS1(T1/E1) backhaul link when the BTS is running in IP Backhaul
(IPBH) mode. Each equipped DS1 is sampled and averaged every 10-
second interval and the averaged value for an hour is reported. The count
shall provide the ability to monitor the backhaul utilization on per DS1
basis in terms of throughput by counting the number of bytes transmitted
per second and comparing it to maximum bandwidth of unchannelized
DS1 to determine 'Average DS1 Occupancy in percentage.
1
Peak DS1 Occupancy: This count represents the peak occupancy of DS1
(T1/E1) backhaul link when the BTS is running in IP Backhaul mode. Each
equipped DS1 is sampled every 10-second interval and the hourly count is
reported. For a given DS1, every 10 seconds, 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 provides the ability to monitor the backhaul
utilization per DS1 basis in terms of throughput by counting the number of
bytes transmitted and determining the peak occupancy in each hourly
service monitoring window in percentage by comparing it with maximum
bandwidth of an unchannelized DS1.
2
Monitor cell site critical triggers
3
IP backhaul critical triggers (1 of 3)
Call accessibility and reliability
IP backhaul resource limitations can compromise call
accessibility and reliablity. Alcatel-Lucent provides a
set of critical triggers for monitoring IPBH resource
utilization at the cell site.
Call accessibility critical triggers
Accessibility critical triggers are provided for these
dimensions of the system:
Voice call terminations and orginations blocked due to
unavailability of IPBH resources
Data call terminations and orginations blocked due to
unavailability of IPBH resources
Voice call terminations and orginations blocked due to
one of the following:
Backhaul (IP or frame relay) resource unavailability
Walsh code starvation
Channel element resource unavailability
Call reliability critical triggers
Reliability critical triggers are provided for these
dimensions of the system:
Voice call soft handover blocking rate due to backhaul
resource unavailability
Data call soft handover blocking rate due to backhaul
resource unavailability
Call accessibility critical triggers
Critical trigger
CDMA_VOICE_BHS_BLK_RATE_OT (1 of 2)
Add additional BHS or rebalance load across existing
BHS
Action
Network operator engineering judgement
SMRG tool generates warnings from 85%
Trigger
Each BHS blocks calls when running at a capacity
load. Calls blocked by one BHS may be carried on
another BHS in the cell.
Method
(Cell_Carrier) TREND CDMA_VOICE_BHS_BLK_RATE_OT PROSPECT
Voice blocking rate (origination and termination)
due to backhaul server(BHS) resource unavailability
Description
Critical trigger
CDMA_VOICE_BHS_BLK_RATE_OT (2 of 2)
( )
100
7 CDMA-CARR ] 33 32 20 19 [ ARR-SC CDMA-PAF-C
7 CDMA-CARR
+ + + +
2G originations assigned to a CDMA traffic channel Field 19
2G terminations assigned to a CDMA traffic channel Field 20
3G originations assigned to a 3G fundamental channel Field 32
Voice origination & termination overflow due to BHS blocking Field 7
3G terminations assigned to a 3G fundamental channel Field 33
Note All counts shown are summed over all sectors for these service
classes: 8k voice, 13k voice, EVRC, EVRC-B, CMDATA, and SMV
Where:
Critical trigger
CDMA_DATA_BHS_BLK_RATE_OT (1 of 2)
BHS
Action
Trigger
Each BHS blocks calls when running at a capacity
load. Calls blocked by one BHS may be carried on
another BHS in the cell.
Method
(Cell_Carrier) TREND CDMA_DATA_BHS_BLK_RATE_OT PROSPECT
Packet data call blocking rate (origination and
termination) due to backhaul server(BHS) resource
unavailability
Description
Critical trigger
CDMA_DATA_BHS_BLK_RATE_OT (2 of 2)
( )
100
8 CDMA-CARR
+ + + +
Packet data origination & termination overflow due to BHS
blocking
Field 8
Note All counts shown are summed over all sectors for all service classes
Where:
Critical trigger
CDMA_CE/BH/WC_BLK_RATE_OT (1 of 3)
interval
Sampling
Trigger
Peak occupancy service measurement averaged
for all DS1 on the URC
Method
(Cell) TREND CDMA_CE/BH/WC_BLK_RATE_OT PROSPECT
Cell site voice call blocking (origination and
termination) due to resource starvation for:
(1) backhaul (IP or frame relay),
(2) Walsh codes, or
(3) channel elements
Description
Critical trigger
( )
100
7 CDMA-CARR
+ + + +
Origination & termination overflow due to BHS blocking Field 7
Note All counts shown are summed over all sectors for all service classes
Where:
Critical trigger - Actions
1. Identify the source of the call blocking by
examining these critical triggers:
CDMA_CE_UTIL_% Channel element utilization
CDMA_PP_BLK_RATE_OT Packet pipe blocking rate
2. If the cause is confirmed to be unavailability of IP
backhaul capacity, add IPBH DS1 facilities to the
cell.
Call reliability critical triggers
Critical trigger
CDMA_VOICE_BHS_BLK_RATE_HO (1 of 2)
BHS
Action
Trigger
(Cell_Carrier) TREND CDMA_VOICE_BHS_BLK_RATE_HO PROSPECT
Voice soft handoff blocking rate due to backhaul
server(BHS) resource unavailability (does not
include semi-soft or hard handoffs, or packet data
call handoffs)
Description
Critical trigger
CDMA_VOICE_BHS_BLK_RATE_HO (2 of 2)
2G intra-MSC soft handoff orders at the target cell site Field 31
2G inter-MSC soft handoff orders at the target cell site Field 32
3G intra-MSC soft handoff orders at the target cell site Field 105
Voice soft handoff overflow due to BHS blocking (exclusive of
semi-soft and hard handoffs)
Field 9
3G inter-MSC soft handoff orders at the target cell site Field 106
Note All counts shown are summed over all sectors for these service
classes: 8k voice, 13k voice, EVRC, EVRC-B, CMDATA, and SMV
Where:
( ) ( ) ( )
100
9 CDMA-CARR ] 106 105 -SC 32 31 -VO [ ARR CDMA-PAF-C
9 CDMA-CARR

+ + + +
Critical trigger
CDMA_DATA_BHS_BLK_RATE_HO (1 of 2)
BHS
Action
Trigger
(Cell_Carrier) TREND CDMA_VOICE_BHS_BLK_RATE_HO PROSPECT
Voice soft handoff blocking rate due to backhaul
server(BHS) resource unavailability (does not
include semi-soft or hard handoffs, or packet data
call handoffs)
Description
Critical trigger
CDMA_DATA_BHS_BLK_RATE_HO (2 of 2)
3G intra-MSC soft handoff orders at the target cell site
{PMDATA}
Field 105
Data soft handoff overflow due to BHS blocking Field 10
3G inter-MSC soft handoff orders at the target cell site
{PMDATA}
Field 106
Where:
( ) ( )
100
10 CDMA-CARR ] 106 } PMDATA { 105 } PMDATA [{ ARR-SC CDMA-PAF-C
10 CDMA-CARR

+ +
Note All counts are summed over all sectors
Summary
Critical triggers for the cell site
CDMA_DATA_BHS_BLK_RATE_HO Data soft handover
Call
reliability
Call
accessibility
Voice soft handover
BHS, code, or CE limits
Data blocking rate
Voice blocking rate
CDMA_VOICE_BHS_BLK_RATE_HO
CDMA_DATA_BHS_BLK_RATE_OT
CDMA_VOICE_BHS_BLK_RATE_OT
CDMA_CE/BH/WC_BLK_RATE_OT
Monitor PSU packet bus critical
triggers
4
PSU2e critical triggers
Access to PSU2e packet bus the bottleneck
Access from the BPH pool to the packet bus is the limiting
resource in the PSU2e for IP backhaul applications
BHSPH capacity limitation
The packet bus is implemented on the Packet Fanout 3
(PF3) hardware. The Backhaul Server Packet Handler
(BHSPH) software running on Backhaul Packet Handlers
(BPH) are capacity limited by BPH access to the PF3.
Critical trigger
The critical trigger BHSPH_PF3_UTIL monitors BHSPH
utilization
Critical trigger
NAR_BHSPH_PF3_UTIL and I5_BHSPH_PF3_UTIL
I5_BHSPH_PF3_UTIL
Name
(International)
NAR_BHSPH_PF3_UTIL
Name (North
American region)
Add a BPH/BHSPH pair to the PSU2e Action
TRFC30 Section 54 IP BACKHAUL MEASUREMENTS
(IPBPH) MAXBPHOCC
Measurement
80% Trigger
Utilization of the Backhaul Server Packet Handler
(BHSPH) software running on Backhaul Packet
Handlers (BPH) in the PSU2e. BHSPH resources are
capacity limited by BPH access to the PF3.
Description
Monitor RNC critical triggers and
service measurements
5
RNC service measurements
Reporting service measurements
3G-1x RNC service measurements are reported using this
method:
Measurements are taken every 10 seconds and
reported every 15 minutes
The highest measurement in a 15-minute period is
reported as the peak
Hourly average and peak values are reported
Network endpoints for RNC IPBH service measurements
Terminology RNC service measurements have the concept of an IPBTS
gateway (GW). The IPBTS GW is another name for the IP backhaul server
instance on a GICC. From the perspective of the external packet data
network, the mobile end user is accessible through the GICC gateway.
Potential RNC bottlenecks for IPBH
RNC bottlenecks
These system attributes are potential bottlenecks for the
3G-1x RNC in IP backhaul applications:
Limit of 512 BHA per IPBTS GW (GICC 1.1)
GICC processing limit of ~12,500 call legs
GICC bandwidth
GICC UDP port limit
Likely RNC bottlenecks for IPBH
Data call penetration
The likely primary bottleneck for the RNC depends in part
on the percentage of data call traffic in the system. When
the data call penetration is near 10%, as it is in some
deployed systems today, the likely primary bottleneck is
the BHA limit of 512
GICC call leg maximum
In systems with a higher level of data call traffic, the
GICC processor maximum of ~12,500 call legs may become
the likely primary bottleneck. In systems with ~10% data
call traffic, the GICC limit is a likely secondary bottleneck
Summary
RNC bearer path measurements for IPBH
AverRateIPBTSGWToFS
PeakRateIPBTSGWToFS
RNC FS
(CICC)
Outgoing
RAN BTS
RNC FS
RAN BTS
RNC FS
(CICC)
RAN BTS
RAN BTS
RAN BTS
GICC Peer
Incoming
Outgoing
Incoming
Incoming
Outgoing
Incoming
Direction
AverRateIPBTSGWToBS
PeakRateIPBTSGWToBS
AverRateBSToIPBTSGW
PeakRateBSToIPBTSGW
Ethernet packets
per second
AverUDPPayloadBSToIPBTSGW
PeakUDPPayloadBSToIPBTSGW UDP payload
octets per second
AverRateFSToIPBTSGW
PeakRateFSToIPBTSGW
AverUDPPayloadIPTBSGWToBS
PeakUDPPayloadIPTBSGWToBS
NumbUDPReqRejected
Rejected UDP port
requests
Measurements System attribute
GICC processor occupancy
AverRateIPBTSGWToFS
PeakRateIPBTSGWToFS
RNC FS
(CICC)
Outgoing
RAN BTS
RNC FS
(CICC)
RAN BTS
RAN BTS
RAN BTS
GICC Peer
Incoming
Outgoing
Incoming
Incoming
Outgoing
Incoming
Direction
AverRateIPBTSGWToBS
PeakRateIPBTSGWToBS
AverRateBSToIPBTSGW
PeakRateBSToIPBTSGW
Ethernet packets
per second
octets per second
AverRateFSToIPBTSGW
PeakRateFSToIPBTSGW
NumbUDPReqRejected
Rejected UDP port
requests
Bottleneck This service measurement shows Ethernet
packet rates for traffic from the RNC frame selector pool
on the CICC through the GICC and on to the RAN BTS. It is
a proxy for GICC processor occupancy.
Bottleneck This service measurement shows Ethernet
packet rates for traffic from the RNC frame selector pool
on the CICC through the GICC and on to the RAN BTS. It is
a proxy for GICC processor occupancy.
GICC bandwidth utilization
AverRateIPBTSGWToFS
PeakRateIPBTSGWToFS
RNC FS
(CICC)
Outgoing
RAN BTS
RNC FS
(CICC)
RAN BTS
RAN BTS
RAN BTS
GICC Peer
Incoming
Outgoing
Incoming
Incoming
Outgoing
Incoming
Direction
AverRateIPBTSGWToBS
PeakRateIPBTSGWToBS
AverRateBSToIPBTSGW
PeakRateBSToIPBTSGW
Ethernet packets
per second
octets per second
AverRateFSToIPBTSGW
PeakRateFSToIPBTSGW
NumbUDPReqRejected
Rejected UDP port
requests
Bottleneck This service measurement shows UDP payload
octets sent from the GICC to the RAN BTS. It is a direct
indicator of GICC bandwidth utilization.
Bottleneck This service measurement shows UDP payload
octets sent from the GICC to the RAN BTS. It is a direct
indicator of GICC bandwidth utilization.
RNC critical triggers for IPBH
Two critical triggers
AverRateIPBTSGWToFS
PeakRateIPBTSGWToFS
RNC FS
(CICC)
Outgoing
RAN BTS
RNC FS
(CICC)
RAN BTS
GICC Peer
Outgoing
Incoming
Incoming
Direction
AverRateIPBTSGWToBS
PeakRateIPBTSGWToBS
AverRateBSToIPBTSGW
PeakRateBSToIPBTSGW
Ethernet packets
per second
AverRateFSToIPBTSGW
PeakRateFSToIPBTSGW
The RNC also provides two critical triggers for IP backhaul.
The first is built from these Ethernet packet rate
measurements:
Critical trigger
RNC_IPBHGW_LOAD (1 of 2)
cgrncIPBH Measurement
group
Add GICC 1.1 resources Action
Limit value is 625,000
Alcatel-Lucent recommends configuring a
warning to be generated at 530,000 packets
per second
Trigger
Load in packets per second on a RNC IPBH
gateway (IPBTS gateway = active GICC 1.1 card)
Description
Critical trigger
RNC_IPBHGW_LOAD (2 of 2)
( ) BTSGWToFS AverRateIP , ToIPBTSGW AverRateFS max
( ) BTSGWToFS PeakRateIP , ToIPBTSGW PeakRateFS max
Take the greater of the two average rates to find the
average load:
Take the greater of the two peak rates to find the
peak load:
UDP port utilization
AverRateIPBTSGWToFS
PeakRateIPBTSGWToFS
RNC FS
(CICC)
Outgoing
RAN BTS
RNC FS
RAN BTS
RNC FS
(CICC)
RAN BTS
RAN BTS
RAN BTS
GICC Peer
Incoming
Outgoing
Incoming
Incoming
Outgoing
Incoming
Direction
AverRateIPBTSGWToBS
PeakRateIPBTSGWToBS
AverRateBSToIPBTSGW
PeakRateBSToIPBTSGW
Ethernet packets
per second
octets per second
AverRateFSToIPBTSGW
PeakRateFSToIPBTSGW
NumbUDPReqRejected
Rejected UDP port
requests
Bottleneck This service measurement shows UDP port requests
rejected due to unavailability of UDP resources. It is a direct
indicator of UDP port utilization. It is also the basis of the
critical trigger RNC_IPBH_BHA_OVL.
Bottleneck This service measurement shows UDP port requests
rejected due to unavailability of UDP resources. It is a direct
indicator of UDP port utilization. It is also the basis of the
critical trigger RNC_IPBH_BHA_OVL.
Critical trigger
RNC_IPBH_BHA_OVL
URCs open BHA to primary and secondary 3G-
1x RNC endpoints. Each BHA supports 240 call
legs. When existing BHAs approach full
occupancy, URCs attempt to open a new BHA.
When the RNC lacks UDP port resources for a
new BHA, this overload condition results.
Description
NumbUDPReqRejected Measurement
cgrncIPBH
Measurement group
Add GICC 1.1 resources
Disable RNC data offload at some URCs in
the RAN (this will redirect data traffic
through the Alcatel-Lucent Packet Switch)
Action
An IPBH gateway (GICC 1.1) has been asked to
allocate more backhaul associations (BHA)
than it can support
Trigger
Monitor IPBH signaling links
6
IPBH signaling measurements
Peak Signaling Traffic Load DL
Total RCS Messages AP to URC
Peak Signaling Traffic Load UL
Ave. Signaling Traffic Load DL
FMM-AP ECP
Ave. Signaling Traffic Load UL
URC BTS
Total RCS Messages URC to AP
Measurement Component NE
URC signaling measurements
Peak Signaling Traffic Load UL
Ave. Signaling Traffic Load UL
URC BTS
Use these measurements for . . .
Engineering multilink groups (MLG) and sizing backhaul
facilities (as in task 1.1.b in IPBH engineering)
AP downlink load signaling measurements
FMM-AP ECP
Engineering RCS Application Processors. These
measurements, which report Ethernet traffic on the
downlink, give a good indication of forward link loading
and so can be used for AP sizing.
RCS-AP signaling measurements
Total RCS Messages URC to AP
Total RCS Messages AP to URC
FMM-AP ECP
Engineering the number of RCS instances per AP. RCS
message levels are directly correlated with AP processor
occupancy. They can also be used as a critical trigger for AP
occupancy.
Review
Identify the events that trigger switch alarms for a
multilink group (MLG) DS1 bit error rate (BER)
Describe what happens when a DS1 BER major
alarm is raised
Identify cell site critical triggers for IP backhaul
(IPBH)
Identify PSU critical triggers for IPBH
Identify 3G-1x RNC critical triggers and service
measurements for IPBH
Identify signaling link measurements for IPBH
Session 4
Understand IP transport in
the core network
Seminar topic map
Current session
Understand IP
transport in
the core network
Engineer
TrFO/RTO
Monitor IP
transport in the
core network
Understand IP
backhaul
Engineer
IP backhaul
Monitor IP
backhaul
Objectives
Explain why transcoder-free operation (TrFO) for
mobile-to-mobile EVRC calls is not possible when the
originating and terminating switches are connected only
by a TDM mesh
Distinguish between TrFO and remote transcoder
operation (RTO)
Distinguish between circuit vocoders, packet vocoders,
and packet frame selectors
Identify the Alcatel-Lucent Packet Switch boards
required for TrFO/RTO, and describe the function of
each
1. Introduction to TrFO and RTO
2. Resource use by call scenario
3. SIP signaling for TrFO/RTO
Introduction to TrFO and RTO
1
~SECTION 3 PMs and KPIs
Traditional bearer path
Key points
Frame selection (FS) and
vocoding (VC) are performed at
both ends of the call
TDM is used for the bearer path
through the PSTN
Key points
Frame selection (FS) and
vocoding (VC) are performed at
both ends of the call
TDM is used for the bearer path
through the PSTN
Traditional bearer path: detail
Eliminate transcoding from the voice path
Key points
No transcoding is performed
anywhere in the voice path
Voice frames are transported in
packets through the IP network
Packet frame selection (PFS) is
performed at both ends of the
call
Key points
No transcoding is performed
anywhere in the voice path
performed at both ends of the
call
Transcoder-free operation (TrFO)
Definition
A mode of network operation for CDMA mobile-to-
mobile calls with the same or similar codecs on the
originating and terminating legs. In a TrFO call:
Note TrFO requires matched or similar codecs
No transcoding is performed on the voice stream
Voice frames are encapsulated in packets and
transported between switches over an IP network
Transcoder free operation: detail
When TrFO is not possible
Key points
performed at the switch
adjacent to the RAN (just as in
the TrFO case)
Circuit vocoding (CV) is
adjacent to the PSTN
Key points
adjacent to the RAN (just as in
the TrFO case)
Circuit vocoding (CV) is
adjacent to the PSTN
Remote transcoder operation (RTO)
Definition
A mode of network operation for mobile-to-land or
land-to-mobile voice calls, or mobile-to-mobile voice
calls that employ incompatible codecs. In a RTO call:
Transcoding is performed at one switch
When the call originates in or terminates to the PSTN,
transcoding is performed at the switch adjacent to
the PSTN
Voice frames are encapsulated in packets and
transported between switches over an IP network
Remote transcoder operation: detail
IP core network TrFO/RTO achitecture
ALU-PS hardware requirements for TrFO/RTO
PHV5, PHV6 Packet Handler for Voice
IP backhaul (IPBH) and frame relay
backhaul (FR BH) are both supported
Backhaul
NPH and PHV packs: PSU2e or iPS-2e
SIPPH and GQPH signaling packs:
PSU2, PSU2e, or iPS-2e
Packet Switching Unit
With a dedicated GSM, either a
SMP60MM or a CORE700
Switching Module Processor
CM3 (CM2 not supported) Communication Module
All SM in the office required to be
CORE700
Exception: Dedicated GSM (DGSM)
Switching Module
3B21B (AWS/VCDX not supported) Administrative Module
TrFO/RTO resource pools
TrFO and RTO calls use these resource pools at the
switch:
Packet frame selectors
Circuit vocoders
Packet vocoders
Network protocol handlers
Packet frame selectors
TrFO calls
Mobile end of RTO calls involving the PSTN
Non-transcoding end of mobile-to-mobile RTO
calls involving incompatible codecs
Used by
Performs traditional frame selection for all TrFO
calls and for the mobile end of RTO calls
Interfaces with circuit vocoders, packet
vocoders, and network protocol handlers
Function
PHV5 and PHV6 (Protocol Handler for Voice)
Hosted on pack
Packet frame selector Name
Circuit vocoders
Voice encoding and decoding for the PSTN
end of RTO calls, and for TrFO/RTO calls
that require access to circuit resources such
as announcements and tones
Require a time slot resource
Function
PHV5 and PHV6 (protocol handler for voice)
Hosted on pack
Circuit vocoder Name
Packet vocoders
Codec conversions for TrFO calls that require
vocoding but not circuit access
Example: EVRC G.711 conversions
Function
PHV5 and PHV6 (Protocol Handler for Voice)
Hosted on pack
Packet vocoder Name
Network protocol handlers
Packet switching units network interface
for IP bearer traffic
Function
Fast Ethernet (100BaseT Ethernet) Network connectivity
PSU2e or iPS-2e Complex
PHE3 with LLE2 electrical or LLE3 optical
paddleboard
Hardware
Network protocol handler Resource
Resource use by call scenario
2
TrFO/RTO resource pools
Scenarios
We will review resource use for four types of call
scenario:
Mobile originating calls
Mobile terminating calls
Voice mail redirection calls
Tandem calls
Resource use
Different vocoder and frame selection resources are
used for different call scenarios
Mobile origination call scenarios
MO EVRCTDM Not TrFO/RTO
Mobile origination EVRC TDM
MO EVRCEVRC Local call progress
EVRC EVRC
Mobile origination Local call progress enabled

MO EVRCEVRC Remote call progress
EVRC EVRC
Mobile origination Remote call progress enabled

MO EVRCG.711 Local call progress
EVRC G.711
Mobile origination Local call progress enabled

Mobile termination call scenarios
MT EVRCTDM Not TrFO/RTO
Mobile termination EVRC TDM
MT EVRCEVRC Local call progress
EVRC EVRC
Mobile termination Local call progress enabled

MT EVRCEVRC Remote call progress
EVRC EVRC
Mobile termination Remote call progress enabled

MT EVRCG.711 Remote call progress
EVRC G.711
Mobile termination Remote call progress enabled

Voice mail redirection call scenarios
MT TDMEVRC VMS Not TrFO/RTO
TDM EVRC
Mobile termination Redirect to voice mail

MT EVRC packet EVRC VMS Remote call progress
EVRC packet EVRC

Mobile termination Redirect to circuit voice mail
Remote call progress enabled
Tandem call scenarios
Tandem TDMTDM Not TrFO/RTO
Tandem (inter-MSC) TDM TDM
Tandem TDM[ EVRC | G.711 ]
Tandem (inter-MSC) TDM [ECRC | G.711]
Tandem [ EVRC | G.711 ] EVRC packet
[EVRC | G.711] EVRC packet

Tandem (inter-MSC) Mobile roams to a packet-enabled office

Call scenario summary (1 of 2)

G.711 packet EVRC
Call scenario

EVRC packet EVRC
TDM EVRC

EVRC EVRC packet

MT
MO
Type
Switch resources used
Progress?
TDM NPH PV CV
FS/VC
(SHT)
PFS BH RCP LCP
Codecs
EVRC G.711 packet
EVRC TDM

Call scenario summary (2 of 2)

Call scenario

EVRC packet EVRC
packet
TDM EVRC packet

EVRC packet
redirected to circuit
voice mail
TDM TDM
Tandem
inter-MSC
VM
redirect
Type
Switch resources used
Progress?
TDM NPH PV CV
FS/VC
(SHT)
PFS BH RCP LCP
Codecs
EVRC packet TDM
TDM redirected to a
voice mail system

SIP signaling for TrFO/RTO
3
TrFO and RTO signaling
Session Initiation Protocol
Session Initiation Protocol is used to coordinate call
setup and control for TrFO and RTO calls
SIP Protocol Handler (SIPPH)
The SIP Protocol Handler terminates SIP signaling in the
Switching Module (SM) of the Alcatel-Lucent Packet
Switch
General QLPS Protocol Handler (GQPH)
The General QLPS Packet Handler performs the
message transport function for inter-SM SIP signaling
transiting the quad-link packet switch
SIPPH overview
SIPT Channel group
Terminates SIP signaling in the Alcatel-Lucent
Packet Switch
Terminates SIP and UDP
Function
Minimum of two SIPPH per office
Require GQPH packs to be equipped
Configuration
One Fast Ethernet port (100BaseT Ethernet) Connectivity
PSU2e or PSU2e (SIP Global SM) Complex
Protocol Handler for Ethernet 2 (PHE2) with
LLE2 electrical or LLE3 optical paddleboard
Hardware
SIP Protocol Handler Resource
GQPH summary
GQPH Channel group
Switching Module (SM) interface to the QLPS
signaling network
Message transport between the SIPPH pool and
other Switching Module Processors throughout
the QLPS network
Function
Each active GQPH requireds 48 NCT2 time slots
(a 24-slot pipe to each side of the GQPH
Spare packs do not require time slots
Connectivity
Minimum of two active GQPH per office
Require SIPPH packs to be equipped
Minimum
configuration
PSU2 or PSU2e (SIP Global SM) Complex
Packet Handler 33 (PH33) Hardware
General QLPS Protocol Handler Resource
Review
Explain why transcoder-free operation (TrFO) for
mobile-to-mobile EVRC calls is not possible when the
originating and terminating switches are connected only
by a TDM mesh
Distinguish between TrFO and remote transcoder
operation (RTO)
Distinguish between circuit vocoders, packet vocoders,
and packet frame selectors
Identify the Alcatel-Lucent Packet Switch boards
required for TrFO/RTO and IPSHO, and describe the
function of each
Supplementary materials
~SUPPLEMENTAL MATERIALS
TrFO/RTO transport network
For detailed
information
about IP
transport in the
core network,
see the
TrFO/RTO
Transport
Network
customer
document
Flexent
Wireless Networks
TrFO/RTO Transport
Network
401-710-095
TrFO/RTO description
For more
information
about the
TrFO/RTO
feature, see this
optional feature
description
Flexent
/ AUTOPLEX
Wireless Networks
Transcoder Free Operation and
Remote Transcoder Operation
(TrFO/RTO)
Optional Feature Description
Release 28.0
Planning and Implementation Guide
401-710-093
Supplement A
EV-DO backhaul engineering
and capacity monitoring
All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 A:2
Objectives
Describe the phased introduction of backhaul
convergence for 1xEV-DO and 3G-1x CDMA
Describe 1xEV-DO backhaul and quality of service
enhancements for Release 28
Size 1xEV-DO DS1 backhaul facilities
Identify the new R28 quality of service (QoS)
measurements for backhaul capacity monitoring
1. Selected 1xEV-DO enhancements for Release 28
2. IP backhaul convergence
3. Engineer 1xEV-DO DS1 backhaul facilities
4. New Release 28 QoS measurements used to monitor
backhaul capacity
Sections in this session
Selected 1xEV-DO enhancements
for Release 28
1
Selected 1x EV-DO features for Release 28
Converged 1x EV-DO and 3G-1x CDMA backhaul with ML-PPP
1X EV-DO Rev A QoS infrastructure with MFPA and DoS
1x EV-DO RAN support for the push to talk application
Enhanced UATI session maximums at the 1x EV-DO RNC
R28 features
Converged 1xEV-DO and 3G-1x CDMA backhaul
Feature description Feature
1xEV-DO Backhaul with ML-PPP at Layer 2 over T1/E1
Introduces support for ML-PPP at the backhaul link
layer
ML-PPP replaces cHDLC as the 1xEV-DO backhaul layer
2 protocol
In R28 cHDLC will continue to be supported for
existing sites
Retrofit to Release 29 will require ML-PPP on the
backhaul
Use of ML-PPP makes possible a converged backhaul
network for 1x EV-DO and 3G-1x CDMA
12304.11
Prerequisite ML-PPP is a prerequisite for R28 Rev A quality of
service features and push to talk support features
R28 features
QoS infrastructure for Rev A
RAN QoS Enhancements for HRPD Rev A
Builds on 12184.9 with enhanced service
measurements
Adds support for SB-EVM processor overload control
Allows EV-DO RNC to modify the QoS of an application
flow
Application-based QoS Support for HRPD Rev A
Introduces a quality of service (QoS) infrastructure for
Rev A applications
Based on multi-flow packet application (MFPA)
Note: For MFPA, see IS-856-A-1
Provides multiple radio link protocol (RLP) flows with
different bandwidth, delay, and jitter requirements
12078.9
12078.10
R28 features
Support for the push to talk application
Enhanced Idle State Protocol
Support for enhanced idle state protocol
Reduces paging delays
Conserves mobile battery power
1xEV-DO Rev A: Data over Signaling Protocol
Ability to transmit data over the access channel in the
reverse link
Uses the data over signaling (DoS) protocol
Supports the Rev A application push to talk
12078.12
12078.13
R28 features
Support for the push to talk application
HRPD Push To Talk Paging Enhancements
Introduces paging enhancements for push to talk
scenarios
Enables priority paging for specified user profiles
Enables paging across multiple RNC service areas
Lowers call setup delays for push to talk sessions
1xEV-DO Basic Push To Talk using Rev A Networks
Introduces radio area network support for the push to
talk applications
Builds on MFPA (10278.9) and DoS over the access
channel in the reverse link (10278.12)
12184.1
12184.5
R28 features
Enhanced UATI session maximums at the RNC
Increasing the Number of UATI Sessions per OHM
Increases the maximum number of unicast access
terminal identifiers (UATI) supported by the RNC
overhead manager (OHM) from to 65,000 to 100,000
Maximum R-P session levels are unaffected by this
feature, but higher UATI levels reduce the chance that
1x EV-DO terminals will have to contend with hybrid
terminals for UATI sessions
9053.3
IP backhaul convergence
2
1xEV-DO and 3G-1x CDMA backhaul
Separate backhaul networks
From the introduction of 1xEV-DO, the data
optimized service has employed a different backhaul
network than 3G-1x CDMA
Backhaul convergence
Beginning with Release 27, the two backhaul
networks are being converged
A converged backhaul simplifies configuration and
administration; allows for common QoS tuning; and
enables more efficient use of physical resources
Backhaul convergence roadmap
Router convergence
Support for common aggregation devices, edge routers,
and office switches
Separate VLANs for 1xEV-DO and 3G-1x CDMA
R 27
Link layer protocol convergence
1xEV-DO support for ML-PPP as link layer protocol
R 28
Description Release
DS1 convergence
Support for shared T1 and E1 facilities
Separate aggregation devices for 1xEV-DO & 3G-1x CDMA
Separate edge routers for 1xEV-DO & 3G-1x CDMA
Separate office switches for 1xEV-DO & 3G-1x CDMA
Link layer protocol is cHDLC for 1xEV-DO and ML-PPP for
3G-1x CDMA
R 26
R 29
R26 backhaul architecture
New for R26 Support for OC-12 facilities between the DS1 multiplexer
and the aggregation and edge routers
New for R27 Converged on IPBH routers and office-side switches
(1xEV-DO and 3G-1x CDMA still VLAN segregated in BH transport network)
New for R28 ML-PPP a supported link layer protocol for 1xEV-DO
New for R29 Multi-link groups can be shared by 1xEV-DO and 3G-1x CDMA
radio controllers. In addition, at lightly loaded sites a single DS1 may be
shared across technologies (not shown).
Engineer 1xEV-DO DS1 backhaul
facilities
3
Task: Size EV-DO backhaul facilities for a cell
Two methods for sizing EV-DO backhaul facilities
Sizing EV-DO backhaul facilities
There are two methods for sizing EV-DO backhaul
facilities:
Size DS1 facilities to handle a desired percentage of
full air interface capacity
Size DS1 facilities to handle estimated average
carrier throughput
Method 1: full air interface capacity
Advantage
Superior performance under relatively high load
levels
Disadvantages
More DS1 facilities are required
DS1 utilization is less efficient
Limiting factor On this method, the cell is capacity limited
by the air interface capacity
Method 2: estimated average carrier throughput
Advantages
Fewer DS1 facilities are required
DS1 utilization is more efficient
Disadvantage
Less available bandwidth can degrade performance
Limiting factor On this method, the cell is capacity limited
by the backhaul bandwidth
Size DS1 facilities using full air interface
capacity
Task 1.a
Size BH DS1 based on total air interface capacity
Steps
1. Multiply total air interface capacity by the desired
loading percentage
Example with 90% loading: Total_capacity * 0.90
2. Divide the Step 1 result by the DS1 reference
capacity to determine the number of facilities
required
E1 reference: ~2.048 Mbps
Size DS1 facilities using estimated
average carrier throughput
Task 1.b
Size BH DS1 based on average carrier throughput
Steps
1. Determine the estimated average carrier
throughput for the cell
2. Determine the cell configuration
Antenna: Single Rx or Dual Rx
EV-DO revision: Rel 0 or Rev A
3. Look up the corresponding DS1 configuration in
the E1 capacity table
E1 capacity table : single carrier cell
Supported carrier loading for E1 BH configurations
Site configuration and carrier loading
Dual Rx antenna Single Rx antenna
No. of
backhaul
facilities
Rev A Rel 0 Rev A Rel 0
Rate (kbps)
E1 x1
460 460 450 450
Carrier loading as a percentage of full air interface capacity
35% 45% 50% 60%
Rate (kbps)
E1 x2
900 850 750 700
95% 90% 85% 75%
. . . continued on next page
E1 capacity table : single carrier cell (continued)
Supported carrier loading for E1 BH configurations
Site configuration and carrier loading
Dual Rx antenna Single Rx antenna
No. of
backhaul
facilities
Rev A Rel 0 Rev A Rel 0
Rate (kbps)
E1 x3
1200 1000 850 750
100% 100% 100% 100%
Rate (kbps)
E1 x4
1200 1000 850 750
100% 100% 100% 100%
New Release 28 QoS
measurements used to monitor
backhaul capacity
4
Basic concepts for 1xEV-DO Rev A quality
of service
Concepts
Quality of service for Rev A
Quality of service (QoS)
In a communications system, the rate and reliability
of an information stream
Services and users can be assigned different levels
of QoS
Multi-flow packet application (MFPA)
Multi-flow packet application is the Rev A standard
(IS-856-A-1) for providing differential QoS to Rev A
users and subscribers
Concepts
MFPA concepts (1 of 2)
A sequence of packets transmitted between the access
terminal (AT) and access network (AN) in support of one
or more applications
IP flow
A value that identifies a predefined set (TSB-58-G) of QoS
characteristics (delay, bandwidth, jitter) for an IP flow
Profile ID
A unidirectional radio link protocol instance between
the AT and the AN
Each RLP flow supports one or more IP flows
RLP flow
Concepts
MFPA concepts (1 of 2)
A reservation identifier assigned by the AT
A FL reservation and its corresponding RL reservation can
share the same reservation label
Reservation
label
An IP flow that has been negotiated by the AT and AN
Every reservation is associated with a profile ID that
determines the IP flow QoS
Reservations can be open or closed
Packets can be exchanged only when the reservation
state is open
Reservation
One or more reservation labels negotiated between the AT
and the AN
Reservation on
request (RoR)
Monitor the system
Reservation on request admission rates and reservation drop rates for
Rev A services are a measure of system accessibility and retainability,
respectively
New 1xEV-DO backhaul service
measurements
New BH capacity monitoring measurements
Measurement sets
Reservations dropped due to backhaul overload
Reservation on request admission failures due to
unavailability of backhaul resources
Backhaul RLP frame loss rates (packet loss rates)
Backhaul counters for applications
With the advent of the Rev A QoS infrastructure, it is
possible to maintain backhaul measurements for these
Rev A applications:
Conversational speech
Conversational video
Push to talk
1xEV-DO service measurements
See this document
for further
information about
1xEV-DO service
measurements
described in this
session
CDMA2000
1xEV-DO
Releases 24 and later
Reference
401-614-326
Note The document
contains
descriptions of all
new service
measurements
for R28
Summary table Service measurement counters
Dropped reservations due to BH overload
Backhaul
overload
Cause
Conv. Video
Sector &
Carrier
(SN-HCS-ANT-CARR)
Reverse
Conv. PTT
Reservations
dropped
Measured
Forward
Conv. Speech
Conv. Video
Link Granularity
Conv. PTT
Conv. Speech
Application
What they tell you Positive values for these counters may indicate a need
for additional backhaul bandwidth
Admission failures due to lack of BH resources
Backhaul
overload
Cause
Conv. Video
Sector &
carrier
(SN-HCS-ANT-CARR)
Reverse
Conv. PTT
Reservation
admission
failures
Measured
Forward
Conv. Speech
Conv. Video
Link Granularity
Conv. PTT
Conv. Speech
Application
What they tell you Positive values for these counters may indicate a need
for additional backhaul bandwidth
RLP frame loss rates on the backhaul
Conv. Video
Controller
(SN-HCS-CTID)
Reverse
Conv. PTT
RLP frame loss rate
calculated as a
percentage over the
reporting period
Measured
Forward
Conv. Speech
Conv. Video
Link Granularity
Conv. PTT
Conv. Speech
Application
100
lost _ frames _ BH received _ frames _ BH
lost _ frames _ BH
+
Summary table Service measurements
Overload rates on the backhaul
Seconds
(summed over an
hour)
Cumulative
counter
Unit
Reverse
Forward
Reverse
Forward
Link
Overload
duration
Controller
(SN-HCS-CTID)
Overload
condition
1xEV-DO
Backhaul
Measured Granularity System
Notes
The Backhaul is considered to be in overload when a single DSCP
marking is in overload
When the BH is in overload, and another DSCP goes into overload, this
counter is not pegged
Release 28 also introduces overload occurrence and duration counters
for the backhaul:
Review
Describe the phased introduction of backhaul
convergence for 1xEV-DO and 3G-1x CDMA
Describe 1xEV-DO backhaul and quality of service
enhancements for Release 28
Size 1xEV-DO DS1 backhaul facilities
Identify the new R28 quality of service (QoS)
measurements for backhaul capacity monitoring
Supplemental materials
1xEV-DO RNC functions and components
Application processor
(AP)
Out-of-band signaling
1xEV-DO base station
controller
Traffic processor (TP) Bearer traffic Packet control function
Traffic stream RNC component Function
Capacity notes
Application processors (AP) are equipped in pairs
(active/active)
The R1SR RNC frame accepts up to 8 AP pairs
Two Traffic processors (TP) are equipped for each AP
Supported TP models are TP690 and TP752i
Minimum configuration is 2 AP and 4 TP
Maximum configuration is 8 AP and 16 TP
RNC capacity table
RNC capacity: 752i model traffic processor
12k-16k 9k-12k 6k-8k 3k-4k Active connections
30k-80k
200,000
130,000
80,000
55-80 Mbps
34
2 AP 4 TP
Capacity by RNC configuration
60k-160k
400,000
260,000
160,000
110-160 Mbps
100
4 AP 8 TP
90k-240k
600,000
390,000
240,000
165-240 Mbps
180
6 AP 12 TP
System atttribute
8 AP 16 TP
260
1x EV-DO 3-sector
carriers
220-320 Mbps
Total throughput (FL
and RL)
320,000
Maximum UATI
sessions: 1 GB AP
520,000
Maximum UATI
sessions: 2 GB AP (FID
9053.2)
800,000
Maximum UATI
9053.3)
120k-320k Total R-P sessions
RNC capacity table
RNC capacity: 690 model traffic processor
7.2k-16k 5.4k-12k 3.6k-8k 1.8k-4k Active connections
18k-80k
200,000
130,000
80,000
55-80 Mbps
34
2 AP 4 TP
Capacity by RNC configuration
36k-160k
400,000
260,000
160,000
110-160 Mbps
100
4 AP 8 TP
54k-240k
600,000
390,000
240,000
165-240 Mbps
180
6 AP 12 TP
System atttribute
8 AP 16 TP
260
1x EV-DO 3-sector
carriers
220-320 Mbps
Total throughput (FL
and RL)
320,000
Maximum UATI
sessions: 1 GB AP
520,000
Maximum UATI
9053.2)
800,000
Maximum UATI
9053.3)
72k-320k Total R-P sessions

Ipbh CL

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ipbh CL

Încărcat de

Drepturi de autor:

Formate disponibile

IP Backhaul for CDMA Voice and Packet Data

IPBH Intoduction (3G1x and 1xEVDO)

Wireless Networks IP Backhaul for CDMA Voice and

wireless 3G1X Voice and Data and 1xEVDO networks.

Wireless Networks IP Backhaul Transport Network:

Executive Cellular Processor (ECP)

The total bandwidth of the DS1:

Executive Cellular Processor (ECP)

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:26

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:27

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:28

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:31

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:32

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:33

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:35

EVRC packet EVRC

[EVRC | G.711] EVRC packet

All Rights Reserved Alcatel-Lucent 2007 CL1301 September 2007 4:40

S-ar putea să vă placă și