411 2133 525 06 12

411-2133-525
CDMA
Operational Measurements Reference System Performance Metrics

NBSS15.0 Standard 06.12 April 2008
Whats inside...
CDMA OM design overview Call setup performance 1xRTT packet data performance RLP throughput performance Access robustness package performance Dropped call performance Handoff performance Intelligent voice service negotiations performance BTS performance Paging performance Border paging performance Data burst message delivery performance Location services performance MCTA performance Authentication performance Call resource allocation and management RF performance
Whats inside...
CDMA-LTX performance OTAPA performance Call flow diagrams with OMs MSC OM descriptions BSC OM descriptions BTS OM descriptions
CDMA
Operational Measurements Reference System Performance Metrics

Document number: 411-2133-525 Product release: NBSS15.0 Document version: Standard 06.12 Date: April 2008
Copyright Country of printing Confidentiality Legal statements Trademarks
Copyright 2008 Nortel Networks All Rights Reserved. Originated in the United States of America
This document is protected by copyright laws and international treaties. All information, copyrights and any other intellectual property rights contained in this document are the property of Nortel Networks. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein and this document shall not be published, copied, produced or reproduced, modified, translated, compiled, distributed, displayed or transmitted, in whole or part, in any form or media. Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant. * Nortel Networks, the Nortel Networks logo, the Globemark, and Unified Networks are trademarks of Nortel Networks.
iv Nortel Networks
Copyright 2008 Nortel Networks
411-2133-525
Standard
06.12
April 2008
Nortel Networks
v Copyright 2008 Nortel Networks
Contents
About this document
Purpose 3-xvii Audience 3-xviii Scope of document 3-xviii Organization 3-xviii Related documents 3-xix Indication of hypertext links 3-xx
1
3-xvii
New in this release

Features 4-xxi Other changes 4-xxi
4-xxi
CDMA OM design overview

OM philosophy 1-1 MTX OM philosophy 1-1 CDMA access system OM philosophy 1-2 MTX OM consolidation 1-4 CDMA access system OM consolidation 1-5 OM metrics overview 1-8 OM validation overview 1-9
1-1
Call setup performance
2-1
List of OMs 2-1 Call setup failure before resources are allocated (blocked calls) 2-9 Goal 2-10 Formula usage 2-10 Total calls attempted 2-12 Call types 2-13 Overall call setup failures (call blocking rate) 2-14 Call setup failures (blocks) due to lack of EBSC/BSC resources 2-14 Call setup failures due to BSC/EBSC processing errors 2-15 Call setup failures (blocks) due to BTS physical resources 2-16 Call setup failures (blocks) due to BTS time-outs 2-16 3G packet data call setup failures (blocks) 2-17 Screened calls 2-17 Screened calls for 3G packet data calls due to mobile service inactive indication
CDMA
System Performance System Performance Metrics
NBSS15.0
vi Contents Nortel Networks
Copyright 2008 Nortel Networks during network initiated dormant to active transition 2-18 Call setup failures due to RF failures 2-18 Goal 2-19 Formulas 2-19 Voice call failures during setup due to non-RF resource failures 2-20 Formulas 2-21 Miscellaneous packet data call failures 2-21 Additional formulas 2-22 Voice call setup performance metrics on a per platform basis- (EBSC and BSC) 2-22 MEID related metrics 2-23 VPAD (voice preemption of active data) voice call setup performance - system level 2-25 Global emergency call metrics 2-26 Silent retry 2-27 3G packet data 2-27 Closed R-P metrics 2-28 OpenRP Metrics 2-30 Validation 2-32 For all call types together or 2G-only systems 2-32 Silent retry OMs validation 2-33 Blocking OMs validation 2-33 Validation for voice call setup performance OMs (per platform basis) 2-34 Validation for MEID OMs 2-35 Validation for 3G packet data OMs 2-35 Validation of VPAD OMs 2-35 Additional validation of HHO OMs 2-35 Validation of close RP OMs 2-36 Validation of open RP OMs 2-36 Validation for PCU manager OMs 2-36 Recommendations 2-37
1xRTT packet data performance

List of OMs 3-1 Goals 3-8 Formulas 3-8 SCH burst setup 3-8 SCH radio link setup 3-26 Additional information 3-41 Validation 3-43 Validation of forward burst setup OMs 3-44 Validation of reverse burst setup OMs 3-46 Validation of F-SCH primary link setup OMs Validation of F-SCH handoff link setup OMs 3-48 Validation of R-SCH primary link setup OMs Validation of R-SCH handoff link setup OMs Validation of SCHDrop OMs 3-49
3-1
3-47 3-47 3-48 3-49
RLP throughput performance

411-2133-525 Standard 06.12 April 2008
4-1
Nortel Networks
Contents vii Copyright 2008 Nortel Networks List of OMs 4-1 RLP throughput performance metrics 4-2 Aggregate sector throughput (per EBID basis) 4-3 Per channel aggregate sector throughput (per EBID basis) 4-4 Per channel contribution to the overall aggregate sector throughput (per EBID basis) 4-6 Average mobile user throughput (per cluster/system basis for all given carriers) 4-8 Per channel throughput (per EBID basis) 4-10 Per channel utilization (per EBID basis) 4-13 Per channel data-retransmission percentage (per EBID basis) 4-15 Average physical layer data rate while bursting 4-17 Maximum bearer data throughput 4-17 Supporting metrics for 3G data throughput performance 4-18 Validation formulas 4-19
Access robustness package performance

Goal 5-1 List of OMs 5-1 CDMA access robustness package performance CASHO failures per sector 5-2 CASHO releases per sector 5-2 ACCHO failures per sector 5-2 ACCHO releases per sector 5-2 Validation 5-2 Validation of CASHO OMs 5-2 Validation of ACCHO OMs 5-2 5-2
5-1
Dropped call performance

Goals for dropped call performance 6-2 List of OMs 6-2 Overall dropped call rate 6-2 RF related dropped call rate 6-3 Network related dropped call rate 6-3 Additional formulas 6-3 Recommendations 6-4
6-1
Handoff performance
List of OMs 7-2 Soft and softer handoff performance 7-3 Goal 7-4 Formula 7-4 Recommendations 7-4 Sector based hard handoff performance 7-5 Goal 7-5 Formula 7-5 Validation 7-7 Route based hard handoff performance 7-8 Goal 7-8 Formulas 7-8
7-1
CDMA
NBSS15.0
viii Contents Nortel Networks Validation 7-8 Trigger type based hard handoff performance Goal 7-9 Formulas 7-9 Validation 7-13 Recommendation 7-14
7-8
Intelligent voice service negotiations performance

Goal 8-2 List of OMs 8-2 Formulas 8-3 Service redirection performance 8-3 Successful call setup based on mobile requested service option Validation 8-8 Recommendations 8-8 Query performance 8-10
8-1
8-6
BTS performance
9-1
List of OMs 9-1 Resource blocking and voice call downgrades 9-8 Origination and termination blocking 9-9 Soft handoff blocking 9-10 3G to 2G voice calls downgrade rate 9-11 Handoff sectors/beams per user 9-11 FSCH queuing 9-14 SCH link data rate downgrades 9-17 Percentage of SCH data rate downgrades per EBID 9-17 Distribution of SCH downgrades by specific downgrade reason 9-18 Distribution of SCH downgrades by specific FSCH downgrade scenario 9-19 Walsh code usage distribution 9-20 Lower bound of average number of walsh codes in simultaneous use 9-21 Upper bound of average number of walsh codes in simultaneous use 9-22 Physical resource utilization metrics 9-22 Peak percentage of physical resources used for 2G FCH 9-22 Peak percentage of physical resources used for 3G FCH 9-22 Peak percentage of forward physical resources used for SCH 9-22 Peak percentage of reverse physical resources used for SCH 9-22 Peak percentage of forward physical resources used 9-22 Peak percentage of reverse physical resources used 9-22 Peak percentage of voice resources used on the forward FCH 9-23 Peak percentage of data resources used on the forward FCH 9-23 Forward transmit power utilization 9-23 Lower bound of average occupancy range 9-24 Upper bound of average occupancy range 9-24 Percentage of time forward transmit power is in an occupancy range 9-24 Forward common channel utilization 9-24 Paging channel utilization 9-24 Forward common control channel utilization 9-25 Reverse common channel utilization 9-26 Access channel utilization 9-26
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Contents ix Copyright 2008 Nortel Networks Enhanced access channel utilization 9-27 Reverse common channel message received by type 9-28 Access channel message received by type 9-28 Enhanced access channel metrics 9-31 Forward common channel message drop rate 9-31 Paging channel message drop rate 9-31 FCCCH channel message drop rate 9-32 Forward common channel messages sent by type 9-33 Paging channel messages sent by type 9-33 FCCCH channel messages sent by type 9-34 MFRM-3 9-34 Metro Cell validation formulas 9-36
Paging performance
10-1
Goal 10-1 List of OMs 10-2 10-5 CDMA call delivery performance metrics 10-5 Overall call delivery performance of a system without BCP activated 10-5 Time distribution of page responses 10-8 Delayed page response rate 10-8 Overall call delivery performance of an anchor system with BCP activated 10-9 CDMA intersystem paging performance metrics 10-11 Overall intersystem paging performance of an anchor system (all border routes of all anchor sectors) 10-12 Intersystem paging performance of an anchor sector (all border routes of the anchor sector) 10-13 Intersystem paging performance of a border route (of an anchor sector) 10-14 CDMA IZP zone performance metrics 10-15 Zone performance for voice, CSD, and packet data calls 10-16 Delayed page response rate 10-19 Zone performance for SMS calls 10-20 Zone performance for MWI 10-22 10-24 MWI delivery performance 10-24 Voice preemption of active data feature paging performance 10-28 Overall paging failures for VPAD feature 10-28 Overall paging successes for VPAD feature 10-28 AMPS formulas 10-28 AMPS repaging formula 10-28 Validation 10-29 CDMA call delivery performance OM validations 10-29 CDMA intersystem paging performance OM validations 10-29 CDMA zone performance OM validations (for a single zone) 10-30 VPAD OMs 10-31 MWI OMs 10-32 Recommendations 10-32 CDMA paging 10-32 Zone paging 10-32
CDMA
NBSS15.0
x Contents Nortel Networks
Border paging performance

Goal 11-1 List of OMs 11-1 11-3 CDMA intersystem paging performance metrics 11-3 Overall intersystem paging performance of a border system (all anchor routes) 11-4 Intersystem paging performance of an anchor route 11-5 CDMA BCP zone performance metrics 11-6 Zone performance for voice, CSD, and packet data calls 11-6 Zone performance for SMS calls 11-10 Success rate of SMS delivery in the border system 11-10 11-10 Validation 11-10 CDMA border cell paging performance OM validations 11-10 CDMA zone performance OM validations (for a single BCP zone) 11-11 SMS Delivery 11-12 11-12 Recommendations 11-12 CDMA paging 11-12
11-1
Data burst message delivery performance
12-1
List of OMs 12-2 Idle mode SMS 12-4 Goal 12-5 Formula 12-5 Validation 12-8 In call SMS 12-9 Goal 12-9 Formula 12-9 Validation 12-10 CAU-CM SMS origination delivery 12-10 Goal 12-10 Formula 12-10 Validation 12-10 Message length histogram metrics 12-10 Formula 12-10 Distribution of DDS messages across channels 12-11 Distribution of DDS messages according to size on a per channel basis 12-12 Upper bound of the average message length on per channel basis 12-13 Mobile-initiated R-SDB 12-13 R-SDB size histogram metrics 12-13 Mobile-initiated SDB delivery success rate at the PCU-M 12-15 Mobile-initiated SDB delivery success rate at the PCU 12-15 Percentage of R-SDBs received on the R-EACH 12-16 Validation 12-16
Location services performance

Goal 13-1
13-1
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of OMs 13-1 LCS paging performance 13-2 LCS call setup performance 13-3 Miscellaneous information 13-4 Recommendations 13-5 Notes 13-5
Contents xi Copyright 2008 Nortel Networks
MCTA performance
List of OMs 14-1 MCTA call setup failures 14-3 Goal 14-4 Formula 14-4 Total number of call setups attempted 14-4 Call types 14-5 MCTA frequency selection failures 14-6 MCTA resource allocation failures before CDA is executed 14-6 Reason codes for MCTA frequency resource allocation failures 14-7 MCTA call setup failures 14-8 14-9 Non MCTA frequency resource allocation failures (per frequency) 14-9 Retain loading related metrics 14-9 Paging channel redirection related metrics 14-10 MCTA RF access failure (per frequency) 14-10 MCTA RF related dropped call rate (per frequency) 14-12 Validation 14-12 Originations, terminations, and handoffs 14-12 Miscellaneous 14-12 Recommendations 14-13
14-1
Authentication performance
Authentication air-interface performance Goal 15-2 List of OMs 15-2 Formulas 15-2 Validation 15-3 Recommendations 15-4 15-1
15-1
Call resource allocation and management

List of OMs 16-1 16-9 BSC/EBSC resource management 16-9 RMU resource management 16-9 RMU resource allocation performance 16-11 Resource utilization metrics 16-13 NRM resource allocation performance 16-18 SBSRM resource allocation performance 16-26 PCU change rate for dormant to active requests 16-27 PCU allocation performance for dormant handoff requests Resource allocation metrics during CNFP overload 16-31 16-32
16-1
16-29
CDMA
NBSS15.0
xii Contents Nortel Networks
Copyright 2008 Nortel Networks Effects of CSRM / SBSRM overload on platform selection mechanism 16-32 Resource allocation failures at CSRM and SBSRM (due to overload condition) 16-33 Resource allocation performance for connection type 16-34 Resource allocation failures for a connection type (due to lack of resources) 1634 Resource allocation failures for a connection type (due to processing errors) 1634 Resource availability rate for a connection type 16-35 Additional formula 16-35 Resource unavailability rate for a connection type 16-35 Resource re-direction rate 16-36 Distribution rate of resource allocation per connection type 16-37 Resource allocation failure rate per connection type 16-37 Distribution ratio for TrFO Vs. NonTrFO calls at TrFO capable PVG cards 16-37 Distribution ratio for EVRC Vs. Non-EVRC calls at non-TrFO PVG cards 16-38 EVRC-B related Metrics 16-38 EVRC-B Mode distribution Metrics (event based) 16-39 EVRC-B Mode distribution Metrics (time-based) 16-40 Primary sector capacity metrics 16-40 Approximate carried load per BSC for non-packet data 16-41 Approximate carried load per BSC for packet data 16-41 Approximate carried load per sector 16-42 Approximate carried load per carrier-sector 16-42 Load contribution per service option on BSC 16-43 Eighth rate gating formulas 16-44 Gating request rates 16-44 Gating request granted rate 16-45 Gating request denied rate 16-45 Gating-enabled handoff percentage 16-46 Gating deactivation rate 16-46 Gating usage 16-47 Validation 16-47 Service option validation formulas 16-47 Resource utilization validation formula 16-48 16-48 Resource allocation validation formula 16-48 NRM resource allocation validation formula 16-49 SBSRM resource allocation validation formula 16-50 CSRM resource allocation validation formula 16-50 16-50 Dormant-to-active - PCU change validation formula 16-50 Dormant handoff - PCU allocation validation formula 16-51 Resource allocation for connection types validation formula 16-51 Eighth rate gating validation formula 16-53
RF performance
List of OMs 17-1 Reference sector FER metrics FCH formula 17-2 17-2
17-1
411-2133-525
Standard
06.12
April 2008
Nortel Networks SCH formula 17-4 Recommendations 17-5
Contents xiii Copyright 2008 Nortel Networks
CDMA-LTX performance
Pegging methods 18-1 List of OMs 18-2 Call setup performance 18-4 Call setup failure before resources are allocated Goal 18-4 Formula 18-5 Validation 18-9 Recommendations 18-11 Access failures 18-13 Dropped call performance 18-13 Goal 18-14 Formula 18-14 Validation 18-15 Recommendations 18-15 Paging performance 18-15 Goal 18-15 Formula 18-15 Limitations 18-17 MCTA performance 18-17 Goal 18-17 Formula 18-17 V5.2 protocol adaptor performance 18-24 Circuit switched data performance 18-25 Goal 18-25 Formula 18-25
18-1
18-4
OTAPA performance
Goal 19-1 List of OMs 19-1 Formulas 19-2 Validation 19-2
19-1
Call flow diagrams with OMs

2G/3G voice call setup flow diagram with OMs 20-2 Voice call setup flow diagram with OMs- CSVS and SBS subsystems 20-9 Call setup flow diagram using BAM channels 20-16 MEID- Registration, origination/termination call flow with OMs 20-19 2G/3G voice/data soft handoff (intra-BSC) flow diagram with OMs 20-30 Hard handoff flow diagram with OMs 20-33 Hard handoff (intra-MSC) 20-34 Access robustness package: call flow with OM register pegs 20-35 IVSN flow diagram with OMs 20-37 Intelligent zone paging flow diagram with OMs 20-45 SMS termination over paging channel 20-45 SMS termination over traffic channel 20-47 In-call SMS termination 20-48
20-1
CDMA
NBSS15.0
xiv Contents Nortel Networks
Copyright 2008 Nortel Networks SMS origination over access channel 20-49 SMS origination over traffic channel 20-50 In-call SMS origination 20-51 VPAD call flow 20-52 VPAD call flow with OM pegs 20-53 Border cell paging and call setup 20-54 Successful paging and call setup in border system 20-54 Successful paging for SMS and SMS delivery in border system Inter-system hard handoff 20-60 Target system 20-60
20-56
MSC OM descriptions
MSC operational measurements 21-1
21-1 22-1
BSC OM descriptions
BSC operational measurements 22-1 CDMA-LTX operational measurements 22-167
BTS OM descriptions
Metro Cell BTS operational measurements 23-2
23-1
411-2133-525
Standard
06.12
April 2008
Nortel Networks Table 13-1
Front xv Copyright 2008 Nortel Networks
Location services performance OMs Table 14-1 MCTA performance OMs Table 22-1 Table 22-2 Table 22-3 14-1
13-1
List of BSC OMsSCH burst setup OM group 22-5 List of BSC OMsPlatform Selection OM group 22-121 List of BSC OMsDHO call resource request processing OM group 22-135 List of BSC OMs OM group 22-150
Table 22-4
CDMA
NBSS15.0
xvi Front Nortel Networks
411-2133-525
Standard
06.12
April 2008
Nortel Networks
xvii Copyright 2008 Nortel Networks
About this document

Purpose
1
1
This document is written to assist the service provider in determining and tracking the performance of the Nortel CDMA System. Various formulas are provided for ascertaining system performance. In some cases the document also provides recommendations on the course of action to take. Some performance measurements are kept simply for establishing norms for system performance so that the service provider may monitor changes in operation (for instance, resource utilization, and call traffic patterns) that are dependent on the number of subscribers/users of the system, rather than a parameter directly under the control of the system. It is also important to note that the performance metrics listed in this document should be evaluated over several OM reporting cycles. This is due to the fact that the number of established calls may fluctuate over time. The same fluctuation could be seen in various other OM registers that track several call-related events. These fluctuations would cause the metrics to vary significantly from one reporting period to the other. The focus of this document is to provide its customers with a high level understanding of the CDMA related OMs available and how to measure the various types of system performance with those OMs. Note: The performance measurements presented in this document are meant to track the CDMA system performance rather than specific call models. The example performance metric goals listed in this document are high level objectives for the service provider and depend on the planned RF/Network requirements. If required, similar metric goals can be created for other metrics listed in this document. Also, the listed metric goals can be changed from system to system. In general, the metrics listed in this document should be monitored against the metric goals, and if the success rate goes down (or the failure rate goes up), further investigation is usually required and should be done.
CDMA
NBSS15.0
xviii About this document Nortel Networks
Audience
1
The audience for this document is Nortel designers, testers, Nortel customers, field support and VO, system engineering groups, and RF engineering. It assumes the reader has a good understanding of the DMS-MTX CDMA software and hardware architecture and CDMA RF technology.
Scope of document
This document covers Operational Measurements related to CDMA System Performance. The CDMA Operational Measurements (OMs) are comprised of OMs from the DMS-MTX and the CDMA Access Subsystems (which includes BSC and/or EBSC and BTSs). This document does not cover BSC/ EBSC and BTS non-application OMs such as for ACN/BCN Transport and Overload Characterization. This document is written within the context of the Nortel CDMA NBSS System. Hence, we refer to OMs that peg for NOIS only (with the exception of some CM OMs that peg for IOS). This document is not intended to correct or document existing performance measurements that are not being added by or are not of primary concern to the CDMA system.This document is not intended to provide the procedures necessary for collecting the MSC, BSC or BTS OM data. Please refer to NTP NN20000-104 and NTP # 411-2131-814 for OM collection procedures. Open A is not discussed in this document. MDM OMs are not discussed in this document. Refer to NTP # 241-6001-031 Preside Multiservice Data Manager Performance Management User Guide.
Organization
The document is organized by performance area. Chapter 2 through Chapter 18 describe the CDMA specific product metrics. Each of these chapters specifies a few example metric goals, list of applicable operational measurements (OMs) used to calculate the metric, formulas for calculating the metric, and a section that recommends changes to the configurable parameters of the MTX-CDMA system or other potential actions to address identified performance issues. For a better understanding and interpretation of the metrics provided in this NTP; it is essential to refer to the explanation of the operational measurements (OMs) provided in the OM Descriptions chapters (Chapters 21, 22 and 23). The following is a list of chapters and performance areas that are discussed in this document: Chapter 1, CDMA OM design overview Chapter 2, Call setup performance
411-2133-525
Standard
06.12
April 2008
Nortel Networks
About this document xix Copyright 2008 Nortel Networks
Chapter 3, 1xRTT packet data performance Chapter 4, RLP throughput performance Chapter 5, Access robustness package performance Chapter 6, Dropped call performance Chapter 7, Handoff performance Chapter 8, Intelligent voice service negotiations performance Chapter 9, BTS performance Chapter 10, Paging performance Chapter 11, Border paging performance Chapter 12, Data burst message delivery performance Chapter 13, Location services performance Chapter 14, MCTA performance Chapter 15, Authentication performance Chapter 16, Call resource allocation and management Chapter 17, RF performance Chapter 18, CDMA-LTX performance Chapter 20, Call flow diagrams with OMs- provides call setup and handoff scenario flow charts with key OMs from related OM group for the majority of the OMs discussed in this document. Chapter 21, MSC OM descriptions- contains a list of all the MSC OMs referenced in this document organized by OM group. Chapter 22, BSC OM descriptions- contains a list of all the BSC OMs referenced in this document organized by OM group. Chapter 23, BTS OM descriptions- contains a list of all the BTS OMs referenced in this document organized by MO.
Related documents
NTP # 411-2133-526: Nortel CDMA Performance Management -Operational Guidelines. Please refer to the System Parameters section for all the Parameters mentioned in this Guide. NTP # 411-2131-814: DMS-MTX Operational Measurements Reference Manual NTP # 241-6001-031: Preside Multiservice Data Manager Performance Management User Guide NTP # 411-2133-802: Packet Data Serving Node Customer Information Guide.
CDMA
NBSS15.0
xx About this document Nortel Networks
NTP # NN20000-104: Nortel CDMA BSS Manager Fault Management -Log Report Generation. NTP # NN20000-144: Nortel CDMA C-EMS Fault Management. This document contains procedures for handling OMs in the C-EMS and a detailed description of OM Parser and OM Log Filter.
Indication of hypertext links

Hypertext links in this document are indicated in blue. If viewing a PDF version of this document, click on the blue text to jump to the associated section or page.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
1-xxi Copyright 2008 Nortel Networks
New in this release
The following sections detail whats new in Nortel CDMA Operational Measurements Reference -- System Performance Metrics (NTP 411-2133525) for NBSS 15.0 / MTX15. Features on page 1-xxi Other changes on page 1-xxi
Features
This document contains no feature update for this release.
Other changes
See the following section for information about changes that are not feature related:
Updated the section Network-initiated dormant-to-active transition failure rate (page -27) Updated the table Call setup performance OMs (page -2) Updated the table MSC operational measurements (page -1)
CDMA
NBSS15.0
1-xxii New in this release Nortel Networks
411-2133-525
Standard
06.12
April 2008
Nortel Networks
1-1 Copyright 2008 Nortel Networks
CDMA OM design overview

OM philosophy
1
1
The CDMA operational measurements (OMs) consist of OMs from the DMSMTX (digital multiplexing switch - mobile telephone exchange) system, including the CAU, CM and other subsystems, and the CDMA access system, including the BSC, EBSC, and BTS subsystems. OMs are configured, collected, stored, and retrieved separately on each system. MTX OM philosophy The DMS-MTX OMs are collected individually by each subsystem (CAU, RMU, and CM) and are periodically sent to the CM for collection. MTX OMs are organized and reported on a per-system, per-sector, or per-carrier-sector basis. MTX OMs are divided into two categories: non-CDMA specific OMs and CDMA specific OMs. Non-CDMA-specific OMs The non-CDMA-specific OMs consist of the OMs common to CDMA, TDMA, and AMPS technologies. Most of these common OMs are related to call processing. However, on systems that are configured for CDMA only, these OMs reflect CDMA related events only. For more information about non-CDMA-specific MTX OMs, see CDMA/ TDMA Operational Measurements Reference Manual (NTP 411-2131-814). CDMA-specific OMs Many OMs have been added to the MTX specifically for CDMA-related events. For example, all OMs pegged by the CAU and RMU are CDMAspecific. The majority of these CDMA-specific groups are identified by OM group names beginning with CAU, RMU, or CDMA. For more information about CDMA-specific OMs, see MSC OM descriptions (page 21-1), BSC OM descriptions (page 22-1), and BTS OM descriptions (page 23-1).
CDMA
NBSS15.0
1-2 CDMA OM design overview Nortel Networks
Extension registers The standard OM registers hold a range of values from 0 to 65 535. When the count in a register exceeds its design limit of 65 535, its extension register (if made available) increases by 1 while the basic register clears. Therefore, an actual event count of 65 536 would show a count of 1 in the extension register and 0 in the basic register. When the actual event count reaches 131 072, the extension register would increase again and show a count of 2, and the basic register would clear again and show a count of 0. Since the features and behavior of extension registers are essentially the same as the registers that they extend, detailed explanations of individual extension registers are unnecessary. For example, the extension register for the OM PGRESP1 is PGRESP1X. CDMA access system OM philosophy The CDMA access system consists of the EBSC/BSC, and the BTS (base station transceiver subsystem). From an OM perspective, the EBSC consists of CPDS (CDMA packet data subsystem), CSVS (CDMA selection and vocoding subsystem), and BSC/SBS (selector bank subsystem). CDMA access system OMs are collected individually by each subsystem and are periodically sent to either the BSSM (base station subsystem manager) or the C-EMS (CDMA element management subsystem). The BSC(SBS) and BTS OMs are sent to the BSSM as QMIP event report messages. Upon receiving these messages, the BSSM stores them in its OM binary file that is currently open. These OMs appear mixed in the BSSM OM binary file. The EBSC OMs (CSVS and CPDS) are uploaded as binary files to the CEMS. 2pVS OMs are handled by the MDP (an MDM component). C-EMS C-EMS is an OA&M platform that was introduced in NBSS 12.1. It manages the OM configurations for the CSVS, CPDS, and SBS subsystems. The CEMS co-resides and interacts with the existing BSSM. Starting in 14.0 release the BSSM should only be deployed with the C-EMS. OM pegging types Each OM can only have one pegging type. The pegging type describes on what basis a particular OM is collected. It also provides a reference and a context for each OM. The following pegging types are supported: node-based: this type of OM is pegged on a per card basis EBID-based: this type of OM is pegged on a per carrier-sector basis IP-based: this type of OM is pegged on a per IP Address basis
411-2133-525
Standard
06.12
April 2008
Nortel Networks
CDMA OM design overview 1-3 Copyright 2008 Nortel Networks
service group-based: this type of OM is pegged on a per service group basis. Service groups are a collection of the following service types: voice: EVRC (8Kbps), high rate voice service (13Kbps), basic 13K, and CSD service types packet data: packet data service type Other: OTAPA (RS1-9.6Kbps), SMS (RS1-9.6Kbps), location based services (RS1-9.6Kbps), Markov (9.6Kbps), Markov(14.4Kbps), MS loopback (8Kbps), and MS loopback (13Kbps) service types
service type-based: this type of OM is pegged on a per service type basis. All the service types are listed above. resource type-based: this type of OM is pegged on a per resource type basis. Supported resource types are as follows: CIC (circuit identification code), ebscSduVoiceAndOther, ebscSduPacketDataAndOther, ebscCct, ebscPkt, ebscTrfo, bscCct, and bscPkt connection type-based: this type of OM is pegged on a connection type basis. Supported connections are as follows: trfo, cct, pkt, and unspecified multi-ID type-based: this type of OM is pegged on a multi-ID basis. This includes the following pegging types: service type, service group, EBID, IP, resource type and RC
OM groups As of NBSS 12.0, OM groups are defined for all of the BSC and EBSC OMs. An OM group is a collection of OMs that logically, functionally, and physically (for example, ESEL cards) relate to one another. Each OM group is assigned an identifier (the group ID). All BSC and EBSC OMs, including those that existed prior to NBSS 12.0, are assigned to OM groups. All BSC and EBSC OMs are classified into these groups. Each OM group can contain OMs of only one pegging type. In NBSS 12.0, BSC and EBSC OMs were given new sequence numbers. OM configuration tool As of NBSS 12.0, the service provider has the capability to turn the pegging of OMs in each group on or off on a per OM group or per OM basis. This continues in NBSS 12.1 and in subsequent releases with the introduction of the C-EMS. The BSSM and the C-EMS provide the user with an interface that is used to inform the system of the users selection. As of NBSS 14.0, the BSSM tool is no longer available. In NBSS 13.0, the OM management tool on the BSSM controls SBS OMs when the C-EMS is not installed. The BSSM OM management tool is disabled when the C-EMS
CDMA System Performance System Performance Metrics NBSS15.0
is installed. The BSSM OM management tools provides system-wide control of SBS OMs (not on a card-level basis). When the C-EMS is installed, the BSSM OM management tool is disabled and the C-EMS OM configuration tool controls CSVS, CPDS, and SBS OMs. The C-EMS provides the ability to enable or disable OM reporting on a percard basis for CSVS and CPDS only (for example, an individual DSFP card can be prevented from uploading its OM file.) The C-EMS OM configuration tool contains a superset of all configurable CSVS, CPDS, and SBS OMs (which are not visually segregated by SBS, CSVS, or CPDS type). Therefore, turning an OM on or off affects that OM on both platforms. Turning performance-related OMs or OM groups on or off through the CEMS OM configuration tool will affect those OM collections on CSVS, CPDS, and SBS. In addition, the C-EMS will not be aware of any manual configuration changes made to the SBS OMs or OM groups through the BSSM system configuration MO. The service provider must be aware that turning off performance-related OMs or OM groups may affect the ability of the provider to use some or all of the metrics described within this document. For more information about C-EMS functionality, see Nortel CDMA C-EMS Fault Management (NN20000-144). BTS OMs are always collected at the subsystem level, but the reporting (for example, uploading) may be enabled or disabled on a per-subsystem basis from the BSSM. For more information about OM management and configuration, see Nortel CDMA BSS Manager Fault Management -- Log Report Generation (NN20000-104). CDMA OMs are collected and stored separately on the DMS-MTX and the BSCandEBSC and the BTS. These systems may or may not consolidate the OMs from multiple nodes as described below. MTX OM consolidation Because of the distributed architecture of the DMS-MTX, any CAU provisioned for the single CDMA access system can process calls from any of the CDMA cells in that BSC system. Therefore, OMs are collected at individual nodes, such as CAU and RMU, across multiple LPPs. With the introduction of the MTX multi-BSC support feature, the NOIS CSS (CDMA signaling subsystem) is enhanced to support more BSCs (the maximum number is increased from 2 to 16) per MTX. As a result the maximum number of cell-sector-frequency supported per NOIS BSC is 4500
411-2133-525 Standard 06.12 April 2008
Nortel Networks
and the maximum number of cell-sector-frequency supported on the MTX is 9000. Depending on the provisioning of parameter OMXFR in table OFCENG, the CM will transfer the values of the OMs from the active to the holding registers every 15 or 30 minutes and upload the OMs from the CAUs and RMUs. Note that parameter OMHISTORYON is disabled. For sector-based OMs, a software entity at the LPP combines and consolidates the OMs from all CAUs on that LPP into a single sector-based OM for that entire LPP. For example, if CAU108 receives 5 originations from sector 13X and CAU109 receives 7 originations from sector 13X, there is one origination OM on the LPP for sector 13X, and its value is 12. These sectorbased OMs gathered at each individual LPP are uploaded to the CM. The CM combines and consolidates all of the individual LPP OMs into a single sectorbased OM. For carrier-sector based OMs, they are similarly consolidated and uploaded as described for the sector-based OMs. For node-based OMs, the OMs are uploaded directly to the CM without consolidation. In MTX 14.0 and NBSS 14.0, the OM framework is modified so that the NOIS LPP OM uploading is initiated each period according to the OFCENG OMXFR setting. This eliminates the two minute skew between the NOIS LPP and the CM OMs. A four minute delay is introduced before starting the subsequent accumulation, recording, reporting, and printing for all MTX OMs, including IOS and CM OMs. This delay is required to ensure that all NOIS LPP OMs are uploaded to the CM holding registers before processing. The NOIS LPP OMs are uploaded directly into the CM holding registers during the four minute OM upload period (and not to the CM active registers). Any late NOIS LPP OMs received by the CM are placed in the CM active registers and used during the next OMXFR cycle. CDMA access system OM consolidation OM consolidation on the CDMA access subsystem is performed by the BSSM and the C-EMS OM parser tool. The OM parser is responsible for parsing each new OM binary file. For OMs tracked on per node basis, the OM parser reports separately for each node. BSC nodes use ESEL and PCU cards. EBSC nodes use ACPs, CACs for DSFP cards, PCUs, and CACs for PCUFP cards. For non-node-based OMs, the OM parser consolidates (for example, sums) the OMs from the multiple nodes. For non-node-based OMs, such as per EBID OMs (extended base ID), the OMs of the individual network elements that relate to that particular EBID are added together to provide a network-wide representation for those OMs.
For example, the FSCHLinkSetupAttempts_2X OM is an EBID-based OM that exists on both ESEL and DSFP cards. Since the ESEL and DSFP cards are pooled system resources, the OM value of FSCHLinkSetupAttempts_2X for a particular EBID may have contributions from more than one ESEL or DSFP card during any given collection period. Therefore, the OM value for FSCHLinkSetupAttempts_2X for a particular EBID is a sum of pegs at all ESEL and DSFP cards. Similarly, the per-IP-based OMs that are pegged at the PCU and the PCUFP cards are also summed up for a particular IP address and a single value is provided in the OM report. This functionality is the default behavior of the OM parser. The OM parser can also be run in nonaccumulation mode as described below. The specifics of OM uploading, processing, and file location are slightly different depending on whether the subsystem is part of the EBSC, BSC, or BTS platform as described below. EBSC-specific OM upload process For C-EMS managed subsystems such as CPDS, the collection agents (for example, the DSFP card for ACPs) are responsible for pegging and collecting OMs. Every 30 minutes, these binary files are transferred to the C-EMS using FTP and placed in the C-EMS /opt/cems/log/OMBinary directory. The binary files have a format similar to SBS binary files. The EBSC OMs are collected over 30 minute intervals starting and ending on the hour or half hour (for example, 16:00:00 or 16:30:00) and then uploaded to the C-EMS. BSC-specific OM upload process For the BSC subsystem, the OMs are pegged, collected, and sent to the BSSM through an event trigger. As of NBSS 12.0, the BSC (SBS) OM upload system is enhanced so that the OM data is directly uploaded from the subsystems (ESEL, PCU) to the BSSM. The uploaded event report is saved in binary format on the BSSM in the /opt/bsm/log/OMBinary directory. The BSC OMs are collected over 30 minute intervals starting and ending on the hour or half hour (for example, 16:00:00 or 16:30:00) and subsequently uploaded to the BSSM. BTS-specific OM upload process For the BTS subsystem, the OMs are pegged, collected, and sent to the BSSM through an event trigger. The uploaded event report is saved in binary format on the BSSM in the /opt/bsm/log/OMBinary directory. The OMs pegged at the BTS cannot distinguish between events related to calls set up on the SBS or CDPS.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The BTS OMs are collected over 30 minute intervals starting and ending on the hour or half hour (for example, 16:00:00 or 16:30:00) and subsequently uploaded to the BSSM. OM parsing In the case of deployment with C-EMS and BSSM, the default behavior of the OM parser is to process the binary files under both the /opt/cems/log/ OMBinary and /opt/bsm/log/OMBinary directories. The output files from the OM parser are raw ASCII text files. C-EMS provides the capability to configure the OM parsing time (for example, when the OM parser is run to generate the ASCII files). The OM parser can be run in different modes. Two of these modes are discussed below. For more information about running the OM parser, see Nortel CDMA C-EMS Fault Management (NN20000-144). OM parser accumulation mode (default) When the OM parser runs under the default mode, it generates the following files: CPDS-<timestamp>, which contains the node-based CPDS OMs listed for each ACP, CAC, and PCU CSVS-<timestamp>, which contains the node-based CSVS OMs listed for each ACP, CAC, and PCU Resource Management-<timestamp>, which contains the node-based resource management OMs for the NRM, CSRM, SDRM, and SBSRM SBSCSubsystem-<timestamp>, which contains the node-based SBS OMs listed for each ESEL and PCU. MCBTSSubsystem-<timestamp>, which contains the node-based BTS OMs listed by BTS MO (for example, the BTSCallProcessing MO and the AdvancedFA MO). BSC-<timestamp>, which contains the non-node-based consolidated (for example, summed) OMs such as EBID, Multi-ID, and IP-based OMs from both BSC and EBSC nodes. For example, per carrier-sector OMs that peg for a given carrier sector on both the CSVS, CPDS, and SBS will result in one single summed up value for those particular OMs.
The node based CPDS/CSVS/resource management-<timestamp> files are stored in the /opt/cems/log directory while the SBSCSubsystem<timestamp>, MCBTSSubsystem-<timestamp>, and BSC-<timestamp> files are stored in the /opt/bsm/log directory.
CDMA
NBSS15.0
OM parser no accumulation mode The OM parser can also be run manually with a non-accumulation option. By specifying this option, the OM parser will not accumulate (for example, add) any EBID and IP OM values together. Instead, it will print out the OM values exactly as they were found in the binary files. Therefore, all OMs will be displayed only on a per-node and per-card basis. When the OM parser runs under this mode, it generates the following files: CPDS-<timestamp> and CSVS-<timestamp>, which contains the nodebased, IP-based, and EBID-based CPDS and CSVS OMs listed for each ACP, CAC, and PCU Resource Management-<timestamp>, which contains OMs at the CNFP SBSCSubsystem-<timestamp>, which contains the node-based, IP-based, and EBID-based BSC OMs listed for each ESEL and PCU MCBTSSubsystem-<timestamp>, which contains the node-based BTS OMs listed by the BTS MO (for example, the BTSCallProcessing MO and the AdvancedFA MO)
When the OM parser is run with the non-accumulation option, the node, interface and some multi-ID-based OMs for CSVS, CPDS, and SBS are no longer summed up. Instead, these OMs for CSVS and CPDS are included in the CSVS/CPDS-<timestamp> file on a per-node basis along with the nodebased OMs. Similarly, these SBS OMs are included in the SBSCSubsystem<timestamp> file along with the node-based OMs.
OM metrics overview
The OMs collected by the DMS-MTX, BSC, EBSC, and BTS make it possible to define and implement performance-related metrics. This document contains informaiton about metrics that help customers monitor and improve the performance of their wireless systems. These metrics are useful because: measurements are pieces of data reporting a value that concerns a particular function or event metrics are pieces of information, derived from one or more measurements, providing a view of system performance
useful metrics have a specific purpose that relate to customer need and are benchmarked to establish norms. metrics are used for preventative actions rather than for debugging or analysis after-the-fact or for the measurement of abnormal events.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
if possible, metrics have a mechanism (formula) in place to guarantee their validity (for example, total number of packets received = total dropped packets + total long packets + total short packets)
OM validation overview
Where possible, formulas are provided at the end of each major section or chapter to allow the validation of related OMs. The basic formula used is: Attempts = Successes + Non-Successes Validation formulas provide confidence that the system is capturing events correctly.
Since OMs are collected during specific intervals, it is possible for related OMs to span one or more OM collection periods. This may cause a slight discrepancy in any of the validation formulas described in this document. For example, an attempt OM for a particular event may be captured at the end of one OM period while the success or non-success of that same event may be captured at the beginning of the next OM period. Therefore it is recommended that, where possible, the validation formulas be used with OMs collected over a 24 hour period in order to minimize the effect of these discrepancies.
CDMA
NBSS15.0
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call setup performance reflects how well the system is accepting originations, terminations, and hard handoff attempts from other CDMA cells. There are three different stages when a call may fail: 1. Before the resources are allocated (blocked Calls). This can occur during the setup of a new origination, termination, or hard handoff target, or during a resource allocation attempt for a queued WPS (wireless priority service (WPS) call. 2. When the mobile is moving from the common channel to the traffic channel (access failures) 3. After the mobile is on the traffic channel. Basically, the subscriber does not perceive the difference between the call (origination) failing due to no resources or due to poor RF performance. However, to the service provider, they are two separate problems: one problem of improper provisioning and the other problem of RF engineering or possible problems with the subscribers mobile unit. For more information about item 1, see Call setup failure before resources are allocated (blocked calls) (page 2-10). For more information about item 2, where the base station is unable to receive traffic from the mobile on the reverse traffic link, see Call setup failures due to RF failures (page 2-18). For more information about item 3, see Dropped call performance (page 6-1). This chapter contains 3G packet data call setup metrics. For packet data calls, the call may set up successfully but the bursts may still fail. The metrics for the packet data scenarios, including SCH burst setups, are listed in 1xRTT packet data performance (page 3-1).
List of OMs
2
The following list contains the MSC, BSC, and BTS OMs that are relevant to this chapter.
2-2 Call setup performance Nortel Networks
For more information about detailed OM descriptions, see MSC operational measurements (page 21-1), BSC OM descriptions (page 22-1), and Metro Cell BTS operational measurements (page 23-2).
Call setup performance OMs
MSC OMs
CAUCPSCT OM group CAUPGRES CAUTRLS CAUORODR SLTPGRES CAUHRLS CAUESWFL CAUFWCAP MCTALLFU CAUTSUCC CAUOATTS CAUORLS CAUHATTS CAUHRLFL CAUNOTCE SCTBTSBK MCTALLTO CAUTBLKS CAUOSUCC CAUERSFL CAUHBLKS CAUDROPR CAUNOWCD MCTAHRQF MCTAMIXF CAUEDLOT CAUOBLKS CAUERLFL CAUHSUCC CAUDROPN CAUNOFOF MCTAREQF CAUHINIT
CAUSCT2 OM group NORFSEFL WPSTRTRY NRFSEFHH MISCFLT WPSRETRY
CAUSCT3V OM group This OM group has the same OM registers as the CAUCPSCT OM group listed above.
CAUST3V2 OM group This OM group has the same OM registers as the CAUSCT2 OM group listed above
CAUSCT3D OM group This OM group has the same OM registers as the CAUCPSCT OM group listed above.
411-2133-525
Standard
06.12
April 2008
Nortel Networks Call setup performance OMs CAUST3D2 OM group CAURELSI PDSEFLDS PDSEFLAS
Call setup performance 2-3 Copyright 2008 Nortel Networks
EBPBCPOM OM group ESBSRASU ESBNRSFL ESBSCSS ECSVRASU ECSNRSFL ECSVCSS ESBESWFL ESBERLFL ECSESWFL ECSERLFL
BAMCPSCT OM group BAMOATTS BAMERLFL MCPCTBAM BAMOSUCC BAMEDLOT BAMPGRES BAMWPSRT BAMTSUCC MCPCOBAM
CAUCPSYS OM group CAUORIGS CAUCNICV CAUTMWNR CAUREGNS CAUCNITR CAUFLASH CAUHOSRC CAUTMWNA CAUMRLS CAUHOTRG CAUTMWNC CAULRLS
CAUCPFRQ OM group MCTORIGS MCTTATTS MCTHSUCC MCTNOWCD MCTERLFL MCTDROPR MCTOATTS MCTTSUCC MCTHRLFL MCTNOFOF MCTAREQT MCTOSUCC MCTHCATT MCTERSFL MCTFWCAP MCTAREQN MCTPGRES MCTHATTS MCTNOTCE MCTBTSBK MCTARQFN
CAUFRQ3V OM group
CDMA
NBSS15.0
2-4 Call setup performance Nortel Networks Call setup performance OMs
This OM group has the same OM registers as the CAUCPFRQ OM group as listed above.
CAUFRQ3D OM group This OM group has the same OM registers as the CAUCPFRQ OM group as listed above.
BAMCPFRQ OM group BAMSCSAT BAMSCSFL BAMSBSAT BAMSBSFL
CAUXTFRQ OM group NMCTATTS MCTPRST MPRFL MRETHBLK MRETHFL NMCTBLKS MCTPRSO MRETATTS MRETSUCC MCTPRRO MPRBLKS MRETHATT MRETHSUC MCTPRRT MPRSUCC MRETBLKS MRETFL
CAUXTF3V OM group This OM group has the same OM registers as the CAUXTFRQ OM group listed above.
CAUXTF3D OM group This OM group has the same OM registers as the CAUXTFRQ OM group listed above.
BSCRM OM group RMUIATOV RMURATOV RMUIANRD RMURANRD RMUIANRV RMURANRV RMUIOEND RMURAOED RMUIOENV RMURAOEV RMURARD RMURARV RMUIATOD RMURATOD
411-2133-525
Standard
06.12
April 2008
Nortel Networks Call setup performance OMs BSCRM2 OM group RMUIRDS RMURRDS RMUINRDS RMURNRDS RMUITODS RMURTODS
RMUIOEDS RMUROEDS
EBSCRM OM group NRMARV NRMOLRV NRMOEPD NRMANRDS NRMSTODS NRMANRV NRMSTOV NRMOLRPD NRMAOEDS NRMOEV NRMARPD NRMSTOPD NRMATODS NRMATOV NRMANRPD NRMARDS NRMOLRDS
CAUMISC OM group CAUUNSO RMUUNSO NRMUNSO FLEVR13K
CDMAIVSN OM group ONILDNY ODENYCAU ODENYCM TDENYCAU
CDMAPDOM OM group MIDTOAAT NIDTOASU NULTOAFL NIFLMINA NIFLSRSP MSREGNOT NIDTOAFX NIFLNSOP MIDTOASU NIDTOAFL MIDTOAAX NIFLPGTM NIFLCLFL MIDTOAFX NULTOAAX MIDTOAFL NULTOAAT MIDTOASX NIFLPGNG NIFLMRLS NIDTOAAX NULTOASX NIDTOAAT NULTOASU NIFLNVLR NIFLVCLL NIFLAMPS NIDTOASX NULTOAFX
CDMA
NBSS15.0
2-6 Call setup performance Nortel Networks Call setup performance OMs CDSNMQRY OM group FLTCEVR 3GFLI13K FLTCI13K 3GFLB13K FLTCB13K
3GFLTEV
MTXPDSCT OM group NWKFLBS AHRLPFL NWKFLAS NARLPFL DARLPFL
MTXPDSYS OM group NARPFLBS DARPFLAS DARPFLBS AHRPFLAS AHRPFLBS DHORPFL NARPFLAS
MTXSYS1 OM group CDMAPRS1 CDMAPRS2 TDENYCM
MTXSYS2 OM group GECRCVD MEIDQSCC ESNATTS GECATTS MEIDQRTC GECSUCC MEIDQSTC MEIDQRCC MEIDATTS
OMMTX OM group MBORIGS
OMMTXSYS OM group TWCSTART
OMMTX2 OM group
411-2133-525
Standard
06.12
April 2008
Nortel Networks Call setup performance OMs VPADIC
OMMTX3 OM group SRTDBORG SLNTRTAF SRTDBO2G SLNTRT2G SRTDBO3V SLNTRT3V SRTDBO3D SLNTRT3D
OMMTXSY2 OM group VPADATT VPADSUC VPADFL
TRMTRS OM group TRSGNCT
WPSOM1 OM group WQTOUT WQOVFL WINVALDQ
BSC OMs
RLP Setup OM group RLPSetupAttempts RLPSetupSuccesses RLPSetupFailures
Packet Session Signaling OM group TotalSessionSetupInitialAtt empts TotalInitialRPSessionSetup Failures TotalSessionSetupReconn TotalSessionSetupSuccess TotalSessionSetupFailur ectAttempts es TotalRPSessionHandoffFa TotalReleasesBeforeInitial TotalReleasesBeforeHan ilures SessionSetup doffSessionSetup
Packet Session Data OM group
CDMA
NBSS15.0
2-8 Call setup performance Nortel Networks Call setup performance OMs TotalFwdPacketsDropped TotalRevPacketsDropped
DCRBufferOverflows
DCRNumOfStopTransm itMsgsSent PeakNumberOfAttached ActiveUsers SessionTransitionsQueu ed
RRBufferOverflows
PeakNumberOfAttachedD AttachedActiveUsers ormantUsers NumberOfDormantCallsG EnteredSessionTransition oingActive ThrottleMode
AttachedDormantUsers
ExitedSessionTransitionThr TotalDormantBufferLimit ottleMode Overflows
RP Session Signaling OM group TotalInitialRP_SessionSetu pAttempts TotalInitialRP_SessionSet TotalInitialRP_SessionSet TotalInitialRP_SessionS upSuccesses upRejectReasonOther etupRejectReasonIdMis match
TotalInitialRP_SessionSetu TotalInitialRP_SessionSet TotalInitialRP_SessionSet TotalRP_SessionHandof pRejectReasonInsufficientR upRejectReasonMobileAu upFailuresReasonPDSN_ fAttempts NotResponding esources thFailure
TotalRP_SessionHandoffSu TotalRP_SessionHandoff ccesses RejectReasonOther
TotalRP_SessionHandoff RejectReasonIdMismatch
TotalRP_SessionHandof fRejectReasonInsufficie ntResources
TotalRP_SessionHandoffRe TotalRP_SessionHandoffF PCU_InitiatedSessionRele PCU_InitiatedSessionRe jectReasonMobileAuthFailu ailuresReasonPDSN_Not asePacketSessionDisconne leasePacketSessionDrop re Responding ct PCU_InitiatedSessionReleas PCU_InitiatedSessionRele TotalRegistrationRequest ePDSN_Reject aseOther MsgSent TotalRegistrationRequestRe TotalRegistrationRequest jectReasonOther RejectReasonIdMismatch TotalRegistrationReques tRetries
TotalRegistrationRequest TotalRegistrationReques RejectReasonInsufficientR tRejectReasonMobileAu esources thFailure
TotalRegistrationRequestRe TotalSignallingMsgReceiv jectReasonPDSN_NotRespo ed nding
RP Session Data OM group RPTotalOutofSequencePack RPTotalUnreliableBytesTr RPTotalUnreliableBytesR etsReceived ansmitted eceived
411-2133-525
Standard
06.12
April 2008
Nortel Networks Call setup performance OMs
PCU Manager OM group DormantToActiveHandoffs PCU_AllocSuccessful DormantHandoffRequests PCU_AllocRequests IMSI_TableFull PCU_AllocFailures
RP Session L2TP OM group ReliablePacketSentSuccess ReliablePacketReTransmit ReliablePacketReceived ted NumberOfTunnelFailure s
TotalUnreliableBytesTrans mitted
TotalUnreliableBytesRece RP_SessionSetupAttempts RP_SessionSetupSucces ived ses
RP_SessionSetupRejectRea RP_SessionSetupRejectRe RP_SessionSetupRejectRe RP_SessionSetupReject sonGenErr asonNoCarrier asonAdminReason ReasonNoTempRsrcs
RP_SessionSetupRejectRea RP_SessionSetupRejectRe RP_SessionSetupRejectRe RP_SessionSetupReject sonNoPermRsrcs asonSysOverload asonOther ReasonNoPDSNRsp
BTS OMs
Advanced Sector MO FchOriginationNonBlocking FchOriginationNonBlocki FchOriginationNonBlocki BlockedFchOriginations 3GDowngrade2G ng3GDowngrade2GNoAc ng3GDowngrade2GNoBc 2G[6]: CFDS Radio n n Config State BlockedFchOriginations3G Voice[6]: CFDS Radio Config State BlockedFchOriginations3 GData[6]: CFDS Radio Config State
CDMA
NBSS15.0
Call setup failure before resources are allocated (blocked calls)
Call setup failures before resources are allocated are network-related call setup failures and can be classified as follows: 1. Screened calls (call setup interrupted for reasons such as un-authenticated mobile, mobile-initiated release, land-side release, and denials due to unsupported Service Options) 2. Call setup failure due to lack of physical resources 3. Call setup failure due to time-outs and software faults Network resources are defined as the following switching resources involved in the call: terrestrial trunks (SBS to DTC trunks) Goal Less than x% of all originations attempted failed due to resource shortages. Less than y% of all terminations attempted failed due to resource shortages. Less than z% of all hard handoffs attempted to CDMA cells are failed due to resource shortages. SBS selector elements BTS traffic channel elements. non-availability of excess RF capacity. non-availability of Walsh codes PDSN PCU
The variables above (x, y, and z) are defined in accordance with the service providers planned grade of service. It is improper to provision the system (for example, x + y + z) for 2% blocking and then set the goal for anything other than 2%. Formula usage The Boolean field OM3G in table CDMAPART is an indicator of whether the OMs for 3G voice calls and 3G data calls are to be kept separate from the OMs for 2G calls. The OM groups CAUSCT3V, CAUSCT3D, CAUFRQ3V, CAUFRQ3D, CAUXTF3V, CAUXTF3D maintain 3G voice and 3G data OM counts for a particular sector only if OM3G is set to Y. If a particular sector is 3G-capable but OM3G is set to N, the 3G voice and 3G data OM counts are combined with the 2G OMs in the CAUCPSCT, CAUCPFRQ and CAUXTFRQ OM groups.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Impact of OM3G Boolean on OM registers in certain OM groups
OM3G Impact on Boolean CAUCPSCT, CAUCPFRQ, and CAUXTFRQ OM groups

Y The registers in these OM groups get pegged only for events related to 2G voice and CSD calls The registers in these OM groups get pegged for all call-related events (3G voice & CSD, 3G data, and 2G voice and CSD calls)
Impact on CAUSCT3V, CAUFRQ3V, and CAUXTF3V OM groups

The registers in these OM groups get pegged only for events related to 3G voice and CSD calls The registers in these OM groups do not get pegged. The related 3G voice and CSD callspecific events will be captured in CAUCPSCT, CAUCPFRQ, and CAUXTFRQ OM groups along with 3G data and 2G call-related events.
Impact on CAUSCT3D, CAUFRQ3D, and CAUXTF3D OM groups

The registers in these OM groups get pegged only for events related to 3G data calls The registers in these OM groups do not get pegged. The related 3G data call-specific events will be captured in CAUCPSCT, CAUCPFRQ, and CAUXTFRQ OM groups along with 3G voice and 2G call-related events.
Impact of OM3G Boolean on OM registers in the new OM groups
OM3G Impact on Boolean CAUSCT2 OM group

Y The registers in this OM group get pegged only fr events related to 2G voice and CSD calls The registers in this OM group get pegged for 2G, 3G voice, and CSD related calls. The 3G packet data OMs do not have registers that can be pegged here.
Impact on CAUST3V2 OM group

The registers in this OM group get pegged only for events related to 3G voice and CSD calls The registers in this OM group do not get pegged. The 3G voice and CSD call related events will be captured in CAUSCT2 OM group.
Impact on CAUST3D2 OM group

The registers in this OM group get pegged only for events related to 3G packet data calls The registers in this OM group do not get pegged.
CDMA
NBSS15.0
The attempts in the following sections refer to those calls that the system is aware of and attempts to setup resources for. For example, the system is not aware of origination call attempts that exhaust the access probes since the origination message is lost and, therefore, is not received by the BTS. Similarly, the system does not count termination call attempts if the page timed out without receiving a response, since the system does not attempt to set up resources. Attempts to allocate resources for WPS calls that are queued are considered a call setup attempt, since the origination for the call originally resulted in a block (the call is then queued). WPS calls can be either 2G or 3G voice only. Total calls attempted The following formula will be used (and will be referred to) throughout the chapter. Total calls attempted = (CAUOATTS + CAUPGRES + CAUHATTS + WPSRETRY + WPSTRTRY) for all sectors - (MCTPRSO + MCTPRST) for all frequencies for all MCTA sectors +/FchOriginationNonBlocking3GDowngrade2G +/FchOriginationNonBlocking3GDowngrade2GNoAcn +/FchOriginationNonBlocking3GDowngrade2GNoBcn for all sectors. The MCTPRSO and MCTPRST OMs are subtracted in the above formula accounting for the origination or termination attempts that get redirected by MCTA to the alternate CDMA band resulting in CAUOATTS or CAUPGRES OM being pegged twice in those events. It is also important to note that the above formula evaluates the metric on a per system wide basis. However, when the metric is to be evaluated on a per sector basis, the MCTPRSO and MCTPRST OMs in the above formula are replaced with MCTPRRO and MCTPRRT OMs respectively. The FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn BTS OMs are pegged when the BTS runs out of XCEM resources but still has CEM resources and all other needed resources to be set up for the call as a 2G voice call rather than a 3G voice call as requested by the mobile. These BTS OMs are included in the above metric as well as other metrics later on in this chapter for the following reason: When a mobile attempts to make a 3G voice call, the attempt is pegged in CAUSCT3V OM group, but if the call is downgraded to 2G as described above, then the subsequent events for that call (i.e. success or access failure,...etc.) are pegged in CAUCPSCT OM group. Therefore, when evaluating certain metrics on a per call type basis (i.e. 2G versus 3G voice), the BTS OMs FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn are added to the 2G attempts and subtracted from the 3G attempts as stated below.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The WPSRETRY and WPSTRTRY OMs only apply to voice and circuit switched data calls. There is no WPS service for packet data calls. For packet data only metrics, do not include these two OMs in the Total Calls Attempted term. Call types The following sections will be referred to throughout the chapter in order to evaluate the metrics based on call types (2G Voice, 3G Voice, Voice Calls, PD Calls and For all Call types together) For 2G voice calls For 2G calls, use the OMs from the OM groups CAUCPSCT, CAUSCT2 and CAUXTFRQ in the formula and add the value of the BTS OMs FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn in the formula. For non-3G enabled systems, the BTS OMs FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn in the above formula are not applicable and are not pegged. For 3G voice calls For 3G Voice calls, use the OMs from OM groups CAUSCT3V, CAUST3V2 and CAUXTF3V in the formula and subtract the value of the BTS OMs FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn in the formula. For voice calls For Voice calls use the OMs from OM groups CAUCPSCT, CAUSCT2, CAUSCT3V, CAUST3V2 (and from OM groups CAUXTFRQ, CAUXTF3V, CAUXTF3D) in the formula, but the BTS OMs FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn in the formula are not applicable since the value is already included in the other OMs. For 3G packet data calls For 3G Packet Data calls, use the OMs from OM groups CAUSCT3D, CAUST3D2 and CAUXTF3D in the formula, but the BTS OMs FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn in the above formula are not applicable for packet data calls. For all call types For all call types together, use the sum of the OMs from OM groups CAUCPSCT, CAUSCT2, CAUSCT3V, CAUST3V2, CAUSCT3D and CAUST3D2 (and from OM groups CAUXTFRQ, CAUXTF3V, CAUXTF3D) in the formula, but the BTS OMs
CDMA
NBSS15.0
FchOriginationNonBlocking3GDowngrade2G/NoAcn/NoBcn in
the formula are not applicable since the value is already included in the other OMs.
Overall call setup failures (call blocking rate)

(CAUOBLKS + CAUTBLKS + CAUHBLKS) all sectors / Total calls attempted x 100 For more information about how to use the above metric based on call type (2G Voice, 3G Voice or 3G Packet data calls), see Call types (page -13)
Call setup failures (blocks) due to lack of EBSC/BSC resources This metric indicates the shortage of the resources for Voice, Packet Data and Data Delivery Services (SMS, OTAPA, LCS). This metric indicates that resources are not available for the call during resource allocation request phase. This situation may be improved by provisioning BSC/EBSC additional resources. System where NRM is resource manager Voice call setup failures (blocks) ( NRMANRV for all CAUs / Total calls attempted)x 100 Packet data call setup failures (blocks) ( NRMANRPD for all CAUs / Total calls attempted)x 100 Data delivery services (SMS, OTAPA, LCS) call setup failures (blocks) ( NRMANRDS for all CAUs / NRMARDS for all CAUs) x 100 All (voice and packet data) call setup failures (blocks) ( (NRMANRV + NRMANRPD) for all CAUs / Total calls attempted) x 100 Failures combined for Voice, Packet data and Data Delivery services together can also be derived. System where RMU is resource manager Voice call setup failures (blocks) ( (RMURANRV + RMUIANRV - RMURARV) for all CAUs / Total calls attempted) x 100 Packet data call setup failures (blocks) ( (RMURANRD + RMUIANRD - RMURARD) for all CAUs / Total calls attempted) x 100 Data delivery services (SMS, OTAPA, LCS) call setup failures (blocks) ( (RMURNRDS + RMUINRDS - RMURRDS) for all CAUs / RMUIRDS for all CAUs) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
All (voice and packet data) call setup failures (blocks) ( (RMURANRV + RMUIANRV - RMURARV + RMURANRD + RMUIANRD - RMURARD) for all CAUs / Total calls attempted) x 100 Failures combined for Voice, Packet data and Data Delivery services together can also be derived. Call setup failures due to BSC/EBSC processing errors This metric is useful in determining the blocks due to certain processing errors such as time outs or internal errors occurring during the resource allocation phase. Blocking of calls due to such error conditions is typically rare and is not due to shortage of resources. System where NRM is resource manager Voice call setup failures ( (NRMATOV + NRMOEV + NRMOLRV + NRMSTOV) for all CAUs + CAUESWFL for all sectors / Total calls attempted) x 100 Packet data call setup failures ( (NRMATOPD + NRMOEPD + NRMOLRPD + NRMSTOPD) for all CAUs + CAUESWFL for all sectors / Total calls attempted) x 100 Data delivery services (SMS, OTAPA, LCS) call setup failures ( (NRMATODS + NRMOEDS + NRMOLRDS + NRMSTODS) for all CAUs / NRMARDS for all CAUs) x 100 All (voice and packet data) call setup failures ( (NRMATOV + NRMOEV + NRMOLRV + NRMSTOV + NRMATOPD + NRMOEPD + NRMOLRPD + NRMSTOPD) for all CAUs + CAUESWFL for all sectors / Total calls attempted) x100 Failures combined for Voice, Packet data and Data Delivery services together can also be derived.
System where RMU is resource manager Voice call setup failures ( (RMUIATOV + RMURATOV + RMUIOENV + RMURAOEV) for all CAUs + CAUESWFL for all sectors / Total calls attempted) x 100 Packet data call setup failures ( (RMUIATOD + RMURATOD + RMUIOEND + RMURAOED) for all CAUs + CAUESWFL for all sectors / Total calls attempted) x 100
Data delivery service (SMS, OTAPA, LCS) call setup failures ( (RMUITODS + RMURTODS + RMUIOEDS + RMUROEDS) for all CAUs / RMUIRDS for all CAUs) x 100 All (voice and packet data) call setup failures ( (RMUIATOV + RMURATOV + RMUIOENV + RMURAOEV + RMUIATOD + RMURATOD + RMUIOEND + RMURAOED) for all CAUs + CAUESWFL for all sectors / Total calls attempted) x 100 Failures combined for Voice, Packet data and Data Delivery services together can also be derived. Call setup failures (blocks) due to BTS physical resources These metrics determine the shortage of BTS physical resources. High values of these metrics should be addressed by provisioning additional BTS resources. Call setup failures (blocks) due to all BTS related blocks ( CAUERSFL all sectors / Total calls attempted) x 100 Call setup failures (blocks) due to lack of BTS channel elements ( CAUNOTCE all sectors / Total calls attempted) x 100 Call setup failures (blocks) due to lack of Walsh codes ( CAUNOWCD all sectors / Total calls attempted) x 100 Call setup failures (blocks) due to lack of forward capacity ( CAUFWCAP all sectors / Total calls attempted) x 100 Call setup failures (blocks) due to no frame offset availability ( CAUNOFOF all sectors / Total calls attempted) x 100 Call setup failures (blocks) due to miscellaneous BTS failure reasons ( SCTBTSBK all sectors / Total calls attempted) x 100 For more information about how to use the above metrics based on call type (2G Voice, 3G Voice or 3G Packet data calls), see Call types (page -13). Call setup failures (blocks) due to BTS time-outs ( (CAUERSFL - CAUNOTCE - CAUNOWCD - CAUFWCAP CAUNOFOF - SCTBTSBK - BlockedFchOriginations*[6] MCTAREQF - MCTAHRQF + MCTALLTO) all sectors / Total calls attempted) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
For more information about how to use the above metrics based on call type (2G Voice, 3G Voice or 3G Packet data calls), see Call types (page -13). Use the appropriate BlockedFchOriginations*[6] OM based on the call type (2G Voice, 3G Voice or 3G Packet data calls). 3G packet data call setup failures (blocks) 3G Packet Data Call setup failures (blocks) due to RP session setup failures during null to active transition of a packet data call before service connect completion can be expressed as: ( NARPFLBS for all sectors) / ( CAUOATTS for all sectors MIDTOAAT - MCTPRSO for all frequencies for all MCTA sectors)) x100 3G Packet Data Call setup failures (blocks) due to RP session setup failures during dormant to active transition of a packet data call before service connect completion can be expressed as: ( DARPFLBS for all sectors) / (MIDTOAAT + NIDTOAAT ) x100 3G Packet Data Call setup failures (blocks) due to RP session setup failures during active handoff of a packet data call before service connect completion can be expressed as: ( AHRPFLBS for all sectors) / ( CAUHATTS for all sectors) x100 In the above formula use the sum of each CAU* OMs from the CAUSCT3D, CAUXTF3D and CDMAPDOM OM groups. The MCTPRSO OM is subtracted in the above formula to account for the origination attempts that are redirected by MCTA to the alternate CDMA band resulting in CAUOATTS being pegged twice in this event. It is also important to note that the above formula evaluates the metric on a per system wide basis. However, when the metric is to be evaluated on a per sector basis, MCTPRSO in the above formula is replaced with MCTPRRO. Screened calls For voice calls ((CAUORLS + CAUTRLS + CAUHRLS + CAUORODR + MISCFLT) all sectors - (WQTOUT + WQOVFL + WINVALDQ) / Total calls attempted) x 100 For more information about the OM groups to use in the above formula, see For voice calls (page -13). For packet data calls ((CAUORLS + CAUTRLS + CAUHRLS + CAUORODR) all sectors / (CAUOATTS + CAUPGRES + CAUHATTS) for all sectors(MCTPRSO + MCTPRST) for all frequencies for all MCTA sectors)) x100
For more information about the OM groups to use in the above formula, see For 3G packet data calls (page -13). Screened calls for 3G packet data calls due to mobile service inactive indication during network initiated dormant to active transition ( CAURELSI all sectors / CAUPGRES all sectors - MCTPRST all freq, all MCTA sectors) x 100 For network initiated dormant calls in the denominator, use the sum of OMs from OM groups CAUSCT3D and from OM groups CAUXTF3D. The MCTPRST OM is subtracted in the above formula accounting for the termination attempt that gets redirected by MCTA to the alternate CDMA band resulting in CAUPGRES OM being pegged twice in that event. It is also important to note that the above formula evaluates the metric on a per system wide basis. However, when the metric is to be evaluated on a per sector basis, the MCTPRST OM in the above formula are replaced with MCTPRRT OM. High value of this CAURELSI OM may result in high values of the Screened calls for All Call Types Together metric, so operators should subtract this (CAURELSI OM) value from the screened calls metric to get screened calls metric due to other failure reasons.
Call setup failures due to RF failures

Call failures during setup are usually RF-related call setup failures and are classified as follows: 1. RF Access failure during origination/termination
RF Access failures are the call setup failures that occur when the mobile is moving from the common channel (paging or FCCCH) to the traffic channel during origination or termination (i.e. the base station is unable to receive traffic from the mobile on the reverse traffic link). 2. RF Hard Handoff failure Hard Handoff failure are the failures that occur when a mobile does not arrive on the traffic channel set up on the sector in the target system due to RF coverage issues. This section provides the following per-sector RF related failure metrics: Overall RF access failures Origination and Termination RF access failures on common channels Hard Handoff RF access failures Origination and Termination RF access failures on FCCCH channel Origination and Termination RF access failure on paging channel
411-2133-525
Standard
06.12
April 2008
Nortel Networks
This section also provides the following per-frequency RF access failure metrics for FCCCH channel: Goal Less than x% of all originations and terminations attempted failed due to RF Access Failure. Less than y% of all hard handoffs attempted to CDMA cells are failed due to RF Access Failure. Origination and Termination RF access failures for same band selected Origination and Termination RF access failures for same frequency selected
Formulas Following are the per sector RF access failure metrics: Overall RF access failures This metric provides the combined RF access failure for originations & terminations on the common channels and Hard Handoffs. ( (CAUERLFL + CAUHRLFL) for all sectors / Total calls attempted) x 100 Origination and termination RF access failure on common channels ( CAUERLFL for all sectors / (CAUOATTS + CAUPGRES + WPSRETRY + WPSTRTRY) for all sectors- (MCTPRSO + MCTPRST) for all frequencies for all MCTA sectors) x 100 Hard handoff (HHO) RF access failure ( CAUHRLFL for all sectors / CAUHATTS for all sectors) x 100 The above formula evaluates the metric on a per system wide basis. However, when the metric is to be evaluated on a per sector basis, the CAUHATTS OM in the above formula is replaced with the CAUHINIT OM. For more information about how to use the above metrics based on call type (2G Voice, 3G Voice or 3G Packet data calls), see Call types (page -13). The RF access failures on FCCCH channel can be compared with the RF access failures on the paging channel to assess the performance of FCCCH channel in comparison with the paging channel. Origination and termination RF access failure on FCCCH channel Since BAM OMs peg for all 2G, 3GVoice and 3GData calls combined, the metric below provides the combined RF access failure for all calls on the FCCCH channel.
CDMA
NBSS15.0
BAMERLFL for all sectors / ((BAMOATTS + BAMPGRES + BAMWPSRT)for all sectors - (MCPCOBAM + MCPCTBAM)) for all frequencies for all MCTA sectors) x 100 Origination and termination RF access failure on paging channel (CAUERLFL - BAMERLFL) for all sectors / ((CAUOATTS + CAUPGRES + WPSRETRY + WPSTRTRY - BAMOATTS BAMPGRES - BAMWPSRT) for all sectors - (MCTPRSO + MCTPRST - MCPCOBAM - MCPCTBAM)) for all frequencies for all MCTA sectors) x 100 All CAU* OMs, WPSRETRY, WPSTRTRY and MCT* OMs in the above formula for paging channel represent the summation of all corresponding OMs from 2G voice, 3G voice and 3G data OM groups. This is because the BAM channel OMs peg for all call types combined. If MCTA feature is turned on, the resources for a call may be set up on the same frequency, a different frequency on the same band or a different frequency on a different band. Following metrics provide the per frequency RF access failures for FCCCH channel. These metrics should not be compared to the per frequency RF access failures presented in the MCTA chapter since the pegging behavior of these OMs is different. Origination and termination RF access failure for same band selected This metric provides the breakdown of the sector wide RF Access failure rate on the FCCCH channel on a per frequency basis. This metric is useful in pointing to a particular frequency issue rather than a sector wide issue. (BAMSBSFL / BAMSBSAT) for a given frequency x 100 Origination and termination RF access failure for same frequency selected This metric provides the RF access failure rate for calls that originated on a frequency and were set up on the same frequency. If the number of carrier redirections are low, then the metric below can be used to derive and compare the RF access failure rate on paging channel with the RF access failure rate of FCCCH channel. (BAMSCSFL / BAMSCSAT) for a given frequency x 100
Voice call failures during setup due to non-RF resource failures

Call failures during setup due to non-RF resource failures are classified as follows: 1. Non-RF resource failure during origination/termination 2. Non-RF resource failure during Hard Handoff.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Formulas Overall RF access failures ( (NORFSEFL + NRFSEFHH) for all sectors / Total calls attempted) x 100 Origination and termination RF access failure ( NORFSEFL for all sectors / (CAUOATTS + CAUPGRES + WPSRETRY + WPSTRTRY) for all sectors- (MCTPRSO + MCTPRST) for all freq;MCTA sectors) x 100 Hard handoff (HHO) RF access failure ( NRFSEFHH for all sectors / CAUHATTS for all sectors) x 100 The above formula evaluates the metric on a per system wide basis. However, when the metric is to be evaluated on a per sector basis, the CAUHATTS OM in the above formula is replaced with the CAUHINIT OM. For more information about how to use the above metrics based on call type (2G Voice or 3G Voice), see Call types (page -13). Miscellaneous packet data call failures For packet data call setup during origination, BSC resources are setup first followed by BTS resources and then R-P session is setup between PCU and PDSN. Mobile could successfully arrive on the traffic channel but the R-P session setup could fail due to lack of PDSN resources. This failure maybe reported at the CAU by the BSC/PCU after CAUOSUCC OM is pegged resulting in a call failure. For null-to-active scenario NARPFLAS OM gets pegged. The OMs captures RLP failures between mobile and PCU are pegged after RP session is setup. 3G packet data call failures (after call setup) due to RP session failures during null to active transition of a packet data call ( NARPFLAS for all sectors) / CAUOATTS for all sectors MIDTOAAT - MCTPRSO for all frequencies for all MCTA sectors) x100 3G packet data call failures (after call setup) due to RP session failures during dormant to active transition of a packet data call ( DARPFLAS for all sectors) / (MIDTOAAT + NIDTOAAT) x100 3G packet data call failures (after call setup) due to RP session failures during active handoff of a packet data call ( AHRPFLAS for all sectors) / ( CAUHATTS for all sectors) x100 In the above formula use the sum of each CAU* OMs from the CAUSCT3D, CAUXTF3D and CDMAPDOM OM groups. The MCTPRSO OM is subtracted in the above formula to account for the origination attempt that is
redirected by MCTA to the alternate CDMA band resulting in CAUOATTS being pegged twice in that event. It is also important to note that the above formula evaluates the metric on a per system wide basis. However, when the metric is to be evaluated on a per sector basis, MCTPRSO in the above formula is replaced with MCTPRRO. 3G packet data call failures (after call setup) due to RLP failures during null to active transition of a packet data call NARLPFL / ( CAUOATTS for all sectors - MIDTOAAT - MCTPRSO for all frequencies for all MCTA sectors) x100 3G packet data call failures (after call setup) due to RLP failures during dormant to active transition of a packet data call DARLPFL / (MIDTOAAT + NIDTOAAT) x100 3G packet data call failures (after call setup) due to RLP failures during active handoff of a packet data call AHRLPFL / ( CAUHATTS for all sectors) x100
Additional formulas
Voice call setup performance metrics on a per platform basis- (EBSC and BSC) These metric formulas measure the call setup failures and successes after resources have been successfully allocated on the EBSC (CSVS) and BSC (SBS) platforms. Call setup failures due to network related and RF related failures can be measured using these metrics. It is important to note that these metrics are only valid when NRM is the central resource manager in the system. Call setup failures due to network related failures Network related failures are Failures due to processing errors during communication between CAU and the selector element after successful resource allocation and before the radio link setup phase. Failures due to processing errors at the selector element during communication between CAU and EBSC after successful radio link setup and before successful call setup.
Percentage of call setup failures due to processing errors Call failures due to processing errors include CAU time-outs, software failures and resource mismatches at the selector element. Resource
411-2133-525
Standard
06.12
April 2008
Nortel Networks
availability status mismatch means that a resource is reserved for allocation by the NRM but is unavailable during CAU call setup request. on CSVS ( ECSESWFL for all CAUs / ECSVRASU for all CAUs) x 100 on SBS ( ESBESWFL for all CAUs / ESBSRASU for all CAUs) x 100 Percentage of call setup failures due to non-RF failures Non-RF failures include internal failures at the BSC like DSP initialization failures etc. on CSVS ( ECSNRSFL for all CAUs / ECSVRASU for all CAUs) x 100 on SBS ( ESBNRSFL for all CAUs / ESBSRASU for all CAUs) x 100 Call setup failures due to RF related failures on CSVS ( ECSERLFL for all CAUs / ECSVRASU for all CAUs) x 100 on SBS ( ESBERLFL for all CAUs / ESBSRASU for all CAUs) x 100 Call setup successes on CSVS ( ECSVCSS for all CAUs / Total calls attempted) x 100 on SBS ( ESBSCSS for all CAUs / Total calls attempted) x 100 MEID related metrics The following metrics at the MTX measure the penetration of MEID and ESN mobiles. They also track the number of MEID mobiles that do not respond to the status request message from the CAU to retrieve the MEID value. An MTXT139 log has been introduced at the MTX to track noncomplaint mobiles i.e., mobiles that send an SCM bit 4 = 1 and ESN field = true ESN and SCM bit 4 = 0, ESN field = pESN. Query to retrieve the MEID value of the mobile could fail due to the channel conditions, RF conditions or the mobile being unable to send the MEID in the status response message. To determine the root cause of the query failure, one should look at the Call Detail Records (CDRs) at the MTX to determine if this failure is related to mobiles that belong to particular manufacturer type.
CDMA
NBSS15.0
It is also important to note that there are no separate OMs for query failures as there no associated timers (no retries as a result) to track the query response. Percentage of calls made by MEID mobiles ((MEIDATTS + MEIDATT2 * 65536)/ Total calls attempted) x 100 Percentage of calls made by ESN mobiles ((ESNATTS + ESNATT2 * 65536) / Total calls attempted) x 100 Percentage of MEID query failures on the common channel ((MEIDQRCC - MEIDQSCC) / MEIDQRCC) x 100 Percentage of MEID query failures on the traffic channel ((MEIDQRTC - MEIDQSTC) / MEIDQRTC) x 100 The following metrics at the BSC measure the PLCM type (pESN, MEID, BS-Assigned) performance by tracking the PLCM collisions whenever there is a call setup failure or a call drop due to RF related reasons. The existing Call Summary Log has been modified to include the PLCM EBID collision bit map field, the PLCM type and the SCM. This will allow the customer to track the carrier-sector information in event of PLCM collision. These metrics help re-evaluate the choice of the PLCM type chosen for call setup in the SelectorSubsystemMO;PlcmTypeConfig. Optimal selection of a PLCM type will help reduce the call setup failures and call drops due to PLCM collisions. For more information, see Nortel CDMA Performance Management -- Operational Guidelines (411-2133-526). For example, if ESN_Preferred is the chosen PLCM type at the BSC and if there are call failures (RF related) due to pESN collisions, changing the choice of PLCM type to Allow_BS_Assigned or BS_Assigned_Preferred could lower the call failures. Percentage of call setup failures in the event of pESN PLCM collisions (PLCM_CallSetupFailuresPseudoESN / PLCM_CallSetupAttemptsPsuedoESN ) x 100 Percentage of call setup failures in the event of MEID PLCM collisions (PLCM_CallSetupFailuresMEID / PLCM_CallSetupAttemptsMEID) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Percentage of call setup failures in the event of BS-assigned PLCM collisions (PLCM_CallSetupFailuresBS_Assigned / PLCM_CallSetupAttemptsBS_Assigned) x 100 Percentage of call drops in the event of pESN PLCM collisions (PLCM_CallDropsPseudoESN / PLCM_CallSetupSuccessesPsuedoESN) x 100 Percentage of call drops in the event of MEID PLCM collisions (PLCM_CallDropsMEID / PLCM_CallSetupSuccessesMEID ) x 100 Percentage of call drops in the event of BS-assigned PLCM collisions (PLCM_CallDropsBS_Assigned / PLCM_CallSetupSuccessesBS_Assigned) x 100 Additional metrics Percentage of RF setup failures in the event of PLCM collisions (PLCM_CallSetupFailuresPseudoESN + PLCM_CallSetupFailuresMEID + PLCM_CallSetupFailuresBS_Assigned) / (CAUERLFL + CAUHRFL) for all sectors) x 100 Percentage of RF setup failures (in the event of non collision) when pESN is selected ((PLCM_CallSetupAttemptsPsuedoESN(PLCM_CallSetupFailuresPseudoESN + PLCM_CallSetupSuccessesPsuedoESN)/ PLCM_CallSetupAttemptsPsuedoESN ) x 100 The above metric tracks RF setup failures when there are no pESN collisions. This metric can be used to compare with the overall RF failure metric at the MTX (values should fairly stay the same). This will ensure that a particular PLCM type will have no impact on the RF part of the call setup (need to compare with metrics for other PLCM types). Similar metrics can be obtained for other PLCM types (MEID, BS_Assigned) VPAD (voice preemption of active data) voice call setup performance system level The following formulas are related to the preemption of active packet data sessions by incoming voice calls due to the VPAD feature: Overall active packet data call preemption due to VPAD feature Percentage of active packet data calls preempted by incoming voice call requests due to the VPAD feature is expressed as
( VPADIC for all sectors / (CAUOSUCC + CAUTSUCC + CAUHSUCC) for all sectors) x 100 The CAU* OMs in the above formula are from OM group CAUSCT3D.The above metric may also be applied on a per cluster or per BSC basis. Overall voice call setup failures related to VPAD feature Percentage of incoming voice setup requests that failed (for any reason, after the CM received a page response) during call setup is expressed as (VPADFL / VPADATT) x100 Global emergency call metrics When considering the GEC metrics that follow, it is important to remember that a GEC call is treated the same way as an ordinary mobile origination or 3WC with the exception of digits translation. The MTX-CM must receive the Origination or Flash with Information message in order for GEC digit translation to take place. GEC mobile user feature activation Percentage of GEC calls received by the CM is expressed by the following: (GECRCVD / (MBORIGS + TWCSTART)) x 100 Please refer to NTP 411-2131-814 for a description of OMMTX.MBORIGS and OMMTXSYS.TWCSTART. GEC feature usage Percentage of received GEC calls that use the translation to the emergency services number datafilled in MTX_GLOBAL_EMERGENCY_DIGITS is expressed by the following: (GECATTS / GECRCVD) x 100 If there are no digits datafilled in MTX_GLOBAL_EMERGENCY_DIGITS, then the value of this metric will be 0%. If digits are datafilled, it is expected that this metric should be 100%. If it is not, this indicates a translations or routing issue. GEC success rate Percentage of successful GEC calls is expressed by the following: (GECSUCC / GECATTS) x 100 The success rate of the GEC is dependent upon many different factors, not the least of which is that the number datafilled in Table OFCVAR may or may not be correct; there is no check made by the MTX that the number datafilled will translate correctly, or that it translates to an emergency services number. These metrics measure the performance of the GEC digits translation only -411-2133-525 Standard 06.12 April 2008
Nortel Networks
as the call is otherwise treated normally, it may block due to lack of resources, suffer an access failure, etc. These types of events are tracked by the existing call setup performance OMs described earlier in this chapter. Silent retry This metric will identify all the sectors that experience high percentage of silent retries in the system (could be due to poor RF conditions, etc.) Percentage of silent retries received by a sector is expressed by the following ratio: ((SRTDBORG + SLNTRTAF) / (CAUOATTS - SRTDBORG SLNTRTAF)) x 100 3G packet data Dormant-to-active transitions average rate for 3G packet data calls (MIDTOAAT + MIDTOAAX + NIDTOAAT + NIDTOAAX) / ((CAUOATTS + CAUHATTS) for all sectors - MCTPRSO for all frequencies for all MCTA sectors - MIDTOAAT - MIDTOAAX) x 100 Use OMs from the CAUSCT3D and CAUXTF3D OM groups in the above formula. Total original 3G packet data call attempts represent first time 3G data call attempts and do not include dormant to active transitions. The MCTPRSO OM is subtracted in the above formula accounting for origination attempts that get redirected by MCTA to the alternate CDMA band resulting in CAUOATTS OM being pegged twice in those events. Mobile-initiated dormant-to-active transition failure rate Percentage of mobile initiated dormant to active transition failures is expressed by the following ratio: ((MIDTOAFL + MIDTOAFX) / (MIDTOAAT + MIDTOAAX)) x 100 A high value of this metric may be due to resource blocking when attempting to setup the radio resources for the session, or due to the mobile not arriving on the traffic channel. Refer to the call setup failure OMs and metrics in this chapter for further details. Network-initiated dormant-to-active transition failure rate Percentage of network initiated dormant to active transition failures is expressed by the following ratio ((NIDTOAFL + NIDTOAFX) / (NIDTOAAT + NIDTOAAX)) x 100 A high value of this metric may be due to resource blocking when attempting to setup the radio resources for the session, due to the mobile not arriving on the traffic channel, or due to the mobile not responding to the page sent by the
network. Refer to the call setup failure OMs and metrics in this chapter and to the Paging Performance chapter in this guide for further details. In order to determine the failure rate due to specific reasons, replace the NIDTOAFL OM with one of the following OMs: NIFLNVLR, NIFLNSOP, NIFLMINA, NIFLPGTM, NIFLPGNG, NIFLVCLL, NIFLSRSP, NIFLCLFL, NIFLMRLS, NIFLAMPS. Please refer to chapter 21 for description of these OMs. Null-to-active transition failure rate Percentage of null to active transition failures is expressed by the following ratio: ((NULTOAFL + NULTOAFX) / (NULTOAAT + NULTOAAX) x 100 A high value of this metric may be due to resource blocking when attempting to setup the radio resources for the new data call, or due to the mobile not arriving on the traffic channel. Refer to the call setup failure OMs and metrics in this chapter for further details. Note that these OMs also get pegged when a dormant mobile hands off to a new MSC and attempts to transition to active before it sends a dormant handoff registration message (an Origination message with Data Ready to Send set to false). The target MSC cannot tell the difference between this type of transition and a new call. RLP session setup failures Percentage of RLP failed session setups is expressed by the following ratio: (RLPSetupFailures / RLPSetupAttempts) x 100 When the mobile is attempting to transition from dormant to null via a Release Order with order qualifier of Service Inactive on the traffic channel, there is a possibility that the message may be received before RLP setup is complete. In this case, the RLPSetupFailures OM is pegged, but does not indicate a problem with either the mobile or the network; the call is released before RLP synchronization is completed. Closed R-P metrics R-P packet session setup failures (TotalSessionSetupFailures / (TotalSessionSetupInitialAttempts + TotalSessionReconnectAttempts)) x100 R-P packet session initial setup failures (TotalInitialRPSessionSetupFailures / RP_SessionSetupAttempts for all PDSNs) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
R-P packet session initial setup not completed due to mobile releasing the call (TotalReleasesBeforeInitialSessionSetup / RP_SessionSetupAttempts for all PDSNs) x 100 R-P packet session initial setup average hop count (RP_SessionSetupRejectReasonGenErr + RP_SessionSetupRejectReasonNoCarrier + RP_SessionSetupRejectReasonAdminReason + RP_SessionSetupRejectReasonNoTempRsrcs + RP_SessionSetupRejectReasonNoPermRsrcs + RP_SessionSetupRejectReasonSysOverload + RP_SessionSetupRejectReasonOther + RP_SessionSetupRejectReasonNoPDSNRsp ) for all PDSNs / (RP_SessionSetupAttempts) for all PDSNs x 100 R-P packet session primary to primary PDSN transitions per initial attempt (RP_SessionSetupRejectReasonGenErr + RP_SessionSetupRejectReasonNoCarrier + RP_SessionSetupRejectReasonAdminReason + RP_SessionSetupRejectReasonNoTempRsrcs + RP_SessionSetupRejectReasonNoPermRsrcs + RP_SessionSetupRejectReasonSysOverload + RP_SessionSetupRejectReasonOther + RP_SessionSetupRejectReasonNoPDSNRsp) for all primary PDSNs (RP_SessionSetupAttempts) for all primary PDSNs + (RP_SessionSetupSuccesses) for all primary PDSNs / (RP_SessionSetupAttempts) for all primary PDSNs x 100 R-P packet session primary to secondary PDSN transitions ( (RP_SessionSetupAttempts) for all primary PDSNs - (RP_SessionSetupSuccesses) for all primary PDSNs if applicable / (RP_SessionSetupAttempts) for all primary PDSNs) x 100 R-P packet session secondary to secondary PDSN transitions ( (RP_SessionSetupRejectReasonGenErr + RP_SessionSetupRejectReasonNoCarrier + RP_SessionSetupRejectReasonAdminReason + RP_SessionSetupRejectReasonNoTempRsrcs + RP_SessionSetupRejectReasonNoPermRsrcs + RP_SessionSetupRejectReasonSysOverload + RP_SessionSetupRejectReasonOther + RP_SessionSetupRejectReasonNoPDSNRsp) for all secondary PDSNs
CDMA
NBSS15.0
- TotalInitialRPSessionSetupFailures / (RP_SessionSetupAttempts) for all primary PDSNs) x 100 R-P packet session handoff setup failures (TotalRPSessionHandoffFailures / TotalSessionSetupReconnectAttempts) x 100 R-P Packet Session Handoff Setup not Completed due to Mobile Releasing the Call (TotalReleasesBeforeHandoffSessionSetup / TotalSessionSetupReconnectAttempts) x 100 OpenRP Metrics Initial R-P session setup failure rate per PCU (TotalInitialRPSessionSetupFailures / TotalInitialRP_SessionSetupAttempts for all PDSNs) x 100 R-P session handoff failure rate per PCU (TotalRPSessionHandoffFailures / TotalRP_SessionHandoffAttempts for all PDSNs) x 100 Average Dormant to Active transaction rate in one second per PCU is expressed by the following ratio NumberOfDormantCallsGoingActive / 1800 (30 minute OM period) Average number of PDSN hops per an Initial R-P session setup per PCU is expressed by the following ratio: (TotalInitialRP_SessionSetupRejectReasonOther + TotalInitialRP_SessionSetupRejectReasonIdMismatch + TotalInitialRP_SessionSetupRejectReasonInsufficientResources + TotalInitialRP_SessionSetupRejectReasonMobileAuthFailure + TotalInitialRP_SessionSetupFailuresReasonPDSN_NotResponding) for all PDSNs / TotalInitialRP_SessionSetupAttempts for all PDSNs x 100 If value provided by this metric is zero then there were no PDSN rejections for session setups. If value provided by this metric is equal to the number of PDSNs this PCU is connected to then all session setups were rejected by all the PDSNs. Average number of PDSN hop for a R-P session handoff per PCU is expressed by the following ratio: (TotalRP_SessionHandoffRejectReasonOther + TotalRP_SessionHandoffRejectReasonIdMismatch + TotalRP_SessionHandoffRejectReasonInsufficientResources + TotalRP_SessionHandoffSetupRejectReasonMobileAuthFailure +
411-2133-525 Standard 06.12 April 2008
Nortel Networks
TotalRP_SessionHandoffFailuresReasonPDSN_NotResponding) for all PDSNs / TotalRP_SessionHandoffAttempts for all PDSNs x 100 If value provided by this metric is zero then there were no PDSN session setup rejections. If value provided by this metric is equal to the number of PDSNs this PCU is connected to then all session setups were rejected by all the PDSNs. Percentage of PCU initiated R-P sessions releases for normal release per PDSN is expressed by the following ratio: PCU_InitiatedSessionReleasePacketSessionDisconnect / (PCU_InitiatedSessionReleasePacketSessionDisconnect + PCU_InitiatedSessionReleasePacketSessionDrop + PCU_InitiatedSessionReleasePDSN_Reject) x 100 Percentage of PCU initiated R-P sessions release due to packet session drop per PDSN is expressed by the following ratio: PCU_InitiatedSessionReleasePacketSessionDrop / (PCU_InitiatedSessionReleasePacketSessionDisconnect + PCU_InitiatedSessionReleasePacketSessionDrop + PCU_InitiatedSessionRelleasePDSN_Reject) x 100 Percentage of PCU initiated R-P session release due to PDSN reject per PDSN is expressed by the following ratio: PCU_InitiatedSessionReleasePDSN_Reject / (PCU_InitiatedSessionReleasePacketSessionDisconnect + PCU_InitiatedSessionReleasePacketSessionDrop + PCU_InitiatedSessionRelleasePDSN_Reject) x 100 Percentage of registration request messages rejected for miscellaneous reasons per PDSN is expressed by the following ratio: TotalRegistrationRequestReasonOther / (TotalRegistrationRequestMsgSent + TotalRegistrationRequestRetries) x 100 Percentage of registration request messages rejected for ID mismatch per PDSN is expressed by the following ratio: TotalRegistrationRequestReasonIdMismatch / (TotalRegistrationRequestMsgSent + TotalRegistrationRequestRetries) x 100
CDMA
NBSS15.0
Percentage of registration request messages rejected for insufficient resources per PDSN is expressed by the following ratio: (TotalRegistrationRequestReason InsufficientResources / (TotalRegistrationRequestMsgSent + TotalRegistrationRequestRetries)) x 100 Percentage of registration request messages rejected for mobile authentication failure per PDSN is expressed by the following ratio: (TotalRegistrationRequestReasonMobileAuthFailure / (TotalRegistrationRequestMsgSent + TotalRegistrationRequestRetries)) x 100 Percentage of registration request messages rejected for PDSN not responding per PDSN is expressed by the following ratio: (TotalRegistrationRequestReasonPDSN_NotResponding / (TotalRegistrationRequestMsgSent + TotalRegistrationRequestRetries)) x 100 Registration request retry rate per PDSN is expressed by the following ratio: (TotalRegistrationRequestRetries / TotalRegistrationRequestMsgSent) x 100 Percentage of PCU allocation request failures per PCU manager (for CPDS platform) is expressed by the following ratio: (PCU_AllocFailures / PCU_AllocRequests) x 100 Percentage of PCU allocation request failures due to IMSI table is full out of all PCU allocation failures per PCU Manager (for CPDS platform) is expressed by the following ratio: (IMSI_TableFull / PCU_AllocFailures) x 100
Validation
Since a call setup may span the OM period, a slight discrepancy may be possible in these sections.
For all call types together or 2G-only systems A validation formula for call setup performance is to sum all successful originations and terminations, all origination and termination setup failures, all of the originations that are aborted normally (originations given MOBRODR or MOBICPT treatment), all originations and terminations that are released during setup by the originating party, and all of the originations and terminations that fail to arrive on the traffic channel. That number should
411-2133-525 Standard 06.12 April 2008
Nortel Networks
equal the number of origination and termination attempts. The formula can be summarized into: Attempts = Successes + Non-Successes; where Attempts = (CAUOATTS + CAUPGRES + CAUHATTS + WPSRETRY + WPSTRTRY) for all sectors- (MCTPRSO + MCTPRST) for all frequencies for all sectors Successes = (CAUOSUCC + CAUTSUCC + CAUHSUCC) for all sectors Non-successes = CAUOBLKS + CAUTBLKS + CAUHBLKS + CAUORLS + CAUTRLS + CAUHRLS + CAUORODR + CAUERLFL + CAUHRLFL + MISCFLT + NORFSEFL + NRFSEFHH + NWKFLBS - (WQTOUT + WQOVFL + WINVALDQ) for all sectorsMCTPRSO - MCTPRST + MCTPRRO + MCTPRRT for all frequencies for all sectors For Voice calls use the sum of the CAU* OMs from OM groups CAUCPSCT, CAUSCT2, CAUSCT3V, CAUST3V2 and use the sum of the MCT* OMs from OM groups CAUCPFRQ, CAUFRQ3V, CAUXTFRQ CAUXTF3V as well as the WPSOM1 group. For Packet Data Calls use the sum of the CAU* OMs from the OM groups CAUSCT3D, CAUST3D2 and use the sum of the MCT* OMs from the CAUFRQ3D, CAUXTF3D as well as the MTXPDSCT OM group. Silent retry OMs validation SLNTRTAF = SLNTRT2G + SLNTRT3V + SLNTRT3D SRTDBORG = SRTDBO2G + SRTDBO3V + SRTDBO3D Blocking OMs validation All of the CAU*BLKS OMs can be summed together and should equal the sum of the all the failure reasons for Voice and Packet Data call types. Voice and packet data call types validation System where NRM is Resource manager Blocks = Failures; where Blocks =
CDMA
NBSS15.0
CAUOBLKS + CAUTBLKS + CAUHBLKS for all sectors Failures = (NRMANRV + NRMATOV + NRMOEV + NRMOLRV + NRMSTOV + NRMANRPD + NRMATOPD + NRMOEPD + NRMOLRPD + NRMSTOPD) for all CAUs + (CAUERSFL + CAUESWFL) for all sectors CAU sheds resource allocation requests during CNFP overload condition and pegs CAUOBLKS or CAUTBLKS. In this event, allocation request is not sent to NRM, so no OM from the EBSCRM OM group (Right hand side) pegs. The following Block OMs during NRM overload condition should be subtracted form Left hand side to make the above formula correct: DCORGVC + DCORGVC2 + DCORGPD + DCORGPD2 + DCPGRVC + DCPGRVC2 + DCGRPD + DCGRPD2. For more information about OM descriptions for these OMs, see CDMA/TDMA Operational Measurements Reference Manual (411-2131-814). System where RMU is Resource manager Blocks = Failures; where Blocks = CAUOBLKS + CAUTBLKS + CAUHBLKS for all sectors Failures = (RMURANRV + RMUIANRV - RMURARV + RMUIOENV + RMURAOEV + RMUIATOV + RMURATOV + RMURANRD + RMUIANRD - RMURARD + RMUIOEND + RMURAOED + RMUIATOD + RMURATOD) for all CAUs + (CAUERSFL + CAUESWFL) for all sectors CAU sheds resource allocation requests during RMU overload condition and pegs CAUOBLKS or CAUTBLKS. In this event, allocation request is not sent to RMU, so no OM from BSCRM OM group (Right hand side of formula) pegs. The following Block OMs during NRM overload condition should be subtracted form Left hand side to make the above formula correct: ORIGDIS + ORIGDIS2 + PGRSDIS + PGRSDIS2 + PDOGDIS + PDOGDIS2 + PDTMDIS + PDTMDIS2. For more information about OM descriptions for these OMs, see CDMA/TDMA Operational Measurements Reference Manual (411-2131-814). Blocking validation for Voice calls and packet data calls separately can also be derived using the OMs from the above formulas appropriately. Validation for voice call setup performance OMs (per platform basis)
411-2133-525
Standard
06.12
April 2008
Nortel Networks
(ESBESWFL + ECSESWFL) for all CAUs <= CAUESWFL for all sectors The inequality in the above formula is because CAUESWFL OM also pegs for processing errors between the CAU and CM. (ESBNRSFL + ECSNRSFL) for all CAUs = (NORFSEFL + NRFSEFHH) for all sectors (ECSERLFL + ESBERLFL) for all CAUs = (CAUERLFL + CAUHRLFL) for all sectors (ECSVCSS + ESBSCSS) for all CAUs = (CAUOSUCC + CAUTSUCC+ CAUHSUCC) for all sectors Validation for MEID OMs MEIDATTS + ESNATTS = (CAUOATTS + CAUPGRES + CAUHATTS) for all sectors Validation for 3G packet data OMs Validation for R-P Packet Session Setup OMs Attempts = Successes + Failures; where Attempts = TotalSessionSetupInitialAttempts + TotalSessionSetupReconnectAttempts Successes = TotalSessionSetupSuccess Failures = TotalSessionSetupFailures Validation of RLP OMs Attempts = Successes + Failures RLPSetupAttempts = RLPSetupSuccesses + RLPSetupFailures Validation of dormant-to-active and null-to-active OMs Attempts = Successes + Failures MIDTOAAT = MIDTOASU + MIDTOAFL NIDTOAAT = NIDTOASU + NIDTOAFL NULTOAAT= NULTOASU + NULTOAFL Validation of VPAD OMs Attempts = Successes + Failures VPADATT = VPADSUC + VPADFL Additional validation of HHO OMs CAUHINIT = CAUHSUCC + CAUHRLFL For 2G HHO attempts In the above formula, use the CAU* OMs from the CAUCPSCT OM group.
CDMA
NBSS15.0
For 3G voice HHO attempts In the above formula, use the CAU* OMs from the CAUSCT3V OM group. For 3G packet data HHO attempts In the above formula, use the CAU* OMs from the CAUSCT3D OM group. Validation of close RP OMs For the following formulas, use all the OMs from a PCU on SBS. The following formulas are per PCU based. TotalSessionSetupInitialAttempts = RP_SessionSetupAttempts for all PDSNs TotalSessionSetupFailures = TotalInitialRPSessionSetupFailures + TotalRPSessionHandoffFailures RP_SessionSetupAttempts for all PDSNs = RP_SessionSetupSuccesses for all PDSN + TotalInitialRPSessionSetupFailures for a PCU Validation of open RP OMs For the following formulas, use all the OMs from a PCU (of the PCUFP card) on CPDS. The following formulas are per PCU based. TotalInitialRP_SessionSetupAttempts for all PDSNs = (TotalInitialRP_SessionSetupSuccesses for all PDSNs + TotalInitialRPSessionSetupFailures for a PCU TotalSessionSetupInitialAttempts = TotalInitialRPsessionSetupAttempts for all PDSNs TotalRP_SessionHandoffAttempts for all PDSNs = (TotalRP_SessionHandoffSuccesses for all PDSN + TotalRPSessionHandoffFailures for a PCU) TotalSessionSetupReconnectAttempts = TotalRP_SessionHandoffAttempts for all PDSNs TotalSessionSetupSuccess = TotalInitialRP_SessionSetupSuccesses TotalRP_SessionHandoffSuccesses) for all PDSNs TotalSessionSetupFailures = (TotalInitialRPSessionSetupFailures for a PCU + TotalRPSessionHandoffFailures for a PCU) Validation for PCU manager OMs PcuAllocRequests = PcuAllocSuccessful + PcuAllocFailures
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Recommendations
Overall, the call setup failure percentages for each of the Origination, Termination and Hard handoff types of call setups should be very close to each other since there is no special processing done to prioritize resources for origination over hard handoff. The following sections list OMs that can indicate the need for an adjustment and at least one possible adjustment.
CAUOBLKS Occurrences
of this OM indicate that origination call setups are failing due to lack of resource reasons. Any time this OM is pegged, the CAU... OMs (except for CAUERLFL) and RM... OMs described below should be reviewed.
CAUTBLKS - Occurrences of this OM indicate that termination call setups are failing. Any time this OM is pegged, the CAU... OMs (except for CAUERLFL) and RM... OMs described below should be reviewed.
Occurrences of this OM indicate that handoffs are failing. Any time this OM is pegged, the CAU... OMs (except for CAUHRLFL) and RM... OMs described below should be reviewed.
CAUHBLKS -
Occurrences of this OM indicate that BTS resources may be causing call setups to fail. To ascertain the reason consult the CAUNOTCE, CAUNOWCD, CAUFWCAP and SCTBTSBK OMs. CAUERSFL is also pegged if any of the software entities on the BTS do not respond to resource requests during call setup.
CAUERSFL CAUNOTCE - Occurrences of this OM indicate that the BTS channel elements
may be under-provisioned. The lack of traffic channel elements (TCEs) can be verified by consulting the BTS Performance Attribute TCEUtilMaximum in AFA MO (Advanced Frequency Assignment Managed Object) in the case of Metro Cell BTS, and/or the BTS Performance Attributes Fch2GMaximumForwardPhysicalResourcesUsed, Fch3GMaximumForwardPhysicalResourcesUsed, SchMaximumForwardPhysicalResourcesUsed, Fch2GMaximumReversePhysicalResourcesUsed, Fch3GMaximumReversePhysicalResourcesUsed, SchMaximumReversePhysicalResourcesUsed in AFA MO (Advanced Frequency Assignment Managed Object). If the number of TCEs in use is close to the maximum number, another channel card should be provisioned at the BTS. Note that TCEUtilMaximum applies only to CCEM resources while all the other BTS performance attributes mentioned above apply only to XCEM resources.
CAUNOWCD - Occurrences of this OM indicate that the BTS is running out of
walsh codes. Since these are reused per frequency, per sector, per BTS. this OM should never be pegged under the current limitation of three carriers supported.
CAUFWCAP - Occurrences of this OM indicate that the BTS is running out of
capacity on the forward link. Deployment of additional carriers or six sectors should be considered. - Occurrences of this OM indicate that the BTS is experiencing a shortage in one of the following resources: T1E1 backhaul resources, BCN link resources, or ACN node IDs. It is recommended to look at the BTS-level EBID-based BTS blocking OMs to isolate which of these resources is causing the blocking condition (for example, BlockedFchOriginations2G, etc.). Provisioning of additional BTS resources may be indicated.
SCTBTSBK BAMERLFL, BAMSBSFL, BAMSCSFL - Occurrences
of this OM indicate possible RF problems for mobiles on the BAM channel, similar to SAT/ DVCC timeout in an AMPS or TDMA system. Contact Nortel Field Support. CLFL 101 cell trouble logs are printed in conjunction with this OM and provide information about the mobile whose call was dropped so that possible mobile unit problems can be investigated.
CAUERLFL -
Occurrences of this OM indicate possible RF problems, similar to SAT/DVCC timeout in an AMPS or TDMA system. Contact Nortel Field Support. CLFL 101 cell trouble logs are printed in conjunction with this OM and provide information about the mobile whose call was dropped so that possible mobile unit problems can be investigated.
- Occurrences of this OM indicate that call setup failed due to timeouts between software entities. The only recommendation here is to check CAU and/or CM CPU occupancy and verify that it is within tolerable levels. This type of timeout event is an error condition and should not happen.
CAUESWFL
- Occurrences of this OM indicate possible RF problems, similar to SAT/DVCC timeout in an AMPS or TDMA system. Contact Nortel Field Support. CLFL 102 mobile ho failure logs are printed on the target sectors CM in conjunction with this OM and provide information about the mobile whose call was dropped so that possible mobile unit problems can be investigated. This case is especially important because the subscriber will have already been in an established call and because it may indicate problems with the hard handoff target selection datafill. This OM is different than CAUHBLKS because it indicates a dropped call rather than a hard handoff attempt failure.
CAUHRLFL CAUUNSO
- Occurrences of this OM indicate that mobiles are requesting unsupported services. This OM gives the service provider a mechanism to track the necessity of providing new service options. CM notes If there are no in-service circuits for routing the call to the PSTN from the MTX, a single, system-wide OM, TRSGNCT from the TRMTRS group, is
06.12 April 2008
411-2133-525
Standard
Nortel Networks
pegged. It indicates that a GNCT (generalized no circuit) treatment was set when routing. This OM normally reflects performance problems during mobile originated calls. This OM is discussed here because CDMA call setup can fail due to no available PSTN circuits. Unfortunately, the TRSGNCT OM is not an exclusive measure for CDMA calls. Many other call processing scenarios peg this OM, including calls from AMPS and TDMA cell-sites. For this reason, the TRSGNCT OM is not included in the CDMA call setup metric calculation in this document. DTC notes Since the circuits between the SBS and the DTC are provisioned at 100%, no resource blocking is possible at that location. BTS notes The BTS is responsible for maintaining its available resources. Failures to allocate resources are communicated to the SBS and to the CAU via messaging. Those failures are recorded at the CAU via CAUERSFL and the appropriate CAU*BLKS OMs.
CDMA
NBSS15.0
411-2133-525
Standard
06.12
April 2008
Nortel Networks
1xRTT packet data performance
This chapters contains metrics useful for determining SCH Burst setup performance and SCH Link Setup performance. It also provides other metrics of interest to determine R-P link performance between PCU and PDSN. Some of the metrics for SCH Burst setup are also useful to determine how BSC Fair Share algorithm benefits allocation of BSC resources for SCHs.
List of OMs
For more information about OMs, see BSC OM descriptions (page 22-1).
1xRTT packet data performance OM descriptions BSC OMs SCH Burst Setup OM group FwdBurstSetupAttempts RevBurstSetupSuccess es FwdBurstBSC_Downgra de FwdBurstDelayIndex_3 RevBurstDelayIndex_2 FwdBurstSetupAttempts _2X FwdBurstSetupSuccess es_2X FwdBurstSetupSucces ses RevBurstSetupFailure s FwdBurstBSC_NonDo wngrade RevBurstBSC_Downgr ade RevBurstDelayIndex_ 3 FwdBurstSetupAttemp ts_4X FwdBurstSetupSucces ses_4X FwdBurstSetupAttemp ts_8X FwdBurstSetupSucces ses_8X FwdBurstDelayIndex_ 1 RevBurstBSC_NonDo wngrade FwdBurstDelayIndex _2 RevBurstDelayIndex _1 FwdBurstSetupFailure s
RevBurstSetupAttem pts
FwdBurstSetupAttem pts_16X FwdBurstSetupSucc esses_16X
sheet 1 of 7
CDMA
NBSS15.0
3-2 1xRTT packet data performance Nortel Networks 1xRTT packet data performance OM descriptions (continued) BSC OMs FwdBurstSetupFailures _2X RevBurstSetupAttempts _2X RevBurstSetupSuccess es_2X RevBurstSetupFailures_ 2X FwdBurstDowngrade_4 X_To_2X FwdBurstDowngrade_1 6X_To_4X FwdBurstNonDowngrad e_8X RevBurstDowngrade_8 X_To_4X RevBurstNonDowngrad e_2X FwdBurstUpgradeAttem pts_2X_To_4X FwdBurstUpgradeAttem pts_4X_To_16X FwdBurstUpgradeSucce sses_2X_To_16X FwdBurstUpgradeFailur es_2X_To_4X FwdBurstUpgradeFailur es_4X_To_16X FwdBurstDowngradeCh ange_8X_To_4X FwdBurstNonDowngrad eChange_8X FwdBurstSetupFailure s_4X RevBurstSetupAttempt s_4X RevBurstSetupSucces ses_4X RevBurstSetupFailure s_4X FwdBurstDowngrade_ 8X_To_2X FwdBurstDowngrade_ 16X_To_8X FwdBurstNonDowngra de_16X RevBurstDowngrade_ 16X_To_2X RevBurstNonDowngra de_4X FwdBurstUpgradeAtte mpts_2X_To_8X FwdBurstUpgradeAtte mpts_8X_To_16X FwdBurstUpgradeSuc cesses_4X_To_8X FwdBurstUpgradeFail ures_2X_To_8X FwdBurstUpgradeFail ures_8X_To_16X FwdBurstDowngradeC hange_16X_To_4X FwdBurstNonDowngra deChange_16X
sheet 2 of 7
FwdBurstSetupFailure s_8X RevBurstSetupAttempt s_8X RevBurstSetupSucces ses_8X RevBurstSetupFailure s_8X FwdBurstDowngrade_ 8X_To_4X FwdBurstNonDowngra de_2X RevBurstDowngrade_ 4X_To_2X RevBurstDowngrade_ 16X_To_4X RevBurstNonDowngra de_8X FwdBurstUpgradeAtte mpts_2X_To_16X FwdBurstUpgradeSuc cesses_2X_To_4X FwdBurstUpgradeSuc cesses_4X_To_16X FwdBurstUpgradeFail ures_2X_To_16X FwdBurstBSC_Downg radeChange FwdBurstDowngradeC hange_16X_To_8X
FwdBurstSetupFailur es_16X RevBurstSetupAttem pts_16X RevBurstSetupSucc esses_16X RevBurstSetupFailur es_16X FwdBurstDowngrade _16X_To_2X FwdBurstNonDowng rade_4X RevBurstDowngrade _8X_To_2X RevBurstDowngrade _16X_To_8X RevBurstNonDowngr ade_16X FwdBurstUpgradeAtt empts_4X_To_8X FwdBurstUpgradeSu ccesses_2X_To_8X FwdBurstUpgradeSu ccesses_8X_To_16X FwdBurstUpgradeFai lures_4X_To_8X FwdBurstBSC_NonD owngradeChange FwdBurstNonDowng radeChange_4X
411-2133-525
Standard
06.12
April 2008
Nortel Networks
1xRTT packet data performance 3-3 Copyright 2008 Nortel Networks
1xRTT packet data performance OM descriptions (continued) BSC OMs
SCH Burst Release OM group FwdBurstBSC_Release _2X RevBurstBSC_Release _2X FwdBurstBTS_PilotRele ase_2X RevBurstBTS_PilotRele ase_2X FwdBurstBSC_Releas e_4X RevBurstBSC_Releas e_4X FwdBurstBTS_PilotRel ease_4X RevBurstBTS_PilotRel ease_4X FwdBurstBSC_Releas e_8X RevBurstBSC_Releas e_8X FwdBurstBTS_PilotRel ease_8X RevBurstBTS_PilotRel ease_8X FwdBurstBSC_Relea se_16X RevBurstBSC_Relea se_16X FwdBurstBTS_PilotR elease_16X RevBurstBTS_PilotR elease_16X
SCH Primary Radio Link Setup OM group FSCHLinkSetupAttempt FSCHLinkSetupBlock FSCHLinkDowngrade FSCHLinkSetupSuccess FSCHNoPhysRes
FSCHRadioLinkAccessFailure FSCHNoFrameOffset
FSCHNoFwdPower
FSCHNoWalshCode
FSCHTimeout
RSCHLinkSetupAttempt RSCHRadioLinkAccessFailure RSCHTimeout
RSCHLinkSetupBlock RSCH_CFDS_HighS peed FSCHLinkSetupAtte mpts_2X FSCHLinkSetupBloc k_2X FSCHLinkSetupSucc ess_2X FSCHRadioLinkAcce ssFailure_2X RSCHLinkSetupAtte mpts_2X
RSCHLinkDowngrade
RSCHLinkSetupSuccess RSCHNoFrameOffset
RSCHNoPhysRes
FSCHLinkSetupAttempt s_4X FSCHLinkSetupBlock_4 X FSCHLinkSetupSucces s_4X FSCHRadioLinkAccess Failure_4X
FSCHLinkSetupAttem pts_8X FSCHLinkSetupBlock_ 8X FSCHLinkSetupSucce ss_8X FSCHRadioLinkAcces sFailure_8X
FSCHLinkSetupAttem pts_16X FSCHLinkSetupBlock_ 16X FSCHLinkSetupSucce ss_16X FSCHRadioLinkAcces sFailure_16X
sheet 3 of 7
CDMA
NBSS15.0
3-4 1xRTT packet data performance Nortel Networks 1xRTT packet data performance OM descriptions (continued) BSC OMs RSCHLinkSetupAttempt s_4X RSCHLinkSetupBlock_4 X RSCHLinkSetupSucces s_4X RSCHRadioLinkAccess Failure_4X SCHDrop_2X FSCHLinkSetupAttempt s_Change_4X FSCHBCNLinkExhaustion RSCHLinkSetupAttem pts_8X RSCHLinkSetupBlock _8X RSCHLinkSetupSucce ss_8X RSCHRadioLinkAcces sFailure_8X SCHDrop_4X FSCHLinkSetupAttem pts_Change_8X FSCHAcnIdExhaustion
RSCHLinkSetupAttem pts_16X RSCHLinkSetupBlock _16X RSCHLinkSetupSucce ss_16X RSCHRadioLinkAcces sFailure_16X SCHDrop_8X FSCHLinkSetupAttem pts_Change_16X FSCHDowngradePow erReqChange_16X_T o_8X FSCHDowngradePow erReqChange_8X_To _2X
RSCHLinkSetupBloc k_2X RSCHLinkSetupSuc cess_2X RSCHRadioLinkAcc essFailure_2X SCHDrop
SCHDrop_16X FSCHBackHaulExhaustion FSCHDowngradePo werReqChange_16X _To_4X FSCHDowngradePo werReqChange_4X_ To_2X
FSCHDowngradePower ReqChange_16X_To_2 X FSCHLinkSetupBlockS W_Error
FSCHDowngradePow erReqChange_8X_To _4X RSCHLinkSetupBlock SW_Error
SCH Handoff Radio Link Setup OM group SHO_FSCHLinkSetupAt tempt SHO_FSCHLinkSetup Block SHO_FSCHLinkSetup Success SHO_FSCHRadioLin kAccessFailure
SHO_FSCHNoFwdPow er SHO_FSCHTimeout
SHO_FSCHNoWalsh Code SHO_RSCHLinkSetup Attempt SHO_RSCH_CFDS_H ighSpeed
SHO_FSCHNoPhysR es SHO_RSCHLinkSetup Block SHO_RSCHNoPhysR es
SHO_FSCHNoFram eOffset SHO_RSCHLinkSetu pSuccess SHO_RSCHNoFram eOffset
SHO_RSCHRadioLinkA ccessFailure
sheet 4 of 7
411-2133-525
Standard
06.12
April 2008
Nortel Networks
1xRTT packet data performance OM descriptions (continued) BSC OMs SHO_RSCHTimeout SHO_FSCHLinkSetup Attempts_2X SHO_FSCHLinkSetup Attempts_4X SHO_FSCHLinkSetu pAttempts_8X
SHO_FSCHLinkSetupAt tempts_16X
SHO_FSCHLinkSetup Block_2X
SHO_FSCHLinkSetup Block_4X
SHO_FSCHLinkSetu pBlock_8X
SHO_FSCHLinkSetupBl ock_16X SHO_FSCHLinkSetupS uccess_16X
SHO_FSCHLinkSetup Success_2X SHO_FSCHRadioLink AccessFailure_2X
SHO_FSCHLinkSetup Success_4X SHO_FSCHRadioLink AccessFailure_4X
SHO_FSCHLinkSetu pSuccess_8X SHO_FSCHRadioLin kAccessFailure_8X
SHO_FSCHRadioLinkA ccessFailure_16X
SHO_RSCHLinkSetup Attempts_2X
SHO_RSCHLinkSetup Attempts_4X
SHO_RSCHLinkSetu pAttempts_8X
SHO_RSCHLinkSetupA ttempts_16X
SHO_RSCHLinkSetup Block_2X
SHO_RSCHLinkSetup Block_4X
SHO_RSCHLinkSetu pBlock_8X
SHO_RSCHLinkSetupBl ock_16X SHO_RSCHLinkSetupS uccess_16X
SHO_RSCHLinkSetup Success_2X SHO_RSCHRadioLink AccessFailure_2X
SHO_RSCHLinkSetup Success_4X SHO_RSCHRadioLink AccessFailure_4X
SHO_RSCHLinkSetu pSuccess_8X SHO_RSCHRadioLi nkAccessFailure_8X
SHO_RSCHRadioLinkA ccessFailure_16X
SHO_FSCHBackHaul Exhaustion
SHO_FSCHBCNLinkE xhaustion
SHO_FSCHAcnIdEx haustion
SHO_FSCHLinkSetupBl ockSW_Error
SHO_RSCHLinkSetup BlockSW_Error
SCH Radio Link Release OM group FSCH_RequestRetract_ 2X FSCH_RequestRetrac t_4X FSCH_RequestRetrac t_8X FSCH_RequestRetra ct_16X
sheet 5 of 7
CDMA
NBSS15.0
3-6 1xRTT packet data performance Nortel Networks 1xRTT packet data performance OM descriptions (continued) BSC OMs FSCH_BTS_Release_2 X RSCH_BTS_Release_2 X FSCH_PilotRelease_2X RSCH_PilotRelease_2X FSCH_UpgradeRelease _2X_To_4X FSCH_UpgradeRelease _4X_To_16X FSCH_BTS_Release_ 4X RSCH_BTS_Release_ 4X FSCH_PilotRelease_4 X RSCH_PilotRelease_4 X FSCH_UpgradeRelea se_2X_To_8X FSCH_UpgradeRelea se_8X_To_16X
FSCH_BTS_Release_ 8X RSCH_BTS_Release_ 8X FSCH_PilotRelease_8 X RSCH_PilotRelease_8 X FSCH_UpgradeRelea se_2X_To_16X
FSCH_BTS_Release _16X RSCH_BTS_Releas e_16X FSCH_PilotRelease_ 16X RSCH_PilotRelease _16X FSCH_UpgradeRele ase_4X_To_8X
Packet Session Data OM group TotalFwdPacketsDropp ed RRBufferOverflows TotalRevPacketsDrop ped DCRBufferOverflows DCRNumOfStopTran smitMsgsSent
RP Session L2TP OM group ReliablePacketSentSuc cess TotalUnreliableBytesTra nsmitted ReliablePacketReTran smitted TotalUnreliableBytesR eceived ReliablePacketReceiv ed NumberOfTunnelFail ures
PCU Queue Occupancy OM group DormantDCR_QueueAt D2A_10 DormantDCR_QueueAt D2A_50 DormantDCR_Queue AtD2A_20 DormantDCR_Queue AtD2A_60 DormantDCR_Queue AtD2A_30 DormantDCR_Queue AtD2A_70 DormantDCR_Queu eAtD2A_40 DormantDCR_Queu eAtD2A_80
sheet 6 of 7
411-2133-525
Standard
06.12
April 2008
Nortel Networks
1xRTT packet data performance OM descriptions (continued) BSC OMs DormantDCR_QueueAt D2A_90 PeakActiveRR_QueueD epth DormantDCR_Queue AtD2A_100 AvgActiveRR_QueueD epth PeakActiveDCR_Queu eDepth AvgActiveDCR_Que ueDepth
Selection and Distribution Unit Queue Occupancy OM group FwdRLPQ_BurstReque stDepth_1 FwdRLPQ_BurstReque stDepth_5 FwdRLPQ_BurstReque stDepth_9 FwdRLPQ_BurstReque stDepth_13 FwdRLPQ_BurstReque stDepth_17 FwdRLPQ_BurstReque stDepth_21 FwdRLPQ_BurstReque stDepth_25
FwdRLPQ_SCH_BurstAvg Depth_16x RevRLPQ_SCH_BurstAvg Depth_16x FwdRLPQ_SCH_BurstPea kDepth_16x RevRLPQ_SCH_BurstPea kDepth_16x
end sheet 7 of 7
FwdRLPQ_BurstRequ estDepth_2 FwdRLPQ_BurstRequ estDepth_6 FwdRLPQ_BurstRequ estDepth_10 FwdRLPQ_BurstRequ estDepth_14 FwdRLPQ_BurstRequ estDepth_18 FwdRLPQ_BurstRequ estDepth_22
FwdRLPQ_SCH_BurstAv gDepth_2x RevRLPQ_SCH_BurstAv gDepth_2x FwdRLPQ_SCH_BurstP eakDepth_2x RevRLPQ_SCH_BurstPe akDepth_2x
FwdRLPQ_BurstRequ estDepth_3 FwdRLPQ_BurstRequ estDepth_7 FwdRLPQ_BurstRequ estDepth_11 FwdRLPQ_BurstRequ estDepth_15 FwdRLPQ_BurstRequ estDepth_19 FwdRLPQ_BurstRequ estDepth_23
FwdRLPQ_SCH_BurstAv gDepth_4x RevRLPQ_SCH_BurstAv gDepth_4x FwdRLPQ_SCH_BurstP eakDepth_4x RevRLPQ_SCH_BurstPe akDepth_4x
FwdRLPQ_BurstReq uestDepth_4 FwdRLPQ_BurstReq uestDepth_8 FwdRLPQ_BurstReq uestDepth_12 FwdRLPQ_BurstReq uestDepth_16 FwdRLPQ_BurstReq uestDepth_20 FwdRLPQ_BurstReq uestDepth_24
FwdRLPQ_SCH_Burst AvgDepth_8x RevRLPQ_SCH_Burst AvgDepth_8x FwdRLPQ_SCH_Burst PeakDepth_8x RevRLPQ_SCH_Burst PeakDepth_8x
CDMA
NBSS15.0
3-8 1xRTT packet data performance Nortel Networks
Goals
Less than w% of all Forward SCH Link Setups attempted failed due to resource shortages. Less than x% of all Reverse SCH Link Setups attempted failed due to resource shortages.
Less than y% of all Forward SCH Burst Setups attempted failed due to resource shortages. Less than z% of all Reverse SCH Burst Setups attempted failed due to resource shortages.
The goals above are examples, only. As such, the service provider may choose the same or separate goals for Forward and Reverse blocking. In addition, the service provider may decide to create separate goals for each data rate. In the examples above, the variables (w, x, y, and z) should be defined in accordance with the service providers planned grade of service. It is improper, for example, to provision the system for 2% blocking, and then set the goal for anything other than 2%.
Formulas
SCH burst setup The formulas in this section provide information on SCH burst setups from BSC resources, BTS resources, and RF perspective. Overall forward burst downgrade rate due to BSC fair share algorithm This metric represents downgrade rate for all data rates (4X, 8X and 16X) combined. (FwdBurstBSC_Downgrade - FwdBurstBSC_DowngradeChange) / (FwdBurstSetupAttempts) x 100
The above overall Forward Burst Downgrade and following Per Data Rate Downgrade Metrics when considered with the Forward Burst Delay metrics can be used to for provisioning of BSC resources. These metrics can also be used to optimize BSC parameters related to FairShare Configuration Algorithm parameters and Burst Preemption Parameters while taking into account throughput metrics listed in RLP throughput performance (page 4-1). Note: The subsequent Fwd Burst Downgrade Rate (after the burst request is already queued by the scheduler at the BTS) can also be evaluated by the same formula above except that the numerator should be: (FwdBurst BSC_DowngradeChange + FwdBurstBSC_NonDowngradeChange).
411-2133-525
Standard
06.12
April 2008
Nortel Networks
These subsequent data-rate downgrades are caused by contention for BSC resources by other pending bursts while the burst request is queued at the BTS scheduler. The following set of metrics can be used to evaluate the impact of BSC resources shortage on the initial burst downgrade and subsequent downgrades for the burst in the BTS scheduler queue. These metrics consider multiple downgrades (not subtracting downgrade and non downgrade change OMs from the numerator) per a burst request to provide the impact of the BSC resource shortages. Forward burst downgrade rate per requested data-rate due to BSC fair share algorithm (CPDS only) The percentage of forward bursts downgraded (due to BSC Fair Share Algorithm) for 16X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_16X_To_2X + FwdBurstDowngrade_16X_To_4X + FwdBurstDowngrade_16X_To_8X) / (FwdBurstSetupAttempts_16X) x 100 The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) for 8X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_8X_To_2X + FwdBurstDowngrade_8X_To_4X) / (FwdBurstSetupAttempts_8X) x 100 The following set of metrics can be used to evaluate the impact of BSC resources shortage on the burst downgrade. These metrics consider only one downgrade (subtracting downgrade and non downgrade change OMs from the numerator) per a burst request to provide the impact of the BSC resource shortages. Forward burst downgrade rate per requested data-rate due to BSC fair share algorithm (CPDS only) The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) for 16X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_16X_To_2X + FwdBurstDowngrade_16X_To_4X + FwdBurstDowngrade_16X_To_8X FwdBurstDowngradeChange_16X_To_4X FwdBurstDowngradeChange_16X_To_8X) / (FwdBurstSetupAttempts_16X) x 100 The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) for 8X Burst attempts is expressed by the following ratio:
(FwdBurstDowngrade_8X_To_2X + FwdBurstDowngrade_8X_To_4X FwdBurstDowngradeChange_8X_To_4X) / (FwdBurstSetupAttempts_8X) x 100 The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) for 4X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_4X_To_2X) / (FwdBurstSetupAttempts_4X) x 100 Forward burst downgrade rate to a specific data rate per requested data-rate due to BSC fair share algorithm (CPDS only) The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) to 8X for 16X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_16X_To_8X) / (FwdBurstSetupAttempts_16X) x 100 The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) to 4X for 16X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_16X_To_4X) / (FwdBurstSetupAttempts_16X) x 100 The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) to 2X for 16X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_16X_To_2X) / (FwdBurstSetupAttempts_16X) x 100 The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) to 4X for 8X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_8X_To_4X) / (FwdBurstSetupAttempts_8X) x 100 The percentage of forward burst downgraded (due to BSC Fair Share Algorithm) to 2X for 8X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_8X_To_2X) / (FwdBurstSetupAttempts_8X) x 100 The percentage of forward bursts downgraded (due to BSC Fair Share Algorithm) to 2X for 4X Burst attempts is expressed by the following ratio: (FwdBurstDowngrade_4X_To_2X) / (FwdBurstSetupAttempts_4X) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Forward burst non-downgrade rate per requested data-rate (CPDS only) The percentage of forward burst not downgraded for 16X Burst attempts is expressed by the following ratio: (FwdBurstNonDowngrade_16X FwdBurstNonDowngradeChange_16X) / (FwdBurstSetupAttempts_16X) x 100 The percentage of forward burst not downgraded for 8X Burst attempts is expressed by the following ratio: (FwdBurstNonDowngrade_8X FwdBurstNonDowngradeChange_8X) / (FwdBurstSetupAttempts_8X) x 100 The percentage of forward burst not downgraded for 4X Burst attempts is expressed by the following ratio: (FwdBurstNonDowngrade_4X FwdBurstNonDowngradeChange_4X) / (FwdBurstSetupAttempts_4X) x 100 Forward bursts delayed due to BSC fair share algorithm The percentage of forward burst delayed (due to BSC Fair Share Algorithm) less than or equal to 1 second is expressed by the following ratio: FwdBurstDelayIndex_ 1 / FwdBurstSetupAttempts x 100 The percentage of forward burst delayed (due to BSC Fair Share Algorithm) more than 1 seconds but less than or equal to 3 second is expressed by the following ratio: FwdBurstDelayIndex_ 2/ FwdBurstSetupAttempts x 100 The percentage of forward burst delayed (due to BSC Fair Share Algorithm) more than 3 second is expressed by the following ratio: FwdBurstDelayIndex_ 3/ FwdBurstSetupAttempts x 100 Forward burst setup failure rate The percentage of overall forward burst setup failures (regardless of the requested data rate) is expressed by the following ratio: FwdBurstSetupFailures / FwdBurstSetupAttempts x 100 Note: The formula {100% minus (the overall Forward Burst Setup Failure rate)} represent the overall Forward Burst Setup Success rate.
CDMA
NBSS15.0
16X forward burst setup failure rate FwdBurstSetupFailures_16X / FwdBurstSetupAttempts_16X x 100 Note 1: The formula stated above represents the percentage of 16X Forward Burst Setup Attempts that could not be setup successfully at 16X or any data rate lower than 16X. Note 2: The formula {100% minus (16X Forward Burst Setup Failure rate)} represents the percentage of 16X Forward Burst Setup Attempts that are setup successfully at either 16X or any data rate lower than 16X. Note 3: The formula {[(FwdBurstSetupSuccesses_16X) / (FwdBurstSetupAttempts_16X)] * 100%} represents the percentage of 16X Forward Burst Setup Attempts that are setup successfully at 16X. 8X forward burst setup failure rate FwdBurstSetupFailures_8X / FwdBurstSetupAttempts_8X x 100 Note 1: The formula stated above represents the percentage of 8X Forward Burst Setup Attempts that could not be setup successfully at 8X or any data rate lower than 8X. The attempts only include initial 8X attempts and do not include 16X attempts that could not be setup at 16X, and therefore are attempted at 8X. Note 2: The formula {100% minus (8X Forward Burst Setup Failure rate)} represents the percentage of 8X Forward Burst Setup Attempts that are setup successfully at either 8X or any data rate lower than 8X. The attempts only include initial 8X attempts and do not include 16X attempts that could not be setup at 16X, and therefore are attempted at 8X. Note 3: The formula {[(FwdBurstSetupSuccesses_8X) / (FwdBurstSetupAttempts_8X + FwdBurstSetupAttempts_16X FwdBurstSetupSuccesses_16X - FwdBurstSetupFailures_16X)] * 100%} closely (In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required so 8X attempt may not have happened) represents the percentage of 8X Forward Burst Setup Attempts that are setup successfully at 8X. The attempts include both initial 8X attempts and 16X attempts that could not be setup at 16X, and therefore are attempted at 8X. 4X forward burst setup failure rate FwdBurstSetupFailures_4X / FwdBurstSetupAttempts_4X x 100 Note 1: The formula stated above represents the percentage of 4X Forward Burst Setup Attempts that could not be setup successfully at 4X or 2X. The attempts only include initial 4X attempts and do not include
411-2133-525 Standard 06.12 April 2008
Nortel Networks
higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 4X. Note 2: The formula {100% minus (4X Forward Burst Setup Failure rate)} represents the percentage of 4X Forward Burst Setup Attempts that are setup successfully at either 4X or 2X. The attempts only include initial 4X attempts and do not include higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 4X. Note 3: The formula {[(FwdBurstSetupSuccesses_4X) / (FwdBurstSetupAttempts_4X + FwdBurstSetupAttempts_8X + FwdBurstSetupAttempts_16X - FwdBurstSetupSuccesses_8X FwdBurstSetupSuccesses_16X - FwdBurstSetupFailures_8X FwdBurstSetupFailures_16X)] * 100%} closely (In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required so 4X attempt may not have happened) represents the percentage of 4X Forward Burst Setup Attempts that are setup successfully at 4X. The attempts include both+ initial 4X attempts and higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 4X. 2X forward burst setup failure rate FwdBurstSetupFailures_2X / FwdBurstSetupAttempts_2X x 100 Note 1: The formula stated above represents the percentage of 2X Forward Burst Setup Attempts that could not be setup successfully at 2X. The attempts only include initial 2X attempts and do not include higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 2X. Note 2: The formula {100% minus (2X Forward Burst Setup Failure rate)} represents the percentage of 2X Forward Burst Setup Attempts that are setup successfully at 2X. The attempts only include initial 2X attempts and do not include higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 2X. Note 3: The formula {[(FwdBurstSetupSuccesses_2X) / (FwdBurstSetupAttempts_2X + FwdBurstSetupAttempts_4X + FwdBurstSetupAttempts_8X + FwdBurstSetupAttempts_16X FwdBurstSetupSuccesses_4X - FwdBurstSetupSuccesses_8X FwdBurstSetupSuccesses_16X - FwdBurstSetupFailures_4X FwdBurstSetupFailures_8X - FwdBurstSetupFailures_16X)] * 100%} closely (In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required so 2X attempt may not have happened) represents the percentage of 2X Forward Burst Setup Attempts that are setup successfully at 2X. The attempts include both initial 2X attempts and
higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 2X. Distribution of successful forward bursts by data rate The percentage of successful forward bursts that are setup at 16X: FwdBurstSetupSuccesses_16X / FwdBurstSetupSuccesses x 100 The percentage of successful forward bursts that are setup at 8X: FwdBurstSetupSuccesses_8X / FwdBurstSetupSuccesses x 100 The percentage of successful forward bursts that are setup at 4X: FwdBurstSetupSuccesses_4X / FwdBurstSetupSuccesses x 100 The percentage of successful forward bursts that are setup at 2X: FwdBurstSetupSuccesses_2X / FwdBurstSetupSuccesses x 100 Average data rate for all successful forward bursts combined The average data rate for all successful forward bursts combined: {(Percentage of successful bursts that are setup at 16X) x (153.6 Kbps) + (Percentage of successful bursts that are setup at 8X) x (76.8 Kbps) + (Percentage of successful bursts that are setup at 4X) x (38.4 Kbps) + (Percentage of successful bursts that are setup at 2X) x (19.2 Kbps)} Note: The average Fwd Burst Data Rate value as given by the above formula plus 9.6 Kbps (which represents the FCH data rate) would represent an approximation of the physical layer data rate while the user is bursting in the forward direction. For more information about metrics measuring throughput at the bearer data level, see RLP throughput performance (page 4-1). Overall reverse burst downgrade rate due to BSC fair share algorithm The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) is expressed by the following ratio: RevBurstBSC_Downgrade / RevBurstSetupAttempts x 100 The above overall Reverse Burst Downgrade and following Per Data Rate Reverse Burst Downgrade Metrics when considered with the Reverse Burst Delay metrics can be used to for provisioning of BSC resources.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Reverse burst downgrade rate per requested data-rate due to BSC fair share algorithm (CPDS only) The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) for 16X Burst attempts is expressed by the following ratio: (RevBurstDowngrade_16X_To_2X + RevBurstDowngrade_16X_To_4X + RevBurstDowngrade_16X_To_8X) / (RevBurstSetupAttempts_16X) x 100 The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) for 8X Burst attempts is expressed by the following ratio: (RevBurstDowngrade_8X_To_2X + RevBurstDowngrade_8X_To_4X) / (RevBurstSetupAttempts_8X) x 100 The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) for 4X Burst attempts is expressed by the following ratio: RevBurstDowngrade_4X_To_2X / RevBurstSetupAttempts_4X x 100 Reverse burst downgrade rate to a specific data rate per requested data-rate due to BSC fair share algorithm (CPDS only) The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) to 8X for 16X Burst attempts is expressed by the following ratio: (RevBurstDowngrade_16X_To_8X / RevBurstSetupAttempts_16X) x 100 The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) to 4X for 16X Burst attempts is expressed by the following ratio: (RevBurstDowngrade_16X_To_4X / RevBurstSetupAttempts_16X) x 100 The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) to 2X for 16X Burst attempts is expressed by the following ratio: (RevBurstDowngrade_16X_To_2X / RevBurstSetupAttempts_16X) x 100 The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) to 4X for 8X Burst attempts is expressed by the following ratio: RevBurstDowngrade_8X_To_4X / RevBurstSetupAttempts_8X x 100 The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) to 2X for 8X Burst attempts is expressed by the following ratio:
CDMA
NBSS15.0
RevBurstDowngrade_8X_To_2X / RevBurstSetupAttempts_8X x 100 The percentage of reverse burst downgraded (due to BSC Fair Share Algorithm) to 2X for 4X Burst attempts is expressed by the following ratio: RevBurstDowngrade_4X_To_2X / RevBurstSetupAttempts_4X x 100 Reverse burst non-downgrade rate per requested data-rate (CPDS only) The percentage of reverse burst not downgraded for 16X Burst attempts is expressed by the following ratio: (RevBurstNonDowngrade_16X / RevBurstSetupAttempts_16X) x 100 The percentage of reverse burst not downgraded for 8X Burst attempts is expressed by the following ratio: (RevBurstNonDowngrade_8X / RevBurstSetupAttempts_8X) x 100 The percentage of reverse burst not downgraded for 4X Burst attempts is expressed by the following ratio: (RevBurstNonDowngrade_4X / RevBurstSetupAttempts_4X) x 100 Percentage of reverse bursts delayed due to BSC fair share algorithm The percentage of reverse burst delayed (due to BSC Fair Share Algorithm) less than or equal to 1 second is expressed by the following ratio: (RevBurstDelayIndex_ 1 / RevBurstSetupAttempts) x 100 The percentage of reverse burst delayed (due to BSC Fair Share Algorithm) more than 1 seconds but less than or equal to 3 second is expressed by the following ratio: (RevBurstDelayIndex_ 2/ RevBurstSetupAttempts) x 100 The percentage of reverse burst delayed (due to BSC Fair Share Algorithm) more than 3 second is expressed by the following ratio: (RevBurstDelayIndex_ 3 / RevBurstSetupAttempts) x 100 Reverse burst setup failure rate The percentage of overall reverse burst setup failures (regardless of the requested data rate) is expressed by the following ratio: (RevBurstSetupFailures / RevBurstSetupAttempts) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Note: The overall Reverse Burst Setup Success rate is equal to {100% minus (the overall Reverse Burst Setup Failure rate as stated in the above formula)}. 16X reverse burst setup failure rate The percentage of 16X reverse burst setup failures is expressed by the following ratio: (RevBurstSetupFailures_16X / RevBurstSetupAttempts_16X) x 100 Note 1: The 16X Reverse Burst Setup Failure rate represents the percentage of 16X Reverse Burst Setup Attempts that could not be setup successfully at 16X or any data rate lower than 16X. Note 2: {100% minus (16X Reverse Burst Setup Failure rate)} represents the percentage of 16X Reverse Burst Setup Attempts that are setup successfully at either 16X or any data rate lower than 16X. Note 3: {[(RevBurstSetupSuccesses_16X) / (RevBurstSetupAttempts_16X)] * 100%} represents the percentage of 16X Reverse Burst Setup Attempts that are setup successfully at 16X. 8X reverse burst setup failure rate The percentage of 8X reverse burst setup failures is expressed by the following ratio: (RevBurstSetupFailures_8X / RevBurstSetupAttempts_8X) x 100 Note 1: The 8X Reverse Burst Setup Failure rate represents the percentage of 8X Reverse Burst Setup Attempts that could not be setup successfully at 8X or any data rate lower than 8X. The attempts only include initial 8X attempts and do not include 16X attempts that could not be setup at 16X, and therefore are attempted at 8X. Note 2: {100% minus (8X Reverse Burst Setup Failure rate)} represents the percentage of 8X Reverse Burst Setup Attempts that are setup successfully at either 8X or any data rate lower than 8X. The attempts only include initial 8X attempts and do not include 16X attempts that could not be setup at 16X, and therefore are attempted at 8X. Note 3: {[(RevBurstSetupSuccesses_8X) / (RevBurstSetupAttempts_8X + RevBurstSetupAttempts_16X RevBurstSetupSuccesses_16X - RevBurstSetupFailures_16X)] * 100%} closely (In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required so 8X attempt may not have happened) represents the percentage of 8X Reverse Burst Setup Attempts that are setup
successfully at 8X. The attempts include both initial 8X attempts and 16X attempts that could not be setup at 16X, and therefore are attempted at 8X. 4X reverse burst setup failure rate The percentage of 4X reverse burst setup failures is expressed by the following ratio: (RevBurstSetupFailures_4X / RevBurstSetupAttempts_4X) x 100 Note 1: The 4X Reverse Burst Setup Failure rate represents the percentage of 4X Reverse Burst Setup Attempts that could not be setup successfully at 4X or 2X. The attempts only include initial 4X attempts and do not include higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 4X. Note 2: {100% minus (4X Reverse Burst Setup Failure rate)} represents the percentage of 4X Reverse Burst Setup Attempts that are setup successfully at either 4X or 2X. The attempts only include initial 4X attempts and do not include higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 4X. Note 3: {[(RevBurstSetupSuccesses_4X) / (RevBurstSetupAttempts_4X + RevBurstSetupAttempts_8X + RevBurstSetupAttempts_16X - RevBurstSetupSuccesses_8X RevBurstSetupSuccesses_16X - RevBurstSetupFailures_8X RevBurstSetupFailures_16X)] * 100%} closely (In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required so 4X attempt may not have happened) represents the percentage of 4X Reverse Burst Setup Attempts that are setup successfully at 4X. The attempts include both initial 4X attempts and higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 4X. 2X reverse burst setup failure rate Percentage of 2X reverse burst setup failures is expressed by the following ratio: (RevBurstSetupFailures_2X / RevBurstSetupAttempts_2X) x 100 Note 1: The 2X Reverse Burst Setup Failure rate represents the percentage of 2X Reverse Burst Setup Attempts that could not be setup successfully at 2X. The attempts only include initial 2X attempts and do not include higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 2X. Note 2: {100% minus (2X Reverse Burst Setup Failure rate)} represents the percentage of 2X Reverse Burst Setup Attempts that are setup
411-2133-525 Standard 06.12 April 2008
Nortel Networks
successfully at 2X. The attempts only include initial 2X attempts and do not include higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 2X. Note 3: {[(RevBurstSetupSuccesses_2X) / (RevBurstSetupAttempts_2X + RevBurstSetupAttempts_4X + RevBurstSetupAttempts_8X + RevBurstSetupAttempts_16X RevBurstSetupSuccesses_4X - RevBurstSetupSuccesses_8X RevBurstSetupSuccesses_16X - RevBurstSetupFailures_4X RevBurstSetupFailures_8X - RevBurstSetupFailures_16X))] * 100% } closely (In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required so 2X attempt may not have happened) represents the percentage of 2X Reverse Burst Setup Attempts that are setup successfully at 2X. The attempts include both initial 2X attempts and higher data rate attempts that could not be setup at a higher rate, and therefore eventually are attempted at 2X. Distribution of successful reverse bursts by data rate The percentage of successful reverse bursts that are setup at 16X is expressed by the following ratio: (RevBurstSetupSuccesses_16X / RevBurstSetupSuccesses) x 100 The percentage of successful reverse bursts that are setup at 8X is expressed by the following ratio: (RevBurstSetupSuccesses_8X / RevBurstSetupSuccesses) x 100 Percentage of successful reverse bursts that are setup at 4X is expressed by the following ratio: (RevBurstSetupSuccesses_4X / RevBurstSetupSuccesses) x 100 The percentage of successful reverse bursts that are setup at 2X is expressed by the following ratio: (RevBurstSetupSuccesses_2X / RevBurstSetupSuccesses) x 100 Average data rate for all successful reverse bursts combined The average data rate for all successful reverse bursts combined is expressed by the following ratio: {(Percentage of successful bursts that are setup at 16X) x (153.6 Kbps) + (Percentage of successful bursts that are setup at 8X) x (76.8 Kbps) + (Percentage of successful bursts that are setup at 4X) x (38.4 Kbps) + (Percentage of successful bursts that are setup at 2X) x (19.2 Kbps)}
CDMA
NBSS15.0
The average Rev Burst Data Rate value as given by the above formula plus 9.6 Kbps (which represents the FCH data rate) would represent an approximation of the user-perceived throughput while the user is bursting on the reverse direction. For more information about an accurate user perceived throughput metric, see RLP throughput performance (page 4-1). Forward infinite burst release rate due to contention for BSC resources Note 1: The values provided by the metrics in this section indicates BSC resources shortage and there may be a need for optimization of MinActiveTimer value. As an example, if metrics values are higher or closer to the set benchmark for higher data rates then it may be necessary to provision more BSC resources for supporting more SCH bursts and better user data throughput. Note 2: It may be necessary to adjust the value of MinActiveTimer to allow infinite burst to continue little longer before it is released due to BSC resource contention. The value of this timer need to be adjusted to recommended value such that the other burst requests do not have to wait for resources too long. The percentage of 2X forward infinite bursts released due to contention for BSC resources is expressed by the following ratio: (FwdBurstBSC_Release_2X / FwdBurstSetupSuccesses_2X) x 100 The percentage of 4X forward bursts released due to contention for BSC resources is expressed by the following ratio: (FwdBurstBSC_Release_4X / FwdBurstSetupSuccesses_4X) x 100 The percentage of 8X forward bursts released due to contention for BSC resources is expressed by the following ratio: (FwdBurstBSC_Release_8X / FwdBurstSetupSuccesses_8X) x 100 The percentage of 16X forward bursts released due to contention for BSC resources is expressed by the following ratio: (FwdBurstBSC_Release_16X / FwdBurstSetupSuccesses_16X) x 100 The percentage of overall forward bursts released due to contention for BSC resources is expressed by the following ratio: (FwdBurstBSC_Release_2X + FwdBurstBSC_Release_4X + FwdBurstBSC_Release_8X + FwdBurstBSC_Release_16X) / (FwdBurstSetupSuccesses) ) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
Forward burst release rate due to contention for BTS resources The values provided by the metrics in this section indicates BTS resources shortage and there may be a need for optimization of MinActiveTimer value. As an example, if metrics values are higher or closer to the set benchmark for higher data rates then it may be necessary to provision more BTS resources (XCEM card or another carrier) for supporting more SCH bursts and better user data throughput. The optimization of RRM parameters and power control parameters for SCH can be performed to reduce burst releases due to forward power shortage. If burst are not released significantly due to BSC resources contention then it may be necessary to adjust the value of MinActiveTimer to allow infinite burst to continue little longer before it is released due to BTS resources contention. The value of this timer need to be adjusted to recommended value such that the other burst requests do not have to wait for resources too long. It is recommended to evaluate metrics from Forward Infinite Burst Release Rate due to contention for BSC resources and Forward Burst Release Rate due to contention for BTS resources together for determining appropriate value of MinActiveTimer. The percentage of 2X forward bursts released due to contention for BTS resources is expressed by the following ratio: (FwdBurstBTS_PilotRelease_2X / FwdBurstSetupSuccesses_2X) x 100 The percentage of 4X forward bursts released due to contention for BTS resources is expressed by the following ratio: (FwdBurstBTS_PilotRelease_4X / FwdBurstSetupSuccesses_4X) x 100 The percentage of 8X forward bursts released due to contention for BTS resources is expressed by the following ratio: (FwdBurstBTS_PilotRelease_8X / FwdBurstSetupSuccesses_8X) x 100 The percentage of 16X forward bursts released due to contention for BTS resources is expressed by the following ratio: (FwdBurstBTS_PilotRelease_16X / FwdBurstSetupSuccesses_16X) x 100 The percentage of overall forward bursts released due to contention for BTS resources is expressed by the following ratio:
CDMA
NBSS15.0
(FwdBurstBTS_PilotRelease_2X + FwdBurstBTS_PilotRelease_4X + FwdBurstBTS_PilotRelease_8X + FwdBurstBTS_PilotRelease_16X) / (FwdBurstSetupSuccesses) x 100 Reverse burst release rate due to contention for BSC resources Note 1: Refer to Note 1 of Forward infinite burst release rate due to contention for BSC resources (page -20). Note 2: Refer to Note 2 of Forward infinite burst release rate due to contention for BSC resources (page -20). The percentage of 2X reverse bursts released due to contention for BSC resources is expressed by the following ratio: (RevBurstBSC_Release_2X / RevBurstSetupSuccesses_2X) x 100 The percentage of 4X reverse bursts released due to contention for BSC resources is expressed by the following ratio: (RevBurstBSC_Release_4X / RevBurstSetupSuccesses_4X) x 100 The percentage of 8X reverse bursts released due to contention for BSC resources is expressed by the following ratio: (RevBurstBSC_Release_8X / RevBurstSetupSuccesses_8X) x 100 The percentage of 16X reverse bursts released due to contention for BSC resources is expressed by the following ratio: (RevBurstBSC_Release_16X / RevBurstSetupSuccesses_16X) x 100 The percentage of overall reverse bursts released due to contention for BSC resources is expressed by the following ratio: (RevBurstBSC_Release_2X + RevBurstBSC_Release_4X + RevBurstBSC_Release_8X + RevBurstBSC_Release_16X) / (RevBurstSetupSuccesses) x 100 Reverse burst release rate due to contention for BTS resources The values provided by the metrics in this section indicates BTS resources shortage and there may be a need for optimization of MinActiveTimer value. As an example, if metrics values are higher or closer to the set benchmark for higher data rates then it may be necessary to provision more BTS resources (XCEM card or another carrier) for supporting more SCH bursts and better user data throughput.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
If bursts are not released significantly due to BSC resources contention then it may be necessary to adjust the value of MinActiveTimer to allow infinite burst to continue little longer before it is released due to BTS resources contention. The value of this timer need to be adjusted to recommended value such that the other burst requests do not have to wait for resources too long. It is recommended to evaluate metrics from Reverse Infinite Burst Release Rate due to contention for BSC resources and Reverse Burst Release Rate due to contention for BTS resources together for determining appropriate value of MinActiveTimer. The percentage of 2X reverse bursts released due to contention for BTS resources is expressed by the following ratio: (RevBurstBTS_PilotRelease_2X / RevBurstSetupSuccesses_2X) x 100 The percentage of 4X reverse bursts released due to contention for BTS resources is expressed by the following ratio: (RevBurstBTS_PilotRelease_4X / RevBurstSetupSuccesses_4X) x 100 The percentage of 8X reverse bursts released due to contention for BTS resources is expressed by the following ratio: (RevBurstBTS_PilotRelease_8X / RevBurstSetupSuccesses_8X) x 100 The percentage of 16X reverse bursts released due to contention for BTS resources is expressed by the following ratio: (RevBurstBTS_PilotRelease_16X / RevBurstSetupSuccesses_16X) x 100 The percentage of overall reverse bursts released due to contention for BTS resources is expressed by the following ratio: (RevBurstBTS_PilotRelease_2X + RevBurstBTS_PilotRelease_4X + RevBurstBTS_PilotRelease_8X + RevBurstBTS_PilotRelease_16X) / (RevBurstSetupSuccesses) x 100 Forward burst data rate upgrade attempts percentage The rate of attempting to upgrade the data rate for a 2X forward burst to a higher rate is expressed by the following ratio: (FwdBurstUpgradeAttempts_2X_To_4X + FwdBurstUpgradeAttempts_2X_To_8X + FwdBurstUpgradeAttempts_2X_To_16X) / (FwdBurstSetupSuccesses_2X) x 100
CDMA
NBSS15.0
The rate of attempting to upgrade the data rate for a 4X forward burst is expressed by the following ratio: (FwdBurstUpgradeAttempts_4X_To_8X + FwdBurstUpgradeAttempts_4X_To_16X) / (FwdBurstSetupSuccesses_4X) x 100 The rate of attempting to upgrade the data rate for a 8X forward burst is expressed by the following ratio: (FwdBurstUpgradeAttempts_8X_To_16X / FwdBurstSetupSuccesses_8X) x 100 The rate of attempting to upgrade the data rate for overall (all rates) forward bursts is expressed by the following ratio: (FwdBurstUpgradeAttempts_2X_To_4X + FwdBurstUpgradeAttempts_2X_To_8X + FwdBurstUpgradeAttempts_2X_To_16X + FwdBurstUpgradeAttempts_4X_To_8X + FwdBurstUpgradeAttempts_4X_To_16X + FwdBurstUpgradeAttempts_8X_To_16X) / (FwdBurstSetupSuccesses - FwdBurstSetupSuccesses_16X) x 100 Forward burst data rate upgrade success percentage The percentage of 2X forward bursts upgraded successfully to a higher data rate is expressed by the following ratio: (FwdBurstUpgradeSuccesses_2X_To_4X + FwdBurstUpgradeSuccesses_2X_To_8X + FwdBurstUpgradeSuccesses_2X_To_16X) / (FwdBurstUpgradeAttempts_2X_To_4X + FwdBurstUpgradeAttempts_2X_To_8X + FwdBurstUpgradeAttempts_2X_To_16X) x 100 The percentage of 4X forward bursts upgraded successfully to a higher data rate is expressed by the following ratio: (FwdBurstUpgradeSuccesses_4X_To_8X + FwdBurstUpgradeSuccesses_4X_To_16X) / (FwdBurstUpgradeAttempts_4X_To_8X + FwdBurstUpgradeAttempts_4X_To_16X) x 100 The percentage of 8X forward bursts upgraded successfully to a higher data rate is expressed by the following ratio: (FwdBurstUpgradeSuccesses_8X_To_16X / FwdBurstUpgradeAttempts_8X_To_16X) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
The percentage of overall forward bursts upgraded successfully to a higher data rate is expressed by the following ratio: (FwdBurstUpgradeSuccesses_2X_To_4X + FwdBurstUpgradeSuccesses_2X_To_8X + FwdBurstUpgradeSuccesses_2X_To_16X + FwdBurstUpgradeSuccesses_4X_To_8X + FwdBurstUpgradeSuccesses_4X_To_16X + FwdBurstUpgradeSuccesses_8X_To_16X) / (FwdBurstUpgradeAttempts_2X_To_4X + FwdBurstUpgradeAttempts_2X_To_8X + FwdBurstUpgradeAttempts_2X_To_16X + FwdBurstUpgradeAttempts_4X_To_8X + FwdBurstUpgradeAttempts_4X_To_16X + FwdBurstUpgradeAttempts_8X_To_16X) x 100 Forward burst data rate upgrade failures percentage The percentage of 2X forward burst failed upgrades to 4X is expressed by the following ratio: (FwdBurstUpgradeFailures_2X_To_4X / FwdBurstUpgradeAttempts_2X_To_4X) x 100 Note: The burst upgrade failures from Datarate1 (e.g. 2X) to Datarate2 (e.g. 4X) mean that either the burst could not be setup at any rate (due to resources or RF issues) during upgrade after releasing the Datarate1 (2X) burst, or only a Datarate1 (2X) burst could be re-established during upgrade after releasing the Datarate1 (2X) burst. The percentage of 2X forward burst failed upgrades to 8X is expressed by the following ratio: (FwdBurstUpgradeFailures_2X_To_8X / FwdBurstUpgradeAttempts_2X_To_8X) x 100 The percentage of 2X forward burst failed upgrades to 16X is expressed by the following ratio: (FwdBurstUpgradeFailures_2X_To_16X / FwdBurstUpgradeAttempts_2X_To_16X) x 100 The percentage of 4X forward burst failed upgrades to 8X is expressed by the following ratio: (FwdBurstUpgradeFailures_4X_To_8X / FwdBurstUpgradeAttempts_4X_To_8X) x 100
CDMA
NBSS15.0
The percentage of 4X forward burst failed upgrades to 16X is expressed by the following ratio: (FwdBurstUpgradeFailures_4X_To_16X / FwdBurstUpgradeAttempts_4X_To_16X) x 100 The percentage of 8X forward burst failed upgrades to 16X is expressed by the following ratio: (FwdBurstUpgradeFailures_8X_To_16X / FwdBurstUpgradeAttempts_8X_To_16X) x 100 The percentage of overall forward burst failed upgrades to a higher data rate is expressed by the following ratio: (FwdBurstUpgradeFailures_2X_To_4X + FwdBurstUpgradeFailures_2X_To_8X + FwdBurstUpgradeFailures_2X_To_16X + FwdBurstUpgradeFailures_4X_To_8X + FwdBurstUpgradeFailures_4X_To_16X + FwdBurstUpgradeFailures_8X_To_16X) / (FwdBurstUpgradeAttempts_2X_To_4X + FwdBurstUpgradeAttempts_2X_To_8X + FwdBurstUpgradeAttempts_2X_To_16X + FwdBurstUpgradeAttempts_4X_To_8X + FwdBurstUpgradeAttempts_4X_To_16X + FwdBurstUpgradeAttempts_8X_To_16X) x 100 SCH radio link setup The formulas in this section provide information on SCH Radio Link setups with respect to BSC resources, BTS resources, and RF perspective. Calculating link metrics for primary and/or secondary links (pilots) In NBSS 14.0, the SCH Radio Link Setup OM group was split into two separate groups: the SCH Primary Radio Link Setup OM group (which pegs only for the primary/reference sector link) and the SCH Handoff Radio Link Setup OM group (which pegs only for the non-primary/non-reference sector link). Therefore, in all of the following SCH Radio Link related metrics/formulas, OMs from the SCH Primary Radio Link Setup OM group should be used for calculating the contributions from a given sector as a primary pilot, and the OMs from the SCH Handoff Radio Link Setup OM group group should be used for calculating the contribution of a sector as a handoff pilot. To achieve pre-NBSS 14.0 equivalent metrics, the sum of the appropriate OMs from both groups should be used. The following considerations apply to the SCH Radio Link metrics:
411-2133-525 Standard 06.12 April 2008
Nortel Networks
The SCH Handoff Radio Link OM names are preceded by SHO_ to avoid confusion with the primary OMs, and are understood to replace the equivalent primary OMs in the appropriate formulas when calculating metrics for handoff links. For example, the primary link OM FSCHLinkSetupAttempts_<data rate> would be replaced by the handoff link OM SHO_FSCHLinkSetupAttempts_<data rate> in any given formula if handoff metrics are desired. The downgrade related SCH link metrics do not apply to handoff links; therefore, there are no equivalent downgrade OMs in the handoff OM group. The drop related SCH link metrics currently account for all links using the drop related OMs from the primary OM group; therefore, there are no equivalent drop OMs in the handoff OM group. The SCH Radio Link Release OM group OMs account for both primary and handoff links. F-SCH link setup blocks The F-SCH Link Setup Block Metrics represent the percentage of Forward Link Setup Attempts that could not be setup successfully. The following considerations apply to the blocking metrics in this section: For the primary F-SCH radio link OM group, the FSCHLinkSetupAttempts_<data rate> OMs are only pegged at the requested data rate even though additional attempts at lower rates are performed. Therefore, the FSCHLinkSetupBlock_<data rate> OMs are only pegged at the requested rate and indicate that the call attempt could not be set up at the requested data rate or any lower data rate. For the handoff F-SCH radio link OM group (i.e., for SCH SHO links), the SHO_FSCHLinkSetupAttempts_<data rate> OMs are only pegged at the actual data rate requested since attempts at lower rates are not performed. Therefore, the SHO_FSCHLinkSetupBlock_<data rate> OMs only represent attempts that could not be setup at the requested data rate. The FSCHLinkSetupAttempts_Change_<data_rate> OMs should NOT be included when calculating any of the FSCH link setup block metrics for handoff links only. The Link Setup Block metrics can be evaluated on a per EBID basis. Overall F-SCH link setup blocks FSCHLinkSetupBlock / (FSCHLinkSetupAttempt (FSCHLinkSetupAttempts_Change_4X -
CDMA
NBSS15.0
FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X)) x 100 16X F-SCH link setup blocks FSCHLinkSetupBlock_16X / (FSCHLinkSetupAttempts_16X FSCHLinkSetupAttempts_Change_16X) x 100 8X F-SCH link setup blocks FSCHLinkSetupBlock_8X / (FSCHLinkSetupAttempts_8X FSCHLinkSetupAttempts_Change_8X) x 100 4X F-SCH link setup blocks FSCHLinkSetupBlock_4X / (FSCHLinkSetupAttempts_4X FSCHLinkSetupAttempts_Change_4X) x 100 2X F-SCH link setup blocks FSCHLinkSetupBlock_2X / FSCHLinkSetupAttempts_2X x 100 F-SCH setup blocks due to lack of forward power FSCHNoFwdPower / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 F-SCH setup blocks due to lack of Walsh codes FSCHNoWalshCode / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 F-SCH setup blocks due to lack of physical resources FSCHNoPhysRes / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 F-SCH setup blocks due to lack of frame offset availability FSCHNoFrameOffset / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
F-SCH setup blocks due to backhaul exhaustion FSCHBackHaulExhaustion / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 F-SCH setup blocks due to BCN link exhaustion FSCHBCNLinkExhaustion / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 F-SCH setup blocks due to ACN ID exhaustion FSCHAcnIdExhaustion / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 F-SCH setup blocks due to timeout FSCHTimeout / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 Distribution of F-SCH setup blocks The following metrics are useful in determining the contribution of each individual blocking reason toward the total number of F-SCH setup blocks. This data is best presented in the form of a pie chart. Contribution of forward power blocks (FSCHNoFwdPower / FSCHLinkSetupBlock) x 100 Contribution of Walsh code blocks (FSCHNoWalshCode / FSCHLinkSetupBlock) x 100 Contribution of physical resource blocks (FSCHNoPhysRes / FSCHLinkSetupBlock) x 100 Contribution of frame offset availability blocks (FSCHNoFrameOffset / FSCHLinkSetupBlock) x 100 Contribution of backhaul exhaustion blocks (FSCHBackHaulExhaustion / FSCHLinkSetupBlock) x 100
CDMA
NBSS15.0
Contribution of BCN link exhaustion blocks (FSCHBCNLinkExhaustion / FSCHLinkSetupBlock) x 100 Contribution of ACN ID exhaustion blocks (FSCHAcnIdExhaustion / FSCHLinkSetupBlock) x 100 Contribution of timeout blocks (FSCHTimeout / FSCHLinkSetupBlock) x 100 F-SCH radio link access failures The F-SCH Radio Link Access Failure Metrics represent the percentage of F-SCH Link Setup Attempts for which the resources for the F-SCH were set up successfully, but the mobile did not arrive on the F-SCH. The Radio Link Access Failure metrics can be evaluated on a per EBID basis. Note: When calculating metrics for handoff SCH links only, the FSCHLinkSetupAttempts_Change_<data_rate> OMs should NOT be used in any of the FSCH radio link access failure formulas. Overall F-SCH radio link access failures FSCHRadioLinkAccessFailure / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 Note: The following rate-specific F-SCH Radio Link Access Failure metrics make use of the FSCHLinkSetupSuccess_<data rate> OMs instead of the FSCHLinkSetupAttempts_<data rate> OMs in the denominator due to the fact that the FSCHRadioLinkAccessFailure_<data rate> OMs are only pegged after the resources have been successfully allocated at a given rate, which may not necessarily be the original data rate requested (e.g., downgrades from 16X to 8X). Therefore, these metrics are only valid if the FSCHLinkSetupSuccess_<data rate> OM is non-zero. 16X F-SCH radio link access failures (FSCHRadioLinkAccessFailure_16X / FSCHLinkSetupSuccess_16X) x 100 8X F-SCH radio link access failures (FSCHRadioLinkAccessFailure_8X / FSCHLinkSetupSuccess_8X) x 100 4X F-SCH radio link access failures (FSCHRadioLinkAccessFailure_4X / FSCHLinkSetupSuccess_4X) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
2X F-SCH radio link access failures (FSCHRadioLinkAccessFailure_2X / FSCHLinkSetupSuccess_2X) x 100 F-SCH primary link downgrades due to BTS FSCHLinkDowngrade / (FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 FSCH primary link downgrades due to changes in power requirement For primary SCH links only, whenever a BTS-queued burst is allocated by the BTS, the BSC checks to see if it needs to downgrade the burst rate due to changes in the power requirements since the last power update sent to the BTS. If the allocated power is less than the new power requirement, then the BSC downgrades the burst. This could result in a BSC downgrade after a BTS downgrade. These metrics in conjunction with the burst downgrade metrics, link downgrade metrics and throughput metrics are useful to evaluate low throughput performance sectors. The percentage of F-SCH link downgrades due to changes in power requirement is expressed by the following ratio: (FSCHDowngradePowerReqChange_16X_To_8X + FSCHDowngradePowerReqChange_16X_To_4X + FSCHDowngradePowerReqChange_16X_To_2X + FSCHDowngradePowerReqChange_8X_To_4X + FSCHDowngradePowerReqChange_8X_To_2X + FSCHDowngradePowerReqChange_4X_To_2X) / (FSCHLinkSetupAttempt - FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 The percentage of 16X F-SCH link downgrades due to changes in power requirement is expressed by the following ratio: (FSCHDowngradePowerReqChange_16X_To_8X + FSCHDowngradePowerReqChange_16X_To_4X + FSCHDowngradePowerReqChange_16X_To_2X) / (FSCHLinkSetupAttempts_ 16X FSCHLinkSetupAttempts_Change_16X) x 100 The percentage of 8X F-SCH link downgrades due to changes in power requirement is expressed by the following ratio:
(FSCHDowngradePowerReqChange_8X_To_4X + FSCHDowngradePowerReqChange_8X_To_2X) / (FSCHLinkSetupAttempts_ 8X FSCHLinkSetupAttempts_Change_8X) x 100 The percentage of 4X F-SCH link downgrades due to changes in power requirement is expressed by the following ratio: (FSCHDowngradePowerReqChange_4X_To_2X / (FSCHLinkSetupAttempts_ 4X FSCHLinkSetupAttempts_Change_4X) x 100 Distribution of successful forward link setups per data rate The percentage of successful forward links that are setup at 16X is expressed by the following ratio: (FSCHLinkSetupSuccess_16X / FSCHLinkSetupSuccess) x 100 The percentage of successful forward links that are setup at 8X is expressed by the following ratio: (FSCHLinkSetupSuccess_8X / FSCHLinkSetupSuccess) x 100 The percentage of successful forward links that are setup at 4X is expressed by the following ratio: (FSCHLinkSetupSuccess_4X / FSCHLinkSetupSuccess) x 100 The percentage of successful forward links that are setup at 2X is expressed by the following ratio: (FSCHLinkSetupSuccess_2X / FSCHLinkSetupSuccess) x 100 Average data rate for all successful forward link setups combined The average data rate for all successful forward link setups combined is expressed by the following ratio: {(Percentage of successful links that are setup at 16X) x (153.6 Kbps) + (Percentage of successful links that are setup at 8X) x (76.8 Kbps) + (Percentage of successful links that are setup at 4X) x (38.4 Kbps) + (Percentage of successful links that are setup at 2X) x (19.2 Kbps)} R-SCH link setup blocks The R-SCH Link Setup Block Metrics represent the percentage of Reverse Link Setup Attempts that could not be setup successfully. The following considerations apply to the blocking metrics in this section:
411-2133-525 Standard 06.12 April 2008
Nortel Networks
For the primary R-SCH radio link OM group, the RSCHLinkSetupAttempts_<data rate> OMs are only pegged at the requested data rate even though additional attempts at lower rates are performed. Therefore, the RSCHLinkSetupBlock_<data rate> OMs are only pegged at the requested rate and indicate that the call attempt could not be set up at the requested data rate or any lower data rate. For the handoff R-SCH radio link OM group (i.e., for SCH SHO links), the SHO_RSCHLinkSetupAttempts_<data rate> OMs are only pegged at the actual data rate requested since attempts at lower rates are not performed. Therefore, the SHO_RSCHLinkSetupBlock_<data rate> OMs only represent attempts that could not be setup at the requested data rate. The Link Setup Block metrics can be evaluated on a per EBID basis. Overall R-SCH link setup blocks (RSCHLinkSetupBlock / RSCHLinkSetupAttempt) x 100 16X R-SCH link setup blocks (RSCHLinkSetupBlock_16X / RSCHLinkSetupAttempts_16X) x 100 8X R-SCH link setup blocks (RSCHLinkSetupBlock_8X / RSCHLinkSetupAttempts_8X) x 100 4X R-SCH link setup blocks (RSCHLinkSetupBlock_4X / RSCHLinkSetupAttempts_4X) x 100 2X R-SCH link setup blocks (RSCHLinkSetupBlock_2X / RSCHLinkSetupAttempts_2X) x 100 R-SCH setup blocks due to lack of physical resources (RSCHNoPhysRes / RSCHLinkSetupAttempt) x 100 R-SCH setup blocks due to lack of frame offset availability (RSCHNoFrameOffset / RSCHLinkSetupAttempt) x 100 R-SCH setup blocks due to reverse high speed CFDS configuration (RSCH_CFDS_HighSpeed / RSCHLinkSetupAttempt) x 100 R-SCH setup blocks due to timeout (RSCHTimeout / RSCHLinkSetupAttempt) x 100
CDMA
NBSS15.0
Distribution of R-SCH setup blocks The following metrics are useful in determining the contribution of each individual blocking reason toward the total number of R-SCH setup blocks. This data is best presented in the form of a pie chart. Contribution of physical resource blocks (RSCHNoPhysRes / RSCHLinkSetupBlock) x 100 Contribution of frame offset availability blocks (RSCHNoFrameOffset / RSCHLinkSetupBlock) x 100 Contribution of timeout blocks (RSCHTimeout / RSCHLinkSetupBlock) x 100 R-SCH radio link access failures The R-SCH Radio Link Access Failure Metrics represent the percentage of R-SCH Link Setup Attempts for which the resources for the R-SCH were set up successfully, but the mobile did not arrive on the R-SCH. The Radio Link Access Failure metrics can be evaluated on a per EBID basis. Overall R-SCH radio link access failures (RSCHRadioLinkAccessFailure / RSCHLinkSetupAttempt) x 100 Note: The following rate-specific R-SCH Radio Link Access Failure metrics make use of the RSCHLinkSetupSuccess_<data rate> OMs instead of the RSCHLinkSetupAttempts_<data rate> OMs in the denominator due to the fact that the RSCHRadioLinkAccessFailure_<data rate> OMs are pegged after the resources have been successfully allocated at a given rate, which may not necessarily be the original data rate requested (e.g., downgrades from 16X to 8X). Therefore, these metrics are only valid if the RSCHLinkSetupSuccess_<data rate> OM is non-zero. 16X R-SCH radio link access failures (RSCHRadioLinkAccessFailure_16X / RSCHLinkSetupSuccess_16X) x 100 8X R-SCH radio link access failures (RSCHRadioLinkAccessFailure_8X / RSCHLinkSetupSuccess_8X) x 100 4X R-SCH radio link access failures (RSCHRadioLinkAccessFailure_4X / RSCHLinkSetupSuccess_4X) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
2X R-SCH radio link access failures (RSCHRadioLinkAccessFailure_2X / RSCHLinkSetupSuccess_2X) x 100 R-SCH data rate downgrades (RSCHLinkDowngrade / RSCHLinkSetupAttempt) x 100 Distribution of successful reverse link setups by data rate The percentage of successful reverse links that are setup at 16X is expressed by the following ratio: (RSCHLinkSetupSuccess_16X / RSCHLinkSetupSuccess) x 100 The percentage of successful reverse links that are setup at 8X is expressed by the following ratio: (RSCHLinkSetupSuccess_8X / RSCHLinkSetupSuccess) x 100 The percentage of successful reverse links that are setup at 4X is expressed by the following ratio: (RSCHLinkSetupSuccess_4X / RSCHLinkSetupSuccess) x 100 The percentage of successful reverse links that are setup at 2X is expressed by the following ratio: (RSCHLinkSetupSuccess_2X / RSCHLinkSetupSuccess) x 100 Average data rate for all successful reverse link setups combined The average data rate for all successful reverse link setups combined is expressed by the following ratio: {(Percentage of successful links that are setup at 16X) x (153.6 Kbps) + (Percentage of successful links that are setup at 8X) x (76.8 Kbps) + (Percentage of successful links that are setup at 4X) x (38.4 Kbps) + (Percentage of successful links that are setup at 2X) x (19.2 Kbps)} SCH drops The SCH Drop Metrics represent the percentage of SCH Links dropped after being setup successfully. The SCH Drop metrics can be evaluated on a per EBID basis. Note: The drop related SCH link metrics account for all links (i.e., primary and handoff) using the drop related OMs from the primary OM group.
CDMA
NBSS15.0
Overall SCH drops SCHDrop / (FSCHLinkSetupSuccess + RSCHLinkSetupSuccess) (FSCHRadioLinkAccessFailure + RSCHRadioLinkAccessFailure) x 100 16X SCH drops SCHDrop_16X / (FSCHLinkSetupSuccess_16X + RSCHLinkSetupSuccess_16X) (FSCHRadioLinkAccessFailure_16X + RSCHRadioLinkAccessFailure_16X) x 100 8X SCH drops SCHDrop_8X / (FSCHLinkSetupSuccess_8X + RSCHLinkSetupSuccess_8X) - (FSCHRadioLinkAccessFailure_8X + RSCHRadioLinkAccessFailure_8X) x 100 4X SCH drops SCHDrop_4X / (FSCHLinkSetupSuccess_4X + RSCHLinkSetupSuccess_4X) - (FSCHRadioLinkAccessFailure_4X + RSCHRadioLinkAccessFailure_4X) x 100 2X SCH drops SCHDrop_2X / (FSCHLinkSetupSuccess_2X + RSCHLinkSetupSuccess_2X) - (FSCHRadioLinkAccessFailure_2X + RSCHRadioLinkAccessFailure_2X) x 100 F-SCH primary link setup request retract rate The percentage of 2X F-SCH Link setup requests being retracted is expressed by the following ratio: (FSCH_RequestRetract_2X / FSCHLinkSetupAttempts_2X) x 100 The percentage of 4X F-SCH Link setup requests being retracted is expressed by the following ratio: (FSCH_RequestRetract_4X / (FSCHLinkSetupAttempts_4X FSCHLinkSetupAttempts_Change_4X) x 100 The percentage of 8X F-SCH Link setup requests being retracted is expressed by the following ratio: (FSCH_RequestRetract_8X / (FSCHLinkSetupAttempts_8X FSCHLinkSetupAttempts_Change_8X) x 100 The percentage of 16X F-SCH Link setup requests being retracted is expressed by the following ratio:
411-2133-525
Standard
06.12
April 2008
Nortel Networks
(FSCH_RequestRetract_16X / (FSCHLinkSetupAttempts_16X FSCHLinkSetupAttempts_Change_16X) x 100 The percentage of overall F-SCH Link setup requests being retracted is expressed by the following ratio: (FSCH_RequestRetract_2X + FSCH_RequestRetract_4X + FSCH_RequestRetract_8X + FSCH_RequestRetract_16X) / (FSCHLinkSetupAttempts_2X + FSCHLinkSetupAttempts_4X + FSCHLinkSetupAttempts_8X + FSCHLinkSetupAttempts_16X FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 Percentage of F-SCH primary link setup attempts data rate change Once a F-SCH Link Setup Request is queued by the scheduler at the BTS, if there is contention on BSC resources by other forward bursts, the BSC Fair Share algorithm could downgrade the data rate for the previously queued F-SCH setup request at the BTS scheduler. The percentage of 4X F-SCH Link setup requests that had their data rate changed to a lower rate (as explained above) is expressed by the following ratio: FSCHLinkSetupAttempts_Change_4X / (FSCHLinkSetupAttempts_4X FSCHLinkSetupAttempts_Change_4X) x 100 The percentage of 8X F-SCH Link setup requests that had their data rate changed to a lower rate (as explained above) is expressed by the following ratio: FSCHLinkSetupAttempts_Change_8X / (FSCHLinkSetupAttempts_8X FSCHLinkSetupAttempts_Change_8X) x 100 The percentage of 16X F-SCH Link setup requests that had their data rate changed to a lower rate (as explained above) is expressed by the following ratio: FSCHLinkSetupAttempts_Change_16X / (FSCHLinkSetupAttempts_16X FSCHLinkSetupAttempts_Change_16X) x 100 The percentage of overall F-SCH Link setup requests that had their data rate changed to a lower rate (as explained above) is expressed by the following ratio:
(FSCHLinkSetupAttempts_Change_4X + FSCHLinkSetupAttempts_Change_8X + FSCHLinkSetupAttempts_Change_16X) / (FSCHLinkSetupAttempts_4X + FSCHLinkSetupAttempts_8X + FSCHLinkSetupAttempts_16X FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X) x 100 F-SCH link upgrade release rate Prior to upgrading the data rate for a forward burst, all the links for that forward burst have to be released first, and then the burst is re-established at a higher data rate. The percentage of 2X F-SCH Links being released (prior to data rate upgrade) is expressed by the following ratio: (FSCH_UpgradeRelease_2X_To_4X / FSCHLinkSetupSuccess_2X) x 100 Note: The FSCH_UpgradeRelease_2X_To_4X OM in the above metric actually represents all 2X F-SCH upgrade related releases including events when the data rate upgrade would be 8X or 16X. The percentage of 4X F-SCH Links being released (prior to data rate upgrade) is expressed by the following ratio: (FSCH_UpgradeRelease_4X_To_8X / FSCHLinkSetupSuccess_4X) x 100 Note: The FSCH_UpgradeRelease_4X_To_8X OM in the above metric actually represent all 4X F-SCH upgrade related releases including events when the data rate upgrade would be 16X. The percentage of 8X F-SCH Links being released (prior to data rate upgrade) is expressed by the following ratio: (FSCH_UpgradeRelease_8X_To_16X / FSCHLinkSetupSuccess_8X) x 100 The percentage of overall F-SCH Links being released (prior to data rate upgrade) is expressed by the following ratio: (FSCH_UpgradeRelease_2X_To_4X + FSCH_UpgradeRelease_4X_To_8X + FSCH_UpgradeRelease_8X_To_16X) / (FSCHLinkSetupSuccess_2X + FSCHLinkSetupSuccess_4X + FSCHLinkSetupSuccess_8X) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
F-SCH link release rate due to contention for BTS resources When burst preemption is triggered at the BTS, the BTS asks the BSC to terminate links active beyond a certain minimum active time (defined by the MinActiveTimer parameter) when there are other link requests that require resources. The following metrics are useful in determining the percentage of links taken down due to BTS resource contention. Excessive values may indicate a need to add additional BTS resources or modify RRM parameters. The percentage of 2X F-SCH Links released due to contention for BTS resources is expressed by the following ratio: (FSCH_BTS_Release_2X / FSCHLinkSetupSuccess_2X) x 100 Note: The release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. The percentage of 4X F-SCH Links released due to contention for BTS resources is expressed by the following ratio: (FSCH_BTS_Release_4X / FSCHLinkSetupSuccess_4X) x 100 The percentage of 8X F-SCH Links released due to contention for BTS resources is expressed by the following ratio: (FSCH_BTS_Release_8X / FSCHLinkSetupSuccess_8X) x 100 The percentage of 16X F-SCH Links released due to contention for BTS resources is expressed by the following ratio: (FSCH_BTS_Release_16X / FSCHLinkSetupSuccess_16X) x 100 The percentage of overall F-SCH Links released due to contention for BTS resources is expressed by the following ratio: (FSCH_BTS_Release_2X + FSCH_BTS_Release_4X + FSCH_BTS_Release_8X + FSCH_BTS_Release_16X) / (FSCHLinkSetupSuccess) x 100 F-SCH link release rate due to lack of BTS resources for new strong links When the current Fwd SCH active set pilots are no longer viable (i.e. are weak) and BTS resources (for new SCH links) could not be setup on the stronger pilots as selected by the SCH active management algorithm, the current F-SCH links are released in order to be able to bring back up the forward burst on the strong pilots.
CDMA
NBSS15.0
The percentage of 2X F-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (FSCH_PilotRelease_2X / FSCHLinkSetupSuccess_2X) x 100 The percentage of 4X F-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (FSCH_PilotRelease_4X / FSCHLinkSetupSuccess_4X) x 100 The percentage of 8X F-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (FSCH_PilotRelease_8X / FSCHLinkSetupSuccess_8X) x 100 The percentage of 16X F-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (FSCH_PilotRelease_16X / FSCHLinkSetupSuccess_16X) x 100 The percentage of overall F-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (FSCH_PilotRelease_2X + FSCH_PilotRelease_4X + FSCH_PilotRelease_8X + FSCH_PilotRelease_16X) / (FSCHLinkSetupSuccess) x 100 R-SCH link release rate due to contention for BTS resources The percentage of 2X R-SCH Links released due to contention for BTS resources is expressed by the following ratio: (RSCH_BTS_Release_2X / RSCHLinkSetupSuccess_2X) x 100 Note: The release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. The percentage of 4X R-SCH Links released due to contention for BTS resources is expressed by the following ratio: (RSCH_BTS_Release_4X / RSCHLinkSetupSuccess_4X) x 100 The percentage of 8X R-SCH Links released due to contention for BTS resources is expressed by the following ratio: (RSCH_BTS_Release_8X / RSCHLinkSetupSuccess_8X) x 100 The percentage of 16X R-SCH Links released due to contention for BTS resources is expressed by the following ratio:
411-2133-525 Standard 06.12 April 2008
Nortel Networks
(RSCH_BTS_Release_16X / RSCHLinkSetupSuccess_16X) x 100 The percentage of overall R-SCH Links released due to contention for BTS resources is expressed by the following ratio: (RSCH_BTS_Release_2X + RSCH_BTS_Release_4X + RSCH_BTS_Release_8X + RSCH_BTS_Release_16X) / (RSCHLinkSetupSuccess) x 100 R-SCH link release rate due to lack of BTS resources for new strong links When the current reverse SCH active set pilots are no longer viable (i.e. are weak) and BTS resources (for new SCH links) could not be setup on the stronger pilots as selected by the SCH active management algorithm, the current R-SCH links are released in order to be able to bring back up the reverse burst on the strong pilots. The percentage of 2X R-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (RSCH_PilotRelease_2X / RSCHLinkSetupSuccess_2X) x 100 The percentage of 4X R-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (RSCH_PilotRelease_4X / RSCHLinkSetupSuccess_4X) x 100 The percentage of 8X R-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (RSCH_PilotRelease_8X / RSCHLinkSetupSuccess_8X) x 100 The percentage of 16X R-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (RSCH_PilotRelease_16X / RSCHLinkSetupSuccess_16X) x 100 The percentage of overall R-SCH Links released due to lack of BTS resources (for new strong pilots) is expressed by the following ratio: (RSCH_PilotRelease_2X + RSCH_PilotRelease_4X + RSCH_PilotRelease_8X + RSCH_PilotRelease_16X) / (RSCHLinkSetupSuccess) x 100 Additional information R-P link Some of the PCU OMs provide information such as, how successful signalling messages are being exchanged between PCU and PDSN, L2TP tunnel failures due to failure of reliable packet transmission, etc.
Following is a list of OMs which can be useful for measuring performance of R-P link between PCU and PDSN: ReliablePacketSentSuccess, ReliablePacketReTransmitted, ReliablePacketReceived, NumberOfTunnelFailures, TotalUnreliableBytesTransmitted, TotalUnreliableBytesReceived, TotalFwdPacketsDropped, TotalRevPacketsDropped. DCR and RR buffers The DormantDCR_QueueAtD2A_* OMs make up a histogram that informs the operator as to the amount of data in the Dormant DCR queue while awaiting setup of radio resources when calls transition from Dormant to Active. The histogram bins are in 10% increments and samples are taken only at network initiated Dormant to Active transitions. The samples are taken as the percentage of queue full, i.e. (current queue depth / total queue length) * 100%. Sampling is performed on the data currently residing in the Dormant DCR queue, at the time the transition request arrives. The sum of the number of pegs over all of the bins reflects the number of Dormant to Active transitions during that OM reporting period. If the higher bins (e.g. DormantDCR_QueueAtD2A_90, DormantDCR_QueueAtD2A_100) peg consistently more than the lower ones, the MaxSecondsToBufferDataCall parameter in the PCU (BSC only the Dormant DCR buffer size on the EBSC is fixed) may need to be increased to prevent buffer overflow and data loss while the radio resources are being established. Four OMs track the overall Active session peak queue depth and average queue depth in the forward (DCR) and reverse (RR) directions and are expressed as a percentage of the total queue consumed. The PeakActiveDCR_QueueDepth and PeakActiveRR_QueueDepth OMs represent the largest queue depth percentage observed across all sessions within the entire 30 minute collection interval. The AvgActiveDCR_QueueDepth and AvgActiveRR_QueueDepth OMs represent the sum of the queue depths across all sessions divided by the number of samples taken in the 30 minute collection interval. Sampling for peak and average queue depth occurs periodically (every 100ms) across all active sessions. If the peak and average values are consistently high, it may be necessary to adjust the values of the MaxSecondsToBufferDataCall (BSC), FwdBufferSize (EBSC), or RevBufferSize (EBSC) parameters to avoid buffer overflow and potential loss of data. High value peaks in conjunction with low to mid-value averages that occur intermittently indicate occasional spikes that may not require action to be taken. When the DCRBufferOverflows or RRBufferOverflows show high values, then there may be a need to reconfigure DCR and RR buffer sizes.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
For more information about the parameters mentioned, see Nortel CDMA Performance Management -- Operational Guidelines (411-2133-526). RLP buffers The FwdRLPQ_BurstRequestDepth_* OMs provide a histogram of forward RLP queue depth (in bytes) at the time SCH bursts are triggered. The RLP Queues rolling average queue depth is noted at the time an SCH burst is requested and this value is used to increment the appropriate histogram bin. Since bursts can only be requested when the periodic processing of the queues is triggered, it is likely that the rolling average at these times is not exactly equal to one of the burst data rate thresholds, but rather somewhere between the various threshold values. This histogram shows the distribution of these queue depth averages. For more information about the histogram bin sizes, see BSC OM descriptions (page 22-1). This histogram provides a view of how much data is arriving in the Forward RLP queue before an SCH is allocated to the data call. There is no guarantee that the burst request is granted as there may be contention for resources, the rate may be downgraded, or the burst may fail to be set up between the BTS and the mobile. This histogram allows the operator to fine tune the BufferThreshold_<data rate> parameters that control which rate is initially requested based on the amount of incoming data. The FwdRLPQ_SCH_BurstPeakDepth_*, FwdRLPQ_SCH_BurstAvgDepth_*, RevRLPQ_SCH_BurstPeakDepth_*, and RevRLPQ_SCH_BurstAvgDepth_* OMs track the peak and average RLP queue depths for each data rate and each direction while a burst is in progress. If the OMs for a given rate indicate over- or under- utilization of the SCH resource, then the BufferThreshold_<data rate> parameters may need to be adjusted. These OMs are also useful in conjunction with the DCRNumOfStopTransmitMsgsSent at the PCU to aid in setting the FwdBufferSize, RevBufferSize, FwdBuffer_High, and FwdBuffer_Low parameters in the RLPQParameters field of the SelectorSubsystem and DSInterface. For more information about the parameters mentioned, see Nortel CDMA Performance Management -- Operational Guidelines (411-2133-526).
Validation
3
Since a SCH setup may span two 30 minute OM periods, a slight discrepancy may be possible in these sections (i.e., the SCH setup attempt may be captured at the end of one OM period while the SCH setup success or nonsuccess is captured at the beginning of the next OM period). Also some race conditions could account for a slight discrepancy. For example, the burst may be retracted from one sector but successfully setup in the another sector. In
this case, retract OM is pegged as well as success OM is pegged. The OMs used in any one of the following formulas must be from only either BSC or EBSC. Validation of forward burst setup OMs Attempts = Successes + Non Successes Attempts = FwdBurstSetupAttempts Successes = FwdBurstSetupSuccesses Non Successes= FwdBurstSetupFailures + Sum of (FSCH_RequestRetract_2X + FSCH_RequestRetract_4X + FSCH_RequestRetract_8X + FSCH_RequestRetract_16X) for all EBIDs Note 1: If the BSC contains both SBS and CPDS subsystems, then the specified FwdBurstSetup OM will be the sum of both the SBS and CPDS FwdBurstSetup node-based OMs. The Retract OMs are collected on a per-EBID basis and will include pegs from both the SBS and CPDS. Note 2: In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required. In the above Validation Formula this case would cause a mismatch between the LHS and RHS. In addition: FwdBurstSetupAttempts = FwdBurstBSC_Downgrade + FwdBurstBSC_NonDowngrade - FwdBurstBSC_DowngradeChange - FwdBurstBSC_NonDowngradeChange FwdBurstSetupAttempts = FwdBurstSetupAttempts_2X + FwdBurstSetupAttempts_4X + FwdBurstSetupAttempts_8X + FwdBurstSetupAttempts_16X FwdBurstSetupSuccesses = FwdBurstSetupSuccesses_2X + FwdBurstSetupSuccesses_4X + FwdBurstSetupSuccesses_8X + FwdBurstSetupSuccesses_16X FwdBurstSetupFailures = FwdBurstSetupFailures_2X + FwdBurstSetupFailures_4X + FwdBurstSetupFailures_8X + FwdBurstSetupFailures_16X The following formula is for CPDS only: FwdBurstSetupAttempts_16X = FwdBurstNonDowngrade_16X + FwdBurstDowngrade_16X_To_8X + FwdBurstDowngrade_16X_To_4X + FwdBurstDowngrade_16X_To_2X FwdBurstNonDowngradeChange_16X 411-2133-525 Standard 06.12 April 2008
Nortel Networks
FwdBurstDowngradeChange_16X_To_8X FwdBurstDowngradeChange_16X_To_4X The following formula is for CPDS only: FwdBurstSetupAttempts_8X = FwdBurstNonDowngrade8X + FwdBurstDowngrade_8X_To_4X + FwdBurstDowngrade_8X_To_2X FwdBurstNonDowngradeChange_8X FwdBurstDowngradeChange_8X_To_4X The following formula is for CPDS only: FwdBurstSetupAttempts_4X = FwdBurstNonDowngrade_4X + FwdBurstDowngrade_4X_To_2X FwdBurstNonDowngradeChange_4X The following formula is for CPDS only. FwdBurstSetupAttempts_2X = FwdBurstNonDowngrade_2X The following formula is for CPDS only: FwdBurstBSC_DowngradeChange = FwdBurstDowngradeChange_8X_To_4X + FwdBurstDowngradeChange_16X_To_4X + FwdBurstDowngradeChange_16X_To_8X The following formula is for CPDS only: FwdBurstBSC_NonDowngradeChange = FwdBurstNonDowngradeChange_4X + FwdBurstNonDowngradeChange_8X + FwdBurstNonDowngradeChange_16X Fwd Burst Upgrade Attempts = Upgrade Successes + Upgrade Failures Fwd Burst Upgrade Attempts = FwdBurstUpgradeAttempts_2X_To_4X + FwdBurstUpgradeAttempts_2X_To_8X + FwdBurstUpgradeAttempts_2X_To_16X + FwdBurstUpgradeAttempts_4X_To_8X + FwdBurstUpgradeAttempts_4X_To_16X + FwdBurstUpgradeAttempts_8X_To_16X Fwd Burst Upgrade Successes = FwdBurstUpgradeSuccesses_2X_To_4X + FwdBurstUpgradeSuccesses_2X_To_8X + FwdBurstUpgradeSuccesses_2X_To_16X + FwdBurstUpgradeSuccesses_4X_To_8X +
CDMA
NBSS15.0
FwdBurstUpgradeSuccesses_4X_To_16X + FwdBurstUpgradeSuccesses_8X_To_16X Fwd Burst Upgrade Failures = FwdBurstUpgradeFailures_2X_To_4X + FwdBurstUpgradeFailures_2X_To_8X + FwdBurstUpgradeFailures_2X_To_16X + FwdBurstUpgradeFailures_4X_To_8X + FwdBurstUpgradeFailures_4X_To_16X + FwdBurstUpgradeFailures_8X_To_16X Validation of reverse burst setup OMs RevBurstSetupAttempts = RevBurstSetupSuccesses + RevBurstSetupFailures Note: In very rare cases it is possible that a Burst Setup request is made at the BSC and before fairshare allocates the resources, the Burst is no longer required. In the above Validation Formula this case would cause a mismatch between the LHS and RHS. In addition: RevBurstSetupAttempts = RevBurstBSC_Downgrade + RevBurstBSC_NonDowngrade RevBurstSetupAttempts = RevBurstSetupAttempts_2X + RevBurstSetupAttempts_4X + RevBurstSetupAttempts_8X + RevBurstSetupAttempts_16X RevBurstSetupSuccesses = RevBurstSetupSuccesses_2X + RevBurstSetupSuccesses_4X + RevBurstSetupSuccesses_8X + RevBurstSetupSuccesses_16X RevBurstSetupFailures = RevBurstSetupFailures_2X + RevBurstSetupFailures_4X + RevBurstSetupFailures_8X + RevBurstSetupFailures_16X The following formula is for CPDS only: RevBurstSetupAttempts_16X = RevBurstNonDowngrade16X + RevBurstDowngrade_16X_To_8X + RevBurstDowngrade_16X_To_4X + RevBurstDowngrade_16X_To_2X The following formula is for CPDS only: RevBurstSetupAttempts_8x = RevBurstNonDowngrade8X + RevBurstDowngrade_8X_To_4X + RevBurstDowngrade_8X_To_2X
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following formula is for CPDS only: RevBurstSetupAttempts_4X = RevBurstNonDowngrade_4X + RevBurstDowngrade_4X_To_2X The following formula is for CPDS only. RevBurstSetupAttempts_2X = RevBurstNonDowngrade_2X Validation of F-SCH primary link setup OMs Attempts = Successes + Failures + Retracts Attempts = FSCHLinkSetupAttempt FSCHLinkSetupAttempts_Change_4X FSCHLinkSetupAttempts_Change_8X FSCHLinkSetupAttempts_Change_16X Successes = FSCHLinkSetupSuccess Failures = FSCHLinkSetupBlock Retracts= FSCH_RequestRetract_2X + FSCH_RequestRetract_4X + FSCH_RequestRetract_8X + FSCH_RequestRetract_16X In addition: FSCHLinkSetupAttempt = FSCHLinkSetupAttempts_2X + FSCHLinkSetupAttempts_4X + FSCHLinkSetupAttempts_8X + FSCHLinkSetupAttempts_16X FSCHLinkSetupBlock = FSCHLinkSetupBlock_2X + FSCHLinkSetupBlock_4X + FSCHLinkSetupBlock_8X + FSCHLinkSetupBlock_16X FSCHLinkSetupSuccess = FSCHLinkSetupSuccess_2X + FSCHLinkSetupSuccess_4X + FSCHLinkSetupSuccess_8X + FSCHLinkSetupSuccess_16X FSCHRadioLinkAccessFailure = FSCHRadioLinkAccessFailure_2X + FSCHRadioLinkAccessFailure_4X + FSCHRadioLinkAccessFailure_8X + FSCHRadioLinkAccessFailure_16X FSCHLinkSetupBlock = FSCHNoFwdPower + FSCHNoWalshCode + FSCHNoPhysRes + FSCHNoFrameOffset + FSCHBackHaulExhaustion + FSCHBCNLinkExhaustion + FSCHAcnIdExhaustion + FSCHTimeout + FSCHLinkSetupBlockSW_Error Validation of F-SCH handoff link setup OMs SHO_FSCHLinkSetupAttempt = SHO_FSCHLinkSetupSuccess + SHO_ FSCHLinkSetupBlock
CDMA
NBSS15.0
In addition: SHO_FSCHLinkSetupAttempt = SHO_FSCHLinkSetupAttempts_2X + SHO_FSCHLinkSetupAttempts_4X + SHO_FSCHLinkSetupAttempts_8X + SHO_FSCHLinkSetupAttempts_16X SHO_FSCHLinkSetupBlock = SHO_FSCHLinkSetupBlock_2X + SHO_FSCHLinkSetupBlock_4X + SHO_FSCHLinkSetupBlock_8X + SHO_FSCHLinkSetupBlock_16X SHO_FSCHLinkSetupSuccess = SHO_FSCHLinkSetupSuccess_2X + SHO_FSCHLinkSetupSuccess_4X + SHO_FSCHLinkSetupSuccess_8X + SHO_FSCHLinkSetupSuccess_16X SHO_FSCHRadioLinkAccessFailure = SHO_FSCHRadioLinkAccessFailure_2X + SHO_FSCHRadioLinkAccessFailure_4X + SHO_FSCHRadioLinkAccessFailure_8X + SHO_FSCHRadioLinkAccessFailure_16X SHO_FSCHLinkSetupBlock = SHO_FSCHNoFwdPower + SHO_FSCHNoWalshCode + SHO_FSCHNoPhysRes + SHO_FSCHNoFrameOffset + SHO_FSCHBackHaulExhaustion + SHO_FSCHBCNLinkExhaustion + SHO_FSCHAcnIdExhaustion + SHO_FSCHTimeout + SHO_FSCHLinkSetupBlockSW_Error Validation of R-SCH primary link setup OMs RSCHLinkSetupAttempt = RSCHLinkSetupSuccess + RSCHLinkSetupBlock In addition: RSCHLinkSetupAttempt = RSCHLinkSetupAttempts_2X + RSCHLinkSetupAttempts_4X + RSCHLinkSetupAttempts_8X + RSCHLinkSetupAttempts_16X RSCHLinkSetupBlock = RSCHLinkSetupBlock_2X + RSCHLinkSetupBlock_4X + RSCHLinkSetupBlock_8X + RSCHLinkSetupBlock_16X RSCHLinkSetupSuccess = RSCHLinkSetupSuccess_2X + RSCHLinkSetupSuccess_4X + RSCHLinkSetupSuccess_8X + RSCHLinkSetupSuccess_16X RSCHRadioLinkAccessFailure = RSCHRadioLinkAccessFailure_2X + RSCHRadioLinkAccessFailure_4X +RSCHRadioLinkAccessFailure_8X + RSCHRadioLinkAccessFailure_16X
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RSCHLinkSetupBlock = RSCH_CFDS_HighSpeed + RSCHNoPhysRes + RSCHNoFrameOffset + RSCHTimeout + RSCHLinkSetupBlockSW_Error Validation of R-SCH handoff link setup OMs SHO_RSCHLinkSetupAttempt = SHO_RSCHLinkSetupSuccess + SHO_RSCHLinkSetupBlock In addition: SHO_RSCHLinkSetupAttempt = SHO_RSCHLinkSetupAttempts_2X + SHO_RSCHLinkSetupAttempts_4X + SHO_RSCHLinkSetupAttempts_8X + SHO_RSCHLinkSetupAttempts_16X SHO_RSCHLinkSetupBlock = SHO_RSCHLinkSetupBlock_2X + SHO_RSCHLinkSetupBlock_4X + SHO_RSCHLinkSetupBlock_8X + SHO_RSCHLinkSetupBlock_16X SHO_RSCHLinkSetupSuccess = SHO_RSCHLinkSetupSuccess_2X + SHO_RSCHLinkSetupSuccess_4X + SHO_RSCHLinkSetupSuccess_8X + SHO_RSCHLinkSetupSuccess_16X SHO_RSCHRadioLinkAccessFailure = SHO_RSCHRadioLinkAccessFailure_2X + SHO_RSCHRadioLinkAccessFailure_4X +SHO_RSCHRadioLinkAccessFailure_8X + SHO_RSCHRadioLinkAccessFailure_16X SHO_RSCHLinkSetupBlock = SHO_RSCH_CFDS_HighSpeed + SHO_RSCHNoPhysRes + SHO_RSCHNoFrameOffset + SHO_RSCHTimeout + SHO_RSCHLinkSetupBlockSW_Error Validation of SCHDrop OMs SCHDrop = SCHDrop_2X + SCHDrop_4X + SCHDrop_8X + SCHDrop_16X
CDMA
NBSS15.0
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RLP throughput performance
This chapter provides metrics for RLP throughput, which reflects how much data traffic the system is carrying, and how efficient the network is in transferring the data between the Packet Data Network (PDN) and the 3G mobiles via the BSC and BTS using the 3G Packet Data service option.
List of OMs
4
For more information about these OMs, see BSC OM descriptions (page 221) and BTS OM descriptions (page 23-1).
RLP throughput OMs BSC OMs RLP Data Throughput OM group FFCH_PhysicalFrames FSCH_PhysicalFrames _16X FSCH_RLP_DataBytes _8X FSCH_ReTxRLP_Data Bytes_4X FSCH_RLP_Frames_2 X RFCH_PhysicalFrames RSCH_PhysicalFrames _16X FSCH_PhysicalFrame s_2X FFCH_RLP_DataByte s FSCH_RLP_DataByte s_16X FSCH_ReTxRLP_Dat aBytes_8X FSCH_RLP_Frames_ 4X RSCH_PhysicalFrame s_2X RFCH_RLP_DataByte s FSCH_PhysicalFrame s_4X FSCH_RLP_DataByte s_2X FFCH_ReTxRLP_Dat aBytes FSCH_ReTxRLP_Dat aBytes_16X FSCH_RLP_Frames_ 8X RSCH_PhysicalFrame s_4X RSCH_RLP_DataByte s_2X FSCH_PhysicalFram es_8X FSCH_RLP_DataByt es_4X FSCH_ReTxRLP_Da taBytes_2X FFCH_RLP_Frames FSCH_RLP_Frames _16X RSCH_PhysicalFram es_8X RSCH_RLP_DataByt es_4X
sheet 1 of 2
CDMA
NBSS15.0
4-2 RLP throughput performance Nortel Networks
RLP throughput OMs (continued) BSC OMs RSCH_RLP_DataBytes _8X RSCH_ReTxRLP_Data Bytes_4X RSCH_RLP_Frames_2 X FFCH_RLP_OverheadF rames MCBTS OMs Advanced Sector MO FrameCntFCH FrameCntFwdSCH_16X PrimaryFrameCntFwdS CH_8X FrameCntRevSCH_8X PrimaryFrameCntRevS CH_8X FrameCntFwdSCH_2 X PrimaryFrameCntFCH PrimaryFrameCntFwd SCH_16X FrameCntRevSCH_16 X PrimaryFrameCntRev SCH_16X
sheet 2 of 2
RSCH_RLP_DataByte s_16X RSCH_ReTxRLP_Dat aBytes_8X RSCH_RLP_Frames_ 4X FFCH_RLP_ZeroPayl oadFrames
RFCH_ReTxRLP_Dat aBytes RSCH_ReTxRLP_Dat aBytes_16X RSCH_RLP_Frames_ 8X RFCH_RLP_Overhea dFrames
RSCH_ReTxRLP_D ataBytes_2X RFCH_RLP_Frames RSCH_RLP_Frames _16X RFCH_RLP_ZeroPa yloadFrames
FrameCntFwdSCH_4 X PrimaryFrameCntFwd SCH_2X FrameCntRevSCH_2X PrimaryFrameCntRev SCH_2X
FrameCntFwdSCH_ 8X PrimaryFrameCntFw dSCH_4X FrameCntRevSCH_4 X PrimaryFrameCntRe vSCH_4X
Note: The FFCH_PhysicalFrames OM is different from the FrameCntFCH BTS OM. Unlike the FrameCntFCH BTS OM, the FFCH_PhysicalFrames OM does not get pegged during pure signaling frames (e.g. during Universal Handoff Direction Message UHDM related frames). Also the FFCH_PhysicalFrames OM start getting pegged from the beginning of the RLP3 link establishment between the SBS and the mobile (after the RP packet session has already been successfully set up).
RLP throughput performance metrics
Note: In the formulas throughout the chapter, 8 is referring to the 8 bits in one byte, and 20 is referring to the 20 msec frame duration, unless otherwise specified.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RLP throughput performance 4-3 Copyright 2008 Nortel Networks
Aggregate sector throughput (per EBID basis) This metric measures the aggregate sector throughput for all users combined in the specific carrier-sector (i.e. EBID) at the RLP layer (i.e. this metric excludes RLP overhead and retransmission). This metric represents the average aggregate sector throughput during the entire OM report interval, and does not indicate the peak aggregate throughput that may occur during simultaneous bursting of the data calls. It is useful in provisioning data resources in network and for optimizing RRM settings. Formula for the forward link aggregate sector throughput metric is: {((FFCH_RLP_DataBytes + FSCH_RLP_DataBytes_16X + FSCH_RLP_DataBytes_8X + FSCH_RLP_DataBytes_4X + FSCH_RLP_DataBytes_2X) x 8) / (1,000)} / 1,800 1,800 in the above formula represents how many seconds in a 30 minutes OM report interval. If the above metric is to be evaluated over a longer period (i.e. over the busy hour or on a daily basis), then the corresponding number of seconds need to be used in the above formula. Also the OMs have to be summed up over the total period Similarly for the reverse link: {((RFCH_RLP_DataBytes + RSCH_RLP_DataBytes_16X + RSCH_RLP_DataBytes_8X + RSCH_RLP_DataBytes_4X + RSCH_RLP_DataBytes_2X) x 8) / (1,000)} / 1,800 IMPORTANT In sectors that are datafilled as logical ISSHO cells in other BSCs (CONNTYPE = ISSHOTR and CELLTYPE = standard in BSMCI table PDB), the calculated aggregate sector throughput will be lower than its actual value if OMs from only the home BSC are used. To accurately calculate the aggregate sector throughput for these sectors, OMs from all BSCs in which the EBID is datafilled need to be used. The BSC collects OMs for every cell that is datafilled in the pilot database, whether that cell physically belongs to that BSC, or that cell is a logical cell used to support ISSHO/IBSHO. Therefore, if a BTS is homed off of BSC1 and is an ISSHO cell for BSC2, and if during the OM reporting period, data is sent to a carrier-sector on that BTS from both BSC1 and BSC2 (a session started in BSC2 and handed off to the BTS as the user moved through the network), the *_DataBytes OMs will peg for that EBID on both BSCs depending on which BSC was supporting the data sessions at the time. The OMs are reported to each separate BSSM supporting those BSCs. To
CDMA
NBSS15.0
accurately calculate the aggregate sector throughput for that sector, the *_DataBytes OMs from BSC1 and BSC2 would need to be added together. It is important to note that in sectors with relatively low data penetration or usage, the values of these metrics may be quite low. This is due to the fact that the system may not be receiving or sending data 100% of the time during the OM collection interval. To illustrate, consider these two situations: Carrier-sector X sends 3.6MB of data to its users over 30 minutes in a continuous stream. The aggregate sector throughput is then (3,600,000 x 8)/(1800 x 1000) = 16 kbps. Carrier-sector Y sends the same 3.6MB of data to its users in several short bursts over the 30 minute period instead of in one long stream, leaving 25 minutes during the period during which no data is sent. The aggregate sector throughput is the same as in the first situation (16 kbps), although the throughput for any given burst in which data was being sent may be many times higher. For example, if all 3.6M gets sent in five minutes, the throughput is 96kbps, but this may be difficult or impossible to determine since the data may not have been sent over five contiguous minutes. This example illustrates that the time data is not being sent or received tends to dilute the value of the aggregate sector throughput metric. For this reason it is especially important to examine these metrics only over a single OM reporting period, as inadvertently including time when there are no data users on the network will only further lower the value of the metric, making interpretation more difficult. It may be more useful simply to benchmark the amount of data sent during an OM reporting period over time, i.e. using only the numerator of the aggregate throughput metrics for a given OM period during the day, and graphing the data over several days to observe trends. This will remove the down time from the measurement and provide a picture of the experienced data load each sector carries instead. As data penetration and the number of data subscribers increases in the network, the throughput metrics will become more useful as data will tend to be sent or received during the entire half hour OM reporting period. As data traffic increases, the amount of down time will diminish. Per channel aggregate sector throughput (per EBID basis) This metric measures the average aggregate sector throughput on a per channel basis (i.e. FCH, 16X SCH, 8X SCH, 4X SCH, or 2X SCH) for all users combined in the specific carrier-sector at the RLP layer (i.e. this metric excludes RLP overhead and retransmission). This metric represents a per
411-2133-525
Standard
06.12
April 2008
Nortel Networks
channel breakdown of the Overall Aggregate Sector Throughput metric as described in the previous section. Formulas for the forward link per channel aggregate sector throughput metric are: Aggregate Fwd FCH Sector Throughput (in Kbps) = (FFCH_RLP_DataBytes x 8) / 1,800,000 Aggregate Fwd 16X SCH Sector Throughput (in Kbps) = (FSCH_RLP_DataBytes_16X x 8) / 1,800,000 Aggregate Fwd 8X SCH Sector Throughput (in Kbps) = (FSCH_RLP_DataBytes_8X x 8) / 1,800,000 Aggregate Fwd 4X SCH Sector Throughput (in Kbps) = (FSCH_RLP_DataBytes_4X x 8) / 1,800,000 Aggregate Fwd 2X SCH Sector Throughput (in Kbps) = (FSCH_RLP_DataBytes_2X x 8) / 1,800,000 Note that the sum of the above 5 metrics add up to the Overall Fwd Link Aggregate Sector Throughput as stated in the previous section. The formulas for the reverse direction are the same, using the RFCH* and RSCH* OMs as appropriate. IMPORTANT: In sectors that are datafilled as logical ISSHO cells in other BSCs (CONNTYPE = ISSHOTR and CELLTYPE = standard in BSMCI table PDB), the calculated per-channel aggregate sector throughput will be lower than its actual value if OMs from only the home BSC are used. To accurately calculate the aggregate sector throughput for these sectors, OMs from all BSCs in which the EBID is datafilled need to be used. For more information about this issue, see Aggregate sector throughput (per EBID basis) (page -3). As was the case for the Aggregate Sector Throughput metric, the Per-Channel Aggregate Sector Throughput values may be low in sectors with low data usage. In the previous section it was illustrated how the time during which no data is sent tends to dilute the value of the metric. As before, it may be useful to use only the values in the numerator to benchmark and graph the data load per channel over time, rather than calculate the average rate. For these per-channel metrics, it is important not to make the mistake of comparing the value of the metric to the physical channel data rate (i.e. an 8X
SCH has a physical channel data rate of 76.8 kbps) and conclude that if they are different there is something wrong with the system. These metrics present the same total data for all users over time measurement that the Aggregate Sector Throughput metric does. Here, the contribution by each channel to that overall metric is determined. To determine the per-channel throughput, as opposed to the per-channel aggregate throughput, refer to Per channel throughput (per EBID basis) (page -10). Per channel contribution to the overall aggregate sector throughput (per EBID basis) This metric measures the percentage that each channel is contributing to the overall aggregate sector throughput during the entire OM report interval. Formulas for the forward link per-channel contribution to the overall aggregate sector throughput metric are: Percentage of overall aggregate Fwd Sector Throughput due to FCH = Aggregate Fwd FCH Sector Throughput / Overall Aggregate Fwd Sector Throughput x 100% Percentage of overall aggregate Fwd Sector Throughput due to 16X SCH = Aggregate Fwd 16X SCH Sector Throughput / Overall Aggregate Fwd Sector Throughput x 100% Percentage of overall aggregate Fwd Sector Throughput due to 8X SCH = Aggregate Fwd 8X SCH Sector Throughput / Overall Aggregate Fwd Sector Throughput x 100% Percentage of overall aggregate Fwd Sector Throughput due to 4X SCH = Aggregate Fwd 4X SCH Sector Throughput / Overall Aggregate Fwd Sector Throughput x 100% Percentage of overall aggregate Fwd Sector Throughput due to 2X SCH = Aggregate Fwd 2X SCH Sector Throughput / Overall Aggregate Fwd Sector Throughput x 100%
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Example:
Example
15%
10% FCH contribution 25% 16X SCH contribution 8X SCH contribution 4X SCH contribution 2X SCH contribution 30%
20%
Note: The numbers stated in this example are for illustration purpose only. The formulas for the reverse direction are the same, using the Aggregate Rev FCH Sector Throughput, Aggregate Rev ** SCH Sector Throughput and Overall Aggregate Rev Sector Throughput metrics as appropriate IMPORTANT: Since the metrics in this section depend on the Aggregate Sector Throughput and Per-channel Aggregate Sector Throughput, the same caution regarding ISSHO sectors for those metrics applies here. In sectors that are datafilled as logical ISSHO cells in other BSCs (CONNTYPE = ISSHOTR and CELLTYPE = standard in BSMCI table PDB), the calculated per-channel contributions to aggregate sector throughput will be inaccurate if OMs from only the home BSC are used. To accurately calculate these metrics for these sectors, OMs from all BSCs in which the EBID is datafilled need to be used. For more information about this issue, see Aggregate sector throughput (per EBID basis) (page -3).
CDMA
NBSS15.0
Average mobile user throughput (per cluster/system basis for all given carriers) This metric estimates the average single user throughput in a given cluster/ system at the RLP layer (i.e. this metric excludes RLP overhead and retransmission). This metric represents the average single user throughput during the entire users active session, and does not indicate the peak user throughput that may be experienced during high data rate bursts. Formula for the forward link average mobile user throughput metric is: {[FFCH_RLP_DataBytes x (PrimaryFrameCntFCH / FrameCntFCH) + FSCH_RLP_DataBytes_16X x (PrimaryFrameCntFwdSCH_16X / FrameCntFwdSCH_16X) + FSCH_RLP_DataBytes_8X x (PrimaryFrameCntFwdSCH_8X / FrameCntFwdSCH_8X) + FSCH_RLP_DataBytes_4X x (PrimaryFrameCntFwdSCH_4X / FrameCntFwdSCH_4X) + FSCH_RLP_DataBytes_2X x (PrimaryFrameCntFwdSCH_2X / FrameCntFwdSCH_2X)] x 8} over all sectors / (PrimaryFrameCntFCH x 20 x 10e-3) over all sectors The BTS OMs (FrameCntFCH, PrimaryFrameCntFCH, FrameCntFwdSCH_2X, FrameCntFwdSCH_4X, FrameCntFwdSCH_8X, FrameCntFwdSCH_16X, PrimaryFrameCntFwdSCH_2X, PrimaryFrameCntFwdSCH_4X, PrimaryFrameCntFwdSCH_8X, PrimaryFrameCntFwdSCH_16X) in the above formulas should be summed up over RC3, RC4 & RC5 for data calls only. Due to soft handoff and mobility during the users active session, this metric should be evaluated on a per cluster/system basis for any given carrier(s) rather than per carrier-sector (EBID) basis. It is more accurate to evaluate this metric on a per system basis, but it can be evaluated on a per cluster basis if needed. The formula for the reverse direction are the same, using the RFCH*, RSCH*, PrimaryFrameCntRevSCH*, FrameCntRevSCH* OMs as appropriate IMPORTANT: Be careful in choosing the cluster or system (per-BSC, per-MSC, etc.) when evaluating this metric, because ISSHO/IBSHO configurations may affect the accuracy of the calculation, as follows. The actual number of data bytes sent in a given sector that is an ISSHO/ IBSHO sector for a neighboring BSC, is the sum of the *_DataBytes OMs from each BSC in which that EBID is datafilled.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
In ISSHO/IBSHO sectors, the PrimaryFrameCnt*, and FrameCnt* OMs will include those frames the BTS sent during the OM collection period that originated from both its home BSC and the neighboring BSC(s) in which it is datafilled as a logical ISSHO/IBSHO cell. If the metric is being evaluated on a per-BSC basis, the cells that support ISSHO/IBSHO for neighboring BSCs may skew the final value of the metric, as the number of data bytes may be lower than what was actually sent, the soft handoff factor in the numerator will include frames that originated from a neighboring BSC, and the PrimaryFrameCnt in the denominator will be higher due to the frames originating from the neighboring BSC. The proper number of data bytes can be determined from the OMs of the neighboring BSC as appropriate, but there are no means to separate the frame count OMs into home frames and neighbor frames. To get an accurate value of this metric, it may be necessary to examine only clusters of cells that do not include any that support ISSHO/IBSHO, or to evaluate the metric over several BSCs or systems (possibly a regional area) in order to account for all of the data bytes and frames sent.
It is extremely important when using this metric to recognize and understand the assumptions and concessions behind it as discussed in the following: The metrics assume that the sum of FCH primary frames constitutes the duration of all active data sessions. Depending upon the setting of the PCU:ActiveBufferThresholdTimer system parameter (this parameter optimizes the transition rate between the active and dormant states), the FCH may be allocated for between 5 to 20 additional seconds with no appreciable bearer data being sent. When summed over all users, it is possible the denominator in the metrics may be a larger number than the actual amount of time it took to send the data calculated in the numerator. This results in a lower calculated average throughput than what the user actually perceives. High FER or RLP retransmission rates experienced by some users will tend to lower the overall average user perceived throughput metric, especially if these users tend to use data applications on the network frequently. For more information about metrics related to retransmissions, see Per channel data-retransmission percentage (per EBID basis) (page 15). The metrics calculate the average user-perceived throughput over all users. Therefore, if the majority of users send small amounts of data intermittently, or if several users use a low-bandwidth streaming applications, the end number may seem low. It is important to remember that even though the physical layer data rate of a given data burst is X kbps, e.g. a (16X SCH+FCH) data burst is 163.2 kbps, by no means will this be the average user-perceived throughput over
the system. The data being sent over the air contains overhead information for RLP, TCP, IP, PPP, applications, etc. that will lower the user-perceived throughput. Also, different applications, server/client activities, etc. will demand different throughput requirements that may not line up exactly with the set physical channel rates, e.g. a 16X+FCH channel set (163.2 kbps) is needed for a 110 kbps streaming audio feed. Per channel throughput (per EBID basis) This metric measures the average per-channel throughput for all users combined in the specific carrier-sector at the RLP layer (i.e. this metric excludes RLP overhead and retransmission). This metric is different from the Per Channel Aggregate Sector Throughput metric described in an earlier section, as the Per Channel Throughput metric represents the average throughput for a single channel only while the channel is up. Formula for the forward link per channel throughput metrics are expressed by the following ratio: Average Fwd FCH Throughput (in Kbps) = (FFCH_RLP_DataBytes x 8) / (FFCH_PhysicalFrames x 20) Average Fwd 16X SCH Throughput (in Kbps) = (FSCH_RLP_DataBytes_16X x 8) / (FSCH_PhysicalFrames_16X x 20) Average Fwd 8X SCH Throughput (in Kbps) = (FSCH_RLP_DataBytes_8X x 8) / (FSCH_PhysicalFrames_8X x 20) Average Fwd 4X SCH Throughput (in Kbps) = (FSCH_RLP_DataBytes_4X x 8) / (FSCH_PhysicalFrames_4X x 20) Average Fwd 2X SCH Throughput (in Kbps) = (FSCH_RLP_DataBytes_2X x 8) / (FSCH_PhysicalFrames_2X x 20) The formulas for the reverse direction are the same, using the RFCH* and RSCH* OMs as appropriate. FCH throughput The calculated per-channel FCH throughput will be lower than expected and not really reflect the true throughput of the channel when it is sending bearer data. A packet data call requires that a fundamental channel be allocated in both the forward and reverse directions, even though bearer data may be sent mostly in only one direction at any given time. When the mobile is sending data generally in only one direction, the FCH in the opposite direction is allocated, but sending only overhead frames; *_PhysicalFrames will be incremented for control, fill, blank, idle, NAK, etc. frames, but *_DataBytes will not increment, as there is no bearer data sent in
411-2133-525 Standard 06.12 April 2008
Nortel Networks
these frames. When this metric is calculated, it essentially aggregates these non-data frames in with the frames from sessions that did carry bearer data, considerably lowering the final value of the metric. For example: Data call 1: 100k bytes are sent in the forward direction using FCH and 8X FSCH. Ideally, this is accomplished in 532 frames, with 10640 bytes sent over FFCH, and 89376 bytes sent over FSCH. No bearer data is sent over the RFCH. Data call 2: The same amount of data is sent in the reverse direction this time; 532 frames, 10640 bytes over RFCH, 89376 bytes over RSCH, no bearer data sent over FFCH. Taken individually, the throughput of the FFCH for data call 1 is 8 kbps, as is the throughput for the RFCH in data call 2. However, the OMs will report the following: FFCH_RLP_DataBytes = 10640, FFCH_PhysicalFrames = 532 + 532 = 1064 RFCH_RLP_DataBytes = 10640, RFCH_PhysicalFrames = 532 + 532 = 1064 The FCH Throughput metric then reports, for both the forward and reverse directions, a value 4 kbps, half the actual throughput of the FCH when it was sending bearer data. Another contributor to low calculated values of FCH throughput is the value of the ActiveBufferThresholdTimer (PCU Managed Object), which has a range of 5to 20 seconds. This is the amount of time the FCH remains allocated before the session transitions from Active to Dormant. If no data arrives during this time, then this timer will contribute between 250 to 1000 additional forward and reverse FCH_PhysicalFrames for every active session that went dormant during the OM collection period, increasing the value of the denominator in the formula and lowering the calculated value of FCH throughput. One can calculate the FCH throughput for the time during which the channel was only sending bearer data, as opposed to during the time the channel was allocated, by replacing *FCH_PhysicalFrames with *FCH_RLP_Frames in the above formulas. For more information, see Per channel throughput (per EBID basis) (page -10). It is important to remember when doing this though, that the FCH is allocated and consuming resources even though it may not be sending bearer data.
CDMA
NBSS15.0
System average per-channel throughput and cumulative system per-channel throughput (per-system) The following formulas may be used to determine the per-channel throughput on a per-system basis. As parameters that affect throughput are generally set on a per-BSC basis, it is recommended that these be calculated per-BSC. Formulas for the per channel throughput are: System Average Fwd FCH Throughput (in Kbps) = Average Fwd FCH Throughput over all sectors / Number of Sectors Where Average Fwd FCH Throughput for any given sector is given by (FFCH_RLP_DataBytes x 8) / (FFCH_PhysicalFrames x 20) as above (see FCH throughput on page 4-10) and Number of Sectors is the number of sectors carrying data traffic in the system of interest. System Average Fwd 16X SCH Throughput (in Kbps) = Average Fwd 16X SCH Throughput over all sectors / Number of Sectors System Average Fwd 8X SCH Throughput (in Kbps) = Average Fwd 8X SCH Throughput over all sectors / Number of Sectors System Average Fwd 4X SCH Throughput (in Kbps) = Average Fwd 4X SCH Throughput over all sectors / Number of Sectors System Average Fwd 2X SCH Throughput (in Kbps) = Average Fwd 2X SCH Throughput over all sectors / Number of Sectors The formulas for the reverse direction are the same, using the Average Rev FCH Throughput and Average Rev ** SCH Throughput as appropriate. The Cumulative System Per-channel Throughput is essentially a weighted average of the Per-channel Throughput. That is, the throughput of those sectors that sent more data figures into the average more significantly than the throughput of the sectors that sent very little. It is calculated using the following: Cumulative Fwd FCH Throughput (in Kbps) = ( FFCH_RLP_DataBytes over all sectors x 8) / ( FFCH_PhysicalFrames over all sectors x 20) Cumulative Fwd 16X SCH Throughput (in Kbps) = ( FSCH_RLP_DataBytes_16X over all sectors x 8) /
411-2133-525
Standard
06.12
April 2008
Nortel Networks
( FSCH_PhysicalFrames_16X over all sectors x 20) Cumulative Fwd 8X SCH Throughput (in Kbps) = ( FSCH_RLP_DataBytes_8X over all sectors x 8) / ( FSCH_PhysicalFrames_8X over all sectors x 20) Cumulative Fwd 4X SCH Throughput (in Kbps) = ( FSCH_RLP_DataBytes_4X over all sectors x 8) / ( FSCH_PhysicalFrames_4X over all sectors x 20) Cumulative Fwd 2X SCH Throughput (in Kbps) = ( FSCH_RLP_DataBytes_2X over all sectors x 8) / ( FSCH_PhysicalFrames_2X over all sectors x 20) The formulas for the reverse direction are the same, using the RFCH* and RSCH* OMs as appropriate. Per channel utilization (per EBID basis) This metric measures the per-channel bandwidth utilization by user data (i.e. How many user data RLP frames are sent on the channel versus how many RLP fill/idle frames are sent while the channel is allocated). If this metric reflects low values in a given network, datafill for the Buffer Thresholds RLP parameters need to be revisited as they may be triggering high data rate SCH bursts in cases when lower data rate SCH bursts are sufficient for the type of data applications being run. Note: All of the utilization formulas stated below are valid only with the assumption that all the mobiles making the 3G data calls in the network are capable of supporting Double-size SCH RLP frames. This should be the case with all 3G mobiles that support 16X SCH, and all 3G mobiles that use Qualcomm chipset or software Formulas for the per channel utilization are: Fwd FCH Bandwidth Utilization percentage = FFCH_RLP_Frames / FFCH_PhysicalFrames x 100% Fwd 16X SCH Bandwidth Utilization percentage = FSCH_RLP_Frames_16X / FSCH_PhysicalFrames_16X x 8 x 100% Fwd 8X SCH Bandwidth Utilization percentage = FSCH_RLP_Frames_8X / FSCH_PhysicalFrames_8X x 4 x 100% Fwd 4X SCH Bandwidth Utilization percentage = FSCH_RLP_Frames_4X / FSCH_PhysicalFrames_4X x 2 x 100% Fwd 2X SCH Bandwidth Utilization percentage =
CDMA
NBSS15.0
FSCH_RLP_Frames_2X / FSCH_PhysicalFrames_2X x 1 x 100% Note: The (8, 4, 2, & 1) factors in the above formulas, are referring to the (8, 4, 2, & 1) MUX PDU (i.e. RLP frames) within each (16X, 8X, 4X, & 2X) SCH physical frame respectively. This is the case when double-size SCH RLP frames are used. The formulas for the reverse direction are the same, using the RFCH* and RSCH* OMs as appropriate. If it is desired to know the throughput of a channel while it is only sending bearer data, one may take the Per-channel Throughput from the previous section, and divide by the Bandwidth Utilization. This would discount the overhead, and idle frames sent on the FCH (see FCH throughput (page -10)), and empty frames that are sent over the SCH when there is no longer any bearer data to send during a burst. For example: Average Fwd 2X SCH Throughput while sending data = Average Fwd 2X SCH Throughput / Fwd 2X SCH Bandwidth Utilization This may also be calculated by using the following: Fwd FCH: (FFCH_RLP_DataBytes x 8) / (FFCH_RLP_Frames x 20) Fwd 2X SCH: (FSCH_RLP_DataBytes_2X x 8) / (FSCH_RLP_Frames_2X x 20) Fwd 4X SCH: (FSCH_RLP_DataBytes_4X x 8) / (FSCH_RLP_Frames_4X x 20 / 2) Fwd 8X SCH: (FSCH_RLP_DataBytes_8X x 8) / (FSCH_RLP_Frames_8X x 20 / 4) Fwd 16X SCH: (FSCH_RLP_DataBytes_16X x 8) / (FSCH_RLP_Frames_16X x 20 / 8) The formulas for the reverse direction are the same, using the RFCH* and RSCH* OMs as appropriate. For the FCH, one can calculate the bandwidth consumed by RLP signalling and by RLP frames that contain no data, respectively, using the following formulas: Fwd FCH RLP signalling bandwidth percentage = (FFCH_RLP_OverheadFrames / FFCH_PhysicalFrames) x 100% Fwd FCH bandwidth percentage carrying zero payload frames = (FFCH_RLP_ZeroPayloadFrames / FFCH_PhysicalFrames) x 100%
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The percentages for the reverse direction may be calculated using the corresponding RFCH* OMs. If the percentage of overhead frames is particularly high, that may indicate that there are a large number of NAKs being transmitted. Check the data retransmission percentage to see if this may be the case. Per channel data-retransmission percentage (per EBID basis) This metric measures the percentage of the channel bandwidth used only for retransmission. This metric should be highly correlated with the FER in the corresponding carrier-sector (EBID). It is important to keep in mind, though, that these metrics evaluate retransmissions at the RLP level. Depending on the values of the metrics, the operator may choose to tune the various RLP parameters found in the SelectorSubsystem/DSInterface. Since re-transmitted and original bytes are pegged at the RLP level in the BSC/EBSC the following examples may be helpful in understanding how the OMs get pegged. In the forward direction, the OMs are pegged at RLP before they are sent over the air to the mobile. This makes pegging original and retransmitted bytes straightforward. Example 1: BSC sends frames 1, 2, 3, and 4 with 10 bytes each on the FFCH. Mobile receives frames 1, 2, 3, and 4. FFCH_RLP_DataBytes = 40 FFCH_ReTxRLP_DataBytes = 0 Example 2: BSC sends frames 1, 2, 3, and 4 with 10 bytes each on the FFCH. Mobile receives frames 1, 2, and 4, but not 3. Mobile sends a NAK for frame 3. BSC retransmits frame 3 and the mobile receives it. FFCH_RLP_DataBytes = 40 FFCH_ReTxRLP_DataBytes = 10 Example 3: BSC sends frames 1, 2, 3, and 4 with 10 bytes each on the FCH. Mobile receives frames 1, 2 and 4, but not 3. Mobile sends a NAK for frame 3, but the BSC never receives it. Mobile still has not received frame 3 and sends 2
CDMA
NBSS15.0
NAKs for frame 3. BSC receives the NAKs this time and retransmits frame 3 twice. Mobile receives retransmitted frame 3 twice. FFCH_RLP_DataBytes = 40 FFCH_ReTxRLP_DataBytes = 20 In the reverse direction, things are pegged slightly differently as frames are processed by RLP after being transmitted, or lost, over the air by the mobile. Example 1: Mobile sends frames 1, 2, 3, and 4 with 10 bytes each over the RFCH. BSC receives frames 1, 2, 3, and 4. RFCH_RLP_DataBytes = 40 RFCH_ReTxRLP_DataBytes = 0 Example 2: Mobile sends frames 1, 2, 3, and 4 with 10 bytes each over the RFCH. BSC receives frames 1, 2, and 4, but not 3. BSC sends a NAK for frame 3. Mobile retransmits frame 3 and the BSC receives it. RFCH_RLP_DataBytes = 40 (30 original bytes + 10 retransmitted bytes) RFCH_ReTxRLP_DataBytes = 10 Here, RFCH_RLP_DataBytes includes the 10 bytes from frame 3 that were retransmitted by the mobile since the retransmission is the first time the BSC receives those bytes. Example 3: Mobile sends frames 1, 2, 3, and 4 with 10 bytes each over the RFCH. BSC receives frames 1, 2, and 4, but not 3. BSC sends a NAK for frame 3. BSC still does not receive frame 3 and sends 2 NAKs for frame 3. Mobile retransmits frame 3 twice and the BSC receives retransmitted frame 3 twice. RFCH_RLP_DataBytes = 40 (30 original bytes + 10 retransmitted bytes) RFCH_ReTxRLP_DataBytes = 20 The first set of retransmitted frame 3 bytes are counted in RFCH_RLP_DataBytes. The second retransmitted frame 3 is not counted in RFCH_RLP_DataBytes, but only in RFCH_ReTxRLP_DataBytes.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Formula for the forward link per channel data retransmission percentage metrics are: Fwd FCH Data Retransmit percentage = FFCH_ReTxRLP_DataBytes / (FFCH_RLP_DataBytes + FFCH_ReTxRLP_DataBytes) x 100% Fwd 16X SCH Data Retransmit percentage = FSCH_ReTxRLP_DataBytes_16X / (FSCH_RLP_DataBytes_16X + FSCH_ReTxRLP_DataBytes_16X) x 100% Fwd 8X SCH Data Retransmit percentage = FSCH_ReTxRLP_DataBytes_8X / (FSCH_RLP_DataBytes_8X + FSCH_ReTxRLP_DataBytes_8X) x 100% Fwd 4X SCH Data Retransmit percentage = FSCH_ReTxRLP_DataBytes_4X / (FSCH_RLP_DataBytes_4X + FSCH_ReTxRLP_DataBytes_4X) x 100% Fwd 2X SCH Data Retransmit percentage = FSCH_ReTxRLP_DataBytes_2X / (FSCH_RLP_DataBytes_2X + FSCH_ReTxRLP_DataBytes_2X) x 100% The formulas for the reverse direction are the same, using the RFCH* and RSCH* OMs as appropriate. Average physical layer data rate while bursting This metric provides the average physical rate granted to all mobile users while bursting on a supplemental channel during the OM collection period. It provides insight into the physical bandwidth allocated to users when the data traffic level is high enough to require supplemental channels. Formula for the forward link average physical data rate while bursting is (in kbps): 9.6 x ((FSCH_PhysicalFrames_2X x 2 + FSCH_PhysicalFrames_4X x 4 + FSCH_PhysicalFrames_8X x 8 + FSCH_PhysicalFrames_16X x 16) / (FSCH_PhysicalFrames_2X + FSCH_PhysicalFrames_4X + FSCH_PhysicalFrames_8X + FSCH_PhysicalFrames_16X)) + 9.6 The formulas for the reverse direction are the same, using the RFCH* and RSCH* OMs as appropriate. Maximum bearer data throughput The maximum throughput for bearer data is not to be confused with the physical rate of the channel. There is overhead introduced at the physical, multiplex, and RLP layers that consume bandwidth, and inefficiencies in data transmission will also be reflected in lower bearer data throughput. Data may
also arrive at the BSC at a rate that is between rates, e.g. the incoming rate is 55 kbps which warrants an 8X SCH burst at 76.8 kbps, resulting in bandwidth that is allocated, but not fully used. Since this chapter focuses mostly on bearer data throughput at the RLP layer, the following table presents the maximum values that can be achieved as a point of comparison.
Maximum bearer data throughput Channel Physical Layer Rate Total Physical Layer Rate (FCH + SCH) 9.6 28.8 48.0 86.4 163.2 Maximum Bearer Data Throughput 8.0 16.8 33.6 67.2 134.4 Total Maximum Bearer Data Throughput (FCH + SCH) 8.0 24.8 41.6 75.2 142.4
FCH 2X SCH 4X SCH 8X SCH 16X SCH
9.6 19.2 38.4 76.8 153.6
Note: All units in kilobits per second
Supporting metrics for 3G data throughput performance The following metrics need to be considered when the throughput metrics are reflecting low values. Most of the following metrics are described in Call setup performance (page 21) and 1xRTT packet data performance (page 3-1): 3G Data calls penetration in the network (i.e. Volume of 3G Data calls) 3G Data calls setup failure rate (i.e. Blocking, Access Failures, RLP setup failures, R-P session setup failures) QOSPI levels of the 3G Data users The data applications that the users are running SCH Bursts setup failure/success rate SCH Bursts data rate downgrades due to ESEL Fair Share Algorithm SCH Bursts setup queuing delay due to ESEL Fair Share Algorithm SCH Link setup failure/success rate SCH data rate downgrades due to lack of BTS resources
411-2133-525
Standard
06.12
April 2008
Nortel Networks
SCH drop rate
Validation formulas
FFCH_PhysicalFrames = FFCH_RLP_OverheadFrames + FFCH_RLP_ZeroPayloadFrames + FFCH_RLPFrames RFCH_PhysicalFrames = RFCH_RLP_OverheadFrames + RFCH_RLP_ZeroPayloadFrames + RFCH_RLPFrames
CDMA
NBSS15.0
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Access robustness package performance
The Access Robustness Package (ARP) feature is an IS95B enhancement on the Nortel CDMA system added in MTX09. This feature is intended to reduce the number of access failures within the Nortel CDMA system by helping the mobile acquire a traffic channel successfully while in the access state. This document provides a list of metrics to track the performance of the Channel Assignment into Soft handoff (CASHO) and Access Handoff (ACCHO) features of the ARP package. An access failure could occur beyond the access state as call setup is not complete until the service connect completion message is received. The metrics in this chapter assess the performance of only the ARP features, and do not track the total Access Failures. For more information about OMs related to total Access Failures (up to the service connect completion stage), see Call setup performance (page 2-1).
Goal
The failure rate of CASHO attempts should be less than x%. The failure rate for ACCHO attempts should be less than y%.
List of OMs
For more information about the following OMs, see MSC OM descriptions (page 21-1)
Access robustness package performance OMs MSC OMs CAUARSCT OM group CAUCHATT CAUAHSUC CAUCHSUC CAUAHFL CAUCHFL CAUCHRLS CAUAHATT CAUAHRLS
CDMA
NBSS15.0
5-2 Access robustness package performance Nortel Networks
CDMA access robustness package performance

The following sets of formulas and metrics will help evaluate the performance of ARP on a per sector basis.
CASHO failures per sector This is helpful in determining whether the goal of the CASHO feature of ARP is met. CAUCHFL / CAUCHATT X 100 CASHO releases per sector This metric calculates the percentage of CASHO call attempts that were abandoned by the calling parties, separating them from CASHO attempts that failed. CAUCHRLS / CAUCHATT X 100 ACCHO failures per sector This will help determine if the goal of the ACCHO feature of ARP is met. CAUAHFL / CAUAHATT X 100 ACCHO releases per sector This metric calculates the percentage of ACCHO call attempts that were abandoned by the calling parties, separating them from ACCHO attempts that failed. CAUAHRLS / CAUAHATT X 100
Validation
Validation of CASHO OMs Attempts = Successes + Failures CAUCHATT for all sectors = CAUCHSUC + CAUCHFL + CAUCHRLS for all sectors Validation of ACCHO OMs Attempts = Successes + Failures CAUAHATT for all sectors = CAUAHSUC + CAUAHFL + CAUAHRLS for all sectors
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Dropped calls include only those calls which were successfully set up (arrived on the traffic channel) and were disconnected for any reason other than one of the parties in the call released the connection. For voice calls, the CM will also generate a call drop log. This log is not generated for data calls as there is no trunk in use at the MSC. Because of the greater reliability of calls inside a CDMA core coverage area, a differentiation in dropped call performance is expected between sectors inside core coverage area and outside of it (transition area where hard handoff takes place). Dropped call performance formulas may be used for performance measurements inside or outside CDMA core coverage areas. It is important to note that if the OM3G Boolean in CDMAPART is set to Y, then the dropped call performance formulas presented in this section can be evaluated for the different types of calls as described in the following list: The performance formulas stated in this section can be limited to events related to 3G voice calls only by using the OM registers involved in the formulas as follows: If an OM register is referenced that can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, only the OM register belonging to CAUSCT3V is referenced, unless otherwise explicitly stated. The performance formulas stated in this section can be limited to events related to 3G packet Data calls only by using the OM registers involved in the formulas as follows: If an OM register is referenced that can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, only the OM register belonging to CAUSCT3D is referenced, unless otherwise explicitly stated. The performance formulas stated in this section can be limited to events related to 2G voice calls only by using the OM registers involved in the formulas as follows: If an OM register is referenced that can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, only the OM register belonging to CAUCPSCT is referenced, unless otherwise explicitly stated.
CDMA
NBSS15.0
6-2 Dropped call performance Nortel Networks
The performance formulas stated in this section can be applied to events related to all types of calls together by using the OM registers involved in the formulas as follows: If an OM register is being referenced which can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, the sum of the 3 registers from each group is being referenced unless otherwise explicitly stated.
However, if the OM3G Boolean in CDMAPART is set to N, then the dropped call performance formulas can be evaluated only for all types of calls together as described in the last bullet above.
Goals for dropped call performance

Less than x% of established calls should drop while inside the core CDMA coverage area. A typical value for x is 1 or 2 percent. Less than y% of established calls should drop while outside the core CDMA coverage area. A typical value for y is 1 to 5 percent.
List of OMs For more information about the following OMs, see BSC OM descriptions (page 22-1) and BTS OM descriptions (page 23-1).
Dropped call performance OMs MSC OMs CAUCPSCT OM group CAUTSUCC CAUDROPN EBPBCPOM OM group ESBDROPR CAUMISC OM group SEFL2PVS SEFLNWK ECSDROR ESBSCSS ECSVCSS CAUOSUCC CAUHSUCC CAUDROPR
Overall dropped call rate The percentage of established calls that are dropped inside or outside core area is expressed by the following ratio: ( (CAUDROPR + CAUDROPN) for all sectors/ (CAUOSUCC + CAUTSUCC + CAUHSUCC) for all sectors) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Dropped call performance 6-3 Copyright 2008 Nortel Networks
Note 1: Since calls can start in one sector, and then move through several other sectors before possibly experiencing a drop, the above formula does not take into account the number of soft handoffs into or out of the sector. In other words, the formula only takes into account the number of calls that start in a sector and does not take into account the amount of traffic that the sector is actually serving. This could cause a problem to be hidden (when numerous handoffs out of a sector occur) or could falsely identify a problem (when numerous handoffs into the sector occur) because the relative amount of traffic being served is not taken into consideration. Therefore the Dropped Call Rate metric should not be evaluated on a per sector basis but rather on a per cluster basis or system wide basis. Note 2: When there is a change of reference sector in the FCH active set for the call, the CAU is not informed of this change unless the previous reference sector (from the CAU perspective) has been dropped from the current active set. Therefore the CAUDROPR & CAUDROPN OMs may not get pegged against the actual reference sector for the call at the time of the drop. RF related dropped call rate The percentage of established calls that are dropped inside or outside core area due to RF related issues is expressed by the following ratio: ( CAUDROPR for all sectors / (CAUOSUCC + CAUTSUCC + CAUHSUCC) for all sectors) x 100 Note: The 2 notes in the previous section apply here as well. Network related dropped call rate The percentage of established calls that are dropped due to network related issues RLM locked, TCE locked, Trunk problem or a Selector problem is expressed by the following ratio: ( CAUDROPN for all sectors / (CAUOSUCC + CAUTSUCC + CAUHSUCC) for all sectors) x 100 Note: Most of the occurrences that lead to the pegging of CAUDROPN OM register are error cases and should not happen. Additional formulas Voice call drop performance metrics on CSVS and SBS These metric formulas measure the dropped call performance due to RF and network failures on the CSVS and the SBS platforms in relation to the calls successfully setup on the respective platforms. It is also important to note that these metrics are valid when NRM is the centralized resource manager in the system.
6-4 Dropped call performance Nortel Networks
Percentage of call drops due to RF related failures CSVS ( ECSDROPR for all CAUs / ECSVCSS for all CAUs) x 100 SBS ( ESBDROPR for all CAUs / ESBSCSS for all CAUs) x 100 Percentage of call drops due to network related failures between ACP and 2pVS (( SEFL2PVS + SEFLNWK) for all CAUs / ECSVCSS for all CAUs) x 100 Recommendations CAUDROPR -Any time this OM is pegged, one possible course of action is to investigate the pilot database to ensure that all nearby pilots have been datafilled for the cell/sector in which the call was dropped. The pilot database may also be checked to verify proper configuration of the soft (and hard) handoff parameters such as T_ADD, T_DROP, T_COMP, and T_TDROP. RF testing and optimization is also appropriate. The CM generates a CLFL100 log whenever this OM is pegged for voice calls. The log does not get generated for data calls as there is no trunk in use at the MSC. For calls dropped outside the core coverage area, the OMs from section (CM Hard Handoff Measurements) can be used to determine the number of hard handoff attempts being made out of the problem cell and the crafts person can additionally verify the IS-41 networking datafill and check the IS-41 OMs for inter-system hard handoff attempts. The CM tool, MTXTRACK, can be used to see hard handoff messaging between the CM and CAU. RF testing and optimization is also appropriate. Contact Nortel Field Support. CAUDROPN -Occurrences of this OM can indicate that necessary call processing resources are not in service or can indicate that there are state mismatches between the SBS and other entities (BTS or DTC). These occurrences are error conditions and normally should not happen. The CM will generate a CLFL100 log whenever this OM is pegged for voice calls. The log does not get generated for data calls as there is no trunk in use at the MSC. Contact Nortel Field Support.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Handoff performance
This chapter provides performance information on how well the handoff mechanism is working, from the time when the need for handoff is detected until the success or failure of the handoff process is known. The OMs used to derive hard handoff performance metrics are of three types: 1. those pegged on a per-sector basis 2. those pegged on a per-route basis (i.e., for inter-system handoffs) 3. those pegged on a per-trigger basis. This chapter contains metrics related to the CDMA system soft/softer handoff performance, intra and inter-system sector-based hard handoff performance, inter-system route-based hard handoff performance, and intra and intersystem trigger-based hard handoff performance. The metrics in this chapter are based upon OMs pegged at the CM. The intersystem metrics are described specifically as being for the source or target MSC, depending on whether measurements are desired on an MTX acting as the source or target. Note that resource setup attempts only occur on the target system. The CAU also provide some OMs that are related to hard handoff performance, but the CAU OMs are designed only to measure target-side hard handoff performance for intra-system and inter-system handoffs combined. For more information, see Call setup performance (page 2-1).
CDMA
NBSS15.0
7-2 Handoff performance Nortel Networks
List of OMs
For more information about the following OMs, see MSC OM descriptions (page 21-1) and BSC OM descriptions (page 22-1).
Handoff performance OMs MSC OMs CAUCPSYS OM group CAUHSOFT
MTXIHO OM group IHO2GATT IHO2GREL IHO3VFAL IHO3DATT IHO3DREL IHO2GSUC IHO2GINT IHO3VBLK IHO3DSUC IHO3DINT IHO2GFAL IHO3VATT IHO3VREL IHO3DFAL IHOSOCHG IHO2GBLK IHO3VSUC IHO3VINT IHO3DBLK IHOSRSUC
OMMTXHO2 OM group CHOSRCAT CHOSRRLS CHOSRCSU CHONSRCR CHOBLKS CHOREJCT CHOSRCFL
OMMTXHO3 OM group EHOSATT EHOSRLS BRTDSUC BRTDNSR PBCONBLK PBCONRJT H3G2GSFL EHOSSU EHONSR BRTDBLK BRTDRJT PBCONSFL H3G2GATT H3G2GRLS EHOBLKS EHOSRJT BRTDSFL PBCONATT PBCONRLS H3G2GSUC H3G2GNSR
sheet 1 of 2
EHOSFL BRTDATT BRTDRLS PBCONSUC PBCONNSR H3G2GBLK H3G2GRJT
411-2133-525
Standard
06.12
April 2008
Nortel Networks Handoff performance OMs (continued) MSC OMs
Handoff performance 7-3 Copyright 2008 Nortel Networks
OMMTXHO4 OM group (sector, frequency based OMs pegged on hard handoff source MTX) SQECSATT SQECSRLS SQRMSATT SQRMSRLS SQRTSATT SQRTSRLS SQECSSU SQECNSR SQRMSSU SQRMNSR SQRTSSU SQRTNSR SQECBLKS SQECSRJT SQRMBLKS SQRMSRJT SQRTBLKS SQRTSRJT SQRTSFL SQRMSFL SQECSFL
NWKIVHHO OM group (route based OMs pegged on hard handoff source MTX) IVHOATTV IVHOATTD IVHOSUCV IVHOSUCD IVHOBLKV IVHOBLKD IVHOFLRV IVHOFLRD
BSC OMs Hard Handoff Trigger OM group RTDdelaytimerHHO_Atte mpts RTDdelaytimerHHO_ Triggers RTDdelaytimerHHO_ Blocks
sheet 2 of 2
Soft and softer handoff performance
The failure of a mobile to successfully complete soft handoff does not mean the call is dropped. It may mean, however, that the system must provide more RF power than is typically necessary to maintain the call. If additional RF power does not exist then the call may eventually drop. It should be noted here that the SBS/ACP does not measure any type of events for soft/softer handoff except for 1xRTT Packet Data Supplemental Channel (SCH) Handoff Radio Link Setups (see soft handoff related metrics/ OMs in SCH radio link setup (page 3-26)). For more information about soft
CDMA
NBSS15.0
handoffs, see the Advanced Sector OMs in Metro Cell BTS operational measurements (page 23-2) and BTS performance (page 9-1). The CAU does not provide any measurements for soft handoff processing. However, it does peg CAUHSOFT to track reference cell changes. Goal Less than x% of soft/softer handoffs attempted should fail. Formula Please refer to the Soft Handoff sections in you which provide the following relevant metrics: Soft Handoff Blocking Rate for 2G Voice Calls, 3G Voice Calls, 3G FCH Data Calls and 3G SCH Data Calls Average Number of FCH Handoff Links for Softer, Soft handoff links Average Number of SCH Handoff Links for Softer, Soft handoff links
Recommendations In addition to monitoring trends for FchHandoffNonBlocking2G, FchHandoffNonBlocking3GVoice, FchHandoffNonBlocking3GData, SchHandoffNonBlocking3G the following recommendations should be considered. BlockedFchHandoffs2G[0], BlockedFchHandoffs3GVoice[0], BlockedFchHandoffs3GData[0], BlockedSchHandoffs[0] - Occurrences of this performance measurement indicate lack of No Physical Resources. Either the soft handoff percentage should be reduced, or another channel card should be provisioned at the BTS. For 2G Calls XCEMs or CCEMs should be added and for 3G Call XCEM Cards should be added. BlockedFchHandoffs2G[1], BlockedFchHandoffs3GVoice[1], BlockedFchHandoffs3GData[1], BlockedSchHandoffs[1] - Occurrences of this performance measurement indicate No Forward Capacity. A number of possibilities for lack of forward capacity: Wrong data filled power control thresholds and ranges (that needs correction), high traffic (needs dedication of new sector(s)), or antenna or transmitter hardware problems (needs adjusting). Statistical trends of the PercentTimeAboveFwdHandoffBlockingThreshold and ConfiguredFwdHandoffBlockingThreshold OMs should also be tracked. BlockedFchHandoffs2G[3], BlockedFchHandoffs3GVoice[3], BlockedFchHandoffs3GData[3], BlockedSchHandoffs[3] - For 3G Voice calls if this blocking reason is consistently higher than No forward capacity, the system may be walsh code limited. In that case, the operator should consider an optimum setting for RCDA_Voice_Selection Parameter to
411-2133-525 Standard 06.12 April 2008
Nortel Networks
bias call setup using RC4 or consider setting RC4_Preferred = True to increase Walsh code availability at the expense of forward power and/or add another carrier. Please refer to NTP 411-2133-526 for RCDA (Radio Configuration Determination Algorithm). For 3G Data if this blocking reason is consistently higher than No forward capacity, the system may be walsh code limited. In that case, the operator should consider setting RC4_Preferred = True to increase Walsh code availability at the expense of forward power.
Sector based hard handoff performance
Hard handoff performance is defined here to be how well CDMA-CDMA hard handoffs and CDMA-AMPS handoffs work. This is measured by collecting the number of hard handoff attempts per sector and comparing them to the number of successful handoffs (both types) and the number of failures. In determining hard handoff performance (especially inter-system hard handoff) it is necessary to take the measurements on the CM because it is the only entity in the architecture which knows about the entire handoff process (from both the source and target-side perspectives, and especially in the case of inter-system handoffs). Goal Less than x% of all intra-system hard handoffs should fail. Less than y% of all inter-system hard handoffs should fail when the MTX is the source. Less than z% of all inter-system hard handoffs should fail when the MTX is the target.
Formula The following metrics provide system-wide hard handoff performance. It is also possible to obtain performance information with respect to a particular border system by using the cells identified as border cells to that system. To evaluate performance at this level, some knowledge of a CDMA sectors hard handoff neighbors is required. The same process of identifying the types of target cells associated with the source cells (or vice-versa) may be done to obtain lower level metrics for CDMA-CDMA (intra-system), CDMA-CDMA (inter-system), CDMA-AMPS (intra-system), and CDMA-AMPS (inter-system) hard handoff performance metrics. Note that the Source handoff metrics below apply to both AMPS and CDMA intra and intersystem calls, while the Target metrics are CDMA inter-system specific. Intra-system metric calculations for the target system To obtain an estimate of the number of intra-system HHOs occurring within the Target system from the following inter-system formulas, it is possible to subtract the related MTXIHO OMs (which peg only for inter-system HHOs) from the related CAUCPSCT/3V/3D OMs (which peg for both intra and inter-system HHOs).However, this information should only be used for
CDMA
NBSS15.0
trending purposes since the results may not represent the exact amount of intra-system HHOs within the system. Source hard handoff setup blocks (intra and inter-system) CHOBLKS for all CDMA sectors / CHOSRCAT for all CDMA sectors x 100 Source hard handoff attempt rejects (intra and inter-system) CHOREJCT for all CDMA sectors / CHOSRCAT for all CDMA sectors x 100 Source hard handoff overall failures (intra and inter-system) CHOSRCFL for all CDMA sectors / CHOSRCAT for all CDMA sectors x 100 Source hard handoff RF access failures (intra and inter-system) (CHOSRCFL - CHONSRCR) for all CDMA sectors / CHOSRCAT for all CDMA sectors x 100 Source hard handoff network failures (intra and inter-system) CHONSRCR for all CDMA sectors / CHOSRCAT for all CDMA sectors x 100 Target IHHO setup blocks for 2G voice and CSD calls (intersystem) IHO2GBLK for all CDMA sectors / IHO2GATT for all CDMA sectors x 100 Target IHHO setup blocks for 3G voice and CSD calls (intersystem) IHO3VBLK for all CDMA sectors / IHO3VATT for all CDMA sectors x 100 Target IHHO setup blocks for 3G packet data calls (inter-system) IHO3DBLK for all CDMA sectors / IHO3DATT for all CDMA sectors x 100 Target IHHO failures for 2G voice and CSD calls (inter-system) IHO2GFAL for all CDMA sectors / IHO2GINT for all CDMA sectors x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Target IHHO failures for 3G voice calls (inter-system) IHO3VFAL for all CDMA sectors / IHO3VINT for all CDMA sectors x 100 Target IHHO failures for 3G data calls (inter-system) IHO3DFAL for all CDMA sectors / IHO3DINT for all CDMA sectors x 100 Additional Formulas Target Inter-system Hard Handoff failures after SO change 1 ( IHOSRSUC for all CDMA sectors / IHOSOCHG for all CDMA sectors) x 100 The above metric tracks the number of inter-system hard handoff failures after a service option change has occurred. It is important to note that above metric is an approximation and the failure cannot be attributed to service option change. This metric value should be the same as the sum of ,Target IHHO failures for 3G voice calls (inter-system) and the call failures due to Release, under normal conditions. Validation The following formulas are valid on a system-wide basis (all CDMA sectors OMs summed together): IHO2GATT + IHO3VATT = IHO2GSUC + IHO3VSUC + IHO2GBLK + IHO3VBLK + IHO2GFAL + IHO3VFAL + IHO2GREL + IHO3VREL IHO3DATT = IHO3DSUC + IHO3DBLK + IHO3DFAL + IHO3DREL IHOSOCHG <= IHO3VATT + IHO2GATT IHOSRSUC <= IHOSOCHG The following formulas are valid for a single sector or on a system-wide basis (all CDMA sectors OMs summed together). IHO2GINT = IHO2GSUC + IHO2GFAL IHO3VINT = IHO3VSUC + IHO3VFAL IHO3DINT = IHO3DSUC + IHO3DFAL
CDMA
NBSS15.0
The following formula is valid for a single sector or on a system-wide basis (all CDMA sectors OMs summed together): CHOSRCAT = CHOSRCSU + CHOBLKS + CHOSRCFL + CHOSRRLS + CHOREJCT
Route based hard handoff performance
This section describes route related hard handoff performance for Inter Vendor Hard Handoff (IVHHO). The IVHHO performance metrics are valid only if IS880 field in the SYSCON table is set to Y. Goal Less than x% of hard handoff attempts should fail for a particular route. Less than y% of hard handoff attempts should be blocked for a particular route.
Formulas IVHHO source hard handoff setup blocks for packet data IVHOBLKD / IVHOATTD x 100 IVHHO source hard handoff setup blocks for 3G voice IVHOBLKV / IVHOATTV x 100 IVHHO source hard handoff failures for packet data IVHOFLRD / IVHOATTD x 100 IVHHO source hard handoff failures for 3G voice IVHOFLRV / IVHOATT x 100 Validation NWKIVHHO OM group Validation: Per route for packet data at SOURCE MSC IVHOATTD >= IVHOSUCD + IVHOBLKD + IVHOFLRD Per route for 3G voice at SOURCE MSC IVHOATTV >= IVHOSUCV + IVHOBLKV + IVHOFLRV
Trigger type based hard handoff performance
This section describes the hard handoff performance categorized by triggering types, such as Signal Quality Hard Handoff (SQHHO), Enhanced Hard Handoff (EHHO) and Round Trip Delay (RTD).
411-2133-525 Standard 06.12 April 2008
Nortel Networks
Goal Less than x% of hard handoff attempts should fail for a particular trigger type. Less than y% of hard handoff attempts should be blocked for a particular trigger type.
Formulas Signal quality hard handoff (SQHHO) performance SQHHO has three internal triggering mechanisms: Ec and RTDmax for IS95B+ mobile calls, and RTD for IS95A mobile calls (since Ec cannot be used for IS95A mobile calls). The following formulas provide hard handoff performance metrics for SQHHO on sector, frequency basis. Though it is possible to sum up the sector, frequency based OMs to derive the overall system wide performance metrics for SQHHO, its primary usage is for trouble shooting on specific sector, frequency of users interest. SQHHO source hard handoff setup blocks for IS95B+ mobile calls with Ec trigger SQECBLKS / SQECSATT x 100 SQHHO source hard handoff setup blocks for IS95B+ mobile calls with RTDmax trigger SQRMBLKS / SQRMSATT x 100 SQHHO source hard handoff setup blocks for IS95A mobile calls with RTD trigger SQRTBLKS / SQRTSATT x 100 SQHHO source hard handoff attempt rejects for IS95B+ mobile calls with Ec trigger SQECSRJT / SQECSATT x 100 SQHHO source hard handoff attempt rejects for IS95B+ mobile calls with RTDmax trigger SQRMSRJT / SQRMSATT x 100 SQHHO source hard handoff attempt rejects for IS95A mobile calls with RTD trigger SQRTSRJT / SQRTSATT x 100
CDMA
NBSS15.0
SQHHO source hard handoff overall failures for IS95B+ mobile calls with Ec trigger SQECSFL / SQECSATT x 100 SQHHO source hard handoff overall failures for IS95B+ mobile calls with RTDmax trigger (SQRMSFL - SQRMNSR) / SQRMSATT x 100 SQHHO source hard handoff overall failures for IS95A mobile calls with RTD trigger (SQRTFL - SQRTNSR) / SQRTSATT x 100 SQHHO source hard handoff RF access failures for IS95B+ mobile calls with Ec trigger (SQECSFL - SQECNSR) / SQECSATT x 100 SQHHO source hard handoff RF access failures for IS95B+ mobile calls with RTDmax trigger (SQRMSFL - SQRMNSR) / SQRMSATT x 100 SQHHO source hard handoff RF access failures for IS95A mobile calls with RTD trigger (SQRTFL - SQRTNSR) / SQRTSATT x 100 SQHHO source hard handoff network failures for IS95B+ mobile calls with Ec trigger SQECNSR / SQECSATT x 100 SQHHO source hard handoff network failures for IS95B+ mobile calls with RTDmax trigger SQRMNSR / SQRMSATT x 100 SQHHO source hard handoff network failures for IS95A mobile calls with RTD trigger SQRTNSR / SQRTSATT x 100 SQHHO source hard handoff attempts due to RTDmax for IS95B+ mobile calls
411-2133-525 Standard 06.12 April 2008
Nortel Networks
This metric provides the percentage information as how many hard handoff attempts are due to RTDmax. The user can derive the percentage of attempts associated with Ec by subtracting this number from 100. This metric maybe helpful to tune the configurable Ec and RTDmax thresholds. If the percentage associated with RTDmax is high while the percentage associated with Ec is low, that might imply the Ec threshold is set too high while the RTDmax threshold is set too low. SQRMSATT per sector per frequency / (SQRMSATT + SQECSATT) per sector per frequency x 100 Enhanced hard handoff performance The following formulas provide performance metrics on Enhanced Hard Handoff (EHHO) triggers for all call types combined. The OMs used in these metrics are pegged on sector, frequency basis. EHHO source hard handoff setup blocks (EHOBLKS per sector, frequency / EHOSATT per sector, frequency) x 100 EHHO source hard handoff attempt rejects (EHOSRJT per sector, frequency / EHOSATT per sector, frequency )x 100 EHHO source hard handoff RF access failures (EHOSFL - EHONSR) / EHOSATT x 100 EHHO source hard handoff network failures EHONSR / EHOSATT x 100 Pilot beacon hard handoff performance The following formulas provide performance metrics on Pilot beacon triggers for all call types combined. The OMs used in these metrics are pegged on sector, frequency basis. Pilot beacon source hard handoff setup blocks (PBCONBLK per sector, frequency / PBCONATT per sector, frequency) x 100 Pilot beacon source hard handoff attempt rejects
CDMA
NBSS15.0
(PBCONRJT per sector, frequency / PBCONATT per sector, frequency) x 100 Pilot beacon source hard handoff RF access failures ((PBCONSFL - PBCONNSR) / PBCONATT) x 100 Pilot beacon source hard handoff network failures (PBCONNSR / PBCONATT) x 100 RTD hard handoff performance The following formulas provide performance metrics on RTD triggers for all call types combined. The OMs used in these metrics are pegged on sector, frequency basis. RTD source hard handoff setup blocks (BRTDBLK per sector, frequency / BRTDATT per sector, frequency) x 100 RTD source hard handoff attempt rejects (BRTDRJT per sector, frequency/ BRTDATT per sector, frequency) x 100 RTD source hard handoff RF access failures ((BRTDSFL - BRTDNSR) / BRTDATT) x 100 RTD source hard handoff network failures (BRTDNSR / BRTDATT) x 100 3G to 2G hard handoff performance The following formulas provide performance metrics on 3G to 2G triggers for call types (3G Voice and 2G Voice) combined. The OMs used in these metrics are pegged on sector, frequency basis. 3G to 2G source hard handoff setup blocks (H3G2GBLK per sector, frequency / H3G2GATT per sector, frequency) x 100 3G to 2G source hard handoff attempt rejects
411-2133-525
Standard
06.12
April 2008
Nortel Networks
(H3G2GRJT per sector, frequency / H3G2GATT per sector, frequency) x 100 3G to 2G source hard handoff RF access failures ((H3G2GSFL - H3G2GNSR) / H3G2GATT) x 100 3G to 2G source hard handoff network failures (H3G2GNSR / H3G2GATT) x 100 Round trip delay timer performance This section only covers the hard handoff performance related to the Round Trip Delay (RTP) timer. The following metric is applicable for Border cells and Ec Cells on EBID basis. RTD source hard handoff deferred due to unexpired handoff delay timer (for all call types) RTDdelaytimerHHO_Blocks / RTDdelaytimerHHO_Attempts x 100 Validation OMMTXHO3 OM group validation EHOSATT = EHOSSU + EHOBLKS + EHOSFL + EHOSRLS + EHOSRJT BRTDATT = BRTDSUC + BRTDBLK + BRTDSFL + BRTDRLS + BRTDRJT PBCONATT = PBCONSUC + PBCONBLK + PBCONSFL + PBCONRLS + PBCONRJT H3G2GATT = H3G2GSUC+ H3G2GBLK + H3G2GSFL + H3G2GRLS + H3G2GRJT OMMTXHO4 OM group validation SQECSATT = SQECSSU + SQECBLKS + SQECSFL + SQECSRLS + SQECSRJT SQRMSATT = SQRMSSU + SQRMBLKS + SQRMSFL + SQRMSRLS + SQRMSRJT SQRTSATT = SQRTSSU + SQRTBLKS + SQRTSFL + SQRTSRLS + SQRTSRJT
CDMA
NBSS15.0
BSC OM group validation RTDdelaytimerHHO_Attempts = RTDdelaytimerHHO_Triggers + RTDdelaytimerHHO_Blocks Recommendation CHOBLKS, IHO**BLK, EHOBLKS, BRTDBLK, PBCONBLK, H3G2GBLK, SQECBLKS, SQRMBLKS, SQRTBLKS, IVHOBLKD, IVHOBLKV - Occurrences of these OMs indicate that target-side resources are causing hard handoffs to be blocked. This could be a matter of lack of resources or a matter of messaging time outs. The target-side CAU OMs (see Hard Handoff related OMs in MSC OM descriptions (page 21-1)), in the case of CDMA-CDMA handoff, or the ICPs OMs, in the case of CDMA-AMPS handoffs, can be consulted. In the case of inter-system handoffs, the IS-41 messaging OMs should be checked for problems such as reject incoming or return error incoming. CHOSRCFL, IHO**FAL, EHOSFL, BRTDSFL, PBCONSFL, H3G2GSFL, SQECSFL, SQRMSFL, SQRTSFL, IVHOFLRD, IVHOFLRV - Occurrences of these OMs indicate that the mobile was not able to acquire the target traffic channel. Contact Nortel Field Support. On the target MTX, CLFL 102 mobile ho failure logs are printed in conjunction with this occurrence. The CAUHRLFL OM is pegged on the target system as well. CHOSRRLS, IHO**RLS, EHOSRLS, BRTDRLS, PBCONRLS, H3G2GRLS, SQECSRLS, SQRMSRLS, SQRTSRLS, IVHORLSD, IVHORLSV - These OMs do not warrant corrective action, but it can be monitored to see how many subscribers hang up during the call (possibly because of the calls quality). CHONSRCR, EHONSR, BRTDNSR, PBCONNSR, H3G2GNSR, SQECNSR, SQRMNSR, SQRTNSR - Occurrences of these OMs indicate that a hard handoff attempt was aborted. Since neither the SBS/ACP nor the CM/CAU have the capability to abort a handoff (due to restoration of better RF conditions at the mobile), this type of timeout is an error condition and should not happen. RTDdelaytimerHHO_blocks - Occurrences of this OM indicate that the number of times the hard handoff have been blocked due to the delay timer. This number helps to understand how delay timer is blocking the HHOs.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Intelligent voice service negotiations performance 8

This chapter describes the intelligent voice service negotiations performance. After implementing this feature, the calls are now redirected to a operator preferred service option using Prioritized Service Option List (PSOL), table SERVSEL, SERVNEG, CDMA_PAGE_WITH_MS_CAP_INFO or CDMA_PAGE_WITHOUT_MS_CAP_INFO parameters. The following table shows possible service redirections.
Possible service redirections (from requested to assigned) From EVRCB EVRC 8K Basic_13K IS733_13K NIL (call termination only) To EVRCB, EVRC, Basic_13K, IS733_13K EVRCB, EVRC, Basic_13K, IS733_13K EVRC, Basic_13K, IS733_13K EVRCB, EVRC, Basic_13K, IS733_13K EVRCB, EVRC, Basic_13K, IS733_13K EVRCB, EVRC, Basic_13K, IS733_13K
There are three scenarios when a call may be denied using IVSN: 1. a mis-match between the mobile capability information and datafill in the table SERVNEG or parameter CDMA_PAGE_WITH_MS_CAP_INFO in table OFCVAR. The service option match is performed by CM or CAU 2. a provided service option is not supported by a mobile 3. a mobile requested service option was NIL during a call origination For more information about scenario 1, see Service redirection performance (page -3). For more information about scenario 2, see Call originations/ terminations rejected by mobiles (page -6). For more information about
CDMA
NBSS15.0
8-2 Intelligent voice service negotiations performance Nortel Networks
scenario 3, see Call originations denied due to NIL service option requested (page -6).
Goal
Successful redirections resulted in call setup to a specific service option x% of the time.
Less than y% of call originations denied due to service option mismatch. Less than z% of call terminations denied due to service option mismatch. Less than u% of call originations denied due to NIL service option requested. Less than a% of call originations/terminations failed due to a mobile rejection. Less than b% of the queries failed on a paging/access channel. Less than c% of the queries failed on a traffic channel. Note: The variables (x, y, z, u, a, b and c) can be defined in accordance with the service providers requirements.
List of OMs
For more information about the following OMs, see MSC OM descriptions (page 21-1), BSC OM descriptions (page 22-1), and BTS OM descriptions (page 23-1).
Intelligent voice service negotiations performance OMs MSC OMs CDMAIVSN OM group VNILEVR VB13KEVR VI13KI13K VEVRB13K ODENYCAU ATTB13K VB8KEVR VNILI13K VB13KI13K VI13KB13 ODENYCM ATTI13K VEVREVR VB8KI13K VNILB13K VB13KB13 TDENYCAU ATTNIL
sheet 1 of 2
VI13KEVR VEVRI13K VB8KB13K ONILDNY ATTEVRC ATTEVRC2
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Intelligent voice service negotiations performance 8-3 Copyright 2008 Nortel Networks
Intelligent voice service negotiations performance OMs (continued) MSC OMs ATTB13K2 ATTI13K2 ATTB8K
CDMIVSN2 OM group ATEVB ATEVB2
VEVREVB VEVBEVB
V13KEVB VEVBEVR
VI13EVB VEVB13K
CDSNMQRY OM group QRYPAORG QRYPAREG FLTCI13K 3GFLB13K MTXSYS1 OM group TDENYCM
VNILEVB VEVBI13K
QRYPATRM QRYPAFL FLTCB13K
QRYTCORG QRYTCFL 3GFLTEVR
QRYTCTRM FLTCEVR 3GFLI13K
FLTCEVB
sheet 2 of 2
Formulas
In this section, the performance is measured using a set of formula and metrics. Service redirection performance All OMs in this document are pegged only during call originations or terminations. They are not pegged during any type of handoffs. These OMs are also not pegged for Circuit Switch Data calls.
Here, attempts refers to those calls that the system is aware of and attempts to setup resources for. For example, the system is not aware of origination call attempts that exhaust the access probe since the origination message is lost and, hence is not received by the BTS. Service redirection to EVRC-B service option (page -4), Service redirection to EVRC service option (page -4), Service redirection to IS733 13K voice service option (page -4), and Service redirection to basic 13K voice service option (page -4) provide the performance of service redirection only. They are not meant to provide overall system performance for call setups. For more
information about system-wide call setup performance, see Call setup performance (page 2-1). These sections will indicate the service redirection to operator preferred service options and will help optimize the SERVNEG & SERVSEL tables and both office parameters used for this feature. The following set of formulae and metrics will help evaluate the performance of service redirection for a specific service option. Service redirection to EVRC-B service option Percentage of relative successful redirections to EVRC-B is expressed by the following ratio: (VNILEVB + VEVBEVB + VEVREVB + VI13KEVB + V13KEVB / VNILEVB + VEVREVB + VI13KEVB + V13KEVB + VEVBEVB + VNILEVRC + VEVBEVR + VB8KEVR + VEVREVR + VI13KEVR + VB13KEVR + VNILI13K + VEVBI13K + VB8KI13K + VEVRI13K + VI13KI13 + VB13KI13 + VNILB13K + VEVB13K + VB8KB13K + VEVRB13K + VI13KB13 + VB13KB13) x 100 Service redirection to EVRC service option Percentage of relative successful redirections to EVRC is expressed by the following ratio: (VNILEVRC + VB8KEVRC + VEVREVR + VI13KEVR + VB13KEVR + VEVBEVR / VNILEVB + VEVREVB + VI13KEVB + V13KEVB + VEVBEVB + VNILEVRC + VEVBEVR + VB8KEVR + VEVREVR + VI13KEVR + VB13KEVR + VNILI13K + VEVBI13K + VB8KI13K + VEVRI13K + VI13KI13 + VB13KI13 + VNILB13K + VEVB13K + VB8KB13K + VEVRB13K + VI13KB13 + VB13KB13) x 100 Service redirection to IS733 13K voice service option Percentage of relative successful redirections to IS733 13K voice is expressed by the following ratio: (VNILI13K + VB8KI13K + VEVRI13K + VI13KI13 + VB13KI13 + VB13KI13 / VNILEVB + VEVREVB + VI13KEVB + V13KEVB + VEVBEVB + VNILEVRC + VEVBEVR + VB8KEVR + VEVREVR + VI13KEVR + VB13KEVR + VNILI13K + VEVBI13K + VB8KI13K + VEVRI13K + VI13KI13 + VB13KI13 + VNILB13K + VEVB13K + VB8KB13K + VEVRB13K + VI13KB13 + VB13KB13) x 100 Service redirection to basic 13K voice service option Percentage of relative successful redirections to Basic 13K voice is expressed by the following ratio:
411-2133-525
Standard
06.12
April 2008
Nortel Networks
(VNILB13K + VB8KB13K + VEVRB13K + VI13KB13 + VB13KB13 / VNILEVB + VEVREVB + VI13KEVB + V13KEVB + VEVBEVB + VNILEVRC + VEVBEVR + VB8KEVR + VEVREVR + VI13KEVR + VB13KEVR + VNILI13K + VEVBI13K + VB8KI13K + VEVRI13K + VI13KI13 + VB13KI13 + VNILB13K + VEVB13K + VB8KB13K + VEVRB13K + VI13KB13 + VB13KB13) x 100 All the OMs in sections Service redirection to EVRC-B service option (page 4), Service redirection to EVRC service option (page -4), Service redirection to IS733 13K voice service option (page -4), and Service redirection to basic 13K voice service option (page -4) are pegged after call is completed. They provide the information of successful redirections and successful call set-ups. The formulas in sections Service redirection to EVRC-B service option (page -4), Service redirection to EVRC service option (page -4), Service redirection to IS733 13K voice service option (page -4), and Service redirection to basic 13K voice service option (page -4) indirectly provide the information about the overall system capacity. For example, if more calls are setup using EVRC then the system capacity may have been increased. Please also review the RMU OMs for each service option to determine blocked calls due to resource shortage. If RMU OM for no resource is higher for a service option then it indicates that some redirections to that service option were not successful. The formulas in sections Service redirection to EVRC-B service option (page -4), Service redirection to EVRC service option (page -4), Service redirection to IS733 13K voice service option (page -4), and Service redirection to basic 13K voice service option (page -4) can be used for per BSC or system-wide performance (dual BSC configuration). For system-wide performance, please add all the corresponding OMs for a service option from CDMAIVSN and CDMIVSN2 group for both the BSCs. Call origination denials Percentage of voice call origination attempts denied due to service option mismatch is expressed by the following ratio: ((ODENYCM + ODENYCAU) / ( CAUOATTS for all CDMA sectors - DCMOATT for all service options for data calls)) x 100 CAUOATTS OM can be found in CAUCPSCT OM group. DCMOATT OM can be found in MTXDCALL OM group. This ratio can be helpful in investigating a cause of call origination failures for the system. It will also help optimize the table SERVNEG and CDMA_PAGE_WITH_MS_CAP_INFO parameter. The above formula should be used for system-wide performance only. For system-wide performance, please add all the corresponding OMs from both the BSCs.
Call termination denials Percentage of voice call terminations denied due to service option mismatch is expressed by the following ratio: ((TDENYCM + TDENYCAU) / (CDMAPRS1 + CDMAPRS2 + TDENYCM - DCMTATT for all service options for data calls)) x 100 CDMAPRS1 and 2 OMs can also be found in MTXSYS1 group. DCMTATT OM can be found in MTXDCALL OM group. This ratio can be helpful in investigating a cause of call termination failures for the system. It will also help optimize the table SERVNEG and parameter CDMA_PAGE_WITH_MS_CAP_INFO in table OFCVAR. The above formula should be used for system-wide performance. For system-wide performance, please add all the corresponding OMs from both the BSCs. TDENYCM is added to the total call termination attempts to account for the calls for which MTX will not send the page request message. Also those call attempts are not pegged anywhere except TDENYCM. Call originations/terminations rejected by mobiles Percentage of voice call originations/terminations rejected by the mobiles is expressed by the following ratio (FLTCEVR + FLTCI13K + FLTCB13K + 3GFLTEVR + 3GFLI13K + 3GFLB13K + FLTCEVB) / ( CAUOATTS for all CDMA sectors) + CDPG1RES + CDPG2RES + CDPG3RES + TDENYCM - (DCMOATT - DCMTATT) for all service options for data calls)) x 100 This will help optimize the SERVSEL table. These OMs are not pegged when a mobile rejects the service option provided using the mobiles PSOL. The above formula should be used for system-wide performance only. Call originations denied due to NIL service option requested Percentage of voice call originations denied due to NIL service option requested by the mobiles is expressed by the following ratio: ONILDNY / ( CAUOATTS for all CDMA sectors - DCMOATT for all service options for data calls) x 100 This will indicate that some mobiles in the system are not properly programmed or dont support IS95 standards. The above formula can be used for per BSC or system-wide performance (dual bsc configuration). Successful call setup based on mobile requested service option These metric formulas are useful to determine the success rate of calls setup on the operator preferred SO as well as on the mobile requested SO. The
411-2133-525 Standard 06.12 April 2008
Nortel Networks
metric values should be substantially high (close to 100%) provided there are enough resources for the operator preferred service option and the MTX tables are accurately data-filled. Percentage of calls successfully setup on operator preferred EVRC-B SO is expressed by the following ratio ((VEVBEVB + VI13EVB + V13KEVB + VNILEVB + VEVREVB) / (ATEVB + ATEVB2 * 65536 + ATTEVRC + ATTEVRC2 * 65536 + ATTB13K + ATTB13K2 * 65536 + ATTI13K + ATTI13K2 * 65536 + ATTNIL + ATTB8K)) x 100 Percentage of calls successfully setup on operator preferred EVRC SO is expressed by the following ratio ((VEVREVR + VEVBEVR + VI13KEVR + VB13KEVR + VNILEVR + V8KEVB) / (ATEVB + ATEVB2 * 65536 + ATTEVRC + ATTEVRC2 * 65536 + ATTB13K + ATTB13K2 * 65536 + ATTI13K + ATTI13K2 * 65536 + ATTNIL + ATTB8K)) x 100 Percentage of calls successfully setup on operator preferred Basic 13K SO is expressed by the following ratio ((VEVRB13 + VI13KB13 + VB13KB13 + VNILB13 + V8KB13 + VEVBI13K) / (ATEVB + ATEVB2 * 65536 + ATTEVRC + ATTEVRC2 * 65536 + ATTB13K + ATTB13K2 * 65536 + ATTI13K + ATTI13K2 * 65536 + ATTNIL + ATTB8K)) x 100 Percentage of calls successfully setup on operator preferred IS 733 13K SO is expressed by the following ratio ((VEVRI13K + VEVBI13K + VI13KI13 + VB13KI13 + VNILI13 + V8KI13K) / (ATEVB + ATEVB2 * 65536 + ATTEVRC + ATTEVRC2 * 65536 + ATTB13K + ATTB13K2 * 65536 + ATTI13K + ATTI13K2 * 65536 + ATTNIL + ATTB8K)) x 100 Percentage of calls successfully setup on EVRC-B when mobile requested EVRC-B (VEVBEVB / ATEVB + ATEVB2 * 65536) x 100 Percentage of calls successfully setup on EVRC when mobile requested EVRC (VEVREVR / ATTEVRC + ATTEVRC2 * 65536) x 100 Percentage of calls successfully setup on Basic 13K when mobile requested Basic 13K (VB13KB13 / ATTB13K + ATTB13K2 * 65536) x 100 Percentage of calls successfully setup on IS 733 13K when mobile requested IS 733 13K (VI13KI13 / ATTI13K + ATTI13K2 * 65536) x 100
CDMA
NBSS15.0
Validation The validation formulas can be summarized into: (CAUOSUCC + CAUTSUCC) for all sectors = (VNILEVB + VEVBEVB + VI13KEVB + V13KEVB + VEVREVB + VEVBEVR + VNILEVRC + VB8KEVRC + VEVREVR + VI13KEVR + VB13KEVR + VEVB13K + VNILI13K + VNILB13K + VB8KI13K + VB8KB13K + VEVBI13K + VEVRI13K + VEVRB13K + VI13KI13 + VI13KB13 + VB13KI13 + VB13KB13 + DCMOCOM + DCMTCOM) The validation for ODENYCM, ODENYCAU, TDENYCAU and ONILDNY, FLTCEVR, FLTCI13K and FLTCB13K OMs can not be performed here. They can be validated in Call setup performance (page 2-1) by incorporating them in the non-successes. Recommendations The performance of Intelligent Voice Service Negotiation will be represented by the following OMs. VSO1SO2 These OMs will provide information about how well the table SERVNEG, SERVSEL and office parameters are configured. For example, by combining all the OMs which are representing redirection to a specific service option (VEVB13K + VNILB13K + VB8KB13K + VEVRB13K + VI13KB13K + VB13KB13K), it is possible to find out how many redirections are made to that service option. This will provide resource utilization information as well as configuration of tables and parameters. By combining OMs which represents the user requested service option (VEVREVB + VEVREVR + VEVRI13K + VEVRB13K), it is possible to find out how many calls are originated or terminated requesting that service option. High occurrences of these type of OMs will indicate the type of mobiles in the system. These OMs will indicate a trend of service redirection i.e. redirections to the Operator preferred service options. VSO1SO2 OMs are pegged for successful originations and terminations whenever the mobile capability information was known or unknown. So they will provide the overall performance of service redirection regardless of the query option selected.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
This types of OMs should be reviewed individually as well as combined to determine the effectiveness of the service redirection. TDENYCM Occurrences of this OM indicates that calls are being denied due to service option mismatch between mobile supported and system preferred service options during call terminations. The datafill in the CDMA_PAGE_WITH_MS_CAP_INFO tuple should be checked. In this scenario, no one OM in the system is pegged except this OM. This OM is not included in Call setup performance (page 2-1) for validation. However, it will be mentioned in that chapter to determine the Total number of call terminations received by the system. ODENYCM and ODENYCAU Occurrences of these OMs indicate that calls are denied due to service option mismatch between mobile supported and system preferred service options during call originations. The datafill in the table SERVNEG should be checked. TDENYCAU Occurrences of this OM indicate that calls are denied due to service option mismatch between mobile supported and system preferred service options during call terminations. The datafill in the table SERVNEG should be checked. ODENYCAU, TDENYCAU, ODENYCM and TDENYCM can provide very important information, such as, some service options which are requested by the mobiles are not supported by the system. This information can be useful to revisit the table SERVNEG or parameter CDMA_PAGE_WITH_MS_CAP_INFO in table OFCVAR or provision resources for those kind of service options. Whenever any denial OM is pegged in the case of SO mismatch, corresponding logs CDMA602 will be generated. It will provide information such as Call type (origination or termination), Mobile requested SO, Mobile voice service capability and System preferred SOs. By reviewing the logs, it can be determined that which service options are not supported by the system or requested by the mobiles. FLTCEVB, FLTCEVR, FLTCI13K, FLTCB13K, 3GFLTEV, 3GFLI13K and 3GFLB13K
CDMA
NBSS15.0
Occurrences of these OMs indicate that calls setups are tried and failed with these service options regardless of user requested service option. It is possible that the table SERVSEL is not data filled properly. If their value is greater than zero then there are some mobiles in the system which dont support the service options (INITSO and ALTSO) data filled in the table SERVSEL against user requested service option. Because these are call setup failure, these OMs are included for validation in Call setup performance (page 2-1). Hard handoffs Because there are no new OMs introduced for handoff failures due to service option a mobile is using not supported by the target system, some existing OM can be reviewed. The CAUHATTS, CAUHSUCC, and RMUNSO OMs should be carefully reviewed. For more information, see Call setup performance (page 2-1). Hard handoff failures can be because of some other reasons too, so please verify the corresponding OMs for failures. If HHO failure OMs due to other reasons are not high and RMUNSO is significantly high then there may be high number of HHO failures due to not supported service option. RMUNSO OM may not be pegged when normal calls are denied due to unsupported service options because in MTX09 IVSN feature, the CAU will make decision before it will request service option from the RMU. In this case, RMUNSO will only be pegged when HHO is denied because the CAU will not make any redirection or check mobiles capability and just request the resource from the RMU. Notes Because TDENYCM OM provides call denials at the system level, it is not possible to determine the performance of a BSC. In case of call failures due to a mobile not supporting system provided service options, OMs dont provide what service options was requested by mobile. A careful analysis of table SERVSEL and CDMA_PAGE_WITHOUT_MS_CAP_INFO parameter in table OFCVAR should be performed against the failure OM to determine the user requested service options. It will help make a decision if a specific SO should be provisioned in the system.
Query performance When the mobile capability is not in the VLR (not known), depending on the query option selected, a mobile will be queried on the paging/Access channel or Traffic channel during a registration, call origination or call termination. The following set of formulae and metrics will help evaluate the impact of each query option on the overall system performance and capacity.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Query performed on the paging-access channel ((QRYPAORG + QRYPATRM + QRYPAREG / QRYPAORG + QRYPATRM + QRYTCORG + QRYTCTRM + QRYPAREG)) x 100 Queries failed on the paging-access channel (QRYPAFL / QRYPAORG + QRYPATRM + QRYPAREG) x 100 Query performed on the traffic channel (QRYTCORG + QRYTCTRM / QRYPAORG + QRYPATRM + QRYTCORG + QRYTCTRM + QRYPAREG) x 100 Queries failed on the traffic channel ((QRYTCFL for a BSCl / QRYTCORG + QRYTCTRM)) x 100 The formulas in sections Query performed on the paging-access channel (page -11), Queries failed on the paging-access channel (page -11), Query performed on the traffic channel (page -11), and Queries failed on the traffic channel (page -11) are applicable to BSC performance. Recommendations Overall, the query OMs will provide the information regarding how mobiles are being queried. The query OMs will show the performance of each query options as selected. These OMs can be used to analyze the impact of query option on the system capacity and performance and will help select the appropriate query option. Note: Please keep in mind that before implementing any query option, one has to make sure that the system is capable of handling the impacts caused by it. QRYTCORG, QRYTCTRM -The sum of these OMs will provide the information about how many calls were successfully setup after using the table SERVSEL. QRYPAFL - Occurrences of this OM indicate that the queries are failing due to the paging or access channel capacity exhausted or the mobiles were in a bad RF coverage area. When this OM is pegged due to query failed during origination or termination, QRYTCORG or QRYTCTRM OM are also pegged if the mobile arrives on the traffic channel and queried. In that case, QRYTCORG or QRYTCTRM OMs indicate how many calls tried to setup using table SERVSEL (blindly redirected).
CDMA
NBSS15.0
411-2133-525
Standard
06.12
April 2008
Nortel Networks
BTS performance
This chapter provides information on different performance aspects that will assist the customer in optimizing and provisioning of BTS resources. Metro Cell BTS performance metrics provide information on Resource Blocking rate (Origination/Termination, Soft Handoff), Soft/Softer handoff Links, FSCH Queuing, SCH Link Data rate Downgrade, Walsh Code Usage Distribution, CE Usage, Forward Transmit Power Usage, Forward & Reverse common channel utilization, Forward and Reverse common channel message drop rate and MFRM-3. The performance attributes contained in logs for six of the Metro Cell BTS Managed Objects (MOs) are discussed within this chapter: BTSCallProcessing MO, Advanced FA (Frequency Assignment) MO, Advanced Sector MO, Power Management MO, RFM MO and the CBCM MO. To obtain the overall performance figures inclusive of all frequencies, the same formula can be used by summing these calculations over all appropriate carrier-sectors.
List of OMs
For more information about the following OMs, see BTS OM descriptions (page 23-1).
BTS performance OMs Metro Cell OMs Advanced FA MO OMs NumOfTCAvailable TCEUtilMaximum TotalForwardPhysical Resources SchMaximumForward PhysicalResourcesUs ed
sheet 1 of 4
CDMA
NBSS15.0
9-2 BTS performance Nortel Networks BTS performance OMs (continued) Metro Cell OMs Fch2GMaximumForwar dPhysicalResourcesUs ed Fch2GMaximumRevers ePhysicalResourcesUs ed MaxFCHVoiceResource sUsed Fch3GMaximumForw ardPhysicalResources Used Fch3GMaximumRever sePhysicalResources Used MaxFCHDataResourc esUsed
TotalReversePhysical Resources MaxFwdPhysicalReso urcesUsed
SchMaximumReverse PhysicalResourcesUs ed MaxRevPhysicalReso urcesUsed
Advanced Sector MO OMs TCEForwardLinkUtilUW Avg RadialHandoffAttempts DataFchForwardLinkUtil Average PercentTimeAboveFwd VoiceCallBlockingThres hold ConfiguredFwdVoiceCa llBlockingThreshold FchOriginationNonBloc king3GVoice FchOriginationNonBloc king3GDowngrade2GN oBcn BlockedFchOriginations 2G* BlockedFchHandoffs3G Voice* OverheadForwardLink UtilUWAvg RadialHandoffSucces ses SchForwardLinkUtilAv erage PercentTimeAboveFw dDataCallBlockingThr eshold ConfiguredFwdDataC allBlockingThreshold FchOriginationNonBlo cking3GData FchHandoffNonBlocki ng3GVoice BlockedFchHandoffs2 G* BlockedFchHandoffs3 GData* OCNSForwardLinkUtil TWAvg RadialHandoffFailures PercentTimeAboveFw dCallBlockingThreshol d ConfiguredFwdCallBlo ckingThreshold FchOriginationNonBlo cking2G FchOriginationNonBlo cking3GDowngrade2 G FchHandoffNonBlocki ng3GData BlockedFchOriginatio ns3GVoice* BlockedSchBursts* PerRingAccessCounts VoiceFchForwardLink UtilAverage PercentTimeAboveFw dHandoffBlockingThre shold ConfiguredFwdHandof fBlockingThreshold FchHandoffNonBlocki ng2G FchOriginationNonBlo cking3GDowngrade2 GNoAcn SchHandoffNonBlocki ng3G BlockedFchOriginatio ns3GData* BlockedSchHandoffs*
sheet 2 of 4
411-2133-525
Standard
06.12
April 2008
Nortel Networks BTS performance OMs (continued) Metro Cell OMs FrameCountFCH FrameCountFwdSCH_1 6X CEFrameCountFwdSC H_8X PrimaryFrameCountFw dSCH_4X FrameCountRevSCH_2 X CEFrameCountRevSC H_2X PrimaryFrameCountRe vSCH_2X PagingChannelUsageIn fo (array) FschDowngradeDueTo PhysRes (array) RschDowngradeDueTo PhysRes (array) InitialFwdSchBurstQueu ed2X * UpdateFwdSchBurstQu eued2X * DistributionOfPriorityCla ss0Delay DistributionOfPriorityCla ss4Delay DistributionOfPriorityCla ss8Delay FrameCountFwdSCH _2X CEFrameCountFCH CEFrameCountFwdS CH_16X PrimaryFrameCountF wdSCH_8X FrameCountRevSCH_ 4X CEFrameCountRevS CH_4X PrimaryFrameCountR evSCH_4X AccessChannelUsage Info (array) FschDowngradeDueT oExceedingMaxDataR ate (array) RschDowngradeDueT oExceedingMaxDataR ate (array) InitialFwdSchBurstQu eued4X * UpdateFwdSchBurstQ ueued4X * DistributionOfPriorityC lass1Delay DistributionOfPriorityC lass5Delay DistributionOfPriorityC lass9Delay
BTS performance 9-3 Copyright 2008 Nortel Networks
FrameCountFwdSCH _4X CEFrameCountFwdS CH_2X PrimaryFrameCountF CH PrimaryFrameCountF wdSCH_16X FrameCountRevSCH_ 8X CEFrameCountRevS CH_8X PrimaryFrameCountR evSCH_8X FschDowngradeDueT oFwdPwr (array) FschDowngradeDueT oNoBcn (array) WalshCodeUsageDist ribution (array) InitialFwdSchBurstQu eued8X * UpdateFwdSchBurstQ ueued8X * DistributionOfPriorityC lass2Delay DistributionOfPriorityC lass6Delay DistributionOfPriorityC lass10Delay
FrameCountFwdSCH _8X CEFrameCountFwdS CH_4X PrimaryFrameCountF wdSCH_2X
FrameCountRevSCH_ 16X CEFrameCountRevS CH_16X PrimaryFrameCountR evSCH_16X FschDowngradeDueT oWC (array) FschDowngradeDueT oNoBackhaul (array) PeakWalshCodeUsag e InitialFwdSchBurstQu eued16X * UpdateFwdSchBurstQ ueued16X * DistributionOfPriorityC lass3Delay DistributionOfPriorityC lass7Delay DistributionOfPriorityC lass11Delay
sheet 3 of 4
CDMA
NBSS15.0
9-4 BTS performance Nortel Networks BTS performance OMs (continued) Metro Cell OMs DistributionOfPriorityCla ss12Delay DistributionOf8XDataRa teDelay NonQueuedFwdSchBur stNonBlocking3G (array) DistributionOfPriorityC lass13Delay DistributionOf16XData RateDelay QueuedFwdSchBurst NonBlocking3G (array) FPCHMessagesDropp edByReason *** ForwardTxPowerUsage Histogram (array) FCCCHTotalMessages ReceivedCount FCCCHUsageInfo (array) CBCM MO OMs BtscCpuUsageHistogra m CongCtrlTotalStormCou nt Power Management MO CarrierTxPowerAvg CarrierRx0PowerMax ConfiguredPowerLimitin gThresholdSPP RFM MO MultiSectorCarrierPowe rStats RadioPowerStats
sheet 4 of 4
DistributionOf2XData RateDelay FwdSCHBurstSetupP eakDelay RevSchBurstNonBloc king3G (array) PagingChannelMessa geReceivedCount FCCCHMessagesRec eivedDropped ** ACHMessagesReceiv ed **** PrimaryFBCCHLinkUti lAvg
DistributionOf4XData RateDelay MaximumFSCHQueu eLength
PagingChannelMessa geDroppedCount FCCCHMessagesDro ppedByReasonType *** REACHMessagesRec eived **** FCCCHLinkUtilAvg
FPCHMessagesRecei vedDropped ** FCCCHTotalMessage sDroppedCount REACHUsageInfo (array)
CongCtrlHalfHourSpik eCount
CongCtrlHalfHourStor mCount
CongCtrlTotalSpikeCo unt
CarrierTxPowerMax CarrierRx1PowerMax DemandedPowerStats
CarrierRx0PowerAvg PercentPowerLimiting DeliveredPowerStats
CarrierRx1PowerAvg AvgTxPowerAboveMa xSPP ConfiguredPowerLimit ingThreshold
411-2133-525
Standard
06.12
April 2008
Nortel Networks
* Each Blocking/Queueing OM has an array of elements containing the blocking reasons. The following table shows the list of array indices and corresponding reasons.
Array indices assigned to blocking/queueing reasons Array index 0 1 2 3 4 5 6 7 8 9 10 Blocking reason No Physical Resources No Forward Capacity No Reverse Capacity No Walsh Code No Frame Offset No Extended Cell Support CFDS Radio Config State CFDS HS RSCH Exceeded Max Data Rate Exceeded CPU Capacity Queue Full (This reason is pegged along with the appropriate reason for the block (0-9, or 11-13). Exceeded BCN Capacity Exceeded Backhaul Capacity Out of ACN Addresses
11 12 13
** Array indices for forward common channel message type OMs (page -6) presents the array elements for FPCHMessagesReceivedDropped and
CDMA
NBSS15.0
9-6 BTS performance Nortel Networks
FCCCHMessagesReceivedDropped OMs which count the messages received and dropped by message type.
Array indices for forward common channel message type OMs Array index 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Element PagingChannelNumber General Page Messages Received General Page Messages Dropped Data Burst Messages Received Data Burst Messages Dropped Feature Notification Messages Received Feature Notification Messages Dropped ECAM Received ECAM Dropped due to lack of buffers ECAM Repeat Dropped due to being stale CAM Received CAM Dropped due to lack of buffers CAM Repeat Dropped due to being stale MECAM Received MECAM Dropped due to lack of buffers MECAM Repeat Dropped due to being stale Base Station Acknowledgement Order Received Other Order Messages Received Base Station Acknowledgement Order Dropped Other Order Messages Dropped Status Request Messages Received Status Request Messages Dropped
sheet 1 of 2
411-2133-525
Standard
06.12
April 2008
Nortel Networks Array indices for forward common channel message type OMs Array index 22 23 24 25 26 27 Element
Authentication Challenge Messages Received Authentication Challenge Messages Dropped Service Redirection Messages Received Service Redirection Messages Dropped Broadcast Data Burst messages receiveda Broadcast Data Burst messages droppedb
sheet 2 of 2
a. Reserved for NBSS release 16.0, not pegged in 15.0 b. Reserved for NBSS release 16.0, not pegged in 15.0
*** Array indices for forward common channel reason type OMs (page -7) presents the array elements for FPCHMessagesDroppedByReason and FCCCHMessagesDroppedByReasonType OMs which count the messages dropped per reason.
Array indices for forward common channel reason type OMs Array index 0 1 2 3 4 5 Element Paging Channel Number Messages Dropped due to lack of buffers Messages Dropped due to message being stale Messages Dropped by EROC-Paging feature Messages Dropped due to size exceed sector limita Messages Dropped due to broadcast queue overflowb a. Reserved for NBSS release 16.0, not pegged in 15.0 b. Reserved for NBSS release 16.0, not pegged in 15.0
**** Array indices for reverse common channel messages type OMs (page 8) presents the array elements for ACHMessagesReceived and
CDMA
NBSS15.0
REACHMessagesReceived OMs which count the messages received by message type.

Array indices for reverse common channel messages type OMs Array index 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Element Paging Channel Number Access Channel Number Ring Index Registration Messages Received Origination Messages Received Page Response Messages Received Mobile Station Acknowledgement Order Messages Received Other Orders Messages Received Data Burst Messages Received Authentication Challenge Response Messages Received Status Response Messages Received Extended Status Response Messages Received Bad CRC Messages Received Invalid Messages Received Unsupported Messages Received
Resource blocking and voice call downgrades
Since blocks are counted by using blocking reason-based indices into an array, formulas for all blocking reasons (when applicable) are the same. The only difference in calculating the blocking rate for one blocking reason vs. another is the index into the blocking performance measurements. The blocking rate for all reasons put together can also be measured by summing up the numerator terms over all i values (i.e, i = 0 to 9, and 11-13).
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Origination and termination blocking These calculations can also be made by obtaining the appropriate sector-based OMs pegged at the CAU. For more information, see MSC OM descriptions (page 21-1). For more information about blocking reasons, see Array indices assigned to blocking/queueing reasons (page -5). 2G call blocking rate This formula includes 2G voice and 2G circuit-switched data calls. (BlockedFchOriginations2G[i] / (FchOriginationNonBlocking2G + FchOriginationNonBlocking3GDowngrade2G + FchOriginationNonBlocking3GDowngrade2GNoAcn + FchOriginationNonBlocking3GDowngrade2GNoBcn + Sum of BlockedFchOriginations2G[0-9, 11-13])) x 100 The FchOriginationNonBlocking3GDowngrade2G, FchOriginationNonBlocking3GDowngrade2GNoAcn, and FchOriginationNonBlocking3GDowngrade2GNoBcn OMs are not applicable to 2G-only systems (i.e., systems where 3G attempts are not possible due to no deployment of 3G resources). 3G voice call blocking rate (BlockedFchOriginations3GVoice[i] / (FchOriginationNonBlocking3GVoice + BlockedFchOriginations3GVoice[0-9, 11-13])) x 100 3G packet data call FCH blocking rate (BlockedFchOriginations3GData[i] / (FchOriginationNonBlocking3GData + BlockedFchOriginations3GData[0-9,11-13])) x 100 3G packet data call SCH blocking rate For reasons i = 0-9 and 11-13: (BlockedSchBursts[i] / (NonQueuedFwdSchBurstNonBlocking3G[0-3] + InitialFwdSchBurstQueued2X[0-9, 11-13] + InitialFwdSchBurstQueued4X[0-9, 11-13] + InitialFwdSchBurstQueued8X[0-9, 11-13] + InitialFwdSchBurstQueued16X[0-9, 11-13] + RevSchBurstNonBlocking3G[0-3] + BlockedSchBursts[0-9, 11-13])) x 100
CDMA
NBSS15.0
For reason i = 10: (BlockedSchBursts[10] / (NonQueuedFwdSchBurstNonBlocking3G[03] + BlockedSchBursts[10] + InitialFwdSchBurstQueued2X[0-9, 11-13] + InitialFwdSchBurstQueued4X[0-9, 11-13] + InitialFwdSchBurstQueued8X[0-9, 11-13] + InitialFwdSchBurstQueued16X[0-9, 11-13])) x 100 The denominator in the above formulas is only the closest number of total attempts resulting from the calculation. Overall blocking rate for all call types (BlockedFchOriginations3GVoice[i] + BlockedFchOriginations3GData[i] + BlockedFchOriginations2G[i] / (FchOriginationNonBlocking3GVoice + FchOriginationNonBlocking3GData + FchOriginationNonBlocking2G + FchOriginationNonBlocking3GDowngrade2G + FchOriginationNonBlocking3GDowngrade2GNoAcn + FchOriginationNonBlocking3GDowngrade2GNoBcn + BlockedFchOriginations3GVoice[0-9, 11-13] + BlockedFchOriginations3GData[0-9, 11-13] + BlockedFchOriginations2G[0-9, 11-13])) x 100 Soft handoff blocking For more information about blocking reasons, see Array indices assigned to blocking/queueing reasons (page -5). The 3G voice and packet data call VPN-based soft handoff blocking rate due to blocking reason i = 5 will always be 100% because VPN-based soft handoff of RC3-5 is not supported. 2G call soft handoff blocking rate 2G calls include 2G voice and 2G circuit-switched data. For reasons i = 1-4, and 6-13: (BlockedFchHandoffs2G[i] / (FchHandoffNonBlocking2G[0] + FchHandoffNonBlocking2G[1] + BlockedFchHandoffs2G[0-9, 11-13])) x 100 For reason i = 0: (BlockedFchHandoffs2G[0] / (FchHandoffNonBlocking2G[0] + BlockedFchHandoffs2G[0-4, 6-9, 11-13])) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
For reason i = 5: (BlockedFchHandoffs2G[5] / (FchHandoffNonBlocking2G[1] + BlockedFchHandoffs2G[1-9, 11-13])) x 100 3G voice call soft handoff blocking rate For non VPN-based soft handoff and reasons i = 0-4, and 6-13: (BlockedFchHandoffs3GVoice[i] / (FchHandoffNonBlocking3GVoice + BlockedFchHandoff3GVoice[0-4, 6-9, 11-13])) x 100 3G packet data call FCH soft handoff blocking rate For non VPN-based soft handoff and reasons i = 0-4, and 6-13: (BlockedFchHandoffs3GData[i] / (FchHandoffNonBlocking3GData + BlockedFchHandoffs3GData[0-4, 6-9, 11-13])) x 100 3G packet data call SCH soft handoff blocking rate For reasons i = 0-4, and 6-13: (BlockedSchHandoffs[i] / (SchHandoffNonBlocking3G + BlockedSchHandoffs[0-9, 11-13])) x 100 3G to 2G voice calls downgrade rate A request for a 3G voice call setup can be downgraded to a 2G voice call if the BTS is out of XCEM resources. ((FchOriginationNonBlocking3GDowngrade2G + FchOriginationNonBlocking3GDowngrade2GNoAcn + FchOriginationNonBlocking3GDowngrade2GNoBcn) / (FchOriginationNonBlocking3GVoice + FchOriginationNonBlocking3GDowngrade2G + FchOriginationNonBlocking3GDowngrade2GNoAcn + FchOriginationNonBlocking3GDowngrade2GNoBcn + BlockedFchOriginations3GVoice[0-9, 11-13])) x 100
Handoff sectors/beams per user
The formulas in this section are useful in determining the average number of RF channel sectors per user in use due to Soft/Softer Handoff. These metrics along with the overall frame counts for each data rate, overall blocking metrics and RRM settings may assist in provisioning the BTS resources. The metrics in this section should be calculated for a particular cluster of sectors or for the whole system by summing the OMs over all sectors in the cluster or in the system. This is indicated by the in the formulas.
CDMA
NBSS15.0
The text, <data rate> indicates the data rate of interest when calculating the metric, and can be any of 2X, 4X, 8X, or 16X. For example, if the average number of sectors in soft handoff for 2X FSCH is being calculated, 2X would replace <data rate> in the OM name. Coompared to the conventional sector, AABS sector has three beams. As super-soft handoff only involves beams on the AABS sector, to use the same formulas defined in this section to determining the average number of RF channel beams per user in use due to super-soft handoff, one has to replace all sector based OMs with AABS beam based OMs in the formula. That means, the metrics in this section when they are used to determine the super-soft handoff on AABS sector, they should be calculated for a particular AABS sector or a cluster of AABS sectors by summing the OMs over all beams in the AABS sector or in all AABS sectors. OMs in formula cannot be mixed and matched among conventional sector OMs and AABS beam OMs. Average number of FCH softer handoff sectors per user FrameCountFCH / CEFrameCountFCH Average number of FCH soft handoff sectors per user (not including softer) CEFrameCountFCH / PrimaryFrameCountFCH Average number of FCH handoff sectors per user (including both soft and softer) FrameCountFCH / PrimaryFrameCountFCH Average number of F-SCH softer handoff sectors per user per data rate FrameCountFwdSCH_<data rate> / CEFrameCountFwdSCH_<data rate> Average number of F-SCH soft handoff sectors per user (not including softer) per data rate CEFrameCountFwdSCH_<data rate> / PrimaryFrameCountFwdSCH_<data rate> Average number of F-SCH handoff sectors per user (including both soft and softer) per data rate FrameCountFwdSCH_<data rate> / PrimaryFrameCountFwdSCH_<data rate> Overall average number of F-SCH softer handoff sectors per user (all data rates) (FrameCountFwdSCH_2X + FrameCountFwdSCH_4X + FrameCountFwdSCH_8X + FrameCountFwdSCH_16X) / (CEFrameCountFwdSCH_2X + CEFrameCountFwdSCH_4X + CEFrameCountFwdSCH_8X + CEFrameCountFwdSCH_16X)
411-2133-525 Standard 06.12 April 2008
Nortel Networks
Overall average number of F-SCH soft handoff sectors per user (not including softer, all data rates) (CEFrameCountFwdSCH_2X + CEFrameCountFwdSCH_4X + CEFrameCountFwdSCH_8X + CEFrameCountFwdSCH_16X) / (PrimaryFrameCountFwdSCH_2X + PrimaryFrameCountFwdSCH_4X + PrimaryFrameCountFwdSCH_8X + PrimaryFrameCountFwdSCH_16X) Overall average number of F-SCH handoff sectors per user (including both soft and softer, all data rates) (FrameCountFwdSCH_2X + FrameCountFwdSCH_4X + FrameCountFwdSCH_8X + FrameCountFwdSCH_16X) / (PrimaryFrameCountFwdSCH_2X + PrimaryFrameCountFwdSCH_4X + PrimaryFrameCountFwdSCH_8X + PrimaryFrameCountFwdSCH_16X) Average number of R-SCH softer handoff sectors per user per data rate FrameCountRevSCH_<data rate> / CEFrameCountRevSCH_<data rate> Average number of R-SCH soft handoff sectors per user (not including softer) per data rate CEFrameCountRevSCH_<data rate> / PrimaryFrameCountRevSCH_<data rate> Average number of R-SCH handoff sectors per user (including both soft and softer) per data rate FrameCountRevSCH_<data rate> / PrimaryFrameCountRevSCH_<data rate> Overall average number of R-SCH softer handoff sectors per user (all data rates) (FrameCountRevSCH_2X + FrameCountRevSCH_4X + FrameCountRevSCH_8X + FrameCountRevSCH_16X) / (CEFrameCountRevSCH_2X + CEFrameCountRevSCH_4X + CEFrameCountRevSCH_8X + CEFrameCountRevSCH_16X) Overall average number of R-SCH soft handoff sectors per user (not including softer, all data rates) (CEFrameCountRevSCH_2X + CEFrameCountRevSCH_4X + CEFrameCountRevSCH_8X + CEFrameCountRevSCH_16X) / (PrimaryFrameCountRevSCH_2X + PrimaryFrameCountRevSCH_4X + PrimaryFrameCountRevSCH_8X + PrimaryFrameCountRevSCH_16X)
Overall average number of R-SCH handoff sectors per user (including both soft and softer, all data rates) (FrameCountRevSCH_2X + FrameCountRevSCH_4X + FrameCountRevSCH_8X + FrameCountRevSCH_16X) / (PrimaryFrameCountRevSCH_2X + PrimaryFrameCountRevSCH_4X + PrimaryFrameCountRevSCH_8X + PrimaryFrameCountRevSCH_16X)
FSCH queuing
The formulas in this section give information related to delays in setting up a forward SCH link due to the queuing of setup requests at the BTS by the BTS Scheduler. A high amount of FSCH queuing may indicate the need to increase the number of BTS resources available for high speed data calls or make adjustments to the RRM or Burst Scheduler Parameters. For more information about queuing reasons, see Array indices assigned to blocking/queueing reasons (page -5). Percentage of FSCH bursts queued ((InitialFwdSchBurstQueued2X[0-9] + InitialFwdSchBurstQueued4X[0-9] + InitialFwdSchBurstQueued8X[0-9] + InitialFwdSchBurstQueued16X[0-9]) / (NonQueuedFwdSchBurstNonBlocking3G[0-3] + BlockedSchBursts[10] + InitialFwdSchBurstQueued2X[0-9] + InitialFwdSchBurstQueued4X[0-9] + InitialFwdSchBurstQueued8X[0-9] + InitialFwdSchBurstQueued16X[0-9])) x 100 Distribution of FSCH queuing by specific queuing reason i Calculated for each reason i = 0-9 ((InitialFwdSchBurstQueued2X[i] + InitialFwdSchBurstQueued4X[i] + InitialFwdSchBurstQueued8X[i] + InitialFwdSchBurstQueued16X[i]) / (InitialFwdSchBurstQueued2X[0-9] + InitialFwdSchBurstQueued4X[0-9] + InitialFwdSchBurstQueued8X[0-9] + InitialFwdSchBurstQueued16X[0-9])) x100 Downgrade percentage for queued FSCH requests at the BTS This is the percentage of downgraded (updated) queued FSCH setup requests at the BTS scheduler due to resource contention at the BSC (i.e. Fairshare algorithm). ((UpdateFwdSchBurstQueued2X[0-9] + UpdateFwdSchBurstQueued4X[0-9] +
411-2133-525 Standard 06.12 April 2008
Nortel Networks
UpdateFwdSchBurstQueued8X[0-9] + UpdateFwdSchBurstQueued16X[0-9]) / (InitialFwdSchBurstQueued2X[0-9] + InitialFwdSchBurstQueued4X[0-9] + InitialFwdSchBurstQueued8X[0-9] + InitialFwdSchBurstQueued16X[0-9])) x100 Distribution of updated FSCH queuing by specific queuing reason This is the percentage of FSCH queuing events (after the data rate has been downgraded due to resources contention at BSC) due to a particular BTS queuing reason out of all the updated FSCH queuing events (due to all BTS reasons combined). Calculated for each reason i =0-9 ((UpdateFwdSchBurstQueued2X[i] + UpdateFwdSchBurstQueued4X[i] + UpdateFwdSchBurstQueued8X[i] + UpdateFwdSchBurstQueued16X[i]) / (UpdateFwdSchBurstQueued2X[0-9] + UpdateFwdSchBurstQueued4X[0-9] + UpdateFwdSchBurstQueued8X[0-9] + UpdateFwdSchBurstQueued16X[0-9])) x 100 Queuing delay distribution for successful FSCH links The following metric presents the delay distribution of queued FSCH link setup successes. This is a measure of the amount of time an FSCH burst waited in the BTS scheduler queue before being granted BTS resources. In each formula, i represents the delay bin (where i can be 0 to 8). The metrics are calculated per delay range for all data rates combined (i.e., FSCH links setup successes with a queuing delay in the 0 to 2 seconds range versus the 2 to 4 seconds range versus the 4 to 6 seconds range, etc.). Long queuing delays may indicate a need for deployment of additional BTS resources to meet the high speed data requirements for that BTS. The array index meanings are presented in Array indices assigned to delay bins (page -15).
Array indices assigned to delay bins Array index i 0 1 Delay bin 0-2 2-4 Delay time (time spent in queue) >0 - <2 sec 2 - <4 sec
CDMA
NBSS15.0
9-16 BTS performance Nortel Networks Array indices assigned to delay bins Array index i 2 3 4 5 6 7 8 Delay bin 4-6 6-8 8-10 10-15 15-20 20-30 30+
Delay time (time spent in queue) 4 - <6 sec 6 - <8 sec 8 - <10 sec 10 - <15 sec 15 - <20 sec 20 - <30 sec >30 sec
Calculated for each array index i=0-8 ((DistributionOf2XDataRateDelay[i] + DistributionOf4XDataRateDelay[i] + DistributionOf8XDataRateDelay[i] + DistributionOf16XDataRateDelay[i]) / QueuedFwdSchBurstNonBlocking3G[0-3]) x 100 Queuing delay distribution per priority class The following metric presents the per Priority Class distribution of queued FSCH link setup successes by delay time in the BTS queue. In each formula A represents the Mobiles Priority Class (where A can be 0 to 13), and i represents the delay bin (where i can be 0 to 8, see Array indices assigned to delay bins (page -15)). The metrics are calculated per delay range for each priority class (i.e., FSCH links setup successes at priority class A with a queuing delay in the 0 to 2 seconds range versus the 2 to 4 seconds range versus the 4 to 6 seconds range, etc.). For a given priority class, long queuing delays may indicate a need for deployment of additional BTS resources to meet the high speed data requirements for that Priority Class. Calculated for each priority class A = 0-13 and delay bin i = 0-8. (DistributionOfPriorityClassADelay[i] / DistributionOfPriorityClassADelay[0-8]) x 100 Queuing delay distribution per requested data rate The following metric presents the per data rate distribution of queued FSCH setup successes by delay time in the BTS queue. In each formula BX represents the requested data rate (i.e. B = 2, 4, 8, or 16). The metrics are calculated per delay range i for each data rate (i.e., FSCH link setup successes at data rate BX with a queuing delay in the 0 to 2 seconds range
411-2133-525 Standard 06.12 April 2008
Nortel Networks
versus the 2 to 4 seconds range versus the 4 to 6 seconds range, etc., see Array indices assigned to delay bins (page -15)). For a given data rate, long delays may indicate a need for deployment of additional BTS resources to meet the high speed data requirements in that area, especially when these higher delays are seen for the lowest data rate of 2X. Calculated for each data rate B = 2, 4, 8, or 16 and delay bin i = 0-8 (DistributionOfBXDataRateDelay[i] / DistributionOfBXDataRateDelay[0-8]) x 100
SCH link data rate downgrades
SCH downgrades occur when BTS high speed data resources are insufficient to support the higher data rates and may indicate the need for deployment of additional BTS resources if support of those rates is desired. The following two terms are used in the metrics in this section: Total FSCH downgrades = FschDowngradeDueToFwdPwr[0-5] + FschDowngradeDueToWC[0-5] + FschDowngradeDueToPhysRes[0-5] + FschDowngradeDueToExceedingMaxDataRate[0-5] + FschDowngradeDueToNoBcn[0-5] + FschDowngradeDueToNoBackhaul[0-5] Total RSCH downgrades = RschDowngradeDueToPhysRes[0-5] + RschDowngradeDueToExceedingMaxDataRate[0-5] Percentage of SCH data rate downgrades per EBID ((FschDowngradeDueToFwdPwr[0-5] + FschDowngradeDueToWC[0-5] + FschDowngradeDueToPhysRes[05] + FschDowngradeDueToExceedingMaxDataRate[0-5] + FschDowngradeDueToNoBcn[0-5] + FschDowngradeDueToNoBackhaul[0-5] + RschDowngradeDueToPhysRes[0-5] + RschDowngradeDueToExceedingMaxDataRate[0-5]) / (NonQueuedFwdSchBurstNonBlocking3G[0-3] + InitialFwdSchBurstQueued2X[0-9] + InitialFwdSchBurstQueued4X[0-9] + InitialFwdSchBurstQueued8X[0-9] + InitialFwdSchBurstQueued16X[0-9] + RevSchBurstNonBlocking3G[0-3] + BlockedSchBursts[0-9, 11-13])) x 100 The denominator is only the closest number of total attempts resulting from the calculation.
Distribution of SCH downgrades by specific downgrade reason The following metrics measure the percentage of SCH data rate downgrade events due to a particular downgrade reason out of all the SCH data rate downgrade events (due to all BTS reasons combined). These metrics can also be applied to each downgrade scenario, e.g. out of all the 16X to 8X downgrades regardless of BTS reason, how many of them are due to power or due to walsh codes or due to physical resources or due to max data rate. Percentage of FSCH downgrades due to lack of forward power (FschDowngradeDueToFwdPwr[0-5] / Total FSCH downgrades) * 100 Percentage of FSCH downgrades due to lack of Walsh codes (FschDowngradeDueToWC[0-5] / Total FSCH downgrades) * 100 Percentage of FSCH downgrades due to lack of physical resources (FschDowngradeDueToPhysRes[0-5] / Total FSCH downgrades) * 100 Percentage of FSCH downgrades due to MaxFwdDataRate BTS settable parameter (FschDowngradeDueToExceedingMaxDataRate[0-5] / Total FSCH downgrades) * 100 Percentage of FSCH downgrades due to lack of BCN link resources (FschDowngradeDueToNoBcn[0-5] / Total FSCH downgrades) * 100 Percentage of FSCH downgrades due to lack of backhaul resources (FschDowngradeDueToNoBackhaul[0-5] / Total FSCH downgrades) * 100 Percentage of RSCH downgrades due to lack of physical resources (RschDowngradeDueToPhysRes[0-5] / Total RSCH downgrades) * 100 Percentage of RSCH downgrades due to MaxRevDataRate BTS setable parameter (RschDowngradeDueToExceedingMaxDataRate[0-5] / Total RSCH downgrades) * 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Distribution of SCH downgrades by specific FSCH downgrade scenario These metrics measure the percentage of SCH data rate downgrade scenario (e.g. 16X to 4X) events out of all the SCH data rate downgrade events (due to all BTS reasons combined). This metric provides a valuable information to the network operator as it may not be alarming if a high percentage of the FSCH downgrades are from 16X to 8X but it would be alarming if a high percentage of the FSCH downgrades are from 16X to 2X for example, as this would negatively impact the user perceived throughput. Percentage of FSCH downgrades from 16x to 8x ((FschDowngradeDueToFwdPwr[0] + FschDowngradeDueToWC[0] + FschDowngradeDueToPhysRes[0] + FschDowngradeDueToExceedingMaxDataRate[0] + FschDowngradeDueToNoBcn[0] + FschDowngradeDueToNoBackhaul[0]) / Total FSCH downgrades) * 100 Percentage of FSCH downgrades from 16x to 4x ((FschDowngradeDueToFwdPwr[1] + FschDowngradeDueToWC[1] + FschDowngradeDueToPhysRes[1] + FschDowngradeDueToExceedingMaxDataRate[1] + FschDowngradeDueToNoBcn[1] + FschDowngradeDueToNoBackhaul[1]) / Total FSCH downgrades) * 100 Percentage of FSCH downgrades from 16x to 2x ((FschDowngradeDueToFwdPwr[2] + FschDowngradeDueToWC[2] + FschDowngradeDueToPhysRes[2] + FschDowngradeDueToExceedingMaxDataRate[2] + FschDowngradeDueToNoBcn[2] + FschDowngradeDueToNoBackhaul[2]) / Total FSCH downgrades) * 100 Percentage of FSCH downgrades from 8x to 4x ((FschDowngradeDueToFwdPwr[3] + FschDowngradeDueToWC[3] + FschDowngradeDueToPhysRes[3] + FschDowngradeDueToExceedingMaxDataRate[3] + FschDowngradeDueToNoBcn[3] + FschDowngradeDueToNoBackhaul[3]) / Total FSCH downgrades) * 100 Percentage of FSCH downgrades from 8x to 2x ((FschDowngradeDueToFwdPwr[4] + FschDowngradeDueToWC[4] + FschDowngradeDueToPhysRes[4] + FschDowngradeDueToExceedingMaxDataRate[4] + FschDowngradeDueToNoBcn[4] +
CDMA
NBSS15.0
FschDowngradeDueToNoBackhaul[4]) / Total FSCH downgrades) * 100 Percentage of FSCH downgrades from 4x to 2x ((FschDowngradeDueToFwdPwr[5] + FschDowngradeDueToWC[5] + FschDowngradeDueToPhysRes[5] + FschDowngradeDueToExceedingMaxDataRate[5] + FschDowngradeDueToNoBcn[5] + FschDowngradeDueToNoBackhaul[5]) / Total FSCH downgrades) * 100 Percentage of RSCH downgrades from 16x to 8x ((RschDowngradeDueToPhysRes[0] + RschDowngradeDueToExceedingMaxDataRate[0]) / Total RSCH downgrades) * 100 Percentage of RSCH downgrades from 16x to 4x ((RschDowngradeDueToPhysRes[1] + RschDowngradeDueToExceedingMaxDataRate[1]) / Total RSCH downgrades) * 100 Percentage of RSCH downgrades from 16x to 2x ((RschDowngradeDueToPhysRes[2] + RschDowngradeDueToExceedingMaxDataRate[2]) / Total RSCH downgrades) * 100 Percentage of RSCH downgrades from 8x to 4x ((RschDowngradeDueToPhysRes[3] + RschDowngradeDueToExceedingMaxDataRate[3]) / Total RSCH downgrades) * 100 Percentage of RSCH downgrades from 8x to 2x ((RschDowngradeDueToPhysRes[4] + RschDowngradeDueToExceedingMaxDataRate[4]) / Total RSCH downgrades) * 100 Percentage of RSCH downgrades from 4x to 2x ((RschDowngradeDueToPhysRes[5] + RschDowngradeDueToExceedingMaxDataRate[5]) / Total RSCH downgrades) * 100
Walsh code usage distribution
The WalshCodeUsageDistribution array provides information on how often the number of Walsh codes in simultaneous use is within a certain usage range. The usage ranges are 0 to 30, 31 to 60, 61 to 70, 71 to 80, 81 to 90, 91 to 100, 101 to 110, 111 to 120, and 121 to 128. Walsh code usage in the upper ranges may indicate the need for deployment of additional BTS resources to prevent call blocking issues.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
The PeakWalshCodeUsage OM provides information on the peak number of walsh codes in simultaneous use during the 30 minutes OM report interval. Since Walsh code usage is measured using a histogram, the exact value of the average number of Walsh codes in use during the OM reporting period cannot be calculated. However, a range can be determined in which the average value lies. For example, in a lightly loaded sector, all of the pegs in the WalshCodeUsageDistribution may peg in the 0-30 range, while in a more loaded sector, pegs may exist in several ranges. In the first case, the average number of Walsh codes in simultaneous use will obviously be a value between 0 and 30 since all of the pegs were solely in that range. In the second case, the average may lie in a range that does not correspond to one of the OM ranges in the array. To illustrate, suppose the WalshCodeUsageDistribution array data for a given OM reporting period is collected as in the following table.
Example WalshCodeUsageDistribution data Range 0-30 31-60 61-70 71-80 81-90 91-100 101-110 111-120 121-128 Value 6 10 56 92 78 45 10 2 0
The average number of Walsh codes in use in this case lies in a range between a lower bound of 73 and an upper bound of 83. The lower and upper bounds for the average number of Walsh codes in simultaneous use are calculated as follows: Lower bound of average number of walsh codes in simultaneous use ((WalshCodeUsageDistribution[0] * 0) + (WalshCodeUsageDistribution[1] * 31) + (WalshCodeUsageDistribution[2] * 61) + (WalshCodeUsageDistribution[3] * 71) + (WalshCodeUsageDistribution[4] * 81) + (WalshCodeUsageDistribution[5] * 91) +
(WalshCodeUsageDistribution[6] * 101) + (WalshCodeUsageDistribution[7] * 111) + (WalshCodeUsageDistribution[8] * 121)) / WalshCodeUsageDistribution[0-8] Upper bound of average number of walsh codes in simultaneous use ((WalshCodeUsageDistribution[0] * 30) + (WalshCodeUsageDistribution[1] * 60) + (WalshCodeUsageDistribution[2] * 70) + (WalshCodeUsageDistribution[3] * 80) + (WalshCodeUsageDistribution[4] * 90) + (WalshCodeUsageDistribution[5] * 100) + (WalshCodeUsageDistribution[6] * 110) + (WalshCodeUsageDistribution[7] * 120) + (WalshCodeUsageDistribution[8] * 128)) / WalshCodeUsageDistribution[0-8]
Physical resource utilization metrics
The physical resource utilization OMs provide the peak number of XCEM physical resources being used simultaneously for the FCH (2G and 3G calls, both forward and reverse) and SCH (for both the forward and reverse links). The metrics below can be used to provision the BTS resources Peak percentage of physical resources used for 2G FCH (Fch2GMaximumForwardPhysicalResourceUsed / TotalForwardPhysicalResources) * 100 Peak percentage of physical resources used for 3G FCH (Fch3GMaximumForwardPhysicalResourceUsed / TotalForwardPhysicalResources) * 100 Peak percentage of forward physical resources used for SCH (SchMaximumForwardPhysicalResourceUsed / TotalForwardPhysicalResources) * 100 Peak percentage of reverse physical resources used for SCH (SchMaximumReversePhysicalResourceUsed / TotalReversePhysicalResources) * 100 Peak percentage of forward physical resources used (MaxFwdPhysicalResourcesUsed / TotalForwardPhysicalResources) * 100 Peak percentage of reverse physical resources used (MaxRevPhysicalResourcesUsed / TotalReversePhysicalResources) * 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Peak percentage of voice resources used on the forward FCH (MaxFCHVoiceResourcesUsed / TotalForwardPhysicalResources) * 100 Peak percentage of data resources used on the forward FCH (MaxFCHDataResourcesUsed / TotalForwardPhysicalResources) * 100
Forward transmit power utilization
The ForwardTxPowerUsageHistogram OM indicates the time duration in seconds during which the forward transmit power was distributed within a certain occupancy range of 10% (i.e. 0%-9%, 10%-19%....90%-100%). The occupancy range is relative to the maximum allowable transmit power. Please note that the last element in the histogram (90%-100%) will be pegged even when the transmit power goes beyond 100%.
Forward Transmit Power Utilization in Percentage
The current value of forward transmit power maxAllowableTxPwr
*100%
Since maxAllowableTxPwr is configurable and depended on datafill of AdvancedSectorMO, the occupancy range will be affected by maxAllowableTxPwr. For example, if we configure maxAllowableTxPwr (maximum allowable transmit power) to 200% of the radio power (the maximum power that the transmitter power amplifier supports, which equals maximum of current value of forward transmit power), forward transmit power will be distributed in the first five or six histograms. If we configure maxAllowableTxPwr to 50% of the radio power, forward transmit power will be distributed in all of the ten histograms but half of forward transmit power will be distributed in the 10th histogram. In order to utilize all ten bins, we can configure maxAllowableTxPwr to align with radio power. If we disable the handoff blocking due to power via setting HandoffBlockingThreshold to 0, hand off blocking will be unaffected by maxAllowableTxPwr and we are free to change maxAllowableTxPwr. Forward transmit power is instantaneously measured every 2 seconds during the 30 minute OM collection interval, and the corresponding occupancy range is incremented by two at each measurement. At the end of the reporting period each occupancy range will have the total time (in seconds) the power level spent in that occupancy range.
CDMA
NBSS15.0
This OM also provides information on the peak occupancy range. High values of Forward TX Power Usage in the upper ranges may indicate high call volume (busy hour, usually remedied by adding an extra carrier) or bad RF conditions (may need optimization). Lower bound of average occupancy range (ForwardTxUsageHistogram[0]*0 + ForwardTxUsageHistogram[1]*10 + ForwardTxUsageHistogram[2]*20 + ForwardTxUsageHistogram[3]*30 + ForwardTxUsageHistogram[4]*40 + ForwardTxUsageHistogram[5]*50 + ForwardTxUsageHistogram[6]*60 + ForwardTxUsageHistogram[7]*70 + ForwardTxUsageHistogram[8]*80 + ForwardTxUsageHistogram[9]*90) / ForwardTxUsageHistogram[0-9] Upper bound of average occupancy range (ForwardTxUsageHistogram[0]*9 + ForwardTxUsageHistogram[1]*19 + ForwardTxUsageHistogram[2]*29 + ForwardTxUsageHistogram[3]*39 + ForwardTxUsageHistogram[4]*49 + ForwardTxUsageHistogram[5]*59 + ForwardTxUsageHistogram[6]*69 + ForwardTxUsageHistogram[7]*79 + ForwardTxUsageHistogram[8]*89 + ForwardTxUsageHistogram[9]*100) / ForwardTxUsageHistogram[0-9] Percentage of time forward transmit power is in an occupancy range Calculated for each occupancy range i = 0-9 (ForwardTxUsageHistogram[i] / ForwardTxUsageHistogram[0-9]) x 100
Forward common channel utilization
The utilization metrics provide a distribution of the amount of time for which a given forward common channel is operating at a certain occupancy level. Paging channel utilization PagingChannelUsageInfo OM captures the occupancy information discussed below for all the paging channels configured in the carrier-sector. The PagingChannelUsageInfo OM array provides information on how long the paging channel is operating within a certain 5% occupancy range (i.e. 0% - 4%, 5% - 9%,... , 95%- 100%). The sample period for calculating the occupancy range is 1.28 seconds, which is equivalent to 16 paging channel slots. Range N1% - N2% encompasses all values between N1 and less than (N2+1). For example, range 0% - 4% encompasses all values between 0 and < 5 i.e.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
the value 4.99 is part of 0% - 4% range. The 95% - 100% range encompasses all values between 95 and <= 100. These OMs also provide information on the peak paging channel occupancy range, as well as the lower bound and upper bound for the average paging channel occupancy range. The lower bound of average occupancy is calculated as follows: Rounded down value of (Sum of (RangeN1toN2 * N1)) / Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)) The upper bound of average occupancy is calculated as follows: Rounded up value of (Sum of (RangeN1toN2 * (N2+1))) / Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)) In the above, RangeN1toN2 = {Range0to4, Range5to9,..., Range95to100}. They are part of the PagingChannelUsageInfo OMs in Sequence Number 141 as described in BTS OM descriptions (page 23-1). The peak occupancy is the upper bound + 1 of the peak occupancy range for the paging channel. For instance, if the highest range pegged is 75%-79%, then PeakOccupancy = 80%. The RangeN1toN2 OMs provide information on how many seconds the paging channel was operating in the N1toN2 occupancy range. This can also be easily mapped to a percentage of the time that the paging channel was operating in the N1toN2 occupancy range: Percentage of time the paging channel was operating in the N1toN2 occupancy range = (RangeN1toN2 * 100%) / [Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)] High values of paging channel occupancy close to the engineering limits along with large message drop rate for the paging channel at the BTS would require appropriate actions such as adding an additional paging channel to the carrier-sector, adding a carrier to the sector, reconfiguring IZP zones, etc. to offload traffic on that particular paging channel. Forward common control channel utilization Similar to the PagingChannelUsageInfo OM array, the FCCCHUsageInfo OM array provides information on how long the FCCCH channel is operating within a certain 5% occupancy range (i.e. 0% - 4%, 5% - 9%,... , 95%100%). The sample period for calculating the occupancy range is 1.28 seconds, which is equivalent to 16 FCCCH channel slots.
CDMA
NBSS15.0
The OM also provides information on the peak FCCCH channel occupancy range, as well as the lower bound and upper bound for the average FCCCH channel occupancy range. The metrics defined above for the Paging Channel are applicable to FCCCH Channel. For example: The upper bound of average occupancy is calculated as follows: Rounded up value of (Sum of (RangeN1toN2 * (N2+1))) / Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)) where values for RangeN1toN2 are from FCCCHUsageInfo OM. Currently there is support for up to one FCCCH channel per carrier-sector. Hence FCCCHUsageInfo OM captures the occupancy information for up to one FCCCH channel per carrier sector. High values of FCCCH channel occupancy close to the engineering limits along with large message drop rate for the FCCCH channel at the BTS would require appropriate actions such as adding a carrier in the sector, reconfiguring IZP zones, etc. to offload traffic on that particular FCCCH channel.
Reverse common channel utilization
The utilization metrics provide a distribution of the amount of time for which a given reverse common channel is operating at a certain occupancy level. Access channel utilization AccessChannelUsageInfo OM captures the occupancy information discussed below for all the access channels configured in the carrier-sector. The AccessChannelUsageInfo OM array provides information on how long the access channel is operating within a certain 5% occupancy range (i.e. 0% - 4%, 5% - 9%,...,95%- 99%), where 95% - 99% also includes 100%. The sample period for calculating the occupancy range is 20 access channel slots. These OMs also provide information on the peak access channel occupancy range, as well as the lower bound and upper bound for the average access channel occupancy range. The lower bound of average occupancy is calculated as follows: Rounded down value of (Sum of (RangeN1toN2 * N1)) / Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.))
411-2133-525 Standard 06.12 April 2008
Nortel Networks
The upper bound of average occupancy is set equal to the lower bound of average occupancy. Note: Access Channel Usage OM structure is defined using range bins: 0~4%, 5~9%, ..., 95~99% to maintain consistency with other usage OM types (PagingChannelUsageInfo OM, REACHUsageInfo OM, etc). However the mechanism of computing Access Channel Occupancy is in terms of number of messages received in a given time interval, which is an integer number and the only values that AccessChannelUsageInfo OM takes are: 0%, 5%, ..., 95%, 100%. This implies that a given bin is pegged only by a single value. Hence the upper bound of average occupancy is same as the lower bound of average occupancy and the peak occupancy is the lower bound of the peak occupancy range for Access Channel Utilization measurements In the above formulas, RangeN1toN2 = {Range0to4, Range5to9,..., Range95to99}. They are part of the AccessChannelUsageInfo OMs in Sequence Number 142 as described in BTS OM descriptions (page 23-1). The peak occupancy is the lower bound of the peak occupancy range for the access channel. For instance, if the highest range pegged is 40%-44%, then the peak occupancy = 40%. The RangeN1toN2 OMs provide information on how many seconds the access channel was operating in the N1toN2 occupancy range. This can also be easily mapped to a percentage of the time that the access channel was operating in the N1toN2 occupancy range: Percentage of time the access channel was operating in the N1toN2 occupancy range = (RangeN1toN2 * 100%) / [Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)] High values of access channel occupancy close to the engineering limits along with high BadCRC rate for the access channel would require appropriate actions such as adding an additional access channel to the carrier sector, adding a carrier to the sector, etc. to offload the traffic on that particular access channel. Enhanced access channel utilization Similar to the AccessChannelUsageInfo OM array, the REACHUsageInfo OM array provides information on how long the enhanced access channel is operating within a certain 5% occupancy range (i.e. 0% - 4%, 5% 9%,...,95%- 99%), where 95% - 99% also includes 100%. The sample period for calculating the occupancy range is 4 seconds. The OM also provide information on the peak enhanced access channel occupancy range, as well as the lower bound and upper bound for the average enhanced access channel occupancy range.
The lower bound of average occupancy is calculated as follows: Rounded down value of (Sum of (RangeN1toN2 * N1)) / Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)) The upper bound of average occupancy is calculated as follows: Rounded up value of (Sum of (RangeN1toN2 * (N2+1))) / Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)) In the above formulas, RangeN1toN2 = {Range0to4, Range5to9,..., Range95to99}. They are part of the REACHUsageInfo OMs in Sequence Number 298 as described in BTS OM descriptions (page 23-1). The peak occupancy is the upper bound +1 of the peak occupancy range for the access channel. For instance, if the highest range pegged is 40%-44%, then the peak occupancy = 45%. The RangeN1toN2 OMs provide information on how many seconds the access channel was operating in the N1toN2 occupancy range. This can also be easily mapped to a percentage of the time that the enhanced access channel was operating in the N1toN2 occupancy range: Percentage of time the enhanced access channel was operating in the N1toN2 occupancy range = (RangeN1toN2 * 100%) / [Sum of (RangeN1toN2) over all values of N1toN2 (i.e. 0to4, 5to9,...etc.)] Currently there is support for up to one EACH channel per carrier-sector. Hence REACHUsageInfo OM captures the occupancy information for up to one REACH channel per carrier sector. High values of enhanced access channel occupancy close to the engineering limits along with high BadCRC rate for the enhanced access channel would require appropriate actions such as adding a carrier to the sector, etc. to offload the traffic on that particular access channel.
Reverse common channel message received by type

Access channel message received by type The following formula provides the operator information on the traffic load that is contributed by each message type on each reverse common channel. ACHMessagesReceived OM captures the messages received information discussed below for all the access channels configured in the carrier-sector.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Refer to for the index mapping used in this metric for the different message types: (ACHMessagesReceived[i] / ACHMessagesReceived[i] over all is) x 100 Example:
Load Contribution chart

3% 9% 3% 6% 3% 15% 18% 3% 7% 7% 6% 20%
Registration Message Origination Message Page Response Message Mobile Station Acknowledgement Order Message Other Orders Data Burst Message Authentication Challenge Response Message Status Response Message Exteneded Status Reponse Message Bad CRC Message Unsupported Message Invalid Message
Note: The numbers stated in this example are for illustration purposes only. Bad CRC ratio This metric provides a ratio of messages that failed the CRC check at the BTS to the total number of messages that are received by the BTS on a given access channel. This information is needed for access channel provisioning. Bad CRC ratio metric along with other access channel OMs are helpful in accessing the need for adding another access channel on that carrier-sector. (ACHMessagesReceived[12] / ACHMessagesReceived[i] over all is) x 100
CDMA
NBSS15.0
Invalid messages ratio Messages that pass the CRC check at the BTS but are either not supported by the Nortel system or have parameters with values outside their allowed range as defined in the standards are termed as Invalid Messages. This metric provides a ratio of invalid messages to the total number of messages that are received by the BTS on a given access channel. High values of this metric would indicate issues with the mobiles in the field. (ACHMessagesReceived[13] / ACHMessagesReceived[i] over all is) x 100 Unsupported messages ratio Messages that pass the CRC check but are not supported due to configuration reasons (e.g. RTD of message exceeds the ASW configured range) are termed as Unsupported Messages. This metric provides a ratio of unsupported messages to the total number of messages that are received by the BTS on a given access channel. High values of this metric would indicate BTS coverage issues. (ACHMessagesReceived[14] / ACHMessagesReceived[i] over all is) x 100 Mobile response rate to paging channel messages Some of the mobile directed messages like Authentication Challenge, Status Request, Extended Status Request and General Page message have a corresponding response message that is received by the network. These metrics provide the response rate of the mobile for each type of message. Page response ratio ACHMessagesReceived[5] / (FPCHMessagesReceivedDropped[1] FPCHMessagesReceivedDropped[2]) x 100 Since paging is performed system-wide, zone-wide, and/or across system borders, the operator should not expect a high ratio for this metric as the majority of page messages sent on any given carrier-sector are for mobiles that may be currently located in other carrier-sectors of the system. If the operator is not utilizing Intelligent Zone Paging or Frequency-Based Paging, this metric may be extremely low. It may be desirable to activate, deploy or optimize these features to reduce paging channel utilization and make better use of the Paging and Access channel bandwidth. This metric provides an estimate of carrier-sector paging efficiency. Status response ratio Mobiles with PREV < 6 respond to Status Request messages sent from the network with a Status Response message and mobiles with PREV >= 6
411-2133-525
Standard
06.12
April 2008
Nortel Networks
respond to Status Request messages with a Extended Status Response message. Hence the Status response ratio is calculated as: (ACHMessagesReceived[10] + ACHMessagesReceived[11]) / (FPCHMessagesReceivedDropped[20] FPCHMessagesReceivedDropped[21]) x 100 Authentication challenge response ratio ACHMessagesReceived[9] / (FPCHMessagesReceivedDropped[22] FPCHMessagesReceivedDropped[23]) x 100 Enhanced access channel metrics The Access channel message received by type and Access channel page response ratio metrics discussed above for the access channel are applicable for the REACH channel. For example: The Bad CRC ratio for REACH channel is calculated as: (REACHMessagesReceived[12] / REACHMessagesReceived[i] over all is) x 100 Note that mobiles on the BAM channel respond to Status request message only using Extended Status Response message. Hence the Status Response message count for BAM channel should always be zero. Currently there is support for up to one EACH channel per carrier-sector. Hence REACHUsageInfo OM captures the message received information for up to one REACH channel per carrier sector.
Forward common channel message drop rate
The following formulas provide the operator information on the message drop rate for each common channel. Under extreme conditions, the Common Channel may have no buffers available to process incoming messages, or may not be able to schedule a message for delivery before it is no longer useful (i.e stale). They provide trending information that can be used for common channel optimization and paging feature deployment (i.e. IZP, FBP, etc.) Paging channel message drop rate The FPCHMessagesReceivedDropped OM captures information for all the paging channels deployed in the carrier-sector. The metrics discussed below can be applied to each paging channel independently.
CDMA
NBSS15.0
Drop rate by message type Refer to for the index mapping used in this metric for the different message types. (FPCHMessagesReceivedDropped[i for message type dropped] / FPCHMessagesReceivedDropped[j for message type received]) x 100 For example, the General Page Message Drop Rate is expressed by: (FPCHMessagesReceivedDropped[2 = General Page Messages Dropped] / FPCHMessagesReceivedDropped[1 = General Page Messages Received]) x 100 For the MECAM, ECAM and CAM messages, the number of messages dropped of each type will be the sum of (FPCHMessagesReceivedDropped[8] + FPCHMessagesReceivedDropped[9]), (FPCHMessagesReceivedDropped[11] + FPCHMessagesReceivedDropped[12]) and (FPCHMessagesReceivedDropped[14] + FPCHMessagesReceivedDropped[15]), respectively. If the drop reason is of interest, the individual array elements may be used. Note that as different page messages have different priorities, the drop rates for different messages may be significantly different. The overload control mechanism will drop lower priority messages before it drops higher priority messages. Drop rate by reason Refer to for the message drop reasons captured by this metric. (FPCHMessagesDroppedByReason[i] / PagingChannelMessageCount) x 100 For example, the Message Drop Rate due to the EROC-Paging feature is expressed by: (PagingChannelMessageReceivedByReason[3 = Messages Dropped by EROC-Paging feature] / PagingChannelMessageReceivedCount) x 100 Note: The PagingChannelMessageReceivedCount OM used in this formula is in the AdvancedSector MO and should not be confused with the OM of the same name in the BTSCallProcessing MO. FCCCH channel message drop rate All the metrics discussed under paging channel message drop rate are applicable for the FCCCH Channel.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
For example: Drop rate by message type is given by: (FCCCHMessagesReceivedDropped[i for message type dropped] / FCCCHMessagesReceivedDropped[j for message type received]) x 100 Since these channels can operate at higher data rates as compared to the paging channel, one may expect the drop rate by message type and drop rate by reason metric values for the FCCCH to be lower than its equivalent metric values for the paging channel. In addition, currently EROC for FCCCH is not being implemented. Hence the message drop rate due to EROC metric will be zero. Mobiles on the FCCCH require an ECAM or MECAM message hence the count for CAM messages received and dropped should be zero.
Forward common channel messages sent by type
The following formula provides the operator information relating to how the available Common Channel bandwidth is being used, i.e. the percentage of messages sent that are of a given type on a given channel. It provides trending information that can be used for common channel optimization and paging feature deployment (i.e. IZP, FBP, etc.), as well as information that can be used to investigate access failures, SMS delivery failures, etc. Paging channel messages sent by type Refer to for the index mapping used in this metric for the different message types. ((FPCHMessagesReceivedDropped[i for message type received] FPCHMessagesReceivedDropped[i for message type dropped]) / (PagingChannelMessageReceivedCount PagingChannelMessageDroppedCount)) x 100 For the MECAM, ECAM and CAM messages, the number of messages dropped of each type will be the sum of (FPCHMessagesReceivedDropped[8] + FPCHMessagesReceivedDropped[9]), (FPCHMessagesReceivedDropped[11] + FPCHMessagesReceivedDropped[12]) and (FPCHMessagesReceivedDropped[14] + FPCHMessagesReceivedDropped[15]), respectively. If the drop reason is of interest, the individual array elements may be used.
CDMA
NBSS15.0
Network response rate for access channel messages For every message received on the access channel, the network transmits a Base station acknowledgement order on the paging channel. The network response ratio is given by: (FPCHMessagesReceivedDropped[16] FPCHMessagesReceivedDropped[18]) / ACHMessagesReceived[i] for i = 3 to 11 FCCCH channel messages sent by type The metric discussed above for the paging channel is applicable for the FCCCH Channel.
MFRM-3
For more information about DeliveredPowerStats, DemandedPowerStats, MultiSectorCarrierPowerStats and RadioPowerStats OMs, see BTS OM descriptions (page 23-1). Percentage of time the carrier-sector was in power limiting, when sector power pooling was disabled (i.e. attribute RFM MO: SectorPowerPoolingEnabled = False) = DemandedPowerStats: PercentTimeAboveConfiguredPowerLimitingThreshold Or
DemandedPowerStats: PercentTimeAboveConfiguredPowerLimitingThresholdSPP This metric would enable the operator to determine whether there is a need to purchase the sector power pooling license. If this metric is non-zero and the value of MultiSectorCarrierPowerStats: PerCarrierPowerLimitingThreshold OM (for the carrier in question) is zero, then the carrier-sector can benefit from sector power pooling. Note: When sector power pooling is disabled (i.e. attribute RFM MO: SectorPowerPoolingEnabled = False), then ConfiguredPowerLimitingThreshold = ConfiguredPowerLimitingThresholdSPP.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Percentage of time the carrier-sector was in power limiting, when sector power pooling was enabled (i.e. attribute RFM MO: SectorPowerPoolingEnabled = True) = DemandedPowerStats: PercentTimeAboveConfiguredPowerLimitingThresholdSPP This metric would enable the operator to determine whether an increase in the sector power pooling threshold (i.e. attribute PowerManagement MO: SectorPowerPoolingThreshold) for the carrier-sector is needed, if the current value of SectorPowerPoolingThreshold is less than 1.5 dB. If this metric is non-zero and the value of MultiSectorCarrierPowerStats: PerCarrierPowerLimitingThreshold OM (for the carrier in question) is zero, then the carrier-sector can benefit from an increase in the sector power pooling threshold. Percentage of time there was a sector power pooling benefit in the carriersector = DeliveredPowerStats: PercentTimeAboveConfiguredPowerLimitingThreshold. The average amount of sector power pooling benefit used by the carriersector = AvgTxPowerAboveMaxSPP. Percentage of time the sector power pooling benefit could not be delivered on one or more carrier-sectors due to high traffic on the other carrier-sectors = MultiSectorCarrierPowerStats: PerCarrierPowerLimitingThreshold (for the carrier in question). If this metric is non-zero then it means that the carrier is in power limiting. This points to the fact that the sector power pooling threshold is likely set too aggressively for this carrier on one or more of the carrier-sectors. The recommended approach is to reduce the sector power pooling threshold on the carrier-sectors that are causing the carrier to go in power limiting until the carrier is no longer in power limiting (i.e. the value of this metric for the carrier is zero). Percentage of time the carrier was in power limiting = MultiSectorCarrierPowerStats: PerCarrierPowerLimitingThreshold OM (for the carrier in question). If the above metric is non-zero, then the sector power pooling threshold for the carrier on one or more of the carrier-sectors is likely set aggressively. The recommended approach is to reduce the sector power pooling thresholds on the carrier-sectors that are causing the carrier to go in power limiting until the carrier is no longer in power limiting.
CDMA
NBSS15.0
Percentage of time the transmit chain was in power limiting = RadioPowerStats: PerTransmitChainPowerLimitingThreshold.
Metro Cell validation formulas

QueuedFwdSchBurstNonBlocking3G[0-3] = DistributionOf2XDataRateDelay[0-8] + DistributionOf4XDataRateDelay[0-8] + DistributionOf8XDataRateDelay[0-8] + DistributionOf16XDataRateDelay[0-8] QueuedFwdSchBurstNonBlocking3G[0-3] = DistributionOfPriorityClass0Delay[0-8] + DistributionOfPriorityClass1Delay[0-8] + DistributionOfPriorityClass2Delay[0-8] + DistributionOfPriorityClass3Delay[0-8] + DistributionOfPriorityClass4Delay[0-8] + DistributionOfPriorityClass5Delay[0-8] + DistributionOfPriorityClass6Delay[0-8] + DistributionOfPriorityClass7Delay[0-8] + DistributionOfPriorityClass8Delay[0-8] + DistributionOfPriorityClass9Delay[0-8] + DistributionOfPriorityClass10Delay[0-8] + DistributionOfPriorityClass11Delay[0-8] + DistributionOfPriorityClass12Delay[0-8] + DistributionOfPriorityClass13Delay[0-8] ForwardTxUsageHistogram[0-9] = 1800 (seconds) RadialHandoffAttempts = RadialHandoffSuccesses + RadialHandoffFailures PerRingAccessAttempts = PerRingAccessSuccesses + PerRingAccessFailures FCCCHTotalMessageReceivedCount = FCCCHMessagesReceivedDropped [i] over all messages received array elements FCCCHTotalMessageDroppedCount= FCCCHMessagesReceivedDropped [i] over all messages dropped array elements
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Paging performance
10
This chapter describes the paging performance for call terminations in a local system. When BCP (Border Cell Paging) is activated, the local system where the call termination attempt first arrives is called the Anchor system in this document. For more information about the intersystem paging performance in a border system, see Border paging performance (page 11-1). It discusses CDMA call delivery performance, IZP (Intelligent Zone Paging) zone performance, MWI (Message Waiting Indication) performance and VPAD (Voice Preemption of Active Data) paging performance. It also provides metrics to track the intersystem paging performance at the Anchor System for each Border route (when BCP is activated). This chapter also provides a metric to track the performance of AMPS cell repaging after no response is received from the CDMA cells. Note: Throughout this document, Anchor system is synonymous with a Serving system.
Goal
Attempts to page a CDMA mobile using IZP zones (with any zone page option) should result in a page response per zone of x%.
10
Attempts to page a CDMA mobile should result in a page response of w%.
Attempts to page a CDMA mobile in a Border system should result in a page response of y%. Attempts to page a dual-mode mobile in the AMPS cells should result in a page response of z%.
CDMA
NBSS15.0
10-2 Paging performance Nortel Networks
List of OMs
10
For more information about the following OMs, see MSC OM descriptions (page 21-1).
Paging performance OMs MSC OMs CAUDATSY OM group CAUBMWNA CAUPMWNT CAUPMWRT CAUTMWRA CAUPMWNA CAUBMWNT CAUTMWNA CAUMWSIS CAUPMWNC CAUPMWRA CAUTMWNC CAUBMWNC CAUPMWNR CAUTMWNT
CDMAPAGE OM group PGATTM1 PGTMOT1 PGATTM2 PGTMOT2 PGATTM3 PGTMOT3 DPGRES1 PGATTM1X PGTMOT1X PGATTM2X PGTMOT2X PGATTM3X PGTMOT3X DPGRES2 PGRESP1 ORGTRM1 PGRESP2 ORGTRM2 PGRESP3 ORGTRM3 PGRESP1X ORGTRM1X PGRESP2X ORGTRM2X PGRESP3X ORGTRM3X
CDMAPGZN OM group PGZNREQ PGZNLPOR PGZNTO RPGLPAT RPSYSRSI PG3ZNREQ PGZNRES PGZNSYRQ PGZNAB RPGLPIR RPSYSRSO PG3ZNRES PGZNLPAT PGZNSYIR RPGZNREQ RPGLPOR REPGTO PG3LPAT
sheet 1 of 4
PGZNLPIR PGZNSYOR RPGZNRES RPSYSRQ RPGZNAB PG3LPIR
411-2133-525
Standard
06.12
April 2008
Nortel Networks Paging performance OMs (continued) MSC OMs PG3LPOR PG3ZNTO PG3SYSRQ PG3ZNAB PG3SYSRI
Paging performance 10-3 Copyright 2008 Nortel Networks
PG3SYSRO
CDMAPGZX OM group
This OM group provides extension registers for all of the OMs in CDMAPGZN group. For example, PGZNREQX is the extension register for CDMAPGZN:PGZNREQ.
CDMAPGZ2 OM group PGZNIDR PGZNODR RPZNIDR RPZNODR
CDMPRDIS OM group
This OM group provides a histogram for the distribution of page response time from 1 to 16 seconds.
CDMASIPG OM group IPG2VATT IPG2VTO IPG2DATT IPG2DTO IPG2SATT IPG2STO IPG2VATX IPG2VTOX IPG2DATX IPG2DTOX IPG2SATX IPG2STOX IPG2VRR IPG2VRFL IPG2DRR IPG2DRFL IPG2SRR IPG2SRFL IPG2VRRX IPG2VRFX IPG2DRRX IPG2DRFX IPG2SRRX IPG2SRFX
CDMASIP2 OM group IPG2V1RR IPG2V3RR IPG2V2FL IPG2D1RR IPG2V1RX IPG2V3RX IPG2V2FX IPG2D1RX IPG2V2RR IPG2V1FL IPG2V3FL IPG2D2RR
sheet 2 of 4
IPG2V2RX IPG2V1FX IPG2V3FX IPG2D2RX
CDMA
NBSS15.0
10-4 Paging performance Nortel Networks Paging performance OMs (continued) MSC OMs IPG2D3RR IPG2D2FL IPG2S1RR IPG2S1FL IPG2D3RX IPG2D2FX IPG2S1RX IPG2S1FX IPG2D1FL IPG2D3FL IPG2S2RR IPG2S2FL
IPG2D1FX IPG2D3FX IPG2S2RX IPG2S2FX
MTXSYS1 OM group RPGAMPS AMPSRESP AMPSTO
MTXSYSX OM group RPGAMPS2
This OM group provides extension registers for some of the OMs in MTXSYS1 group. AMPSRSP2 AMPSTO2
MWIZONPG OM group PGZNREQ RPGZNRES PGZNREQ2 RPSYSRQ2 PGZNRES RPSYSRQ PGZNRES2 RPSYSRS2 PGZNTO RPSYSRS RPGZNRQ2 RPGZNREQ REPGTO RPGZNRS2
NWKOG2 OM group RELIVOG
OMMTX2 OM group VPADIC
OMMTXSY2 OM group
sheet 3 of 4
411-2133-525
Standard
06.12
April 2008
Nortel Networks Paging performance OMs (continued) MSC OMs VPADATT VPADSUC VPADFL
SMSZONPG OM group PGZNREQ PGZNSYRQ RPGZNRES RPGZNAB PGZNRES PGZNSYIR RPSYSRQ REPGTO PGZNTO PGZNSYOR RPSYSRSI PGZNAB RPGZNREQ RPSYSRSO
SMSZONPX OM group
This OM group provides extension registers for all of the OMs in SMSZONPG group. For example, PGZNREQX is the extension register for SMSZONPG:PGZNREQ.
sheet 4 of 4
10
CDMA call delivery performance metrics
10
This section provides CDMA system-level call delivery performance metrics (i.e. paging performance for call terminations) for Voice, CSD and Packet Data call types, regardless of the paging method used i.e. system-wide or zone based. These metrics may be useful for optimizing paging related configurable parameters such as the number of local page attempts, the page timeout value etc. that are configured in the Table PAGECTRL. If the call delivery performance is low, then additional metrics described in CDMA IZP zone performance metrics (page 10-15), Paging channel utilization (page 9-24), Access channel utilization (page 9-26), Mobile response rate to paging channel messages (page 9-30), and Paging channel message drop rate (page 9-31) can also be evaluated during investigation. Overall call delivery performance of a system without BCP activated Percentage of overall successful paging rate is expressed by the following ratio: ((Number of first page responses + Number of second page responses + Number of third page responses) / (Number of first page requests Number of originator terminations for the first page - Number of
originator terminations for the second page - Number of originator terminations for the third page)) x 100 Number of first page responses =
PGRESP1 + (PGRESP1X * 65536)
Number of second page responses =

Number of third page responses =

Number of first page requests =

PGATTM1 + (PGATTM1X * 65536)
Number of originator terminations for the first page =

ORGTRM1 + (ORGTRM1X * 65536)
Number of originator terminations for the second page =

Number of originator terminations for the third page =

First page success rate is expressed by the following ratio: ((Number of first page responses) / (Number of first page requests Number of originator terminations for the first page)) x 100 Number of first page responses =


Second page success rate is expressed by the following ratio: ((Number of second page responses)/(Number of second page requests Number of originator terminations for the second page)) x 100 Number of second page responses =
Number of second page requests =


411-2133-525 Standard 06.12 April 2008
Nortel Networks ORGTRM2 + (ORGTRM2X * 65536)
Third page success rate is expressed by the following ratio: ((Number of third page responses)/(Number of third page requests Number of originator terminations for the third page)) x 100 Number of third page responses =
Number of third page requests =


The paging performance metrics for the 5 CDMA call types (2G CSD, 3G CSD, 2G Voice, 3G Voice, and 3G Packet Data) can be calculated separately. Choose the tuple(s) from the CDMAPAGE OM group to be used in the above formulas as follows: For 2G CSD call paging performance Use the OMs from the index 0 tuple (CSD_MOB_P_REV_1_TO_5). For 3G CSD call paging performance Use the OMs from the index 1 tuple (CSD_MOB_P_REV_6)and the index 2 tuple (CSD_MOB_P_REV_7_PLUS). For 2G voice call paging performance Use the OMs from the index 3 tuple (VOICE_MOB_P_REV_1_TO_5). For 3G voice call paging performance Use the OMs from the index 4 tuple (VOICE_MOB_P_REV_6)and the index 5 tuple (VOICE_MOB_P_REV_7_PLUS). For 3G packet data call paging performance Use the OMs from the index 6 tuple (PACKET_DATA_MOB_P_REV_6) and the index 7 tuple (PACKET_DATA_MOB_P_REV_7_PLUS). For all call types call paging performance Use the sum of the OMs from the index 0, 1, 2, 3, 4, 5, 6 and 7 tuples. Note: Since the paging of a mobile for termination of a packet data call is network initiated, the page abandon registers in CDMAPAGE may never be pegged for packet data calls.
CDMA
NBSS15.0
Overall Call Delivery failure rate of a System can be derived by subtracting the Overall Call Delivery Performance of a System without BCP activated metric value from 100. Time distribution of page responses The PRDISnn OMs of the CDMPRDIS OM group make up a histogram that provides the time distribution of page responses received at the CM, where page response time is the time interval between a page request and the corresponding page response. The histogram bins are from 1 to 16 seconds with one second increment. The sum of the number of pegs over all of the bins reflects the number of page responses received in that OM collection period. Average and peak page response time calculations can be obtained from this histogram. Delayed page response rate This metric measures the number of first and second page responses that arrive late at the MTX CM, in terms of the configured page timeout value for the page response. Hence, the delayed page response is one that arrives after the response timer for that page attempt request has expired. Percentage of delayed page response rate for first page is expressed by the following ratio: (Number of delayed first page responses/Total number of responses to first page attempt) x 100 Number of delayed first page responses =
DPGRES1
Total number of responses to first page attempt =

PGRESP1 + (PGRESP1X * 65536) + DPGRES1
Percentage of delayed page response rate for second page is expressed by the following ratio: (Number of delayed second page responses/Total number of responses to second page attempt) x 100 Number of delayed second page responses =
DPGRES2
Total number of responses to second page attempt =

PGRESP2 + (PGRESP2X * 65536) + DPGRES2 - DPGRES1
This metric may be used to optimize page timers such that page attempts are reduced and paging channel capacity is conserved. This is because higher delayed page response rates indicate that the configured page timeout value at the CM may be too short.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Overall call delivery performance of an anchor system with BCP activated Percentage of overall successful paging rate is expressed by the following ratio: ((Number of first page responses + Number of second page responses + Number of third page responses + Number of page responses received in border systems) / (Number of first page requests - Number of originator terminations for the first page - Number of originator terminations for the second page - Number of originator terminations for the third page)) x 100 Number of first page responses =


Number of page responses received in border systems =

(IPG2VRR + IPG2DRR) FOR ALL BORDER ROUTES




First page success rate is expressed by the following ratio: ((Number of first page responses + Number of first page responses received in border systems) / (Number of first page requests - Number of originator terminations for the first page)) x 100 Number of first page responses =
Number of first page responses received in border systems =

(IPG2V1RR + (IPG2V1RX * 65536) + IPG2D1RR + (IPG2D1RX * 65536)) FOR ALL BORDER ROUTES

10-10 Paging performance Nortel Networks PGATTM1 + (PGATTM1X * 65536)

Second page success rate is expressed by the following ratio: ((Number of second page responses + Number of second page responses received in border systems)/(Number of second page requests - Number of originator terminations for the second page)) x 100 Number of second page responses =
Number of second page responses received in border systems =



Third page success rate is expressed by the following ratio: ((Number of third page responses + Number of third page responses received in border systems)/(Number of third page requests - Number of originator terminations for the third page)) x 100 Number of third page responses =
Number of third page responses received in border systems =



The above call delivery performance metric is for all call types, and it can be derived by using the sum of the OMs from the index 0, 1, 2, 3, 4, 5, 6 and 7 tuples of CDMAPAGE OM group. The same call delivery performance metric combined for Voice and CSD calls can be derived by using the OMs from the index 0, 1, 2, 3, 4 and 5 tuples of CDMAPAGE OM group and by excluding IPG2DRR, IPG2D1RR,
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Paging performance 10-11 Copyright 2008 Nortel Networks IPG2D2RR, IPG2D3RR OMs and respective extension registers from the formula. Note however that BCP is not supported for CSD calls.
The same call delivery performance metric for Packet Data calls only can be derived by using the OMs from the index 6 and 7 tuples of CDMAPAGE OM group and by excluding IPG2VRR, IPG2V1RR, IPG2V2RR, IPG2V3RR OMs and respective extension registers from the formula.
Overall Call Delivery failure rate of a System can be derived by subtracting Overall Call Delivery Performance of a System with Border Cell Paging activated metric value from 100.
CDMA intersystem paging performance metrics
10
This section provides CDMA intersystem paging performance metrics on a per Anchor system, per Anchor sector (i.e. the sector in the Anchor system where the mobile is last known to be in) and per Border system route, distinguished for Voice, Packet Data and SMS call types. These metrics are associated with call terminations that are attempted in Border systems (when BCP is activated in Anchor system and Border systems), regardless of the paging method used in the Border system, i.e. system-wide or zone based. These performance metrics are useful to determine and compare paging performance across different Border systems that are adjacent to an Anchor system. They can also be used to determine the performance of intersystem paging on a Border system route provisioned for a specific Anchor sector. This can help in reconfiguring and optimizing the Border system configurations for the Anchor sector. For example, a Border system route with extremely low success rates could be removed from the corresponding Anchor sector to avoid the impact on paging channel capacity in the Border system. In addition, intersystem paging related configurable parameters can be optimized or BCP zones can be reconfigured in the Border system. For more information, see Border paging performance (page 11-1). These metrics can not provide per page attempt granularity because the Anchor system only sends one ISPAGE2 Invoke message to the Border system specifying the number of page attempts that the Border system should make. In response to the ISPAGE2 Invoke message, the Border system only sends one ISPAGE2 Return Result message to the Anchor system (i.e. ISPAGE2 Return Result message is not sent per border page attempt). Note: The call abandon scenario affects all metrics described in this section because such occurrences should be subtracted from the number of intersystem page attempts. However, the number of such occurrences are not included in the formulas below, because that number is expected to be insignificant, especially on a per Anchor sector basis and on a per Border route basis.
Overall intersystem paging performance of an anchor system (all border routes of all anchor sectors) Percentage of overall successful paging rate is expressed by the following ratio: (Number of intersystem page successes for all calls / Number of intersystem page attempts for all calls) x 100 Number of intersystem page successes for all calls =
[(IPG2VRR + (IPG2VRRX * 65536)) + (IPG2DRR + (IPG2DRRX * 65536)) + (IPG2SRR + (IPG2SRRX * 65536))] FOR ALL BORDER ROUTES OF ALL ANCHOR SECTORS
Number of intersystem page attempts for all calls =

[(IPG2VATT + (IPG2VATX * 65536)) 1 + (IPG2DATT + (IPG2DATX * 65536)) 2 + (IPG2SATT + (IPG2SATX * 65536)) 3] FOR ALL ANCHOR
SECTORS
1 In the
case when an Anchor sector has more than one Border route, use the (IPG2VATT + (IPG2VATX * 65536)) of any one route of that Anchor sector. Individual counts of (IPG2VATT + (IPG2VATX * 65536)) for each Border route of that Anchor sector must not be summed here. Usually, such individual counts for each Border route of the Anchor sector should be equal (depending, however on each Border routes individual parameter setting for sending intersystem page requests on that route) and any one (IPG2VATT + (IPG2VATX * 65536)) OM count can be selected. 2 See Note 1. It similarly applies to (IPG2DATT + (IPG2DATX * 65536)) used in this formula. 3 See Note 1. It similarly applies to (IPG2SATT + (IPG2SATX * 65536)) used in this formula.
Success rate for Voice calls is expressed by the following ratio: (Number of intersystem page successes for Voice calls / Number of intersystem page attempts for Voice calls) x 100 Number of intersystem page successes for Voice calls = (IPG2VRR + (IPG2VRRX * 65536)) FOR ALL BORDER ROUTES OF ALL
ANCHOR SECTORS
Number of intersystem page attempts for Voice calls = (IPG2VATT + (IPG2VATX * 65536)) 1 FOR ALL ANCHOR SECTORS
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Success rate for Packet Data calls is expressed by the following ratio: (Number of intersystem page successes for Packet Data calls / Number of intersystem page attempts for Packet Data calls) x 100 Number of intersystem page successes for Packet Data calls =
(IPG2DRR + (IPG2DRRX * 65536)) FOR ALL BORDER ROUTES OF ALL ANCHOR SECTORS
Number of intersystem page attempts for Packet Data calls =

(IPG2DATT + (IPG2DATX * 65536)) 2 FOR ALL ANCHOR SECTORS
Success rate for SMS calls is expressed by the following ratio: (Number of intersystem page successes for SMS calls / Number of intersystem page attempts for SMS calls) x 100 Number of intersystem page successes for SMS calls =
((IPG2SRR + (IPG2SRRX * 65536))) FOR ALL BORDER ROUTES OF ALL ANCHOR SECTORS
Number of intersystem page attempts for SMS calls =

(IPG2SATT + (IPG2SATX * 65536)) 3 FOR ALL ANCHOR SECTORS
Intersystem paging performance of an anchor sector (all border routes of the anchor sector) Percentage of successful paging rate is expressed by the following ratio: (Number of intersystem page successes for all calls / Number of intersystem page attempts for all calls) x 100 Number of intersystem page successes for all calls =
((IPG2VRR + (IPG2VRRX * 65536)) + (IPG2DRR + (IPG2DRRX * 65536)) + (IPG2SRR + (IPG2SRRX * 65536))) FOR ALL BORDER ROUTES OF THE ANCHOR SECTOR

((IPG2VATT + (IPG2VATX * 65536)) 1 + (IPG2DATT + (IPG2DATX * 65536)) 2 + (IPG2SATT + (IPG2SATX * 65536)) 3) OF THE ANCHOR
SECTOR
Success rate for Voice calls is expressed by the following ratio: (Number of intersystem page successes for Voice calls / Number of intersystem page attempts for Voice calls) x 100 Number of intersystem page successes for Voice calls =
CDMA
NBSS15.0
Copyright 2008 Nortel Networks (IPG2VRR + (IPG2VRRX * 65536)) FOR ALL BORDER ROUTES OF THE ANCHOR SECTOR
Number of intersystem page attempts for Voice calls =

(IPG2VATT + (IPG2VATX * 65536)) 1 OF THE ANCHOR SECTOR
(IPG2DRR + (IPG2DRRX * 65536)) FOR ALL BORDER ROUTES OF THE ANCHOR SECTOR

(IPG2DATT + (IPG2DATX * 65536)) 2 OF THE ANCHOR SECTOR
((IPG2SRR + (IPG2SRRX * 65536))) FOR ALL BORDER ROUTES OF THE ANCHOR SECTOR

(IPG2SATT + (IPG2SATX * 65536)) 3 OF THE ANCHOR SECTOR
Intersystem paging performance of a border route (of an anchor sector) Percentage of successful paging rate is expressed by the following ratio: (Number of intersystem page successes for all calls / Number of intersystem page attempts for all calls) x 100 Number of intersystem page successes for all calls =
((IPG2VRR + (IPG2VRRX * 65536)) + (IPG2DRR + (IPG2DRRX * 65536)) + (IPG2SRR + (IPG2SRRX * 65536))) OF THE BORDER ROUTE

((IPG2VATT + (IPG2VATX * 65536)) + (IPG2DATT + (IPG2DATX * 65536)) + (IPG2SATT + (IPG2SATX * 65536))) OF THE BORDER ROUTE
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Success rate for Voice calls is expressed by the following ratio: (Number of intersystem page successes for Voice calls / Number of intersystem page attempts for Voice calls) x 100 Number of intersystem page successes for Voice calls =
(IPG2VRR + (IPG2VRRX * 65536)) OF THE BORDER ROUTE

(IPG2VATT + (IPG2VATX * 65536)) OF THE BORDER ROUTE
(IPG2DRR + (IPG2DRRX * 65536)) OF THE BORDER ROUTE

(IPG2DATT + (IPG2DATX * 65536)) OF THE BORDER ROUTE
[(IPG2SRR + (IPG2SRRX * 65536))] OF THE BORDER ROUTE

(IPG2SATT + (IPG2SATX * 65536)) OF THE BORDER ROUTE
CDMA IZP zone performance metrics
10
This section provides CDMA zone performance metrics for IZP zones. These metrics are associated with page attempts that are configured to use the zone paging method (when IZP is activated in the local system i.e. Anchor system with BCP). These metrics are defined separately for each page attempt that can be configured to use the IZP zone paging method. Refer to sections Zone performance for voice, CSD, and packet data calls (page -16), Zone performance for SMS calls (page -20) and Zone performance for MWI (page -22). These metrics must be used for IZP zone performance only and must not be used for the overall system-level performance.
CDMA
NBSS15.0
Zone performance for voice, CSD, and packet data calls These performance metrics are useful to determine the overall IZP zone performance as well as the per page attempt performance for Voice, CSD and Packet Data call types combined, regardless of zone, zone+zonelist or system-wide page option. This helps determine the effectiveness of the zone configuration and is useful for optimizing overall zone configuration within a system. Maximizing zone performance may improve the capacity of paging and access channels. These metrics may be useful for optimizing zone paging related configurable parameters such as the zone page option etc., that are configured in the Table CDMAPGZN. The metrics mentioned in this section use OMs from the CDMAPGZN and CDMAPGZX OM groups. The following terms are used in these metrics. Number of first page responses =
PGZNRES + (PGZNRESX * 65536) + PGZNLPIR + (PGZNLPIX * 65536) + PGZNLPOR + (PGZNLPOX * 65536) + PGZNSYIR + (PGZNSYIX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)
Number of in-zone first page responses =

PGZNRES + (PGZNRESX * 65536) + PGZNLPIR + (PGZNLPIX * 65536) + PGZNSYIR + (PGZNSYIX * 65536)
Number of out-of-zone first page responses =

PGZNLPOR + (PGZNLPOX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)

RPGZNRES + (RPGZNREX * 65536) + RPGLPIR + (RPGLPIRX * 65536) + RPGLPOR + (RPGLPORX * 65536) + RPSYSRSI + (RPSYSRIX * 65536) + RPSYSRSO + (RPSYSROX * 65536)
Number of in-zone second page responses =

RPGZNRES + (RPGZNREX * 65536) + RPGLPIR + (RPGLPIRX * 65536) +
411-2133-525
Standard
06.12
April 2008
Nortel Networks RPSYSRSI + (RPSYSRIX * 65536)
Number of out-of-zone second page responses =

RPGLPOR + (RPGLPORX * 65536) + RPSYSRSO + (RPSYSROX * 65536)

PG3ZNRES + (PG3ZNREX * 65536) + PG3LPIR + (PG3LPIRX * 65536) + PG3LPOR + (PG3LPORX * 65536) + PG3SYSRI + (PG3SYRIX * 65536) + PG3SYSRO + (PG3SYROX * 65536)
Number of in-zone third page responses =

PG3ZNRES + (PG3ZNREX * 65536) + PG3LPIR + (PG3LPIRX * 65536) + PG3SYSRI + (PG3SYRIX * 65536)
Number of out-of-zone third page responses =

PG3LPOR + (PG3LPORX * 65536) + PG3SYSRO + (PG3SYROX * 65536)

PGZNREQ + (PGZNREQX * 65536) + PGZNLPAT + (PGZNLPAX * 65536) + PGZNSYRQ + (PGZNSYRX * 65536)

RPGZNREQ + (RPGZNREX * 65536) + RPGLPAT + (RPGLPATX * 65536) + RPSYSRQ + (RPSYSRQX * 65536)

PG3ZNREQ + (PG3ZNREX * 65536) + PG3LPAT + (PG3LPATX * 65536) + PG3SYSRQ + (PG3SYRQX * 65536)

PGZNAB + (PGZNABX * 65536)

RPGZNAB + (RPGZNABX * 65536)

PG3ZNAB + (PG3ZNABX * 65536)
Number of delayed in-zone first page responses =
CDMA
NBSS15.0
10-18 Paging performance Nortel Networks PGZNIDR
Number of delayed out-of-zone first page responses =

PGZNODR
Total number of first page responses = Number of first page responses + PGZNIDR + PGZNODR Number of delayed in-zone second page responses =
RPZNIDR
Number of delayed out-of-zone second page responses =

RPZNODR
Total number of second page responses = Number of second page responses + RPZNIDR + RPZNODR PGZNIDR - PGZNODR
Overall zone performance Percentage of overall successful paging rate for a zone is expressed by the following ratio: ((Number of first page responses + Number of second page responses + Number of third page responses) / (Number of first page requests + Number of second page requests + Number of third page requests Number of originator terminations for the first page - Number of originator terminations for the second page - Number of originator terminations for the third page)) x 100 Note: The above metric gives the performance of the zone in terms of the number of page responses received in response to the page requests sent in the zone. It does not necessarily reflect the call delivery performance of the zone in question. Zone performance of first page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of first page responses) / (Number of first page requests Number of originator terminations for the first page)) x 100 IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone first page responses) / (Number of first page requests - Number of originator terminations for the first page)) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone first page responses) / (Number of first page requests - Number of originator terminations for the first page)) x 100 Zone performance of second page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of second page responses) / (Number of second page requests Number of originator terminations for the second page)) x 100 IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone second page responses) / (Number of second page requests - Number of originator terminations for the second page)) x 100 OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone second page responses) / (Number of second page requests - Number of originator terminations for the second page)) x 100 Zone performance of third page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of third page responses) / (Number of third page requests Number of originator terminations for the third page)) x 100 IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone third page responses) / (Number of third page requests - Number of originator terminations for the third page)) x 100 OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone third page responses) / (Number of third page requests - Number of originator terminations for the third page)) x 100 Delayed page response rate This metric measures the number of first and second zone page responses that arrive late at the MTX CM, in terms of the configured page timeout value for the page response. Hence, the delayed page response is one that arrives after the response timer for that page attempt request has expired.
CDMA
NBSS15.0
In-zone delayed page response rate for first page is expressed by the following ratio: (Number of delayed in-zone first page responses/Total number of first page responses) x 100 In-zone delayed page response rate for second page is expressed by the following ratio: (Number of delayed in-zone second page responses/Total number of second page responses) x 100 Out-of-zone delayed page response rate for first page is expressed by the following ratio: (Number of delayed out-of-zone first page responses/Total number of first page responses) x 100 Out-of-zone delayed page response rate for second page is expressed by the following ratio: (Number of delayed out-of-zone second page responses/Total number of second page responses) x 100 This metric may be used to optimize page timers such that page attempts are reduced and paging channel capacity is conserved. This is because higher delayed page response rates indicate that the configured page timeout value at the CM may be too short. Zone performance for SMS calls This will help determine the effectiveness of the zone definition. If a certain percentage of total success is not achieved then zone tuning should be performed. The metrics mentioned in this section use OMs under IZP zone type from SMSZONPG and SMSZONPX OM groups. Note: Same zone and system-wide page retry time outs are captured in REPGTO in the SMSZONPG OM group. The following terms are used in these metrics. Number of first page responses =
PGZNRES + (PGZNRESX * 65536) + PGZNSYIR + (PGZNSYIX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)

PGZNRES + (PGZNRESX * 65536) + 411-2133-525 Standard 06.12 April 2008
Nortel Networks PGZNSYIR + (PGZNSYIX * 65536)

PGZNSYOR + (PGZNSYOX * 65536)

RPGZNRES + (RPGZNREX * 65536) + RPSYSRSI + (RPSYSRIX * 65536) + RPSYSRSO + (RPSYSROX * 65536)

RPGZNRES + (RPGZNREX * 65536) + RPSYSRSI + (RPSYSRIX * 65536)

RPSYSRSO + (RPSYSROX * 65536)

PGZNREQ + (PGZNREQX * 65536) + PGZNSYRQ + (PGZNSYRX * 65536)

RPGZNREQ + (RPGZNRQX * 65536) + RPSYSRQ + (RPSYSRQX * 65536)
Number of abandons for the first page =

Number of abandons for the second page =

Overall zone performance Percentage of overall successful paging rate for a zone is expressed by the following ratio: ((Number of first page responses + Number of second page responses) / (Number of first page requests + Number of second page requests Number of abandons for the first page - Number of abandons for the second page)) x 100 Note: The above metric gives the performance of the zone in terms of the number of page responses received in response to the page requests sent in the zone. It does not necessarily reflect the call delivery performance of the zone in question.
CDMA
NBSS15.0
Zone performance of first page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of first page responses) / (Number of first page requests Number of abandons for the first page)) x 100 IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone first page responses) / (Number of first page requests - Number of abandons for the first page)) x 100 OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone first page responses) / (Number of first page requests - Number of abandons for the first page)) x 100 Zone performance of second page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of second page responses) / (Number of second page requests Number of abandons for the second page)) x 100 IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone second page responses) / (Number of second page requests - Number of abandons for the second page)) x 100 OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone second page responses) / (Number of second page requests - Number of abandons for the second page)) x 100 If a certain percentage of success is not achieved then zone tuning should be performed. Zone performance for MWI This will help determine the effectiveness of the zone definition. If a certain percentage of total success is not achieved then zone tuning should be performed. The metrics mentioned in this section use OMs from MWIZONPG OM group.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
Note: Same zone and system-wide page retry time outs are captured in REPGTO in the MWIZONPG OM group. Overflow registers in each OM group is identified by the trailing 2. Overall zone performance Percentage of overall successful page request for a zone is expressed by the following ratio: ((Total responses for initial zone page requests + Total responses for retry requests) / (Total initial page requests + Total retry requests)) x 100 Total responses for initial zone page requests =
PGZNRES + (PGZNRES2 * 65536)
Total responses for retry requests =

RPGZNRES + (RPGZNRS2 * 65536) + RPSYSRS + (RPSYRS2 * 65536)
Total initial page requests =

PGZNREQ + (PGZNREQ2 * 65536)
Total retry requests =

RPGZNREQ + (RPGZNRQ2 * 65536) + RPSYSRQ + (RPSYSRQ2 * 65536)
Zone paging performance for initial attempt Percentage of successful initial zone page requests for a zone is expressed by the following ratio: (Total responses for initial zone page requests / Total initial page requests for a zone) x 100 Total responses for initial zone page requests =
PGZNRES + (PGZNRES2 * 65536)
Total initial page requests for a zone =

PGZNREQ + (PGZNREQ2 * 65536)
If a certain percentage of success is not achieved then zone tuning should be performed. Zone paging performance for retry Percentage of successful zone retry requests for a zone is expressed by the following ratio: (Total responses for zone retry requests / Total zone retry requests for a zone) x 100 Total responses for zone retry requests =
CDMA
NBSS15.0
10-24 Paging performance Nortel Networks RPGZNRES + (RPGZNRS2 * 65536)
Total zone retry requests for a zone =

RPGZNREQ + (RPGZNRQ2 * 65536)
It is used in part to determine the effectiveness of the zone attempts. Zone paging performance for system-wide retry Percentage of successful system-wide retry for a zone is expressed by the following ratio: (Total system-wide retry responses / Total system-wide retries) x 100 Total system-wide retry responses =
RPSYSRS + (RPSYRS2 * 65536)
Total system-wide retries for a zone =

RPSYSRQ + (RPSYSRQ2 * 65536)
MWI delivery performance
10 10
A page request for MWI is sent during a mobile registration or when the MSC receives QUALDIR message from the HLR with MWI indication when message waiting indication is received at HLR. During mobile registration, if a message is pending for that mobile, with MWI retry not allowed and Intelligent Paging activated Page request for MWI is sent to a zone (it goes to both BSCs in dual BSC system). OM CAUPMWNA is pegged. with MWI retry allowed and Intelligent Paging activated First page attempt for MWI is sent to LKC (it goes to only one BSC in dual BSC system). OM CAUBMWNA is pegged. If first page attempt for MWI sent to LKC times out waiting for response, CAUBMWNT is pegged. If first page fails, retry page attempt for MWI is sent to a zone or system according to configuration of the zone where mobile is (it goes to both BSCs in dual BSC system). OM CAUPMWRA is pegged. with MWI retry not allowed and Intelligent Paging not activated Page request for MWI is sent to LKC (it goes to only one BSC in dual BSC system). OM CAUBMWNA is pegged. with MWI retry allowed and Intelligent Paging not activated First page attempt for MWI is sent to LKC (it goes to only one BSC in dual BSC system). OM CAUBMWNA is pegged.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
If first page attempt for MWI sent to LKC times out waiting for response, CAUBMWNT is pegged. If first page fails, retry page attempt for MWI is sent system wide (it goes to both BSCs in dual BSC system). OM CAUPMWRA is pegged. During QUALDIR message from the HLR to MSC with MWI indication on Paging Channel, with MWI retry not allowed and Intelligent Paging activated Page request for MWI is sent to a zone (it goes to both BSCs in dual BSC system). OM CAUPMWNA is pegged. with MWI retry allowed and Intelligent Paging activated First page attempt for MWI is sent to a zone (it goes to both BSCs in dual BSC system). OM CAUPMWNA is pegged. If first page attempt sent for MWI times out waiting for response from mobile, CAUPMWNT is pegged. If first page fails, retry page attempt for MWI is sent to a zone or system according to configuration of the zone where mobile is (it goes to both BSCs in dual BSC system). OM CAUPMWRA is pegged. with MWI retry not allowed and Intelligent Paging not activated Page request for MWI is sent system wide (it goes to both BSCs in dual BSC system). OM CAUPMWNA is pegged. with MWI retry allowed and Intelligent Paging not activated First page attempt for MWI is sent system wide (it goes to both BSCs in dual BSC system). OM CAUPMWNA is pegged. If first page attempt sent for MWI times out waiting for response from mobile, CAUPMWNT is pegged. If first page fails, retry page attempt for MWI is sent system wide (it goes to both BSCs in dual BSC system). OM CAUPMWRA is pegged. During QUALDIR message from HLR to MSC with MWI indication on Traffic Channel, A page attempt for MWI is sent to mobile on a Traffic Channel (TCH). It goes to one relevant BSC only in dual BSC system. OM CAUTMWNA is pegged. If the first page sent for MWI on Paging Channel times out waiting for the response and mobile has moved to the traffic channel before the retry page attempt for MWI is sent, then retry page attempt for MWI is sent on the traffic channel. It goes to relevant one BSC only in dual BSC system. CAUTMWRA is pegged.
If the first or retry page attempt for MWI is sent on traffic channel, times out waiting for response, CAUTMWNT is pegged.
The following metrics measure the performance of MWI Page for the different paging scenarios. Even the OMs defined above are pegged differently, the same metrics can be used regardless of Intelligent Paging is activated or not activated. Note: All the MWI performance formulas below are to measure System level performance ONLY. Do not use these formulas for per BSC performance. Add OMs from all CAUs for the formula below. Overall MWI delivery performance on paging channel and traffic channel-system level Percentage successes of the page attempts for MWI is expressed by the following ratio: (Total number of page successes / Total number of page attempts) x 100 Total number of page successes = CAUBMWNC + CAUPMWNC +
CAUPMWNR + CAUTMWNC
Total number of first page attempts = CAUBMWNA + (CAUPMWNA / Number of BSCs) + CAUTMWNA MWI delivery performance on paging channel - system level Overall page performance: Percentage successes of the page attempts for MWI is expressed by the following ratio: (Total number of page successes / Total number of page attempts) x 100 Total number of page successes = CAUBMWNC + CAUPMWNC +
CAUPMWNR
Total number of first page attempts = CAUBMWNA + (CAUPMWNA / Number of BSCs) First page attempt performance: Percentage success of first page attempts for MWI is expressed by the following ratio:
411-2133-525
Standard
06.12
April 2008
Nortel Networks
(Total number of first page successes / Total number of first page attempts) x 100 Total number of first page successes = CAUBMWNC + CAUPMWNC Total number of first page attempts = CAUBMWNA + (CAUPMWNA / Number of BSCs) Retry page attempt performance: Percentage success of retry page attempts for MWI is expressed by the following ratio: (Total number of MWI page retry successes / Total number of MWI page retry attempts) x 100 Total number of MWI page retry successes = CAUPMWNR Total number of MWI page retry attempts = (CAUPMWRA / Number of BSCs) MWI delivery performance on traffic channel - system level Percentage successes of the page attempts for MWI is expressed by the following ratio: (Total number of page successes / Total number of page attempts) x 100 Total number of page successes = CAUTMWNC Total number of first page attempts = CAUTMWNA + CAUTMWRA
CDMA
NBSS15.0
Voice preemption of active data feature paging performance

Overall paging failures for VPAD feature Percentage of overall voice call paging failures due to unanswered VPAD feature related requests is expressed by the following formula: (Number of page failures related to the VPAD feature / Number of VPAD related page requests)
10
Number of page failures related to the VPAD feature = VPADIC for all CDMA sectors - VPADATT Number of VPAD related page requests = VPADIC for all CDMA sectors Overall paging successes for VPAD feature Percentage of incoming voice requests (due to VPAD feature) resulting in a successful page responses (i.e., page success rate for the VPAD feature) is expressed by the following formula: (Number of VPAD related page responses / Number of VPAD related page requests) x 100 Number of VPAD related page responses = VPADATT Number of VPAD related page requests = VPADIC for all CDMA sectors
AMPS formulas
10
AMPS repaging formula In the case where the switch is set up to send a third page to both CDMA and AMPS, this metric measures the number of times that repaging in the AMPS cells results in a successfully locating the mobile: Number of AMPS repage responses -------------------------------------------------- x 100 Number of AMPS repage requests Number of AMPS repage responses = AMPSRESP + (AMPSRSP2 * 65536) Number of AMPS repage requests = RPGAMPS + (RPGAMPS2 * 65536)
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Validation
CDMA call delivery performance OM validations When BCP is not activated Attempts = Successes + Timeouts + Originator terminations
PGATTM1 + (PGATTM1X * 65536) = PGRESP1 + (PGRESP1X * 65536) + PGTMOT1 + (PGTMOT1X * 65536) + ORGTRM1 + (ORGTRM1X * 65536) PGATTM2 + (PGATTM2X * 65536) = PGRESP2 + (PGRESP2X * 65536) + PGTMOT2 + (PGTMOT2X * 65536) + ORGTRM2 + (ORGTRM2X * 65536) PGATTM3 + (PGATTM3X * 65536) = PGRESP3 + (PGRESP3X * 65536) + PGTMOT3 + (PGTMOT3X * 65536) + ORGTRM3 + (ORGTRM3X * 65536)
10
When BCP is activated If the BCP SOC is activated or de-activated during an OM collection period, then the validation formula below may not hold true for that OM collection period. Attempts = Successes in Anchor system + Successes in Border systems + All Originator terminations + Final Timeouts [PGATTM1 + (PGATTM1X * 65536)] for all tuples = { [PGRESP1 + (PGRESP1X * 65536)] for all tuples + [PGRESP2 + (PGRESP2X * 65536)] for all tuples + [PGRESP3 + (PGRESP3X * 65536)] for all tuples} + { [IPG2VRR] for all Border routes + [IPG2DRR] for all Border routes} + { [ORGTRM1 + (ORGTRM1X * 65536)] for all tuples + [ORGTRM2 + (ORGTRM2X * 65536)] for all tuples + [ORGTRM3 + (ORGTRM3X * 65536)] for all tuples} + { [PGTMOT1 + (PGTMOT1X * 65536)] for all tuples OR [PGTMOT2 + (PGTMOT2X * 65536)] for all tuples OR [PGTMOT3 + (PGTMOT3X * 65536)] for all tuples} Note: In the last term (Final Timeouts) above, to determine that value do the following. If the total number of both second and third page attempts are zero, then only use [PGTMOT1 + (PGTMOT1X * 65536)] for all tuples; If the total number of third page attempts are zero, then only use [PGTMOT2 + (PGTMOT2X * 65536)] for all tuples; Otherwise, only use [PGTMOT3 + (PGTMOT3X * 65536)] for all tuples. CDMA intersystem paging performance OM validations Attempts = Successes + Failures + Timeouts For any Border route of an Anchor sector,
CDMA
NBSS15.0
IPG2VATT + (IPG2VATX * 65536) = IPG2VRR + (IPG2VRRX * 65536) + IPG2VRFL + (IPG2VRFX * 65536) + IPG2VTO + (IPG2VTOX * 65536) IPG2DATT + (IPG2DATX * 65536) = IPG2DRR + (IPG2DRRX * 65536) + IPG2DRFL + (IPG2DRFX * 65536) + IPG2DTO + (IPG2DTOX * 65536) IPG2SATT + (IPG2SATX * 65536) = IPG2SRR + (IPG2SRRX * 65536) + IPG2SRFL + (IPG2SRFX * 65536) + IPG2STO + (IPG2STOX * 65536)
For any Border route of an Anchor sector,

IPG2VRR = IPG2V1RR + (IPG2V1RX * 65536) + IPG2V2RR + (IPG2V2RX * 65536) + IPG2V3RR + (IPG2V3RX * 65536) IPG2DRR = IPG2D1RR + (IPG2D1RX * 65536) + IPG2D2RR + (IPG2D2RX * 65536) + IPG2D3RR + (IPG2D3RX * 65536) IPG2VRFL = IPG2V1FL + (IPG2V1FX * 65536) + IPG2V2FL + (IPG2V2FX * 65536) + IPG2V3FL + (IPG2V3FX * 65536) IPG2DRFL = IPG2D1FL + (IPG2D1FX * 65536) + IPG2D2FL + (IPG2D2FX * 65536) + IPG2D3FL + (IPG2D3FX * 65536) IPG2SRR = IPG2S1RR + (IPG2S1RX * 65536) + IPG2S2RR + (IPG2S2RX * 65536) IPG2SRFL = IPG2S1FL + (IPG2S1FX * 65536) + IPG2S2FL + (IPG2S2FX * 65536)
CDMA zone performance OM validations (for a single zone) For voice, CSD, and packet data calls For Voice, CSD and Packet Data calls, use OMs from CDMAPGZN and CDMAPGZX OM groups in the validation formulas described here. Attempts = Successes + Timeouts + Abandons For First Page:
PGZNREQ + (PGZNREQX * 65536) + PGZNLPAT + (PGZNLPAX * 65536) + PGZNSYRQ + (PGZNSYRX * 65536) = {PGZNRES + (PGZNRESX * 65536) + PGZNLPIR + (PGZNLPIX * 65536) + PGZNLPOR + (PGZNLPOX * 65536) + PGZNSYIR + (PGZNSYIX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)} + {PGZNTO + (PGZNTOX * 65536)} + {PGZNAB + (PGZNABX * 65536)}
For Second Page:

RPGZNREQ + (RPGZNRQX * 65536) + RPGLPAT + (RPGLPATX * 65536) + RPSYSRQ + (RPSYSRQX * 65536) = {RPGZNRES + (RPGZNREX * 65536) + RPGLPIR + (RPGLPIRX * 65536) + RPGLPOR + (RPGLPORX * 65536) + RPSYSRSI + (RPSYSRIX * 65536) + RPGSYSRO + (RPSYSROX * 65536)} + {REPGTO + (REPGTOX * 65536)} + {RPGZNAB + (RPGZNABX * 65536)}
411-2133-525
Standard
06.12
April 2008
Nortel Networks
For Third Page:

PG3ZNREQ + (PG3ZNRQX * 65536) + PG3LPAT + (PG3LPATX * 65536) + PG3SYSRQ + (PG3SYRQX * 65536) = {PG3ZNRES + (PG3ZNREX * 65536) + PG3LPIR + (PG3LPIRX * 65536) + PG3LPOR + (PG3LPORX * 65536) + PG3SYSRI + (PG3SYRIX * 65536) + PG3SYSRO + (PG3SYROX * 65536)} + {PG3ZNTO + (PG3ZNTX * 65536)} + {PG3ZNAB + (PG3ZNABX * 65536)}
Note: Depending on the zone page or repage option configured in the system, some OMs in the above formulas may not get pegged (i.e. show zero value). For SMS For SMS, use OMs from SMSZONPG and SMSZONPX OM groups in the validation formula described here. Attempts = Successes + Non-Successes For First Page,
PGZNREQ + (PGZNREQX * 65536) + PGZNSYRQ + (PGZNSYRX * 65536) = {PGZNRES + (PGZNRESX * 65536) + PGZNSYIR + (PGZNSYIX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)} + {PGZNTO + (PGZNTOX * 65536)} + {PGZNAB + (PGZNABX * 65536)}
For Second Page,

RPGZNREQ + (RPGZNRQX * 65536) + RPSYSRQ + (RPSYSRQX * 65536) = {RPGZNRES + (RPGZNREX * 65536) + RPSYSRSI + (RPSYSRIX * 65536) + RPGSYSRO + (RPSYSROX * 65536)} + {REPGTO + (REPGTOX * 65536)} + {RPGZNAB + (RPGZNABX * 65536)}
For MWI calls Use OMs from MWIZONPG OM group in the validation formula described here. Attempts = Successes + Non-Successes For First Page:
PGZNREQ + (PGZNREQ2 * 65536) = PGZNRES + (PGZNRES2 * 65536) + PGZNTO
For retry:
RPGZNREQ + (RPGZNRQ2 * 65536) + RPSYSRQ + (RPSYSRQ2 * 65536) = RPGZNRES + (RPGZNRS2 * 65536) + RPSYSRS + (RPSYRS2 * 65536) + REPGTO
VPAD OMs
VPADATT = VPADSUC + VPADFL CDMA System Performance System Performance Metrics NBSS15.0
MWI OMs
CAUPMWNA=CAUPMWNC + CAUPMWNT CAUPMWRA = CAUPMWNR + CAUPMWRT CAUBMWNA = CAUBMWNC + CAUBMWNT CAUTMWNA + CAUTMWRA = CAUTMWNC + CAUTMWNT
Recommendations
CDMA paging If the CDMA paging performance metrics indicate low success rate, the service provider should investigate the use of Active Mobile Paging or possibly shorten that features activity timer, MOBILE_ACTIVE_MINUTES, which would inhibit more page requests from being sent out. This does decrease the chance of terminating to a subscriber because the attempt to locate and serve the subscriber is never made.
10
Zone paging It is possible that the mobiles may move from one zone X (where initial page request is being sent) to another zone Y before receiving the initial page request i.e. Mobile misses first page in zone X. if the mobile performs zone based registration (VLR has information on a new cell belonging to zone Y) in zone Y before page retry is sent then page retry is sent to the mobile, using the selected retry option for this zone Y. corresponding OMs for this zone Y will be pegged for the page retry. no retry OMs in the original zone X will be pegged.
In the above explained scenario, for the zone Y, when the page timeout OM for the previous page attempt is less than the page request OM for next page attempt (using any zone page option), the difference between them indicates the mobility between the zones i.e. more mobiles are moving into the zone. For the zone Y, when the page timeout OM for the previous page attempt is higher than the page request OM for next page attempt (using any zone page option), it indicates that more mobiles are moving out of this zone before receiving that previous page request. A very high difference between the page timeout OM for the previous page attempt and the page request OM for next page attempt will indicate high mobility between zones. An action should be taken accordingly for page zone boundary redefinition.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
It is recommended to revisit retry page option for a zone in question with higher number of mobiles moving into. For example, system-wide retry option is not beneficial for this zone as it may affect paging channel capacity.
CDMA
NBSS15.0
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Border paging performance
11
This chapter describes the paging performance in the Border system for intersystem page requests made by Anchor system, when BCP (Border Cell Paging) is activated in the Border system. For information about the intersystem paging performance in an Anchor system, see Paging performance (page 10-1). It discusses BCP zone performance and also provides metrics to track the intersystem paging performance for each Anchor system route.
Goal
11
Attempts to page a CDMA mobile in the Border system for a specific Anchor route should result in a page response of x%. Attempts to page a CDMA mobile in the Border system using BCP zones (with any zone page option) should result in a page response per zone of y%.
List of OMs
11
Border paging performance OMs MSC OMs CDMABIPG OM group IP2B1VAT IP2B2VAT IP2B3VAT IP2B1DAT IP2B2DAT IP2B1VRS IP2B2VRS IP2B3VRS IP2B1DRS IP2B2DRS IP2B1VTO IP2B2VTO IP2B3VTO IP2B1DTO IP2B2DTO
sheet 1 of 3
IP2B1VRL IP2B2VRL IP2B3VRL IP2B1DRL IP2B2DRL
CDMA
NBSS15.0
11-2 Border paging performance Nortel Networks Border paging performance OMs (continued) MSC OMs IP2B3DAT IP2B3DRS IP2B3DTO
IP2B3DRL
SMSBIPG OM group IP2B1SAT IP2B1SFL IP2B2SRL SMSBDDFL IP2B1SRS IP2B2SAT IP2B2SFL IP2B1STO IP2B2SRS SMSBDDAT IP2B1SRL IP2B2STO SMSBDDSC
CDMAPGZN OM group PGZNREQ PGZNLPOR PGZNTO RPGLPAT RPSYSRSI PG3ZNREQ PG3LPOR PG3ZNTO PGZNRES PGZNSYRQ PGZNAB RPGLPIR RPSYSRSO PG3ZNRES PG3SYSRQ PG3ZNAB PGZNLPAT PGZNSYIR RPGZNREQ RPGLPOR REPGTO PG3LPAT PG3SYSRI PGZNLPIR PGZNSYOR RPGZNRES RPSYSRQ RPGZNAB PG3LPIR PG3SYSRO
CDMAPGZX OM group
This OM group provides extension registers for all of the OMs in CDMAPGZN group. For example, PGZNREQX is the extension register for CDMAPGZN:PGZNREQ.
SMSZONPG OM group PGZNREQ PGZNSYRQ RPGZNRES PGZNRES PGZNSYIR RPSYSRQ PGZNTO PGZNSYOR RPSYSRSI
sheet 2 of 3
PGZNAB RPGZNREQ RPSYSRSO
411-2133-525
Standard
06.12
April 2008
Nortel Networks Border paging performance OMs (continued) MSC OMs RPGZNAB REPGTO
Border paging performance 11-3 Copyright 2008 Nortel Networks
SMSZONPX OM group
This OM group provides extension registers for all of the OMs in SMSZONPG group. For example, PGZNREQX is the extension register for SMSZONPG:PGZNREQ.
sheet 3 of 3
11
CDMA intersystem paging performance metrics
11
This section provides CDMA intersystem paging performance metrics on a per Anchor route (i.e. incoming route from an Anchor system) and on a per page attempt, further distinguished for Voice call types, Packet Data call types and SMS. These metrics are associated with call terminations that are attempted in Border systems (when BCP is activated in Anchor system and Border systems), regardless of the paging method used in the Border system i.e. system-wide or zone based. These performance metrics are useful to determine the overall intersystem paging performance of the Border system. This may help identify the need to reconfigure the paging parameters for page attempts in the Border system. Note: All the metrics mentioned in this section can be separately evaluated for first, second or third page attempts (Note that for SMS calls, the Border system does not attempt a third page). For instance, if the success rate for the second page attempt is desired, then only use second page related OMs for attempts, successes and cancellations in the formulas below. When more than one Anchor system is adjacent to the Border system, these performance metrics are also useful to compare intersystem paging performance between the different Anchor routes. This may help in reconfiguring and optimizing the adjacent route configuration for Anchor/ Border pairs. For example, an Anchor system route with extremely low success rates could be removed as an adjacent route of the Border system, to avoid the impact on paging channel capacity in the Border system.
CDMA
NBSS15.0
11-4 Border paging performance Nortel Networks
Overall intersystem paging performance of a border system (all anchor routes) Percentage of overall successful paging rate is expressed by the following ratio: (Number of intersystem page successes for all calls / (Number of intersystem page attempts for all calls - Number of page cancellations for all calls)) x 100 Number of intersystem page successes for all calls =
[IP2B1VRS + IP2B1DRS + IP2B1SRS + IP2B2VRS + IP2B2DRS + IP2B2SRS + IP2B3VRS + IP2B3DRS] FOR ALL ANCHOR ROUTES

[IP2B1VAT + IP2B1DAT + IP2B1SAT] FOR ALL ANCHOR ROUTES
Number of page cancellations for all calls =

[IP2B1VRL + IP2B1DRL + IP2B1SRL + IP2B2VRL + IP2B2DRL + IP2B2SRL + IP2B3VRL + IP2B3DRL] FOR ALL ANCHOR ROUTES
Success rate for Voice calls is expressed by the following ratio: (Number of intersystem page successes for Voice calls / (Number of intersystem page attempts for Voice calls - Number of page cancellations for Voice calls)) x 100 Number of intersystem page successes for Voice calls =
[IP2B1VRS + IP2B2VRS + IP2B3VRS] FOR ALL ANCHOR ROUTES

[IP2B1VAT] FOR ALL ANCHOR ROUTES
Number of page cancellations for Voice calls =

[IP2B1VRL + IP2B2VRL + IP2B3VRL] FOR ALL ANCHOR ROUTES
Success rate for Packet Data calls is expressed by the following ratio: (Number of intersystem page successes for Packet Data calls / (Number of intersystem page attempts for Packet Data calls - Number of page cancellations for Packet Data calls)) x 100 Number of intersystem page successes for Packet Data calls =
[IP2B1DRS + IP2B2DRS + IP2B3DRS] FOR ALL ANCHOR ROUTES

[IP2B1DAT] FOR ALL ANCHOR ROUTES
Number of page cancellations for Packet Data calls =

[IP2B1DRL + IP2B2DRL + IP2B3DRL] FOR ALL ANCHOR ROUTES
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Success rate for SMS calls is expressed by the following ratio: (Number of intersystem page successes for SMS calls / (Number of intersystem page attempts for SMS calls - Number of page cancellations for SMS calls)) x 100 Number of intersystem page successes for SMS calls =
[IP2B1SRS + IP2B2SRS] FOR ALL ANCHOR ROUTES

[IP2B1SAT] FOR ALL ANCHOR ROUTES
Number of page cancellations for SMS calls =

[IP2B1SRL + IP2B2SRL] FOR ALL ANCHOR ROUTES
Intersystem paging performance of an anchor route Percentage of overall successful paging rate is expressed by the following ratio: (Number of intersystem page successes for all calls / (Number of intersystem page attempts for all calls - Number of page cancellations for all calls)) x 100 Number of intersystem page successes for all calls =
IP2B1VRS + IP2B1DRS + IP2B1SRS + IP2B2VRS + IP2B2DRS + IP2B2SRS + IP2B3VRS + IP2B3DRS

IP2B1VAT + IP2B1DAT + IP2B1SAT
Number of page cancellations for all calls =

IP2B1VRL + IP2B1DRL + IP2B1SRL + IP2B2VRL + IP2B2DRL + IP2B2SRL + IP2B3VRL + IP2B3DRL
Success rate for Voice calls is expressed by the following ratio: (Number of intersystem page successes for Voice calls / (Number of intersystem page attempts for Voice calls - Number of page cancellations for Voice calls)) x 100 Number of intersystem page successes for Voice calls =
IP2B1VRS + IP2B2VRS + IP2B3VRS

IP2B1VAT
Number of page cancellations for Voice calls =

IP2B1VRL + IP2B2VRL + IP2B3VRL
CDMA
NBSS15.0
Success rate for Packet Data calls is expressed by the following ratio: (Number of intersystem page successes for Packet Data calls / (Number of intersystem page attempts for Packet Data calls - Number of page cancellations for Packet Data calls)) x 100 Number of intersystem page successes for Packet Data calls =
IP2B1DRS + IP2B2DRS + IP2B3DRS

IP2B1DAT
Number of page cancellations for Packet Data calls =

IP2B1DRL + IP2B2DRL + IP2B3DRL
Success rate for SMS calls is expressed by the following ratio: (Number of intersystem page successes for SMS calls / (Number of intersystem page attempts for SMS calls - Number of page cancellations for SMS calls)) x 100 Number of intersystem page successes for SMS calls =
IP2B1SRS + IP2B2SRS

IP2B1SAT
Number of page cancellations for SMS calls =

IP2B1SRL + IP2B2SRL
CDMA BCP zone performance metrics
11
This section provides CDMA zone performance metrics for BCP zones only. These metrics are associated with page attempts in the Border system that are configured to use the zone paging method in BCP zones. Note: When intersystem page attempts are configured to use the zone paging method in the Border system and IZP zones are selected instead of BCP zones, these metrics do not apply. This is because the CDMAPGZN OMs and SMSZONPG OMs do not get pegged in the Border system for intersystem page attempts when IZP zones are used. Zone performance for voice, CSD, and packet data calls These metrics are useful to determine the overall BCP zone performance as well as the per page attempt performance for Voice and Packet Data call types combined, regardless of zone, zone+zonelist or system-wide page option. This helps determine the effectiveness of the zone configuration and is useful for optimizing overall zone configuration within the Border system. Maximizing zone performance may improve the capacity of paging and access channels.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
These metrics may be useful for optimizing zone paging related configurable parameters such as the zone page option etc., that are configured in the Table CDMAPGZN. The metrics mentioned in this section use OMs from the CDMAPGZN and CDMAPGZX OM groups. The following terms are used in these metrics. Number of first page responses =
PGZNRES + (PGZNRESX * 65536) + PGZNLPIR + (PGZNLPIX * 65536) + PGZNLPOR + (PGZNLPOX * 65536) + PGZNSYIR + (PGZNSYIX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)

PGZNRES + (PGZNRESX * 65536) + PGZNLPIR + (PGZNLPIX * 65536) + PGZNSYIR + (PGZNSYIX * 65536)

PGZNLPOR + (PGZNLPOX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)

RPGZNRES + (RPGZNREX * 65536) + RPGLPIR + (RPGLPIRX * 65536) + RPGLPOR + (RPGLPORX * 65536) + RPSYSRSI + (RPSYSRIX * 65536) + RPSYSRSO + (RPSYSROX * 65536)

RPGZNRES + (RPGZNREX * 65536) + RPGLPIR + (RPGLPIRX * 65536) + RPSYSRSI + (RPSYSRIX * 65536)

RPGLPOR + (RPGLPORX * 65536) + RPSYSRSO + (RPSYSROX * 65536)

PG3ZNRES + (PG3ZNREX * 65536) + PG3LPIR + (PG3LPIRX * 65536) + PG3LPOR + (PG3LPORX * 65536) + PG3SYSRI + (PG3SYRIX * 65536) +
CDMA
NBSS15.0
11-8 Border paging performance Nortel Networks PG3SYSRO + (PG3SYROX * 65536)
Number of in-zone third page responses =

PG3ZNRES + (PG3ZNREX * 65536) + PG3LPIR + (PG3LPIRX * 65536) + PG3SYSRI + (PG3SYRIX * 65536)
Number of out-of-zone third page responses =

PG3LPOR + (PG3LPORX * 65536) + PG3SYSRO + (PG3SYROX * 65536)

PGZNREQ + (PGZNREQX * 65536) + PGZNLPAT + (PGZNLPAX * 65536) + PGZNSYRQ + (PGZNSYRX * 65536)

RPGZNREQ + (RPGZNRQX * 65536) + RPGLPAT + (RPGLPATX * 65536) + RPSYSRQ + (RPSYSRQX * 65536)

PG3ZNREQ + (PG3ZNREX * 65536) + PG3LPAT + (PG3LPATX * 65536) + PG3SYSRQ + (PG3SYRQX * 65536)



PG3ZNAB + (PG3ZNABX * 65536)
Overall zone performance Percentage of overall successful paging rate for a zone is expressed by the following ratio: ((Number of first page responses + Number of second page responses + Number of third page responses) / (Number of first page requests + Number of second page requests + Number of third page requests Number of originator terminations for the first page - Number of originator terminations for the second page - Number of originator terminations for the third page)) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Zone performance of first page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of first page responses) / (Number of first page requests Number of originator terminations for the first page)) x 100 IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone first page responses) / (Number of first page requests - Number of originator terminations for the first page)) x 100 OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone first page responses) / (Number of first page requests - Number of originator terminations for the first page)) x 100 Zone performance of second page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of second page responses) / (Number of second page requests Number of originator terminations for the second page)) x 100 IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone second page responses) / (Number of second page requests - Number of originator terminations for the second page)) x 100 OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone second page responses) / (Number of second page requests - Number of originator terminations for the second page)) x 100 Zone performance of third page attempts Percentage of successful paging rate for a zone is expressed by the following ratio: ((Number of third page responses) / (Number of third page requests Number of originator terminations for the third page)) x 100
CDMA
NBSS15.0
IN-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of in-zone third page responses) / (Number of third page requests - Number of originator terminations for the third page)) x 100 OUT-OF-ZONE page response success rate for a zone is expressed by the following ratio: ((Number of out-of-zone third page responses) / (Number of third page requests - Number of originator terminations for the third page)) x 100 Zone performance for SMS calls This will help determine the effectiveness of the zone definition. If a certain percentage of total success is not achieved then zone tuning should be performed. The metrics in this section are same as the metrics listed in Paging performance (page 10-1) with the exception that the OMs used in these metrics be taken from under the BCP zone type from SMSZONPG and SMSZONPX OM groups. Success rate of SMS delivery in the border system This metric gives the success rate of SMS delivery at the Border system over all Anchor routes and also on a per-Anchor system (per route) basis. Percentage of successful SMS delivery at the Border system for all Anchor routes is: (Number of intersystem SMSs successfully delivered) / (Number of intersystem SMSs attempted) x 100 Number of intersystem SMSs successfully delivered =
[SMSBDDSC] FOR ALL ANCHOR ROUTES
Number of intersystem SMSs attempted =

[SMSBDDAT] FOR ALL ANCHOR ROUTES
Validation
CDMA border cell paging performance OM validations Attempts = Successes + Timeouts + Page Cancellations (i.e. Releases)
11 11
Note: The validation formulas mentioned below for Voice calls and Packet Data calls may not hold true when the Border system sends a page attempt but decides by itself to cancel the page attempt (as opposed to page cancelled due to incoming RELEASE Invoke message). Such scenarios are expected to be very few and very rare.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
For Voice calls,

IP2B1VAT = IP2B1VRS + IP2B1VTO + IP2B1VRL IP2B2VAT = IP2B2VRS + IP2B2VTO + IP2B2VRL IP2B3VAT = IP2B3VRS + IP2B3VTO + IP2B3VRL
For Packet Data calls,

IP2B1DAT = IP2B1DRS + IP2B1DTO + IP2B1DRL IP2B2DAT = IP2B2DRS + IP2B2DTO + IP2B2DRL IP2B3DAT = IP2B3DRS + IP2B3DTO + IP2B3DRL
For SMS calls,

IP2B1SAT = IP2B1SRS + IP2B1STO + IP2B1SRL + IP2B1SFL IP2B2SAT = IP2B2SRS + IP2B2STO + IP2B2SRL + IP2B2SFL
CDMA zone performance OM validations (for a single BCP zone) For voice, CSD, and packet data calls For Voice, CSD and Packet Data calls, use OMs from CDMAPGZN and CDMAPGZX OM groups in the validation formulas described here. Attempts = Successes + Timeouts + Abandons For First Page,
PGZNREQ + (PGZNREQX * 65536) + PGZNLPAT + (PGZNLPAX * 65536) + PGZNSYRQ + (PGZNSYRX * 65536) = {PGZNRES + (PGZNRESX * 65536) + PGZNLPIR + (PGZNLPIX * 65536) + PGZNLPOR + (PGZNLPOX * 65536) + PGZNSYIR + (PGZNSYIX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)} + {PGZNTO + (PGZNTOX * 65536)} + {PGZNAB + (PGZNABX * 65536)}
For Second Page,

RPGZNREQ + (RPGZNRQX * 65536) + RPGLPAT + (RPGLPATX * 65536) + RPSYSRQ + (RPSYSRQX * 65536) = {RPGZNRES + (RPGZNREX * 65536) + RPGLPIR + (RPGLPIRX * 65536) + RPGLPOR + (RPGLPORX * 65536) + RPSYSRSI + (RPSYSRIX * 65536) + RPGSYSRO + (RPSYSROX * 65536)} + {REPGTO + (REPGTOX * 65536)} + {RPGZNAB + (RPGZNABX * 65536)}
For Third Page,

PG3ZNREQ + (PG3ZNRQX * 65536) + PG3LPAT + (PG3LPATX * 65536) + PG3SYSRQ + (PG3SYRQX * 65536) = {PG3ZNRES + (PG3ZNREX * 65536) + PG3LPIR + (PG3LPIRX * 65536) + PG3LPOR + (PG3LPORX * 65536) + PG3SYSRI + (PG3SYRIX * 65536) + PG3SYSRO + (PG3SYROX * 65536)} + {PG3ZNTO + (PG3ZNTX * 65536)} + {PG3ZNAB + (PG3ZNABX * 65536)}
CDMA
NBSS15.0
Note: Depending on the zone page or repage option configured in the system, some OMs in the above formulas may not get pegged (i.e. show zero value). For SMS For SMS, use OMs from SMSZONPG and SMSZONPX OM groups in the validation formula described here. Attempts = Successes + Non-Successes For First Page,
PGZNREQ + (PGZNREQX * 65536) + PGZNSYRQ + (PGZNSYRX * 65536) = {PGZNRES + (PGZNRESX * 65536) + PGZNSYIR + (PGZNSYIX * 65536) + PGZNSYOR + (PGZNSYOX * 65536)} + {PGZNTO + (PGZNTOX * 65536)} + {PGZNAB + (PGZNABX * 65536)}
For Second Page,

RPGZNREQ + (RPGZNRQX * 65536) + RPSYSRQ + (RPSYSRQX * 65536) = {RPGZNRES + (RPGZNREX * 65536) + RPSYSRSI + (RPSYSRIX * 65536) + RPGSYSRO + (RPSYSROX * 65536)} + {REPGTO + (REPGTOX * 65536)} + {RPGZNAB + (RPGZNABX * 65536)}
SMS Delivery Attempts = Successes + Non-Successes

SMSBDDAT = SMSBDDSC + SMSBDDFL
Recommendations
CDMA paging If the overall intersystem paging performance is low, then the INCOMING_ISPAGE2_PAGING parameter in Table PAGECTRL in the Border system can be re-configured to improve paging performance. In addition, outgoing ISPAGE2 message parameters in Table PAGECTRL at the Anchor system may also be re-configured to improve the paging performance in the Border system.
11 11
If the intersystem paging performance for a specific Anchor route is low, then optimization of adjacent route configuration for Anchor/Border pairs may be required. Also, if the BCP zone paging performance is low, then BCP zone optimization may be required.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Data burst message delivery performance
12
This chapter describes metrics to measure the performance of DBM (data burst message) delivery. The DBMs covered in this chapter include Short Message Service (SMS) and Reverse Short Data Burst (R-SDB). DBM delivery performance reflects the efficiency of SMS and R-SDB Delivery and Origination capability of the system. Note that only mobile-initiated R-SDB is supported in the system. The chapter also presents the SMS and R-SDB message size OMs which capture the different sizes of the SMS or R-SDB messages that were sent on the common and traffic channels. These OMs can be used to assess the impact of DBM delivery on the common and traffic channels. There are three different types of SMS delivery: 1. When the mobile is idle, SMS may be sent on the paging channel (SMS Termination), or the mobile may send an SMS message on the access channel (SMS Origination). 2. When the mobile is idle, but is instructed to go onto a traffic channel to receive the SMS Termination or to send the SMS Origination. 3. When the mobile is in an active call. For more information about item #1 and item #2, see Idle mode SMS (page 12-4). For more information about item #3, see In call SMS (page 129). There are two types of R-SDB delivery: 1. When the mobile is idle, the R-SDB may be sent by the mobile on the reverse enhanced access channel (R-EACH). 2. When the mobile is in an active voice call, the R-SDB is sent on the reverse traffic channel.
CDMA
NBSS15.0
12-2 Data burst message delivery performance Nortel Networks
Note: For a mobile to send an R-SDB, it must have a dormant packet data session at the PCU.
List of OMs
12
MSC OMs CAUDATSC OM group SMOATITC SMOCSSTC SMOSUITC SMSPRRES SMSTMCFL SMOATBTC SMSDVCFL SMOATTAC SMOFAIAC SMSORATS SMSTATPG SMSTRCFL SMOFABTC SMSDVCSC SMOCSFTC SMOFAITC SMSORSUC SMSTFLPG SMSTSCPG SMOSUBTC SMSORCFL SMOCSRAC SMOSUCAC SMSPGRES SMSTFLTC SMSTSCTC SMSDVCAT
CAUDATS2 OM group SMSTATTC
CAUDATSY OM group SMODBRTO SMSPGTO SMSPGREQ SMOCMREQ SMSPGRTO SMOCMRES SMSPGRTY SMOCMRTO
DDSLFRBC OM group BAMF25 BAMF125 BAMF225 BAMR75 BAMF50 BAMF150 BAMF255 BAMR100 BAMF75 BAMF175 BAMR25 BAMR125
sheet 1 of 2
BAMF100 BAMF200 BAMR50 BAMR150
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC OMs BAMR175 BAMR200
Data burst message delivery performance 12-3 Copyright 2008 Nortel Networks
BAMR225
BAMR255
DDSLFRBX OM group This OM group has extension registers for each OM in the DDSLFRBC OM group.
DDSLFRCC OM group DDSF25 DDSF125 DDSF225 DDSR75 DDSR175 DDSA25 DDSP25 DDSP125 DDSF50 DDSF150 DDSF255 DDSR100 DDSR200 DDSA50 DDSP50 DDSF75 DDSF175 DDSR25 DDSR125 DDSR225 DDSA75 DDSP75 DDSF100 DDSF200 DDSR50 DDSR150 DDSR255 DDSA100 DDSP100
DDSLFRCX OM group This OM group has extension registers for each OM in the DDSLFRCC OM group.
sheet 2 of 2
CDMA
NBSS15.0
BSC OMs
Short Data Burst OM group EACH_RSDB_Histogr am_1 EACH_RSDB_Histogr am_5 EACH_RSDB_Histogr am_9 RFCH_RSDB_Histogr am_3 RFCH_RSDB_Histogr am_7 TotalRSDB_Forwarde d EACH_RSDB_Histogr am_2 EACH_RSDB_Histogr am_6 EACH_RSDB_Histogr am_10 RFCH_RSDB_Histogr am_4 RFCH_RSDB_Histogr am_8 TotalRSDB_Dropped EACH_RSDB_Histogr am_3 EACH_RSDB_Histogr am_7 RFCH_RSDB_Histogr am_1 RFCH_RSDB_Histogr am_5 RFCH_RSDB_Histogr am_9 EACH_RSDB_Histogr am_4 EACH_RSDB_Histogr am_8 RFCH_RSDB_Histogr am_2 RFCH_RSDB_Histogr am_6 RFCH_RSDB_Histogr am_10
PCU Manager OM group PCUM_TotalRSDB_R eceived PCUM_TotalRSDB_F orwarded PCUM_TotalRSDB_Dr opped
BTS OMs
Advanced Sector MO OM group REACHShortDataBurs tReceived REACHMessagesRec eived
Idle mode SMS
12
When the mobile is in the idle mode, it can originate an SMS call or an SMS delivery (termination) could be initiated to the mobile. The SMS delivery to the mobile can be made on the Paging or the Forward Traffic channel, depending on the size of the message. Similarly, a mobile can send the SMS message over the Access channel or the Reverse Traffic channel. To use the reverse traffic channel, the mobile originates an SMS call by using service option 6.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
If the message has to be delivered to or received from the mobile on the traffic channel, then the usual procedure for ordering the mobile to a traffic channel is performed. However, instead of pegging the normal call setup registers special SMS registers are pegged on the CAU. Goal Attempts to page a CDMA mobile for SMS should result in a page response v% of the time. Attempts to send SMS data on the paging channel should be successful w% of the time. Attempts to send SMS data on the forward traffic channel when the mobile is not in a call should be successful x% of the time. Attempts by the mobile to send the SMS data on the Access Channel should be successful y% of the time. Attempts by the mobile to send SMS data on the reverse traffic channel when the mobile is not in a call should be successful z% of the time.
Formula Overall SMS page request failuressystem level SMSPGRTO for all CAUs / SMSPGREQ for all CAUs x 100 In the case of a multiple-BSC configuration, due to the SMS location page is sent out on all the BSCs but a response, if received, will be received from only one of the BSCs, above formula need to be adjusted as follows: Replace SMSPGREQ by (SMSPGREQ / number of BSCs). This will adjust pegging of SMS page attempts happened in all BSCs (CAUs) to one SMS page attempt from the MSC perspective. Replace SMSPGRTO by (SMSPGRTO - (SMSPGRTY / number of BSCs)). This will adjust pegging of SMS page retry timeouts happened in all BSCs (CAUs) to one SMS page retry timeout from the MSC perspective.
In the case of a multiple-BSC configuration, when SMS retry is DISABLED in the system, Replace SMSPGRTO by SMSPGTO OM followed by replacing SMSPGTO by (SMSPGTO - (SMSPGREQ / number of BSCs)). This will adjust pegging of SMS page timeouts happened in all BSCs (CAUs) to one SMS page timeout from the MSC perspective.
Due to a race condition when a mobile is being paged for the SMS and call originated by that mobile, the MSC does not send second SMS page to the mobile after timing out on the first SMS page. This is not an overall SMS page failure as second page is never attempted (when SMS page retry is
ENABLED), but rather considered as voluntary SMS page retry abandon due to the mobile is already in a call. Voluntary SMS page retry abandon can be determined as: (SMSPGTO - SMSPGRTY) for all CAUs In case of a multiple-BSC configuration, replace (SMSPGTO by SMSPGTO - (SMSPGREQ / number of BSCs)) and replace SMSPGRTY by (SMSPGRTY / number of BSCs). Voluntary page retry abandon is not captured in Overall SMS page failures rate or Overall SMS page success rate. SMS page request failures for first page: system level SMSPGTO for all CAUs / SMSPGREQ for all CAUs x 100 In the case of a multiple-BSC configuration, above formula need to be adjusted as follows: Replace SMSPGREQ by SMSPGREQ / number of BSCs. Replace SMSPGTO by (SMSPGTO - SMSPGREQ / number of BSCs) SMS page request failures for page retry: system level SMSPGRTO for all CAUs/ SMSPGRTY for all CAUs x 100 In the case of a multiple-BSC configuration, above formula need to be adjusted as follows: Replace SMSPGRTY by SMSPGRTY / number of BSCs. This will adjust pegging of SMS page retry attempts happened in all BSCs (CAUs) to one SMS page retry attempt from the MSC perspective. Replace SMSPGRTO by (SMSPGRTO - (SMSPGRTY / number of BSCs). Idle mobiletotal SMS termination failures (SMSTFLPG + SMSTMCFL + SMSTRCFL + SMSTFLTC) for all CDMA sectors / (SMSPGRES + SMSPRRES) for all CDMA sectors x 100 The reason SMSPGRTO is not considered in the failures because if both page time out then the SMS termination is not attempted.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Idle mobiledetailed SMS termination failures SMS delivery to an idle mobile can be made on the paging channel or the mobile can be ordered to the traffic channel. The failure scenarios are as below: Mobile does not respond to the page (Not really a SMS delivery failure). For more information, see Overall SMS page request failuressystem level (page -5). Mobile does not acknowledge SMS delivery made on paging channel. Radio link could not be established with the mobile. Mobile does not acknowledge SMS delivery made on forward traffic channel.
Idle mobile - SMS termination paging channel delivery failures: SMSTFLPG for all CDMA sectors / SMSTATPG for all CDMA sectors x 100 Idle mobile - SMS termination radio link setup failures: SMSTMCFL for all CDMA sectors / SMSORATS for all CDMA sectors x 100 Idle mobile - SMS termination traffic channel delivery failures: SMSTFLTC for all CDMA sectors / SMSTATTC for all CDMA sectors x 100 Idle mobiletotal SMS origination failures (SMOFAIAC + SMOCSFTC + SMSORCFL + SMOFAITC) for all CDMA sectors + SMODBRTO for all CAUs / (SMOATTAC + SMOCSRAC) for all CDMA sectors x 100 Idle mobiledetailed SMS origination failures SMS origination from an idle mobile can be made on the access channel or the mobile can request for a traffic channel. The failure scenarios are as below: CAU is not able to decode the Data Burst Message received over access channel CAU is unsuccessful in delivering the message received over the access channel to the SMS Center via CM. A traffic channel (call) could not be established.
CDMA
NBSS15.0
CAU did not receive a Data Burst Message over the traffic channel set up for the SMS delivery and times out. CAU is not able to decode the Data Burst Message received over the traffic channel set up for the SMS delivery. CAU is unsucessful in delivering the message received over the traffic channel set up for the SMS delivery to the SMS center via the CM.
Idle mobile - SMS origination access channel delivery failures: SMOFAIAC for all CDMA sectors / SMOATTAC for all CDMA sectors x 100 Idle mobile - SMS origination radio link setup failures: SMOCSFTC for all CDMA sectors / SMOCSRAC for all CDMA sectors x 100 Idle mobile - SMS origination traffic channel delivery failures: SMOFAITC for all CDMA sectors / SMOATITC for all CDMA sectors x 100 Idle mobile - SMS origination traffic channel SMS timeouts: SMODBRTO for all CAUs / SMOCSSTC for all CDMA sectors x 100 Additional formula Idle mobile - SMS traffic channel failures due to lack of BSC resources: ( SMSORCFL + SMSTRCFL for all CDMA sectors / SMSORATS + SMOCSRAC for all CDMA sectors) x 100 Validation Attempts = Successes + Non-successes Idle Mobile SMS location attempts SMSPGREQ = SMSPGRES + SMSPGTO SMSPGRTY= SMSPRRES + SMSPGRTO Idle Mobile SMS termination traffic channel setup attempts SMSORATS = SMSORSUC + SMSTMCFL + SMSTRCFL
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Idle Mobile SMS termination traffic channel delivery attempts SMSTATTC = SMSTSCTC + SMSTFLTC Idle Mobile SMS access channel attempts SMOATTAC = SMOSUCAC + SMOFAIAC Idle Mobile SMS origination traffic channel setup attempts SMOCSRAC = SMOCSSTC + SMOCSFTC + SMSORCFL Idle Mobile SMS origination traffic channel delivery attempts SMOATITC = SMOSUITC + SMOFAITC Idle Mobile Total SMS termination delivery attempts Overall Attempts = Attempts over PC + Attempts over TC (SMSPGRES + SMSPRRES) = SMSTATPG + SMSORATS Idle Mobile SMS origination setup successfully over traffic channel Call setup successes = Msg Delivery Successes + Msg Delivery Timeouts SMOCSSTC = SMOATITC + SMODBRTO
In call SMS
12
If the mobile is in a call the CAU sends the SMS data over the forward traffic channel. If the mobile is in the process of setting up a call, the CAU waits till it receives the CATSOM_SOMServiceConnectRsp message and then sends the SMS data over the forward traffic channel. Similarly, if the mobile is in a call then the mobile can send SMS data over the traffic channel
Goal Attempts to send SMS data to the mobile on the forward traffic channel when the mobile is in a call should be successful x% of the time. Attempts by the mobile to send SMS data on the forward traffic channel when the mobile is in call should be successful y% of the time.
Formula In call - total SMS termination failures SMSDVCFL for all CDMA sectors / SMSDVCAT for all CDMA sectors x 100
In call - total SMS origination failures SMOFABTC for all CDMA sectors / SMOATBTC for all CDMA sectors x 100 Validation In Call - SMS origination attempts Attempts = Successes + Non-successes SMOATBTC = SMOSUBTC + SMOFABTC
CAU-CM SMS origination delivery
12
In case of mobile originated SMS, the CM has to pass the SMS data from the CAU on to the SMS Center and the response from the SMS Center on to the CAU. Goal Attempts to send SMS data to the SMS Center via the CM should be successful x% of the time.
Formula CAU-CM SMS origination delivery failures SMOCMRTO for all CAUs / SMOCMREQ for all CAUs x 100 Validation In Call - SMS origination attempts Attempts = Successes + Non-successes SMOCMREQ = SMOCMRES + SMOCMRTO
Message length histogram metrics
12
The distribution of Data Delivery Services (DDS) message sizes over common and traffic channels may be helpful in assessing the capacity impacts of these services on those channels and for channel overload detection and prevention. The message length histogram can be used to assess the impact of parameter changes (e.g. MAX_CAP_SZ) on the distribution of SMS between access & reverse traffic channel. DDS services include SMS, EMS, OTAPA, OTASP and LCS services. EMS, OTAPA, OTASP and LCS services are supported only on the traffic channel. Formula The following formula will be used throughout this section.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
* in all the formulas below refers to the different message sizes. Refer the corresponding OM groups for the message sizes pegged for each channel. DDSLFRCX and DDSLFRBX OM groups contain the extension registers for all the OMs in DDSLFRBC and DDSLFRCC OM groups. The total count for a given message size should be calculated as follows: For message size 26-50 bytes sent on the forward FCCCH channel: BAMF50 + (BAMF50X x 65536) Total traffic on Paging channel = (DDSP* + (DDSP*X x 65536)) over all message sizes Total traffic on FCCCH channel = (BAMF* + (BAMF*X x 65536)) over all message sizes Total traffic on Forward traffic channel = (DDSF* + (DDSF*X x 65536)) over all message sizes Total traffic on Access channel = (DDSA* + (DDSA*X x 65536)) over all message sizes Total traffic on REACH channel = (BAMR* + (BAMR*X x 65536)) over all message sizes Total traffic on Reverse traffic channel = (DDSR* + (DDSR*X x 65536)) over all message sizes Total traffic in forward direction = Total traffic on Paging channel + Total traffic on FCCCH channel + Total traffic on Forward traffic channel Total traffic in reverse direction = Total traffic on Access channel + Total traffic on REACH channel + Total traffic on Reverse traffic channel Distribution of DDS messages across channels This metric provides the distribution of DDS messages across channels. Paging channel Total traffic on Paging channel / Total traffic in forward direction x 100 FCCCH channel Total traffic on FCCCH channel / Total traffic in forward direction x 100
CDMA
NBSS15.0
Forward traffic channel Total traffic on Forward traffic channel / Total traffic in forward direction x 100 Access channel Total traffic on Access channel / Total traffic in reverse direction x 100 R-EACH channel Total traffic on REACH channel / Total traffic in reverse direction x 100 Reverse traffic channel Total traffic on Reverse traffic channel / Total traffic in reverse direction x 100 Distribution of DDS messages according to size on a per channel basis This metric provides the per message size distribution to the total messages delivered on a per channel basis. Paging channel DDSP* + (DDSP*X x 65536) for a particular message size on the paging channel / Total traffic on Paging channel x 100 For example: Percentage of messages of size 26 to 50 bytes on the paging channel = (DDSP50 + (DDSSP50X * 65536)) / Total traffic on Paging channel x 100 FCCCH channel BAMF* + (BAMF*X x 65536) for a particular message size on the FCCCH channel / Total traffic on FCCCH channel x 100 Forward traffic channel DDSF* + (DDSF*X x 65536) for a particular message size on the forward traffic channel / Total traffic on Forward traffic channel x 100 Access channel DDSA* + (DDSA*X x 65536) for a particular message size on the access channel / Total traffic on Access channel x 100 R-EACH channel BAMR* + (BAMR*X x 65536) for a particular message size on the REACH channel / Total traffic on REACH channel x 100 Reverse traffic channel DDSR* + (DDSR*X x 65536) for a particular message size on the reverse traffic channel / Total traffic on Reverse traffic channel x 100 Example: Distribution of DDS messages according to size on a per Channel basis
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Distribution of DDS messages according to size on Paging Channel

12% 7%
0-25 Bytes
25% 20%
26-50 Bytes 51-75 Bytes 76-100 Bytes 101-125 Bytes
36%
Note: The numbers stated in this example are for illustration purposes only. Upper bound of the average message length on per channel basis This metric can be used to compute the upper bound on the average message length on a per channel basis. For paging channel the upper bound on the average message length is: {((DDSP25 + DDSP25X x 65536) x 25) + ((DDSP50 + DDSP50X x 65536) x 50) + ((DDSP75 + DDSP75X x 65536) x 75) ((DDSP100 + DDSP100X x 65536) x 100) ((DDSP125 + DDSP125X x 65536) x 125)} / Total traffic on Paging channel x 100 Similarly the upper bound of average length can be calculated for all other common and traffic channels by using the corresponding OMs for that channel.
Mobile-initiated R-SDB
12
When the mobile is in the idle mode, it can originate an R-SDB. The R-SDB initiated by the mobile is sent on the R-EACH (Reverse Enhanced Access Channel). If the mobile is in an active voice call, then it sends the R-SDB over the R-FCH (Reverse Fundamental Channel). Note: The metrics in this section apply to eBSC only. R-SDB size histogram metrics The R-SDB size histogram OMs show the characteristics of the distribution of the R-SDB sizes received on the R-EACH/R-FCH, during every OM interval, at the PCU (PCUFP). By combining the OM data from a large number of OM intervals, the customer can create an accurate statistical model
of the distribution of the R-SDB sizes received on the R-EACH/R-FCH. This distribution model is vital in doing capacity simulations of R-EACH/R-FCH. Lower bound of the average size of the R-EACH R-SDB received by the PCUs (PCUFPs) {(EACH_RSDB_Histogram_1 x 1) + (EACH_RSDB_Histogram_2 x 26) + (EACH_RSDB_Histogram_3 x 51) + (EACH_RSDB_Histogram_4 x 76) + (EACH_RSDB_Histogram_5 x 101) + (EACH_RSDB_Histogram_6 x126) + (EACH_RSDB_Histogram_7 x 151) + (EACH_RSDB_Histogram_8 x 176) + (EACH_RSDB_Histogram_9 x 201) + (EACH_RSDB_Histogram_10 x 226)}over all PCUs / Total R-EACH R-SDBs received by the PCUs (PCUFPs). Where, Total R-EACH R-SDBs received by the PCUs (PCUFPs) = { EACH_RSDB_Histogram_1 + EACH_RSDB_Histogram_2 + ... + EACH_RSDB_Histogram_10} over all PCUs. Upper bound of the average size of the R-EACH R-SDB received by the PCUs (PCUFPs) {(EACH_RSDB_Histogram_1 x 25) + (EACH_RSDB_Histogram_2 x 50) +(EACH_RSDB_Histogram_3 x 75) + (EACH_RSDB_Histogram_4 x 100) + (EACH_RSDB_Histogram_5 x 125) + (EACH_RSDB_Histogram_6 x 150) + (EACH_RSDB_Histogram_7 x 175) + (EACH_RSDB_Histogram_8 x 200) + (EACH_RSDB_Histogram_9 x 225) + (EACH_RSDB_Histogram_10 x 255)}over all PCUs / Total R-EACH R-SDBs received by the PCUs (PCUFPs). Lower bound of the average size of the R-FCH R-SDB received by the PCUs (PCUFPs) {(RFCH_RSDB_Histogram_1 x 1) + (RFCH_RSDB_Histogram_2 x 26) + (RFCH_RSDB_Histogram_3 x 51) + (RFCH_RSDB_Histogram_4 x 76) + (RFCH_RSDB_Histogram_5 x 101) + (RFCH_RSDB_Histogram_6 x 126) + (RFCH_RSDB_Histogram_7 x 151) + (RFCH_RSDB_Histogram_8 x 176) + (RFCH_RSDB_Histogram_9 x 201) + (RFCH_RSDB_Histogram_10 x 226)}over all PCUs / Total R-FCH RSDBs received by the PCUs (PCUFPs). Where, Total R-FCH R-SDBs received by the PCUs (PCUFPs) = {RFCH_RSDB_Histogram_1 + RFCH_RSDB_Histogram_2 + ... + RFCH_RSDB_Histogram_10} over all PCUs
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Upper bound of the average size of the R-FCH R-SDB received by the PCUs (PCUFPs) {(RFCH_RSDB_Histogram_1 x 25) + (RFCH_RSDB_Histogram_2 x 50) +(RFCH_RSDB_Histogram_3 x 75) + (RFCH_RSDB_Histogram_4 x 100) +(RFCH_RSDB_Histogram_5 x 125) + (RFCH_RSDB_Histogram_6 x 150) + (RFCH_RSDB_Histogram_7 x 175) + (RFCH_RSDB_Histogram_8 x 200) + (RFCH_RSDB_Histogram_9 x 225) + (RFCH_RSDB_Histogram_10 x 246)}over all PCUs / Total R-FCH RSDBs received by the PCUs (PCUFPs). Mobile-initiated SDB delivery success rate at the PCU-M The failures that can occur at the PCU-M before the PCU-M sends the RSDB to the PCU are: 1. PCU (PCUFP) in overload condition. 2. PCU-M could not find the packet data session. 3. PCU in 'Pcu_CallpUnavailable' or 'Pcu_Locked' status. Percentage of Mobile-initiated R-SDBs sent via R-EACH and R-FCH, that were delivered by the PCU-M to the PCU (PCUFP) = {PCUM_TotalRSDB_Forwarded / PCUM_TotalRSDB_Received} x 100 Percentage of Mobile-initiated R-SDBs sent via R-EACH and R-FCH, that were not delivered by the PCU-M to the PCU (PCUFP) = {PCUM_TotalRSDB_Dropped / PCUM_TotalRSDB_Received}x 100 Mobile-initiated SDB delivery success rate at the PCU The failures that can occur at the PCU before the PCU sends the R-SDB to the PDSN are: 1. IMSI lookup failure. 2. RP session does not exist or other incorrect states for sending R-SDB, which can happen in race conditions of call state change. 3. CPDS PCU in overload while the overload notification not processed by PCUM. Percentage of Mobile-initiated R-SDBs sent via R-EACH and R-FCH, that were delivered by the PCU (PCUFP) to the PDSN =
CDMA
NBSS15.0
{TotalRSDB_Forwarded / ((EACH_RSDB_Histogram_1 + ... + EACH_RSDB_Histogram_10) + (RFCH_RSDB_Histogram_1 + ... + RFCH_RSDB_Histogram_10))} x 100 Percentage of Mobile-initiated R-SDBs sent via R-EACH and R-FCH, that were not delivered by the PCU (PCUFP) to the PDSN = {TotalRSDB_Dropped / ((EACH_RSDB_Histogram_1 + ... + EACH_RSDB_Histogram_10) + (RFCH_RSDB_Histogram_1 + ... + RFCH_RSDB_Histogram_10))} x 100 Percentage of R-SDBs received on the R-EACH Percentage of all messages sent over the R-EACH that were R-SDBs = {REACHShortDataBurstReceived}over all carrier-sectors / {Sum of REACHMessagesReceived [i] over the i values (i = 3 to 14)}over all carrier sectors x 100 Percentage of DBMs sent over the R-EACH that were R-SDBs = {REACHShortDataBurstReceived}over all carrier-sectors / {REACHMessagesReceived [8]: DBMReceived} over all carrier sectors x 100 Validation PCUM_TotalRSDB_Received = PCUM_TotalRSDB_Forwarded + PCUM_TotalRSDB_Dropped (EACH_RSDB_Histogram_1 + ... + EACH_RSDB_Histogram_10) + (RFCH_RSDB_Histogram_1 + ... + RFCH_RSDB_Histogram_10) = TotalRSDB_Forwarded + TotalRSDB_Dropped
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Location services performance

Location Services (LCS) performance chapter provides information for incoming location services requests, required calls setup and related networking messages.
13
There are three different scenarios when a location service is performed: An idle mobiles coarse position information. In this case, page request is sent to the mobile. Page retry is sent if required. An idle Mobiles precise position information which requires call setup using Service Option 35. In this case, page request is sent to the mobile. Page retry is sent if required. A Mobiles coarse or precise position information when the mobile is already in a Voice, Active Packet Data or QNC (Quick Net Connect) Circuit Switch Data call.
Goal
Less than x% of all LCS calls attempted failed. Less than y% of all LCS calls attempted failed due to BSC resource shortages.
13
List of OMs
13
Table 13-1 Location services performance OMs MSC OMs LCSSYS OM group LCPG4CUR IMIPRQRR LCFWDDB LCQACTMB LCSSESS LCFWDDBX MV2TCHAT E911SESS LCREVDB MV2TCHSU PRECRQST LCREVDBX
CDMA
NBSS15.0
13-2 Location services performance Nortel Networks Table 13-1 Location services performance OMs MSC OMs LCOREQIV SMDPSOGX SMDPOSIC SMDPSICX
SMDPOSOG
NWKIC3 OM group LPRQIVIC IPRFRRIC IPRQIVIC OREQRRIC IPRQRRIC IPRFIVIC
NWKOG3 OM group LPRQRROG IPRFRROG IPRQIVOG OREQIVOG IPRQRROG IPRFIVOG
CDMAVSO OM group ATLCS SULCS HCLCS FLLCS
LCS paging performance When a mobile is in an idle mode, a SMS page request or page retry will be sent from the MSC to CAU for coarse or precise location information, in turn, CAU performs Paging and repaging (if required). Paging for the location services follow the same principal of the SMS paging mechanism such as when Intelligent zone paging is enabled, paging for LCS utilizes that mechanism, when page retry is required, the mobile has to be registered in the SMS repage zone and the parameter CDMA_SMS_PAGE_RETRY in table OFCVAR is set ENABLED to perform repage. This page retry follows the Intelligent Zone paging mechanism too i.e. page retry will be sent to the same zone or system-wide. It is possible that SMS repage zone and Intelligent paging zones have same coverage area. Overall LCS page request success rate Overall LCS page request success rate is approximately equal to the 2G Voice call paging performance or 3G Voice call paging performance.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Location services performance 13-3 Copyright 2008 Nortel Networks
Note 1: Since paging performance should be SO-independent, it is possible to derive the desired metrics for location services from metrics Overall 2G or 3G Voice call paging performance in chapter. In order to derive total number of page responses received for page requests regarding location services, multiply Overall page success rate (for 2G or 3G voice calls) by number of LCS page requests. LCS page requests are represented by the sum of MV2TCHAT and LCPG4CUR OMs. Note 2: In the case of a page response related to lCpg4cur, a release will be sent to the mobile by the CAU to move it back to the idle mode after receiving page response. LCS call setup performance In the case of precise location information for an idle mobile, CAU initiates the BSC and BTS resources setup. There is no special requirements for resource setups at the BTS for LCS related call setups. Note: Some performance metrics from Call setup performance (page 2-1) are used here in order to estimate call setup performance for Location Services. Overall call setup success rate for LCS calls Percentage of overall LCS call setup success after page response is received is expressed by the following ratio: (MV2TCHSU / ATLCS) x 100 Overall call setup failure rate for LCS calls = 100 - Overall call setup success rate for LCS calls Failures indicate unavailable BSC resources for the LCS SO 35, unavailable BTS resources, or RF failure in moving the mobile to a TCH, discounting race conditions like voice call originations and terminations or Mobile initiated Dormant to Active transition or Network/mobile initiated Active to Dormant transition or Network/mobile initiated Active to Null transition during LCS call setup. LCS call setup failure before resources are allocated (blocked calls) Call setup failures before resources are allocated are network-related call setup failures and can be classified as follows: Call setup failure due to lack of physical resources Network resources are defined to be the following switching resources involved in the call: SBS selector elements (ESEL cards only)
CDMA
NBSS15.0
13-4 Location services performance Nortel Networks
BTS resources such as traffic channel elements, Frame offset, Walsh code, Forward capacity and reverse capacity.
Formulas LCS call setup failures (call blocking rate) Following performance metrics are useful to determine blocking rate for LCS call setups due to BSC or BTS resources. LCS call setup failures (blocks) due to lack of BSC resources Percentage of LCS call setup failures (blocks) due to BSC resources is expressed by the following ratio: Possible per BSC (FLLCS / ATLCS) x 100 Miscellaneous information Success rate of IS-801 session setup for precise requests Percentage of precise position requests for which the subsequent IS-801 messaging is started can be expressed by the following ratio: (E911SESS + LCSSESS + LCSSESSX * 65536) / (PRECRQST + PRECCRQSX * 65536 + E911SESS) x100 Because E911SESS in the denominator represents E911-related successful session initiations rather than attempted session initiations, the percentage may be slightly higher than it should be. Successfully started IS-801 sessions after call setup Percentage of successfully started IS-801 sessions for which an idle mobile was successfully moved to a traffic channel can be expressed by the following ratio: (MV2TCHSU + MV2TCHSX * 65536) / (E911SESS + LCSSESS + LCSSESSX * 65536) x100 Average number of databurst messages per IS-801 session Average number of databurst messages per IS-801 session can be expressed by the following ratio: (LCFWDDB + (65536 * LCFWDDBX) + LCREVDB + (65536 * LCREVDBX)) / (E911SESS + LCSSESS) x100 This metric does not account for data burst message retransmissions due to the mobile or network not receiving acknowledgement. A low value provided by this metric may indicate that the mobiles were in bad RF environment during LCS session and in turn higher retransmissions of data burst messages may have occurred.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Location services performance 13-5 Copyright 2008 Nortel Networks
Recommendations
13
Appropriate MPCAP datafill in HLR profile is required to reduce call setup failures due to mobiles responding to pages with an indication of no support for the LCS SO.
Notes
13
The following information can also be obtained from the OMs provided in this feature. Call setup failure for Precise position information due to either an unavailable BTS resources or failures in moving to the mobile to a TCH after resources setup are given by sum SULCS for all BSCs- MV2TCHSU Number of ANSI-41 messages sent and received by the MSC and HLR related to LCS IPRQIVIC + IPRQRRIC + IPRQIVOG + IPRQRROG + IPRFIVIC + IPRFIVOG + IPRFRRIC + IPRFRROG + SMDPOSIC + (SMDPSICX * 65536) + SMDPOSOG + (SMDPSOGX * 65536) + (2 * LCOREQIV) + LPRQIVIC + LPRQRROG Number of network-initiated LCS requests. IPRQIVIC - LCOREQIV Number of coarse (non-precise) positioning requests. (IPRQIVIC - PRECRQST) - E911SESS Since E911SESS represents sessions successfully started as a result of receiving the first E911-related SMDPP of a session, and not all such SMDPPs will be successful (e.g., the SMDPP may arrive when no call is in progress, resulting in an smdpp with SMSCAUSE), this result may be a little high than real possible value. Number of precise positioning requests PRECRQST + E911SESS Note: Since E911SESS represents sessions successfully started as a result of receiving the first E911-related SMDPP of a session, and not all such SMDPPs will be successful, this result may be little lower than real possible value. Position requests (i.e., received ISPOSREQs or ISPOSREQFWDs) for a mobile in a call that result in querying the BSC for current cell/sector/ OWD information
LCQACTMB
CDMA
NBSS15.0
13-6 Location services performance Nortel Networks
411-2133-525
Standard
06.12
April 2008
Nortel Networks
MCTA performance
14
MCTA performance reflects how well the system is allocating resources across multiple frequencies for new originations, terminations, and hard handoff attempts from other CDMA cells. The performance is determined on a per frequency basis. MCTA OMs do not replace the normal call processing OMs but are pegged in addition to the normal call processing OMs.
List of OMs
14
For more information about the following OMs, see MSC OM descriptions (page 21-1) and BTS OM descriptions (page 23-1).
Table 14-1 MCTA performance OMs MSC OMS CAUCPFRQ OM group MCTORIGS MCTTATTS MCTHSUCC MCTNOWCD MCTERLFL MCTDROPR MCTOATTS MCTTSUCC MCTHRLFL MCTNOFOF MCTAREQT MCTREGIS MCTOSUCC MCTHCATT MCTERSFL MCTFWCAP MCTAREQN MCWPSORY MCTPGRES MCTHATTS MCTNOTCE MCTBTSBK MCTARQFN MCWPSTRY
CAUFRQ3V OM group This OM group has the same OM registers as the CAUCPFRQ OM group as listed above.
CAUFRQ3D OM group
sheet 1 of 3
CDMA
NBSS15.0
14-2 MCTA performance Nortel Networks Table 14-1 MCTA performance OMs (continued)
This OM group has the same OM registers as the CAUCPFRQ OM group as listed above.
CAUXTFRQ OM group NMCTATTS MCTPRST MPRFL MRETHBLK MRETHFL NMCTBLKS MCTPRSO MRETATTS MRETSUCC MCTPRRO MPRBLKS MRETHATT MRETHSUC MCTPRRT MPRSUCC MRETBLKS
MRETFL
CAUXTF3V OM group This OM group has the same OM registers as the CAUXTFRQ OM group as listed above.
CAUXTF3D OM group This OM group has the same OM registers as the CAUXTFRQ OM group as listed above.
CAUCPSCT OM group MCTAHRQF MCTAREQF MCTAMIXF MCTALLTO MCTALLFU
CAUSCT3V OM group This OM group has the same OM registers as the CAUCPSCT OM group as listed above.
CAUSCT3D OM group This OM group has the same OM registers as the CAUCPSCT OM group as listed above.
sheet 2 of 3
411-2133-525
Standard
06.12
April 2008
Nortel Networks Table 14-1 MCTA performance OMs (continued) MCBTS OMs Advanced Sector MO 2G_MctaFull[0]: MctaAttempt 2G_MctaFull[4]: MctaFull_RECAP 2G_MctaFull[1]: MctaFull_NoTCE 2G_MctaFull[5]: MctaFull_Radio_confi g 3GV_MctaFull[0]: MctaAttempt 3GV_MctaFull[4]: MctaFull_RECAP 3GV_MctaFull[8]: MctaFull_NoAcn
MCTA performance 14-3 Copyright 2008 Nortel Networks
2G_MctaFull[2]: MctaFull_NoWCD 2G_MctaFull[6]: MctaFull_NoBcn
2G_MctaFull[3]: MctaFull_FWCAP 2G_MctaFull[7]: MctaFull_NoBackhaul
2G_MctaFull[8]: MctaFull_NoAcn 3GV_MctaFull[3]: MctaFull_FWCAP 3GV_MctaFull[7]: MctaFull_NoBackhaul
3GV_MctaFull[1]: MctaFull_NoTCE 3GV_MctaFull[5]: MctaFull_Radio_confi g 3GD_MctaFull[0]: MctaAttempt
3GV_MctaFull[2]: MctaFull_NoWCD 3GV_MctaFull[6]: MctaFull_NoBcn 3GD_MctaFull[1]: MctaFull_NoTCE
3GD_MctaFull[2]: MctaFull_NoWCD 3GD_MctaFull[6]: MctaFull_NoBcn
3GD_MctaFull[3]: MctaFull_FWCAP 3GD_MctaFull[7]: MctaFull_NoBackhaul
3GD_MctaFull[4]: MctaFull_RECAP 3GD_MctaFull[8]: MctaFull_NoAcn
3GD_MctaFull[5]: MctaFull_Radio_confi g
sheet 3 of 3
MCTA call setup failures
14
MCTA comes into effect only during call setup time for originations, terminations and hard handoffs. In the case of hard handoffs, MCTA is used at the target SBS which treats the hard handoff as a new call being setup. The BTS is responsible for maintaining its available resources. Failures to allocate resources are communicated to the SBS and to the CAU via messaging. Those failures are recorded at the CAU via the appropriate MCT* OM registers. In case of overall MCTA frequency selection failure, either MCTAREQF or MCTAHRQF is pegged (along with the appropriate MCTALLFU or MCTALLTO or MCTAMIXF OM register), and in addition the corresponding failure reasons for each of the co-located frequencies will get pegged in the new BTS performance attribute arrays 2G_MctaFull,
CDMA
NBSS15.0
14-4 MCTA performance Nortel Networks
3GV_MctaFull, and 3GD_MctaFull. MCTARQFN is also pegged against carriers which are Full or Not Available. In case of MCTA successful frequency selection despite one or more BTSs failure to allocate resources, the particular failures for the non-selected frequencies are recorded either in MCTAREQT or in MCTAREQN (along with the corresponding failure reason that get pegged in the new BTS performance attribute arrays 2G_MctaFull, 3GV_MctaFull, and 3GD_MctaFull for the non-selected frequencies). Furthermore, if the selected frequency fails to setup resources, then the failure is recorded in MCTERSFL (along with the appropriate MCTNOTCE, MCTNOWCD, MCTFWCAP, MCTBTSBK or MCTNOFOF OM register). Goal Less than x% of all MCTA call attempts (originations, terminations and hard handoff attempts in sectors that have MCTA enabled) fail due to resource shortage on all frequencies (for example, Carrier Determination Algorithm CDA could not select any frequency to place the call attempt on because all frequencies do not have resources available). Less than y% of all MCTA call attempts (originations, terminations and hard handoff attempts in sectors that have MCTA enabled) fail due to resource shortage on the selected frequency by CDA. The variables (x, y) should be defined in accordance with the service providers preference. Formula The following formulae capture the performance of MCTA before and after the Carrier Determination Algorithm (CDA) has selected a frequency. It is important to note that if the OM3G Boolean in CDMAPART is set to Y, then it may be useful to evaluate the different MCTA performance formulae for the different types of calls as described in the next four paragraphs: Total number of call setups attempted The following formula will be used (and will be referred) to throughout the chapter. It represents total number of MCTA call setups attempted after a frequency has been selected by CDA and the call setup is attempted on that selected frequency. Total number of call setups attempted = (MCTOATTS + MCTTATTS + MCTHATTS) for a CDMA frequency for all MCTA sectors
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call types 2G calls All the MCTA performance formulae and validation formulae stated in this section can be limited to events related to 2G voice calls only by using the MCTA OM registers involved in the formulae as follows: If an OM register is referenced that can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, only the OM register belonging to CAUCPSCT is referenced, unless otherwise explicitly stated. Also if an OM register is referenced that can be found in all of CAUCPFRQ, CAUFRQ3V and CAUFRQ3D OM groups (or in CAUXTFRQ, CAUXTF3V and CAUXTF3D OM groups), only the OM register belonging to CAUCPFRQ (or CAUXTFRQ) is referenced, unless otherwise explicitly stated. 3G voice calls All the MCTA performance formulae and validation formulae stated in this section can be limited to events related to 3G voice calls only by using the MCTA OM registers involved in the formulae as follows: If an OM register is referenced that can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, only the OM register belonging to CAUSCT3V is referenced, unless otherwise explicitly stated. Also if an OM register is referenced that can be found in all of CAUCPFRQ, CAUFRQ3V and CAUFRQ3D OM groups (or in CAUXTFRQ, CAUXTF3V and CAUXTF3D OM groups), only the OM register belonging to CAUFRQ3V (or CAUXTF3V) is referenced, unless otherwise explicitly stated. 3G packet data calls All the MCTA performance formulae and validation formulae stated in this section can be limited to events related to 3G packet Data calls only by using the MCTA OM registers involved in the formulae as follows: If an OM register is referenced that can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, only the OM register belonging to CAUSCT3D is referenced, unless otherwise explicitly stated. Also if an OM register is referenced that can be found in all of CAUCPFRQ, CAUFRQ3V and CAUFRQ3D OM groups (or in CAUXTFRQ, CAUXTF3V and CAUXTF3D OM groups), only the OM register belonging to CAUFRQ3D (or CAUXTF3D) is referenced, unless otherwise explicitly stated. All call types together All the MCTA performance formulae and validation formulae stated in this section can be applied to events related to all types of calls together by using the MCTA OM registers involved in the formulae as follows: If an OM register is referenced that can be found in all of CAUCPSCT, CAUSCT3V and CAUSCT3D OM groups, the sum of the 3 registers from each group is referenced, unless otherwise explicitly stated. Also if an OM register is referenced that can be found in all of CAUCPFRQ, CAUFRQ3V and CAUFRQ3D OM groups (or in CAUXTFRQ, CAUXTF3V and CAUXTF3D
CDMA
NBSS15.0
OM groups), the sum of the 3 registers from each group is being referenced, unless otherwise explicitly stated. However, if the OM3G Boolean in CDMAPART is set to N, then the different MCTA performance formulae can be evaluated only for all types of calls together as described in the last bullet above. MCTA frequency selection failures (MCTAREQF + MCTAHRQF) for all MCTA sectors / (MCTORIGS + MCTPGRES + MCTHCATT + MCWPSORY + MCWPSTRY - MCTPRSO - MCTPRST) for all CDMA frequencies for all MCTA sectors x 100 The MCTPRSO and MCTPRST OMs are subtracted in the above formula to account for the origination or termination attempts that get redirected by MCTA to the alternate CDMA band resulting in MCTORIGS or MCTPGRES OM being pegged twice in those events. It is also important to note that the above formula evaluates the metric on a per system wide basis, however when the metric is to be evaluated on a per sector basis, the MCTPRSO and MCTPRST OMs in the above formula need to be replaced with MCTPRRO and MCTPRRT OMs respectively. MCTA resource allocation failures before CDA is executed These formulas capture the events when a particular frequency responds with a resource full response or times out in response to a capacity query request before the Carrier Determination Algorithm (CDA) is executed. Note that this event may or may not lead to overall MCTA frequency selection failure depending on whether all other frequencies respond with a similar response or not. If at least one frequency responds with a resource available response then the CDA will successfully select a carrier for the call attempt. MCTA frequency resource allocation failures (per frequency) ( (MCTAREQF + MCTAHRQF) for all MCTA sectors + (MCTAREQN + MCTAREQT) for a CDMA frequency for all MCTA sectors) / (MCTORIGS + MCTPGRES + MCTHCATT + MCWPSORY + MCWPSTRY) for all CDMA frequencies for all MCTA sectors x 100 MCTA frequency resource allocation failures (per frequency) due to lack of physical resources ( MCTALLFU for all MCTA sectors + (MCTARQFN + MCTAREQN) for a CDMA frequency for all MCTA sectors) / (MCTORIGS + MCTPGRES + MCTHCATT + MCWPSORY + MCWPSTRY) for all CDMA frequencies for all MCTA sectors x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
MCTA frequency resource allocation failures (per frequency) due to time-outs ( MCTALLTO for all MCTA sectors + ( MCTAMIXF for all MCTA sectors - MCTARQFN for a CDMA frequency for all MCTA sectors) + MCTAREQT for a CDMA frequency for all MCTA sectors) / (MCTORIGS + MCTPGRES + MCTHCATT + MCWPSORY + MCWPSTRY) for all CDMA frequencies for all MCTA sectors) x 100 Reason codes for MCTA frequency resource allocation failures When an MCTA frequency is queried for capacity estimate, it will respond with a zero capacity estimate in cases of lack of BTS resources (i.e. No TCE, No WCD,...etc.). In such a case, CDA can not consider such an MCTA frequency for carrier selection for call setup. The following sections present formulas to indicate the percentage a given MCTA frequency responds with a zero capacity estimate due to each BTS resource. These formulas can be evaluated on a per frequency basis for any given sector or for several sectors together (in this case the corresponding OMs from the Advanced Sector MO for these sectors should be added up). The reason code formulas below can be evaluated separately for each type of call (i.e. 2G call, 3G Voice call or 3G Data call) by replacing ** in the formula below with 2G or 3GV or 3GD. To evaluate the formula for all types of calls together, the sum of the corresponding OMs from each array (i.e. 2G array, 3GV array, and 3GD array) should be used. Note: These metrics provide the failures that occur before the Carrier Determination Algorithm is executed. MCTA frequency resource allocation failure due to lack of BTS channel element resources (before the Carrier Determination Algorithm CDA is executed) (**_MctaFull[1] / **_MctaFull[0]) x 100 MCTA frequency resource allocation failure due to lack of walsh codes (before the Carrier Determination Algorithm CDA is executed) (**_MctaFull[2] / **_MctaFull[0]) x 100 MCTA frequency resource allocation failure due to lack of fwd. capacity (before the Carrier Determination Algorithm CDA is executed) (**_MctaFull[3] / **_MctaFull[0]) x 100 MCTA frequency resource allocation failure due to carrier radio configuration not supporting call type (before the Carrier Determination Algorithm CDA is executed) (**_MctaFull[5] / **_MctaFull[0]) x 100
CDMA
NBSS15.0
MCTA frequency resource allocation failure due to lack of BCN capacity (before the Carrier Determination Algorithm CDA is executed) (**_MctaFull[6] / **_MctaFull[0]) x 100 MCTA frequency resource allocation failure due to lack of backhaul capacity (before the Carrier Determination Algorithm CDA is executed) (**_MctaFull[7] / **_MctaFull[0]) x 100 MCTA frequency resource allocation failure due to lack of ACN IDs (before the Carrier Determination Algorithm CDA is executed) (**_MctaFull[8] / **_MctaFull[0]) x 100 MCTA call setup failures These formula determine the call setup failures after the MCTA frequency has been selected and the call setup is attempted on the selected frequency. MCTA frequency related call setup failures (per frequency) MCTERSFL for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100 MCTA call setup failures due to lack of BTS resources (per frequency) (after a frequency has been selected) MCTNOTCE + MCTNOWCD + MCTNOFOF + MCTFWCAP + MCTBTSBK) for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100 MCTA call setup failure due to lack of BTS channel element resources (per frequency) (after a frequency has been selected) MCTNOTCE for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100 MCTA call setup failure due to lack of Walsh codes (after a frequency has been selected) MCTNOWCD for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100 MCTA call setup failure due to no frame offset availability (after a frequency has been selected) MCTNOFOF for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100 MCTA call setup failure due to lack of fwd. capacity (after a frequency has been selected) MCTFWCAP for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
MCTA call setup failure due to miscellaneous BTS failure reasons (after a frequency has been selected) Miscellaneous BTS failure reasons include failures of the following resources: T1E1 backhaul resources, ACN node IDs, or BCN link resources MCTBTSBK for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100 MCTA call setup failures due to BTS time outs (per frequency) (after a frequency has been selected) (MCTERSFL - (MCTNOTCE + MCTNOWCD + MCTNOFOF + MCTFWCAP + MCTBTSBK)) for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100 Non MCTA frequency resource allocation failures (per frequency) For calls originating/terminating on frequencies that have an MCTA_DISABLED setting (i.e. Non MCTA frequency), CDA is not invoked and therefore only resources on the originating frequencies are considered for call setup (Note that the originating frequency is referring to the frequency that the mobile sends an origination/page response message on). The following performance metric evaluates the resource allocation failure rate on these non MCTA frequencies. NMCTBLKS for a Non MCTA frequency for all MCTA sectors / NMCTATTS for a Non MCTA frequency for all MCTA sectors x 100 Retain loading related metrics For MCTA sectors where certain frequencies have MCTA_with_Retain_loading setting, CDA would select the originating frequency for call setup until the frequency reaches its capacity estimate threshold (Note that the originating frequency is referring to the frequency that the mobile sends an origination/page response message on). The following metrics evaluates the percentage of CDA success in setting up calls on the originating carrier Retain loading percentage (per frequency) (MRETATTS + MRETHATT) for a CDMA frequency for all MCTA sectors / (MCTORIGS + MCTPGRES + MCTHCATT + MCWPSORY + MCWPSTRY) for a CDMA frequency for all MCTA sectors x 100 Retain loading blocking rate (per frequency) (MRETBLKS + MRETHBLK) for a CDMA frequency for all MCTA sectors / (MRETATTS + MRETHATT) for a CDMA frequency for all MCTA sectors x 100
CDMA
NBSS15.0
Paging channel redirection related metrics For MCTA sectors where certain frequencies have a setting that allows for Multi Mode Traffic Allocation MMTA (i.e. to allow for redirecting calls to the alternate CDMA band), CDA would under certain condition redirect calls (except HHO attempts) to the CDMA crossband via a paging channel redirection. The following metrics evaluates the percentage of paging channel redirection on a per sector basis. Paging channel redirection percentage (MCTPRRO + MCTPRRT) for a CDMA frequency for all MCTA sectors / (MCTORIGS + MCTPGRES + MCWPSORY + MCWPSTRY - MCTPRSO - MCTPRST) for a CDMA frequency for all MCTA sectors x 100 Paging channel redirection failure rate The following metrics evaluates the paging channel redirection failure rate (i.e calls are redirected to the alternate CDMA band but mobiles fail to reoriginate on the crossband) (MCTPRRO + MCTPRRT - MCTPRSO - MCTPRST) for all CDMA frequencies for all MCTA sectors / (MCTPRRO + MCTPRRT) for all CDMA frequency for all MCTA sectors x 100 Blocking rate for redirected calls (via the paging channel redirection method) The following metrics evaluates the blocking rate for redirected calls via the paging channel redirection method (i.e calls are redirected to the alternate CDMA band and mobiles re-originate on the crossband but calls are blocked due to lack of resources on the crossband). MPRBLKS for all CDMA frequency for all MCTA sectors / (MCTPRSO + MCTPRST) for all CDMA frequencies for all MCTA sectors x 100 MCTA RF access failure (per frequency) These formula determine the MCTA RF access failures after the MCTA frequency has been selected and resources are successfully setup on the selected frequency. By subtracting the Retain Loading RF Access failure rates from the overall RF Access failure rate, the result will reflect the RF Access failure rate for calls that are switched from one carrier to another during call setup. Overall MCTA RF access failure (per frequency) MCTERLFL + MCTHRLFL) for a CDMA frequency for all MCTA sectors / Total number of call setups attempted x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
For 3G Packet Data calls, the sum of registers MCTERLFL and MCTHRLFL over all frequencies for all sectors could be overinflated by TotalSessionSetupFailures which is a BSC OM (see BSC OM descriptions (page 22-1)for OM details). This is because the attempt to set up the R-P packet session is done after the mobile arrives on the traffic channel but before sending the service connect message out to the mobile. Therefore if the R-P packet session setup fails, it will still be pegged as an access failure. The TotalSessionSetupFailures count can be subtracted from the numerator in the above formula when measuring the RF Access Failure rate on a system wide basis for 3G packet data calls. MCTA origination and termination RF access failure (per frequency) MCTERLFL for a CDMA frequency for all MCTA sectors / (MCTOATTS + MCTTATTS) for a CDMA frequency for all MCTA sectors x 100 MCTA hard handoff RF access failure (per frequency) MCTHRLFL for a CDMA frequency for all MCTA sectors / MCTHATTS for a CDMA frequency for all MCTA sectors x 100 Overall retain loading RF access failure (per frequency) MRETFL + MRETHFL) for a CDMA frequency for all MCTA sectors / (MRETATTS + MRETHATT) for a CDMA frequency for all MCTA sectors) x 100 Retain loading origination and termination RF access failure (per frequency) MRETFL for a CDMA frequency for all MCTA sectors / MRETATTS for a CDMA frequency for all MCTA sectors x 100 Retain loading hard handoff RF access failure (per frequency) MRETHFL for a CDMA frequency for all MCTA sectors / MRETHATT for a CDMA frequency for all MCTA sectors x 100 RF access failure for redirected calls to crossband (per frequency) In addition to the Paging channel redirection failure rate on page -10.,this formula determine the RF access failure rate for redirected calls to cross band after the mobiles re-originate on the cross band and resources are setup successfully on a cross band frequency. MPRFL for a CDMA frequency for all MCTA sectors / (MCTPRSO + MCTPRST) for all CDMA frequencies for all MCTA sectors x 100
CDMA
NBSS15.0
MCTA RF related dropped call rate (per frequency) The percentage of established calls on each frequency in MCTA enabled sectors that are dropped due to RF related issues is expressed by the following ratio: MCTDROPR for a CDMA frequency for all MCTA sectors / (MCTOSUCC + MCTTSUCC + MCTHSUCC) for a CDMA frequency for all MCTA sectors x 100
Validation
14
Originations, terminations, and handoffs The OM registers validated in this section are pegged once a MCTA frequency has been selected. A validation formula for MCTA call setup performance is to sum all successful originations, terminations and handoffs and all origination, termination and handoff setup failures due to lack of resources and all origination, termination and handoff RF access failures. That number should be less than or equal to the number of all origination, termination and handoff attempts. The formula can be summarized into: Attempts >= MCTOATTS MCTTATTS MCTHATTS Miscellaneous For MCTA cells, MCTAREQF + MCTAHRQF = MCTALLFU + MCTALLTO + MCTAMIXF MCTAMIXF >= MCTARQFN(f) (for each co-located carrier f). MCTERSFL >= MCTNOTCE + MCTNOWCD + MCTNOFOF + MCTFWCAP + MCTBTSBK (for each co-located carrier f). (MRETATTS + MRETHATT) >= (MRETSUCC + MRETHSUCC + MRETBLKS + MRETHBLK + MRETFL + MRETHFL) (for each co-located carrier f) (MCTPRSO + MCTPRST) >= (MPRSUCC + MPRBLKS + MPRFL) (for each co-located carrier f) Successes + MCTOSUCC MCTTSUCC MCTHSUCC Non-successes MCTERLFL MCTHRLFL MCTERSFL
411-2133-525
Standard
06.12
April 2008
Nortel Networks
CAUOATTS = CAUPGRES = CAUHATTS = CAUOSUCC = CAUTSUCC = CAUHSUCC = CAUERLFL = CAUHRLFL = CAUDROPR =
MCTORIGS ( f ) MCTPGRES ( f ) MCTHCATT ( f ) MCTOSUCC ( f ) MCTTSUCC ( f ) MCTHSUCC ( f ) MCTERLFL ( f ) MCTHRLFL ( f ) MCTDROPR ( f ) MCTOATTS ( f MCTTATTS ( f
MCTORIGS( f ) + MCWPSORY ( f )
f f f
MCTPGRES( f ) + MCWPSTRY ( f )
f f f
MCTHCATT ( f )
f f
MCTHATTS ( f MCTPRSO ( f MCTPRST ( f
MCTPRRO ( f )
f f
MCTPRRT ( f )
f f
Recommendations
14
Overall, the MCTA call setup failure percentages for each of the three types of call setups should be very close to each other since there is no special processing done to prioritize resources for origination over handoff, for
CDMA
NBSS15.0
example. The following sections list OMs that can indicate the need for an adjustment. MCTNOTCE - refer to CAUNOTCE in Call setup performance (page 2-1). MCTNOWCD - refer to CAUNOWCD in Call setup performance (page 21). MCTFWCAP - refer to CAUFWCAP in Call setup performance (page 2-1). MCTBTSBK - refer to SCTBTSBK in Call setup performance (page 2-1). MCTALLFU - Occurrences of this OM indicate that the BTS is running out of capacity on the forward link. Deployment of additional carriers or six sectors should be considered. MCTARQFN - Occurrences of this OM indicate that the BTS is running out of capacity on the forward link. Deployment of additional carriers or six sectors should be considered. MCTALLTO - Occurrences of this OM indicate that the BTSC card is running out of CPU capacity. It could also indicate additional load on the SBSC card. MCTERLFL - refer to CAUERLFL in Call setup performance (page 2-1). MCTHRLFL - refer to CAUHRLFL in Call setup performance (page 2-1). MCTAREQT - Occurrences of this OM indicate that the BTSC card for a particular frequency is running out of CPU capacity. This OM may not always be pegged under low traffic load. MCTAREQN - Occurrences of this OM indicate that the BTS card for a particular frequency is running out of forward capacity. This OM may not always be pegged under low traffic load. MCTDROPR - refer to CAUDROPR in Call setup performance (page 2-1)
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Authentication performance
Authentication air-interface performance
15
15
Authentication is the process by which information is exchanged between the mobile station and the entity performing the authentication, for the explicit purpose of confirming the identity of the mobile. Its primary objective is to allow the network to protect itself from unauthorized users, thereby ensuring that only valid mobiles are granted access to network services. This section deals with the OM registers that track the performance of the CM/ HLR/VLR CDMA air interface with the BTS/BSC for CDMA systems. The following list identifies the authentication messages supported on the DMS-MTX over the Air Interface and describes how each one is used: Unique Challenge Order - This message is sent to the mobile to initiate a Unique Challenge and causes the mobile to run the authentication algorithm. The mobile responds to this message with a Unique Challenge Order Confirmation which contains the authentication algorithm's outputs. SSD (Shared Secret Data) Update Order - This message is sent to the mobile to initiate the SSD Update procedure and causes the mobile to run the authentication algorithm. The mobile responds to this message after completing the Base station Challenge process, with a SSD Update Order Confirmation which contains an indication of the success or failure of the SSD update procedure. Base Station Challenge Order- This message is sent from the mobile to the MSC/VLR in response to the SSD Update Order and contains the random value RANDBS to be used as an input to the authentication algorithm. The MSC/VLR responds to this message with a Base Station Challenge Order Confirmation which contains the authentication algorithm's outputs.
The CAU serves to relay authentication related messages between the CM and the SBS/BTS. These messages may be sent over the paging/access or the traffic channel.
CDMA
NBSS15.0
15-2 Authentication performance Nortel Networks
Goal Attempts to send a SSD Update Message to a CDMA mobile should result in a success response y% of the time. Attempts to send a Unique Challenge to a CDMA mobile should be successful z% of the time. By successful it is meant that a Unique Challenge Order confirmation is received from the mobile.
List of OMs For more information about the following OMs, see List of Metro Cell BTS OMs (page 23-2).
Authentication performance OMs MSC OMs CAUAUTH OM group CAUAORIG CAUSUSA CAUSUFT CAUUCCT CAUBSCCT CAUAREG CAUSUFA CAUUCP CAUBSCA CAUSUCM CAUAPGRS CAUSUT CAUUCCA CAUBSCCP CAUUCCM CAUSUP CAUSUST CAUUCT CAUBSCT CAUBSCCM
Formulas Paging/access channel SSD update attempts This metric provides trending information regarding the distribution of SSD updates between the paging/access and traffic channels. (CAUSUP) / CAUSUCM) x 100 Paging/access channel SSD update failures This metric provides trending information regarding the failure rate for SSD updates attempted over the paging/access channels. (CAUSUFA / CAUSUP) x 100 Traffic channel SSD update attempts This metric provides trending information regarding the distribution of SSD updates between the paging/access and traffic channels. (CAUSUT / CAUSUCM) x 100 Traffic channel SSD update successes This metric provides trending information regarding the success rate for SSD updates attempted over the traffic channels.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
Authentication performance 15-3 Copyright 2008 Nortel Networks
(CAUSUST / CAUSUT) x 100 Traffic channel SSD update failures This metric provides trending information regarding the failure rate for SSD updates attempted over the traffic channels. (CAUSUFT / CAUSUT) x 100 Paging/access channel unique challenge attempts This metric provides trending information regarding the distribution of Unique challenges between the paging/access and traffic channels. (CAUUCP / CAUUCCM) x 100 Paging/access channel unique challenge confirmations This metric provides trending information regarding the response rate for Unique challenges performed over the paging/access channels. (CAUUCCA / CAUUCP) x 100 Traffic channel unique challenge attempts This metric provides trending information regarding the distribution of Unique challenges between the paging/access and traffic channels. (CAUUCT / CAUUCCM) x 100 Traffic channel unique challenge confirmations This metric provides trending information regarding the response rate for Unique challenges performed over the traffic channels. (CAUUCCT / CAUUCT) x 100 Traffic channel base station challenge confirmations This metric provides trending information regarding the response rate for Base Station challenges performed over the traffic channels. (CAUBSCCT) / (CAUBSCT) x 100 Validation SSD update attempts CAUSUP + CAUSUT = CAUSUCM CAUSUSA + CAUSUFA = CAUSUP CAUSUST + CAUSUFT = CAUSUT Unique challenge attempts CAUUCP + CAUUCT = CAUUCCM
CDMA
NBSS15.0
15-4 Authentication performance Nortel Networks
Recommendations CAUSUFA -This implies that the mobile failed to update its SSD. Examine the AUTH302 logs to determine which mobiles are failing SSD update, and then take any appropriate corrective action. CAUSUFT -This implies that the mobile failed to update its SSD. Examine the AUTH302 logs to determine which mobiles are failing SSD update, and then take any appropriate corrective action. CAUUCCA - If the percentage of Unique Challenge confirmations is below a customer-defined threshold, the customer must examine the AUTH300 and AUTH302 logs to determine which mobiles are failing Unique Challenge processing, and take any appropriate corrective action. CAUUCCT -If the percentage of Unique Challenge confirmations is below a customer-defined threshold, the customer must examine the AUTH300 and AUTH302 logs to determine which mobiles are failing Unique Challenge processing, and take any appropriate corrective action.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call resource allocation and management
16
This chapter provides metrics to evaluate the effectiveness of various resources (BTS/BSC) utilization and allocation for different service options in the system. The metrics described in this chapter cover BSC/EBSC resource allocation and management aspects for the RMU and NRM resource managers. This includes a variety of measurements such as call resource allocation failure rate, call resource allocation failure rate per network connection type, distribution of call resource allocation between Service Types, PCU change rate for dormant-to-active requests, PCU allocation failure rate for dormant handoff requests, resource utilization histograms, redirection rate for network connection type, platform selection rate etc. In addition, eighth rate gating and primary sector capacity are also described in this chapter for resource allocation performance and resources utilized in the system. In general, these metrics are used to determine the need for provisioning more resources (BTS/BSC). They may help for re-configuration of already provisioned resources in the system to improve the resource allocation performance.
List of OMs
16
Call resource allocation and management OMs MSC OMs CDMADFSO OM group ATASYC96 ATASY144 SUASYC96 SUASY144 HCASYC96 HCASY144
sheet 1 of 8
FLASYC96 FLASY144
CDMA
NBSS15.0
16-2 Call resource allocation and management Nortel Networks Call resource allocation and management OMs (continued) ATASYCIS ATALG96 ATALG144 ATGR396 ATGR3144 ATGR3IS SUASYCIS SUALG96 SUALG144 SUGR396 SUGR3144 SUGR3IS HCASYCIS HCALG96 HCALG144 HCGR396 HCGR3144 HCGR3IS
FLASYCIS FLALG96 FLALG144 FLGR396 FLGR3144 FLGR3IS
CDMAPDSO OM group ATINPPP SUINPPP HCINPPP FLINPPP
CDMAVSO OM group ATEVRC ATBSC13K ATIS13K ATSMS ATOTAPA ATLCS SUEVRC SUBSC13K SUIS13K SUSMS SUOTAPA SULCS HCEVRC HCBSC13K HCIS13K HCSMS HCOTAPA HCLCS FLEVRC FLBSC13K FLIS13K FLSMS FLOTAPA FLLCS
BSCRM OM group RMUIARV RMUIATOV RMURATOV RMUIASD RMURARD RMUIARV2 RMUIOENV RMURAOEV RMUIASD2 RMURASD RMUIASV RNURARV RMUIARD RMUIATOD RMURATOD RMUIASV2 RMURASV RMUIARD2 RMUIOEND RMURAOED
BSCRM2 OM group
sheet 2 of 8
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call resource allocation and management 16-3 Copyright 2008 Nortel Networks
Call resource allocation and management OMs (continued) RMUIRDS RMURRDS RMUIRDS2 RMUINRDS RMURNRDS RMUITODS RMURTODS RMUIOEDS RMUROEDS
EBSCRM OM group NRMARV NRMOLRV NRMASPD NRMSTOPD NRMANRDS NRMOEDS NRMASPD2 NRMASV NRMSTOV NRMANRPD NRMOEPD NRMATODS NRMARV2 NRMARDS2 NRMANRV NRMOEV NRMSTOPD NRMARDS NRMOLRDS NRMASV2 NRMASDS2 NRMATOV NRMARPD NRMOLPD NRMASDS NRMSTODS NRMARPD2
RMU3G OM group REQ3GV SUC3GV2 SUC3GV NORS3GV2 NORS3GV REQ3GV2
Statistics OM group (PVG OMs) trfoConnectionsSetup connectionsSetup evrcConnectionsSetu p evrc0ConnectionsSet up
BSC OMs Resource Utilization OMs ResourceUtilizationInde x_1 ResourceUtilizationInde x_5 ResourceUtilizationIn dex_2 ResourceUtilizationIn dex_5 ResourceUtilizationIn dex_3 ResourceUtilizationIn dex_6 ResourceUtilizationIn dex_4 ResourceUtilizationIn dex_7
sheet 3 of 8
CDMA
NBSS15.0
16-4 Call resource allocation and management Nortel Networks Call resource allocation and management OMs (continued) ResourceUtilizationInde x_8 ResourceUtilizationInde x_12 ResourceUtilizationInde x_16 ResourceUtilizationInde x_20 ResourceUtilizationInde x_24 ResourceUtilizationInde x_28 ResourceUtilizationIn dex_9 ResourceUtilizationIn dex_13 ResourceUtilizationIn dex_17 ResourceUtilizationIn dex_21 ResourceUtilizationIn dex_25 ResourceUtilizationIn dex_29
ResourceUtilizationIn dex_10 ResourceUtilizationIn dex_14 ResourceUtilizationIn dex_18 ResourceUtilizationIn dex_22 ResourceUtilizationIn dex_26 ResourceUtilizationIn dex_30
ResourceUtilizationIn dex_11 ResourceUtilizationIn dex_15 ResourceUtilizationIn dex_19 ResourceUtilizationIn dex_23 ResourceUtilizationIn dex_27
Call Resource Request Processing OM group AllocationRequestRecei ved AllocationRequestRej ectedDueToOverload AllocationRequestDen ied
Call Resource Setup OM group AllocationRequestAcce pted AllocationRequestRes ourceUnavailable AllocationRequestSuc cesses AllocationRequestFail ures
Resource Availability Check OM group ResourceCheckAttempt s ResourceCheckUnav ailable ResourceCheckAvaila ble
Platform Selection OM group SelectionAttemptsOnPri maryPlatform SelectionSuccessOnP rimaryPlatform SelectionAttemptsOn SecondaryPlatform SelectionSuccessOnS econdaryPlatform
Service Resource Setup OM group

sheet 4 of 8
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call resource allocation and management OMs (continued) SelectedEBSC_Allocati onAttempts AlternateEBSC_Allocati onAttempts SelectedBSC_Allocatio nAttempts AlternateBSC_Allocatio nSuccesses SelectedEBSC_Alloca tionSuccesses AlternateEBSC_Alloc ationSuccesses SelectedBSC_Allocati onSuccesses AlternateBSC_Allocati onFailures SelectedEBSC_MG_ AllocationFailures AlternateEBSC_MG_ AllocationFailures SelectedBSC_Allocati onFailures SelectedEBSC_SDU_ AllocationFailures AlternateEBSC_SDU_ AllocationFailures AlternateBSC_Allocati onAttempts
BSC Resource Request Processing OM group BSC_AllocationRequest Received BSC_AllocationDiscar dedDueToOverload BSC_AllocationReque stDenied
BSC Resource Setup OM group BSC_AllocationRequest Accepted BSC_AllocationInitialTi meouts BSC_AllocationRetryFa ilures BSC_ResourceUnava ilableOnInitialAttempt BSC_AllocationInitialS uccesses BSC_AllocationRetryT imeouts BSC_AllocationInitialA ttempts BSC_ResourceUnava ilableOnRetryAttempt BSC_AllocationRetry Successes BSC_AllocationInitialF ailures BSC_AllocationRetry Attempts BSC_AllocationIntern alFailures
DTA Call Resource Setup OM group DTA_BSC_AllocationR equestAccepted DTA_BSC_RequestedS uccessOnEBSC DTA_EBSC_Allocatio nRequestAccepted DTA_EBSC_Request edSuccessOnEBSC DTA_AllocationReque stResourceUnavailabl e DTA_EBSC_Request edSuccessOnBSC DTA_BSC_Requeste dSuccessOnBSC DTA_AllocationReque stsFailures
DTA BSC PCU Lookup OM group DTA_PacketSessionFo und DTA_PCU_Changed DTA_PCU_NotChang ed
sheet 5 of 8
CDMA
NBSS15.0
16-6 Call resource allocation and management Nortel Networks Call resource allocation and management OMs (continued)
DHO Call Resource Request Processing OM group DHO_AllocationReques tReceived DHO_AllocationRequ estRejectedDueToOv erload DHO_AllocationRequ estDenied
DHO Call Resource Setup OM group DHO_AllocationReques tSuccesses DHO_AllocationRequ estFailures
DHO Service Resource Setup OM group DHO_SelectedEBSC_A llocationAttempts DHO_AlternateBSC_All ocationSuccesses DHO_SelectedBSC_All ocationFailures DHO_SelectedEBSC_ AllocationSuccesses DHO_AlternateBSC_ AllocationFailures DHO_AlternateEBSC _AllocationAttempts DHO_SelectedEBSC_ AllocationFailures DHO_SelectedBSC_A llocationAttempts DHO_AlternateEBSC _AllocationSuccesses DHO_AlternateBSC_ AllocationAttempts DHO_SelectedBSC_A llocationSuccesses DHO_AlternateEBSC _AllocationFailures
EBSC Voice Resource Request Processing OM group

EBSC_VoiceAllocationRe questReceived EBSC_VoiceAllocationR equestAccepted EBSC_VoiceAllocationR equestDenied EBSC_VoiceAllocationR equestDiscardedDueTo Overload
Platform Selection Overload Setup OM group PlatformSelectionFailur esDueToTQ_Exceeded PlatformPreferenceCh ange SecondaryPlatformDr oppedDueToTQ_Exce eded
DTA Platform Selection Overload OM group

sheet 6 of 8
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call resource allocation and management OMs (continued) DTA_PlatformSelection FailuresDueToTQ_Exc eeded DTA_PlatformPrefere nceChange DTA_SecondaryPlatfo rmDroppedDueToTQ_ Exceeded
DHO Platform Selection Overload OM group DHO_PlatformSelection FailuresDueToTQ_Exc eeded DHO_PlatformPrefere nceChange DHO_SecondaryPlatf ormDroppedDueToTQ _Exceeded
DHO Platform Selection Overload OM group DHO_PlatformSelection FailuresDueToTQ_Exc eeded DHO_PlatformPrefere nceChange DHO_SecondaryPlatf ormDroppedDueToTQ _Exceeded
Connection Call Resource Setup OM group ConnectionAllocationRe questReceived ConnectionAllocation ResourceUnavailable ConnectionAllocation ResourceAvailable ConnectionAllocation ResourceFailures
Connection Resource Availability Check OM group ConnectionResourceCh eckAttempts ConnectionResource CheckUnavailable ConnectionResource CheckAvailable
BSC Connection Resource Availability Check OM group BSC_ConnectionResou rceCheckAttempts BSC_ConnectionRes ourceCheckUnavailab le BSC_ConnectionRes ourceCheckAvailable
Connection Resource Redirection OM group AllocationRequestRedir ectonTrFO_ToCct AllocationRequestRed irectonTrFO_ToPkt AllocationRequestRed irectonPktToTrFO AllocationRequestRed irectonPktToCct
sheet 7 of 8
CDMA
NBSS15.0
16-8 Call resource allocation and management Nortel Networks Call resource allocation and management OMs (continued) AllocationRequestRedir ectonCctToTrFO AllocationRequestRedir ectonUnspecifiedToTrF O AllocationRequestRed irectonCctToPkt
AllocationRequestRed irectonUnspecifiedTo Cct
AllocationRequestRed irectonUnspecifiedTo Pkt
Connection Resource Setup OM group EBSC_ConnectionAlloc ationAttempts BSC_ConnectionAllocat ionAttempts EBSC_ConnectionAll ocationSuccesses BSC_ConnectionAlloc ationSuccesses EBSC_MG_Connectio nAllocationFailures BSC_ConnectionAlloc ationFailures EBSC_SDU_Connecti onAllocationFailures
EVRC-B Distribution OM group EVRCB_FrameCountF wdMode_0 EVRCB_FrameCountR evMode_4 EVRCB_SelectionCoun tFwdMode_6 EVRCB_FrameCount FwdMode_4 EVRCB_FrameCount RevMode_6 EVRCB_SelectionCou ntRevMode_0 EVRCB_FrameCount FwdMode_6 EVRCB_SelectionCou ntFwdMode_0 EVRCB_SelectionCou ntRevMode_4 EVRCB_FrameCount RevMode_0 EVRCB_SelectionCou ntFwdMode_4 EVRCB_SelectionCou ntRevMode_6
RFCH Gating OM group RFCHGatingRequests RFCHGatingDeactivatio ns RFCHGatingGranted Requests RFCHGatingDeniedR equests RFCHGatingEnabled Handoffs
Reference Sector Frame Count OM group ReferenceSectorFrame Count_FFCH ReferenceSectorFram eCount_FSCH

sheet 8 of 8
411-2133-525
Standard
06.12
April 2008
Nortel Networks
BSC/EBSC resource management
16 16
This section describes performance metrics for resource management and allocations for the SBS and CSVS, CPDS platforms. The metrics covered in this section are for the RMU and NRM resource allocation and management, SBSRM resource allocation performance, PCU change rate for dormant-toactive requests, PCU allocation failure rate for dormant handoff requests, BSC/EBSC Resource Utilization metrics, metrics for the effects of Overload control and NRM Resource allocation performance for various connection types. RMU resource management This section discusses the BSC resources managed by RMU. When a resource allocation request is sent to the RMU, it consults resources configured (datafilled) and determines whether resources can be requested from BSC or not. The performance of resource configuration into pools is measured using the metrics described in this section. The resource configuration data consists of Definition of Service Pools, configuration of SERVPOOL, SEVRTE and SBSINV tables, EVRC SOCing, configuration of service pools for resource selection etc. These configuration data can be used in conjunction with the metrics to re-configure resources to improve performance if needed. Resource for each service option is requested from a set of pools that are configured as an ordered list in the SERVRTE table. Ideally, the first pool in the ordered list for that Service option should be able to provide resources. If it does not, then every subsequent pool in that ordered list requested for a service option is considered as a Pool Overhead. There may be scenarios when none of the pools in that ordered list for the given service option may be able to allocate resources. A typical scenario affected by this configuration is: Same pools shared by multiple service options, can result in some service options monopolizing the pool while starving some other due to the nature of pool ordering in the SERVRTE table. RMU OMs provide the following measurements for a given Service Option. Average hop count and pool overhead Hop Counts are the number of pools including the first pool in the list consulted to find resources for a specific Service Option except for Packet Data service option (see note below regarding this exception). The Hop Counts for Packet Data service option indicate the number of PCUs searched in order to find resources for the Packet Data calls. PCUs are
16-10 Call resource allocation and management Nortel Networks
searched during transitions to the active state and during dormant handoffs. The Hop Counts OM is pegged in both of these instances. The following set of formulas and metrics will help evaluate the performance of resource configuration and customization. RMU OMs along with the SERVRTE table is used for deriving and calculating the following: For a given Service Option, Average Hop Count = Hop Count / Attempts Percentage of Pool Overhead for a given Service Option can be expressed by the following: Pool Overhead = (Average Hop Count - 1) x 100 For example: For a 13K Service Option, Average Hop Count = HCBSC13K / ATBSC13K Hop Count = HCBSC13K, Attempts = ATBSC13K The Pool Overhead metric stated above does not apply to the Packet Data service option. RMU resource allocation failure per service option The RMU is involved in the SBS resource management for one BSC. It also handles the resource requests from all the CAUs in one BSC. The resource allocation fails after consulting all allocated pools for a specific service option at the RMU. OMs on RMU from CDMAVSO OM group are used in deriving the formula of resource allocation failure per service option are as follows: Percentage of Resource Allocation failure for a given Service Option can be expressed by the following: Percentage of Resource Allocation Failure = (No Resource / Attempts) x 100 For example: For a basic 13K Service Option, Percentage of Resource Allocation Failure = (FLBSC13K / ATBSC13K) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RMU resource allocation performance The performance of BSC resource allocation at RMU is measured using formulas in this section. RMU selects the BSC resources from its internal data structures for a call allocation request from CAU. After the BSC resources are selected by RMU, it tries to allocate the selected BSC resources. Resource allocation failures reported by RMU are measured by OMs from BSCRM OM group on CAU. These OMs are pegged for voice, packet data and data delivery services (SMS, OTAPA, LCS). The failures may lead to call blocks. For more information about call blocks, see Call setup performance (page 2-1). Resource allocation failures (due to lack of resources) This metric provides the RMU resource allocation failure rate due to no available resources when processing the resource allocation requests from the CAU. Percentage failures of initial resource allocation for voice calls: ( RMUIANRV for all CAUs / RMUIARV for all CAUs) x 100 Percentage failures of retry resource allocation for voice calls: ( RMURANRV for all CAUs / RMURARV for all CAUs) x 100 Percentage failures of initial resource allocation for packet data calls: ( RMUIANRD for all CAUs / RMUIARD for all CAUs) x 100 Percentage failures of retry resource allocation for packet data calls: ( RMURANRD for all CAUs / RMURARD for all CAUs) x 100 Percentage failures of initial resource allocation for data delivery services calls: ( RMUINRDS for all CAUs / RMUIRDS for all CAUs) x 100 Percentage failures of retry resource allocation for data delivery services calls: ( RMUINRDS for all CAUs / RMURRDS for all CAUs) x 100 This metric indicates the blocking situation (resource allocation failures) during call setup phase. The blocking situation should first be handled by investigating the cause of blocking such as hardware failures, optimization / re-configuration of tables at RMU for already provisioned resource etc. Even
after removing the possible cause of blocking, the situation doesnt improve then additional BSC/EBSC resource provisioning should be considered for the affected service options. Resource allocation failures (due to processing errors) The metrics provides the RMU resource allocation failure rate due to errors (internal software failures, time outs etc.) that occur when processing the resource allocation requests from CAU. Percentage failures of initial resource allocation for voice calls: ( (RMUIATOV + RMUIOENV) for all CAUs / RMUIARV for all CAUs) x 100 Percentage failures of retry resource allocation for voice calls: ( (RMURATOV + RMURAOEV) for all CAUs / RMURARV for all CAUs) x 100 Percentage failures of initial resource allocation for packet data calls: ( (RMUIATOD + RMUIOEND) for all CAUs / RMUIARD for all CAUs) x 100 Percentage failures of retry resource allocation for packet data calls: ( (RMURATOD + RMURAOED) for all CAUs / RMURARD for all CAUs) x 100 Percentage failures of initial resource allocation for data delivery services calls: ( RMUITODS + RMUIOEDS for all CAUs / RMUIRDS for all CAUs) x 100 Percentage failures of retry resource allocation for data delivery services calls: ( (RMURTODS + RMUROEDS) for all CAUs / RMURRDS for all CAUs) x 100 Resource allocation failures (due to all failure types) A metric providing the view of all failures for initial and retry attempts during resource allocation at RMU can be obtained using the OMs from the BSCRM OM group for voice, packet data and data delivery services (SMS, OTAPA, LCS) For example,
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Percentage failures of initial resource allocation for voice calls: ( (RMUIANRV + RMUIATOV + RMUIOENV) for all CAUs / RMUIARV for all CAUs) x 100 Similarly, other metric formulas can also be derived. Resource utilization metrics Resource management entities at CNFP such as SDRM, CSRM and SBSRM manage various resources such as Selection and Distribution Unit (SDU) resources, 2pVS MG (DSP) and CIC (trunks) resources, Selector Element resources. The SDU resources reported from DSFP-V cards to SDRM reflect the utilization for SDU resources for Voice and Other services. The SDU resources reported from DSFP-D cards to SDRM reflect the utilization for SDU resources for Packet Data and Other service types. The 2pVS cards can be connected to either SPM (Spectrum Peripheral Module), DTC (Digital Trunk Controller) or PVGs (TrFO capable PVGs or Trunk PVGs). The MG resources reported from a 2pVS to CSRM reflects the circuit MG, TrFO MG or packet MG resources depending on its connection to DTC or SPM or PVG. The SBS can be connected to DTC/SPM or PVG. The Selector Element resources reported from SBS connected to DTC/SPM reflects the circuit Selector Element resource types. The Selector Element resources reported from SBS connected to PVG reflects the packet Selector Element resource types. The Selector Element resources reported to SBSRM are the combined utilization of vocoding (DSP) and selector element resources. In summary, the resource manager entities (SBSRM, SDRM and CSRM) at CNFP manage the various resources reported to them as follows: SDRM OMs: Selection and Distribution Unit resources (SDU i.e. Selector Elements) for Voice and Other Service Types (Reported from DSFP-V) Selection and Distribution Unit resources (SDU i.e. Selector Elements) for Packet Data and Other Service Types (Reported from DSFP-D)
CSRM OMs: Circuit Identification Code (CIC meaning trunks) resources TrFO MG (Media Gateway i.e. DSPs) Resources (Reported from 2pVS connected to TrFO capable PVGs)
CDMA
NBSS15.0
Packet MG (Media Gateway i.e. DSPs) Resources (Reported from 2pVS connected to Trunk PVGs) Circuit MG (Media Gateway i.e. DSPs) Resources (Reported from 2pVS connected to SPMs to CSRM): These OMs track the 2pVS resource utilization based on the configured 2pVS licenses. The 2pVS currently supports EVRC and EVRC-B service options and hence the 2pVS resource utilization reflects utilization due to both service options.
EVRC CCDS Circuit license utilization (system-wide): These OMs track the resource utilization for the EVRC service option based on the configured CCDS licenses for EVRC.
EVRC-B CCDS Circuit license utilization (system-wide): These OMs track the resource utilization for EVRC-B service option based on the configured licenses for EVRC-B.
If the resource utilization histograms for EVRC/EVRC-B are high, operator can purchase additional CCDS licenses for EVRC/EVRC-B provided there are enough 2pVS card resources that can support those additional calls. On the other hand if the 2pVS resource utilization is also high then additional 2pVS cards may be needed. SBSRM OMs: Selector Element Resources (Reported from SBS connected to PVGs) Selector Element Resources (Reported from SBS connected to DTCs)
Table 16-1Resource Type summary Resource Type ebscSduVoiceAndOther ebscSduPacketDataAn dOther cic ebscCct ebscPkt Resource Manager SDRM SDRM CSRM CSRM CSRM System-Wide Utilization measurement for: DSFP-V cards DSFP-D cards CIC resources MG connected to SPMs MG connected to Trunk PVGs
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call resource allocation and management 16-15 Copyright 2008 Nortel Networks Table 16-1Resource Type summary Resource Type ebscTrfo ebscEvrcLicense ebscEvrcbLicense bscCct bscPkt Resource Manager CSRM CSRM CSRM SBSRM SBSRM System-Wide Utilization measurement for: MG connected to Trfo capable PVGs EVRC Licences EVRC-B Licences SBS connected to DTCs SBS connected to PVGs
These resource managers have the utilization OMs pegged for the utilization of various types of resources. The Resource Utilization OMs indicate the percentage of licensed resources utilized for the ranges of 0-1%, 1-5%, 5-10%, 10-15%, 15-20%...85-90%, 90-91%, 91-92%...99-100%, 100%. These OMs have finer granularity at the higher end of utilizations for a better view of resource utilization. These OMs are collected in one second interval with an instantaneous value at that time. The instantaneous value indicates the percentage of licensed resources utilized in the system at that particular moment for that particular resource type. The OMs for each resource type make up a histogram that provides the time distribution of resource utilization. The metrics derived from these OMs provide trend of resource utilization (such as average and peak utilization) for various type resources. This section presents the metrics for the corresponding resources at each resource manager entity. (i.e. CSRM, SDRM and SBSRM). Average configured resource utilization This metric provides the average use of resources over the trend monitoring period of time.
CDMA
NBSS15.0
The lower bound of average utilization is expressed as follows: (ResourceUtilizationIndex_1 * 0 + ResourceUtilizationIndex_2 * 1 + ResourceUtilizationIndex_3 * 5 + ResourceUtilizationIndex_4 * 10 + ResourceUtilizationIndex_5 * 15 + ResourceUtilizationIndex_6 * 20 + ResourceUtilizationIndex_7 * 25 + ResourceUtilizationIndex_8 * 30 + ResourceUtilizationIndex_9 * 35 + +...+ ResourceUtilizationIndex_18 * 80 + ResourceUtilizationIndex_19 * 85 + ResourceUtilizationIndex_20 * 90 + ResourceUtilizationIndex_21 * 91 + ResourceUtilizationIndex_22 * 92 + ResourceUtilizationIndex_23 * 93 + +...+ ResourceUtilizationIndex_28 * 98 + ResourceUtilizationIndex_29 * 99 + ResourceUtilizationIndex_30 * 100) / ( ResourceUtilizationIndex_1-30)
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The upper bound of average utilization is expressed as follows: (ResourceUtilizationIndex_1 * 1 + ResourceUtilizationIndex_2 * 5 + ResourceUtilizationIndex_3 * 10 + ResourceUtilizationIndex_4 * 15 + ResourceUtilizationIndex_5 * 20 + ResourceUtilizationIndex_6 * 25 + ResourceUtilizationIndex_7 * 30 + ResourceUtilizationIndex_8 * 35 + ResourceUtilizationIndex_9 * 40 + +...+ ResourceUtilizationIndex_18 * 85 + ResourceUtilizationIndex_19 * 90 + ResourceUtilizationIndex_20 * 91 + ResourceUtilizationIndex_21 * 92 + ResourceUtilizationIndex_22 * 93 + ResourceUtilizationIndex_23 * 94 + +...+ ResourceUtilizationIndex_28 * 99 + ResourceUtilizationIndex_29 * 100 + ResourceUtilizationIndex_30 * 100) / ( ResourceUtilizationIndex_1-30) where, ResourceUtilizationIndex_1-30 = ResourceUtilizationIndex_1 + ResourceUtilizationIndex_2 + ResourceUtilizationIndex_3 + ResourceUtilizationIndex_4 + +...+ ResourceUtilizationIndex_27 + ResourceUtilizationIndex_28 + ResourceUtilizationIndex_19 + ResourceUtilizationIndex_30 The above metrics can be derived at each resource manager for various resource types. These metrics provide trending information of the resource utilization which can be used for resource planning.
CDMA
NBSS15.0
If resource utilization trend for a particular resource type is steadily increasing then additional resource provisioning should be considered to reduce call blocking. Peak configured resource utilization The highest bin containing non zero count provides the peak utilization of resources during the monitoring time period. For example, if ResourceUtilizationIndex_18 is the highest bin then peak utilization for this resource type is between range 80% <= 85%. If the peak utilization is steadily increasing closer to 100% of peak level, additional resources provisioning should be planned. If the average and peak both value are close and towards 100%, resource provisioning should be planned. NRM resource allocation performance This section describes various resource allocation and management metrics that are available at the NRM (i.e. Network Resource Manager, which is the centralized resource manager entity for SBS, CPDS and CSVS call resources). Many of the metrics described in this section can be calculated on a per Service group or per Service Type basis. There are three Service groups called voice, packetData and other; and there are nine Service Types called packetPpp, smsRateSet1, markov, msLoopback, otapa1, lcsRateSet1, evrc8k, evrcb, highRateVoice13k, and csd (For all practical purposes, a Service Type is the same as a service option). 1. Service group voice includes Service Types evrc8k, evrcb, highRateVoice13k, and csd. 2. Service group packetData includes Service Type packetPpp. 3. Service group other includes Service Types smsRateSet1, markov, msLoopback, otapa1, and lcsRateSet1. Resource allocation failures (due to lack of resources) This metric provides the NRM resource allocation failure rate due to lack of resources when processing the incoming resource allocation requests from the CAU. The metric can be calculated individually for each Service group or combined for all Service groups together. The resource allocation failure rate due to lack of resources (combined for all Service groups) is expressed by the following ratio: ( AllocationRequestResourceUnavailable for all Service groups / AllocationRequestAccepted for all Service groups) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
The resource allocation failure rate due to lack of resources (for a specific Service group: voice or packetData or other) is expressed by the following ratio: (AllocationRequestResourceUnavailable for the Service group / AllocationRequestAccepted for the Service group) x 100 This metric provides an indication to provision additional BSC/EBSC resources for the affected Service group(s). However, in some cases it may be possible to relieve this situation by optimizing the Preference Table configuration of already provisioned resources. Refer to the NRM platform selection performance metrics (page -20) that presents examples for the NRM preference table re-configuration needs in order to prevent call blocking. Resource allocation failures (due to processing errors) This metric provides the NRM resource allocation failure rate due to errors (internal software failures, timeouts etc.) that occur when processing the incoming resource allocation requests from the CAU. The metric can be calculated individually for each Service group or combined for all Service groups together. The resource allocation failure rate due to processing errors (combined for all Service groups) is expressed by the following ratio: ( AllocationRequestFailures for all Service groups / AllocationRequestAccepted for all Service groups) x 100 The resource allocation failure rate due to processing errors (for a specific Service group: voice or packetData or other) is expressed by the following ratio: (AllocationRequestFailures for the Service group / AllocationRequestAccepted for the Service group) x 100 Resource unavailability rate This metric indicates how often there are no resources for a particular service type in the system due to lack of resources. Resource Unavailability Rate for a Service Type is expressed by following ratio: (ResourceCheckUnavailable for a Service Type / ResourceCheckAttempts for a Service Type) x 100 This metric is useful to determine the need for more resources in the system. Typically, this metric value should be zero when resources are adequately provisioned in the system.
Additionally, this metric can also be used in conjunction with Distribution Rate of Platform selection to determine optimization need of NRM preference table. (See Distribution Rate of Platform Selection for a Service) NRM platform selection performance metrics These metrics are useful in determining performance of NRM platform selection mechanism. NRM has a configurable Preference Table to achieve the desired distribution of call on both platforms. If the configuration is not done optimally, there may be resource starvation for some Service Types. In this situation, these metrics help to identify the need for reconfiguration of preference table. The resource starvation should first be handled by optimizing the preference table. If optimization does not improve situation or where optimization is not feasible then additional resources should be provisioned. These metrics indicate need of provisioning of additional resources for a Service Type. The Selection Success Rate of Primary platform metric is useful to determine need of provisioning additional resources. The distribution rate of primary vs. secondary platform metric is useful in preference table reconfiguration. These metrics are only applicable to the Service Types that are supported on both platforms. Selection success rate of primary platform for a service type This metric indicates the Selection Success rate of primary and secondary platform on a per Service Type basis. Selection Success rate of Primary Platform for a Service Type is expressed by the following ratio: (SelectionSuccessOnPrimaryPlatform for a Service Type / SelectionAttemptsOnPrimaryPlatform for a Service Type) x 100 The selection success rate usage is explained using an example here. As a simple example, suppose that for EVRC Service Type, EBSC is the configured primary platform and BSC is the configured secondary platform. The ratio of EVRC resources available on EBSC Vs. BSC is 3:1. An assumption in this example is that Call Hold Time is uniform and same for all calls. In one case, when Primary Platform (EBSC in this example) satisfies all EVRC requests and Overflow Threshold is not exceeded, the Selection Success Rate will be 100%.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
In another case, when there is an overflow from EBSC to BSC, the Primary Platform Selection Success Rate will go below 100% as some of the EVRC calls are attempted first on EBSC but will set up successfully on the BSC. Another scenario is that the system is operating at the maximum capacity. Both EBSC and BSC platforms will successfully setup all incoming requests up to their available capacity. Out of all these requests, 75% will succeed on EBSC and 25% on BSC. (Selection success rate for primary platform (EBSC) will be 75% in this case.) The selection success rate ratio of Primary Vs. Secondary Platforms (EBSC Vs. BSC) will be 75:25 which is equal to their resource availability ratio of 3:1. Therefore, if the trend indicates that Selection Success Rate of Primary Platform metric (75% in above example) is closer to the ratio of the Primary Platform with respect to total capacity, it may indicate that primary platform is running closer to the maximum capacity. In that situation, more resources on the Primary Platform may be required for that Service Type. The relevant fluctuation range of the metrics could perhaps be determined on a case by case basis depending on the system characteristics such as call model, system capacity etc. Selection success rate of secondary platform for a service type Selection Success rate of Secondary Platform for a Service Type is expressed by the following ratio: (SelectionSuccessOnSecondaryPlatform for a Service Type / SelectionAttemptsOnSecondaryPlatform for a Service Type) x 100 This metric provides information on the selection success rate on the secondary platform. Overflow rate from primary to secondary platform Overflow rate from Primary to Secondary platform can be derived by a formula (100 - Selection Success Rate of a Primary platform for a Service Type) Distribution rate of platform selection for a service type This metric provides information on the distribution of platform selection across primary and secondary platforms for a Service Type. This metric shows successful distribution of allocated resources on two platforms. The successful distribution on a per platform for each Service Type can be obtained by Distribution Rate of Resource Allocations on SBS and CPDS, CSVS. Distribution rate of Primary Platform selection for a Service Type is expressed by the following ratio:
[SelectionSuccessOnPrimaryPlatform for a Service Type / (SelectionSuccessOnPrimaryPlatform + SelectionSuccessOnSecondaryPlatform) for a Service Type] x 100 Distribution rate of Secondary Platform selection for a Service Type: [SelectionSuccessOnSecondayPlatform for a Service Type / (SelectionSuccessOnPrimaryPlatform + SelectionSuccessOnSecondaryPlatform) for a Service Type] x 100 Note: The sum of above two metrics is 100%. This metric can be used in conjunction with Resource Unavailability Rate to determine need to re-configure the Preference Table. Preference table can be re-configured for Overflow threshold or a choice of Primary/Secondary platform for each Service Type. The purpose of the re-configuration is to avoid the starvation of resources for a Service Type on any Platform by distributing calls properly to both platforms. (See examples below) Example: Reconfiguration of overflow thresholds for a Service Type Service Types that are only configured on SBS (e.g. 13K voice) have to compete for resources with EVRC which is supported on both EBSC and BSC. As a simple example, suppose that configured primary and secondary platforms are EBSC and BSC for EVRC. The intention in this case is to allocate most of the resources for EVRC on the EBSC platform first and keep the SBS available for 13K. Given this scenario, if few percentage of EVRC calls are still ending up on SBS, it may result in higher than 0% of resource unavailability rate for 13K. In this case, EVRC Overflow Thresholds should be re-evaluated to avoid starvation of 13K on SBS. Similarly, the above assessment applies to the Service Types configured on both platforms (e.g., SMS, OTAPA, Packet Data etc.) as they also have to compete for resources with each other. Example: Reconfiguration of the choice of platforms for a Service Type As a simple example, suppose that BSC is the configured Primary Platform for EVRC and most of the EVRC calls are ending up on BSC. As a result, 13K Unavailability rate could be much higher (closer to 100%) because the SBS is used for setting up EVRC calls. Hence, choice of Platforms for EVRC should be switched to EBSC as the Primary Platform to avoid starvation of 13K Service Type on the BSC. In summary, to avoid resource starvation or to optimize the preference table, Distribution Rate and Resource Unavailability rate for different Service Types should be monitored together.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Resource allocation failures on SBS and CPDS, CSVS This metric provides failure rate of resource allocations that are attempted on the SBS and CPDS, CSVS platforms by the NRM using the respective platform resource managers (i.e. SBSRM for SBS platform and CSRM/ SDRM for CPDS, CSVS platform). Typically, this metric value should be very low and it is indicative of processing errors that occur after NRM has selected a platform which has resources available. One of the processing errors is resource availability mismatch information between NRM and subresource manager. This can happen when resource utilization is running close to 100% and could result in resource allocation failures. The failure rate of resource allocations (for a specific Service Type) on the SBS platform is expressed by the following ratio: ((SelectedBSC_AllocationFailures + AlternateBSC_AllocationFailures) for the Service Type / (SelectedBSC_AllocationAttempts + AlternateBSC_AllocationAttempts) for the Service Type) x 100 The failure rate of resource allocations (for a specific Service Type) on the CPDS, CSVS platform is expressed by the following ratio: ((SelectedEBSC_MG_AllocationFailures + AlternateEBSC_MG_AllocationFailures + SelectedEBSC_SDU_AllocationFailures + AlternateEBSC_SDU_AllocationFailures) for the Service Type / (SelectedEBSC_AllocationAttempts + AlternateEBSC_AllocationAttempts) for the Service Type) x 100 Similarly, both of the above formulas can be enhanced by using the sum of respective OMs for all Service Types together in order to calculate the overall success rate of resource allocations on each platform. Distribution rate of resource allocations on SBS and CPDS, CSVS This metric provides distribution of successful resource allocations for each Service Type in terms of all successfully processed resource allocation requests by the NRM. In addition, this distribution is obtained separately for SBS and CPDS, CSVS platforms. The distribution rate of successful resource allocations (for a specific Service Type) on the SBS platform is expressed by the following ratio: [ (SelectedBSC_AllocationSuccesses + AlternateBSC_AllocationSuccesses) for the Service Type / (SelectedBSC_AllocationSuccesses + AlternateBSC_AllocationSuccesses) for all Service Types ] x 100
CDMA
NBSS15.0
Example: Distribution of successful resource allocations on SBS (by service type)

packetPpp 8% 12% 1% 4% 10% 65% smsRateSet1 otapa1 lcsRateSet1 evrc8k highRateVoice13k
The distribution rate of successful resource allocations (for a specific Service Type) on the CPDS, CSVS platform is expressed by the following ratio: ((SelectedEBSC_AllocationSuccesses + AlternateEBSC_AllocationSuccesses) for the Service Type / (SelectedEBSC_AllocationSuccesses + AlternateEBSC_AllocationSuccesses) for all Service Types) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Example: Distribution of successful resource allocations on CPDS/CSVS (by service type)
packetPpp smsRateSet1 38% evrc8k
57%
5%
This distribution rate at each platform for a Service Type can be used to estimate the breakdown of resources utilized by each Service Type on any platform. For more information about average configured resource utilization, see Resource utilization metrics (page -13). For example, the breakdown percentage of average resources (i.e. Selector Elements) utilized by EVRC Service Type on the CSVS platform can be estimated by the following ratio: ((SelectedEBSC_AllocationSuccesses + AlternateEBSC_AllocationSuccesses) for EVRC / (SelectedEBSC_AllocationSuccesses + AlternateEBSC_AllocationSuccesses) for all Service Types) x ((Average configured resources utilized) for ebscSduVoiceAndOther resource type) Suppose that in an OM collection period, the Average configured resources utilized on DSFP-V cards is 60%, and the distribution rate of successful resource allocations for EVRC on the CSVS platform is 80%, then the estimated breakdown of selector elements utilized by EVRC on CSVS platform is 48% (and the remaining 12% breakdown of utilized selector elements can be attributed to other Service Types).
CDMA
NBSS15.0
Additional formulas Percentage of resource allocation requests processed by NRM This metric indicates the percentage of incoming call resource allocation requests from the CAU that the NRM accepts for processing. During NRM overload condition, this provides an indirect measure of impact to overall call setup performance in the system. ( AllocationRequestAccepted for all Service groups / AllocationRequestReceived) x 100 SBSRM resource allocation performance This section describes resource allocation metrics at the SBSRM (i.e. SBS Resource Manager). The NRM interacts with the SBSRM for call resource allocation on the SBS. Resource allocation failures (due to resource availability status mismatch) This metric provides the SBSRM resource allocation failure rate due to lack of available SBS resources when processing the incoming resource allocation requests from the NRM. This primary cause is that there is mismatch between the NRM and SBSRM regarding SBS resource availability status (which could arise in high resource utilization case), because otherwise NRM would not have made the request to SBSRM. The metric can be calculated individually for each Service group or combined for all Service groups together. The resource allocation failure rate due to lack of resources (combined for all Service groups) is expressed by the following ratio: ( (BSC_ResourceUnavailableOnInitialAttempt + BSC_ResourceUnavailableOnRetryAttempt) for all Service groups / BSC_AllocationRequestAccepted for all Service groups) x 100 The resource allocation failure rate due to lack of resources (for a specific Service group or Service Type) is expressed by the following ratio: ((BSC_ResourceUnavailableOnInitialAttempt + BSC_ResourceUnavailableOnRetryAttempt) for the Service group or Service Type / BSC_AllocationRequestAccepted for the Service group or Service Type) x 100 Resource allocation failures (due to processing errors) This metric provides the SBSRM resource allocation failure rate due to errors (internal software failures, time-outs etc.) that occur when processing the incoming SBS resource allocation requests from the NRM. The metric can be
411-2133-525
Standard
06.12
April 2008
Nortel Networks
calculated individually for each Service group or combined for all Service groups together. The resource allocation failure rate due to processing errors (combined for all Service groups) is expressed by the following ratio: ( (BSC_AllocationInitialTimeouts + BSC_AllocationRetryTimeouts + BSC_AllocationRetryFailures + BSC_AllocationInternalFailures) for all Service groups / BSC_AllocationRequestAccepted for all Service groups) x 100 The resource allocation failure rate due to processing errors (for a specific Service group or Service Type) is expressed by the following ratio: ((BSC_AllocationInitialTimeouts + BSC_AllocationRetryTimeouts + BSC_AllocationRetryFailures + BSC_AllocationInternalFailures) for the Service group or Service Type / BSC_AllocationRequestAccepted for the Service group or Service Type) x 100 This metric indicates that SBS resource allocation failed at the SBSRM because of internal errors and/or communication errors with SBS. Additional formulas When processing the incoming SBS resource allocation requests from the NRM, SBSRM makes up to two resource allocation attempts on the SBS platform. Success Rate of Initial Attempt by SBSRM ( BSC_AllocationInitialSuccesses for all Service groups / BSC_AllocationInitialAttempts for all Service groups) x 100 Success Rate of Retry Attempt by SBSRM ( BSC_AllocationRetrySuccesses for all Service groups / BSC_AllocationRetryAttempts for all Service groups) x 100 Percentage of resource allocation requests processed by SBSRM This metric indicates the percentage of incoming SBS resource allocation requests from the NRM that the SBSRM accepts for processing. ( BSC_AllocationRequestAccepted for all Service groups / BSC_AllocationRequestReceived) x 100 PCU change rate for dormant to active requests This section describes inter-platform and SBS intra-platform PCU change rate metric at the NRM and SBSRM respectively, when processing dormantto-active resource allocation requests. Metrics described in this section may
be useful for CNFP traffic/capacity studies, call modeling and correlating with dormant-to-active packet data call setup performance, but are not considered generally useful for resource provisioning of packet data calls. Note that metric formulas in this section use OMs for packetPpp Service Type from the DTA Call Resource Setup and DTA BSC PCU Lookup OM groups. SBS to CPDS PCU change rate This metric measures how often PCU is changed from SBS to CPDS platform, where the PCU with dormant packet session resides on SBS and a new packet session is to be established on a CPDS PCU for the transition to active state. This PCU change is due to lack of required packet data call resource (i.e. selector element) on SBS. The SBS to CPDS PCU change rate is expressed by the following ratio: (DTA_BSC_RequestedSuccessOnEBSC / DTA_BSC_AllocationRequestAccepted) x 100 CPDS to SBS PCU change rate This metric measures how often PCU is changed from CPDS to SBS platform, where the PCU with dormant packet session resides on CPDS and a new packet session is to be established on a SBS PCU for the transition to active state. This PCU change is due to lack of required packet data call resource (i.e. selector element) on CPDS. The CPDS to SBS PCU change rate is expressed by the following ratio: (DTA_EBSC_RequestedSuccessOnBSC / DTA_EBSC_AllocationRequestAccepted) x 100 Inter-platform PCU change rate (compared to successful dormant-to-active resource allocations) This metric measures how often PCU is changed between either platform (CPDS to SBS and vice versa), in comparison with all dormant-to-active resource allocation requests that are successful. The inter-platform PCU change rate (compared to successful dormant-toactive resource allocations) is expressed by the following ratio: ((DTA_BSC_RequestedSuccessOnEBSC + DTA_EBSC_RequestedSuccessOnBSC) / (DTA_BSC_RequestedSuccessOnBSC + DTA_EBSC_RequestedSuccessOnEBSC + DTA_BSC_RequestedSuccessOnEBSC + DTA_EBSC_RequestedSuccessOnBSC)) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
SBS intra-platform PCU change rate This metric measures how often PCU is changed from within the SBS platform, where the PCU with dormant packet session resides on one SBS shelf and a new packet session is to be established on another SBS shelf for the transition to active state. This PCU change is due to lack of required packet data call resource (i.e. selector element) at the SBS shelves level. The SBS intra-platform PCU change rate is expressed by the following ratio: (DTA_PCU_Changed / DTA_PacketSessionFound)x 100 Additional formulas Percentage of D-to-A resource allocation requests This metric indicates the percentage of incoming dormant-to-active packet data resource allocation requests from the CAU that the NRM accepts for processing, in comparison with the total packet data resource allocation requests. ((DTA_BSC_AllocationRequestAccepted + DTA_EBSC_AllocationRequestAccepted) / AllocationRequestAccepted for packetData Service group) x 100 Success rate of D-to-A resource allocation requests This metric indicates the success rate of incoming dormant-to-active packet data resource allocation requests from the CAU that the NRM accepts for processing, regardless of the platform where resources are allocated. ((DTA_BSC_RequestedSuccessOnBSC + DTA_EBSC_RequestedSuccessOnEBSC + DTA_BSC_RequestedSuccessOnEBSC + DTA_EBSC_RequestedSuccessOnBSC) / (DTA_BSC_AllocationRequestAccepted + DTA_EBSC_AllocationRequestAccepted)) x 100 PCU allocation performance for dormant handoff requests This section describes metrics to measure PCU allocation performance at the NRM, when processing dormant handoff PCU requests. Metrics described in this section may be useful for CNFP traffic/capacity studies and call modeling, but are not considered generally useful for PCU resource provisioning. Note that metric formulas in this section use OMs for packetPpp Service Type from the DHO Call Resource Setup and DHO Service Resource Setup OM groups.
CDMA
NBSS15.0
PCU allocation failure rate for DHO This metric indicates the failure rate of incoming dormant handoff PCU allocation requests from the CAU that the NRM accepts for processing. The PCU allocation failure rate for DHO is expressed by the following ratio: (DHO_AllocationRequestFailures / (DHO_AllocationRequestReceived DHO_AllocationRequestRejectedDueToOverload DHO_AllocationRequestDenied)) x 100 PCU allocation failures on SBS and CPDS This metric provides failure rate of dormant handoff PCU allocations that are attempted on the SBS and CPDS platforms by the NRM via the respective platform resource managers (i.e. SBSPCUM for SBS platform and CPDS PCU-M for CPDS platform). The failure rate of DHO PCU allocations on the SBS platform is expressed by the following ratio: ((DHO_SelectedBSC_AllocationFailures + DHO_AlternateBSC_AllocationFailures) / (DHO_SelectedBSC_AllocationAttempts + DHO_AlternateBSC_AllocationAttempts)) x 100 The failure rate of DHO PCU allocations on the CPDS platform is expressed by the following ratio: ((DHO_SelectedEBSC_AllocationFailures + DHO_AlternateEBSC_AllocationFailures) / (DHO_SelectedEBSC_AllocationAttempts + DHO_AlternateEBSC_AllocationAttempts)) x 100 Distribution rate of PCU allocations on SBS and CPDS, CSVS This metric provides distribution (by SBS and CPDS platforms) of successful dormant handoff PCU allocations, in terms of all successfully processed PCU allocation requests by the NRM. The distribution rate of successful DHO PCU allocations on the SBS platform is expressed by the following ratio: ((DHO_SelectedBSC_AllocationSuccesses + DHO_AlternateBSC_AllocationSuccesses) / (DHO_SelectedBSC_AllocationSuccesses + DHO_AlternateBSC_AllocationSuccesses + DHO_SelectedEBSC_AllocationSuccesses + DHO_AlternateEBSC_AllocationSuccesses)) x 100
411-2133-525 Standard 06.12 April 2008
Nortel Networks
The distribution rate of successful DHO PCU allocations on the CPDS platform is expressed by the following ratio: ((DHO_SelectedEBSC_AllocationSuccesses + DHO_AlternateEBSC_AllocationSuccesses) / (DHO_SelectedBSC_AllocationSuccesses + DHO_AlternateBSC_AllocationSuccesses + DHO_SelectedEBSC_AllocationSuccesses + DHO_AlternateEBSC_AllocationSuccesses)) x 100 Additional formulas Percentage of PCU allocation requests processed by NRM This metric indicates the percentage of incoming dormant handoff PCU resource allocation requests from the CAU that the NRM accepts for processing. During NRM overload condition, this provides an indirect measure of impact to overall dormant handoff performance in the system. ((DHO_AllocationRequestReceived DHO_AllocationRequestRejectedDueToOverload DHO_AllocationRequestDenied) / DHO_AllocationRequestReceived)x 100 Average Request Rate (per second) for dormant handoff This metric indicates the average rate of incoming dormant handoff PCU resource allocation requests from the CAU that the NRM accepts for processing, during a given full 30 minute OM collection period. ((DHO_AllocationRequestReceived DHO_AllocationRequestRejectedDueToOverload DHO_AllocationRequestDenied) / 1800) x 100
Resource allocation metrics during CNFP overload
16
CPU Overload of the resource managing entities (NRM, SBSRM, CSRM) on the CNFP can result in resource allocation failures or change in platform selection. These effects are measured using metrics presented in this section. Resource allocation failures (due to NRM overload condition) This metric provides failures due to NRM Overload situation. Resource allocation failure rate is expressed by the following ratio: (AllocationRequestRejectedDueToOverload / (AllocationRequestReceived) for all Service groups) x 100 This metric provides information of resource allocation failures at NRM due to Overload conditions.
NRM discards every incoming message regardless of message type during severe overload conditions that may be caused by ACN message queue being exceeded. Resource allocation requests discarded during severe overload conditions are not accounted in the above formula. Note that SDRM is running on the same PMC as NRM. Hence, SDRM also goes into CPU overload when NRM is in CPU overload situation. Resource allocation failures (due to transaction queue exceeded) This metric provides the resource allocation failures due to Transaction queue exceeding system defined thresholds due to possible overload condition of CSRM / SBSRM. Resource allocation failure rate is expressed by the following ratio: Voice, Packet Data (N-to-A and D-to-A), Other Call types: (PlatformSelectionFailuresDueToTQ_Exceeded + DTA_PlatformSelectionFailuresDueToTQ_Exceeded / (AllocationRequestAccepted) for all Service groups) x 100 Dormant Handoff requests: (DHO_PlatformSelectionFailuresDueToTQ_Exceeded / (DHO_AllocationRequestReceived DHO_AllocationRequestRejectedDueToOverload DHO_AllocationRequestDenied)) x 100 Effects of CSRM / SBSRM overload on platform selection mechanism CPU overload of sub-resource manager or Transaction queue exceeding at NRM for EBSC and BSC platforms can result in one of the followings: Change in the selection preference of EBSC and BSC Drop of the platform whose resource manager is in overload. These effects reflected in metric below cause preference change of platforms but it does not cause resource allocation failures. Preferred platform change rate This metrics shows the number of times Platform choices are interchanged due to Transaction Queue Size exceeded or SBSRM / CSRM is in Overload status. Platform Preference Change rate is expressed by the following ratio:
411-2133-525 Standard 06.12 April 2008
Nortel Networks
Voice, Packet Data (N-to-A and D-to-A), Other Call types: (PlatformPreferenceChange + DTA_PlatformPreferenceChange / (AllocationRequestAccepted) for all Service groups) x 100 Dormant Handoff requests: (DHO_PlatformPreferenceChange / (DHO_AllocationRequestReceived DHO_AllocationRequestRejectedDueToOverload DHO_AllocationRequestDenied)) x 100 Secondary platform drop rate This metric shows the number of times the Secondary Platform is eliminated from the selection choices due to Transaction Queue exceeded thresholds on that platform. Secondary platform drop rate is expressed by the following ratio: Voice, Packet Data (N-to-A and D-to-A), Other Call types: (SecondaryPlatformDroppedDueToTQ_Exceeded + DTA_SecondaryPlatformDroppedDueToTQ_Exceeded / (AllocationRequestAccepted) for all Service groups) x 100 Dormant Handoff requests: (DHO_SecondaryPlatformDroppedDueToTQ_Exceeded / (DHO_AllocationRequestReceived DHO_AllocationRequestRejectedDueToOverload DHO_AllocationRequestDenied)) x 100 Resource allocation failures at CSRM and SBSRM (due to overload condition) This metric provides failures due to Overload situation at the resource manager entity. Resource allocation failure rate is expressed by the following ratio: CSRM: (EBSC_VoiceAllocationRequestDiscardedDueToOverload / EBSC_VoiceAllocationRequestReceived) x 100 SBSRM:
CDMA
NBSS15.0
(BSC_AllocationRequestDiscardedDueToOverload / BSC_AllocationRequestReceived) x 100
Resource allocation performance for connection type

This section describes the metrics for the Resource Allocation for various connection types at NRM.
16
CAU sends a Connection Type indicator for voice services in the resource allocation request to the NRM. The possible connection type indicators are: TrFO, packet, circuit, unspecified. Unspecified connection type means that CAU sends a resource allocation request with an empty connection type. NRM maintains the view of resource availability for each connection type. Resource allocation failures for a connection type (due to lack of resources) This metric provides the NRM resource allocation failure rate due to lack of resources for a connection type when processing the incoming resource allocation requests from the CAU. The resource allocation failure rate due to lack of resources is expressed by the following ratio: (ConnectionAllocationResourceUnavailable for a connection type / ConnectionAllocationRequestReceived for a connection type) x 100 This metric provides an indication of no resource situation at BSC/EBSC for the affected connection type. A further investigation should be performed in order to resolve no resource situation such as hardware failures etc. If the no resource situation doesnt improve after resolving blocking reasons, additional resources should be provisioned for an appropriate connection type. That may resolve the resource unavailability situation. Resource allocation failures for a connection type (due to processing errors) This metric provides the NRM resource allocation failure rate for a connection type due to errors (internal software failures, timeouts etc.) that occur when processing the incoming resource allocation requests from the CAU. The resource allocation failure rate due to processing errors for a connection type is expressed by the following ratio: (ConnectionAllocationResourceFailures for a connection type / ConnectionAllocationRequestReceived for a connection type) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Resource availability rate for a connection type This metric provides the successful resource allocation rate for a connection type from the total resource allocation requests received. The resource availability rate is expressed by the following ratio: (ConnectionAllocationResourceAvailable for a connection type / ConnectionAllocationRequestReceived for a connection type) x 100 Additional formula Percentage of resource allocation requests on a per connection type This metric indicates the percentage of incoming resource allocation requests on a per connection type at the NRM. The percentage of resource allocation requests on a per connection type is expressed by the following ratio: (ConnectionAllocationRequestReceived for a connection type / (ConnectionAllocationRequestReceived) for all connection types) x 100 This metric provides a view of the percentage distribution of voice allocation requests on a per connection type. Resource unavailability rate for a connection type This metric indicates how often there is no resource situation for a connection type in the system. EVRC resource unavailability rate The EVRC resource unavailability rate for a connection type is expressed by the following ratio: (ConnectionResourceCheckUnavailable for a connection type / ConnectionResourceCheckAttempts for a connection type) x 100 Typically, this metric value should be zero when resources are adequately provisioned in the system. Resource unavailability rate for EVRC TrFO indicates no resource situation for EVRC TrFO on CSVS. Resource unavailability rate for EVRC Packet and EVRC Circuit should be monitored along with Resource Utilization Metrics on CSRM for ebscPkt, ebscCct resource types. The analysis of these metrics assist in determining the platform (CSVS or SBS) on which the EVRC packet or EVRC circuit resource provisioning is needed. Provisioning additional resources on relevant platform may improve resource unavailability situation. Similar metric is applicable to EVRC-B service option
13K resource unavailability rate The 13K resource unavailability rate for a connection type is expressed by the following ratio: (BSC_ConnectionResourceCheckUnavailable for a connection type / BSC_ConnectionResourceCheckAttempts for a connection type) x 100 Resource Unavailability Rate for 13K on a per connection indicates provisioning need for 13K packet and/or 13K circuit resources on SBS. Resource re-direction rate This metric provides the resource redirection rate for a requested connection type for resource allocation requests. An example of Resource redirection rate from TrFO to circuit connection is expressed by the following ratio: (AllocationRequestRedirectionTrFO_ToCct / ConnectionAllocationRequestReceived) x 100 Resource redirection rate for all other connection types can be derived in the similar way as expressed in the above ratio. This metric provides the re-direction from CAU requested connection type to the next suitable connection type. For example, if CAU has requested resources for EVRC TrFO and NRM eventually allocates resources for EVRC packet, it is resource re-direction from TrFO to packet. One of the intentions of the resource re-direction is to prevent resource allocation failures due to no resource situation for the requested connection type. Another intention is to distribute the resource allocations on two different platforms as desired by not selecting a particular platform when the utilization of that platform has exceeded than configured threshold. Re-direction of resources takes place at various phases of resource allocation as follows: During NRM resource availability check phase, if resources are unavailable for a preferred connection type, the next connection type is attempted. During platform selection phase, if the utilization percentage of EVRC for a preferred connection type is above overflow thresholds on both platforms, another connection type is attempted. Upon NRMs resource allocation request to the sub resource managers with a preferred connection type, sub resource manager may respond back with another connection type if the resources for the requested connection type are not available.
06.12 April 2008
411-2133-525
Standard
Nortel Networks
If a resource re-direction rate to circuit connection type is higher than zero, it may indicate that more IW-SPM hardware are utilized during call setup. Distribution rate of resource allocation per connection type This metric provides distribution of successful resource allocations for each connection type in terms of all successfully processed resource allocation requests by NRM. In addition, this distribution is obtained separately for SBS and CSVS platforms. The distribution rate of successful resource allocation for a specific connection type on SBS is expressed by the following ratio: (BSC_ConnectionAllocationSuccesses for a connection type / BSC_ConnectionAllocationSuccesses for all connection types) x 100 The distribution rate of successful resource allocation for a specific connection type on CSVS is expressed platform by the following ratio: (EBSC_ConnectionAllocationSuccesses for a connection type / EBSC_ConnectionAllocationSuccesses for all connection types) x 100 Resource allocation failure rate per connection type This metric provides resource allocation failure rate at NRM for each connection type during interaction of NRM with SDRM/CSRM or SBSRM. These errors are internal errors, time outs or resource mismatches between NRM and SDRM / CSRM / SBSRM. Resource allocation failure rate per connection type for SBS is expressed by the following ratio: (BSC_ConnectionAllocationFailures for a connection type / BSC_ConnectionAllocationAttempts for a connection type) x 100 Resource allocation failure rate per connection type for CSVS is expressed by the following ratio: ((EBSC_MG_ConnectionAllocationFailures + EBSC_SDU_ConnectionAllocationFailures) for a connection type / (EBSC_ConnectionAllocationAttempts for a connection type)) x 100 Distribution ratio for TrFO Vs. NonTrFO calls at TrFO capable PVG cards The TrFO capable PVG cards perform the codec negotiation which may result in the call utilizing TrFO mode (on the TrFO capable PVG successful negotiation of EVRC codec will result in activation of TrFO mode). This
CDMA
NBSS15.0
metric provides the distribution ratio of successful TrFO mode Vs. Non-TrFO mode at the TrFO capable PVGs (The OMs in the following metrics should be used from TrFO capable PVG cards). Distribution for TrFO calls is expressed by the following ratio: (trfoConnectionsSetup / connectionsSetup) x 100 Distribution for Non-TrFO calls is expressed by the following ratio: [(connectionsSetup - trfoConnectionsSetup) / connectionsSetup] x 100 = [1 (trfoConnectionsSetup / connectionsSetup)] x 100 This metric assists in determining the TrFO mode utilization success at TrFO capable PVGs. This metric is similar to the corresponding metric at NRM (Resource availability rate for TrFO connection type). However, the metric values may differ because PVG may be supporting more BSCs and may be handling different mix of traffic. Distribution ratio for EVRC Vs. Non-EVRC calls at non-TrFO PVG cards The Non-TrFO PVG cards perform codec negotiation for NonTrFO calls (i.e. EVRC and non-EVRC codec types). This metric provides the distribution ratio of successful EVRC Vs. Non-EVRC codec negotiations at non-TrFO PVGs (The OMs in the following metrics should be used from Non-TrFO PVG cards). Distribution rate for EVRC core calls is expressed by the following ratio: [(evrcConnectionsSetup + evrc0ConnectionsSetup) / connectionsSetup] x 100 (Note that this metric is applicable for RTO PVG cards because RTO PVGs are the ones that support EVRC codec types.) Distribution rate for Non-EVRC core calls is expressed by the following formula: = [100 Distribution rate for EVRC Core calls] This metric assists in determining the codec negotiation success at non-TrFO PVGs. This metric is similar to the corresponding metric at NRM (Resource availability rate for packet connection type). However, the metric values may differ because PVG may be supporting more BSCs may be connected to numerous different entities and may be handling different mix of traffic.
EVRC-B related Metrics
16
EVRC-B is the spectrally efficient vocoder that allows the operator to make efficient use of the RF spectrum. This service option supports variable codec
411-2133-525 Standard 06.12 April 2008
Nortel Networks
modes which represent different average encoding rates. The higher codec mode produces a lower encoding rate suitable for high capacity environments at a small reduction in voice quality. By using an efficient mode management scheme operator will be able to trade-off RF capacity (users/sector) for voice quality and vice-versa. The current EVRC-B mode management scheme permits the use of Modes 0, 4 & 6. The lowest mode Mode 0 has similar functionality as the existing EVRC service option whereas the highest mode Mode 6 can support significantly high capacity. This service option is supported on the CSVS platform and on the Circuit Resource type only. Operator can control the mode managament scheme on a per BSC basis by using either the Static or the Dynamic mode management configuration. When the operator selects the Static configuration and a desired codec mode, all the calls are initiated with that mode only. This configuration can be used where a predictable capacity gain or known voice quality is desired. When the operator selects dynamic mode configuration (default setting), the BSC uses operator-selected thresholds and the current sector forward link RF loading to determine forward and reverse link modes. EVRC-B Mode distribution Metrics (event based) During call setup, based on the BTS loading report and the threshold settings (customer defined or default) a forward mode and reverse mode are selected for the call. These metrics capture the distribution of modes (that are selected during call setup based on the loading report) over the entire BSC in both the forward and reverse directions. These metrics will help the operator validate the threshold settings that determine the mode selection. If Dynamic mode management configuration is selected, then for a capacity (or a voice quality) conscious network one should see significant pegs in the higher modes (or lower modes) provided the thresholds settings are done correctly. On the other hand, if Static mode management configuration is selected, these metrics simply track the static mode the operator selected for use. Selection percentage for forward Mode X {{EVRCB_SelectionCountFwdMode_X / (EVRCB_SelectionCountFwdMode_0 + EVRCB_SelectionCountFwdMode_4 + EVRCB_SelectionCountFwdMode_6 )} * 100 Where X = 0, 4 or 6. Selection percentage for reverse Mode X {{EVRCB_SelectionCountRevMode_X / (EVRCB_SelectionCountRevMode_0 +
EVRCB_SelectionCountRevMode_4 + EVRCB_SelectionCountRevMode_6 )} * 100 Where X = 0, 4 or 6. It is important to note that the above metrics do not capture EVRC-B calls that are setup on RC1. For these calls, the sector loading report is not considered for mode selection and Mode 0 is selected for the call in both the forward and reverse directions. EVRC-B Mode distribution Metrics (time-based) These metrics capture the amount of time a particular mode is being used (forward and reverse) for the duration of the call. This information will help understand the actual BTS resource usage by both the forward and reverse modes. These OMs are frame-based and so are captured every 20ms aganist the mode that is being currently used. It is important to note that since these OMs are captured on a per frame basis any mode changes after call setup will also be captured. Telematics calls request calls to be setup on Mode 0 only irrespective of the mode selection based on the BTS loading during call setup. Percentage of frames using forward Mode X {EVRCB_FrameCountFwdMode_X / (EVRCB_FrameCountFwdMode_0 + EVRCB_FrameCountFwdMode_4 + EVRCB_FrameCountFwdMode_6 )} * 100 Where X = 0, 4 or 6. Percentage of frames using reverse Mode X {EVRCB_FrameCountRevMode_X / (EVRCB_FrameCountRevMode_0 + EVRCB_FrameCountRevMode_4 + EVRCB_FrameCountRevMode_6 )} * 100 Where X = 0, 4 or 6.
Primary sector capacity metrics
16
The metrics proposed in this section provide detailed information about the amount of subscriber traffic carried by each EBID in the system. This information can be used to estimate the future resource requirements for the BSC (SBS, CPDS) and BTS. When approximate carried load is calculated over a single carrier-sector, it represents the air-link erlang load of the EBID and helps to determine if a new carrier is required to be added on that sector. Note 1: The metrics below are calculated over a busy hour period. This is because over a busy hour the product of call request rate and call holding
411-2133-525 Standard 06.12 April 2008
Nortel Networks
time is a constant. Since the OM reporting interval is 30 minutes, the OMs are to be summed over two 30 minute intervals. Note 2: The primary sector capacity metrics discussed in this section are not reliable when there are non-zero entries in the corresponding PeggingLimitationExceeded OM group. Approximate carried load per BSC for non-packet data This metric is a measure of the approximate non-packet data load that is carried by a BSC. Knowing the traffic increase pattern, per BSC metrics can be utilized to estimate the future requirement for selector cards to support all the non-packet data calls with a given blocking probability. The approximate carried load per BSC for non-packet data is expressed by the following ratio: Total number of non-packet data frames carried by the BSC x 0.02 / 3600 Total number of non-packet data frames carried by the BSC = ( ReferenceSectorFrameCount_FFCH over all RCs, all EBIDs and all non-packet data SOs supported by the BSC) Approximate carried load per BSC for packet data This metric is a measure of the approximate packet data load that is carried by a BSC. Knowing the traffic increase pattern, per BSC metrics can be utilized to estimate the future requirement for selector cards to support all the packet data calls with a given blocking probability. The approximate carried load per BSC for packet data is expressed by the following ratio: Total number of packet data frames carried by the BSC x 0.02 / 3600 Total number of packet data frames carried by the BSC = ( ReferenceSectorFrameCount_FFCH over all RCs, all EBIDs and all packet data SOs supported by the BSC) Example: Using the above metric and Erlang B table, the resource utilization can be obtained. Consider a BSC with 4 SBS shelves i.e.120 ESEL cards (1920 selector elements). Let Approximate Carried Load for Non-Packet Data = 1740 erlangs At 0.1% blocking, 1920 SEs can carry 1829 erlangs of traffic. Hence the resource utilization is given by:
(Carried Load / Provisioned erlangs) x 100 = 95.1%. This indicates that the ESEL resources provisioned for non-packet data are near exhaustion and there is a need to provision more resources. Similar resource utilization can be calculated for packet data load. Note: The resource utilization should be calculated over the resources that are provisioned for the particular service option (voice or packet data). Provisioned resources for voice on the ESEL are the resources that are dedicated for voice service option. Similarly, provisioned resources for packet data (Service Option = 33) on the ESEL are the resources that are dedicated for packet data SO. Approximate carried load per sector This metric is a measure of the approximate load that is carried by a sector. Per sector metrics provide the over the air load that is supported by the sector with a given blocking probability. The approximate carried load per sector is expressed by the following ratio: Total number of non-packet data and packet data frames carried by the sector x 0.02 / 3600 Total number of non-packet data and packet data frames carried by the sector = {( ReferenceSectorFrameCount_FFCH over all RCs and all SOs supported by a carrier-sector)}all carriers in a sector Approximate carried load per carrier-sector This metric is a measure of the approximate load that is carried by a carrier sector. These metrics can be used as indicators for increasing the number of carriers in a sector. The approximate carried load per carrier-sector is expressed by the following ratio: Total number of non-packet data and packet data frames carried by the carrier-sector x 0.02 / 3600 Total number of non-packet data and packet data frames carried by the carrier-sector = ( ReferenceSectorFrameCount_FFCH over all RCs and all SOs supported by a carrier-sector) Note: The above metric assumes that none of the calls in any of the sectors of the BTS are in soft/softer handoff. A BTS may be carrying calls
411-2133-525
Standard
06.12
April 2008
Nortel Networks
which are in soft/softer handoff with other sectors. Since the OMs are pegged only if the sector is the reference sector for that call, the carried load estimated from the metric may be lower than the actual load carried by the sector. Better estimates of the carried load may be obtained using other BTS OMs (PrimaryFrameCntFCH, etc.) Load contribution per service option on BSC This metric provides the load contribution of each service option towards the approximate load carried by the BSC. Knowledge of the traffic distribution in the BSC on a per service option basis can be used for reconfiguring the available resources at the BSC among different service pools. Each service option can be configured for a different blocking probability. The percentage of load contribution by a particular service option is expressed by the following: {(Total number of frames carried by the BSC with a particular SO / Total number of frames carried by the BSC) x 0.02} x 100 Total number of frames carried by the BSC with a particular SO = ( ReferenceSectorFrameCount_FFCH over all RCs, all EBIDs and a particular SO supported by the BSC) Total number of frames carried by the BSC = ( ReferenceSectorFrameCount_FFCH over all RCs, all EBIDs and all SOs supported by the BSC)
CDMA
NBSS15.0
Example:
Load Contribution chart
13% 1% 14% 1% 16% 24% 2% 2% 2% 20% 12% 1% 2%
8K calls Loopback 13K calls Asynchronous Data Services CSD calls Group 3 Fax Analog Fax EVRC calls Location Services Markov calls Packet Data SMS OTAPA
Note: The numbers stated in this example are for illustration purposes only.
Eighth rate gating formulas
16
Due to the potential impact the Eighth Rate Gating functionality has on forward link capacity, it is important to monitor the blocking rate due to lack of forward capacity (see Call setup performance (page 2-1)) when considering the values of the following metrics and determining if the ReverseFCHGatingCapacityThreshold in the AdvancedSector MO needs to be adjusted. Gating request rates These formulas can be used to measure the penetration of mobiles that utilize Eighth Rate Gating in the network. Since the feature may have an impact on forward link capacity, these metrics may be used to determine if this functionality is prevalent enough in the network to potentially be the cause of an impact. The percentage of non-blocking 3G voice calls that request eighth rate gating is expressed by the following (may be evaluated per-sector or per-system): (Number of calls that request gating/Number of non blocking 3G voice originations or terminations) x 100 Number of calls that request gating = RFCHGatingRequests
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Number of non blocking 3G voice originations or terminations = FchOriginationNonBlocking3GVoice The percentage of non-blocking calls (of all call types) that request eighth rate gating is expressed by the following (may be evaluated per-sector or per-system): (Number of calls that request gating/Number of non blocking 2G, 3G voice, and 3G data Originations/Terminations) x 100 Number of calls that request gating = RFCHGatingRequests Number of non blocking 2G, 3G voice, and 3G data Originations/ Terminations = FchOriginationNonBlocking2G + FchOriginationNonBlocking3GVoice + FchOriginationNonBlocking3GData + FchOriginationNonBlocking3GDowngrade2G Even though resources are available to set up the call, the call may still fail for a variety of reasons (e.g. radio link access failure). This metrics only intention is to measure how often the gating functionality is being requested by the mobile stations in the network. The FchOriginationNonBlocking2G, FchOriginationNonBlocking3GVoice, FchOriginationNonBlocking3GData, and FchOriginationNonBlocking3GDowngrade2G OMs are found in the AdvancedSector MO of the BTS. Gating request granted rate Percentage of Originations/Terminations that request eighth rate gating that are granted gating is expressed by the following (may be evaluated per-sector or per-system): (Number of granted gating requests/Number of gating requests) x100 Number of granted gating requests = RFCHGatingGrantedRequests Number of gating requests = RFCHGatingRequests Gating request denied rate A high value of this metric may indicate the ReverseFCHGatingCapacityThreshold is set to a value that is too low, or that the power level in the sector is consistently high enough to exceed the threshold. Depending on the overall traffic level and target capacity of the sector, the threshold may need to be adjusted; this may in turn further increase the value of this metric. (Number of denied gating requests/Number of gating requests) x 100 Number of denied gating requests = RFCHGatingDeniedRequests Number of gating requests = RFCHGatingRequests
Gating-enabled handoff percentage The ReverseFCHGatingCapacityThreshold is not checked when adding soft/ softer handoff links. If a call has gating enabled upon origination/termination, it remains enabled as it moves through the system. Gating is only disabled during hard handoff or under certain soft handoff conditions described in the next metric. As gating may have an impact on forward link capacity, it is useful to know what percentage of mobiles handing off into a particular sector or cluster are performing gating. Depending on the overall traffic level, blocking rate, gating usage, etc., this metric will aid in optimizing the value of ReverseFCHGatingCapacityThreshold. Percentage of soft handoff links that when added are supporting a call with gating enabled is expressed by the following (may be evaluated per-sector or per-system): (Number of gating-enabled soft handoffs/Number of non-blocking 3G voice handoffs) x 100 Number of gating-enabled soft handoffs = RFCHGatingEnabledHandoffs Number of non-blocking 3G voice handoffs = FchHandoffNonBlocking3GVoice Depending on the topology of the network, some of the gating-enabled soft handoff links being established in the sector may have gating deactivated during the final stages of call setup (refer to the next section). If this is the case, the numerator should be replaced with RFCHGatingEnabledHandoffs RFCHGatingDeactivations to better reflect the number of soft handoff links that are established that actually perform gating. Note: FchHandoffNonBlocking3GVoice is found in the AdvancedSector MO of the BTS. Gating deactivation rate Due to the specific circumstances that dictate deactivating gating while a call is active, this metric is more for informational purposes than for indicating the need for action on the part of the operator. Percentage of links that have gating deactivated when a handoff link has been requested due to differences in values in reverse power control delay between 2 BTSs or for soft handoff to a BTS that does not support gating is expressed by the following (may be evaluated per-sector or per-system): (Number of gating deactivations/Number of gating-enabled calls) x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Number of gating deactivations = RFCHGatingDeactivations Number of gating-enabled calls = RFCHGatingEnabledHandoffs + RFCHGatingGrantedRequests Gating usage Percentage of calls setup in a sector that have gating enabled is expressed by the following (per-sector): (Number of originations, terminations, handoffs with gating enabled/ Number of calls setup in the sector) x 100 Number of originations, terminations, handoffs with gating enabled = RFCHGatingEnabledHandoffs + RFCHGatingGrantedRequests Number of calls setup in the sector = FchOriginationNonBlocking2G + FchOriginationNonBlocking3GVoice + FchOriginationNonBlocking3GData + FchOriginationNonBlocking3GDowngrade2G + FchHandoffNonBlocking2G + FchHandoffNonBlocking3GVoice + FchHandoffNonBlocking3GData This metric provides the operator with an idea of how many gating enabled calls are in a particular sector based on how the resources are setup, i.e. the forward power usage is below the ReverseFCHGatingCapacityThreshold and there are gating-enabled soft handoffs being setup in that sector. However, if there are gating deactivations happening in the sector, it is more accurate to replace the numerator in the above formula with RFCHGatingEnabledHandoffs + RFCHGatingGrantedRequests RFCHGatingDeactivations, as this better reflects the number of links that actually have gating enabled after the call is completely setup. Note: Even though resources are available to set up the call, the call may still fail for a variety of reasons (e.g. radio link access failure). This metrics only intention is to measure the overall usage of gating by the mobile stations in the network. The FchOriginationNonBlocking2G, FchOriginationNonBlocking3GVoice, FchOriginationNonBlocking3GData, FchOriginationNonBlocking3GDowngrade2G, FchHandoffNonBlocking2G, FchHandoffNonBlocking3GVoice, and FchHandoffNonBlocking3GData OMs are found in the AdvancedSector MO of the BTS.
Validation
16
Service option validation formulas In general, the validation formulas for each service option are summarized by:
CDMA
NBSS15.0
Attempts = Success + Non-successes For example, for the EVRC service option: ATEVRC = SUEVRC+ FLEVRC For all other service options, follow the above example using the appropriate OMs for that service option. For 3G service options, following the validation example above: REQ3GV + REQ3GV2= SUC3GV + SUC3GV2+NORS3GV + NORS3GV2 ATINPPP = SUINPPP+FLINPPP Resource utilization validation formula For 30 minutes of OM collection period: (ResourceUtilizationIndex_1 - 30) = 1800 Resource allocation validation formula System where RMU is BSC resource manager Initial voice call requests: RMUIARV + (RMUIARV2 * 65536) = RMUIASV + (RMUIASV2 * 65536) + RMUIATOV + RMUIANRV + RMUIOENV Retry voice call requests: RMURARV = RMURASV + RMURATOV + RMURANRV + RMURAOEV Initial packet data call requests: RMUIARD + (RMUIARD2 * 65536) = RMUIASD + (RMUIASD2 * 65536) + RMUIATOD + RMUIANRD + RMUIOEND Retry packet data call requests: RMURARD = RMURASD + RMURATOD + RMURANRD + RMURAOED Initial data delivery service call requests: RMUIRDS + (RMUIRDS2 * 65536) = RMUISDS + (RMUISDS2 * 65536) + RMUITODS + RMUINRDS + RMUIOEDS Retry data delivery services call requests:
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RMURRDS = RMURSDS + RMURTODS + RMURNRDS + RMUROEDS System where NRM is EBSC / BSC resource manager Voice call requests: NRMARV + (NRMARV2 * 65536) = NRMASV + (NRMASV2 * 65536) + NRMANRV + NRMATOV + NRMOEV + NRMOLRV + NRMSTOV Packet Data call requests: NRMARPD + (NRMARPD2 * 65536) = NRMASPD + (NRMASPD2 * 65536) + NRMANRPD + NRMATOPD + NRMOEPD + NRMOLRPD + NRMSTOPD Data Delivery Services call requests: NRMARDS + (NRMARDS2 * 65536) = NRMASDS + (NRMASDS2 * 65536) + NRMANRDS + NRMATODS + NRMOEDS + NRMOLRDS + NRMSTODS NRM resource allocation validation formula AllocationRequestReceived = AllocationRequestRejectedDueToOverload + AllocationRequestDenied + AllocationRequestAccepted for all Service groups For each Service group, AllocationRequestAccepted = AllocationRequestResourceUnavailable + AllocationRequestSuccesses + AllocationRequestFailures For each Service Type: ResourceCheckAttempts = ResourceCheckAvailable + ResourceCheckUnavailable For each Service Type supported on both platforms: SelectionAttemptsOnPrimaryPlatform = SelectionSuccessOnPrimaryPlatform + SelectionSuccessOnSecondaryPlatform For each Service group and Service Type,
CDMA
NBSS15.0
SelectedEBSC_AllocationAttempts = SelectedEBSC_AllocationSuccesses + SelectedEBSC_MG_AllocationFailures + SelectedEBSC_SDU_AllocationFailures AlternateEBSC_AllocationAttempts = AlternateEBSC_AllocationSuccesses + AlternateEBSC_MG_AllocationFailures + AlternateEBSC_SDU_AllocationFailures SelectedBSC_AllocationAttempts = SelectedBSC_AllocationSuccesses + SelectedBSC_AllocationFailures AlternateBSC_AllocationAttempts = AlternateBSC_AllocationSuccesses + AlternateBSC_AllocationFailures SBSRM resource allocation validation formula BSC_AllocationRequestReceived = BSC_AllocationDiscardedDueToOverload + BSC_AllocationRequestDenied + BSC_AllocationRequestAccepted for all Service groups/Service Types. For each Service group and Service Type, BSC_AllocationRequestAccepted = BSC_ResourceUnavailableOnInitialAttempt + BSC_AllocationInitialTimeouts + BSC_AllocationInitialSuccesses + BSC_ResourceUnavailableOnRetryAttempt + BSC_AllocationRetryFailures + BSC_AllocationRetryTimeouts + BSC_AllocationRetrySuccesses + BSC_AllocationInternalFailures CSRM resource allocation validation formula EBSC_VoiceAllocationRequestReceived = EBSC_VoiceAllocationRequestAccepted + EBSC_VoiceAllocationRequestDenied + EBSC_VoiceAllocationRequestDiscardedDueToOverload Dormant-to-active - PCU change validation formula DTA_BSC_AllocationRequestAccepted + DTA_EBSC_AllocationRequestAccepted = DTA_ResourceUnavailable + DTA_BSC_RequestedSuccessOnBSC + DTA_BSC_RequestedSuccessOnEBSC + DTA_EBSC_RequestedSuccessOnEBSC + DTA_BSC_RequestedSuccessOnBSC + DTA_AllocationRequestsFailures
411-2133-525
Standard
06.12
April 2008
Nortel Networks
DTA_PacketSessionFound = DTA_PCU_Changed + DTA_PCU_NotChanged Dormant handoff - PCU allocation validation formula DHO_AllocationRequestReceived = DHO_AllocationRequestRejectedDueToOverload + DHO_AllocationRequestDenied + DHO_AllocationRequestSuccesses + DHO_AllocationRequestFailures DHO_SelectedEBSC_AllocationAttempts = DHO_SelectedEBSC_AllocationSuccesses + DHO_SelectedEBSC_AllocationFailures DHO_AlternateBSC_AllocationAttempts = DHO_AlternateBSC_AllocationSuccesses + DHO_AlternateBSC_AllocationFailures DHO_SelectedBSC_AllocationAttempts = DHO_SelectedBSC_AllocationSuccesses + DHO_SelectedBSC_AllocationFailures DHO_AlternateEBSC_AllocationAttempts = DHO_AlternateEBSC_AllocationSuccesses + DHO_AlternateEBSC_AllocationFailures DHO_AllocationRequestSuccesses = DHO_SelectedEBSC_AllocationSuccesses + DHO_AlternateBSC_AllocationSuccesses + DHO_SelectedBSC_AllocationSuccesses + DHO_AlternateEBSC_AllocationSuccesses Resource allocation for connection types validation formula Resource availability check validation formula For EVRC and EVRC-B: For each connection type: ConnectionResourceCheckAttempts[ConnectionType] = ConnectionResourceCheckAvailable[ConnectionType] + ConnectionResourceCheckUnavailable[ConnectionType] For 13K: For each connection type: BSC_ConnectionResourceCheckAttempts[ConnectionType] = BSC_ConnectionResourceCheckAvailable[ConnectionType] + BSC_ConnectionResourceCheckUnavailable[ConnectionType]
CDMA
NBSS15.0
Resource re-direction for connection type validation formula ConnectionAllocationRequestReceivedTrFO = ConnectionAllocationResourceUnavailableTrFO+ ConnectionAllocationResourceAvailableTrFO + ConnectionAllocationResourceFailuresTrFO + AllocationRequestRedirectionTrFO_ToCct + AllocationRequestRedirectionTrFO_ToPkt ConnectionAllocationRequestReceivedpacket = ConnectionAllocationResourceUnavailablepacket+ ConnectionAllocationResourceAvailablepacket + ConnectionAllocationResourceFailurespacket + AllocationRequestRedirectionPktToCct + AllocationRequestRedirectionPktToTrFO ConnectionAllocationRequestReceivedcircuit = ConnectionAllocationResourceUnavailablecircuit + ConnectionAllocationResourceAvailablecircuit + ConnectionAllocationResourceFailurescircuit + AllocationRequestRedirectionCctToPkt + AllocationRequestRedirectionCctToTrFO ConnectionAllocationRequestReceivedunspecified = ConnectionAllocationResourceUnavailableunspecified + ConnectionAllocationResourceAvailableunspecified + ConnectionAllocationResourceFailuresunspecified + AllocationRequestRedirectionUnspecifiedToPkt + AllocationRequestRedirectionUnspecifiedToTrFO + AllocationRequestRedirectionUnspecifiedToCct Successful resource allocation per platform validation formula For all connection type: CSVS: EBSC_ConnectionAllocationAttempts for all connection types = EBSC_ConnectionAllocationSuccesses for all connection types + EBSC_MG_ConnectionAllocationFailures for all connection types + EBSC_SDU_ConnectionAllocationFailures for all connection types SBS: BSC_ConnectionAllocationAttempts for all connection types = BSC_ConnectionAllocationSuccesses for all connection types +
411-2133-525 Standard 06.12 April 2008
Nortel Networks
BSC_ConnectionAllocationFailures for all connection types Eighth rate gating validation formula RFCHGatingRequests = RFCHGatingGrantedRequests + RFCHGatingDeniedRequests
CDMA
NBSS15.0
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RF performance
17
This chapter describes the RF performance monitoring methods in CDMA system. These methods are per-call data gathering (from call reporting and call logging) and reference sector FER performance metrics. The metrics proposed in this chapter can be used as indicators of possible RF issues over the air-link. For more information about per-call data gathering (from call reporting and call logging), see Nortel CDMA BSS Manager Fault Management -- Log Report Generation (NN20000-104). Reference sector FER OMs at the BSC/ EBSC give the user the capability of monitoring frame error rates in a carriersector on the fundamental and supplemental channels for the forward and the reverse links, on a per RC basis.
List of OMs
17
For more information about the following OMs, see BSC OM descriptions (page 22-1).
RF performance OMs BSC OMs Reference Sector FER OM group FFCH_BadNonDataFr ames RFCH_BadNonDataF rames FSCH_BadFrames_2 X FSCH_BadFrames_8 X RSCH_BadFrames_2 X FFCH_TotalNonDataFr ames RFCH_TotalNonDataF rames FSCH_TotalFrames_2 X FSCH_TotalFrames_8 X RSCH_TotalFrames_2 X FFCH_BadDataFram es RFCH_BadDataFram es FSCH_BadFrames_4 X FSCH_BadFrames_1 6X RSCH_BadFrames_4 X FFCH_TotalDataFram es RFCH_TotalDataFram es FSCH_TotalFrames_4 X FSCH_TotalFrames_1 6X RSCH_TotalFrames_4 X
CDMA
NBSS15.0
17-2 RF performance Nortel Networks RF performance OMs (continued) BSC OMs RSCH_BadFrames_8 X RSCH_TotalFrames_8 X
RSCH_BadFrames_1 6X
RSCH_TotalFrames_1 6X
Reference sector FER metrics
17
Due to the negative impact of high Frame Error Rates (FER) on the system performance in terms of voice quality, packet data throughput, airlink capacity and call drop rate, it is essential to monitor the frame error rate in a carrier-sector on the fundamental and supplemental channels for the forward and reverse link. These metrics can be used as a means of comparison with the system target FER datafilled in the FlexiblePowerControlProfiles in the Selector Subsystem MO at the BSC. The forward link ReferenceSectorFER OMs are pegged against the reference pilot based on the counts reported in the PMRM. The PMRM is generated by the mobile when the number of errors occurring in the forward link frames equals the PMRM reporting threshold, PWR_REP_THRESH. This parameter is located in the SectorSystemParameters attribute of the AdvancedSector MO. There are three scenarios which affect the accuracy of these metrics: In good RF conditions, it is possible that this threshold is never reached and hence no PMRM is send by the mobile or the counters in the mobile rollover due to which the counts reported in the PMRM are incorrect. In bad RF conditions, there may be loss of PMRM reports. If a call is released before the threshold is reached, there will be no PMRM send.
The reverse link ReferenceSectorFER OMs are pegged against the reference pilot based on the frames received by the network. The reverse link OMs are pegged after the reverse link frame selection process at the BSC. Note: The reference sector FER metrics discussed in this section are not reliable when there are non-zero entries in the corresponding PeggingLimitationExceeded OM group. FCH formula The FER OMs are multi-ID pegging type. The OMs are pegged per EBID, per RC. Examples:
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RF performance 17-3 Copyright 2008 Nortel Networks
If there are two voice calls in a carrier-sector that utilize RC3 and RC4 configurations respectively, then two OM sets are reported, one for RC3 and one for RC4. If there are two voice calls with same configurations (for example RC3) but in different carrier-sectors, then two OM sets are reported each for RC3 in different carrier-sectors.
There is differentiation between non-packet data and packet data service groups; i.e. NonData OMs are pegged for all service options (including CSD, EVRC, 13K, SMS, Test calls etc., except for packet data) and Data OMs are pegged for packet data only. In general, the frame error rate is defined as: (Total number of frames with errors / Total number of frames reported in the PMRM) x 100 FER for FFCH non-packet data frames (per EBID, per RC basis) FFCH_BadNonDataFrames / FFCH_TotalNonDataFrames x 100 FER for FFCH packet data frames (per EBID, per RC basis) FFCH_BadDataFrames / FFCH_TotalDataFrames x 100 FER for RFCH non-packet data frames (per EBID, per RC basis) RFCH_BadNonDataFrames / RFCH_TotalNonDataFrames x 100 FER for RFCH packet data frames (per EBID, per RC basis) RFCH_BadDataFrames / RFCH_TotalDataFrames x 100 Total FER for RFCH non-packet data and packet data frames (per EBID, per RC basis) (RFCH_BadNonDataFrames + RFCH_BadDataFrames) / (RFCH_TotalNonDataFrames + RFCH_TotalDataFrames) x 100 Note: The RFCH* OMs peg for all reverse channel frame rates (Full, Half, Quarter, Eighth). Whereas the RFCH target FER parameters (FlexiblePowerControlProfiles:RxFER) are datafilled separately for different frame rates. In addition, the same frame error rate value datafilled value for RxFER is utilized for voice and data frames on the RFCH. Hence caution is advised when comparing the above 3 metrics calculated for the RFCH against the datafilled target RFCH FER parameters.
CDMA
NBSS15.0
17-4 RF performance Nortel Networks
For the forward fundamental channel, a lower bound of FER for non-packet data and packet data frames can be calculated using the ReferenceSectorFrameCount OMs. A large difference between the lower bound and the FER calculated using the total frame count reported in the PMRM would indicate that a large number of PMRMs are lost, not reported or are inaccurate due to mobile counts being rolled over. In this case, the FER counts should not be relied upon. For example, the lower bound for FFCH non-packet data frames can be calculated as follows: Total number of frames with errors / Total number of frames transmitted by the network x 100 FFCH_BadNonDataFrames / ReferenceSectorFrameCount_FFCH over all non-packet data service options x 100 SCH formula FER for FSCH frames (per EBID, per RC, per data rate basis) The metrics defined above for the FSCH can be compared with the TxFER_PktData datafilled separately for different SCH data rates in the FlexiblePowerControlProfiles in the Selector Subsystem MO. FSCH_BadFrames_<data rate> / FSCH_TotalFrames_<data rate> x 100 where the <data rate> can be {2X, 4X, 8X, 16X} FER for RSCH frames (per EBID, per RC, per data rate basis) RSCH_BadFrames_<data rate> / RSCH_TotalFrames_<data rate> x 100 where the <data rate> can be {2X, 4X, 8X, 16X} For the forward supplemental channel, a lower bound of FER for FSCH frames on a per data rate basis cannot be calculated since the ReferenceSectorFrameCount OMs are not on a data rate basis. However, a combined lower bound (over all data rates) could be calculated as follows: Total number of frames with errors / Total number of frames transmitted by the network x 100 FSCH_BadFrames_<data rate> over all data rates / ReferenceSectorFrameCount_FSCH over all service options x 100
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RF performance 17-5 Copyright 2008 Nortel Networks
Recommendations
The following table lists the target FER parameters as defined in the FlexiblePowerControlProfiles.
Target frame error rate parameters as defined in the flexible power control panel Rate set configurations Forward FCH Voice RC1, RC2 RC3,RC4,RC5 PrTxerror TxFER Data N/A TxFER_Pkt Data Reverse FCH Voice PrRxerror 1 RxFER_XX
2
17
Forward SCH Data N/A RxFER_XX

2
Reverse SCH Data N/A N/A
Data N/A TxFER_ PktData

3
1 PrRxerror is an array of frame error rates for full, half, quarter, eighth and unknown 2 There is no distinction provided between voice and data frames in the reverse link. Hence the same frame error rate datafilled value is utilized 3 The parameter is datafilled separately for different data rates XX can be Full, Half, Quarter, Eighth and Unknown N/A implies that there is no corresponding parameter defined in the FlexiblePowerControlProfiles
Radio configurations supported in the Nortel product are listed in Radio configurations supported in the Nortel system (page -5).
Radio configurations supported in the Nortel system FCH voice Forward link Reverse link RC1, RC2, RC3, RC4, RC5 RC1, RC2, RC3, RC4 FCH data RC3, RC4 RC3 SCH RC3, RC4 RC3
Since the Reference Sector FER metrics provide the call FER, the trends of these metrics can be compared against the target FER for the system. Example: For FFCH carrying packet data with RC3 configuration (FFCH_BadDataFrames / FFCH_TotalDataFrames) x 100 is the frame error rate measured for packet data on the forward fundamental channel with RC3 configuration. This can be compared against the datafilled value TxFERPktData for RC3. For FSCH carrying packet data at 16X data rate with RC3 configuration (FSCH_BadFrames_16X / FSCH_TotalFrames_16X) x 100 is the frame
17-6 RF performance Nortel Networks
error rate measured for packet data frames with 16X data rate on the forward supplemental channel with RC3 configuration. This can be compared against the datafilled value for the attribute TxFER_PktData for 16X. If the values obtained from the metrics are not close to the target FER parameters, this indicates that the minimum / maximum transmit gain and setpoint parameters may need to be adjusted. As the metrics are only indicators of possible RF issues, trending of these metrics and other field data should be considered before adjusting any parameters. Minimum/maximum transmit gain for different RCs (page -6) and Minimum/maximum setpoint parameters for different RCs (page -6) list these parameters as defined in the FlexiblePowerControlProfiles.
Minimum/maximum transmit gain for different RCs Forward gain minimum RC1, RC2 RC3, RC4, RC5 (FCH) RC3, RC4, RC5 (SCH) PTXlower TxMinGain TxMinGain Forward gain maximum PTXupper TxMaxGain TxMaxGain Reverse gain minimum N/A N/A N/A Reverse gain maximum N/A N/A N/A
Note: N/A implies that there is no corresponding parameter defined in the FlexiblePowerControlProfiles. Minimum/maximum setpoint parameters for different RCs Forward minimum setpoint RC1, RC2 RC3, RC4, RC5 (FCH) RC3, RC4, RC5 (SCH) N/A TxMinSetPoint TxMinSetPoint Forward maximum setpoint N/A TxMaxSetPoint TxMaxSetPoint Reverse minimum setpoint PRXlower RxMinSetPoint N/A Reverse maximum setpoint PRXupper RxMaxSetPoint N/A
Note: N/A implies that there is no corresponding parameter defined in the FlexiblePowerControlProfiles.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
CDMA-LTX performance
18
The CDMA-LTX product does not have a CAU. Therefore, performance measurements previously collected by the CAU are distributed throughout the BSC and documented here. In cases where a hybrid network (one with fixed and mobile service) is to be monitored, the performance measurements related to mobile subscribers still come from the MTX/CAU as described in earlier chapters.
Pegging methods
18
All CDMA-LTX OMs are either pegged on a per-subsystem or per-EBID basis. The EBID has band, frequency, and sector information embedded in it. Any group of OMs pegged on an EBID basis may be dissected and parsed for analysis on a per-band, per-frequency, or per-sector basis. OMs pegged on a per-subsystem basis are generally intended for system-wide interpretation. In either case, the system-wide interpretation is seen only after adding all instances of the OM from all subsystems or EBIDs. A handful of OMs are neither per-EBID or per-system. The V5.2 protocol OMs are pegged on a per-V5.2 interface or per-V5.2 link basis. The circuit-switched data OMs are pegged on a per-service option basis.
CDMA
NBSS15.0
18-2 CDMA-LTX performance Nortel Networks
List of OMs
18
For more information about the following OMs, see BSC OM descriptions (page 22-1).
CDMA-LTX performance OMs CDMA-LTX OMs BCM MO OMs PageResponse OriginationAttempts TCEUnavailable CallDropLossOfTraffic CallDropNetworkRelate d LAUInitiatedRelease MCTACDAFailureAllFul l RadioResourceAllocate d LandRelease MCTACDAFailureAllTi medOut TerminationSuccess OriginationSuccess WalshCodeUnavailabl e FailedCallSoftwareTim eout TerminationBlocked OriginationBlocked ForwardCapacityFull RadioLinkFailNoTraffi cChannel CallingNumberDuring Termination MCTABTSFailure MCTACDAFailureMix ed TerminationReleased RadioLinkSetupError ReverseCapacityFull CallDropRadioRelated FlashMessage MCTACDABlocked OriginationReleased
FWPAM MO OMs PageRequests Originations TermSubscriberUnavail able PageTimeOut Registrations OrigSubscriberMobility Restricted RspToPage1 UnexpectedPageResp onse TermSubscriberMobilit yRestricted RspToPage2 OrigSubscriberUnavail able
RM MO OMs RMServiceResourceNA K SCIS MO OMs

sheet 1 of 2
RMSRMTimeOut
RMNoAvailableResou rces
RMUnsupportedServi ceOption
411-2133-525
Standard
06.12
April 2008
Nortel Networks CDMA-LTX performance OMs (continued) CDMA-LTX OMs DataCallOriginationAtte mpt DataCallAbnormalRele ase DataCallOriginationCo mpleted DataCallMITRequest
CDMA-LTX performance 18-3 Copyright 2008 Nortel Networks
DataCallTerminationA ttempt DataCallMITAcknowle dge
DataCallTerminationC ompleted PortUsage
VPA MO OMs BCCAllocationRejects EFBytesReceived/ EFBytesReceivedOverfl ow EFFramesTooLong/ EFFramesTooLongOve rflow BCCDeallocationReje ct EFFramesAborted/ EFFramesAbortedOve rflow EFFramesTooShort/ EFFramesTooShortO verflow
sheet 2 of 2
BCCSuccessfulAllocat ions EFFramesBadFCS/ EFFramesBadFCSOv erflow
BCCSuccessfulDeallo cations EFFramesReceived/ EFFramesReceivedO verflow
CDMA
NBSS15.0

Call setup performance reflects how well the system is accepting new originations and terminations. There are three different times when a call may fail: 1. before the resources are allocated 2. when a LAU is moving from the paging/access channel to the traffic channel 3. after a LAU is on the traffic channel and before a Service Connect Complete message is received
18
For more information about item #1, see Call setup failure before resources are allocated (page -4). For more information about item #2, where the base station is unable to receive traffic from the LAU on the reverse traffic link, see Access failures (page -13). For more information about item #3, which is considered an access failure, see Access failures (page -13). Call setup failure before resources are allocated Call setup failures before resources are allocated are network-related call setup failures and can be classified as follows: Screened calls (LAU-initiated release, LE-side release, denials due to unsupported Service Options, etc.) Call setup failure due to lack of physical resources Call setup failure due to time-outs and software faults
Network resources are defined to be the following switching resources involved in the call: Terrestrial trunks (LE to VPA trunks) SBS selector elements BTS traffic channel elements
Another contributor to call setup failure is the non-availability of excess RF capacity. Excess RF capacity is related to the amount of power needed by both the forward and reverse links to handle a new call in the cell/sector. Goal Less than x% of all originations attempted failed due to resource shortages. Less than y% of all terminations attempted failed due to resource shortages.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Note: The variables above are defined in accordance with the service providers planned grade of service. It is improper to provision the system for 2% blocking and then set the goal for anything other than 2%. Formula Each formula presented in Call setup failures (page -5) is to be used to calculate system-wide call setup performance for originations and terminations. Each formula presented in Detailed call setup failures (page -6) is to be used to calculate system-wide detailed call setup performance. Note that in Detailed call setup failures (page -6) a distinction between an origination and a termination cannot be made. Furthermore, note that attempts refers to those calls that the system is aware of and attempts to setup resources for. For example, the system is not aware of origination call attempts that exhaust the access probes since the origination message is lost and, therefore, is not received by the BTS. Similarly, the system does not count termination call attempts if the page timed-out without receiving a response since the system will not attempt to setup any resources. Call setup failures TOTAL FAILURE RATE Percentage of call setup failures is expressed by the following ratio: (Number of call setup failures / Total calls attempted) x 100 Number of call setup failures = sum OriginationBlocked for all CDMA sectors + sum TerminationBlocked for all CDMA sectors Total calls attempted = sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors ORIGINATION SETUP FAILURE Percentage of origination setup failures is expressed by the following ratio: (Number of origination setup failures / Total originations attempted) x 100
CDMA
NBSS15.0
Number of origination setup failures = sum OriginationBlocked for all CDMA sectors Total originations attempted = sum OriginationAttempts for all CDMA sectors TERMINATION SETUP FAILURE Percentage of termination setup failures is expressed by the following ratio: (Number of termination setup failures / Total terminations attempted) x 100 Number of termination setup failures = sum TerminationBlocked for all CDMA sectors Total terminations attempted = sum PageResponse for all CDMA sectors OR Total terminations attempted = RspToPage1 + RspToPage2 Detailed call setup failures SCREENED CALLS Percentage of screened calls is expressed by the following ratio: (Number of screened calls / Total calls attempted) x 100 Number of screened calls = sum OriginationReleased for all CDMA sectors + sum TerminationReleased for all CDMA sectors + sum RMUnsupportedServiceOption for all FWSBSs + sum OrigSubscriberUnavailable for all FWPAMs + sum TermSubscriberUnavailable for all FWPAMs + sum OrigSubscriberMobilityRestricted for all FWPAMs + sum TermSubscriberMobilityRestricted for all FWPAMs Total calls attempted = sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors
411-2133-525 Standard 06.12 April 2008
Nortel Networks
CALL SETUP FAILURE DUE TO LACK OF PHYSICAL RESOURCES Percentage of call setup failures due to lack of physical resources is expressed by the following ratio: (Number of physical resource blocks / Total calls attempted) x 100 Number of physical resource blocks = sum RMNoAvailableResources for all FWSBSs + sum RadioLinkSetupError for all CDMA sectors Total calls attempted = sum OriginationAttempts for all CDMA sectors+ sum PageResponse for all CDMA sectors CALL SETUP FAILURE DUE TO LACK OF TCEs Percentage of call setup failures (in non MCTA enabled sectors) due to lack of traffic channel elements is expressed by the following ratio: (Number of lack of TCEs blocks / Total calls attempted) x 100 Number of lack of TCEs blocks = sum TCEUnavailable for all CDMA sectors Total calls attempted = sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors CALL SETUP FAILURE DUE TO LACK OF WALSH CODES Percentage of call setup failures due to lack of Walsh Codes is expressed by the following ratio: (Number of lack of Walsh Codes blocks / Total calls attempted) x 100 Number of lack of Walsh Codes blocks = sum WalshCodeUnavailable for all CDMA sectors Total calls attempted =
CDMA
NBSS15.0
sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors CALL SETUP FAILURES DUE TO LACK OF FORWARD CAPACITY Percentage of call setup failures due to lack of forward capacity is expressed by the following ratio: (Number of lack of fwd. capacity blocks / Total calls attempted) x 100 Number of lack of fwd. capacity blocks = sum ForwardCapacityFull for all CDMA sectors Total calls attempted = sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors CALL SETUP FAILURES DUE TO BTS TIMEOUTS Note: This formula is only valid for non-MCTA cells. While the formula may serve as an approximation of behavior in an MCTA cell, there is currently no method for accurately measuring this metric in an MCTA cell. Note: The percentage of call setup failures due to BTS time-outs is expressed by the following ratio: (Number of blocks due to BTS time-outs / Total calls attempted) x 100 Number of blocks due to BTS time-outs = sum RadioLinkSetupError for all CDMAsectors sum TCEUnavailable for all sectors sum WalshCodeUnavailable for all sectors sum ForwardCapacityFull for all sectors sum ReverseCapacityFull for all sectors Total calls attempted =
411-2133-525
Standard
06.12
April 2008
Nortel Networks
sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors CALL SETUP FAILURE DUE TO BSC TIMEOUTS AND SOFTWARE FAULTS Percentage of call setup failures due to BSC time-outs and software faults is expressed by the following ratio: (Number of BSC time-outs and software faults / Total calls attempted) x 100 Number of BSC time-outs and software faults = sum RMSRMTimeOut for all FWSBSs + sum RMSRMServiceResourceNAK for all FWSBSs + sum FailedCallSoftwareTimeout for all CDMA sectors Total calls attempted = sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors RF ACCESS FAILURES Percentage of RF access failures is expressed by the following ratio: (Number of RF access failures / Total calls attempted) x 100 Number of RF access failures = sum RadioLinkFailNoTrafficChannel for all sectors Total calls attempted = sum OriginationAttempts for all CDMA sectors + sum PageResponse for all CDMA sectors Validation Since a call setup may span the OM period, a slight discrepancy may be possible.
CDMA
NBSS15.0
Originations and terminations One validation formula for call setup performance is to sum all successful originations and terminations, all origination and termination setup failures, all of the originations that are aborted normally, all originations and terminations that are released during setup by the originating party, and all of the originations and terminations that fail due to no Service Connect Complete message. These should be summed for all sectors and nodes with system-wide pegs. That number should equal the number of origination and termination attempts. The formula can be summarized as shown in the following table.
Validation of originations and terminations Attempts OriginationAttempts PageResponse = Successes OriginationSuccess TerminationSucces + Non-successes OriginationBlocked TerminationBlocked OriginationReleased TerminationReleased RadioLinkFailNoTrafficChannel RMUnsupportedServiceOption
Since the FWPAM in the CN does some screening of origination attempts, the sum of originations seen by the FWPAM should be equal to the sum of originations denied by the FWPAM plus the originations seen by the BCM, as shown in the following table.
Sum of originations seen by FWPAM Originations = OrigSubscriberUnavailable + OrigSubscriberMobilityRestricted + OriginationAttempts PageRequests = PageTimeOut + PageResponse
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Miscellaneous All of the blocking OMs can be summed together and should equal the sum of the all the failure reasons: OriginationBlocked [all sectors] + TerminationBlocked [for all sectors] = RMNoAvailableResources [for all FWSBSs] + RMServiceResourceNAK [for all FWSBSs] + RMSRMTimeOut [for all FWSBSs] + RadioLinkSetupError [for all sectors] + FailedCallSoftwareTimeout [for all sectors] Since RadioLinkSetupError is pegged when the BTS responds with a failure code or does not respond at all. Therefore for all sectors, RadioLinkSetupError >= TCEUnavailable + WalshCodeUnavailable + ForwardCapacityFull + MCTACDABlocked Recommendations Overall, the call setup failure percentages for originations and terminations should be very close to each other since there is no special processing done to prioritize one over the other. The following sections list OMs that can indicate the need for an adjustment and at least one possible adjustment. Originations OriginationBlocked Occurrences of this OM indicate that origination call setups are failing due to lack of resource reasons. When this OM is pegged, the OMs below describe what should be reviewed. RadioLinkSetupError Occurrences of this OM indicate that BTS resources may be causing call setups to fail. To ascertain the reason consult the TCEUnavailable, WalshCodeUnavailable, and ForwardCapacityFull OMs. RadioLinkSetupFailure is also pegged if any of the software entities on the BTS do not respond to resource requests during call setup.
CDMA
NBSS15.0
TCEUnavailable Occurrences of this OM indicate that the BTS channel elements may be under-provisioned. The lack of traffic channel elements (TCEs) can be verified by consulting the BTSs Advanced Frequency Assignment Managed Objects (MO) TCEUtilMaximum data, or the soft handoff percentage data (see section 5.1.2.6 for more information). If the number of TCEs in use is close to the maximum number, or if there is excessive soft handoff, another channel card should be provisioned at the BTS. ForwardCapacityFull Occurrences of this OM indicate that the BTS is running out of capacity on the forward link. Deployment of additional carriers or six sectors should be considered. FailedCallSoftwareTimeout Occurrences of this OM indicate that call setup failed due to timeouts between software entities. The only recommendation here is to check SBS and/or CN CPU occupancy and verify that it is within tolerable levels. This type of timeout event is an error condition and should not happen. RMNoAvailableResources or RMUnsupportedServiceOption An occurrence of either indicates that a call setup failed due to SBS resource shortage problems. If that is the case, more SBS selector elements need to be provisioned or be brought in-service. Again, for information on provisioning, please refer to the CDMA Deployment and Provisioning Guide. These OMs may indicate that SBSs have resource shortages, for example: an out-ofservice selector card or selector elements or hung resources. Investigation of these issues should be done via the BSSM/C-EMSs interface. RMSRMTimeOut An occurrence of this OM indicates that a call setup failed due to one of two reasons: 1) the SBS/SRM that the RMU is requesting resources from is heavily loaded with respect to CPU cycles or 2) there is a communication problem between in the SBS. This type of timeout event is an error condition and should not happen. RMUnsupportedServiceOption Occurrences of this OM indicate that LAUs are accessing the system and requesting unsupported services. This OM gives the service provider a mechanism to track the necessity of providing new service options and the types of service options it should consider providing.
411-2133-525 Standard 06.12 April 2008
Nortel Networks
Terminations TerminationBlocked Occurrences of this OM indicate that termination call setups are failing. When this OM is pegged, the OMs described below should be reviewed. RadioLinkSetupError For more information, see Originations (page -11). FailedCallSoftwareTimeout For more information, see Originations (page -11). RMNoAvailableResources or RMUnsupportedServiceOption For more information, see Originations (page -11). RMSRMTimeOut For more information, see Originations (page -11). RMUnsupportedServiceOption For more information, see Originations (page -11). Access failures An access failure occurs when call setup resources are properly allocated an initialized, but no Service Connect Complete message is received from the LAU. The subscriber cant distinguish access failures from other call setup failures, but they are different problems to the service provider. Access failures indicate possible RF engineering issues while other call setup failures indicate possible provisioning issues. RadioLinkFailNoTrafficChannel This OM is pegged when a LAU doesnt successfully arrive on the traffic channel due to RF problems. This peg could indicate inadequate coverage, interference issues, slow handoff, or simply an RF fade at a vulnerable time in the call setup. The BCM pegs this OM on a per-EBID basis.
18
Dropped calls include only those calls which were successfully set up (arrived on the traffic channel) and were disconnected for any reason other than one of the parties in the call went on hook.
CDMA
NBSS15.0
Goal Less than x% of established calls should drop while inside the V5.2 CDMA coverage area. Formula This section defines call drop performance for fixed applications only. Note 1: These performance metrics should be done over several OM reporting cycles. This is due to the fact that the number of established calls may fluctuate over time; the same fluctuation could be seen for dropped calls. These fluctuations would cause each metric to vary significantly from one reporting period to the next. An example might be that at 5:01 PM, the number of attempted calls jumps significantly, while the number of dropped calls remains relatively constant for the first reporting period (assuming that rush hour traffic peaks at 6:00, at which time call drops due to overloading or high occupancy start to increase). Note 2: These formulas dont take into account the number of soft handoffs into or out of the sector. In other words, each formula only takes into account the number of calls that start in a cell and does not take into account the amount of traffic that the cell is actually serving. This could cause a problem to be hidden (when numerous handoffs out of a cell occur) or could falsely identify a problem (when numerous handoffs into the cell occur) because the relative amount of traffic being served is not taken into consideration. The percentage of established calls that are dropped are expressed by the following ratio: (Number of dropped calls / Number of established calls) x 100 Number of dropped calls = sum CallDropRadioRelated for all sectors Note 1: The cells referred to above means that the service provider must identify which cells service fixed applications (ie., LAUs) and sum the CallDropRadioRelated OM from those sectors. Note 2: The CallDropNetworkRelated could be added into the number of dropped calls, but most occurrences of this OM are error cases and should not happen. Number of established calls = sum OriginationSuccess for all sectors + sum TerminationSuccess for all sectors
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Validation Validation not precise for two reasons: 1. Calls set up during one reporting period might not drop until the next reporting period. 2. Calls set up in one cell/sector may drop in a different cell/sector. Recommendations CallDropRadioRelated Any time this OM is pegged, one possible course of action is to investigate the pilot database to ensure that all nearby pilots have been datafilled for the cell/sector in which the call was dropped. The pilot database may also be checked to verify proper configuration of the soft handoff parameters such as T_ADD, T_DROP, T_COMP, and T_TDROP. Neighbor lists should also be checked as missing neighbors are a common source of interference. RF testing and optimization is also appropriate. Contact Nortel Field Support. CallDropNetworkRelated Occurrences of this OM can indicate that necessary call processing resources are not in service or can indicate that there are state mismatches between the FWSBS and other entities (BTS). These occurrences are error conditions and should not happen. Contact Nortel Field Support.
Paging performance
18
This section discusses the paging performance measurement. It discusses the likelihood of receiving a page response given a page attempt. Also discussed is the effectiveness of an initial page, a retry page, and retry-paging. Goal Attempts to page a CDMA mobile should result in a page response x% of the time. Formula Retry paging These formulas apply only to deployments where page retry is used. Also, these formulas are not applicable when more than one page retry per termination attempt is implemented. Note page retry paging is mutually exclusive from quick repeat paging. Overall paging performance represents the percentage of terminations attempts that result in a successful page (ie: a page response). This formula is the most important paging performance formula. This essentially reflects the performance improvement that the page retry scheme offers over a single page attempt. The overall paging success rate should be higher than the initial page success rate and the page retry success rate.
CDMA
NBSS15.0
Retry Paging Success Rate = (number of page responses/number of termination attempts) x 100 number of page responses = RspToPage1+ RspToPage2 number of termination attempts = number of initial page attempts = 1/2(PageRequests + RspToPage1) The denominator in the above equation is not obvious. It is derived as follows. It is easiest to derive the number of initial page attempts by deriving the number of page retires and subtracting that from the total number of pages. The derivation begins with the total number of page requests, PageRequests. Subtracting RspToPage1 from PageRequests eliminates the number of times a retry was not attempted. Therefore PageRequests RspToPage1 yields the number indicating the total number of pages sent during call attempts which resulted in a page retry. Clearly, half of the pages sent during call attempts resulting in a page retry are the retry pages. Note: The other half does not equate to the total number of initial pages since initial pages also occur call attempts that dont result in a retry. Therefore, the total number of retry pages sent is 1/2(PageRequests RspToPage1). The total number of initial pages sent is simply the total number of pages minus the total number of retry pages, or 1/2 (PageRequests + RspToPage1). Note that the plus sign isnt a mistake. Quick repeat paging This formula is applicable only to networks with quick repeat paging. Note quick repeat paging is mutually exclusive from page retry paging. Two quickrepeated pages constitute one page attempt since each page attempt always results in two pages. The PageRequests OM gets pegged twice during a such an attempt. The RspToPageX OMs are invalid when quick-repeat paging is turned on. Note that the overall paging success rate for quick-repeat paging is different from that of retry paging. Quick Repeat Paging Success Rate = (number of page responses/number of termination attempts)
411-2133-525
Standard
06.12
April 2008
Nortel Networks
x 100 number of page responses = PageResponse number of termination attempts = 1/2*PageRequests Limitations The CDMA-LTX Paging and Access Manager (FWPAM) does not track registered LAUs. LAUs are paged for each termination attempt regardless of whether or not the LAUs are registered (or powered off). When a LAU isnt registered and a termination attempt takes place, PageRequests will get pegged twice while the page response OMs will never be pegged. This scenario artificially lowers the results measured by paging performance OM formulas.
MCTA performance
MCTA performance reflects how well the system is allocating resources across multiple frequencies for new originations and terminations. The performance is determined on a per frequency basis. MCTA OMs do not replace the normal call processing OMs but are pegged in addition to the normal call processing OMs.
18
In the CDMA-LTX, MCTA comes into effect only during call setup for originations and terminations. This section is only concerned with the performance for fixed applications. For more information about MCTA performance for mobile applications, see MCTA performance (page 14-1). Goal Less than x% of all MCTA originations (originations in sectors that have MCTA enabled) attempted failed due to resource shortages. Less than y% of all MCTA terminations (terminations to sectors that have MCTA enabled) attempted failed due to resource shortages. Note: The variables above (x and y) are defined in accordance with the service providers planned grade of service. It is improper to provision the system (example: x + y) for 2% blocking and then set the goal for anything other than 2%. Formula MCTA frequency selection failure An MCTA frequency selection failure occurs when MCTA cant select a frequency because all of them either have no resources or have not responded. The percentage of MCTA frequency selection failure represents the percentage of call attempts which were blocked due to MCTA frequency selection failure.
CDMA
NBSS15.0
(Number of MCTA frequency selection failures / Total MCTA calls attempted) x 100 Number of MCTA frequency selection failures = sum MCTACDABlocked for all FWSBSs Total MCTA calls attempted = sum OriginationAttempts for all MCTA sectors + sum PageResponse for all MCTA sectors
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Note: MCTACDABlocked is a system-wide peg. The information above may be obtained on a per-sector level, if needed, by replacing the numerator with MCTACDAFailureAllTimedOut + MCTACDAFailureAllFull + MCTACDAFailureMixed. MCTA frequency resource allocation failures (per frequency) The percentage of MCTA frequency resource allocation failures represents the percentage of call attempts where a MCTA did not choose a particular frequency due to a resource shortage or timeout. These calls may or may not have resulted in call setup failure. In the formulas below, let fi represent the frequency that MCTA did not choose. (Number of MCTA fi resource allocation failures / Total MCTA calls attempted) x 100 Number of MCTA frequency resource allocation failures = sum MCTACDABTSFailure for fi over all MCTA sectors + sum MCTACDAFailureAllTimedOut for all fs over all MCTA sectors + sum MCTACDAFailureAllFull for all fs over all MCTA sectors + sum MCTACDAFailureMixed for all fs over all MCTA sectors Total MCTA calls attempted = sum OriginationAttempts for all MCTA sectors + sum PageResponse for all MCTA sectors Note: The MCTA frequency resource allocation failures represented by the first term in the numerator of the above formula do not lead to overall MCTA frequency selection failure. The resource allocation failures represented by the remaining terms in the numerator of the above formula do lead to overall MCTA frequency selection failure. MCTA frequency related call setup failures (per frequency) This formula represents the percentage of calls where a MCTA-selected frequency, fi, failed call setup due to a resource shortage or timeout. Note this is not expressed as a percentage of overall call attempts, but as a percentage of all calls among which MCTA successfully picked a frequency for a setup attempt. This formula reflects how many times the selected frequency blocked a call.
The percentage of MCTA call setup failures after a frequency has been selected is expressed by the formula below. The numerator isnt obvious. The numerator is the number of times call setup failed on fi after MCTA successfully selected fi. This is equivalent to the total number of call setup failures on fi (RadioLinkSetupError) minus the number of times RadioLinkSetupError was pegged as a result of MCTA frequency selection failure. The denominator is the numerator + the number of times call setup succeeded on fi after MCTA selected fi. (Number of MCTA call setup failures on fi / Total number of MCTA call setups attempted on fi) x 100 Number of MCTA call setup failures on fi = sum RadioLinkSetupError for fi on all MCTA sectors (sum MCTACDAFailureAllTimedOut for fi on all MCTA sectors + sum MCTACDAFailureAllFull for fi on all MCTA sectors + sum MCTACDAFailureMixed for fi on all MCTA sectors) Total call setups attempted when MCTA selected fi = sum RadioLinkSetupError for fi on all MCTA sectors (sum MCTACDAFailureAllTimedOut for fi on all MCTA sectors + sum MCTACDAFailureAllFull for fi on all MCTA sectors + sum MCTACDAFailureMixed for fi on all MCTA sectors) + sum RadioResourceAllocated for fi on all MCTA sectors Note: Some screened calls (i.e call releases that occur shortly after a frequency has been selected) are included in the above formula as call setup failures and thats because they could not be separated out, and since they are expected to be negligible, the formula is a good measure of setup failure rate (after frequency selection). MCTA call setup failures due to lack of resources (per frequency) This is a subset of what MCTA frequency related call setup failures (per frequency) (page -19) measures. The percentage of MCTA call setup failures due to lack of resources (timeouts not included) after a frequency has been selected is expressed by the following:
411-2133-525
Standard
06.12
April 2008
Nortel Networks
(Number of MCTA call setup failures due to lack of resources / Total number of MCTA call setups attempted) x 100 Number of MCTA call setup failures on fi due to lack of resources = sum TCEUnavailable for fi on all MCTA sectors + sum WalshCodeUnavailable for fi on all MCTA sectors + sum ForwardCapacityFull for fi on all MCTA sectors + sum ReverseCapacityFull for fi on all MCTA sectors Total call setups attempted when MCTA selected fi = sum RadioLinkSetupError for fi on all MCTA sectors (sum MCTACDAFailureAllTimedOut for fi on all MCTA sectors + sum MCTACDAFailureAllFull for fi on all MCTA sectors + sum MCTACDAFailureMixed for fi on all MCTA sectors) + sum RadioResourceAllocated for fi on all MCTA sectors MCTA call setup failures due to timeouts (per frequency) This is a subset of what MCTA frequency related call setup failures (per frequency) (page -19) measures. The percentage of MCTA call setup failures due to timeouts (lack of resource scenarios not included) after a frequency has been selected is expressed by subtracting the MCTA call setup failures due to lack of resources (per frequency) (page -20) formula from the MCTA frequency related call setup failures (per frequency) (page -19) formula. Detailed MCTA call setup failures due to lack of resources (per frequency) MCTA call setup failure due to lack of TCEs Percentage of MCTA call setup failures due to lack of traffic channel elements after a frequency has been selected is expressed by the following ratio: (Number of lack of TCEs blocks / Total calls attempted) x 100 Number of lack of TCEs blocks = sum TCEUnavailable for fi on all MCTA sectors Total call setups attempted when MCTA selected fi =
sum RadioLinkSetupError for fi on all MCTA sectors (sum MCTACDAFailureAllTimedOut for fi on all MCTA sectors + sum MCTACDAFailureAllFull for fi on all MCTA sectors + sum MCTACDAFailureMixed for fi on all MCTA sectors) + sum RadioResourceAllocated for fi on all MCTA sectors MCTA call setup failure due to lack of Walsh codes Percentage of MCTA call setup failures due to lack of Walsh codes after a frequency has been selected is expressed by the following ratio: (Number of lack of Walsh Code blocks / Total calls attempted) x 100 Number of lack of Walsh Code blocks = sum WalshCodeUnavailable for fi on all MCTA sectors
Total call setups attempted when MCTA selected fi = sum RadioLinkSetupError for fi on all MCTA sectors (sum MCTACDAFailureAllTimedOut for fi on all MCTA sectors + sum MCTACDAFailureAllFull for fi on all MCTA sectors + sum MCTACDAFailureMixed for fi on all MCTA sectors) + sum RadioResourceAllocated for fi on all MCTA sectors MCTA call setup failure due to lack of fwd capacity Percentage of MCTA call setup failures due to lack of forward link capacity after a frequency has been selected is expressed by the following ratio: (Number of lack of fwd. capacity blocks / Total calls attempted) x 100 Number of lack of fwd. capacity blocks = sum ForwardCapacityFull for fi on all MCTA sectors Total call setups attempted when MCTA selected fi =
411-2133-525
Standard
06.12
April 2008
Nortel Networks
sum RadioLinkSetupError for fi on all MCTA sectors (sum MCTACDAFailureAllTimedOut for fi on all MCTA sectors + sum MCTACDAFailureAllFull for fi on all MCTA sectors + sum MCTACDAFailureMixed for fi on all MCTA sectors) + sum RadioResourceAllocated for fi on all MCTA sectors MCTA RF access failure (per frequency) This formula determines the MCTA RF access failures after the MCTA frequency has been selected and resources are successfully setup on the selected frequency. Percentage of MCTA RF access failures, after a frequency has been selected and resources are successfully setup on the selected frequency, is expressed by the following ratio: (Number of MCTA RF access failures / Total calls attempted) x 100 Number of MCTA RF access failures = sum RadioLinkFailNoTrafficChannel for fi on all MCTA sectors Total call setups attempted when MCTA selected fi = sum RadioLinkSetupError for fi on all MCTA sectors (sum MCTACDAFailureAllTimedOut for fi on all MCTA sectors + sum MCTACDAFailureAllFull for fi on all MCTA sectors + sum MCTACDAFailureMixed for fi on all MCTA sectors) + sum RadioResourceAllocated for fi on all MCTA sectors Validation Only the MCTA failure reason OMs may be validated: MCTACDABlocked = MCTACDAFailureAllTimedOut + MCTACDAFailureAllFull + MCTACDAFailureMixed Recommendations Overall, the MCTA call setup failure percentages for each of the two types of call setups should be very close to each other since there is no special
CDMA
NBSS15.0
processing done to prioritize resources. The following sections list OMs that can indicate the need for an adjustment. TCEUnavailable Refer to CAUNOTCE in Call setup performance (page 2-1). WalshCodeUnavailable Refer to CAUNOWCD in Call setup performance (page 2-1). ForwardCapacityFull Refer to CAUFWCAP in Call setup performance (page 2-1). ReverseCapacityFull Refer to CAURECAP in Call setup performance (page 2-1). MCTACDAFailureAllFull or MCTACDAFailureMixed Occurrences of this OM indicate that the BTS is running out of capacity on the forward link. Deployment of additional carriers or six sectors should be considered. If cells are configured for segregated resources between LAUs and mobiles, shared resources or restricted mobility should also be considered since sharing buys increased capacity associated with pooling gain. MCTACDAFailureAllTimedOut Occurrences of this OM indicate that the BTSC card is running out of CPU capacity. It could also indicate additional load on the SBSC card. RadioLinkFailNoTrafficChannel Refer to CAUERLFL in Call setup performance (page 2-1). MCTABTSFailure Occurrences of this OM indicate that the BTSC card for a particular frequency is running out of CPU capacity or the BTS card for a particular frequency is running out of forward capacity. If there isnt a problem with the BTS, this OM indicates a trend that will eventually lead to MCTACDAFailureAllFull, MCTACDAFailureMixed, or MCTACDAFailureAllTimedOut (example: blocked calls).
V5.2 protocol adaptor performance
18
The following OMs are provided as required by the V5.2 specification requirements. These OMs provide information to monitor load distribution and general V5.2 protocol operation: BCCSuccessfulAllocations PortUsage BCCAllocationRejects
411-2133-525 Standard 06.12 April 2008
Nortel Networks
BCCSuccessfulDeallocations BCCDeallocationReject EFBytesReceived/EFBytesReceivedOverflow EFFramesReceived/EFFramesReceivedOverflow EFFramesAborted/EFFramesAbortedOverflow EFFramesBadFCS/EFFramesBadFCSOverflow EFFramesTooShort/EFFramesTooShortOverflow EFFramesTooLong/EFFramesTooLongOverflow
Circuit switched data performance
18
CDMA Circuit Switched Data (CSD) feature uses an InterWorking Function (IWF) to enable circuit switched networks to provide circuit switched and packet switched data as well as fax services to the wireless user. The IWF is a 3Com product based on 3Coms Total Control Wireless Access System. The following CDMA service options are supported: CDMA_ASYNC_96 - CDMA Asynchronous Data Rate Set 1 Goal Each of the goals defined are for each of the services options supported. For service option X attempts to set up a call for CSD originations should fail less than y% of the time. For service option X attempts to set up a call for CSD terminations should fail less than z% of the time. CDMA_ASYNC_144 - CDMA Asynchronous Data Rate Set 2 CDMA_G3FAX_96 - CDMA group 3 Class 2.0 Digital Fax Rate Set 1 CDMA_G3FAX_144 - CDMA group 3 Class 2.0 Digital Fax Rate Set 1 CDMA_AFAX_96 - CDMA Analog Fax Rate Set 1 CDMA_AFAX_144 - CDMA Analog Fax Rate Set 2
Formula CSD IWF call setup failures my be expressed as: (Number of IWF CSD data-call setup failures / Total CSD data-call setup attempted) x 100 Number of IWF CSD data-call setup failures =
sum DataCallAbnormalRelease for all service options Total CSD data-call setup attempted = sum DataCallOriginationAttempt for all service options + sum DataCallTerminationAttempt for all service options
411-2133-525
Standard
06.12
April 2008
Nortel Networks
19
CDMA
NBSS15.0
19-2 Nortel Networks
411-2133-525
Standard
06.12
April 2008
Nortel Networks
OTAPA performance 20-3 Copyright 2008 Nortel Networks
OTAPA performance
20
The CDMA Over-The-Air Parameter Administration (OTAPA) feature enables the network service provider to program the Mobile Stations Number Assignment Module (NAM) parameters (e.g. IMSI, SID, NID, etc.) and the CDMA Preferred Roaming List without any action on the part of mobile subscribers (MS). These parameters control the wireless network usage by the MS. OTAPA allows administrating these parameters without the involvement of the mobile subscriber. This chapter provides a list of metrics to track the performance of OTAPA.
Goal

20
Less than x% of attempts to page a CDMA mobile for an OTAPA session should result in failure. Less than y% of the attempts to setup resources for an OTAPA session should result in failure. Less than z% of the attempts to send data bursts during an OTAPA session should result in failure.
List of OMs
20
OTAPA performance OMs MSC OMs OTASYS OMs group COTPATPP COTPABRT COTPDSUC COTPREQF COTPATPT COTPPGRS COTPDFLR COTPRREQ COTPUNSP COTAPREL COTAPREQ COTAPNOT COTPNALC COTPDATP COTPREQS
Formulas
Overall page request failures for OTAPA sessions ((COTPATPP - COTPPGRS) / COTPATPP) x 100 OTAPA sessions setup failure rate due to unsupported service option by the mobiles (COTPUNSP / COTPATPP) x 100
20
CDMA
NBSS15.0
20-4 OTAPA performance Nortel Networks
Overall OTAPA sessions setup failure rate (COTPNALC / COTPATPT) x 100 Abort rate for OTAPA sessions (COTPABRT / COTPATPT) x 100 OTAPA data bursts delivery failure rate (COTPDFLR / COTPDATP) x 100 Validation Attempts = Unsupported + Not Allocated + Aborted + Released COTPATPT = OCTPUNSP + COTPNALC + COTPABRT + COTPREL Delivery Attempts = Delivery Successes + Delivery Failures COTPDATP = COTDSUC + COTPDFLR
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Call flow diagrams with OMs
20
This chapter is intended to provide a general overview of when Operational Measurements are pegged during call setups or handoffs. The call setups and handoff scenarios covered in this chapter are Mobile origination voice calls, Mobile terminated voice calls, Mobile Initiated Packet Data calls, Network Originated Supplemental channel setup, soft handoffs and hard handoffs. The call flow diagrams with OMs cover most commonly used OMs which can provide a trend regarding network performance rather than providing much more detailed information. Please refer to individual chapters for OM groups which can provide in-depth information.
CDMA
NBSS15.0
2G/3G voice call setup flow diagram with OMs

NOTE: For 2G voice call setup, the OMs stated in this section belong to OM groups - CAUCPSCT, CAUCPFRQ,
CAUC-SYS and CAURM (with 2G index); and the Advanced Sector MO at the BTS. For 3G voice call setup, the OMs stated in this section belong to CAUSCT3V, CAUFRQ3V, CAURM (with 3G index); and the Advanced Sector MO at the BTS.
20
Origination Termination
20-2 2G/3G voice call setup flow diagram with OMs Nortel Networks
411-2133-525 Standard 06.12 April 2008
Mobile
Origination
BTS
BSC
MTX
OMs pegged
Origination Indication Base Station Ack
CAUOATTS MISCFLT CAUORIGS MCTORIGS & in case of redirection by MCTA: MCTPRSO
Page Request
CDPG1REQ CDPG2REQ CDPG3REQ CAUPGREQ
Page Page Response Base Station Ack Page Response
CAUPGRES MISCFLT MCTPGRES & in case of redirection by MCTA: MCTPRST CDPG1RES CDPG2RES CDPG3RES CDMAPRS2
411-2133-525 Standard 06.12 April 2008
2G/3G voice call setup flow diagram with OMs (RMU is BSC resource manager) Mobile BTS SBS MTX OMs pegged
Attempts: RMUIARV RMURARV
Resource Allocation Request BSC Resource Allocation Resource Allocation Response Time out
CAU$BLKS No Resources: RMUIANRV RMURANRV
Failures: RMUIOENV RMURAOEV
Time out: RMUIATOV RMURATOV
$ = T for Mobile Terminated calls, O for Mobile Originated
Note: Similar OMs from BSCRM OM group peg for a Data Delivery Service (SMS, OTAPA, LCS) call.
411-2133-525 Standard 06.12 April 2008
2G/3G voice call setup flow diagram with OMs (NRM is BSC/EBSC resource manager) Mobile BTS BSC (CNFP)
MTX
OMs pegged
Resource Allocation Request BSC Resource Allocation Resource Allocation Response Time out
Attempts: NRMARV CAU$BLKS No Resources: NRMANRV
Failures: NRMOEV NRMOLRV
Time out: NRMIATOV NRMRATOV
$ = T for Mobile Terminated calls, O for Mobile Originated
Note: Similar OMs from EBSCRM OM group peg for a Data Delivery Service (SMS, OTAPA, LCS) call.
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
Setup Radio Link
MTX
OMs pegged
In Case of Failure, MCTAREQF and one of the following OMs: MCTALLTO MCTALLFU (MCTAMIXF & MCTARQFN) In Case of Success: MCT$ATTS and in some cases: MRETATTS MCTAREQN MCTAREQT
BTS OMs
2G_MctaFull 3GV_MctaFull 3GD_MctaFull
CAU$BLKS CAUERSFL
& in some cases:
Carrier Selection via MCTA.
MPRBLKS NMCTBLKS
In Case of Success: FchOriginationNonBlockin g2G FchOriginationNonBlockin g3GVoice FchOriginationNonBlockin g3GDowngrade2G FchOriginationNonBlockin g3gDowngrade2gNoAcn FchOriginationNonBlockin g3gDowngrade2gNoBcn In Case of Failure, one of the following arrays get pegged: BlockedFchOriginations2G BlockedFchOriginations3G Voice
BTS Resource Request BTS Resource Response
In Case of Failure, one of the following OMs:
CAUNOTCE CAUNOWCD CAUFWCAP SCTBTSBK CAUNOFOF

In Case of Failure, one of the following OMs:
CAU$BLKS CAUERSFL MCTERSFL

& in some cases:
$ = T for Mobile Terminated calls, O for Mobile Originated calls
MCTNOTCE MCTNOWCD MCTFWCAP MCTBTSBK MCTNOFOF
MRETBLKS MPRBLKS NMCTBLKS
Nortel Networks
Mobile
BTS
BSC
MTX
OMs pegged
NULL TRAFFIC DATA
(Extended) Channel Assignment
In cases of redirection by MCTA:
MCTPRRO
for origination and -
MCTPRRT
2G/3G voice call setup flow diagram with OMs 20-6 Copyright 2008 Nortel Networks
for termination -
Preamble
NULL TRAFFIC DATA
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
MTX
OMs pegged
Base Station Acknowledgment Mobile Acknowledgment

In case of Failure: CAUERLFL MCTERLFL
& in some cases:
Radio Link Setup Rsp
MRETFL MPRFL
Service Connect Req Service Connect Message

In case of RF Failure: CAUEDLOT CAUERLFL MCTERLFL
& in some cases:
Service Connect Completion Service Connect Rsp
MRETFL MPRFL In case of non-RF Failure: NORFSEFL In case of Success: CAU$SUCC MCT$SUCC
& in some cases:
MRETSUCC MPRSUCC
Nortel Networks
Mobile
BTS
BSC
SAT Present
MTX
If the mobile originated the call, the call setup will finish with a SAT Present indication from the BSC to the MTX.
Alert with information

2G/3G voice call setup flow diagram with OMs 20-8 Copyright 2008 Nortel Networks
Connect
Answer
If the mobile is receiving the call, the mobile will alert the user of the incoming call. The user, if he or she desires, will then connect the call. The call setup finishes with an Answer indication from the BSC to the MTX.
20-9 Voice call setup flow diagram with OMs- CSVS and SBS subsystems Nortel Networks Copyright 2008 Nortel Networks
411-2133-525 Standard 06.12 April 2008
Voice call setup flow diagram with OMs- CSVS and SBS subsystems
The OMs in the call flow below are pegged for Call Originations, Terminations and HardHandoffs. All the OMs below are pegged at the MTX and are in the EBPBCPOM OM group
Mobile
Origination/Page Response
BTS
EBSC
Origination/ Page ResponseIndication
MTX
OMs pegged
Based on the mobile requested SO: ATEVRCB ATEVRC ATEB13K ATI13K ATNIL Successful resource allocation on the SBS: ESBSRASU on the CSVS ECSVRASU Service option unsupported at NRM: NRMUNSO
Base Station Ack Resource Allocation Request Resource Allocation Response
In case of failure CAU$BLKS
Call Setup Request
Call setup Response
Call failure on the SBS: ESBESWFL on the CSVS ECSESWFL
411-2133-525 Standard 06.12 April 2008
Voice call setup flow diagram with OMs- CSVS and SBS subsystems
Mobile
BTS
BSC
MTX
OMs pegged
In case of RF failure on the SBS: ESBERLFL on the CSVS ECSERLFL In case of non-RF failure on the SBS: ESBENRSFL on the CSVS: ECSNRSFL In case of successful call setup on the SBS: ESBSCSS on the CSVS: ECSVCSS
Radio link Setup Request
Radio Link setup Response
CAU$RLFL
Service connect request Service connect message
Service connect complete message Service Connect Response
CAU$SUCC
Call successfully established
Call drop due to RF reasons on the SBS: ESBDROPR on the CSVS ECSDROPR Call drop due to network related failures on CSVS: SEFLNWK, SEFL2PVS
411-2133-525 Standard 06.12 April 2008
NRM voice resource allocation flow diagram with OMs CAU NRM
AllocationRequestReceived
Resource Allocation Request
Resource Allocation Request Processing Phase
AllocationRequestRejectedDueToOverload AllocationRequestDenied AllocationRequestAccepted AllocationRequestUnavailable
Resource Availability Check Phase
ResourceCheckAttempts ResourceCheckUnavailable ResourceCheckAvailable
Platform Selection Phase
SelectionAttemptsOnPrimaryPlatform SelectionSuccessOnPrimaryPlatform SelectionAttemptsOnSecondaryPlatform SelectionSuccessOnSecondaryPlatform
Note: This call flow diagram is also applicable to other service types such as SMS, OTAPA, LCS, Loopback, and Markov services.
411-2133-525 Standard 06.12 April 2008
NRM voice resource allocation flow diagram with OMs (continued) CAU NRM CSRM/SDRM SBSRM
SelectedEBSC_AllocationAttempts AlternateEBSC_AllocationAttempts Resource Allocation Request Interaction with Resource Manager Phase (CSVS/ CPDS) Resource Allocation Response
SelectedEBSC_AllocationSuccesses AlternateEBSC_AllocationSuccesses SelectedEBSC_MG_AllocationFailures AlternateEBSC_MG_AllocationFailures SelectedEBSC_SDU_AllocationFailures AlternateEBSC_SDU_AllocationFailures
Resource Allocation Request Interaction with Resource Manager Phase (SBS)
SelectedBSC_AllocationAttempts AlternateBSC_AllocationAttempts SelectedBSC_AllocationSuccesses AlternateBSC_AllocationSuccesses SelectedBSC_AllocationFailures AlternateBSC_AllocationFailures
Resource Allocation Response AllocationRequestSuccesses AllocationRequestFailures Resource Allocation Response
411-2133-525 Standard 06.12 April 2008
SBS call resource allocation flow diagram with OMs NRM SBSRM ESEL1 ESEL2
BSC_AllocationRequestReceived
Initial Attempt
Resource Allocation Request Resource Allocation Response
BSC_AllocationRequestDiscardedDueToOv erload BSC_AllocationRequestDenied BSC_AllocationRequestAccepted BSC_ResourceUnavailableOnInitialAttempt
BSC_AllocationInitialAttempts
BSC_AllocationInitialSuccesses BSC_AllocationInitialFailures BSC_AllocationInitialTimeouts
Retry (if initial Attempt failed)
BSC_ResourceUnavailableOnRetryAttempt BSC_AllocationInitialAttempts
Resource Allocation Response
BSC_AllocationInitialSuccesses BSC_AllocationInitialFailures BSC_AllocationInitialTimeouts In case of internal failures at SBSRM while processing NRMs request: BSC_AllocationInternalFailures
411-2133-525 Standard 06.12 April 2008
Voice resource allocation for a connection type diagram with OMs CAU NRM
Resource Allocation Req Resource Allocation Request Processing Phase NRMs Resource Allocation Phases ConnectionAllocationRequestReceived
For EVRC service on a per connection type ConnectionResourceCheckAttempts ConnectionResourceCheckUnavailable ConnectionResourceCheckAvailable
Platform Selection Phase
ConnectionAllocationResourceUnavailable
Sending Request to CSRM/SDRM or SBSRM
411-2133-525 Standard 06.12 April 2008
Voice resource allocation for a connection type diagram with OMs (continued) CAU NRM CSRM/SDRM SBSRM
EBSC_ConnectionAllocationAttempts Resource Allocation Request Interaction with Resource Manager Phase (CSVS) Resource Allocation Response EBSC_ConnectionAllocationSuccesses EBSC_MG_ConnectionAllocationFailures BSC_ConnectionAllocationAttempts For 13K service on a per connection type: BSC_ConnectionResourceCheckAttempts BSC_ConnectionResourceCheckUnavailable BSC_ConnectionResourceCheckAvailable
BSC_ConnectionAllocationSuccesses BSC_ConnectionAllocationFailures Resource Allocation Request Interaction with Resource Manager Phase (SBS) Resource Alloc Rsp
Upon Sub Resource manager response: AllocationRequestRedirectionTrFO_ToCct AllocationRequestRedirectionTrFO_ToPkt AllocationRequestRedirectionPktToTrFO AllocationRequestRedirectionPktToCct AllocationRequestRedirectionCctToTrFO AllocationRequestRedirectionCctToPkt AllocationRequestRedirectionUnspecifiedToCct AllocationRequestRedirectionUnspecifiedToPkt AllocationRequestRedirectionUnspecifiedToTrFO
ConnectionAllocationResourceAvailable ConnectionAllocationResourceFailures
Call setup flow diagram using BAM channels

NOTE: The BAM OMs peg for all voice and data calls that are setup using the BAM channels. The OMs are pegged for both
originations and terminations. These OMs are pegged at the same time in the call flow and in addition to CAU OMs.
0
20-16 Call setup flow diagram using BAM channels Nortel Networks
411-2133-525 Standard 06.12 April 2008
Mobile
Origination
BTS
BSC
MTX
OMs pegged
Origination Indication
BAMOATTS
Base Station Ack
Page Request Page Page Response Base Station Ack Page Response
BAMPGRES
BSC Resource Availability Determination and Allocation Setup Radio Link

Note: The rectangular boxes indicate exchanges of multiple messages between subsystems or processes within subsystems that are not shown for clarity.
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
MTX
OMs pegged
Carrier Selection via MCTA. BTS Resource Request BTS Resource Response NULL TRAFFIC DATA Extended Channel Assignment Message Preamble NULL TRAFFIC DATA Base Station Acknowledgment Mobile Acknowledgment
In case of call redirection to an alternate band: MCPCOBAM for origination
and
MCPCTBAM for termination In case of no redirection: BAMSBSAT
If the originating carrier is selected for call setup: BAMSCSAT
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
Radio Link Setup Rsp Service Connect Req
MTX
OMs pegged
For RF Access Failures: BAMERLFL In case of an access failure when there was no redirection: BAMSBSFL In case of an access failure when the originating carrier is selected for call setup: BAMSCSFL
Service Connect Message Service Connect Completion Service Connect Rsp
For RF Access Failures: BAMEDLOT BAMERLFL In case of an access failure when there was no redirection: BAMSBSFL In case of an access failure when the originating carrier is selected for call setup: BAMSCSFL
SAT Present
Alert with information Connect Answer
In case of Success: BAM$SUCC
MEID- Registration, origination/termination call flow with OMs

Registration Origination/ Termination
20-19 MEID- Registration, origination/termination call flow with OMs Nortel Networks Copyright 2008 Nortel Networks
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
Registration Indication
MTX
OMs pegged
Registration Message
Status Request on the common channel during Registration: MEIDQRCC MEIDQSCC
Status Request
Status Request on traffic channel after successful call setup: MEIDQRTC MEIDQSTC
Status Response
Origination/ Page Response/ Handoff
Origination/ Page Response/ReadyNewCellIndication
BTS Ack
If the SCM =1 and ESN field = pESN then MEIDATTS If the SCM =0 and ESN field = ESN then ESNATTS
MEID- Registration, origination/termination call flow with OMs
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
BSC Resource Allocation
MTX
OMs pegged
Based on the PLCM type used during call setup: PLCMCallSetupAttempts_PseudoESN PLCMCallSetupAttempts_MEID PLCMCallSetupAttempts_BSAssigned Note: These OMs are pegged against the target system during Hard Handoff
Radio Link SetupRequest Radio Link Resource Indication Hard Handoffs: Target systems receives Radio Link Setup Response message ECAM Radio Link Setup Response Service Connect Req Service Connect Message Service Connect Completion Service Connect Rsp
ECAM
In the event of RF failure and a PLCM collision detected at the BTS: PLCMCallSetupFailures_PseudoESN PLCMCallSetupFailures_MEID PLCMCallSetupFailures_BSAssigned For Success: PLCMCallSetupSuccess_PseudoESN PLCMCallSetupSuccess_MEID PLCMCallSetupSuccess_BSAssigned
In the event of RF failure and a PLCM collision detected at the BTS: PLCMCallSetupDrops_PseudoESN PLCMCallSetupDrops_MEID PLCMCallSetupDrops_BSAssigned
3G packet data call setup flow diagram with OMs Mobile-initiated packet setup, FCH (RMU is BSC/EBSC resource manager)
NOTE: MSC OMs described in the 3G voice OM flow are also pegged for FCH packet data calls under the CAUSCT3D, CAUFRQ3D OM, and CAURM groups.
411-2133-525 Standard 06.12 April 2008
Mobile
Origination
BTS
SBS
MTX
OMs pegged
If setup is a dormant -> active transition, peg MIDTOAAT
Base Station Ack

Attempts: RMUIARD RMURARD No Resources: RMUIANRD RMURANRD
CAU$BLKS
Failures: RMUIOEND RMUIATOD RMURAOED RMURATOD
Note: Similar OMs from BSCRM OM group peg for a

Data Delivery Service (SMS, OTAPA, LCS) call.
3G packet data call setup flow diagram with OMs Mobile-initiated packet setup, FCH (NRM is BSC/EBSC resource manager)
NOTE: MSC OMs described in the 3G voice OM flow are also pegged for FCH packet data calls under the CAUSCT3D, CAUFRQ3D OM, and CAURM groups.
411-2133-525 Standard 06.12 April 2008
Mobile
Origination
BTS
BSC (CNFP)
MTX
OMs Pegged
If setup is a dormant -> active transition, peg MIDTOAAT
Base Station Ack
Attempts: NRMARPD
CAU$BLKS
No Resources: NRMANRPD
Failures: NRMOEPD NRMATOPD NRMOLRPD NRMSTOPD
Note: Similar OMs from EBSCRM OM group peg for a $ = T for Mobile Terminated calls, O for Mobile Originated
Data Delivery Service (SMS, OTAPA, LCS) call.
Nortel Networks
Mobile-initiated packet setup, FCH
Mobile BTS OMs

2G_MctaFull 3GV_MctaFull 3GD_MctaFull
BTS
BSC
Setup Radio Link
MTX
OMs pegged
MEID- Registration, origination/termination call flow with OMs 20-23 Copyright 2008 Nortel Networks
Carrier Selection via MCTA
In Case of Success: FchOriginationNonB locking3GData In Case of Failure, the following array get pegged: BlockedFchOriginati ons3GData
BTS Resource Request BTS Resource Response
Mobile-initiated packet setup, FCH BSC
MTX
OMs pegged
(Extended) Channel Assignment NULL TRAFFIC DATA
411-2133-525
Standard
Mobile
06.12
April 2008
Preamble
NULL TRAFFIC DATA
BTS
Nortel Networks
Mobile-initiated packet setup, FCH Mobile BTS BSC MTX PDSN OMs pegged
Base Station Acknowledgment

CDMA System Performance System Performance Metrics NBSS15.0 MEID- Registration, origination/termination call flow with OMs 20-25 Copyright 2008 Nortel Networks
Mobile Acknowledgment Radio Link Setup Rsp Service Connect Req

TotalSesstionSetupInitial Attempts
Service Connect Message
Layer 2 Session setup (unless dormant to active transition)
Peg these for L2TP signalling packets when appropriate: ReliablePacketSentSuccess, ReliablePacketReTransmitted, ReliablePacketReceived.
TotalSessionSetupSuccesss or TotalSessionSetupFail-
PCU-PDSN Failure
PDSEFLDS
411-2133-525 Standard 06.12 April 2008
Mobile-initiated packet setup, FCH Mobile BTS BSC MTX PDSN OMs pegged
If setup is a dormant -> active transition, - peg MIDTOASU - blocking or RF trouble ends the call before this point, peg MIDTOAFL
PCU-PDSN Failure
PDSEFLDAS
RLP3 Establishment
Peg RLPSetupAttempts and either RLPSetupSuccesses or RLPSetupFailures
PPP Establishment (unless dormant -> active transition)
PDN
IP Traffic
411-2133-525 Standard 06.12 April 2008
Packet data call resource allocation flow diagram with OMs CAU NRM
AllocationRequestReceived
Resource Allocation Req

AllocationRequestRejectedDueToOverload AllocationRequestDenied AllocationRequestAccepted AllocationRequestUnavailable For dormant-to-active calls, these OMs are also pegged: DTA_BSC_AllocationRequestAccepted OR DTA_EBSC_AllocationRequestAccepted, DTA_AllocationRequestUnavailable
Resource Allocation Request Processing Phase
ResourceCheckAttempts ResourceCheckUnavailable ResourceCheckAvailable
Platform Selection Phase (for null-toactive requests only)
SelectionAttemptsOnPrimaryPlatform SelectionSuccessOnPrimaryPlatform SelectionAttemptsOnSecondaryPlatform SelectionSuccessOnSecondaryPlatform The above OMs only peg for null-to-active calls and do not peg for dormant-to-active calls
411-2133-525 Standard 06.12 April 2008
Packet data call resource allocation flow diagram with OMs (continued) CAU NRM
SDRM
SBSRM
Interaction with Resource Manager Phase
SelectedEBSC_AllocationAttempts OR AlternateEBSC_AllocationAttempts In case of success: SelectedEBSC_AllocationSuccesses OR AlternateEBSC_AllocationSuccesses In case of failure: SelectedEBSC_SDU_AllocationFailures OR AlternateEBSC_SDU_AllocationFailures SelectedBSC_AllocationAttempts OR AlternateBSC_AllocationAttempts In case of success: SelectedBSC_AllocationSuccesses OR AlternateBSC_AllocationSuccesses In case of failure: SelectedBSC_AllocationFailures OR AlternateBSC_AllocationFailures In case of success: AllocationRequestSuccesses In case of failure: AllocationRequestFailures For dormant-to-active calls, these OMs are also pegged: In case of success, any one of: DTA_BSC_RequestedSuccessOnBSC DTA_BSC_RequestedSuccessOnEBSC DTA_EBSC_RequestedSuccessOnEBSC DTA_EBSC_RequestedSuccessOnBSC In case of failure: DTA_AllocationRequestFailures
Interaction with Resource Manager Phase
411-2133-525 Standard 06.12 April 2008
Dormant handoff PCU allocation flow diagram with OMs CAU NRM CPDS PCU-M SBSPCUM
DHO_AllocationRequestReceived DHO_AllocationRequestRejectedDueTo Overload DHO_AllocationRequestDenied
PCU Allocation Req PCU Allocation Request Processing Phase PCU Allocation Request PCU Allocation Response
Interaction with PCU Manager Phase
DHO_SelectedEBSC_AllocationAttempts OR DHO_AlternateEBSC_AllocationAttempts In case of success: DHO_SelectedEBSC_AllocationSuccesses OR DHO_AlternateEBSC_AllocationSuccesses In case of failure: DHO_SelectedEBSC_AllocationFailures OR DHO_AlternateEBSC_AllocationFailures DHO_SelectedBSC_AllocationAttempts OR DHO_AlternateBSC_AllocationAttempts In case of success: DHO_SelectedBSC_AllocationSuccesses OR DHO_AlternateBSC_AllocationSuccesses In case of failure: DHO_SelectedBSC_AllocationFailures OR DHO_AlternateBSC_AllocationFailures
Interaction with PCU Manager Phase
PCU Allocation Request PCU Allocation Response
PCU Allocation Response
In case of success: DHO_AllocationRequestSuccesses In case of failure: DHO_AllocationRequestFailures
2G/3G voice/data soft handoff (intra-BSC) flow diagram with OMs Soft handoff
20
Nortel Networks
Mobile
Call in Progress
BTS1
BTS2
BSC
OMs pegged
FchHandoffNonBlocking2G FchHandoffNonBlocking3GVoice FchHandoffNonBlocking3GData SchHandoffNonBlocking3G are pegged if the resources are successfully allocated. Note that pegging these OMs do not necessarily indicate a successful soft handoff.
2G/3G voice/data soft handoff (intra-BSC) flow diagram with OMs 20-30 Copyright 2008 Nortel Networks
Pilot Strength Measurement Message
Setup BTS2 resources

BlockedFchHandoffs2G BlockedFchHandoffs3GVoice BlockedFchHandoffs3GData BlockedSchHandoffs are pegged if the BTS is unable allocate resources. These OMs are arrays that map to the various blocking reasons.
Selector Frames Selector Frames
Extended (2G) or Universal (3G) Handoff Direction Message Handoff Completion Message Call in Progress
20-31 2G/3G voice/data soft handoff (intra-BSC) flow diagram with OMs Nortel Networks Copyright 2008 Nortel Networks
411-2133-525 Standard 06.12 April 2008
Network-originated F-SCH burst

(takes place after FCH packet call has been established)
Mobile BTS OMs

If queued by scheduler InitialFwdSchBurstQueued?X UpdatedFwdSchBurstQueued?X DistributionOfPriorityClass#Delay DistributionOf?XDataRateDelay FwdSCHBurstSetupPeakDelay MaximumFSCHQueueLength In Case of Success: NonQueuedFwdSchBurstNo nBlocking3G Or QueuedFwdSchBurstNonBlo cking3G Or RevSchBurstNonBlocking3G In Case of Failure: BlockedSchBursts
BTS
BSC
PDN->Mobile traffic buffered in RLPQ reaches threshold in RLPQ
PDN
BSC OMs
FwdBurstSetupAttempts* FwdBurstUpgradeAttempts_?X_To_?X FwdBurstBSC_Downgrade FwdBurstBSC_DowngradeChange FwdBurstBSC_DowngradeChange_?X_To_?X FwdBurstBSC_NonDowngrade FwdBurstBSC_NonDowngradeChange* FwdBurstDelayIndex_1 or 2 or 3 FSCHLinkSetupAttempt* for initial link SHO_FSCHLinkSetupAttempt* for HO links FSCHLinkSetupAttemptsChange_?X for the queued up requests when applicable. Peg (SHO_)FSCHLinkSetupBlock* and a blocking reason [1] for initial (or HO) link that blocks. Peg FSCHLinkDowngrade if data rate is downgraded by the BSC due to insufficient BTS resources. Peg (SHO_)FSCHTimeout for initial (or HO) link that times out. Peg FwdBurstSetupFailures* if all links timeout or block. Peg (SHO_)FSCHLinkSetupSuccess* for each initial (or HO) link allocated.
ESEL Fair Share Algorithm BTS Resource Request BTS SCHEDULER
BTS Resource Response
[1] BTS Blocking reason OMs at the BSC for initial F-SCH links include: FSCHNoFwdPower, FSCHNoWalshCode, FSCHNoPhysRes, FSCHNoFrameOffset, FSCHBackHaulExhaustion, FSCHBCNLinkExhaustion, FSCHAcnIdExhaustion, and FSCHLinkSetupBlockSW_Error. Note that these OMs indicate a link, but not necessarily a SCH burst, was blocked. SHO link blocking reason OMs are prepended with SHO_.
* The appropriate rate-specific versions of these OMs will also peg. ? represents the appropriate corresponding data rates (i.e. 2X, 4X, 8X, or 16X). # represents the priority class number (i.e. 1 through 14) based on the datafilled QOSPI level of the user.
Nortel Networks
Network-originated F-SCH Burst (continued)

(takes place after FCH packet call has been established)
Mobile
BTS
BSC
PDN
OMs pegged
Extended Supplemental Channel Assignment Message

CDMA
Peg FSCHRadioLinkAccessFailure* and FwdBurstSetupFailures* if no Ack. as well as FwdBurstUpgradeFailures_?X_To_?X in cases of data rate upgrade attempts. Peg FwdBurstSetupSuccesses* otherwise. as well as FwdBurstUpgradeSuccess_?X_To_?X in cases of data rate upgrade attempts.
2G/3G voice/data soft handoff (intra-BSC) flow diagram with OMs 20-32 Copyright 2008 Nortel Networks
Layer 2 Ack
System Performance System Performance Metrics NBSS15.0
High-Speed IP Traffic Via F-SCH (aggregated with existing F-FCH
* The appropriate rate-specific versions of these OMs will also peg. ? represents the appropriate corresponding data rates (i.e. 2X, 4X, 8X, or 16X).
Hard handoff flow diagram with OMs Hard handoff (intra-MSC) Mobile BTSS BSCS BTST BSCT MTX PDSN
20
S = Source T = Target
20-33 Hard handoff flow diagram with OMs Nortel Networks
411-2133-525 Standard 06.12 April 2008
OMs pegged
In Case of Unsupported Services: RMUNSO CAUUNSO In the case of Resource Allocation Failure: RMUIANRV RMURANRV RMUIOENV RMUIATOV RMURAOEV RMURATOV
Call in Progress Pilot Strength Measurement Message Handoff Indication BSC Resource Availability Determination
CAUHBLKS
BSC and BTS Resource Allocation
CAUHATTS MCTHCATT MCTHATTS are pegged in the target CAU MCTAHRQF, CAUERSFL and the accompanying reason OMs are pegged if no frequency is successfully selected * CAUHBLKS and the accompanying blocking reason OMs are pegged in the target CAU if radio resource allocation fails at this point.*
Handoff Message Request
*NOTE: Possible OM pegs include: MCTAREQF,MCTALLTO,MCTALLFU,MCTAMIXF,MCTARQFN,MCTAREQN,MCTAREQT, CAUNOTCE,CAUNOWCD,CAUFWCAP,SCTBTSBK,CAUNOFOF,MCTNOTCE,MCTNOWDC,MCTFWCAP,MCTBTSBK,MCTNOFOF,MCTERSFL
Hard handoff (intra-MSC) Hard handoff (intra-MSC) Mobile

20
S = Source T = Target
Nortel Networks
BTSS
BSCS
BTST
BSCT
MTX
PDSN
OMs pegged
Extended (2G) or Universal (3G) Handoff Direction Message Handoff Message Response Release Radio Resources
TotalSessionSetupReconnectAttempts TotalSessionSetupSuccess are pegged in the PCU MO of the SBS. TotalSessionSetupFailures will be pegged if the setup is unsuccessful.
Teardown BTS1 resources
Reconnect Data Session
3G Data Call only
Reconnect Data Session

Hard handoff (intra-MSC) 20-34 Copyright 2008 Nortel Networks
Connect Resources Handoff Completion Message Call in Progress
CAUHSUCC MCTHSUCC are pegged in the target CAU. If the mobile fails to arrive on the traffic channel, but all resources were allocated successfully, then CAUHRLFL and MCTHRLFL will be pegged.
Access robustness package: call flow with OM register pegs
20
20-35 Access robustness package: call flow with OM register pegs Nortel Networks
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
Call Setup in Progress
MTX
OMs pegged
NULL TRAFFIC DATA
Begin Fwd Traffic Rsp Radio Link Resource Ind.

If more than one traffic channel has been allocated, CAUCHATT will be pegged. If more than one ECAM is to be sent (indicated by the presence of at least two ACN Node Ids in the ACN_Node_Id_List), CAUAHATT will be pegged.
Preamble
NULL TRAFFIC DATA
Access robustness package: call flow with OM register pegs
Nortel Networks
Mobile
BTS
BSC
MTX
OMs pegged
If CAUCHATT was pegged, either CAUCHSUC or CAUCHFL will be pegged. If the message indicates success, CAUCHSUC is pegged. If the message times out, or indicates failure, CAUCHFL will be pegged.

Mobile Acknowledgment
Access robustness package: call flow with OM register pegs 20-36 Copyright 2008 Nortel Networks
If CAUAHATT was pegged, either CAUAHSUC or CAUAHFL will be pegged. If the message indicates success, CAUAHSUC is pegged. If the message times out, or indicates failure, CAUAHFL will be pegged.
IVSN flow diagram with OMs

20 OMs pegged
20-37 IVSN flow diagram with OMs Nortel Networks
411-2133-525 Standard 06.12 April 2008
Mobile
Origination
BTS
BSC
MTX
Origination Indication Base Station Ack
ONILDNY is pegged if NIL service option is requested. ODENYCM is pegged if mismatch between the mobile capability in the VLR and the table SERVNEG. Call will not be setup ATEVRC ATB13K ATI13K ATNIL
Page Request
TDENYCM is pegged if mismatch between the mobile capability in the VLR and CDMA_PAGE_WITH_MS_CAP_INF O parameter in the table OFCVAR. Page request is not sent out.
Page Page Response Base Station Ack Page Response
Nortel Networks
Mobile
BTS
Status Request
BSC
MTX
OMs pegged
This status request message is sent if selected query option allows querying the mobile on the Paging/Access channel. QRYPAORG or QRYPATRM is pegged. QRYPAFL is pegged if Status response message is not received by the CAU. ODENYCAU or TDENYCAU pegged if mismatch between the retrieved service options and table SERVNEG. Call will not be setup after this.
Status Request
Status Response Status Response
BSC Resource Availability Determination BSC Resource Allocation

IVSN flow diagram with OMs 20-38 Copyright 2008 Nortel Networks
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
Setup Radio Link
MTX
OMs pegged
Carrier Selection via MCTA.
BTS Resource Request

BTS Resource Response
Nortel Networks
BSC
MTX
OMs pegged
NULL TRAFFIC DATA
Mobile
CDMA
Preamble
NULL TRAFFIC DATA
BTS
NBSS15.0
20-41 IVSN flow diagram with OMs Nortel Networks Copyright 2008 Nortel Networks

411-2133-525
Standard
06.12
April 2008
Nortel Networks
Mobile
BTS
BSC
MTX
OMs pegged
This status request message is sent if the mobile is queried on the traffic channel. QRYTCORG or QRYTCTRM is pegged by CAU when Radio Link Setup Rsp is received. QRYTCFL is pegged if no service options are received in the Service Connect Response message from the SBS by the CAU. FLCEVR or FLTCI13K or FLTCB13K pegged if mobile does not support provided service option.

Mobile Acknowledgment Status Request Status Response
One of VNILEVB, VEVBEVB, VEVBEVR, VEVB13K, VNILEVR, VB8KEVR, VEVREVR, VI13KEVR, VB13KEVR, VNILI13K, VB8KI13K, VEVRI13K, VI13KI13, VB13KI13, VNILB13K, VB8KB13K, VEVRB13K is pegged when call is successfully setup. VI13KB13, VB13KB13K
411-2133-525 Standard 06.12 April 2008
Mobile
BTS
BSC
SAT Present
MTX
OMs pegged
If the mobile originated the call, the call setup will finish with a SAT Present indication from the BSC to the MTX.
Alert with information If the mobile is receiving the call, the mobile will alert the user of the incoming call. The user, if he or she desires, will then connect the call. The call setup finishes with an Answer indication from the BSC to the MTX.
Connect
Answer
Nortel Networks
REGISTRATION
Mobile
Registration
BTS
BSC
MTX
OMs pegged
Registration Indication
QRYPAREG is pegged. This status request message is sent if selected query option allows querying the mobile during registration on the Paging/Access channel.
Status Request
Status Response
QRYPAFL is pegged if Status response message is not received by CAU.
Nortel Networks
Call flow diagrams with OMs 20-45 Copyright 2008 Nortel Networks
Intelligent zone paging flow diagram with OMs
20
Mobile
BTS
BSC
MTX
OMs pegged
PGZNREQ is pegged if zone based paging is performed.
Page Request
Page
The page retry is performed. Retry OM such as RPGZNREQ, RPSYSRQ, PG3ZNREQ etc. are pegged as per the zone configuration.
Page Response
PGZNTO is pegged for the initial page time out. REPGTO, PG3ZNREQ are pegged in case of page retry timeout. PGZNRES is pegged for page response to fist page.
Base Station Ack
Page Response
RPGZNRES or RPSYSRSI or RPSYSRSO or RPSYSRS etc. are pegged accordingly for page retry response.
SMS termination over paging channel
20
CDMA
NBSS15.0
20-46 Call flow diagrams with OMs Nortel Networks
MC OMs Pegged SMSPGREQ SMSPGRES

Msg then and
but if CAU times out
Message Center SMDPP Invoke
CM
CAU
BTS
MS
sms_page
page msg
waiting for initial page response
page msg page response
SMSPGTO SMSPGRTY SMSPRRES

Msg then
waiting for retry page response
page response
SMS Delivery
SMSPGRTO SMSTATPG SMSTSCPG or SMSTFLPG sms_page response

smdpp Return release SMS Delivery Resp.
data burst msg data burst ack
Release Order Release Ack

release ack
411-2133-525
Standard
06.12
April 2008
Nortel Networks
SMS termination over traffic channel

MC OMs Pegged SMSPGREQ
but if CAU times out waiting for initial page response Msg then
20
SBS BTS MS
Message Center SMDPP Invoke
CM
CAU
SMSPGRES
sms_page page msg page msg page response page response
SMSPGTO
and
SMSPGRTY SMSPRRES
page response Msg then
waiting for retry
NORMAL TRAFFIC CHANNEL SETUP

SMS page response Forward Data Delivery SMS Delivery
SMSPGRTO SMSORATS
or
data burst msg data burst ack
SMSORSUC (SMSTMCFL
and/or
SMSTRCFL)
SMS Delivery Resp. Reverse Data Delivery smdpp Return release Release Order
SMSTATTC
SMSTSCTC or SMSTFLTC
Release Ack release ack
CDMA
NBSS15.0
In-call SMS termination

MC OMs Pegged
Message Center
20
CM CAU SBS MS
TRAFFIC CHANNEL IS SETUP AND MOBILE IS IN A CALL

SMDPP Invoke
SMSDVCAT
Forward Data Delivery SMS Delivery data burst msg data burst ack
SMSDVCSC or SMSDVCFL
smdpp Return
SMS Delivery Resp. Reverse Data Delivery
MOBILE CONTINUES TO BE IN A CALL
411-2133-525
Standard
06.12
April 2008
Nortel Networks
SMS origination over access channel

MC OMs Pegged
Message Center
20
CAU BTS MS
CM
data burst msg
SMOATTAC
and possibly
DataBurstInd
SMOFAIAC
SMSOrigination SMDPP Invoke smdpp Return SMSOrigination Response
SMOSUCAC or SMOFAIAC
DataBurstIndResp.
data burst ack
CDMA
NBSS15.0
SMS origination over traffic channel

MC
Message Center
20
CAU SBS BTS MS
CM
OMs Pegged
origination Orig-Ind-Opt-6
SMOCSRAC SMOCSSTC
or SMOCSFTC and/or
NORMAL TRAFFIC CHANNEL SETUP

data burst msg DataBurstInd
SMSORCFL (SMOATITC
and possibly
SMOFAITC)
but if CAU times out waiting for Msg then
SMODBRTO SMOCMREQ
SMDPP Invoke smdpp Return SMSOrigination Response DataBurstInd Resp. data burst ack Order Message ReleaseOrder SMSOrigination
SMOCMRES
SMOCMRTO
or
SMOSUITC SMOFAITC
411-2133-525
Standard
06.12
April 2008
Nortel Networks
In-call SMS origination

MC
Message Center
20
CM CAU SBS MS
OMs Pegged TRAFFIC CHANNEL IS SETUP AND MOBILE IS IN A CALL

data burst msg
SMOATBTC
and possibly
DataBurstInd
SMOFABTC
SMSOrigination
SMOCMREQ
SMDPP Invoke smdpp Return
SMOCMRES
SMSOrigination Response
SMOCMRTO SMOSUBTC or SMOFABTC

DataBurstInd Resp. data burst ack
MOBILE CONTINUES TO BE IN A CALL
CDMA
NBSS15.0
VPAD call flow
20
The following message flow diagram depicts the VPAD (Voice Preemption of Active Data Call) feature-related forcing of an Active Packet Data Call to a Dormant Data Call state in order to deliver an incoming Voice Call Termination to the Mobile Subscriber. This call flow assumes that the MS is in an Active Data Call with VPAD SOC ON and Call Waiting Enabled (i.e., the Durable Cancel Call Waiting (DCCW) feature is not enabled for Data calls).
411-2133-525
Standard
06.12
April 2008
Nortel Networks
VPAD call flow with OM pegs

MS BTS BSC CAU RMU CM
20
Incoming Voice Call for a mobile in an active data session Release with retry delay Retry Order
OMs Pegged
Peg VPADIC
Retry Order
Service Option Control Message Release Order
VPAD Page Delay Timer (2 sec.)
Data Call should now be in Dormant state.
Page Request
Page
Page Request
If the system receives a data origination from the MS during this period, it will send a Retry Order on the Paging Channel, followed by another Page (after a 2 sec delay).
Page Response Page Response
Peg VPADATT
If Call Setup is Successful: Peg VPADSUC If CM receives a Call Failure after the page response, but before the call is answered or an answer-timed-out occurs: Peg VPADFL
Page Response
Normal 3G Voice Call Setup Resource Allocation Messaging occurs here.
After the Voice Call is released, the data call is treated as a normal Dormant Packet Data Call.
CDMA
NBSS15.0
Border cell paging and call setup
20
Successful paging and call setup in border system The following message flow depicts the paging of a roaming MS last registering in a cell at or near the Anchor systems border. The MS has moved to a border area in the Border system. Paging occurs in both, the Anchor and the border system. For the Call Flow and OM Pegging assume that the ISPAGE2 message indicated three attempts in Border System and the PAGEIND parameter in = Paging.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
MS
BTS
BSC
Border System
Anchor System/VLR
OMs Pegged
A Call for a MS arrives at the Anchor System. Anchor System determines that MS was last registered in the Border Cell of the Anchor System.
ISPAGE2 Invoke
Peg IPG2IVOG. Peg IPG2VATT or IPG2DATT.
Anchor System sends Page Request via its BSC/BTSs. ispage2 return result (If MS is Busy or BCP Inactive) Page Request Page Page Response BTS ACK Page Response Peg CDMABIPG group OMs for page attempts, successes, timeouts and cancellations. Peg IPG2RRIC ispage2 with MS busy or BCP feature is inactive in Border System. Also peg IPG2VRFL or IPG2DRFL and applicable CDMASIP2 group OMs.
ispage2 return result
ispage2 with Page response, Peg IPG2RRIC.Also peg IPG2VRR or IPG2DRR and applicable CDMASIP2 group OMs. If timeout, peg IPG2VTO or IPG2DTO.
ISSETUP Invoke
ISSETUP Invoke is sent only if page response is received in Border system, Peg ISETIVOG
CDMA
NBSS15.0
Nortel Networks
Successful paging for SMS and SMS delivery in border system The following message flow depicts the paging of a roaming MS last registering in a cell at or near the Anchor systems border. The MS has moved to a border area in the Border system. Paging occurs in both, the Anchor and the border system. For the Call Flow and OM Pegging assume that the ISPAGE2 message indicated two attempts in Border System.
CDMA
NBSS15.0
Nortel Networks
MS
BTS
BSC
Border System
Anchor System/VLR
OMs Pegged
A SMS for a MS arrives at the Anchor Systems CM from the SMS center. Anchor System determines that MS was last registered in the Border Cell of the Anchor System.
ISPAGE2 Invoke
Peg IPG2IVOG. Peg IPG2SATT
Anchor System sends Page Request via its BSC/BTSs. ispage2 return result (If MS is Busy or BCP Inactive) Page Request Page Page Response BTS ACK Page Response Peg SMSBIPG group OMs for page attempts, successes, timeouts and cancellations. ispage2 with Page response, Peg IPG2RRIC.Also peg IPG2SRR and IPG2S1RR or IPG2S2RR. If timeout, peg IPG2STO. Peg IPG2RRIC If ispage2 with MS busy or BCP feature is inactive in Border System, then peg IPG2SRFL.
ispage2 return result
ISSMDPP Invoke
ISSMDPP Invoke is sent only if page response is received in Border system, Peg ISSMIVOG
CDMA
NBSS15.0
MS
BTS
BSC
Border System
Anchor System/VLR
OMs Pegged
After setting up BSC/BTS Resources, the MS is Ordered to a Traffic Channel and the MS Arrived on the Traffic Channel.
SMSBDDAT Data burst
Please refer to 2G/3G Voice Call Setup Flow diagram with OMs for call termination in this chapter for call setup and related OMs that will peg in Border
Data Burst Ack
SMSBDDSC. If no DataBurstAck is received from the MS or the MS responds with a failure code, then peg SMSBDDFL.
issmdpp return result ISSMRRIC
411-2133-525
Standard
06.12
April 2008
Nortel Networks
MS
BTS
BSC
Border System
Anchor System/VLR
OMs Pegged
issetup return result ISETRRIC After setting up BSC/BTS Resources, the MS is Ordered to a Traffic Channel and the MS Arrived on the Traffic Channel.
Alert with information
The MS Connects (if the User Desires)
Please refer to 2G/3G Voice Call Setup Flow diagram with OMs for call termination in this chapter for call setup and related OMs that will peg in Border System.
Answer Indication
ISANSWER Invoke IANSIVIC
isanswer return result IANSRROG
The Call is in progress
CDMA
NBSS15.0
Inter-system hard handoff
20
Target system The following message flow depicts the pegging of the MTXIHO OMs on the Target System. The mobile in this case has moved from the source system into a border cell that triggers a hard handoff request to the target system.
SBSTarget
CAUTarget
MTXTarget
FACDIR2
MTXsource
OMs Pegged (on Target)

IHO2GATT or IHO3VATT or IHO3DATT
ReadyNewCell
SBS prepares target cell NewCellReady

(If no resources, IHO2GBLK or IHO3VBLK or IHO3DBLK) (If SO changed, IHOSOCHG (If release occurs, IHO2GREL or IHO3VREL or IHO3DREL) (If timeout occurs, IHO2GFAL or IHO3VFAL or IHO3DFAL)
facdir2 (response) Handoff Completion Ind Release Order
SAT Present
SAT Present
IHO2GSUC or IHO3VSUC or IHO3DSUC IHOSRSUC
MONCH
Note: IHO2GINT or IHO3VINT or IHO3DINT is pegged along with the failure or success OM in the selected sector to indicate the MPHHO attempt in that sector.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
MSC OM descriptions 21-1 Copyright 2008 Nortel Networks
MSC OM descriptions
21
This chapter lists all the MSC OMs discussed in the CDMA System Performance Operational Measurements guide. This chapter may also include other CDMA related MSC OMs which are not used in any metric but are provided for completeness or informational purposes. This chapter contains the detailed descriptions and reference chapter for each of the OMs. OM group are listed in alphabetical order by group name, and each OM group lists the OMs contained within that group. Note: OMs with no reference chapter are listed merely for completeness.
MSC operational measurements

The following table includes a description of each OM along with more information wherever applicable. In any reference to CAU*BLKS, * = O, T or H (i.e., CAUOBLKS, CAUTBLKS, or CAUHBLKS).
21
MSC operational measurements Register AUTHCTR2 OM group ACRGASIG Description AUTHentication CenTeR 2. This OM group pegs events in the Authentication Center. AC otaspreq Request for Generate Authentication SIGnature. This event takes place when the mobile challenges the OTAPA session authenticity
sheet 1 of 225
Reference chapter
CDMA
NBSS15.0
21-2 MSC OM descriptions Nortel Networks MSC operational measurements Register BAMCPFRQ OM group New OM group in 14.0 release BAMSCSAT Description
Reference chapter Call setup performance (page 2-1)
BAM Call Processing FReQuency. These OMs are pegged by CAU to track the RF access failures on BAM channels on a per Sector/Band/Freq. The OMs in this group peg for originations and terminations received for all call types (Voice and Packet Data) combined. BAM Same Carrier Selected ATtempts. This OM is pegged against the originating carrier when a call origination/termination (or a re-origination/termination after band redirection) is received on a frequency and the resources for the call are setup on the same frequency. BAM Same Carrier Selected FaiLures. This OM pegs tracks the access failures for only those attempts that are tracked by BAMSCSAT. CAUERLFL, MCTERLFL and MRETFL peg along with this OM.
Call setup performance (page 2-1)
BAMSCSFL
BAMSBSAT
BAM Same Band Selected ATtempts. This OM is pegged against the originating carrier when a call origination/termination (or a re-origination/termination after band redirection) is received on a frequency and the resources for the call are set up on the same band regardless of the frequency selected on that band. Note: This excludes the paging channel redirected calls to other band.
BAMSBSFL
BAM Same Band Selected FaiLures. This OM pegs tracks the access failures for only those attempts that are tracked by BAMSBSAT. CAUERLFL, MCTERLFL peg along with this OM.
sheet 2 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register BAMCPSCT OM group Modified OM group in 14.0 release BAMOATTS Description
BAM Call Processing SeCTor. These OMs capture similar call events information as the corresponding OMs in CAUCPSCT OM group. The OMs in this group peg only for calls on BAM channels. The OMs peg for originations and terminations received for all call types (Voice and Packet Data) combined. BAM Origination ATTemptS. This OM is similar to CAUOATTS
Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1)
BAMOSUCC
BAM Origination SUCCess. This OM is similar to CAUOSUCC
BAMPGRES
BAM PaGe RESponse. This OM is similar to CAUPGRES
BAMTSUCC
BAM Termination SUCCess. This OM is similar to CAUTSUCC
BAMERLFL
BAM Error case, Radio Link FaiLure. This OM is similar to CAUERLFL BAM Error Drop Loss Of Traffic. This OM is similar to CAUEDLOT
BAMEDLOT New OM in 14.0 release BAMWPSRT New OM in 14.0 release MCPCOBAM New OM in 14.0 release
BAM Wireless Priority Service ReTry. This OM will peg only when WPS is turned ON. Applicable only to WPS activated CDMA carriers. MCta Paging Channel Redirection for successful call Origination on BAM. This OM is similar to MCTPRSO
sheet 3 of 225
CDMA
NBSS15.0
21-4 MSC OM descriptions Nortel Networks MSC operational measurements Register MCPCTBAM New OM in 14.0 release
sheet 4 of 225
Description MCta Paging Channel Redirection for successful call Termination on BAM. This OM is similar to MCTPRST
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register BSCRM OM group Modified OM group in 14.0 release Description
Reference chapter Call setup performance (page 2-1) Call resource allocation and management (page 16-1)
BSC Resource Manager. This OM group tracks events on a perCAU basis. These OMs are pegged by CAU to measure resource allocation performance of RMU for resource allocation requests made from CAU to RMU. CAU makes up to two attempts for resource allocation for each call. This OM group keeps track of resource allocation attempts, success, failures, timeout for each CAU request per call. All OMs for voice are pegged for both 2G and 3G voice calls. OMs for voice calls from also peg for CSD calls starting MTX14.
RMUIARV
RMU Initial Attempt Request for Voice. This OM is pegged when CAU sends the initial resource allocation request to RMU for a voice/CSD call. RMU Initial Attempt Success for Voice. This OM is pegged when CAU receives successful resource allocation response from RMU for the initial resource allocation request for a voice/CSD call. RMU Initial Attempt Time Out for Voice. This OM is pegged when CAU times out while waiting for the initial resource allocation response from RMU for a voice call. In this case, CAU does not retry to allocate resources from RMU for the same call. The appropriate CAU*BLKS OM is pegged along with this OM.
sheet 5 of 225
Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1)
RMUIASV
RMUIATOV
CDMA
NBSS15.0
21-6 MSC OM descriptions Nortel Networks MSC operational measurements Register RMUIANRV Description
RMU Initial Attempt No Resources for Voice. This OM is pegged when CAU receives unsuccessful resource allocation response from RMU due to the lack of resources for initial resource allocation request for a voice/CSD call. In the case of IVSN feature interaction, the CAU requests upto two services from RMU in the initial resource allocation request. In this case, CAU retries to allocate resources from RMU for the same call. However, the CAU may request different services (upto two services) than in the initial resource allocation request. RMU reports lack of resources to CAU in two situations: RMU determines that resources are unavailable by checking its internal data structures RMU experiences out-of-sync condition for resource availability information with the SRMs actual resource availability status. In addition, CAURM:SRMNNORM is pegged at RMU for each unsuccessful response from SRM.
RMUIOENV Modified OM in 14.0 release
RMU Initial attempt Other Error No retry for Voice. This OM is pegged for voice/CSD calls when the CAU receives a resource allocation response to the initial resource allocation request for one of the following RMU error conditions: Resource allocation request sent by CAU to RMU contains an invalid parameter. In the same error conditions that also cause pegging of CAURM:RMSRMNAK, that are reported by RMU. RMU times out waiting for response from SRM. In addition, CAURM:RMSRMTO is pegged at RMU. TimeSlot (TID) mismatch for SRM entry between Table SBSINV on CM and SRM response to RMU. RMU responds back with unsupported service option error
Call setup performance (page 2-1) Call resource allocation and management (page 16-1)
CAU does not retry the resource allocation request for a call because of these error conditions. The appropriate CAU*BLKS OM is pegged along with this OM.
sheet 6 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RMURARV Description
Reference chapter Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1)
RMU Retry Attempt Request for Voice. This OM is pegged when CAU sends the retry resource allocation request to RMU for a voice/CSD call. Note: In some rare situations, CAU does not actually retry if CAU or RMU or both are in overload condition.
RMURASV
RMU Retry Attempt Success for Voice. This OM is pegged when CAU receives successful retry resource allocation response from RMU for a voice/CSD call. RMU Retry Attempt Time Out for Voice. This OM is pegged when CAU times out while waiting for the retry resource allocation response from RMU for a voice/CSD call. The appropriate CAU*BLKS OM is pegged along with this OM.
RMURATOV
RMURANRV
RMU Retry Attempt No Resources for Voice. This OM is pegged when CAU receives unsuccessful resource allocation response from RMU for a retry resource allocation request due to the lack of resources for a voice/CSD call. RMU reports lack of resources to CAU in the similar situations described in RMUIANRV. The appropriate CAU*BLKS OM is pegged along with this OM.
RMURAOEV Modified OM in 14.0 release
RMU Retry Attempt Other Error for Voice. This OM is pegged for voice/CSD calls when the CAU receives a resource allocation response to the retry resource allocation request for one of the RMU error conditions described for the RMUIOENV OM. The appropriate CAU*BLKS OM is pegged along with this OM.
sheet 7 of 225
CDMA
NBSS15.0
21-8 MSC OM descriptions Nortel Networks MSC operational measurements Register RMUIARV2 Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1); Call resource allocation and management (page 16-1)
RMU Initial Attempt Request for Voice 2 (extension). This OM is the extension of RMUIARV.
RMUIASV2
RMU Initial Attempt Success for Voice 2 (extension). This OM is the extension of RMUIASV.
RMUIARD
RMU Initial Attempt Request for packet Data. This OM is pegged when CAU sends the initial resource allocation request to RMU for a packet data call. RMU Initial Attempt Success for packet Data. This OM is pegged when CAU receives successful resource allocation response for initial resource allocation request from RMU for a packet data call. RMU Initial Attempt Time Out for packet Data. This OM is pegged when CAU times out while waiting for the initial resource allocation response from RMU for a packet data call. In this case, CAU does not retry to allocate resources from RMU. The appropriate CAU*BLKS OM is pegged along with this OM.
RMUIASD
RMUIATOD
RMUIANRD
RMU Initial Attempt No Resources for packet Data. This OM is pegged when CAU receives unsuccessful resource allocation response from RMU due to the lack of resources for initial resource allocation request for a packet data call. In this case, CAU retries to allocate resources from RMU. RMU reports lack of resources to CAU in the situations described in RMUIANRV. The appropriate CAU*BLKS OM is pegged along with this OM.
sheet 8 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RMUIOEND Modified OM in 14.0 release Description
Reference chapter Call setup performance (page 2-1); Call resource allocation and management (page 16-1)
RMU Initial attempt Other Error No retry for packet Data. This OM is pegged for packet data calls when the CAU receives a resource allocation response to the initial resource allocation request for one of the following RMU error conditions: Resource allocation request sent by CAU to RMU contains an invalid parameter. Unsuccessful resource allocation acknowledgment is received at RMU from SRM. In addition, CAURM:SRMNAK3D is pegged at RMU. In the same error conditions that also cause pegging of CAURM:SRMNAK3D, that are reported by RMU. TimeSlot (TID) mismatch for SRM entry between Table SBSINV on CM and SRM response to RMU. RMU responds back with unsupported service option error
CAU does not retry the resource allocation request for a call because of these error conditions. The appropriate CAU*BLKS OM is pegged along with this OM. RMURARD RMU Retry Attempt Request for packet Data. This OM is pegged when CAU sends the retry resource allocation request to RMU for a packet data call. Note: In some rare situations, CAU does not actually retry if CAU or RMU or both are in overload condition. Call setup performance (page 2-1); Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
RMURASD
RMU Retry Attempt Success for packet Data. This OM is pegged when CAU receives successful resource allocation response for a retry resource allocation request from RMU for a packet data call.
sheet 9 of 225
CDMA
NBSS15.0
21-10 MSC OM descriptions Nortel Networks MSC operational measurements Register RMURANRD Description
Reference chapter Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
RMU Retry Attempt No Resources for packet Data. This OM is pegged when CAU receives unsuccessful resource allocation response for a retry resource allocation request from RMU due to the lack of resources for a packet data call. RMU reports lack of resources to CAU in the situations described in RMUIANRV. The appropriate CAU*BLKS OM will be pegged in this situation.
RMURATOD
RMU Retry Attempt Time Out for packet Data. This OM is pegged when CAU times out while waiting for the retry resource allocation response from RMU for a packet data call. The appropriate CAU*BLKS OM is pegged along with this OM.
RMURAOED Modified OM in 14.0 release
RMU Retry Attempt Other Error for packet Data. This OM is pegged for packet data calls when the CAU receives a resource allocation response to the retry resource allocation request for one of the RMU error conditions described for the RMUIOEND OM. The appropriate CAU*BLKS OM is pegged along with this OM.
RMUIASD2
RMU Initial Attempt Success for packet Data 2 extension. This OM is the extension of RMUIASD.
RMUIARD2
RMU Initial Attempt Request for packet Data 2 extension. This OM is the extension of RMUIARD.
sheet 10 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register BSCRM2 OM group New OM group in 14.0 release Description
BSC Resource Manager 2. This OM group is an extension of BSCRM OM group that includes registers for Data Delivery Services (SMS, OTAPA, LCS). The OMs from this OM group peg for Data delivery services in the similar events the OMs peg for Voice services from BSCRM OM group. This OM group keeps track of resource allocation attempts, success, failures, timeout for each CAU request per call. The OMs from this group are as follows: RMUIRDS: RMU Initial attempt Request for Data delivery Service (Similar to BSCRM:RMUIARV) RMUISDS: RMU Initial attempt Success for Data delivery Service. (Similar to BSCRM:RMUIASV) RMUITODS: RMU Initial attempt Time Out for Data delivery Service (Similar to BSCRM:RMUIATOV) RMUINRDS: RMU Initial attempt No Resource for Data delivery Service (Similar to BSCRM:RMUIANRV) RMUIOEDS: RMU Initial attempt Other Error no retry for Data delivery Service (Similar to BSCRM:RMUIOENV) RMURRDS: RMU Retry attempt Request for Data delivery Service (Similar to BSCRM:RMURARV) RMURSDS: RMU Retry attempt Success for Data delivery Service (Similar to BSCRM:RMURASV) RMURTODS: RMU Retry attempt Time Out for Data delivery Service (Similar to BSCRM:RMURATOV) RMURNRDS: RMU Retry attempt No Resource for Data delivery Service (Similar to BSCRM:RMURANRV) RMUROEDS: RMU Retry attempt Other Error for Data delivery Service (Similar to BSCRM:RMURAOEV)
For pegging details of these OMs, refer to the similar OMs from BSCRM OM group.
sheet 11 of 225
CDMA
NBSS15.0
21-12 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUARSCT OM group Description
Reference chapter Access robustness package performance (page 5-1)
CAU Access Robustness per SeCTor. CAUARSCT OM group tracks events per sector. These OMs are pegged by the CAU on a per sector basis for feature attempts, successes and failures, provided that (1) Access Robustness Package SOC is activated, and (2) The mobile and the originating BTS are both IS95 Bcapable (or higher, i.e. P_REV >= 5 for the BTS and MOB_P_REV >= 4 for the mobile). CAU Channel assignment into soft Handoff ATTempts. CAUCHATT is pegged for the reference sector, when the CAU receives a message from the BSC indicating that more than one traffic channel has been allocated. CAUCHATT measures the total number of CASHO attempts for call originations/ terminations per sector. Note: Pegging of the CAUCHATT and CAUAHATT OMs are functionally independent. Therefore, for the same call origination/termination in a sector, either one or both OMs may be pegged depending on the conditions that are satisfied for a handoff attempt during the access state. CAU Channel assignment into soft Handoff SUCcess. CAUCHSUC is pegged for the reference sector when the CAU receives a message from the BSC indicating that the mobile has successfully arrived on to a traffic channel. This will be pegged only if CAUCHATT was pegged for the same origination/ termination and it indicates that the CASHO attempt has been successful. CAUCHSUC measures the total number of CDMA CASHO successes per sector. CAU Channel assignment into soft Handoff FaiLure. CAUCHFL is pegged for the reference sector when either the CATRLM_RLMRadioLinkSetupRsp message is received by the CAU with a call failure status, or the call times out while waiting for this message. This will be pegged only if CAUCHATT was pegged for the same origination/termination and it indicates that the CASHO attempt has failed. CAUCHFL measures the total number of CDMA CASHO failures per sector.
sheet 12 of 225
CAUCHATT
Access robustness package performance (page 5-1)
CAUCHSUC
CAUCHFL
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUAHATT Description
Reference chapter Access robustness package performance (page 5-1)
CAU Access Handoff ATTempts. CAUAHATT is pegged for the reference sector when the CAU receives a message from the BSC indicating that more than one BTS may be notified, and at least one of the additional BTSs has its ACCESS_HO_ENABLED bool set to true. This implies that multiple Extended Channel Assignment Messages will be sent to the mobile. CAUAHATT measures the total number of ACCHO attempts per sector for call originations/terminations. Note: Pegging of the CAUCHATT and CAUAHATT OMs are functionally independent. Therefore, for the same call origination/termination in a sector, either one or both OMs may be pegged depending on the conditions that are satisfied for a handoff attempt during the access state. CAU Access Handoff SUCcess. CAUAHSUC is pegged for the reference sector when the CAU receives a message from the BSC indicating that the mobile has successfully acquired a traffic channel. This will be pegged only if CAUAHATT was pegged for the same origination/termination and it indicates that the ACCHO attempt has been successful. CAUAHSUC measures the total number of CDMA ACCHO successes per sector. CAU Access Handoff FaiLure. CAUAHFL is pegged for the reference sector when either the CATRLM_RLMRadioLinkSetupRsp message is received by the CAU with a call failure status, or the call times out while waiting for this message. This will be pegged only if CAUAHATT was pegged for the same origination/termination and it indicates that the ACCHO attempt has failed. CAUAHFL measures the total number of CDMA ACCHO failures per sector. CAU CHannel assignment into soft handoff ReLeaSe. CAUCHRLS is pegged for the reference sector when a release message is received prior to the mobile arriving on the traffic channel. This will be pegged only if CAUCHATT was pegged for the same origination/termination and it indicates that the CASHO attempt has been successful. CAU Access Handoff ReLeaSe. CAUAHRLS is pegged for the reference sector when a release message is received prior to the mobile arriving on the traffic channel. This will be pegged only if CAUAHATT was pegged for the same origination/ termination and it indicates that the ACCHO attempt has been successful.
sheet 13 of 225
CAUAHSUC
CAUAHFL
CAUCHRLS
Access robustness package performance (page 5-1) Access robustness package performance (page 5-1)
CAUAHRLS
CDMA
NBSS15.0
21-14 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUAUTH OM group CAUAORIG Description
Reference chapter Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1)
CAU AUTHentication. This OM group is pegged per systemwide basis. CAU Authenticatable ORIGination received. This OM is pegged when the CAU receives an origination message from a BTS which has authentication enabled. CAU Authenticatable REGistration received. This OM is pegged when the CAU receives a registration message from a BTS which has authentication enabled. CAU Authenticatable PaGe ReSponse received. This OM is pegged when the CAU receives a page response message from a BTS which has authentication enabled. CAU SSD Update request on Paging channel. This OM is pegged when the CAU sends a paging-channel-bound SSD update request to the BTS. CAU SSD Update Success on Access channel. This OM is pegged when the CAU receives an access-channel-originated SSD update success message from the BTS. CAU SSD Update Failure on Access channel. This OM is pegged when the CAU receives an access-channel-originated SSD update failure message from the BTS. CAU SSD Update request on Traffic channel. This OM is pegged when the CAU sends a traffic-channel-bound SSD update request to the SBS. CAU SSD Update Success on Traffic channel. This OM is pegged when the CAU receives a traffic-channel-originated SSD update success message from the SBS. CAU SSD Update Failure on Traffic channel. This OM is pegged when the CAU receives a traffic-channel-originated SSD update failure message from the SBS. CAU Unique Challenge request on Paging channel. This OM is pegged when the CAU sends a paging-channel-bound Unique Challenge request to the BTS.
sheet 14 of 225
CAUAREG
CAUAPGRS
CAUSUP
CAUSUSA
CAUSUFA
CAUSUT
CAUSUST
CAUSUFT
CAUUCP
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUUCCA Description
Reference chapter Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1)
CAU Unique Challenge Confirmation on Access channel. This OM is pegged when the CAU receives an access-channeloriginated Unique Challenge confirmation message from the BTS. CAU Unique Challenge request on Traffic channel. This OM is pegged when the CAU sends a traffic-channel-bound Unique Challenge request to the SBS. CAU Unique Challenge Confirmation on Traffic channel. This OM is pegged when the CAU receives a traffic-channeloriginated Unique Challenge confirmation message from the SBS. CAU Base Station Challenge received on Access channel. This OM is pegged when the CAU receives an access-channeloriginated Base Station Challenge message from the BTS. CAU Base Station Challenge Confirmation sent over Paging channel. This OM is pegged when the CAU sends a pagingchannel-bound Base Station Challenge Confirmation message to the BTS. This register is not pegged in MTX07 onwards. This is because currently the CM does not send a Base Station Challenge Confirmation over the paging channel in order to prevent a rogue mobile from reverse-engineering the authentication algorithm. CAU Base Station Challenge received on Traffic channel. This OM is pegged when the CAU receives a traffic-channeloriginated Base Station Challenge message from the SBS. CAU Base Station Challenge Confirmation sent over Traffic channel. This OM is pegged when the CAU sends a trafficchannel-bound base station confirmation message to the SBS. CAU Ssd Update request from CM. This OM is pegged when the CAU receives a SSD Update request from the CM. CAU Unique Challenge request from CM. This OM is pegged when the CAU receives a Unique Challenge request from the CM.
sheet 15 of 225
CAUUCT
CAUUCCT
CAUBSCA
CAUBSCCP
CAUBSCT
Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1) Authentication performance (page 15-1)
CAUBSCCT
CAUSUCM
CAUUCCM
CDMA
NBSS15.0
21-16 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUBSCCM Description
Reference chapter Authentication performance (page 15-1)
CAU Base Station Challenge confirmation received from CM. This OM is pegged when the CAU receives a Base Station Challenge confirmation message from the CM.
sheet 16 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUCPFRQ OM group Modified in 14.0 release MCTORIGS Description
Reference chapter MCTA performance (page 14-1)
CAU Call Processing per FReQuency. This OM group is pegged per Sector/Band/Freq. Note: The following OM is deleted in NBSS 13.0: MCTRECAP.
MCTa ORIGination. This OM is pegged, along with CAUOATTS, when the CAU receives an origination message from a sector that has MCTA enabled. It is pegged against the originating frequency. Test call originations are pegged in a separate OM. MCTa Origination ATTemptS. This OM is pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile origination in a sector with MCTA enabled. Please note that the MCTA frequency for MCTOATTS may be different from the MCTA frequency on which the call originated (MCTORIGS). MCTa Origination SUCCess. This OM is pegged, along with CAUOSUCC, when a mobile originated call successfully arrives on the traffic channel. This includes all originations placed on the traffic channel to receive treatment. MCTa PaGe RESponse. For mobile terminated calls, attempts are recorded in MCTPGRES which indicates that a page response was received from a CDMA sector in response to a page request. CAUPGRES is also pegged whenever MCTPGRES is pegged. This OM is pegged irrespective of whether it was the first or the second attempt to page the mobile. MCTa Termination ATTemptS. This OM is pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile termination in a sector with MCTA enabled. MCTa Termination SUCCess. This OM is pegged, along with CAUTSUCC, when a mobile-terminated call successfully arrives on the traffic channel.
sheet 17 of 225
MCTA performance (page 14-1) MCTA performance (page 14-1)
MCTOATTS
MCTOSUCC
MCTPGRES
MCTTATTS
MCTTSUCC
CDMA
NBSS15.0
21-18 MSC OM descriptions Nortel Networks MSC operational measurements Register MCTHCATT Description
MCTa hard Handoff Call ATTempts. This OM is pegged, along with CAUHATTS, when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector (that has MCTA enabled) should begin. Note: This register is pegged by the target CAU against the target cell/sector. MCTa Handoff ATTemptS. This OM is pegged when an MCTA frequency is successfully selected by the Carrier Determination Algorithm (CDA) for a mobile hard handoff attempt into a target sector with MCTA enabled. Note: This register is pegged by the target CAU against the target cell/sector. MCTa Hard-handoff SUCCess. This OM is pegged, along with CAUHSUCC, when a mobile successfully arrives on the traffic channel after a hard handoff. Note: This register is pegged by the target CAU against the target cell/sector. MCTa Handoff Radio Link FaiLure. This OM is pegged, along with CAUHRLFL, if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). Note: This register is pegged by the target CAU against the target cell/sector. MCTa Error case, Radio link Setup FaiLure. This OM is pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, whenever a call setup fails due to the fact that the BTS could not allocate resources due to any of the BTS failure reasons. This OM is also pegged when the BTS does not respond at all to resource requests. MCTERSFL is pegged only after an MCTA frequency is selected. MCTERSFL is pegged against the selected frequency. MCTa NO Traffic Channel Element. This OM is pegged, along with MCTERSFL and CAUNOTCE and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element via NOIS messages regardless of origination, termination or hard handoff. MCTNOTCE is pegged only after an MCTA frequency is selected. MCTNOTCE is pegged against the selected frequency.
sheet 18 of 225
MCTHATTS
MCTA performance (page 14-1)
MCTHSUCC
MCTHRLFL
MCTERSFL
MCTNOTCE
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MCTNOWCD Description
MCTa NO Walsh Code. This OM is pegged, along with MCTERSFL and CAUNOWCD and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS messages regardless of origination, termination or hard handoff. MCTNOWCD is pegged only after an MCTA frequency is selected. MCTNOWCD is pegged against the selected frequency. MCTa NO Frame Offset Failure. This OM is pegged, along with MCTERSFL and CAUNOFOF and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS can not allocate resources due to some CSM 5000 hardware limitation. The CSM5000 is limited in how much traffic it can support on its reverse link because of the limitation on the number of decoding units (both Viterbi and Turbo) that can be active on a frame offset (and adjacent frame offsets). MCTNOFOF is pegged only after an MCTA frequency is selected. MCTNOFOF is pegged against the selected frequency. MCTa ForWard CAPacity full. This OM is pegged, along with MCTERSFL and CAUFWCAP and CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via NOIS messages regardless of origination, termination or hard handoff. MCTFWCAP is pegged only after an MCTA frequency is selected. MCTFWCAP is pegged against the selected frequency. MCTa BTS BlocK. This OM is pegged, along with MCTERSFL, SCTBTSBK, CAUERSFL and the appropriate CAU*BLKS OM, anytime a BTS reports one of the following resource setup failure reasons via NOIS message regardless of origination, termination or hard handoff: no T1E1 backhaul resources are available no BCN link resources are available no ACN node IDs are available (unlikely to occur)
MCTNOFOF
MCTFWCAP
MCTBTSBK New OM in 13.0 release
Note: * = O, T or H MCTBTSBK is pegged only after an MCTA frequency is selected. MCTBTSBK is pegged against the selected frequency.
sheet 19 of 225
CDMA
NBSS15.0
21-20 MSC OM descriptions Nortel Networks MSC operational measurements Register MCTERLFL Description
MCTa Error case, Radio Link FaiLure. This OM is pegged, along with CAUERLFL, when the origination or termination fails because the mobile never arrived on the traffic channel (similar to SAT timeout). MCTERLFL is not pegged in cases where the CAUOBLKS or CAUTBLKS OMs are pegged. MCTA Request Time-out. This OM is pegged when a frequency was successfully selected by MCTA but one or more of the BTSs never responded to a capacity request. MCTAREQT is pegged against the carrier(s) that did not respond to the capacity request. MCTAREQT may not always be pegged under low traffic load conditions. MCTA REQuest response full or Not available. This OM is pegged when a frequency was successfully selected by MCTA but one or more of the BTSs responded with a resource full or not available response. MCTAREQN is pegged against the carrier(s) that respond with a resource full or not available response. MCTAREQN may not always be pegged under low load conditions. MCTA ReQuest response Failed full or Not available. This OM is pegged, along with CAUERSFL and MCTAMIXF and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because some BTSs timed-out while some responded with a resource full or not available response. MCTARQFN is pegged against the carrier(s) that respond with a resource full or not available response. MCTa DROPped Radio link. This OM is pegged, along with CAUDROPR, against the primary pilot when a call is dropped by the SBS due to loss of traffic or due to HCM (handoff completion message) timeout for soft or softer handoff. These are RF-related call failures as detected by the SBS. Loss of traffic is defined as the SBS failing to receive active reverse traffic frames from the mobile, which can happen either due to poor RF conditions between the mobile and the BTS, or due to a shortage of available link capacity between the SBS and BTS. Note that when there is a change of reference sector in the FCH active set for the call, the CAU is not informed of this change unless the previous reference sector (from the CAU perspective) has been dropped from the current active set. Therefore the MCTDROPR & CAUDROPR OMs may not get pegged against the actual reference sector for the call at the time of the drop.
sheet 20 of 225
MCTAREQT
MCTAREQN
MCTARQFN
MCTDROPR
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MCTREGIS Description
Reference chapter MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1)
MCTa REGIStration. This OM is pegged when the CAU receives an registration message from a sector that has MCTA enabled. It is pegged against the originating frequency. MCta Wireless Priority Service Origination RetrY. This OM will peg only when WPS is turned ON. Applicable only to WPS activated CDMA carriers. MCta Wireless Priority Service Termination RetrY. This OM will peg only when WPS is turned ON. Applicable only to WPS activated CDMA carriers.
sheet 21 of 225
MCWPSORY
MCWPSTRY
CDMA
NBSS15.0
21-22 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUCPSCT OM group Modified in 13.0 release Description
Reference chapter Call setup performance (page 2-1) Dropped call performance (page 6-1) MCTA performance (page 14-1) Paging performance (page 10-1)
CAU Call Processing SeCTor. Tracks events based on the primary sector. However, hard handoff events are tracked based on the target sector. Additional OMs related to Call Processing per sector are listed in the CAUSCT2 OM group. Note: The following OM is deleted in NBSS 13.0: CAURECAP.
CAUPGRES
CAU PaGe RESponse. For mobile terminated calls, attempts are recorded in CAUPGRES which indicates that a page response was received from a CDMA sector in response to a page request (irrespective of whether it was in response to an initial page request or a retry by the CM).
Call setup performance (page 2-1) Paging performance (page 10-1) Call setup performance (page 2-1)
CAUNOFOF
CAU NO Frame Offset Failure. This OM is pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no frame offset availability via NOIS messages regardless of origination, termination or hard handoff. Note: * = O, T or H. When MCTA is enabled, if there is a failure to select a carrier for call setup (i.e. none of the co-located carriers indicated that it has resources available for the call setup), CAUNOFOF does not get pegged. CAUNOFOF is pegged only after an MCTA frequency is selected.
CAUTSUCC
CAU Termination SUCCess. CAUTSUCC is pegged when a mobile-terminated call successfully arrives on the traffic channel. Note: This OM is used to classify calls as established.
Call setup performance (page 2-1) Dropped call performance (page 6-1)
sheet 22 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUTBLKS Description
CAU Termination BLocKS. CAUTBLKS is pegged any time a mobile-terminated call setup fails due to resource shortage. It represents all of the termination setup failures (Blocks) in a sector, regardless of resource. One or more of the following call setup failure reasons is pegged in conjunction with CAUTBLKS: RMUIANRV, RMURANRV, RMSRMNAK, RMSRMTO, CAUERSFL, CAUNOTCE, CAUNOWCD, CAUNOFOF, CAUFWCAP, SCTBTSBK and CAUESWFL.
CAUTRLS
CAU Termination ReLeaSed. CAUTRLS is pegged when a mobile terminated call is released. This OM is pegged when the mobile sends a release after sending the page response and before it sends service connect completion message. This OM is also pegged if CM sends a release message to CAU before Mobile sends service connect completion message. For example, calling party ending the call before Mobile sends service connect completion message. CAU Origination ATTemptS. This OM is pegged when the CAU receives an origination message from the BTS. Test call originations are pegged in a separate OM. CAU Origination SUCCess. CAUOSUCC is pegged when a mobile-originated call successfully arrives on a CDMA traffic channel. Note: This OM is used to classify calls as established.
CAUOATTS
Call setup performance (page 2-1) Call setup performance (page 2-1) Dropped call performance (page 6-1)
CAUOSUCC
CAUOBLKS
CAU Origination BLocKS. CAUOBLKS is pegged any time a mobile-originated call setup fails due to resource shortage. It represents the total number of origination setup failures (Blocks) in a sector, regardless of resource. The same failure reasons that are pegged for CAUTBLKS can be pegged in conjunction with CAUOBLKS.
sheet 23 of 225
CDMA
NBSS15.0
21-24 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUORODR Description
CAU Origination ReOrDeR. The CM can send reorder commands to the mobile originators whose calls will not be set up. These situations can occur by datafilling a treatment with the MOBRODR or MOBICPT CLLI instead of an announcement or tone CLLI in table TMTCNTL. CAUORODR is pegged when the CAU receives a reorder or intercept message from the CM indicating that the origination is intentionally stopped without putting the mobile on the traffic channel. CAUORODR is also pegged if the service option received from the mobile is invalid and the CM sends a release message to the CAU indicating a reorder message is to be sent to the mobile so that it will retry the origination with an updated service option. CAU Origination ReLeaSed. CAUORLS is pegged when a mobile-originated call is released by the mobile station or the CM before the mobile sends a service connect completion message. For example, Mobile failing authentication due to nonsubscription of service, this can also happen when user ends the call attempt before Mobile sends a service connect completion message. CAU Error case, Radio Setup FaiLure. CAUERSFL is pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails due to the fact that some BTS resource is not available. This OM is also pegged when the BTS does not respond to resource requests. It is also pegged when the Carrier Determination Algorithm (CDA) fails to select a carrier in an MCTA enabled sector (i.e. No available capacity on all colocated carriers). Note: * = O, T or H. CAU NO Traffic Channel Element. This OM is pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no traffic channel element via NOIS messages regardless of origination, termination or hard handoff. Note: * = O, T or H. When MCTA is enabled, if there is a failure to select a carrier for call setup (i.e. none of the co-located carriers indicated that it has resources available for the call setup), CAUNOTCE does not get pegged. CAUNOTCE is pegged only after an MCTA frequency is selected.
sheet 24 of 225
CAUORLS
CAUERSFL
CAUNOTCE
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUNOWCD Description
CAU NO Walsh Code. This OM is pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports no walsh code via NOIS messages regardless of origination, termination or hard handoff. Note: * = O, T or H. When MCTA is enabled, if there is a failure to select a carrier for call setup (i.e. none of the co-located carriers indicated that it has resources available for the call setup), CAUNOWCD does not get pegged. CAUNOWCD is pegged only after an MCTA frequency is selected.
CAUFWCAP
CAU ForWard CAPacity full. This OM is pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports forward capacity full via NOIS messages regardless of origination, termination or hard handoff. Note: * = O, T or H. When MCTA is enabled, if there is a failure to select a carrier for call setup (i.e. none of the co-located carriers indicated that it has resources available for the call setup), CAUFWCAP does not get pegged. CAUFWCAP is pegged only after an MCTA frequency is selected.
SCTBTSBK New OM in 13.0 release
SeCTor BTS BlocK. This OM is pegged, along with CAUERSFL and the appropriate CAU*BLKS OM, any time a BTS reports one of the following resource setup failure reasons via NOIS messages regardless of origination, termination or hard handoff: - no T1E1 backhaul resources are available - no BCN link resources are available - no ACN node IDs are available (unlikely to occur) When MCTA is enabled, if there is a failure to select a carrier for call setup (i.e. none of the co-located carriers indicated that it has resources available for the call setup), SCTBTSBK does not get pegged. SCTBTSBK is pegged only after an MCTA frequency is selected.
CAUEDLOT
CAU Error Drop Loss Of Traffic. This OM is pegged when the mobile drops of the traffic channel after the Radio Link Setup Response is received but before the Service Connect Response is received. This scenario is considered an access failure. The register CAUERLFL is also pegged in conjunction with this register.
sheet 25 of 225
CDMA
NBSS15.0
21-26 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUESWFL Description
CAU Error case, SoftWare FauLt. This OM is pegged, along with the appropriate CAU*BLKS OM, whenever a call setup fails due to time outs between software entities that should not occur (for example: no response from the CM, failure message received from SBS). Note: * = O, T or H. Note that this OM doesnt peg for the following error conditions: When CAU times out waiting for the Resource Allocation Response from RMU. When RMU reports to CAU the TimeSlot (TID) mismatch for SRM entry between Table SBSINV on CM and SRM response to RMU.
The above error conditions are covered in BSCRM:RMUIOENV at CAU. CAUERLFL CAU Error case, Radio Link FaiLure. This OM is pegged if the origination or termination fails because the mobile never arrived on the traffic channel. This OM is pegged in the following scenarios: 1. If the CAU does not receive the Radio Link Setup Response message after it sent the CAM/ECAM/MECAM. 2. If SOM Service Connection Response message timeout for voice/packet data call origination/termination. 3. If SOM Service Connection Response message containing SOM failure code som_status_external_failure is received for voice/packet data call origination/termination. Call setup performance (page 2-1)
SLTPGRES
SLoTted mode PaGe RESponse. This OM is the equivalent of CAUPGRES except that it is pegged by the CAU only in response to a slotted mode page request. Slotted mode paging is measured separately so that performance differences can be determined. SLTPGRES is a subset of the CAUPGRES. Note: Pegged only for slotted mode termination attempts
sheet 26 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUHATTS Description
CAU Handoff ATTemptS. This OM is pegged when the CAU receives a ReadyNewCell message from the CM, indicating that a hard handoff attempt sequence in a (CDMA) target sector should begin. Note: Pegged by the target CAU against the target cell/sector. In the case of Multi Pilot Hard Handoff (MPHHO), the CAUHATTS OM is pegged against the first target sector in the target list.
CAUHBLKS
CAU Handoff BLocKS. This OM is pegged any time a CDMA-toCDMA hard handoff setup fails due to resource shortage. It represents all of the hard handoff setup failures into a sector, regardless of resource. This OM is pegged for both inter- and intra-system hard handoff attempts. CAUHBLKS is not the number of dropped hard handoffs, it merely represents the number of times that a hard handoff could not be completed due to resource shortages in the target cell/sector--the call in the source cell is still up. The same failure reasons that are pegged for CAUOBLKS can be pegged in conjunction with CAUHBLKS. Note: Pegged by the target CAU against the target cell/sector. In the case of Multi Pilot Hard Handoff (MPHHO), the CAUHBLKS OM is pegged against the first target sector in the target list.
CAUHRLFL
CAU Handoff Radio Link FaiLure. This OM is pegged if the hard handoff attempt fails because the mobile never arrived on the target sectors traffic channel (similar to SAT timeout). CAUHRLFL is not pegged in cases where CAUHBLKS is pegged. This OM is pegged by the target CAU against the target cell/sector. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the CAUHRLFL OM to peg against a different sector than the CAUHATTS OM. While the CAUHATTS OM is always pegged against the first target sector in the target list, the CAUHRLFL OM is pegged against the first target sector in the target list in which resources are setup successfully. Note: For voice calls only, if a 3G to 2G BTS downgrade occurs in the selected target sector, then this OM will be pegged in the CAUCPSCT (2G) OM group even though the CAUHATTS OM was pegged in the CAUSCT3V (3G) OM group.
sheet 27 of 225
CDMA
NBSS15.0
21-28 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUHSUCC Description
Reference chapter Call setup performance (page 2-1) Dropped call performance (page 6-1)
CAU Handoff SUCCess. This OM is pegged when a mobile, attempting a hard handoff, successfully arrives on the traffic channel in the target sector. Note: This OM is used to classify calls as established. Pegged by the target CAU against the target cell/sector. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the CAUHSUCC OM to peg against a different sector than the CAUHATTS OM. While the CAUHATTS OM is always pegged against the first target sector in the target list, the CAUHSUCC OM is pegged against the first target sector in the target list in which resources are setup successfully. Note: For voice calls only, if a 3G to 2G BTS downgrade occurs in the selected target sector, then this OM will be pegged in the CAUCPSCT (2G) OM group even though the CAUHATTS OM was pegged in the CAUSCT3V (3G) OM group.
CAUHRLS
CAU Handoff ReLeaSed. This OM is pegged during a hard handoff attempt when a call setup in a target cell is released by the source system before the mobile arrives on the traffic channel. Note: Pegged by the target CAU against the target cell/ sector. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the CAUHRLS OM to peg against a different sector than the CAUHATTS OM. While the CAUHATTS OM is always pegged against the first target sector in the target list, the CAUHRLS OM is pegged against the first target sector in the target list in which resources are setup successfully. The CAUHRLS OM will peg against the first target sector if the release takes place prior to resource setup. Note: For voice calls only, if a 3G to 2G BTS downgrade occurs in the selected target sector, then this OM will be pegged in the CAUCPSCT (2G) OM group even though the CAUHATTS OM was pegged in the CAUSCT3V (3G) OM group.
sheet 28 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUHINIT Description
CAU Handoff INITiated. This OM is pegged against the first target sector in the target list in which resources are setup successfully for a hard handoff attempt. Note that for any given hard handoff attempt, the CAUHSUCC OM or CAUHRLFL OM will get pegged against the same sector as the CAUHINIT OM, but the CAUHATTS OM could be pegged against a different sector in the cases when the first sector in the target list does not have resources available. This OM is pegged by the target CAU against the target cell/sector. Note: For voice calls only, if a 3G to 2G BTS downgrade occurs in the selected target sector, then this OM will be pegged in the CAUCPSCT (2G) OM group even though the CAUHATTS OM was pegged in the CAUSCT3V (3G) OM group. CAU DROPped call Rf. This OM is pegged, along with MCTDROPR, by the CAU against the primary pilot when a call is dropped by the SBS due to loss of traffic. Loss of traffic is defined as the SBS failing to receive active reverse traffic frames from the mobile, which can happen either due to poor RF conditions between the mobile and the BTS, or due to a shortage of available link capacity between the SBS and BTS. Note that when there is a change of reference sector in the FCH active set for the call, the CAU is not informed of this change unless the previous reference sector (from the CAU perspective) has been dropped from the current active set. Therefore the CAUDROPR OM may not get pegged against the actual reference sector for the call at the time of the drop.
sheet 29 of 225
CAUDROPR
Dropped call performance (page 6-1)
CDMA
NBSS15.0
21-30 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUDROPN Description
Reference chapter Dropped call performance (page 6-1)
CAU DROPped call Network. This OM is pegged by the CAU when any non-RF drop indication reasons are sent from the SBS in the radio link drop indication message. The following are the network-related call drop reasons that will cause CAUDROPN to be pegged: RLM locked: Initiated by the network management during maintenance, the RLM is locked and hence the calls handled by that RLM should be dropped. TCE locked: Initiated by the network management during maintenance, the TCE is locked and hence the calls using that TCE should be dropped. Trunk problem: The selector (example: SBS) is taking down the call due to the DS0 becoming unavailable/unequipped (detected during maintenance). Selector problem: The selector receives a request from the CAU to release SBS resources without going through the proper procedure of releasing the call. This is an error case. Note that when there is a change of reference sector in the FCH active set for the call, the CAU is not informed of this change unless the previous reference sector (from the CAU perspective) has been dropped from the current active set. Therefore the CAUDROPN OM may not get pegged against the actual reference sector for the call at the time of the drop. MCTa Handoff ReQuest Failure. This OM is pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for a hard handoff call setup. It is pegged on a Per-Sector basis on the target side. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU. Note: This register is pegged by the target CAU against the target cell/sector. MCTa MIXed Failure. This OM is pegged, along with CAUERSFL and MCTARQFN and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because some BTSs timed-out while some responded with a resource full or not available response.
MCTAHRQF
Call setup performance (page 2-1) MCTA performance (page 14-1) Call setup performance (page 2-1) MCTA performance (page 14-1) MCTA performance (page 14-1)
MCTAMIXF
MCTALLTO
MCTa ALL frequencies Timed-Out. This OM is pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because none of the BTSs responded to the capacity request query.
sheet 30 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MCTALLFU Description
Reference chapter MCTA performance (page 14-1) Call setup performance (page 2-1) MCTA performance (page 14-1)
MCTa ALL frequencies FUll. This OM is pegged, along with CAUERSFL and (MCTAREQF or MCTAHRQF), when NO frequency was successfully selected by MCTA because none of the BTSs had resources available. MCTA REQuest Failure. This OM is pegged, along with CAUERSFL, when NO frequency was successfully selected by MCTA for origination or termination call setup. It is pegged on a Per-Sector basis. The failure reasons are pegged by MCTAMIXF, MCTALLTO or MCTALLFU.
MCTAREQF
sheet 31 of 225
CDMA
NBSS15.0
21-32 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUCPSYS OM group Modified OM group in 13.0 release Description
Reference chapter Call setup performance (page 2-1) Paging performance (page 10-1) Handoff performance (page 7-1)
CAU Call Processing SYStem. This OM group tracks events on a per-CAU basis. This OM group has the following OMs deleted: CAUTMWNR This OM group has the following OMs moved to the CAUDATSY OM group: CAUPMWNA, CAUPMWNC, CAUPMWNR, CAUTMWNA, CAUTMWNC
CAUPGREQ
CAU PaGe REQuest. This OM is pegged whenever the CAU receives a page request from the CM. CAUPGREQ is necessary to know how many paging attempts are being processed by a single CAU.Prior to MTX15 this OM pegged only for voice call page requests. In MTX15, this register is modified to peg for Packet Data Call Termination (Dormant to Active) paging requests as well. CAU ORIGinationS. This OM is kept on a per-CAU basis, as opposed to the way that CAUOATTS is kept on a per-sector basis. This OM is necessary because the CAUOATTS OM is consolidated at the CM with the originations handled by other CAUs for the same sector, therefore hiding the number of originations handled by any one CAU. CAUORIGS is pegged every time that CAUOATTS is pegged--whenever a voice origination message is received from a mobile. CAU REGistratioNS. This OM is pegged when the CAU receives a registration notification from the mobile. This OM in conjunction with CAUORIGS is useful to determine how the CIU load distribution is performing. CAU HandOff SouRCe. This OM is pegged when the CAU receives a hard handoff or intersystem handoff request from the SBS. This OM is pegged by the source system only. CAU HandOff TaRGet. This OM is pegged when the CAU receives a ReadyNewCell message from the CM to prepare a cell for handoff. Note: Pegged per target CAU basis. CAU Handoff SOFT. This OM is pegged when the CAU receives an indication that the mobile has completed a soft/softer handoff that resulted in a reference or primary cell change.
sheet 32 of 225
CAUORIGS
CAUREGNS
Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Handoff performance (page 7-1)
CAUHOSRC
CAUHOTRG
CAUHSOFT
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUCNICV Description
Reference chapter Call setup performance (page 2-1) Call setup performance (page 2-1) Paging performance (page 10-1) Call setup performance (page 2-1) Call setup performance (page 2-1)
CAU Calling Number Identification during ConVersation. This OM is pegged when the CAU sends a CNI notification to the mobile when the mobile is already in the conversation state. CAU Calling Number Identification during TeRmination. This OM is pegged when the CAU sends a CNI notification to the mobile in the process of call setup. SLoTted mode PaGe REQuest. This OM is pegged when a page request is received from the CM for a mobile which is operating in slotted mode. Note: Pegged only for slotted mode termination attempts CAU FLASH message received. This OM is pegged when the CAU receives a flash message from the SBS to be forwarded to the CM. CAU Mobile-initiated ReLeaSe. This OM is pegged when the radio link release message is received by the serving CAU from the serving ESEL/ACP card. The radio link release message is sent as a result of Mobile sending a release to the serving ESEL/ACP. Note: In case of a packet data call, ESEL/ACP sends a radio link release message to the CAU when a R-P Session setup fails at PCU.
CAUCNITR
SLTPGREQ
CAUFLASH
CAUMRLS
CAULRLS
CAU Land ReLeaSe. This OM is pegged when the call is released by a party other than the mobile being served by the CAU pegging this register. This in not necessarily a Land Release. Network-Initiated Short Data Burst ATTempts. This OM is pegged when the CAU receives a Short Data Burst message from the PCU to send to the mobile. SDB is being considered for future release, and therefore this register will not get pegged. Note: This is a 3G related OM. Network-Initiated Short Data Burst SuCcess. This OM is pegged when the CAU receives a response from the mobile to the SDB message sent. SDB is being considered for future release, and therefore this register will not get pegged. Note: This is a 3G related OM.
sheet 33 of 225
Call setup performance (page 2-1) Call setup performance (page 2-1)
NISDBATT
NISDBSC
CDMA
NBSS15.0
21-34 MSC OM descriptions Nortel Networks MSC operational measurements Register NISDBFL Description
Network-Initiated Short Data Burst FaiLure. This OM is pegged when the CAU times out waiting for a response from the mobile to the SDB message sent. SDB is being considered for future release, and therefore this register will not get pegged. Note: This is a 3G related OM. CAU DUPlicate PaGe response. This OM is pegged when a duplicate page response is received before the call is setup. Log CDMA100 is printed. CAU UNeXpected PaGe response. This OM is pegged when an unexpected page response is received by the CAU.
sheet 34 of 225
CAUDUPPG
CAUUNXPG
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUDAT3G OM group Description
CAU DATa 3G. This group captures mobile-initiated Short Data Burst (SDB) events that take place during dormant 3G Packet Data calls. It is pegged on a per Sector basis. Note: This is a 3G related OM group. Note: The OMs SDPCULKR, SDPCULKF, MISDBSC, MISDBFL have been removed from this OM group.
MISDBATT New OM in release 13.0
Mobile Initiated Short Data Burst ATTempted to send. This OM is pegged when a R-SDB is received at the CAU from the BTS. The R-SDB was sent to the BTS from the mobile, on the REACH.
sheet 35 of 225
CDMA
NBSS15.0
21-36 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUDATSC OM group Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
CAU DATa processing SeCTor. This OM group is pegged on a per Sector basis.
SMOATITC
SMs Origination ATtempt over Idle Traffic Channel. This OM is pegged when the CAU receives a SMS DataBurst message from the mobile after it has moved from the Access channel to the Traffic channel following a SMS Origination call setup request. SMs Origination ATTempt over the Access Channel. This OM is pegged when the CAU receives a SMS DataBurst message from an idle mobile over the Access Channel. This OM tracks the number of SMS messages that the mobile attempted to send over the Access Channel. SMS Origination ResourCe Allocation FaiLures.This OM is pegged when mobile originated SMS call setup fails over the idle TCH (in order for mobile to send a long SMS message) due to any failures during SBS resource allocation phase. The failures during resource allocation include lack of SBS resource or any software error condition. SMs Origination Call Setup Failure over the Traffic Channel. This OM is pegged when Call Setup over the Idle Traffic Channel (in order for the mobile to send a long SMS message) does not succeed. This OM tracks the number of times an idle mobile was unsuccessful in moving from the Access Channel to the Traffic Channel for purpose of sending a long SMS message. This OM is pegged for all failures including access failures except failures during SBS resource allocation. SMs Origination Call Setup Request over the Access Channel. This OM is pegged when the CAU receives a Origination message with service option 6 from an idle mobile over the Access Channel. This message is received from the mobile requesting to be switched from Access to Traffic Channel in order to send a long SMS message. This OM tracks the number of attempts made by a mobile to setup a traffic channel in order to send an SMS message.
sheet 36 of 225
SMOATTAC
SMSORCFL New OM in 14.0 release
SMOCSFTC Modified in 14.0 release
SMOCSRAC
Data burst message delivery performance (page 12-1)
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SMOCSSTC Description
Reference chapter Data burst message delivery performance (page 12-1) Call resource allocation and management (page 16-1)
SMs Origination Call Setup Successful over the Traffic Channel. This OM is pegged when the mobile is successfully ordered to an Idle Traffic Channel for purpose of sending a long SMS message. This OM tracks the number of times an idle mobile successfully moved from the Access Channel to the Traffic Channel for purpose of sending a long SMS message. SMs Origination FAIlure over the Access Channel. This OM is pegged when the CAU sends an unsuccessful SMS DataBurst Acknowledgment message to an idle mobile over the Paging Channel. This OM tracks the number of access channel SMS messages sent by the mobile that the CAU was not successful in sending on to the SMS Message Center (SMSMC). This OM is also pegged: if the CAU is not able to successfully decode the SMS message received from the mobile; if a negative acknowledgment is received from the SMS MC; or if the Acknowledgement from the SMS MC does not reach the CM. SMs Origination FAilure over Idle Traffic Channel. This OM is pegged when the CAU sends an unsuccessful SMS DataBurst Acknowledgment message to an idle mobile over the traffic Channel. This OM tracks the number of traffic channel SMS messages sent by the mobile that the CAU was not successful in sending on to the SMS Center. This OM is also pegged: if the CAU was not able to successfully decode the SMS message received from the mobile; if the SMS data burst message could not successfully be sent to the CM; if a negative acknowledgment is received from the SMS MC; or if the Acknowledgement from the SMS MC does not reach the CM. Note: SMOFAITC is not pegged when there is a release from the mobile while CAU is waiting for the SMS data burst from the mobile after the traffic channel is setup.
SMOFAIAC Modified in 13.0 release
SMOFAITC Modified in 13.0 release
SMOSUCAC
SMs Origination SUCcessful over the Access Channel. This OM is pegged when the CAU sends a successful SMS DataBurst Acknowledgment message to an idle mobile over the Paging Channel. This OM tracks the number of access channel SMS messages sent by the mobile that the CAU was successful in sending on to the SMS Center.
sheet 37 of 225
CDMA
NBSS15.0
21-38 MSC OM descriptions Nortel Networks MSC operational measurements Register SMOSUITC Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
SMs Origination SUccessful over Idle Traffic Channel. This OM is pegged when the CAU sends a successful SMS DataBurst Acknowledgment message to an idle mobile over the Traffic Channel. This OM tracks the number of traffic channel SMS messages sent by the mobile that the CAU was successful in sending on to the SMS Center. SMS ORder to channel ATtempts. This OM is pegged when an attempt is made to order the mobile to the traffic channel for purpose of delivering a short message.
SMSORATS
SMSORSUC
SMS ORder to channel SUCcess. This OM is pegged when the mobile is successfully ordered to the traffic channel for purpose of delivering a short message.
SMSPGRES
SMS PaGe RESponse. This OM is pegged when a mobile responds to an initial page request within the number of seconds defined by the office parameter MTX_CAU_PAGE_TIMEOUT. Note: This OM counts all CDMA SMS page responses received by the CAU, including slotted and non-slotted mode. SMS Page Retry RESponse. This OM is pegged when a mobile responds to a page retry request within the number of seconds defined by the office parameter MTX_CAU_PAGE_TIMEOUT. Note: This OM counts all CDMA SMS page responses received by the CAU, including slotted and non-slotted mode. SMS Termination ATtempts over the PaGing channel. This OM is pegged when an attempt is made to send a short SMS message to a mobile over the paging channel (i.e. when a decision is made that the SMS is short enough to be sent over the paging channel after receiving a page response from the mobile). SMS Termination FaiLure over the PaGing channel. This OM is pegged upon the failure to deliver the short message to a mobile over the paging channel (i.e. the CAU receives an SMS Delivery Response message with unsuccessful cause code from the BTS). This OM is not pegged if there is no Ack to the message.
sheet 38 of 225
SMSPRRES
SMSTATPG
SMSTFLPG
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SMSTFLTC Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
SMS Termination FaiLure over the Traffic Channel to an idle mobile. This OM is pegged upon the failure to deliver a short message to an idle mobile over the forward traffic channel (i.e. when the CAU receives SMS Delivery Response with unsuccessful cause code from an idle mobile, or if no ACK is received from the mobile). SMS Termination MisCellaneous call setup FaiLure. This OM is pegged when the short message cannot be delivered to an idle mobile over the forward traffic channel due to the failure of setting up the forward traffic channel due to lack of resources (BTS resources) or the failure of the mobile to arrive on the traffic channel (i.e. access failure). SMS Termination ResourCe FaiLure. This OM is pegged when the short message cannot be delivered to an idle mobile over the forward traffic channel due to the failure of setting up the forward traffic channel during SBS resource allocation. The failures during resource allocation include lack of SBS resources or any software error condition. SMS Termination SuCcessful over the PaGing channel. This OM is pegged when a short message has been successfully delivered to a mobile over the paging channel (i.e. when the CAU receives a successful SMS Delivery Response message from the BTS). SMS Termination SuCcessful over the Traffic Channel to an idle mobile. This OM is pegged when a short message is successfully delivered to an idle mobile over the forward traffic channel (i.e when the CAU receives a successful SMS Data Delivery Response message from an idle mobile). SMs Origination ATtempt over Busy Traffic Channel. This OM is pegged when the CAU receives a SMS DataBurst message from a mobile already in a call. This OM tracks the number of times mobiles attempt to send a SMS message while they are already in a call.
sheet 39 of 225
SMSTMCFL Modified in 14.0 release
SMSTRCFL
SMSTSCPG
SMSTSCTC
SMOATBTC
CDMA
NBSS15.0
21-40 MSC OM descriptions Nortel Networks MSC operational measurements Register SMOFABTC Modified in 13.0 release Description
Reference chapter Data burst message delivery performance (page 12-1)
SMs Origination FAilure over Busy Traffic Channel. This OM is pegged when the CAU sends an Unsuccessful SMS DataBurst Acknowledgment message to a mobile already in a call. This OM tracks the number of in-call SMS messages sent by the mobile that the CAU was not successful in sending on to the SMS Center. This OM is also pegged: if the CAU was not able to successfully decode the SMS message received from the mobile; if the CAU was not able to deliver the SMS message to the CM; if a negative acknowledgment is received from the SMS MC; or if the Acknowledgement from the SMS MC does not reach the CM. Note: This OM is also pegged if the CAU receives an acknowledgement from the CM for an SMS Origination Failure Over a Busy Traffic Channel even though the mobile did not request an acknowledgment.
SMOSUBTC Modified in 13.0 release
SMs Origination SUccessful over Busy Traffic Channel. This OM is pegged when the CAU sends a Successful SMS DataBurst Acknowledgment message to a mobile already in a call. This OM tracks the number of in-call SMS messages sent by the mobile that the CAU was successful in sending on to the SMS Center. Note: This OM is also pegged if CAU receives an acknowledgement from the CM for an SMS Origination Success Over a Busy Traffic Channel even though the mobile did not request an acknowledgment.
SMSDVCAT
SMS DeliVery in Call ATtempts. This OM is pegged when an attempt is made to deliver a short message to a mobile active in a call.
Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
SMSDVCFL Modified in 13.0 release
SMS DeliVery in Call FaiLure. This OM is pegged upon the failure to deliver a short message to a mobile active in a call (for instance, when the CAU receives SMS Delivery Response with unsuccessful cause code from the mobile, or if no ACK is received from the mobile). This OM is also pegged when an encoding problem occurs during voice call setup (origination or termination leg) while sending an SMS message to a mobile.
sheet 40 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SMSDVCSC Description
SMS DeliVery in Call SuCcess. This OM is pegged when a short message has been successfully delivered to mobile active in a call.
sheet 41 of 225
CDMA
NBSS15.0
21-42 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUDATS2 OM group Added in 14.0 release SMSTATTC Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
CAU DATa processing Sector 2. This OM group is an extension of the CAUDATSC OM group. The OMs in this OM group are pegged on a per sector basis.
SMS Termination ATtempt over the Traffic Channel to an idle mobile. This OM is pegged when an attempt is made to deliver a SMS to an idle mobile over traffic channel (i.e. when the CAU receives a Forward Data Delivery message from the CM and decides to send an SMS Data Burst Cmd message to the SBS). This OM is pegged on a per-sector basis and is found in CAUDATS2 group.
sheet 42 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUDATSY OM group Modified in 13.0 release Description
Reference chapter Paging performance (page 10-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
CAU DATa processing SYstem. This OM group is pegged on a per CAU basis. This OM group has the following OMs moved from the CAUCPSYS OM group: CAUPMWNA, CAUPMWNC, CAUPMWNR, CAUTMWNA, CAUTMWNC
SMODBRTO
SMs Origination DataBurst Received TimeOut. This OM is pegged after the CAU has timed out without receiving a SMS Mobile Origination DataBurst request from the mobile. This OM tracks the SMS Mobile Origination failures due to not receiving SMS Mobile Origination DataBurst requests from the Idle mobile over the Traffic Channel after a successful Call Setup SMS PaGe ReQuest. This OM is pegged when a CAU receives a SMS page request from the CM.
SMSPGREQ
SMSPGRTO
SMS PaGe Retry Time-Out. This OM is pegged after the CAU has timed out without receiving a page response for page retry request.
SMSPGRTY
SMS PaGe ReTrY. This OM is pegged when a CAU receives a SMS page retry request from the CM.
SMSPGTO
SMS PaGe Time-Out. This OM is pegged after the CAU has timed out without receiving a page response for initial page request.
sheet 43 of 225
CDMA
NBSS15.0
21-44 MSC OM descriptions Nortel Networks MSC operational measurements Register SMOCMREQ Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Paging performance (page 10-1)
SMs Origination CM REQuest. This OM is pegged when the CAU sends a SMS Mobile Origination request to the CM to be passed on to the SMS center.
SMOCMRES
SMs Origination CM RESponse. This OM is pegged when the CAU receives a SMS Mobile Origination response from the CM to be passed on to the mobile. This response need not be a successful response. SMs Origination CM Request Time-Out. This OM is pegged when the CAU times-out while waiting for a SMS Mobile Origination response from the CM to be passed on to the mobile. CAU Paging channel Message Waiting Notification Attempt. This OM is pegged when the CAU receives an MWI command message from CM and delivers the MWI to the system-wide or zone sends it over Paging Channel to an idle mobile. Note: This OM is only pegged for the first page attempt for MWI under one of the following two conditions: (1) When Qual_Dir (for pending message indication) message is sent from HLR to MSC; (2) When Mobile Station registers when page retry is not activated and Intelligent Zone Paging is activated. CAU Paging channel Message Waiting Notification Completion. This OM is pegged when CAU receives a response from the mobile for a paging channel MWI (IS-95A feature notification message) message that was sent to the system-wide or zone. Note: This OM is pegged for the following conditions: (1) During registration, when MWI page retry is not allowed and Intelligent Paging is activated, it is pegged for the first successful page attempt; (2) During Qual_Dir from HLR to MSC i.e. for a pending message, it is pegged for the first successful page attempt. CAU Paging channel Message Waiting Notification Timeout. This OM is pegged when CAU times out waiting for the acknowledgement for its first system-wide or zone page attempt for MWI on Paging Channel.
sheet 44 of 225
SMOCMRTO
CAUPMWNA Modified in 13.0 release
CAUPMWNC
Paging performance (page 10-1)
CAUPMWNT New OM in 13.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUPMWRA New OM in 13.0 release Description
Reference chapter Paging performance (page 10-1)
CAU Paging channel Message Waiting notification Retry Attempt. This OM is pegged when the CAU attempts to send system-wide or zone page retry for MWI on Paging Channel (PCH). This OM is pegged for the following conditions: (1) When CM does not receive the acknowledgement for its first Last Known Cell page for MWI on PCH, CM sends system-wide or zone page retry request for MWI to CAU, this OM is pegged; (2) When CM does not receive the acknowledgement for its first page attempt for MWI on PCH sent to the system wide or zone, CM sends system-wide or zone page retry request for MWI to CAU, this OM is pegged. CAU Paging channel Message Waiting Notification completion upon Retry. This OM is pegged when a mobile responds to a paging channel MWI (IS-95A feature notification message) message for the Retry page sent for MWI. Note: This OM is pegged for the following conditions: (1) During registration, when MWI page retry is allowed, it is pegged for the response received from the Mobile for a retry attempt sent for MWI Page attempt only; (2) During Qual_Dir from HLR to MSC i.e. for a pending message, it is pegged for the response received from Mobile for a retry page attempt sent for MWI if retry is allowed. CAU Paging channel Message Waiting Retry notification Timeout. This OM is pegged when the CAU times out waiting for the acknowledgement for its system-wide or zone page retry attempt for MWI on Paging Channel (PCH). CAU last known Bts Message Waiting Notification Attempt. This OM is pegged when the CAU attempts to send a page request for MWI to the mobile on the paging channel of the cell where the mobile is registering from. Note: This OM is pegged for the following conditions: (1) During registration, when MWI page retry is allowed, it is pegged for the first page attempt; (2) During registration, when MWI page retry is not allowed and Intelligent Paging is not activated, it is pegged for the first and only page attempt. Note that this OM is not pegged for any other situations.
sheet 45 of 225
CAUPMWNR
CAUPMWRT New OM in 13.0 release CAUBMWNA
Paging performance (page 10-1) Paging performance (page 10-1)
CDMA
NBSS15.0
21-46 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUBMWNC Description
CAU last known Bts Message Waiting Notification Completion. This OM is pegged when the CAU receives acknowledgement from the mobile on the access channel when a first page is sent to the only one BTS where the mobile is registering from. Note: This OM is pegged for the following conditions: (1) During registration, when MWI page retry is allowed, it is pegged for the first successful page attempt; (2) During registration, when MWI page retry is not allowed and Intelligent Paging is not activated, it is pegged for the first successful page attempt. CAU last known Bts paging channel Message Waiting Notification Timeout. This OM is pegged when the CAU times out waiting for the acknowledgement for its first page attempt for MWI sent to Last Known Cell only. CAU Traffic channel Message Waiting Notification Attempt. This OM is pegged when the CAU attempts to send a page request for MWI to the mobile on the traffic channel without performing any prior page attempts for MWI on PCH. CAU Traffic channel Message Waiting Notification Completion. This OM is pegged when the CAU receives acknowledgement from the mobile for a traffic channel page request for MWI. CAU Traffic channel Message Waiting Notification attempt Timeout. This OM is pegged when the CAU times out waiting for acknowledgement for page request for MWI on Traffic Channel (TCH). CAU Traffic channel Message Waiting Notification Retry Attempt. This OM is pegged when the CAU attempts to send retry page request for MWI on the Traffic Channel if the first page for MWI sent on paging channel has timed out and mobile has moved to traffic channel.
sheet 46 of 225
CAUBMWNT New OM in 13.0 release CAUTMWNA Modified OM in 13.0 release CAUTMWNC
Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1)
CAUTMWNT New OM in 13.0 release CAUTMWRA New OM in 13.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUMWSIS New OM in 13.0 release Description
CAU MWi Suspended in call Initial Setup. This OM is pegged when CAU does not perform retry MWI page request on traffic channel or paging channel after first MWI page request times out on paging channel. (MWI Page retry is activated at CM) The following are the conditions when retry MWI Page request is not performed: (1) The mobile is in a call initial setup state as an originator (2) There is an error when CAU sends MWI Page. (3) The terminator Mobile (that was previously in ringing state) answers the call. (4) The terminator Mobile (that was previously in ringing state) performs an intra-system hard-handoff to another cell.
sheet 47 of 225
CDMA
NBSS15.0
21-48 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUFRQ3D OM group Description
CAU call processing per FReQuency for 3g Data. This OM group is a clone of CAUCPFRQ OM group and so has the exact same registers. The OM registers in this group are pegged only for events related to 3G packet Data calls, except when the OM3G parameter in table CDMAPART is set to N. If the OM3G parameter is set to N, then the OM registers in OM group CAUFRQ3D are not pegged and the same events will be captured in CAUCPFRQ OM group along with 3G Voice calls events and 2G calls events. This OM group pegs on a per Sector/Band/Freq. basis. Note: This 3G OM group tracks events based on the reference sector on a per-frequency basis. However, hard handoff events are tracked based on the target sector on a per frequency basis.
sheet 48 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUFRQ3V OM group Description
CAU call processing per FReQuency for 3G Voice. This OM group is a clone of CAUCPFRQ OM group and so has the exact same registers. The OM registers in this group are pegged only for events related to 3G Voice calls, except when the OM3G parameter in table CDMAPART is set to N. If the OM3G parameter is set to N, then the OM registers in OM group CAUFRQ3V are not pegged and the same events will be captured in CAUCPFRQ OM group along with 3G Packet Data calls events and 2G calls events. This OM group pegs on a per Sector/Band/Freq. basis. Note: This OM group tracks events based on the reference sector on a per-frequency basis. However, hard handoff events are tracked based on the target sector on a per frequency basis.
sheet 49 of 225
CDMA
NBSS15.0
21-50 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUMISC OM group Modified in 14.0 release CAUUNSO Description
CAU MISCellaneous OM group. This group contains all the miscellaneous OMs that peg at the CAU.
CAU UNsupported Service Option. This OM is pegged when the service options sent by the mobile are unsupported. This OM is pegged irrespective of call type and is also pegged for data applications such as OTAPA, SMS etc. This OM functionality is similar to RMUUNSO. This OM is pegged in conjunction with MISCFLT OM.
RMUUNSO New OM in 14.0 release
RMU UNsupported Service Option. This OM is pegged during the resource allocation phase when CAU receives response from the RMU indicating that the service option CAU sent is not supported at the RMU. The MISCFLT OM is pegged along with this OM.
NRMUNSO New OM in 14.0 release
NRM UNsupported Service Option. This OM is pegged during the resource allocation phase when CAU receives response from the NRM indicating that the service option CAU sent is not supported at the NRM. The MISCFLT OM is pegged along with this OM.
SEFL2PVS New OM in 14.0 release
Selector Element FaiLure 2PVS. This OM tracks network related call drops due to loss of traffic between the vocoder (on the 2pVS) and the Selector Element (on the DSFP-V) after successful call setup on the CSVS platform. Loss of traffic means that ACP stops receiving forward traffic frames from the 2pVS during call progress for a configurable period of time (which is reported back to the CAU). This timer (Forward Link Missing Time Frame) can be configured via C-EMS. Default value is 5 sec and the range is 1-15 sec. The CAUDROPN OM is pegged along with this OM
sheet 50 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SEFLNWK New OM in 14.0 release Description
Reference chapter Dropped call performance (page 6-1)
Selector Element FaiLure NetWorK. This OM tracks network related call drops when the vocoder (on the 2pVS) detects network failure. A network failure indication is then sent to the Selector Element (on the DSFP-V) which is reported back to the CAU. Newtork failure includes: TDM Failure, ATM bearer failure, DSP failure etc. The CAUDROPN OM is pegged along with this OM
FLEVR13K New OM in 14.0 release
FaiLure EVRc 13K. This OM is pegged when the mobile fails to implement a Rate set change from EVRC to 13K service option during the service connect phase. This occurs in the following scenario. Mobile requests EVRC service option in the origination or page response message and the call is setup on 13K Service Option due to lack of EVRC resources. CAU then directs the mobile to do a rate set change during the service connect phase by sending the service connect message.
sheet 51 of 225
CDMA
NBSS15.0
21-52 MSC OM descriptions Nortel Networks MSC operational measurements Register CAURM OM group Modified OM group in 13.0 release Description
Reference chapter
CAU Resource Manager. This OM group tracks events on a perRMU basis. These OMs are pegged by RMU to track the resource allocation failures at RMU that may be experienced for a CAU resource allocation request. Note: The following OMs are deleted from this OM group in 13.0 release. NORREQ3D, RMOVLD, RMDEPLT, RMNORM, RMNORREQ, EVRCREQ, EVRCOVFL RM Service Resource Manager (SRM) Negative AcK. This OM is pegged for all call types except packet data calls, when the Resource Manager (RMU) was unable to send resource allocation request to SRM or, when the RMU was unable to decode a SRM response message or, when the RMU detected that the Call_Id in the SRM response did not match with the request that was sent out.
RMSRMNAK
Note: When the resource allocation response is received for a voice call at the CAU, either the BSCRM:RMUIOENV or RMURAOEV OM is pegged depending upon whether the resource allocation attempt is the initial or retry attempt.
RMSRMTO
RM SRM Time-Out. This OM is pegged for all call types except packet data calls when the RMU times out while waiting on a call resource allocation response from the SRM. Note: When the timeout response is received for a voice call at the CAU, either the BSCRM:RMUIOENV or RMURAOEV OM is pegged depending upon whether the resource allocation attempt is the initial or retry attempt.
sheet 52 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SRMNAK3D Description
Reference chapter
SRM Time-Out for 3G packet Data calls. This OM is pegged for packet data calls when the RMU times out while waiting on a call resource allocation response from the SRM. Note: When the timeout response is received for packet data call at the CAU, either the BSCRM:RMUIOEND or RMURAOED OM is pegged depending upon whether the resource allocation attempt is the initial or retry attempt.
SRMTO3D
SRM Time-Out for 3G packet Data calls. This OM is pegged for packet data calls when the RMU times out while waiting on a call resource allocation response from the SRM. Note: When the timeout response is received for packet data call at the CAU, either the BSCRM:RMUIOEND or RMURAOED OM is pegged depending upon whether the resource allocation attempt is the initial or retry attempt.
sheet 53 of 225
CDMA
NBSS15.0
21-54 MSC OM descriptions Nortel Networks MSC operational measurements Register SRMNNORM Description
Reference chapter
SRM Negative acknowledgement for NO Resource available. This OM is pegged for all call types at the RMU, when the RMU receives a SRM response indicating that no resource is available to fulfill the SRM resource allocation request. This pegging event indicates a mismatch condition between the RMUs internal information (about SRM resource availability status) and the SRMs actual resource availability status. During call setup, the CAU requests BSC resources from the RMU. Upon receiving a resource allocation request from the CAU, the RMU makes upto four resource request attempts from SRMs that it believes to have available resources. In addition, CAU pegs BSCRM:RMUIANRV or RMUIANRD depending on call type. If required, for the same call setup, the CAU makes a second attempt to obtain resources from the RMU, which leads to another four possible attempts by the RMU from SRMs. In addition, CAU pegs BSCRM:RMURANRV or RMURANRD depending on call type. Hence, for those calls that experience the mismatch condition described above, multiple resource request attempts must be made, resulting in increased call setup time. This OM is pegged for each RMU attempt that failed in accordance with this mismatch condition. An average number of failed SRM resource request attempts per call setup (i.e. failed due to this mismatch condition) can be estimated using this OM count and the count of call setup attempts. This average number is useful for trending of call setup performance. A low average value indicates that most calls did not experience the mismatch condition.
RMNOCIU
Resource Manager NO CIU ready. This OM is pegged by the RMU when Resource Manager Unit was unable to route forward messages because no CIUs were found READY. In addition, RMSRMNAK or SRMNAK3D is also pegged depending on call type. Note: When the resource allocation response is received at the CAU, either the BSCRM:RMUIOENV, RMURAOEV, RMUIOEND or RMURAOED OM is pegged depending upon whether the resource allocation attempt is the initial or retry attempt and call type.
sheet 54 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUSCT2 OM group New OM group in 13.0 release, modified in 14.0 NORFSEFL Description
CAU call processing per SeCTor 2 for 2G calls. This group contains sector based OMs in addition to the OMs in CAUCPSCT OM group. This OM group tracks events based on primary sector. However, hard handoff events are tracked based on the target sector.
NOn RF SEtup FaiLure. This OM is pegged when origination/ termination call setup fails due to non-RF related setup failures. These failures include internal failures within the network like time-outs, software failures and DSP setup failures etc. Note: CAUERLFL, MCTERLFL, MPRFL and MRETFL are not pegged for non-RF related failures.
NRFSEFHH
Non RF SEtup FaiLure for Hard Handoff. This OM is pegged when hard handoff call setup fails due to non-RF setup failures. These failures include internal failures within the network like time-outs, software failures and DSP setup failures etc. Note: CAUHRLFL, MCTHRLFL and MRETHFL are not pegged for non-RF related failures.
MISCFLT
MISCellaneous FauLTs. This OM is pegged anytime one of the following OMs is pegged: CAUUNSO, ODENYCAU, TDENYCAU, ONILDNY, FLTCEVR, FLTCB13K, FLTCI13K. Note: This OM provides a sector based representation of the above node based OMs.
WPSRETRY
Wireless Priority Service RETRY. This OM will peg only when WPS is turned ON. Applicable only to WPS activated CDMA carriers.
sheet 55 of 225
CDMA
NBSS15.0
21-56 MSC OM descriptions Nortel Networks MSC operational measurements Register WPSTRTRY Added in MTX14 release Description
Wireless Priority Service Termination ReTRY. This OM will peg only when WPS is turned ON. Applicable only to WPS activated CDMA carriers.
sheet 56 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUSCT3D OM group Description
Reference chapter Call setup performance (page 2-1) MCTA performance (page 14-1)
CAU call processing per SeCTor for 3G Data. This OM group is a clone of CAUCPSCT OM group and contains the exact same registers. The registers, whose descriptions are different, are listed below. OM group CAUCPSCT should be referred to for the rest of the common registers. The OM registers in this group are pegged only for events related to 3G packet Data calls, except when the OM3G parameter in table CDMAPART is set to N. If the OM3G parameter is set to N, then the OM registers in OM group CAUSCT3D are not pegged and the same events will be captured in CAUCPSCT OM group along with 3G Voice calls events and 2G calls events. Please refer to the Call Setup Performance Chapter for details on parameter OM3G. This OM group pegs on a per Sector basis. Note: This 3G OM group tracks events based on the reference sector. However, hard handoff events are tracked based on the target sector. Additional OMs related to Call processing per sector are listed in the CAUST3D2 OM group.
CAUTRLS
CAU Termination ReLeaSed. CAUTRLS is pegged when a mobile terminated call is released. This OM is pegged when the mobile sends a release after sending the page response and before it sends service connect completion message. This OM is also pegged if CM sends a release message to CAU before Mobile sends service connect completion message. For example, calling party ending the call before Mobile sends service connect completion message. Note: If mobile gets a page for a Network Initiated Dormant to Active Call when Mobile is in Null state (no existing PPP session), Mobile sends a release message before sending a service connect completion message.
sheet 57 of 225
CDMA
NBSS15.0
21-58 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUSCT3V OM group Description
CAU call processing per SeCTor for 3G Voice. This OM group is a clone of CAUCPSCT OM group and so has the exact same registers. The OM registers in this group are pegged only for events related to 3G Voice calls, except when the OM3G parameter in table CDMAPART is set to N. If the OM3G parameter is set to N, then the OM registers in OM group CAUSCT3D are not pegged and the same events will be captured in CAUCPSCT OM group along with 3G packet Data calls events and 2G calls events. Please refer to the Call Setup Performance Chapter for details on parameter OM3G. This OM group pegs on a per Sector basis. Note: This 3G OM group tracks events based on the reference sector. However, hard handoff events are tracked based on the target sector. Additional OMs related to Call processing per sector are listed in the CAUST3V2 OM group.
0
sheet 58 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUST3V2 OM group New OM group in 13.0 release Description
CAU call processing per SecTor for 3G Voice 2 calls. This group contains sector based OMs in addition to the OMs in CAUSCT3V OM group. This group contains the same registers as CAUSCT2 OM group.
sheet 59 of 225
CDMA
NBSS15.0
21-60 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUST3D2 OM group New OM group in 13.0 release CAURELSI Description
CAU call processing per SecTor for 3G packet Data 2 calls. This group contains sector based OMs in addition to the OMs in CAUSCT3D OM group. This OM group is for 3G packet data calls.
CAU RELease Service Inactive. This OM is pegged when the Mobile station sends a release reason with Service Inactive Indication during a network initiated Dormant to Active transition (mobile already on the TCH). Note: This OM is pegged in conjunction with CAUTRLS.
PDSEFLDS
PDsn SEtup FaiLure During call Setup. This OM is pegged during packet data call setup (null to active) when calls are released due to PCUs failure to setup RP session on all the datafilled PDSNs. During Setup means that this OM is pegged before the CAU receives the service connect completion message. Note: The CAUORLS OM is no longer pegged in this scenario.
PDSEFLAS
PDsn SEtup FaiLure After call Setup. This OM is pegged during packet data call setup (null to active) when calls are released due to PCUs failure to setup RP session on all the datafilled PDSNs. After Setup means that this OM is pegged after the CAU receives the service connect completion message. Note: The CAUMRLS OM is no longer pegged in this scenario.
sheet 60 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUXTF3D OM group Description
CAU eXTended Frequency based OM group. This OM group is a clone of CAUXTFRQ OM group and so has the exact same registers. The OM registers in this group are pegged only for events related to 3G packet data calls, except when the OM3G parameter in table CDMAPART is set to N. If the OM3G parameter is set to N, then the OM registers in OM group CAUXTF3D are not pegged and the same events will be captured in CAUXTFRQ OM group along with 3G Voice calls events and 2G calls events. This OM group is pegged per Sector/Band/Freq.
sheet 61 of 225
CDMA
NBSS15.0
21-62 MSC OM descriptions Nortel Networks MSC operational measurements Register CAUXTF3V OM group Description
CAU eXTended Frequency based OM group. This OM group is a clone of CAUXTFRQ OM group and so has the exact same registers. The OM registers in this group are pegged only for events related to 3G Voice calls, except when the OM3G parameter in table CDMAPART is set to N. If the OM3G parameter is set to N, then the OM registers in OM group CAUXTF3V are not pegged and the same events will be captured in CAUXTFRQ OM group along with 3G packet Data calls events and 2G calls events. This OM group is pegged per Sector/Band/Freq.
sheet 62 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CAUXTFRQ OM group Description
CAU eXTended FReQuency based OM group. This OM group is pegged per Sector/Band/Freq.
NMCTATTS Added in 11.0 release
Non MCTA call ATTemptS. Pegged when CDA determines that the originating carrier for the call attempt (origination or termination) has MCTA flag turned OFF.
Call setup performance (page 2-1) MCTA performance (page 14-1)
NMCTBLKS Added in 11.0 release
Non MCTa BLocKS. Pegged, along with the appropriate CAU*BLKS, when CDA determines that the originating carrier for the call attempt (origination or termination) has MCTA flag turned OFF, and also there were no BTS resources available for the call setup. (Note that the existing OMs MCTAREQF or MCTAHRQF should not be pegged in this scenario). MCTA Paging channel Redirection Sent out for call Origination. Pegged when a paging channel Redirection is sent out to the mobile in order for the mobile to move to a carrier on the alternate band and re-send an origination message.
Call setup performance (page 2-1) MCTA performance (page 14-1) Call setup performance (page 2-1) MCTA performance (page 14-1)
MCTPRRO Added in 11.0 release
MCTPRRT Added in 11.0 release
MCTa Paging channel Redirection Sent out for call Termination. Pegged when a paging channel Redirection is sent out to the mobile in order for the mobile to move to a carrier on the alternate band and re-send a page response.
sheet 63 of 225
CDMA
NBSS15.0
21-64 MSC OM descriptions Nortel Networks MSC operational measurements Register MCTPRST Added in 11.0 release Description
MCTa Paging channel Redirection Successful for call Termination. Pegged, along with MCTPGRES and CAUPGRES, when the mobile re-send a page response after the mobile was redirected to the alternate band.
MCTPRSO Added in 11.0 release
MCTa Paging channel Redirection Successful for call Origination. Pegged, along with MCTORIGS and CAUOATTS, when the mobile re-send an origination message after the mobile was redirected to the alternate band.
MPRBLKS Added in 11.0 release
Mcta Paging channel Redirection resulting in BLocKS. Pegged, along with the appropriate CAU*BLKS, when a redirection attempt fails due to resource Blocking.
MPRSUCC Added in 11.0 release
Mcta Paging channel Redirection resulting in SUCCess. Pegged, along with either (MCTOSUCC & CAUOSUCC) or (MCTTSUCC &CAUTSUCC), when a redirection attempt succeeds in terms of setting up resources and having the mobile arrive on the traffic channel.
MPRFL Added in 11.0 release
Mcta Paging channel Redirection resulting in FaiLure. Pegged, along with MCTERLFL and CAUERLFL, when a redirection attempt succeeds in terms of setting up resources but the mobile fails to arrive on the traffic channel.
sheet 64 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MRETATTS Added in 11.0 release Description
Mcta RETain carrier ATTemptS. Pegged, along with either MCTOATTS or MCTTATTS, when CDA selects the originating carrier for the call setup.
MRETHATT Added in 11.0 release
Mcta RETain carrier Hho ATTempts. Same as above OM, but pegged only in case of HHO. However in this case MCTHATTS get pegged along with MRETHATT.
MRETBLKS Added in 11.0 release
Mcta RETain carrier BLocKS. Pegged, along with MCTERSFL and CAUERSFL and the appropriate CAU*BLKS, when CDA selects the originating carrier for the call setup, but the call setup fails due to BTS resources shortage (i.e during the time interval between Capacity Request and Resource Request, some of the BTS resources on the selected carrier are no longer available). Mcta RETain carrier Hho BLocKs. Same as above OM, but pegged only in case of HHO.
MRETHBLK Added in 11.0 release
MRETSUCC Added in 11.0 release
Mcta RETain carrier SUCCess. This OM is Pegged along with either (MCTOSUCC & CAUOSUCC) or (MCTTSUCC & CAUTSUCC), when CDA selects the originating carrier for the call setup, and the setup is successful and the mobile arrives successfully on the traffic channel.
sheet 65 of 225
CDMA
NBSS15.0
21-66 MSC OM descriptions Nortel Networks MSC operational measurements Register MRETHSUC Added in 11.0 release Description
Mcta RETain carrier Hho SUCcess. Same as above OM, but pegged only in case of HHO. However the OMs that get pegged along with MRETHSUC are MCTHSUCC and CAUHSUCC.
MRETFL Added in 11.0 release
Mcta RETain carrier FaiLure. Pegged, along with MCTERLFL and CAUERLFL, when CDA selects the originating carrier for the call setup, and the setup is successful but the mobile fail to arrive on the traffic channel.
MRETHFL Added in 11.0 release
Mcta RETain carrier Hho FaiLure. Same as above OM, but pegged only in case of HHO. However in this case MCTHRLFL and CAUHRLFL OMs get pegged along with MRETHFL.
sheet 66 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMABIPG OM group New OM group in 13.0 release Description
Reference chapter Border paging performance (page 11-1)
CDMA Border Intersystem PaGe. This OM group is pegged at the Border system on per route (i.e. per intersystem route with an Anchor system) basis. These OMs only apply to Border Cell Paging in the Border system. These OMs track the border page attempts, successes, timeouts and releases (i.e. border page cancellations) for a route and can distinguish between first, second and third border page attempts, for voice and packet data calls. Note 1: There is no correlation between the border page attempt number with the anchor page attempt number. This is because the Anchor system can send the ISPAGE2 Invoke message to the Border system during its first, second or third local page attempt, always indicating the number of page attempts that the Border system should make. Hence, the Anchor system sends only one ISPAGE2 Invoke message to the Border system for a call termination. Note 2: The total time limit for the total number of page attempts is also specified by the Anchor system to the Border System in the ISPAGE2 Invoke message. The Border system divides the total time limit for each page attempt to derive the per page attempt timeout period. If the total time limit is not specified in the ISPAGE2 Invoke message, then the Border system uses the page timeout values configured for its own local page attempts.
0
These OMs are pegged in the Border system when, BCP is activated in the Anchor and Border system and, ISPAGE2 Invoke message is received from an Anchor System and, A valid page method (i.e. ALL, ZONE, SYSTEM or LAST for each border page attempt) is configured in the Border system by the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
Note: These OMs are pegged regardless of the paging method used for a border page attempt.
sheet 67 of 225
CDMA
NBSS15.0
21-68 MSC OM descriptions Nortel Networks MSC operational measurements Register IP2B1VAT Description
Intersystem Page 2 Border system for 1st Voice call ATtempts. This OM is pegged when the first page attempt is made in the Border system for voice calls. Note: If the mobile is already busy in a call prior to the sending of the page request for this attempt in the Border system, then paging is cancelled by the Border system and this OM is not pegged.
IP2B1VRS
Intersystem Page 2 Border system for 1st Voice call page ReSponse. This OM is pegged when the page response is received for the first page attempt made in the Border system for voice calls. Intersystem Page 2 Border system for 1st Voice call TimeOut. This OM is pegged when the border system times out waiting for page response during the first page attempt made in the Border system for voice calls.
Border paging performance (page 11-1) Border paging performance (page 11-1)
IP2B1VTO
IP2B1VRL
Intersystem Page 2 Border system for 1st Voice call ReLease. This OM is pegged when the border system cancels paging for the first page attempt made in the Border system for voice calls. Note: The Anchor system sends the RELEASE Invoke message to the Border system to cancel paging in the Border system when mobile has already responded to paging in another system or when call is abandoned.
Border paging performance (page 11-1)
sheet 68 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IP2B2VAT Description
Intersystem Page 2 Border system for 2nd Voice call ATtempts. This OM is pegged when the second page attempt is made in the Border system for voice calls after the first page attempt has timed out. Note 1: In the ISPAGE2 Invoke message, the Anchor system specifies the number of page attempts that the Border system should make. The Border system will not exceed the specified page attempt numbers, even if the previous page attempt timed out waiting for a page response. Note 2: Note: If the mobile is already busy in a call prior to the sending of the page request for this attempt in the Border system, then paging is cancelled by the Border system and this OM is not pegged.
IP2B2VRS
Intersystem Page 2 Border system for 2nd Voice call page ReSponse. This OM is pegged when the page response is received for the second page attempt made in the Border system for voice calls. Intersystem Page 2 Border system for 2nd Voice call TimeOut. This OM is pegged when the border system times out waiting for page response during the second page attempt made in the Border system for voice calls. Intersystem Page 2 Border system for 2nd Voice call ReLease. This OM is pegged when the border system cancels paging for the second page attempt made in the Border system for voice calls. Note: The Anchor system sends the RELEASE Invoke message to the Border system to cancel paging in the Border system when mobile has already responded to paging in another system or when call is abandoned.
Border paging performance (page 11-1) Border paging performance (page 11-1) Border paging performance (page 11-1)
IP2B2VTO
IP2B2VRL
sheet 69 of 225
CDMA
NBSS15.0
21-70 MSC OM descriptions Nortel Networks MSC operational measurements Register IP2B3VAT Description
Intersystem Page 2 Border system for 3rd Voice call ATtempts. This OM is pegged when the third page attempt is made in the Border system for voice calls after the second page attempt has timed out. Note 1: In the ISPAGE2 Invoke message, the Anchor system specifies the number of page attempts that the Border system should make. The Border system will not exceed the specified page attempt numbers, even if the previous page attempt timed out waiting for a page response.
IP2B3VRS
Intersystem Page 2 Border system for 3rd Voice call page ReSponse. This OM is pegged when the page response is received for the third page attempt made in the Border system for voice calls. Intersystem Page 2 Border system for 3rd Voice call TimeOut. This OM is pegged when the border system times out waiting for page response during the third page attempt made in the Border system for voice calls. Intersystem Page 2 Border system for 3rd Voice call ReLease. This OM is pegged when the border system cancels paging for the third page attempt made in the Border system for voice calls. Note: The Anchor system sends the RELEASE Invoke message to the Border system to cancel paging in the Border system when mobile has already responded to paging in another system or when call is abandoned.
IP2B3VTO
IP2B3VRL
IP2B1DAT
Intersystem Page 2 Border system for 1st packet Data call ATtempt. This OM is pegged when the first page attempt is made in the Border system for Packet Data calls. Note: If the mobile is already busy in a call prior to the sending of the page request for this attempt in the Border system, then paging is cancelled by the Border system and this OM is not pegged.
sheet 70 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IP2B1DRS Description
Reference chapter Border paging performance (page 11-1) Border paging performance (page 11-1) Border paging performance (page 11-1)
Intersystem Page 2 Border system for 1st packet Data call page ReSponse. This OM is pegged when the page response is received for the first page attempt made in the Border system for Packet Data calls. Intersystem Page 2 Border system for 1st packet Data call TimeOut. This OM is pegged when the border system times out waiting for page response during the first page attempt made in the Border system for Packet Data calls. Intersystem Page 2 Border system for 1st packet Data call ReLease. This OM is pegged when the border system cancels paging for the first page attempt made in the Border system for Packet Data calls. Note: The Anchor system sends the RELEASE Invoke message to the Border system to cancel paging in the Border system when mobile has already responded to paging in another system or when call is abandoned.
IP2B1DTO
IP2B1DRL
IP2B2DAT
Intersystem Page 2 Border system for 2nd packet Data call ATtempt. This OM is pegged when the second page attempt is made in the Border system for Packet Data calls after the first page attempt has timed out. Note 1: In the ISPAGE2 Invoke message, the Anchor system specifies the number of page attempts that the Border system should make. The Border system will not exceed the specified page attempt numbers, even if the previous page attempt timed out waiting for a page response. Note 2: If the mobile is already busy in a call prior to the sending of the page request for this attempt in the Border system, then paging is cancelled by the Border system and this OM is not pegged.
IP2B2DRS
Intersystem Page 2 Border system for 2nd packet Data call page ReSponse. This OM is pegged when the page response is received for the second page attempt made in the Border system for Packet Data calls.
sheet 71 of 225
CDMA
NBSS15.0
21-72 MSC OM descriptions Nortel Networks MSC operational measurements Register IP2B2DTO Description
Reference chapter Border paging performance (page 11-1) Border paging performance (page 11-1)
Intersystem Page 2 Border system for 2nd packet Data call TimeOut. This OM is pegged when the border system times out waiting for page response during the second page attempt made in the Border system for Packet Data calls. Intersystem Page 2 Border system for 2nd packet Data call ReLease. This OM is pegged when the border system cancels paging for the second page attempt made in the Border system for Packet Data calls. Note: The Anchor system sends the RELEASE Invoke message to the Border system to cancel paging in the Border system when mobile has already responded to paging in another system or when call is abandoned.
IP2B2DRL
IP2B3DAT
Intersystem Page 2 Border system for 3rd packet Data call ATtempt. This OM is pegged when the third page attempt is made in the Border system for Packet Data calls after the second page attempt has timed out. Note 1: In the ISPAGE2 Invoke message, the Anchor system specifies the number of page attempts that the Border system should make. The Border system will not exceed the specified page attempt numbers, even if the previous page attempt timed out waiting for a page response. Note 2: If the mobile is already busy in a call prior to the sending of the page request for this attempt in the Border system, then paging is cancelled by the Border system and this OM is not pegged.
IP2B3DRS
Intersystem Page 2 Border system for 3rd packet Data call page ReSponse. This OM is pegged when the page response is received for the third page attempt made in the Border system for Packet Data calls. Intersystem Page 2 Border system for 3rd packet Data call TimeOut. This OM is pegged when the border system times out waiting for page response during the third page attempt made in the Border system for Packet Data calls.
sheet 72 of 225
IP2B3DTO
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IP2B3DRL Description
Intersystem Page 2 Border system for 3rd packet Data call ReLease. This OM is pegged when the border system cancels paging for the third page attempt made in the Border system for Packet Data calls. Note: The Anchor system sends the RELEASE Invoke message to the Border system to cancel paging in the Border system when mobile has already responded to paging in another system or when call is abandoned.
0
sheet 73 of 225
CDMA
NBSS15.0
21-74 MSC OM descriptions Nortel Networks MSC operational measurements Register CDMADFSO OM group Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
CDMA Data Fax Service Options. This OM group is pegged per RMU, per Service Option basis.
ATASYC96
ATtempts for ASYnC data 9.6. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the Async Data 9.6 service option. SUccessful resource allocation for ASYnC data 9.6. This OM is pegged when a resource for an Async Data 9.6 service option request has been successfully allocated. Hop Count for ASYnC data 9.6. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for ASYnC data 9.6. This OM is pegged when an attempt to allocate resource for the Async Data 9.6 service option fails. It is due to no resources available in any pool from a list. ATtempts for ASYnc data 14.4. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the Async Data 14.4 service option. SUccessful resource allocation for ASYnc data 14.4. This OM is pegged when a resource for an Async Data 14.4 service option request has been successfully allocated Hop Count for ASYnc data 14.4. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for ASYnc data 14.4. This OM is pegged when an attempt to allocate resource for the Async Data 14.4 service option fails. It is due to no resources available in any pool from a list.
sheet 74 of 225
SUASYC96
HCASYC96
FLASYC96
ATASY144
SUASY144
HCASY144
FLASY144
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register ATASYCIS Description
ATtempts for ASYnC data IS707. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the Async Data IS707 service option. SUccessful resource allocation for ASYnC data IS707. This OM is pegged when a resource for an Async Data IS707 service option request has been successfully allocated Hop Count for ASYnC data IS707. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for ASYnC data IS707. This OM is pegged when an attempt to allocate resource for the Async Data IS707 service option fails. It is due to no resources available in any pool from a list. ATtempts for AnaLoG fax 9.6. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the Analog Fax 9.6 service option. SUccessful resource allocation for AnaLoG fax 9.6. This OM is pegged when a resource for a Analog Fax 9.6 service option request has been successfully allocated Hop Count for AnaLoG fax 9.6. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for AnaLoG fax 9.6. This OM is pegged when an attempt to allocate resource for the Analog Fax 9.6 service option fails. It is due to no resources available in any pool from a list. ATtempts for AnaLoG fax 14.4. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the Analog Fax 14.4 service option.
sheet 75 of 225
SUASYCIS
HCASYCIS
FLASYCIS
ATALG96
SUALG96
HCALG96
FLALG96
ATALG144
CDMA
NBSS15.0
21-76 MSC OM descriptions Nortel Networks MSC operational measurements Register SUALG144 Description
SUccessful resource allocation for AnaLoG fax 14.4. This OM is pegged when a resource for a Analog fax 14.4 service option request has been successfully allocated Hop Count for AnaLoG fax 14.4. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for AnaLoG fax 14.4. This OM is pegged when an attempt to allocate resource for the Analog fax 14.4 service option fails. It is due to no resources available in any pool from a list. ATtempts for GRoup 3 fax 9.6. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the group 3 Fax 9.6 service option. SUccessful resource allocation for GRoup 3 fax 9.6. This OM is pegged when a resource for an group 3 Fax 9.6 service option request has been successfully allocated Hop Count for GRoup 3 fax 9.6. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for GRoup 3 fax 9.6. This OM is pegged when an attempt to allocate resource for the group 3 Fax 9.6 service option fails. It is due to no resources available in any pool from a list. ATtempts for GRoup 3 fax 14.4. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the group 3 Fax 14.4 service option. SUccessful resource allocation for GRoup 3 fax 14.4. This OM is pegged when a resource for an group 3 Fax 14.4 service option request has been successfully allocated
sheet 76 of 225
HCALG144
FLALG144
ATGR396
SUGR396
HCGR396
FLGR396
ATGR3144
SUGR3144
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register HCGR3144 Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
Hop Count for GRoup 3 fax 14.4. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for GRoup 3 fax 14.4. This OM is pegged when an attempt to allocate resource for the group 3 Fax 14.4 service option fails. It is due to no resources available in any pool from a list. ATtempts for GRoup 3 fax IS707. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the group 3 Fax IS707 service option. SUccessful resource allocation for GRoup 3 fax IS707. This OM is pegged when a resource for an group 3 Fax IS707 service option request has been successfully allocated Hop Count for GRoup 3 fax IS707. This OM is pegged for each pool, including the first pool, the RMU searches through from a list to find a resource for a service option. FaiLures for GRoup 3 fax IS707. This OM is pegged when an attempt to allocate resource for the GRoup 3 Fax IS707 service option fails. It is due to no resources available in any pool from a list.
sheet 77 of 225
FLGR3144
ATGR3IS
SUGR3IS
HCGR3IS
FLGR3IS
CDMA
NBSS15.0
21-78 MSC OM descriptions Nortel Networks MSC operational measurements Register CDMAIVSN OM group Modified in 14.0 release Description
Reference chapter Call setup performance (page 2-1) Intelligent voice service negotiations performance (page 8-1)
CDMA Intelligent Voice Service Negotiations. This OM group pegs on a per BSC basis. Note: This OM group is pegged at the CAU, but when OMSHOW performed, they are displayed per BSC not per CAU.
VNILEVR
Voice call termination NIL to EVRc. This OM is pegged when the mobile requested service option is NIL and a call is established with EVRC. The call will be denied if the mobile requested service option is NIL and the call type is origination. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls Basic 8K to EVRc. This OM is pegged when the mobile requested service option is Basic 8K Voice and a call is established with EVRC. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls EVRc to EVRc. This OM is pegged when the mobile requested service option is EVRC and a call is established with EVRC. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
sheet 78 of 225
Intelligent voice service negotiations performance (page 8-1)
VB8KEVR
VEVREVR
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register VI13KEVR Description
Reference chapter Intelligent voice service negotiations performance (page 8-1)
Voice calls I733 13K to EVRc. This OM is pegged when the mobile requested service option is IS733 13K Voice and a call is established with EVRC. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls Basic 13K to EVRc. This OM is pegged when the mobile requested service option is Basic 13K Voice and a call is established with EVRC. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice call termination NIL to I733 13K. This OM register is pegged when the mobile requested service option is NIL and a call is established with IS733 13K Voice. The call will be denied if the mobile requested service option is NIL and the call type is origination. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls Basic 8K to I733 13K. This OM is pegged when the mobile requested service option is Basic 8K Voice and a call is established with IS733 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
sheet 79 of 225
VB13KEVR
VNILI13K
VB8KI13K
CDMA
NBSS15.0
21-80 MSC OM descriptions Nortel Networks MSC operational measurements Register VEVRI13K Description
Voice calls EVRc to I733 13K. This OM is pegged when the mobile requested service option is EVRC and a call is established with IS733 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls I733 13K to I733 13K. This OM is pegged when the mobile requested service option is IS733 13K Voice and a call is established with IS733 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls Basic 13K to I733 13K. This OM is pegged when the mobile requested service option is Basic 13K Voice and a call is established with IS733 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice call termination NIL to Basic 13K. This OM is pegged when the mobile requested service option is NIL and a call is established with Basic 13K Voice. The call will be denied if the mobile requested service option is NIL and the call type is origination. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
VI13KI13K
VB13KI13K
VNILB13K
sheet 80 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register VB8KB13K Description
Voice calls Basic 8K to Basic 13K. This OM is pegged when the mobile requested service option is Basic 8K Voice and a call is established with Basic 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls EVRc to Basic 13K. This OM is pegged when the mobile requested service option is EVRC and a call is established with Basic 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
0
VEVRB13K
VI13KB13
Voice calls I733 13K to Basic 13K. This OM is pegged when the mobile requested service option is IS733 13K Voice and a call is established with Basic 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
0
sheet 81 of 225
CDMA
NBSS15.0
21-82 MSC OM descriptions Nortel Networks MSC operational measurements Register VB13KB13 Description
Voice calls Basic 13K to Basic 13K. This OM is pegged when the mobile requested service option is Basic 13K Voice and a call is established with Basic 13K Voice. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
0
ONILDNY
Origination with NIL service option DeNY. This OM is pegged when the requested service option in the Origination message is NIL and the call is denied by CAU. In this case the call will not be set up. The existing OM CAUOATTS is also pegged for attempts.
Call setup performance (page 2-1) Intelligent voice service negotiations performance (page 8-1) Call setup performance (page 2-1) Intelligent voice service negotiations performance (page 8-1) Call setup performance (page 2-1) Intelligent voice service negotiations performance (page 8-1)
ODENYCAU
call Origination DENY by CAU. This OM is pegged during a mobile origination when the mobiles voice service capability, retrieved by querying the mobile on the paging/access channel, does not match any of the service options preferred by the system. ODENYCAU is pegged only when a mobile is queried on the paging/access channel during call origination.
ODENYCM
call Origination DENY by CM. This OM is pegged during a mobile origination when the mobiles voice service capability in the VLR does not match any of the service options preferred by the system. This OM is pegged at CM, so it can be validated against CAUOATTS OM which is also pegged for origination.
sheet 82 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register TDENYCAU Description
Reference chapter Call setup performance (page 2-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1)
call termination DENY by CAU. This OM is pegged during a mobile termination when the mobiles voice service capability, retrieved by querying the mobile on the paging/access channel, does not match any of the service options preferred by the system. TDENYCAU is pegged only when a mobile is queried on the paging/access channel during call termination.
ATTEVRC
ATtempt EVRC. This OM is pegged when the mobile sends an Origination or a Page Response message indicating that EVRC SO should be used to setup the call.
ATTB13K
ATtempt Basic 13K. This OM is pegged when the mobile sends an Origination or a Page Response message indicating that Basic 13K SO should be used to setup the call.
ATTI13K
ATtempt IS 733 13K. This OM is pegged when the mobile sends an Origination or a Page Response message indicating that IS 733 13K SO should be used to setup the call.
ATTNIL
ATTempt NIL. This OM is pegged when the mobile sends an Origination or a Page Response message indicating that NIL SO should be used to setup the call.
sheet 83 of 225
CDMA
NBSS15.0
21-84 MSC OM descriptions Nortel Networks MSC operational measurements Register CDMIVSN2 OM group New in 15.0 release ATEVB Description
Reference chapter Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1)
CDMA Intelligent Voice Service Negotiations extension. This OM group pegs on a per BSC basis. Note: This OM group is pegged at the CAU, but when OMSHOW performed, they are displayed per BSC not per CAU. ATtempt EVrcB. This OM is pegged when the mobile sends an Origination or a Page Response message indicating that EVRCB SO should be used to setup the call.
ATEVB2
Attempt EVrcB 2 extension. This register is an extension to the ATEVB register.
VNILEVB
Voice calls NIL to EVrcB. This OM is pegged when the mobile requested service option is NIL and a call is established with EVRC-B. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls EVRc to EVrcB. This OM is pegged when the mobile requested service option is EVRC and a call is established with EVRC-B. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls 13K to EVrcB. This OM is pegged when the mobile requested service option is Basic 13K and a call is established with EVRC-B. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
sheet 84 of 225
VEVREVB
V13KEVB
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register VI13KEVB Description
Voice calls IS 733 13K to EVrcB. This OM is pegged when the mobile requested service option is IS 733 13K and a call is established with EVRC-B. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls EVrcB to EVrcB. This OM is pegged when the mobile requested service option is EVRC-B and a call is established with EVRC-B. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls EVrcB to EVRc. This OM is pegged when the mobile requested service option is EVRC-B and a call is established with EVRC. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly. Voice calls EVrcB to Basic 13K. This OM is pegged when the mobile requested service option is EVRC-B and a call is established with Basic 13K. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
sheet 85 of 225
VEVBEVB
VEVBEVR
VEVB13K
CDMA
NBSS15.0
21-86 MSC OM descriptions Nortel Networks MSC operational measurements Register VEVBI13K Description
Voice calls EVrcB to IS 733 13K. This OM is pegged when the mobile requested service option is EVRC-B and a call is established with IS 733 13K. Note: A mobile can request preferred service option via Origination message during call origination or via page response message during call termination. This OM is pegged after a successful call setup, i.e. after receiving Service Connect Complete Message from a mobile. The existing OMs CAUOSUCC and CAUTSUCC are pegged correspondingly.
sheet 86 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMAPDOM OM group MIDTOAAT Description
Reference chapter Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1)
CDMA Packet Data OM. This OM group tracks dormant to active transitions (both mobile initiated and network initiated) on a system-wide basis. This is a 3G related OM group. Mobile-Initiated Dormant To Active ATtempts. This OM is pegged when the MSC receives an origination message from a mobile which is in a dormant data call state. Mobile-Initiated Dormant To Active SUccess. This OM is pegged when the mobile-initiated dormant to active transition is successful mobile arrives on the traffic channel. Mobile-Initiated Dormant To Active FaiLures. This OM is pegged when the mobile-initiated dormant to active transition fails due to lack of resources or the mobile fail to arrive on the traffic channel. Network-Initiated Dormant To Active ATtempTs. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state. Network-Initiated Dormant To Active SUccess. This OM is pegged when the network-initiated dormant to active transition is successful mobile arrives on the traffic channel. Network-Initiated Dormant To Active FaiLures. This OM is pegged when the network-initiated dormant to active transition fails due to lack of resources or the mobile fail to arrive on the traffic channel. NULl To Active ATtempts. This OM provides a count of the number of times a mobile has attempted to transition from Null to Active. It is also pegged when a mobile with a dormant session hands off to another MSC and attempts to transition from Dormant to Active before a Dormant Handoff Registration message (an Origination message with Data Ready to Send set to false) is sent. NULl To Active SUccess. This OM provides a count of the number of times a mobile has successfully transitioned from Null to Active. It is also pegged when a mobile with a dormant session hands off to another MSC and successfully transitions from Dormant to Active before a Dormant Handoff Registration message (an Origination message with Data Ready to Send set to false) is sent.
sheet 87 of 225
MIDTOASU
MIDTOAFL
NIDTOAAT
NIDTOASU
NIDTOAFL
NULTOAAT
NULTOASU
CDMA
NBSS15.0
21-88 MSC OM descriptions Nortel Networks MSC operational measurements Register NULTOAFL Description
NULl To Active FaiLures. This OM provides a count of the number of times a mobile has failed to successfully transition from Null to Active. It is also pegged when a mobile with a dormant session hands off to another MSC and fails to successfully transition from Dormant to Active before a Dormant Handoff Registration message (an Origination message with Data Ready to Send set to false) is sent. Mobile-Initiated Dormant TO Active ATtempt eXtension. This is the extension register for MIDTOAAT. Mobile-Initiated Dormant To Active Success eXtension. This is the extension register for MIDTOASU. Network-Initiated dormant to active FaiLures due to No VLR entry. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and a VLR entry does not exist for the subscriber. Network-Initiated dormant to active FaiLures due to Nil Service Option in Page response. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and MSC has paged the mobile but the mobile responds with NIL service option in the page response message. This happens when the PPP session at mobile has been lost due to some reasons. Network-Initiated dormant to active FaiLures due to Mobile INActive. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and there is an MS Inactive state in the VLR for the subscriber. Network-Initiated dormant to active FaiLures due to PaGe TiMout. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and timeout occurs after MSC pages the mobile.
sheet 88 of 225
MIDTOAAX
Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1)
MIDTOASX
NIFLNVLR
NIFLNSOP
NIFLMINA
NIFLPGTM
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register NIFLPGNG Description
Network-Initiated dormant to active FaiLures due to PaGe response Not Get. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and MSC has paged the mobile but the page response has not been received at MSC. Network-Initiated dormant to active FaiLures due to Mobile in Voice CaLL. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and MSC has not received any page response from the mobile when PCU requests another dormant to active transition for the same data call. Network-Initiated dormant to active FaiLures due to timeout on cau rESPonse. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and after resources have been setup, the CM times out on CAU answer message which might indicate a problem with the communication between CM and CAU within the MSC. Network-Initiated dormant to active FaiLures due to Cau internaL FaiLures. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and an internal failure occurs in the CAU. Network-Initiated dormant to active FaiLures due to Mobile ReLeaSe. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and the mobile releases the call while the CM is waiting for an answer message from CAU after the resources have been setup. Network-Initiated dormant to active FaiLures due to mobile in AMPS coverage area. This OM is pegged when the MSC receives a PCU_Page_Request after the network PCU decides to make the transition to active state and the mobile has moved into an AMPS coverage area. MS REGistered NOTification messages. This OM pegs the total number of MS Registered Notification messages sent out to the BSC by MSC.
sheet 89 of 225
NIFLVCLL
NIFLSRSP
NIFLCLFL
NIFLMRLS
NIFLAMPS
MSREGNOT
CDMA
NBSS15.0
21-90 MSC OM descriptions Nortel Networks MSC operational measurements Register MIDTOAFX Description
Reference chapter Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1)
Mobile-Initiated Dormant To Active Failures eXtension. This OM register is an extension register of MIDTOAFL. Network-Initiated Dormant To Active Attempts eXtension. This OM register is an extension register of NIDTOATT. Network-Initiated Dormant To Active Success eXtension. This OM register is an extension register of NIDTOASU. Network-Initiated Dormant To Active Failures eXtension. This OM register is an extension register of NIDTOAFL. NULl To Active Attempts eXtension. This OM register is an extension register of NULTOAAT. Together with NULTOAAT, they provide a count of the number of times a mobile has attempted to transition from Null to Active. It is also pegged when a mobile with a dormant session hands off to another MSC and attempts to transition from Dormant to Active before a Dormant Handoff Registration message (an Origination message with Data Ready to Send set to false) is sent. NULl To Active Success eXtension. This OM register is an eXtension register of NULTOASU. NULl To Active Failures eXtension. This OM register is an extension register of NULTOAFL.
sheet 90 of 225
NIDTOAAX
NIDTOASX
NIDTOAFX
NULTOAAX
NULTOASX
NULTOAFX
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMPDOM2 OM group RAHFCDCF Description
Reference chapter
CDMA Packet Data OM group 2. This OM group provides retry related OMs for packet data. PD Call Re-establishment attempt After Handoff Failures, Call Drop and Call setup Failure. This OM pegs the re-establishment attempts after the original call experienced either handoff failure, or call drop or call setup failure. PD Call Re-Establishment Success After HandOff FaiLure.This OM pegs the sucess of the re-establishment after the original call experienced handoff failure. PD Call Re-Establishment Failure After HandOff FaiLure.This OM pegs the failure of the re-establishment after the original call experienced handoff failure. PD Call Re-Establishment Success After Call DRoP. This OM pegs the sucess of the re-establishment after the original call experienced call drop. PD Call Re-Establishment Failure After Call DRoP. This OM pegs the failure of the re-establishment after the original call experienced call drop. Release OM for Handoff Failure, Call Drop and Call setup Failure. This OM pegs the releases during the re-establishment after the original call experienced either handoff failure, or call drop or call setup failure.
sheet 91 of 225
RESAHOFL
REFAHOFL
RESACDRP
REFACDRP
ROHFCDCF
CDMA
NBSS15.0
21-92 MSC OM descriptions Nortel Networks MSC operational measurements Register CDMAPDSO OM group Description
CDMA Packet Data Service Option. This OM group provides resource allocation measurements for the CDMA2000_INT_PPP_DATA service option on a per RMU basis. This is a 3G related OM group.
ATINPPP
resource Allocation Attempts for CDMA2000 INternet PPP Data service option. This OM is pegged when there is an attempt made by the RMU for a resource request from the CAU to allocate a resource for a CDMA2000_INT_PPP_DATA service option.
Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call setup performance (page 2-1)
SUINPPP
SUccessful resource allocation for CDMA2000 INternet PPP Data service option. This OM is pegged when a resource for a CDMA2000_INT_PPP_DATA service option request has been successfully allocated. Hop Count for CDMA2000 INternet PPP Data service option. This OM is pegged to indicate the number of PCUs searched in order to find resources for the CDMA2000 INternet PPP Data service option on the given RMU. PCUs are searched during transitions to the active state and during dormant handoffs. HCINPPP is pegged in both of these instances. resource allocation FaiLures for CDMA2000 INternet PPP Data service option. This OM is pegged when an attempt to allocate resource for a CDMA2000_INT_PPP_DATA service option fails. It is due to no resources available in any pool from the list.
HCINPPP
FLINPPP
Call setup performance (page 2-1) Call resource allocation and management (page 16-1)
sheet 92 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMAPAGE OM group Modified OM group in 13.0 release Description
CDMA PAGE. This OM group is pegged at the CM on a per System basis. This OM group provides paging OMs based on the Mobile Protocol Revision of the mobile being paged and the type of the call that is being initiated. The tuples are: CSD_MOB_P_REV_1_TO_5 CSD_MOB_P_REV_6 CSD_MOB_P_REV_7_PLUS VOICE_MOB_P_REV_1_TO_5 VOICE_MOB_P_REV_6 VOICE_MOB_P_REV_7_PLUS PACKET_DATA_MOB_P_REV_6 PACKET_DATA_MOB_P_REV_7_PLUS
These OMs are pegged in the local CDMA system (i.e. Anchor System, when Border Cell Paging is activated), regardless of the Local paging method (i.e. ALL, ZONE, SYSTEM, LAST) configured in Table PAGECTRL. Note: Paging OMs in groups MTXSYS1, MTXSYSX, CDMASIPG, CDMASIP2, CDMAPDOM, CDMAPGZN, CDMAPGZ2 and CDMAPGZX are also pegged when applicable. All of the 3G voice call OMs are pegged for VPAD related voice call attempts.
0
PGATTM1
PaGe ATTeMpt 1. This OM is pegged per call type and mobile type when the first page is sent to a mobile. PaGe ATTeMpt 1 eXtension. This OM is the extension of PGATTM1.
sheet 93 of 225
PGATTM1X
CDMA
NBSS15.0
21-94 MSC OM descriptions Nortel Networks MSC operational measurements Register PGRESP1 Description
PaGe RESPonse 1. This OM is pegged per call type and mobile type when the mobile responds to the first page in the system it was last known. Note: When BCP is activated, and the system is configured to send inter-system page request to the Border system (using configurable parameters OUTGOING_VOICE_CIRCUIT_ISPAGE2 and OUTGOING_PACKET_DATA_ISPAGE2 in table PAGECTRL), if page response is received in the Border system, this OM is not pegged.
0
PGRESP1X
PaGe RESPonse 1 eXtension. This OM is the extension of PGRESP1. PaGe TiMeOuT 1. This OM is pegged per call type and mobile type if the system times out waiting for the first page response. Note: When BCP is activated, and the system is configured to send inter-system page request to the Border systems (using configurable parameters OUTGOING_VOICE_CIRCUIT_ISPAGE2 and OUTGOING_PACKET_DATA_ISPAGE2 in table PAGECTRL), this OM is only pegged when page response is not received in this system (i.e. Anchor system) and the Border systems.
0 0
PGTMOT1
PGTMOT1X
PaGe TiMeOuT 1 eXtension. This OM is the extension of PGTMOT1.

sheet 94 of 225
Chapter 10, Paging performance
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register ORGTRM1 Description ORiGinator TeRMination 1.
Note: The word Termination in the OM name means the call originator released the call. This OM is pegged per call type and mobile type, if the call is abandoned (call originator released the call) or dropped due to RF failure (for mobile to mobile call, originator side link failure) after the first page is sent and before the page response is received or time limitation is reached. This OM is also pegged in some scenarios for VPAD feature when page request is sent again if during waiting for page response state data call origination is received from the mobile. ORGTRM1X ORiGinator TeRMination 1 eXtension. This OM is the extension of ORGTRM1. PaGe ATTeMpt 2. This OM is pegged per call type and mobile type when the second page is sent to a mobile after time out occurs waiting for the first page response. PaGe ATTeMpt 2 eXtension. This OM is the extension of PGATTM2. PaGe RESPonse 2. This OM is pegged per call type and mobile type when the mobile responds to the second page in the system it was last known. The note in PGRESP1 also applies to this OM. PGRESP2X PaGe RESPonse 2 eXtension. This OM is the extension of PGRESP2. PaGe TiMeOuT 2. This OM is pegged per call type and mobile type if the system times out waiting for the second page response. The note in PGTMOT1 also applies to this OM.
sheet 95 of 225
Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1)
PGATTM2
PGATTM2X
PGRESP2
PGTMOT2
CDMA
NBSS15.0
21-96 MSC OM descriptions Nortel Networks MSC operational measurements Register PGTMOT2X Description
Reference chapter Paging performance (page 10-1) Paging performance (page 10-1)
PaGe TiMeOuT 2 eXtension. This OM is the extension of PGTMOT2. ORiGinator TeRMination 2. Termination word in the OM name means call originator released the call. This OM is pegged per call type and mobile type, if the call is abandoned (call originator released the call) or dropped due to RF failure (for mobile to mobile call, originator side link failure) after the second page is sent and before the page response is received or time limitation is reached. This OM is also pegged in some scenarios for VPAD feature when page request is sent again if during waiting for page response state data call origination is received from the mobile. ORiGinator TeRMination 2 eXtension. This OM is the extension of ORGTRM2. PaGe ATTeMpt 3. This OM is pegged per call type and mobile type when the third page is sent to a mobile after time out occurs waiting for the second page response. PaGe ATTeMpt 3 eXtension. This OM is the extension of PGATTM3.
ORGTRM2
ORGTRM2X
PGATTM3 New OM in 13.0 release PGATTM3X New OM in 13.0 release PGRESP3 New OM in 13.0 release PGRESP3X New OM in 13.0 release PGTMOT3 New OM in 13.0 release
PaGe RESPonse 3. This OM is pegged per call type and mobile type when the mobile responds to the third page in the system it was last known. The note in PGRESP1 also applies to this OM. PaGe RESPonse 3 eXtension. This OM is the extension of PGRESP3.
PaGe TiMeOuT 3. This OM is pegged per call type and mobile type if the system times out waiting for the third page response. The note in PGTMOT1 also applies to this OM.
sheet 96 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register PGTMOT3X New OM in 13.0 release ORGTRM3 New OM in 13.0 release ORiGinator TeRMination 3. Description
PaGe TiMeOuT 3eXtension. This OM is the extension of PGTMOT3.
Note: Termination word in the OM name means call originator released the call. This OM is pegged per call type and mobile type, if the call is abandoned (call originator released the call) or dropped due to RF failure (for mobile to mobile call, originator side link failure) after the second page is sent and before the page response is received or time limitation is reached. This OM is also pegged in some scenarios for VPAD feature when page request is sent again if during waiting for page response state data call origination is received from the mobile.
ORGTRM3X New OM in 13.0 release DPGRES1 New OM in 14.0 release DPGRES2 New OM in 14.0 release
ORiGinator TeRMination 3 eXtension. This OM is the extension of ORGTRM3.
Delayed PaGe RESponse 1. This OM is pegged per call type and mobile type when the mobiles response to the first page is received during the second or third page attempt made by the system. Delayed PaGe RESponse 2. This OM is pegged per call type and mobile type when the mobiles response to the second page is received during the third page attempt made by the system.
sheet 97 of 225
CDMA
NBSS15.0
21-98 MSC OM descriptions Nortel Networks MSC operational measurements Register CDMAPGZN OM group Modified OM group in 13.0 release Description
Reference chapter Call setup performance (page 2-1) Paging performance (page 10-1) Border paging performance (page 11-1)
CDMA PaGe ZoNe. This OM group tracks events per paging zone and per paging zone type. The paging zone type can be an IZP zone (Intelligent Zone Paging) or a BCP zone (Border Cell Paging). An IZP zone is applicable to paging in any system, while a BCP zone is applicable to paging in a border system only. A same cell can be configured to belong to an IZP zone and also to a BCP zone. IZP and BCP zones are configured in table CDMAPGZN. The IZP or BCP zone type is defined by the ZONETYPE field in that table. These OMs are pegged for IZP zones in a system when: IZP is activated in the system and, Any local page attempt is configured to use the ZONE paging method.
Note: This also applies for an Anchor system when BCP is also activated through SOC in that system.
0
These OMs are pegged for BCP zones in the Border system when: BCP is activated in the Border system and, ISPAGE2 Invoke message is received from the Anchor System and, Any intersystem page attempt is configured to use the ZONE paging method and, BCP zones are to be used for the zone paging method (as opposed to IZP zones). This is configured in the BCP_ZONE_PAGING parameter in Table PAGECTRL.
Each OM in this group is pegged combined for Voice, CSD and Packet Data call terminations.
sheet 98 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register PGZNREQ Modified OM in 13.0 release Description
Reference chapter Paging performance (page 10-1) Border paging performance (page 11-1)
PaGe ZoNe REQuest. This OM is pegged when an first page request is sent to the zone, where zone_page option is selected in table CDMAPGZN:PAGEOPT field. For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
PGZNRES Modified OM in 13.0 release
PaGe ZoNe RESponse. This OM is pegged when the page response is received for the first page request that was sent to the zone (i.e. where zone_page option is selected in table CDMAPGZN:PAGEOPT field). For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
Paging performance (page 10-1) Border paging performance (page 11-1)
Note: When BCP is activated, and the page response is received in a Border system, this OM is not pegged for the IZP zone in the Anchor system.
0
For BCP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 99 of 225
CDMA
NBSS15.0
21-100 MSC OM descriptions Nortel Networks MSC operational measurements Register PGZNLPAT New OM in 13.0 release Description
PaGe ZoNe+zoneList Page ATtempt. This OM is pegged when the first page request is sent to the zone and zonelist, where zone_list option is selected in table CDMAPGZN:PAGEOPT field. Note: For the zone_list option, if the zone list is configured as empty, then even though the page attempt would only affect the zone (i.e. mobiles last known zone), this OM is pegged.
0
For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
PGZNLPIR New OM in 13.0 release
PaGe ZoNe+zoneList Page In-zone Response. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the first page request that was sent to the zone and zonelist (where zone_list option is selected in table CDMAPGZN:PAGEOPT field). For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
sheet 100 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register PGZNLPOR New OM in 13.0 release Description
PaGe ZoNe+zoneList Page Out-of-zone Response. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the first page request that was sent to the zone and zonelist (where zone_list option is selected in table CDMAPGZN:PAGEOPT field). For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
For BCP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL. Paging performance (page 10-1) Border paging performance (page 11-1)
PGZNSYRQ New OM in 13.0 release
PaGe ZoNe SYstem ReQuest. This OM is pegged when the first page request is sent system-wide, where system_page option is selected in table CDMAPGZN:PAGEOPT field. For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 101 of 225
CDMA
NBSS15.0
21-102 MSC OM descriptions Nortel Networks MSC operational measurements Register PGZNSYIR New OM in 13.0 release Description
PaGe ZoNe SYstem In-zone Response. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the first page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:PAGEOPT field). For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
PGZNSYOR New OM in 13.0 release
PaGe ZoNe SYstem Out-of-zone Response. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the first page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:PAGEOPT field). For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
sheet 102 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register PGZNTO Modified OM in 13.0 release Description
PaGe ZoNe Time-Out. This OM is pegged when no page response is received within a certain time period for the first page request sent to the zone, regardless of the page option selected in table CDMAPGZN:PAGEOPT field. For IZP zone, this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
Note: When BCP is activated, and the page response is received in a Border system, this OM is pegged for the IZP zone in the Anchor system.
0
sheet 103 of 225
CDMA
NBSS15.0
21-104 MSC OM descriptions Nortel Networks MSC operational measurements Register PGZNAB New OM in 13.0 release Description PaGe ZoNe call ABandon For IZP zone:
this OM is pegged if the call is abandoned (call originator released the call or originator side link failure occurred for mobile to mobile call) after the first page was sent to the zone and before either page response is received or page response timeout occurred. This OM is also pegged in some scenarios for VPAD feature when page request is sent again if during waiting for page response state, data call origination is received from the mobile. this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
For BCP zone: this OM is pegged when the Border system receives a RELEASE Invoke message from the Anchor system during its first page attempt to cancel paging in the BCP zone. this OM is applicable only when the first page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
RPGZNREQ Modified OM in 13.0 release
RePaGe ZoNe REQuest. This OM is pegged when a second page request is sent to the zone after the first page time-out, where zone_page option is selected in table CDMAPGZN:REPGOPT field. For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 104 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RPGZNRES Modified OM in 13.0 release Description
RePaGe ZoNe RESponse. This OM is pegged when the page response is received for the second page request that was sent to the zone (i.e. where zone_page option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
For BCP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
RPGLPAT New OM in 13.0 release
RePaGe zone+zoneList Page ATtempt. This OM is pegged when a second page request is sent to the zone and zonelist after the first page time-out, where zone_list option is selected in table CDMAPGZN:REPGOPT field. Note: For the zone_list option, if the zone list is configured as empty, then even though the page attempt would only affect the zone (i.e. mobiles last known zone), this OM is pegged.
0
For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 105 of 225
CDMA
NBSS15.0
21-106 MSC OM descriptions Nortel Networks MSC operational measurements Register RPGLPIR New OM in 13.0 release Description
RePaGe zone+zoneList Page In-zone Response. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the second page request that was sent to the zone and zonelist (where zone_list option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
RPGLPOR New OM in 13.0 release
RePaGe zone+zoneList Page Out-of-zone Response. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the second page request that was sent to the zone and zonelist (where zone_list option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
sheet 106 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RPSYSRQ Modified OM in 13.0 release Description
RePage SYStem ReQuest. This OM is pegged when a second page request is sent system-wide after the first page time-out, where system_page option is selected in table CDMAPGZN:REPGOPT field. For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
RPSYSRSI Modified OM in 13.0 release
RePage SYStem ReSponse In-zone. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the second page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
sheet 107 of 225
CDMA
NBSS15.0
21-108 MSC OM descriptions Nortel Networks MSC operational measurements Register RPSYSRSO Modified OM in 13.0 release Description
RePage SYStem ReSponse Outside of zone. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the second page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
REPGTO Modified OM in 13.0 release
REPaGe Time-Out. This OM is pegged when no page response is received within a certain time period for the second page request sent to the zone, regardless of the page option selected in table CDMAPGZN:REPGOPT field. For IZP zone, this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
Note: When BCP is activated, and the page response is received in a Border system, this OM is pegged for the IZP zone in the Anchor system.
0
sheet 108 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RPGZNAB New OM in 13.0 release Description RePaGe ZoNe call ABandon. For IZP zone:
this OM is pegged if the call is abandoned (call originator released the call or originator side link failure occurred for mobile to mobile call) after the second page was sent to the zone and before either page response is received or page response timeout occurred. This OM is also pegged in some scenarios for VPAD feature when page request is sent again if during waiting for page response state, data call origination is received from the mobile. this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
For BCP zone: this OM is pegged when the Border system receives a RELEASE Invoke message from the Anchor system during its second page attempt to cancel paging in the BCP zone. this OM is applicable only when the second page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
PG3ZNREQ New OM in 13.0 release
PaGe 3rd ZoNe REQuest. This OM is pegged when a third page request is sent to the zone after the second page time-out, where zone_page option is selected in table CDMAPGZN:REPGOPT field. For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 109 of 225
CDMA
NBSS15.0
21-110 MSC OM descriptions Nortel Networks MSC operational measurements Register PG3ZNRES New OM in 13.0 release Description
PaGe 3rd ZoNe RESponse. This OM is pegged when the page response is received for the third page request that was sent to the zone (i.e. where zone_page option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
For BCP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
PG3LPAT New OM in 13.0 release
PaGe 3rd zone+zoneList Page ATtempt. This OM is pegged when a third page request is sent to the zone and zonelist after the second page time-out, where zone_list option is selected in table CDMAPGZN:REPGOPT field. Note: For the zone_list option, if the zone list is configured as empty, then even though the page attempt would only affect the zone (i.e. mobiles last known zone), this OM is pegged.
0
For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 110 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register PG3LPIR New OM in 13.0 release Description
PaGe 3rd zone+zoneList Page In-zone Response. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the third page request that was sent to the zone and zonelist (where zone_list option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
PG3LPOR New OM in 13.0 release
PaGe 3rd zone+zoneList Page Out-of-zone Response. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the third page request that was sent to the zone and zonelist (where zone_list option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
sheet 111 of 225
CDMA
NBSS15.0
21-112 MSC OM descriptions Nortel Networks MSC operational measurements Register PG3SYSRQ New OM in 13.0 release Description
PaGe 3rd SYStem ReQuest. This OM is pegged when a third page request is sent system-wide after the second page timeout, where system_page option is selected in table CDMAPGZN:REPGOPT field. For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL. For BCP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
PG3SYSRI New OM in 13.0 release
PaGe 3rd SYStem Response In-zone. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the third page request that was sent systemwide (where system_page option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
sheet 112 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register PG3SYSRO New OM in 13.0 release Description
PaGe 3rd SYStem Response Out-of-zone. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the third page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:REPGOPT field). For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
0
PG3ZNTO New OM in 13.0 release
PaGe 3rd ZoNe Time-Out. This OM is pegged when no page response is received within a certain time period for the third page request sent to the zone, regardless of the page option selected in table CDMAPGZN:REPGOPT field. For IZP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
Note: When BCP is activated, and the page response is received in a Border system, this OM is pegged for the IZP zone in the Anchor system. For BCP zone, this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 113 of 225
CDMA
NBSS15.0
21-114 MSC OM descriptions Nortel Networks MSC operational measurements Register PG3ZNAB New OM in 13.0 release Description PaGe 3rd ZoNe call ABandon. For IZP zone:
this OM is pegged if the call is abandoned (call originator released the call or originator side link failure occurred for mobile to mobile call) after the third page was sent to the zone and before either page response is received or page response timeout occurred. This OM is also pegged in some scenarios for VPAD feature when page request is sent again if during waiting for page response state, data call origination is received from the mobile. this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
For BCP zone: this OM is pegged when the Border system receives a RELEASE Invoke message from the Anchor system during its third page attempt to cancel paging in the BCP zone. this OM is applicable only when the third page attempt is configured to use the ZONE paging method in the INCOMING_ISPAGE2_PAGING parameter of Table PAGECTRL.
sheet 114 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMAPGZX OM group New OM group in 13.0 release Description
Reference chapter Call setup performance (page 2-1) Paging performance (page 10-1)
CDMA PaGe Zone eXtension. This OM group has extension registers for each OM in the CDMAPGZN OM group. For example, the extension register for PGZNREQ OM (in CDMAPGZN group) is PGZNREQX in this group.
sheet 115 of 225
CDMA
NBSS15.0
21-116 MSC OM descriptions Nortel Networks MSC operational measurements Register CDMAPGZ2 OM group New OM group in 14.0 release Description
CDMA PaGe Zone 2. This OM group is an extension of the CDMAPGZN OM group and it consists of OMs that track additional zone paging events (i.e. delayed page responses) per paging zone. This OM group has the same structure as CDMAPGZN, so refer to the CDMAPGZN OM group description for any additional information. The delayed page response OMs in this group are applicable to IZP zones only when the first/second page attempt is configured to use the ZONE paging method in the LOCAL_CIRCUIT_PAGING and/or LOCAL_PACKET_DATA_PAGING parameters of Table PAGECTRL.
PGZNIDR
PaGe ZoNe response with In-zone Delayed Response on attempt 1. This OM is pegged when a delayed page response is received within the zone (i.e. in mobiles last known zone), for the first page request, regardless of the zone page option used (CDMAPGZN:PAGEOPT parameter). PaGe ZoNe response with Out-of-zone Delayed Response on attempt 1. This OM is pegged when a delayed page response is received from outside the zone (i.e. in mobiles last known zone), for the first page request, regardless of the zone page option used (CDMAPGZN:PAGEOPT parameter). RePaged ZoNe response with In-zone Delayed Response on attempt 2. This OM is pegged when a delayed page response is received within the zone (i.e. in mobiles last known zone), for the second page request, regardless of the zone page option used (CDMAPGZN:REPGOPT parameter). RePaged ZoNe response with Out-of-zone Delayed Response on attempt 2. This OM is pegged when a delayed page response is received from outside the zone (i.e. in mobiles last known zone), for the second page request, regardless of the zone page option used (CDMAPGZN:REPGOPT parameter).
sheet 116 of 225
PGZNODR
RPZNIDR
RPZNODR
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMASIPG OM group New OM group in 13.0 release Description
CDMA Serving Intersystem PaGe. This OM group is pegged at the Anchor system on a per Anchor cell, per Anchor sector and per route (i.e. per intersystem route with a Border system) basis. These OMs only apply to Border Cell Paging in the Anchor system. These OMs track the intersystem remote page attempts, remote page successes, remote page timeouts and remote page failures (where remote refers to events occurring at the Border system). However, these OMs cannot distinguish between first, second and third remote page attempts. Note: There is no correlation between the border page attempt number with the anchor page attempt number. This is because the Anchor system may send the ISPAGE2 Invoke message to the Border system during its first, second or third local page attempt, always indicating the number of page attempts that the Border system should make. Hence, the Anchor system sends only one ISPAGE2 Invoke message to the Border system for a call termination.
0
These OMs are pegged in the Anchor system when: BCP is activated in the Anchor system and, ISPAGE2 Invoke message is sent by the Anchor System.
Note: If BCP is not activated in the Border system, then Border system returns ISPAGE2 return result message with failure indication. Also, even when BCP is activated in the Border system, the Anchor system has no knowledge or control over the paging method used in the Border system. These OMs are pegged regardless of the paging method (system-wide or zone) used in the border page attempts.
sheet 117 of 225
CDMA
NBSS15.0
21-118 MSC OM descriptions Nortel Networks MSC operational measurements Register IPG2VATT Description
Intersystem PaGe 2 Voice call ATTempts. This OM is pegged when the ISPAGE2 Invoke message is sent to the Border system for voice calls. Note: The Anchor system sends only one ISPAGE2 Invoke message to the Border system for a call termination, indicating the number of page attempts that the Border system should make.
0
IPG2VATX
Intersystem PaGe 2 Voice call ATtempts eXtension. This OM is the extension of IPG2VATT. Intersystem PaGe 2 Voice Return Results. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system indicating that page response was received in the Border system. Intersystem PaGe 2 Voice Return Results eXtension. This OM is the extension of IPG2VRR. Intersystem PaGe 2 Voice Timeout. This OM is pegged for voice calls in two scenarios: When the ISPAGE2 return result message is received from the Border system indicating that 'no page response' was received in the Border system. When the ISPAGE2 return result message is not received from the Border system within the specified time limit. This time limit is specified by the Anchor system to the Border System in the ISPAGE2 Invoke message (Anchor system determines the time limit using the CDMA_PAGE_TIMEOUT and CDMA_LAST_PAGE_TIMEOUT parameters in Table PAGECTRL). In addition, the Anchor system allows a network time delay for the ISPAGE2 return result message (configured in the Table PAGECTRL:ISPAGE2_NETWORKING_DELAY_TIME parameter).
IPG2VRR
IPG2VRRX
IPG2VTO
sheet 118 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IPG2VTOX Description
Intersystem PaGe 2 Voice Timeout eXtension. This OM is the extension of IPG2VTO. Intersystem PaGe 2 Voice Return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system indicating unsuccessful intersystem pages due to a reason other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 Voice Return result FaiLure eXtension. This OM is the extension of IPG2VRFL. Intersystem PaGe 2 packet Data ATTempts. This OM is pegged when the ISPAGE2 Invoke message is sent to the Border system for packet Data calls. Note: The Anchor system sends only one ISPAGE2 Invoke message to the Border system for a call termination, indicating the number of page attempts that the Border system should make.
IPG2VRFL
IPG2VRFX
IPG2DATT
IPG2DATX
Intersystem PaGe 2 packet Data ATtempts eXtension. This OM is the extension of IPG2VATT. Intersystem PaGe 2 packet Data Return Result. This OM is pegged when the ISPAGE2 return result message is received (for Packet Data calls) from the Border system indicating that page response was received in the Border system. Intersystem PaGe 2 packet Data Return Result eXtension. This OM is the extension of IPG2DRR.
sheet 119 of 225
IPG2DRR
IPG2DRRX
CDMA
NBSS15.0
21-120 MSC OM descriptions Nortel Networks MSC operational measurements Register IPG2DTO Description
Intersystem PaGe 2 packet Data TimeOut.This OM is pegged for Packet Data calls in two scenarios: When the ISPAGE2 return result message is received from the Border system indicating that 'no page response' was received in the Border system. When the ISPAGE2 return result message is not received from the Border system within the specified time limit. This time limit is specified by the Anchor system to the Border System in the ISPAGE2 Invoke message (Anchor system determines the time limit using the CDMA_PAGE_TIMEOUT and CDMA_LAST_PAGE_TIMEOUT parameters in Table PAGECTRL). In addition, the Anchor system allows a network time delay for the ISPAGE2 return result message (configured in the Table PAGECTRL:ISPAGE2_NETWORKING_DELAY_TIME parameter).
IPG2DTOX
Intersystem PaGe 2 packet Data TimeOut eXtension. This OM is the extension of IPG2DTO. Intersystem PaGe 2 packet Data Return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for Packet Data calls) from the Border system indicating unsuccessful intersystem pages due to a reason other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 packet Data Return result FaiLure eXtension. This OM is the extension of IPG2DRFL. Intersystem PaGe 2 SMS ATTempts. This OM is pegged when an ISPAGE2 Invoke message is sent to the Border system for SMS. Intersystem PaGe 2 SMS ATtempts eXtension. This OM is an extension of IPG2SATT.
sheet 120 of 225
IPG2DRFL
IPG2DRFX
IPG2SATT New OM in 14.0 release IPG2SATX New OM in 14.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IPG2SRR New OM in 14.0 release Description Intersystem PaGe 2 SMS Return Results.
This OM is pegged when an ISPAGE2 Return Result message is received (for SMS) from the Border system indicating that the page response was received from the mobile in the Border system. Intersystem PaGe 2 SMS Return Results eXtension. This OM is an extension of IPG2SRR. Intersystem PaGe 2 SMS TimeOut. This OM is pegged for SMS in two scenarios: -When the ISPAGE2 Return Result message is received from the Border system indicating that 'no page response' was received in the Border system. -When the ISPAGE2 Return Result message is not received from the Border system within the specified time limit.
IPG2SRRX New OM in 14.0 release IPG2STO New OM in 14.0 release
IPG2STOX New OM in 14.0 release IPG2SRFL New OM in 14.0 release
Intersystem PaGe 2 SMS TimeOut eXtension. This OM is an extension of IPG2STO. Intersystem PaGe 2 SMS Return result FaiLure. This OM is pegged when the ISPAGE2 Return Result message is received (for SMS) from the Border system indicating unsuccessful intersystem pages due to a reason other than 'no page response'. In such cases the Access denied reasons in the ISPAGE2 Return Result include: "Busy" "Operation Not Supported" "Service Reject By System" "Shortage" "Unavailable"
sheet 121 of 225
CDMA
NBSS15.0
21-122 MSC OM descriptions Nortel Networks MSC operational measurements Register IPG2SRFX New OM in 14.0 release Description
Intersystem PaGe 2 SMS Return result Failure eXtension. This OM is an extension of IPG2SRFL.
sheet 122 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMASIP2 OM group New OM group in 14.0 release Description
CDMA Serving Intersystem Page 2. This OM group is an extension of the CDMASIPG OM group and is pegged at the Anchor system on a per Anchor cell, per Anchor sector and per route (i.e. per intersystem route with a Border system) basis. For voice and packet data calls, these OMs are a refinement of the intersystem remote page success and failure OMs in CDMASIPG because those events are tracked here in terms of first, second and third local page attempts. This OM group has the same structure as CDMASIPG, so refer to the CDMASIPG OM group description for any additional information.
IPG2V1RR
Intersystem PaGe 2 Voice 1st page Return Results. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system during the first local page attempt, indicating that page response was received in the Border system. Intersystem PaGe 2 Voice 1st page Return results eXtension. This OM is the extension of IPG2V1RR. Intersystem PaGe 2 Voice 2nd page Return Results. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system during the second local page attempt, indicating that page response was received in the Border system. Intersystem PaGe 2 Voice 2nd page Return results eXtension. This OM is the extension of IPG2V2RR. Intersystem PaGe 2 Voice 3rd page Return Results. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system during the third local page attempt, indicating that page response was received in the Border system. Intersystem PaGe 2 Voice 3rd page Return results eXtension. This OM is the extension of IPG2V3RR.
sheet 123 of 225
IPG2V1RX
IPG2V2RR
IPG2V2RX
IPG2V3RR
IPG2V3RX
CDMA
NBSS15.0
21-124 MSC OM descriptions Nortel Networks MSC operational measurements Register IPG2V1FL Description
Intersystem PaGe 2 Voice 1st page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system during the first local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 Voice 1st page return result Failure eXtension. This OM is the extension of IPG2V1FL. Intersystem PaGe 2 Voice 2nd page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system during the second local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 Voice 2nd page return result Failure eXtension. This OM is the extension of IPG2V2FL. Intersystem PaGe 2 Voice 3rd page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for voice calls) from the Border system during the third local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 Voice 3rd page return result Failure eXtension. This OM is the extension of IPG2V3FL. Intersystem PaGe 2 packet Data 1st page Return Results. This OM is pegged when the ISPAGE2 return result message is received (for packet data calls) from the Border system during the first local page attempt, indicating that page response was received in the Border system. Intersystem PaGe 2 packet Data 1st page Return results eXtension. This OM is the extension of IPG2D1RR.
IPG2V1FX
IPG2V2FL
IPG2V2FX
IPG2V3FL
IPG2V3FX
IPG2D1RR
IPG2D1RX
sheet 124 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IPG2D2RR Description
Intersystem PaGe 2 packet Data 2nd page Return Results. This OM is pegged when the ISPAGE2 return result message is received (for packet data calls) from the Border system during the second local page attempt, indicating that page response was received in the Border system. Intersystem PaGe 2 packet Data 2nd page Return results eXtension. This OM is the extension of IPG2D2RR. Intersystem PaGe 2 packet Data 3rd page Return Results. This OM is pegged when the ISPAGE2 return result message is received (for packet data calls) from the Border system during the third local page attempt, indicating that page response was received in the Border system. Intersystem PaGe 2 packet Data 3rd page Return results eXtension. This OM is the extension of IPG2D3RR. Intersystem PaGe 2 packet Data 1st page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for packet data calls) from the Border system during the first local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 packet Data 1st page return result Failure eXtension. This OM is the extension of IPG2D1FL. Intersystem PaGe 2 packet Data 2nd page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for packet data calls) from the Border system during the second local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 packet Data 2nd page return result Failure eXtension. This OM is the extension of IPG2D2FL.
IPG2D2RX
IPG2D3RR
IPG2D3RX
IPG2D1FL
IPG2D1FX
IPG2D2FL
IPG2D2FX
sheet 125 of 225
CDMA
NBSS15.0
21-126 MSC OM descriptions Nortel Networks MSC operational measurements Register IPG2D3FL Description
Intersystem PaGe 2 packet Data 3rd page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for packet data calls) from the Border system during the third local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 packet Data 3rd page return result Failure eXtension. This OM is the extension of IPG2D3FL. Intersystem PaGe 2 SMS Return Results 1. This OM is pegged when an ISPAGE2 Return Result message is received (for SMS) during the first local page attempt indicating that the page response was received from the mobile in the Border system. Note for every IPG2SATT peg, the success event is pegged by either IPG2SRR1 or IPG2SRR2 but never both.
IPG2D3FX
IPG2S1RR
IPG2S1RX
Intersystem PaGe 2 SMS Return results 1 eXtension. This OM is an extension of IPG2S1RR.
IPG2S2RR
Intersystem PaGe 2 SMS Return Results 2. This OM is pegged when an ISPAGE2 Return Result message is received (for SMS) during the second local page attempt indicating that the page response was received from the mobile in the Border system. Note for every IPG2SATT peg, the success event is pegged by either IPG2SRR1 or IPG2SRR2 but never both.
IPG2S2RX
Intersystem PaGe 2 SMS Return results 2 eXtension. This OM is an extension of IPG2S2RR.
IPG2S1FL
Intersystem PaGe 2 SMS 1st page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for SMS) from the Border system during the first local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied.
sheet 126 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IPG2S1FX Description
Intersystem PaGe 2 SMS 1st page return result Failure eXtension. This OM is the extension of IPG2S1FL. Intersystem PaGe 2 SMS 2nd page return result FaiLure. This OM is pegged when the ISPAGE2 return result message is received (for SMS) from the Border system during the second local page attempt, indicating unsuccessful intersystem pages due to reasons other than 'no page response', such as mobile is busy or termination to mobile is denied. Intersystem PaGe 2 SMS 2nd page return result Failure eXtension. This OM is the extension of IPG2S2FL.
sheet 127 of 225
IPG2S2FL
IPG2S2FX
CDMA
NBSS15.0
21-128 MSC OM descriptions Nortel Networks MSC operational measurements Register CDMPRDIS OM group New OM group in 13.0 release Description
CDMa Page Response DIStribution. This OM group is pegged at the CM and it measures the time distribution of page responses received at the CM. When a page response is received at the CM, one of the 16 registers of this OM group is pegged based on the value of Page Response Time in seconds. Page Response Time refers to the time interval between a page request and the corresponding page response. The 16 registers are named as PRDIS01 through PRDIS16. The PRDISnn OM is used to count the number of page responses for which the page response is received between [nn-1] seconds (inclusive [nn-1]) to nn seconds (exclusive nn). As example, for all page responses received between 5 (inclusive 5) to 6 seconds (exclusive 6), the PRDIS06 OM is pegged. When the page response is received in 15 seconds or greater, then the PRDIS16 OM is pegged. Office parameter MTX_CDMA_PGRES_TIME_OM must be Y for this OM group to be pegged.
sheet 128 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SMSZONPG OM group Modified in 14.0 release Description
Reference chapter Call setup performance (page 2-1) Paging performance (page 10-1) Border paging performance (page 11-1) Border paging performance (page 11-1)
SMS ZONe PaGe. This OM group tracks events per paging zone and per paging zone type. The paging zone type can be an IZP zone (Intelligent Zone Paging) or a BCP zone (Border Cell Paging). OMs in this group is pegged for SMS only. This OM group has the similar structure as CDMAPGZN, so refer to the CDMAPGZN OM group description for any additional information.
PGZNREQ Modified in 14.0 release
PaGe ZoNe REQuest. This OM is pegged when an first page request is sent to the zone, where zone_page option is selected in table CDMAPGZN:PAGEOPT field. The additional conditions for this OM to peg are same as the ones for PGZNREQ OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
PGZNRES Modified in 14.0 release
PaGe ZoNe RESponse. This OM is pegged when the page response is received for the first page request that was sent to the zone (i.e. where zone_page option is selected in table CDMAPGZN:PAGEOPT field). The additional conditions for this OM to peg are same as the ones for PGZNRES OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
PGZNTO Modified in 14.0 release
PaGe ZoNe Time-Out. This OM is pegged when no page response is received within a certain time period for the first page request sent to the zone, regardless of the page option selected in table CDMAPGZN:PAGEOPT field. The additional conditions for this OM to peg are same as the ones for PGZNTO OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
sheet 129 of 225
CDMA
NBSS15.0
21-130 MSC OM descriptions Nortel Networks MSC operational measurements Register PGZNAB New OM in 14.0 release Description PaGe ZoNe call ABandon
The additional conditions for this OM to peg are same as the ones for PGZNAB OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING. PaGe ZoNe SYstem ReQuest. This OM is pegged when the first page request is sent system-wide, where system_page option is selected in table CDMAPGZN:PAGEOPT field. The additional conditions for this OM to peg are same as the ones for PGZNSYRQ OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
PGZNSYRQ New OM in 14.0 release
PGZNSYIR New OM in 14.0 release
PaGe ZoNe SYstem In-zone Response. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the first page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:PAGEOPT field). The additional conditions for this OM to peg are same as the ones for PGZNSYIR OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
PGZNSYOR New OM in 14.0 release
PaGe ZoNe SYstem Out-of-zone Response. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the first page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:PAGEOPT field). The additional conditions for this OM to peg are same as the ones for PGZNSYOR OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
sheet 130 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RPGZNREQ Modified in 14.0 release Description
RePaGe ZoNe REQuest. This OM is pegged when a zone is repaged after the first page time-out, where zone_page option is selected in table CDMAPGZN:REPGOPT field. The additional conditions for this OM to peg are same as the ones for RPGZNREQ OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
RPGZNRES Modified in 14.0 release
RePaGe ZoNe RESponse. This OM is pegged when the page response is received for the second page request that was sent to the zone (i.e. where zone_page option is selected in table CDMAPGZN:REPGOPT field. The additional conditions for this OM to peg are same as the ones for RPGZNRES OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
RPSYSRQ Modified in 14.0 release
RePage SYStem ReQuest. This OM is pegged when a second page request is sent system-wide after the first page time-out, where system_page option is selected in table CDMAPGZN:REPGOPT field. The additional conditions for this OM to peg are same as the ones for RPSYSRQ OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
RPSYSRSI New OM in 14.0 release
RePage SYStem ReSponse In-zone. This OM is pegged when page response is received within the zone (i.e. in mobiles last known zone), for the second page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:REPGOPT field). The additional conditions for this OM to peg are same as the ones for RPSYSRSI OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
sheet 131 of 225
CDMA
NBSS15.0
21-132 MSC OM descriptions Nortel Networks MSC operational measurements Register RPSYSRSO New OM in 14.0 release Description
RePage SYStem ReSponse Outside of zone. This OM is pegged when page response is received from outside the zone (i.e. not in mobiles last known zone), for the second page request that was sent system-wide (where system_page option is selected in table CDMAPGZN:REPGOPT field). The additional conditions for this OM to peg are same as the ones for RPSYSRSO OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
REPGTO Modified in 14.0 release
REPaGe Time-Out. This OM is pegged when no page response is received within a certain time period for the second page request sent to the zone, regardless of the page option selected in table CDMAPGZN:REPGOPT field. The additional conditions for this OM to peg are same as the ones for REPGTO OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
RPGZNAB New OM in 14.0 release
RePaGe ZoNe call ABandon. The additional conditions for this OM to peg are same as the ones for RPGZNAB OM in CDMAPGZN OM group except that the applicable parameter in Table PAGECTRL is called LOCAL_DDS_PAGING.
sheet 132 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SMSZONPX OM group New OM group in 14.0 release Description
Reference chapter Call setup performance (page 2-1) Paging performance (page 10-1) Border paging performance (page 11-1)
sheet 133 of 225
SMS ZONe Page eXtension. This OM group has extension registers for each OM in the SMSZONPG OM group. For example, the extension register for PGZNREQ OM (in SMSZONPG group) is PGZNREQX in this group.
CDMA
NBSS15.0
21-134 MSC OM descriptions Nortel Networks MSC operational measurements Register SMSBIPG New OM group in 14.0 release Description
SMS Border Intersystem PaGe. This OM group is pegged at the Border system on per route (i.e. per intersystem route with an Anchor system) basis. These OMs only apply to Border Cell Paging in the Border system for SMS calls. These OMs track the border page attempts, successes, timeouts and releases (i.e. border page cancellations) for a route and can distinguish between first and second border page attempts for SMS calls. This OM group also tracks the number of SMS data delivery attempts, successes and failures at Border system. OMs in this group is pegged for SMS only. This OM group has the similar structure as CDMABIPG, so refer to the CDMABIPG OM group description for any additional information and notes.
IP2B1SAT New OM in 14.0 release IP2B1SRS New OM in 14.0 release IP2B1STO New OM in 14.0 release IP2B1SRL New OM in 14.0 release
Intersystem Page 2 Border system for 1st SMS page ATtempt. This OM is pegged when the first page attempt is made in the Border system for SMS. Intersystem Page 2 Border system for 1st SMS page ReSponse. This OM is pegged when a page response is received for the first page attempt made in the Border system for SMS. Intersystem Page 2 Border system for 1st SMS page TimeOut. This OM is pegged when the Border system times out waiting for the page response for the first page attempt made in the Border system for SMS. Intersystem Page 2 Border system for 1st SMS page ReLease. This OM is pegged when the Border system cancels paging for the first page attempt made in the Border system for SMS.
sheet 134 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IP2B1SFL New OM in 14.0 release Description
Intersystem Page 2 Border system for 1st SMS page Failure. This OM is pegged when the Border system encounters a paging problem during the 1st page attempt and sends an ISPAGE2 Return Result message (for SMS) to the Anchor system indicating the paging failure reason. In such cases the cause codes in the ISPAGE2 Return Result include: "Busy" "Operation Not Supported" "Service Reject By System" "Shortage" "Unavailable"
IP2B2SAT New OM in 14.0 release IP2B2SRS New OM in 14.0 release IP2B2STO New OM in 14.0 release IP2B2SRL New OM in 14.0 release
Intersystem Page 2 Border system for 2nd SMS page ATtempt. This OM is pegged when the second page attempt is made in the Border system for SMS. Intersystem Page 2 Border system for 2nd SMS page ReSponse. This OM is pegged when a page response is received for the second page attempt made in the Border system for SMS. Intersystem Page 2 Border system for 2nd SMS page TimeOut. This OM is pegged when the Border system times out waiting for the page response for the second page attempt made in the Border system for SMS. Intersystem Page 2 Border system for 2nd SMS page ReLease. This OM is pegged when the Border system cancels paging for the second page attempt made in the Border system for SMS.
sheet 135 of 225
CDMA
NBSS15.0
21-136 MSC OM descriptions Nortel Networks MSC operational measurements Register IP2B2SFL New OM in 14.0 release Description
Intersystem Page 2 Border system for 2nd SMS page Failure. This OM is pegged when the Border system encounters a paging problem during the 2nd page attempt and sends an ISPAGE2 Return Result message (for SMS) to the Anchor system indicating the paging failure reason. In such cases the cause codes in the ISPAGE2 Return Result include: "Busy" "Operation Not Supported" "Service Reject By System" "Shortage" "Unavailable"
SMSBDDAT New OM in 14.0 release SMSBDDSC New OM in 14.0 release SMSBDDFL New OM in 14.0 release
This OM is pegged when a Forward Data Delivery (FDD) message is sent by the Border system to the mobile.
This OM is pegged when a Reverse Data Delivery (RDD) message is received from the mobile, indicating that the SMS was successfully received by the mobile.
This OM is pegged when a Reverse Data Delivery (RDD) message is not received from the mobile (i.e. the Border system times out) or the RDD contains a failure cause code. The failure causes are: No DataBurst Ack from the mobile. Mobile rejected SMS bearer data.
sheet 136 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MWIZONPG OM group Description
Reference chapter Call setup performance (page 2-1) Paging performance (page 10-1)
MWI ZONe PaGe. This OM group tracks events per IZP Zone. These OMs are pegged only when Intelligent Paging is activated through SOC. OMs in this group are pegged for MWI only.
PGZNREQ
PaGe ZoNe REQuest. This OM is pegged when an initial (first) page request is sent to the zone. This OM is not pegged when MWI is sent to the last know cell. PaGe ZoNe REQuest eXtension. This OM is the extension of PGZNREQ. PaGe ZoNe RESponse. This OM is pegged when the page response is received for the initial (first) page sent to the zone.This OM is not pegged when MWI is sent to the last know cell. PaGe ZoNe RESponse eXtension. This OM is the extension of PGZNRES. PaGe ZoNe Time-Out. This OM is pegged when no page response received within a certain time period for the initial (first) page sent to the zone. This OM is not pegged when MWI is sent to the last know cell. RePaGe ZoNe REQuest. This OM is pegged when a zone is repaged after the initial zone page time-out. This register is only pegged when zone repage option is selected for a zone. RePaGe ZoNe ReQuest eXtension. This OM is the extension of RPGZNREQ.
Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1)
PGZNREQ2
PGZNRES
PGZNRES2
PGZNTO
RPGZNREQ
RPGZNRQ2
sheet 137 of 225
CDMA
NBSS15.0
21-138 MSC OM descriptions Nortel Networks MSC operational measurements Register RPGZNRES Description
RePaGe ZoNe RESponse. This OM is pegged when a page response is received within the zone where repage request was sent. This register is only pegged when zone repage option is selected for a zone. In case of IS95B mobile responding back from outside of the original zone (Access Entry Handoff), this OM will not be pegged if paging CAU does not receive the page response message. The page response message will be discarded by the system. In this case, REPGTO OM is pegged. RePaGe ZoNe ReSponse eXtension. This OM is the extension of RPGZNRES. RePage SYStem ReQuest. This OM is pegged when a repage is sent to the entire system after the initial zone page time-out. This register is only pegged when system-wide repage is selected for a zone. RePage SYStem ReQuest eXtension. This OM is the extension of RPSYSRQ. RePage SYStem ReSponse. This OM is pegged when a page response (from original zone or out of zone) is received for a system-wide MWI repage. RePage SYstem ReSponse eXtension. This OM is the extension of RPSYSRS. REPaGe Time-Out. This OM is pegged when no response is received for a repage is done for a zone. This register is pegged whether same zone or system-wide repage is selected for a zone.
sheet 138 of 225
RPGZNRS2
Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1) Paging performance (page 10-1)
RPSYSRQ
RPSYSRQ2
RPSYSRS
RPSYRS2
REPGTO
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDMAVSO OM group Description
CDMA Voice Service Options. This OM group is pegged per RMU, per Service Option basis.
ATEVRC
ATtempts for EVRC. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the EVRC service option. SUccessful resource allocation for EVRC. This OM is pegged when a resource for an EVRC service option request has been successfully allocated Hop Count for EVRC. This OM is pegged for each pool, including the first pool, as the RMU searches through a list of pools to find a resource for this service option. FaiLures for EVRC. This OM is pegged when an attempt to allocate resource for the EVRC service option fails. It is due to no resources available in any pool from a list. ATtempts for BaSiC 13K. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the Basic 13K service option. SUccessful resource allocation for BaSiC 13K. This OM is pegged when a resource for a BASIC 13K service option request has been successfully allocated Hop Count for BaSiC 13K. This OM is pegged for each pool, including the first pool, as the RMU searches through a list of pools to find a resource for this service option. FaiLures for BaSiC 13K. This OM is pegged when an attempt to allocate resource for the Basic 13K service option fails. It is due to no resources available in any pool from a list.
sheet 139 of 225
SUEVRC
HCEVRC
FLEVRC
ATBSC13K
SUBSC13K
HCBSC13K
FLBSC13K
CDMA
NBSS15.0
21-140 MSC OM descriptions Nortel Networks MSC operational measurements Register ATIS13K Description
ATtempts for IS733 13K. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the IS 733 13K service option. SUccessful resource allocation for IS733 13K. This OM is pegged when a resource for an IS733 13K service option request has been successfully allocated Hop Count for IS733 13K. This OM is pegged for each pool, including the first pool, as the RMU searches through a list of pools to find a resource for this service option. FaiLures for IS733 13K. This OM is pegged when an attempt to allocate resource for the IS733 13K service option fails. It is due to no resources available in any pool from a list. ATtempts for Short Message Service. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the SMS service option. SUccessful resource allocation for Short Message Service. This OM is pegged when a resource for an SMS service option request has been successfully allocated Hop Count for Short Message Service. This OM is pegged for each pool, including the first pool, as the RMU searches through a list of pools to find a resource for this service option. FaiLures for Short Message Service. This OM is pegged when an attempt to allocate resource for the SMS service option fails. It is due to no resources available in any pool from a list. ATtempts for OTAPA. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the OTAPA_RATESET_1 service option.
sheet 140 of 225
SUIS13K
HCIS13K
FLIS13K
ATSMS
SUSMS
HCSMS
FLSMS
ATOTAPA
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SUOTAPA Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
SUccessful resource allocation for OTAPA. This OM is pegged when a resource for OTAPA_RATESET_1 service option request has been successfully allocated Hop Count for OTAPA. This OM is pegged for each pool, including the first pool, as the RMU searches through a list of pools to find a resource for this service option. FaiLures for OTAPA. This OM is pegged when an attempt to allocate resource for the OTAPA_RATESET_1 service option fails. It is due to no resources available in any pool from a list. ATtempts for LoCation Services. This OM is pegged when there is an attempt made by RMU for a resource request from CAU to allocate resource for the LCS (Location Services) service option. SUccessful resource allocation for LoCation Services. This OM is pegged when a resource for a LCS service option request has been successfully allocated. Hop Count for LoCation Services. This OM is pegged for each pool, including the first pool, the RMU searches through from a list of pools to find a resource for LCS service option. FaiLures for LoCation Services. This OM is pegged when an attempt to allocate resource for the LCS service option fails. It is due to no resources available in any pool from a list.
sheet 141 of 225
HCOTAPA
FLOTAPA
ATLCS Added in 12.0 release SULCS Added in 12.0 release HCLCS Added in 12.0 release FLLCS Added in 12.0 release
CDMA
NBSS15.0
21-142 MSC OM descriptions Nortel Networks MSC operational measurements Register CDSNMQRY OM group Modified in 14.0 release Description
Reference chapter Call setup performance (page 2-1) Intelligent voice service negotiations performance (page 8-1)
CDma Service Negotiations Mobile QueRY. This OM group is pegged per CAU basis. Note: This OM group is pegged at the CAU, but when OMSHOW performed, they are displayed per BSC not per CAU.
QRYPAORG
QueRY on Paging/Access channel during ORiGination. This OM is pegged when a query is performed on the paging/access channel to retrieve the mobile capability information during a first call origination. This OM is also pegged when mobile is queried for band class information during MCTA. QueRY on Paging/Access channel during TeRMination. This OM is pegged when a query is performed on the paging/access channel to retrieve the mobile capability information during a first call termination. QueRY on Traffic Channel during ORiGination. This OM is pegged when a query is performed on the traffic channel to retrieve the mobile capability information during a first call origination. QueRY on Traffic Channel during TeRMination. This OM is pegged when a query is performed on the traffic channel to retrieve the mobile capability information during a first call termination. QueRY on Paging/Access channel during REGistration. This OM is pegged when a query is performed on the paging/access channel to retrieve the mobile capability information on paging/ access channel during a first registration. QueRY on Paging/Access channel FaiLed. This OM is pegged when the CAU times out while waiting for the Status Response message when querying a mobile on the paging/access channels. This register will be pegged for queries during registrations, call originations and terminations.
sheet 142 of 225
Intelligent voice service negotiations performance (page 8-1) Chapter 8, Intelligent voice service negotiations performance Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1)
QRYPATRM
QRYTCORG
QRYTCTRM
QRYPAREG
QRYPAFL
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register QRYTCFL Description
Reference chapter Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1) Intelligent voice service negotiations performance (page 8-1)
QueRY on Traffic Channel FaiLed. This OM is pegged when the CAU times out while waiting for the Status Response message when querying a mobile on the FWD/REV traffic channels. This register will be pegged for queries during call originations and terminations. FaiLed Traffic Channel using EVRc. This OM is pegged when EVRC is used to setup the traffic channel for a 2G voice call but a mobile does not support EVRC. Note: This happens when the mobiles voice service capability is unknown. This register is not pegged for datafill errors in PSOL. This register is only pegged when table SERVSEL is used for service redirection. 3G FaiLed Traffic channel using EVRc. This OM is pegged when EVRC is used to setup the traffic channel for a 3G voice call but a mobile does not support EVRC. Note: This happens when the mobiles voice service capability is unknown. This register is not pegged for datafill errors in PSOL. This register is only pegged when table SERVSEL is used for service redirection. FaiLed Traffic Channel using I733 13K. This OM is pegged when IS733 13K Voice is used to setup the traffic channel for a 2G voice call but a mobile does not support IS733 13K Voice. Note: This happens when the mobiles voice service capability is unknown. This register is not pegged for datafill errors in PSOL. This register is only pegged when table SERVSEL is used for service redirection. 3G FaiLed Traffic channel using I733 13K. This OM is pegged when IS733 13K Voice is used to setup the traffic channel for a 3G voice call but a mobile does not support IS733 13K Voice. Note: This happens when the mobiles voice service capability is unknown. This register is not pegged for datafill errors in PSOL. This register is only pegged when table SERVSEL is used for service redirection. FaiLed Traffic Channel using Basic 13K. This OM is pegged when Basic 13K Voice is used to setup the traffic channel for a 2G call but a mobile does not support Basic 13K Voice. Note: This happens when the mobiles voice service capability is unknown. This register is not pegged for datafill errors in PSOL. This register is only pegged when table SERVSEL is used for service redirection.
sheet 143 of 225
FLTCEVR Modified in 14.0 release
3GFLTEVR New OM in 14.0 release
FLTCI13K Modified in 14.0 release
3GFLI13K New OM in 14.0 release
FLTCB13K Modified in 14.0 release
CDMA
NBSS15.0
21-144 MSC OM descriptions Nortel Networks MSC operational measurements Register 3GFLB13K New OM in 14.0 release Description
FaiLed Traffic Channel using Basic 13K. This OM is pegged when Basic 13K Voice is used to setup the traffic channel for a 3G call but a mobile does not support Basic 13K Voice. Note: This happens when the mobiles voice service capability is unknown. This register is not pegged for datafill errors in PSOL. This register is only pegged when table SERVSEL is used for service redirection. FaiLed Traffic Channel using EVrcB. This OM is pegged when EVRC-B SO is used to setup the traffic channel for the call but a mobile does not support EVRC-B. Note: This happens when the mobiles voice service capability is unknown. This register is not pegged for datafill errors in PSOL. This register is only pegged when table SERVSEL is used for service redirection.
sheet 144 of 225
FLTCEVB New OM in 15.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register DDSLFRBC OM group New OM group in 14.0 release Description
Data Delivery Services Length over Forward and Reverse BAM Channel. The OMs in this group are pegged to capture the number of DDS messages that are sent on the Forward & Reverse BAM Channels. Each OM represents a bin of a certain size of the received message. They are pegged on a system level at the CM. In the forward direction, the OMs are pegged after the page response is received and the DDS message is sent out for delivery. In the reverse direction the OMs are pegged when a DDS message is received from the mobile. DDS messages include SMS, SMS Broadcast, EMS, OTAPA, OTASP and LoCation Services messages. EMS, OTAPA, OTASP and LCS messages are sent only on the traffic channel. OMs in this group peg only for SMS messages sent on the NOIS interface.
BAMF25
11-25 bytes of dds data sent over BAM F-CCCH. This OM represents the number of DDS messages of size 11-25 bytes that were sent over BAM F-CCCH channel.
Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
BAMF50
26-50 bytes of dds data sent over BAM F-CCCH. This OM represents the number of DDS messages of size 26 -50 bytes that were sent over BAM F-CCCH channel.
BAMF75
BAMF100
sheet 145 of 225
CDMA
NBSS15.0
21-146 MSC OM descriptions Nortel Networks MSC operational measurements Register BAMF125 Description
BAMF150
BAMF175
BAMF200
BAMF225
BAMF255
BAMR25
11-25 bytes of dds data sent over BAM R-EACH. This OM represents the number of DDS messages of size 11-25 bytes that were received over BAM R-EACH channel.
sheet 146 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register BAMR50 Description
26-50 bytes of dds data sent over BAM R-EACH. This OM represents the number of DDS messages of size 26 -50 bytes that were received over BAM R-EACH channel.
BAMR75
BAMR100
BAMR125
BAMR150
BAMR175
BAMR200
sheet 147 of 225
CDMA
NBSS15.0
21-148 MSC OM descriptions Nortel Networks MSC operational measurements Register BAMR225 Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
BAMR255
sheet 148 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register DDSLFRBX OM group New OM group in 14.0 release Description
This OM group has extension registers for each OM in the DDSLFRBC OM group. For example, the extension register for BAMF25 OM (in DDSLFRBC group) is BAMF25X OM in this group.
sheet 149 of 225
CDMA
NBSS15.0
21-150 MSC OM descriptions Nortel Networks MSC operational measurements Register DDSLFRCC OM group New OM group in 14.0 release Description
DDS Length over Forward and Reverse Common Channel. This OM group captures the number of DDS messages that are sent on the Paging Channel, Access Channel and Forward & Reverse Traffic Channels. Each OM represents a bin of a certain size of the received message. They are pegged on a system level at the CM. In the forward direction, the OMs are pegged after the page response is received and the DDS message is sent out for delivery. In the reverse direction the OMs are pegged when a DDS message is received from the mobile. DDS messages include SMS, SMS Broadcast, EMS, OTAPA, OTASP and LCS messages. EMS, OTAPA, OTASP and LCS messages are sent only on the traffic channel.
DDSF25
0-25 bytes of DDS data sent over Forward traffic channel. This OM represents the number of DDS messages of size 0-25 bytes that were sent over Forward Traffic channel.
Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
DDSF50
26-50 bytes of DDS data sent over Forward traffic channel. This OM represents the number of DDS messages of size 26 -50 bytes that were sent over Forward Traffic channel.
DDSF75
51-75 bytes of DDS data sent over Forward traffic channel. This OM represents the number of DDS messages of size 51 -75 bytes that were sent over Forward Traffic channel.
DDSF100
76-100 bytes of DDS data sent over Forward traffic channel. This OM represents the number of DDS messages of size 76 100 bytes that were sent over Forward Traffic channel.
DDSF125
sheet 150 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register DDSF150 Description
DDSF175
DDSF200
DDSF225
201-225 bytes of DDS data sent over Forward traffic channel. This OM represents the number of DDS messages of size 201225 bytes that were sent over Forward Traffic channel.
DDSF255
226-255 bytes of DDS data sent over Forward traffic channel. This OM represents the number of DDS messages of size 226255 bytes that were sent over Forward Traffic channel.
DDSR25
0-25 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 0-25 bytes that were received over Reverse Traffic channel.
DDSR50
26-50 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 26 50 bytes that were received over Reverse Traffic channel.
sheet 151 of 225
CDMA
NBSS15.0
21-152 MSC OM descriptions Nortel Networks MSC operational measurements Register DDSR75 Description
DDSR100
DDSR125
101-125 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 101 -125 bytes that were received over Reverse Traffic channel. 126-150 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 126 -150 bytes that were received over Reverse Traffic channel. 151-175 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 151 -175 bytes that were received over Reverse Traffic channel. 176-200 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 176 -200 bytes that were received over Reverse Traffic channel. 201-225 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 201-225 bytes that were received over Reverse Traffic channel.
sheet 152 of 225
DDSR150
DDSR175
DDSR200
DDSR225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register DDSR255 Description
226-255 bytes of DDS data received over Reverse traffic channel. This OM represents the number of DDS messages of size 226-255 bytes that were received over Reverse Traffic channel. 11-25 bytes of DDS data received over Access channel. This OM represents the number of DDS messages of size 11-25 bytes that were received over Access channel.
DDSA25
DDSA50
26-50 bytes of DDS data received over Access channel. This OM represents the number of DDS messages of size 26 -50 bytes that were received over Access channel.
DDSA75
51-75 bytes of DDS data received over Access channel. This OM represents the number of DDS messages of size 51 -75 bytes that were received over Access channel.
DDSA100
76-100 bytes of DDS data received over Access channel. This OM represents the number of DDS messages of size 76 - 100 bytes that were received over Access channel.
DDSP25
11-25 bytes of DDS data sent over Paging channel. This OM represents the number of DDS messages of size 11-25 bytes that were sent over Paging channel.
DDSP50
26-50 bytes of DDS data sent over Paging channel. This OM represents the number of DDS messages of size 26 -50 bytes that were sent over Paging channel.
sheet 153 of 225
CDMA
NBSS15.0
21-154 MSC OM descriptions Nortel Networks MSC operational measurements Register DDSP75 Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
DDSP100
DDSP125
sheet 154 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register DDSLFRCX OM group New OM group in 14.0 release Description
This OM group has extension registers for each OM in the DDSLFRCC OM group. For example, the extension register for DDSF25 OM (in DDSLFRCC group) is DDSF25X OM in this group.
sheet 155 of 225
CDMA
NBSS15.0
21-156 MSC OM descriptions Nortel Networks MSC operational measurements Register EBSCRM OM group New OM group in 14.0 release Description
EBSC Resource Manager. This OM group tracks events on a per-CAU request basis. These OMs are pegged by CAU to measure resource allocation performance of NRM (Network Resource Manager) for call resource allocation requests made from CAU to NRM. This OM group keeps track of resource allocation attempts, success, failures and timeout per CAU request. The OMs in this group peg for Voice/CSD, Packet Data and Data Delivery Services (SMS, LCS, OTAPA) calls.
NRMARV
NRM Attempt Request for Voice. This OM is pegged when CAU sends the resource allocation request to NRM for a voice/CSD call. NRM Attempt Success for Voice. This OM is pegged when CAU receives successful resource allocation response from NRM for a voice/CSD call. NRM Attempt Time Out for Voice. This OM is pegged when CAU times out while waiting for the resource allocation response from CAU for a voice/CSD call. The appropriate CAU*BLKS OM is pegged along with this OM.
Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1)
NRMASV
NRMATOV
NRMANRV
NRM Attempt No Resources for Voice. This OM is pegged when CAU receives unsuccessful resource allocation response from NRM due to the lack of requested resources for a voice/CSD call. The appropriate CAU*BLKS OM is pegged along with this OM.
NRMOEV
NRM attempt Other Error for Voice. This OM is pegged when the CAU receives resource allocation failure response for voice/ CSD calls due to an error condition. The possible failure reasons are: CAU sends unknown service option to NRM in resource allocation request, SDRM/CSRM/SBSRM is administratively locked or an internal error. The appropriate CAU*BLKS OM is pegged along with this OM.
sheet 156 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register NRMOLRV Description
NRM OverLoad Reject for Voice. This OM is pegged when CAU receives resource allocation failure response for voice/CSD calls from NRM as a rejection due to NRMs Overload condition.
NRMSTOV
NRM subSystem Time Out for Voice. This OM is pegged when CAU receives resource allocation failure response from NRM for voice/CSD calls due to NRM time out during resource allocation with SDRM, CSRM or SBSRM. Circuit Identification Code To Termination ID mapping Failure. This OM is pegged when CAU fails to map CIC (circuit selected on CSVS) to TID after a successful resource allocation response is received from NRM for voice calls. SBS to Termination ID mapping Failure. This OM is pegged when CAU fails to map SBS Trunk (circuit selected on SBS) to a TID when a successful resource allocation response is received from the NRM. NRM Attempt Request for Voice 2 (extension). This OM is the extension of NRMARV.
Call resource allocation and management (page 16-1)
CICTTIDF
SBSTIDF
NRMARV2
Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
NRMASV2
NRM Attempt Success for Voice 2 (extension). This OM is the extension of NRMASV.
NRMARPD
NRM Attempt Request for Packet Data. This OM is pegged when CAU sends the resource allocation request to NRM for a packet data call. NRM Attempt Success for Packet Data. This OM is pegged when CAU receives successful resource allocation response from NRM for a packet data call.
NRMASPD
sheet 157 of 225
CDMA
NBSS15.0
21-158 MSC OM descriptions Nortel Networks MSC operational measurements Register NRMATOPD Description
Reference chapter Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
NRM Attempt Time Out for Packet Data. This OM is pegged when CAU times out while waiting for the resource allocation response from NRM for a packet data call. The appropriate CAU*BLKS OM is pegged along with this OM.
NRMANRPD
NRM Attempt No Resources for Packet Data. This OM is pegged when CAU receives unsuccessful resource allocation response from NRM due to the lack of requested resources for a packet data call. The appropriate CAU*BLKS OM is pegged along with this OM.
NRMOEPD
NRM attempt Other Error for Packet Data. This OM is pegged when the CAU receives resource allocation failure response for packet data calls due to an error condition. The possible failure reasons are: CAU sends unknown service option to NRM in resource allocation request, SDRM/SBSRM is administratively locked or an internal error. The appropriate CAU*BLKS OM is pegged along with this OM.
NRMOLRPD
NRM OverLoad Reject for Packet Data. This OM is pegged when CAU receives resource allocation failure response for packet data calls from NRM as a rejection due to NRMs Overload condition. The appropriate CAU*BLKS OM is pegged along with this OM.
NRMSTOPD
NRM subSystem Time Out for Packet Data. This OM is pegged when CAU receives resource allocation failure response from NRM for voice calls due to NRM time out during resource allocation with SDRM or SBSRM. The appropriate CAU*BLKS OM is pegged along with this OM.
sheet 158 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register NRMARPD2 Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1)
NRM Attempt Request for Packet Data 2 (extension). This OM is the extension of NRMARPD.
NRMASPD2
NRM Attempt Success for Packet Data 2 (extension). This OM is the extension of NRMASPD.
NRMARDS
NRM Attempt Request for Data delivery Service. This OM is pegged when CAU sends the resource allocation request to NRM for a data delivery service call. NRM Attempt Success for Data delivery Service. This OM is pegged when CAU receives successful resource allocation response from NRM for a data delivery service call. NRM Attempt Time Out for Data delivery Service. This OM is pegged when CAU times out while waiting for the resource allocation response from CAU for a data delivery service call. The call is blocked in this case.
NRMASDS
NRMATODS
NRMANRDS
NRM Attempt No Resources for Data delivery Service. This OM is pegged when CAU receives unsuccessful resource allocation response from NRM due to the lack of requested resources for a data delivery service call. The call is blocked in this case.
sheet 159 of 225
CDMA
NBSS15.0
21-160 MSC OM descriptions Nortel Networks MSC operational measurements Register NRMOEDS Description
Reference chapter Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call setup performance (page 2-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
NRM attempt Other Error for Data delivery Service. This OM is pegged when the CAU receives resource allocation failure response for data delivery service calls due to an error condition. The possible failure reasons are: CAU sends unknown service option to NRM in resource allocation request, SDRM/SBSRM is administratively locked or an internal error. The call is blocked in this case.
NRMOLRDS
NRM OverLoad Reject for Data delivery Service. This OM is pegged when CAU receives resource allocation failure response for data delivery service calls from NRM as a rejection due to NRMs Overload condition. The call is blocked in this case.
NRMSTODS
NRM subSystem Time Out for Data delivery Service. This OM is pegged when CAU receives resource allocation failure response from NRM for data delivery service calls due to NRM time out during resource allocation with SDRM or SBSRM. The call is blocked in this case.
NRMARDS2
NRM Attempt Request for Data delivery Service 2 (extension). This OM is the extension of NRMARDS.
Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
NRMASDS2
NRM Attempt Success for Data delivery Service 2 (extension). This OM is the extension of NRMASDS.
sheet 160 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register EBPBCPOM OM group New OM group in 14.0 release ESBSRASU Description
EBsc Platform Based Call Processing OM. The OMs in this group are pegged at the CAU on a system level basis for Voice calls irrespective of call type (Origination, Termination or Hard Handoff). These OMs measure call setup success, failures and call drops on the CSVS and SBS subsystems when NRM is the centralized resource manager. Ebsc SBS Resource Allocation Success. This OM is pegged when NRM sends a resource allocation response to the CAU indicating successful resource allocation on the SBS. Ebsc CSVs Resource Allocation Success. This OM is pegged when NRM sends a resource allocation response to the CAU indicating a successful resource allocation on the CSVS. Ebsc SBS Error SoftWare FaiLure. This OM is pegged for all call failures during the call setup phase (i.e communication between CAU and the Selector Element on the SBS). These failures include CAU time-outs, resource mismatches, software failures on the Selector Element. The CAUESWFL OM is pegged along with this OM.
ECSVRASU
ESBESWFL
ECSESWFL
Ebsc CSvs Error SoftWare FaiLure. This OM is pegged for all call failures during the call setup phase (i.e communication between CAU and the Selector Element on the DSFP-V). These failures include CAU time-outs, resource mismatches, software failures on the Selector Element. The CAUESWFL OM is pegged along with this OM.
ESBNRSFL
Ebsc SBs Non Rf Setup FaiLure. This OM is pegged for call setup failures due to non-RF related failures on SBS. The failure reasons for this OM pegging are same as the NORFSEFL/ NRFSEFHH OM failure reasons. The NORFSEFL or the NRFSEFHH will be pegged along with this OM.
sheet 161 of 225
CDMA
NBSS15.0
21-162 MSC OM descriptions Nortel Networks MSC operational measurements Register ECSNRSFL Description
Ebsc CSvs Non Rf Setup FaiLure. This OM is pegged for call setup failures due to non-RF related on CSVS. The failure reasons for this OM pegging are same as the NORFSEFL/ NRFSEFHH OM failure reasons. The NORFSEFL or the NRFSEFHH will be pegged along with this OM.
ESBERLFL
Ebsc SBs Error Radio Link FaiLure. This OM is pegged for call setup failures due to RF related failures after successful resource allocation on SBS. The failure reasons for this OM pegging are same as the CAUERLFL/CAUHRLFL OM failure reasons. The CAUERLFL or the CAUHRLFL will be pegged along with this OM.
ECSERLFL
Ebsc CSvs Error Radio Link FaiLure. This OM is pegged for call setup failures due to RF related failures after successful resource allocation on CSVS. The failure reasons for this OM pegging are same as the CAUERLFL/CAUHRLFL OM failure reasons. The CAUERLFL or the CAUHRLFL will be pegged along with this OM.
ESBDROPR
Ebsc SBs DROP due to Rf failures. This OM is pegged for call drops due to RF related failures after successful call setup on SBS. The failure reasons for this OM pegging are same as the CAUDROPR failure reasons. The CAUDROPR OM is pegged along with this OM.
ECSDROPR
Ebsc CSvs DROP due to Rf failures. This OM is pegged for call drops due to RF related failures after successful call setup on the CSVS. The failure reasons for this OM pegging are same as the CAUDROPR failure reasons. The CAUDROPR OM is pegged along with this OM.
sheet 162 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register ESBSCSS Description
Ebsc SBS Call Setup Success. This OM is pegged for successful call setup on the SBS subsystem. This OM is pegged when the resource is setup on the SBS and CAU receives a successful service connect response. The existing CAU$SUCC OM is pegged along with this OM. ($=O,T,H).
ECSVCSS
Ebsc CSVs Call Setup Success. This OM is pegged for successful call setup on the CSVS subsystem. This OM is pegged when the resource is setup on the CSVS and CAU receives a successful service connect response. The existing CAU$SUCC OM is pegged along with this OM. ($=O,T,H).
sheet 163 of 225
CDMA
NBSS15.0
21-164 MSC OM descriptions Nortel Networks MSC operational measurements Register LCSSYS OM group Description
Reference chapter Location services performance (page 13-1) Location services performance (page 13-1)
LoCation Services SYStem. This OMs in this group are related to LCS or E911 position determination services and pegged by CM per system level. LoCation services PaGing for CURrent Information. This OM is pegged when the receipt of LCS related ISPOSREQ message from MPC (Mobile Positioning Center) results in attempting to page an idle mobile to obtain current cell/sector/OWD (One Way Delay) for coarse positioning. Note: Existing Paging OMs for SMS in CAUDATSC and CAUDATSY group are not pegged for this case. If zone based paging is enabled, paging related OMs in SMSZONPG OM group are also pegged for this case.
0
LCPG4CUR Added in 12.0 release
LCQACTMB Added in 12.0 release MV2TCHAT Added in 12.0 release
LoCation services Query for ACTive MoBile. This OM is pegged when the receipt of an LCS related ISPOSREQ message from MPC or ISPOSREQFWD message from Anchor MSC resulted in querying the BSC to obtain current cell/sector/OWD for an active (i.e., in call) mobile for coarse positioning. MoVe to Traffic CHannel ATtempt. This OM is pegged when the receipt of LCS related ISPOSREQ message from MPC with ACTCODE (indicating Prepare for CDMA Handset-Based Position Determination) results in an attempt by the serving MSC to move the designated idle mobile to a traffic channel allocated against SO-35. Pegging of this OM indicates that a page request is being sent to the mobile. Note: Existing Paging OMs for SMS in CAUDATSC and CAUDATSY group are not pegged for this case. If zone based paging is enabled, paging related OMs in SMSZONPG OM group are also pegged for this case.
0
Location services performance (page 13-1) Location services performance (page 13-1)
sheet 164 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MV2TCHSU Added in 12.0 release Description
Reference chapter Location services performance (page 13-1)
Move To Traffic Channel Success. This OM is pegged when the mobile is successfully moved to SO-35 TCH (Traffic CHannel) for subsequent IS-801 positioning. After traffic channel is setup, IS-801 sessions is started for exchanging data burst messages between the mobile and the MSC. Note: Existing traffic channel setup and databurst OMs for SMS in CAUDATSC and CAUDATSY group are not pegged for this case.
0
IMIPRQRR Added in 12.0 release
IMmediately sent Intersystem Position ReQuest Return Result. This OM is pegged when an ISPOSREQ message is immediately sent by the serving MSC to MPC upon receipt of an ISPOSREQ message. In this case, ISPOSREQ message may provide any available position-related info for the mobile that may be stored in the VLR, and the included Position Result parameter may indicate success or failure. Success cases include the following: E911-related ISPOSREQ message; Mobile identified in ISPOSREQ message is no longer registered in the MSC/VLR; E911-related ISPOSREQ message, but the mobile is no longer in call Failure cases include the following:
Location services performance (page 13-1)
LCSSESS Added in 12.0 release
LoCation Services SeSSion. After MSC receives an ISPOSREQ from the MPC with an ACTCODE indicating Prepare for CDMA Handset-Based Position Determination, this OM is pegged when an IS 801 session has been started by virtue of one of the following occurring: When the mobile is successfully moved to the traffic channel with SO-35 to exchange IS-801 Data bursts for precise location. When a mobile is already on a traffic channel for some other service and it is possible to exchange IS-801 Data bursts for precise location.
sheet 165 of 225
CDMA
NBSS15.0
21-166 MSC OM descriptions Nortel Networks MSC operational measurements Register E911SESS Added in 12.0 release Description
E911 SESSion. This OM is pegged when the Serving MSC starts an IS-801 session upon receipt of the first SMDPP (SMS Delivery Point to Point INVOKE) message from PDE for a mobile that is in call but for which an ISPOSREQ message was not previously received from MPC with ACTCODE indicating Prepare for CDMA Handset Based Position Determination. This can occur for an E911-related session or LCS-related session after intersystem handoff forward has occurred. PRECise ReQueST. This OM is pegged when ISPOSREQ message is received by MSC from MPC with an ACTCODE indicating Prepare for CDMA Handset Based Position Determination for the mobiles precise location. This OM provides information on how many precise location requests received from the MPC, but out of all those requests, a subset of requests may require setting up the Traffic channel for IS-801 session as in some instances mobiles may be already in the call. LoCation service ForWarD link Data Burst. This OM is pegged when forward link data burst message which carry IS-801 bearer data is sent by the Serving MSC to the mobile. LoCation Service ForWarD link Data Burst eXtension. This OM register is the extension of LCFWDDB.
PRECRQST Added in 12.0 release
LCFWDDB Added in 12.0 release LCFWDDBX Added in 12.0 release LCREVDB Added in 12.0 release LCREVDBX Added in 12.0 release
Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1)
LoCation service REVerse link Data Burst. This OM is pegged when reverse link data burst message which carry IS-801 bearer data is received by the Serving MSC. LoCation service REVerse link Data Burst eXtension. This OM register is the extension of LCREVDB.
sheet 166 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register LCOREQIV Added in 12.0 release Description
LoCation services Origination REQuest InVoke. This OM is pegged when ORREQ message related to mobile position determination for E911 Phase 2 or LCS is triggered. The trigger may be the mobile placing an E911 call or dialing digits related to Location Based Services. In either case, the MSC sends the INVOKE message to SCP (Service Control Point) to initiate Location Services. This corresponds to number of attempted mobile initiated position requests. SMDPP/smdpp POSition determination InComing. This OM is pegged when a SMDPP/smdpp (SMS Delivery Point to Point INVOKE or RETURN RESULT) message sent from PDE (Position Determination Entity) is received by the MSC which is related to CDMA position determination service. SMDPP/smdpp PoSition determination InComing eXtension. This OM register is the extension of SMDPOSIC.
SMDPOSIC Added in 12.0 release SMDPSICX Added in 12.0 release SMDPOSOG Added in 12.0 release SMDPSOGX Added in 12.0 release LCSSESSX Added in 14.0 release MV2TCHTX Added in 14.0 release PRECRQSX Added in 14.0 release
Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1)
SMDPP/smdpp POSition determination OutGoing. This OM is pegged when SMDPP/smdpp message is sent by the MSC to PDE which is related to CDMA position determination service. SMDPP/smdpp PoSition determination OutGoing eXtension. This OM register is the extension of SMDPOSOG.
LoCation Services SESSion eXtension. Extension register added for LCSSESSX.
MoVe 2 Traffic CHannel aTtempt eXtension. Extension register added for MV2TCHTX.
PRECise ReQueSt eXtension. Extension register added for PRECRQSX.
sheet 167 of 225
CDMA
NBSS15.0
21-168 MSC OM descriptions Nortel Networks MSC operational measurements Register MTXIHO OM group Modified OM group in Release 15 IHO2GATT Description
Reference chapter Handoff performance (page 7-1)
MTX Intersystem HandOff. This OM group evaluates the performance of Intersystem Hard HandOff (IHHO) on the target MSC (MTX). These OMs are introduced to measure IHHO attempts, successes, blocks, failures and releases for 2G, 3G voice and 3G data calls respectively. The OMs are pegged at the CM on a per-sector basis. Inter-system hard HandOff 2G ATTempt. This OM is pegged when an inter-system 2G hard handoff attempt in a (CDMA) target sector is being requested. The OM is pegged upon receipt of the FACDIR2 message. In the case of Multi Pilot Hard Handoff (MPHHO), the IHO2GATT OM is pegged against the first target sector in the target list.
Handoff performance (page 7-1)
IHO2GSUC
Inter-system hard HandOff 2G SUCcess. This OM is pegged when a mobile, attempting an inter-system hard handoff, successfully arrives on the 2G traffic channel on the target sector. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO2GSUC OM to peg against a different sector than the IHO2GATT OM. While the IHO2GATT OM is always pegged against the first target sector in the target list, the IHO2GSUC OM is pegged against the first target sector in the target list in which resources are setup successfully. Note: If a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GSUC OM will be pegged for a handoff success even though the attempt was pegged against the IHO3VATT OM.
sheet 168 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IHO2GFAL Description
Inter-system hard HandOff 2G FAiLure. This OM is pegged when an inter-system hard handoff attempt fails because the mobile never arrived on the target sectors 2G traffic channel allocated. IHO2GFAL is not pegged in cases where IHO2GBLK is pegged. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO2GFAL OM to peg against a different sector than the IHO2GATT OM. While the IHO2GATT OM is always pegged against the first target sector in the target list, the IHO2GFAL OM is pegged against the first target sector in the target list in which resources are setup successfully. Note: If a handoff failure occurs after a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GFAL OM will be pegged even though the attempt was pegged against the IHO3VATT OM.
0
IHO2GBLK
Inter-system hard HandOff 2G BLocK. This OM is pegged against the target sector when an inter-system 2G hard handoff setup fails due to a resource shortage in the target system.
0
In the case of Multi Pilot Hard Handoff (MPHHO), the IHO2GBLK OM is pegged against the first target sector in the target list.
sheet 169 of 225
CDMA
NBSS15.0
21-170 MSC OM descriptions Nortel Networks MSC operational measurements Register IHO2GREL Description
Inter-system hard HandOff 2G RELeased. This OM is pegged when the inter-system 2G hard handoff setup in a target cell is released by the source system before the mobile arrives on the traffic channel. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO2GREL OM to peg against a different sector than the IHO2GATT OM. While the IHO2GATT OM is always pegged against the first target sector in the target list, the IHO2GREL OM is pegged against the first target sector in the target list in which resources are setup successfully. The IHO2GREL OM will peg against the first target sector if the release takes place prior to resource setup. Note: If a release occurs after a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GREL OM will be pegged even though the attempt was pegged against the IHO3VATT OM.
0
IHO2GINT
Inter-system hard HandOff 2G Initiated. This OM is pegged against the first target sector in the target list in which 2G voice resources are setup successfully for a hard handoff attempt. Note that for any given hard handoff attempt, the IHO2GSUC OM or IHO2GFAL OM will get pegged against the same sector as the IHO2GINT OM, but the IHO2GATT OM could be pegged against a different sector in the cases when the first sector in the target list does not have resources available. Note: If a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GINT OM will be pegged even though the attempt was pegged against the IHO3VATT OM.
IHO3VATT
Inter-system hard HandOff 3g Voice ATTempt. This OM is pegged when an inter-system 3G voice hard handoff attempt in a (CDMA) target sector is being requested. The OM is pegged upon receipt of the FACDIR2 message. In the case of Multi Pilot Hard Handoff (MPHHO), the IHO3VATT OM is pegged against the first target sector in the target list.
sheet 170 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IHO3VSUC Description
Inter-system hard HandOff 3g Voice SUCcess. This OM is pegged when the mobile, attempting an inter-system voice hard handoff, successfully arrives on the 3G traffic channel on the target sector. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO3VSUC OM to peg against a different sector than the IHO3VATT OM. While the IHO3VATT OM is always pegged against the first target sector in the target list, the IHO3VSUC OM is pegged against the first target sector in the target list in which resources are setup successfully. Note: If a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GSUC OM will be pegged for a handoff success even though the attempt was pegged against the IHO3VATT OM.
0
IHO3VFAL
Inter-system hard HandOff 3g Voice FAiLure. This OM is pegged when the inter-system voice hard handoff attempt fails because the mobile never arrives on the target sectors 3G traffic channel allocated. IHO3VFAL is not pegged in cases where IHO3VBLK is pegged. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO3VFAL OM to peg against a different sector than the IHO3VATT OM. While the IHO3VATT OM is always pegged against the first target sector in the target list, the IHO3VFAL OM is pegged against the first target sector in the target list in which resources are setup successfully. Note: If a handoff failure occurs after a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GFAL OM will be pegged even though the attempt was pegged against the IHO3VATT OM.
sheet 171 of 225
CDMA
NBSS15.0
21-172 MSC OM descriptions Nortel Networks MSC operational measurements Register IHO3VBLK Description
Inter-system hard HandOff 3g Voice BLocK. This OM is pegged against target sector when the inter-system 3G voice hard handoff setup fails due to a resource shortage in the target system. In the case of Multi Pilot Hard Handoff (MPHHO), the IHO3VBLK OM is pegged against the first target sector in the target list.
IHO3VREL
Inter-system hard HandOff 3g Voice RELeased. This OM is pegged when the inter-system 3G voice hard handoff setup in a target cell is released by the source system before the mobile arrives on the traffic channel. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO3VREL OM to peg against a different sector than the IHO3VATT OM. While the IHO3VATT OM is always pegged against the first target sector in the target list, the IHO3VREL OM is pegged against the first target sector in the target list in which resources are setup successfully. The IHO3VREL OM will peg against the first target sector if the release takes place prior to resource setup. Note: If a release occurs after a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GREL OM will be pegged even though the attempt was pegged against the IHO3VATT OM.
IHO3VINT
Inter-system hard HandOff 3g Voice Initiated. This OM is pegged against the first target sector in the target list in which 3G voice resources are setup successfully for a hard handoff attempt. Note that for any given hard handoff attempt, the IHO3VSUC OM or IHO3VFAL OM will get pegged against the same sector as the IHO3VINT OM, but the IHO3VATT OM could be pegged against a different sector in the cases when the first sector in the target list does not have resources available. Note: If a 3G to 2G BTS downgrade took place in the target sector, then the IHO2GINT OM will be pegged for even though the attempt was pegged against the IHO3VATT OM.
sheet 172 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IHO3DATT Description
Inter-system hard HandOff 3g packet Data ATTempt. This OM is pegged when an inter-system 3G packet datacall hard handoff attempt in a (CDMA) target sector is being requested. The OM is pegged upon receipt of the FACDIR2 message. In the case of Multi Pilot Hard Handoff (MPHHO), the IHO3DATT OM is pegged against the first target sector in the target list.
IHO3DSUC
Inter-system hard HandOff 3g packet Data SUCcess. This OM is pegged when the mobile, attempting an inter-system 3G packet datacall hard handoff, successfully arrives on the traffic channel on the target sector. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO3DSUC OM to peg against a different sector than the IHO3DATT OM. While the IHO3DATT OM is always pegged against the first target sector in the target list, the IHO3DSUC OM is pegged against the first target sector in the target list in which resources are setup successfully.
IHO3DFAL
Inter-system hard HandOff 3g packet Data FAiLure. This OM is pegged when the inter-system 3G packet datacall hard handoff attempt fails because the mobile never arrive on the target sectors traffic channel allocated. IHO3VFAL is not pegged in cases where IHO3VBLK is pegged. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO3DFAL OM to peg against a different sector than the IHO3DATT OM. While the IHO3DATT OM is always pegged against the first target sector in the target list, the IHO3DFAL OM is pegged against the first target sector in the target list in which resources are setup successfully.
IHO3DBLK
Inter-system hard HandOff 3g packet Data BLocK. This OM is pegged against target sector when the inter-system 3G packet datacall hard handoff setup fails due to a resource shortage in the target system (including R-P session setup failure). In the case of Multi Pilot Hard Handoff (MPHHO), the IHO3DBLK OM is pegged against the first target sector in the target list.
sheet 173 of 225
CDMA
NBSS15.0
21-174 MSC OM descriptions Nortel Networks MSC operational measurements Register IHO3DREL Description
Inter-system hard HandOff 3g packet Data RELeased. This OM is pegged when the inter-system 3G packet datacall hard handoff setup in a target cell is released by the source system before the mobile arrives on the traffic channel. In the case of Multi Pilot Hard Handoff (MPHHO), the potential exists for the IHO3DREL OM to peg against a different sector than the IHO3DATT OM. While the IHO3DATT OM is always pegged against the first target sector in the target list, the IHO3DREL OM is pegged against the first target sector in the target list in which resources are setup successfully. The IHO3DREL OM will peg against the first target sector if the release takes place prior to resource setup.
IHO3DINT
Inter-system hard HandOff 3g packet Data Initiated. This OM is pegged against the first target sector in the target list in which 3G packet datacall resources are setup successfully for a hard handoff attempt. Note that for any given hard handoff attempt, the IHO3DSUC OM or IHO3DFAL OM will get pegged against the same sector as the IHO3DINT OM, but the IHO3DATT OM could be pegged against a different sector in the cases when the first sector in the target list does not have resources available. Inter system hard HandOff Service Option CHanGe. This OM is pegged at the target CM if the service option that the target CM has sent in the ReadyNewCell message is different than the service option that it received in the NewCellReady message. The NewCellReady message will be sent by the CAU after the resources are successfully setup. In case of Multi-Pilot Hard handoff (MPHHO) this OM is pegged against the target sector in which the 3G Voice call resource is successfully setup for a hard handoff attempt.
IHOSOCHG
IHOSRSUC
Inter system hard HandOff Service Redirection SUCcessful. This OM is pegged at the target CM if, after the CM detects a successful service option change, the mobile successfully arrives on the target sectors traffic channel. In case of Multi-Pilot Hard handoff (MPHHO) this OM is pegged against the target sector in which the 3G Voice call resource is successfully setup for a hard handoff attempt.
sheet 174 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MTXPDSCT OM group New OM group in 14.0 release Description
MTX Packet Data SeCtor based. The OMs are pegged at the CM on a per-sector basis.
NWKFLBS
NetWork rp session FaiLure Before Service connect completion. This OM pegs RP session setup failures for packet data calls before service connect completion. It is pegged during Null to Active, Dormant to Active transition as well as Active Handoff. NetWork rp session FaiLure After Service connect completion. This OM pegs RP session setup failures for packet data calls after service connect completion. It is pegged during Null to Active, Dormant to Active transition as well as Active Handoff. Null-to-Active RLP setup FaiLure. This OM pegs RLP failures for packet data calls during Null to Active transition. Dormant-to-Active RLP setup FaiLure. This OM pegs RLP failures for packet data calls during Dormant to Active transition. Active Handoff RLP setup FaiLure. This OM pegs RLP failures for packet data calls during active handoff.
sheet 175 of 225
Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1) Call setup performance (page 2-1)
NWKFLAS
NARLPFL
DARLPFL
AHRLPFL
CDMA
NBSS15.0
21-176 MSC OM descriptions Nortel Networks MSC operational measurements Register MTXPDSYS OM group New OM group in 14.0 release NARPFLBS Description
MTX Packet Data System based. This OM group is pegged at CM per system basis.
Null-to-Active RP session setup FaiLure Before Service connect completion. This OM pegs RP session setup failures for packet data calls before service connect completion. It is pegged during packet data session Null to Active transition. When this OM is pegged, NWKFLBS and PDSEFLBS are also pegged. Dormant-to-Active RP session setup FaiLure Before Service connect completion. This OM pegs RP session setup failures for packet data calls before service connect completion. It is pegged during packet data session Dormant to Active transition. When this OM is pegged, NWKFLBS is also pegged. Active Handoff RP session setup FaiLure Before Service connect completion. This OM pegs RP session setup failures for packet data calls before service connect completion. It is pegged during packet data session Active Handoff. When this OM is pegged, NWKFLBS is also pegged. Null-to-Active RP session setup FaiLure After Service connect completion. This OM pegs RP session setup failures for packet data calls after service connect completion. It is pegged during packet data session Null to Active transition.When this OM is pegged, NWKFLAS and PDSEFLAS are also pegged. Dormant-to-Active RP session setup FaiLure After Service connect completion. This OM pegs RP session setup failures for packet data calls after service connect completion. It is pegged during packet data session Dormant to Active transition. When this OM is pegged, NWKFLAS is also pegged. Active Handoff RP session setup FaiLure After Service connect completion. This OM pegs RP session setup failures for packet data calls after service connect completion. It is pegged during packet data session Active Handoff.When this OM is pegged, NWKFLAS is also pegged.
sheet 176 of 225
DARPFLBS
AHRPFLBS
NARPFLAS
DARPFLAS
AHRPFLAS
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register DHORPFL Description
Dormant HandOff RP session setup FaiLure. This OM pegs RP session setup failures for packet data calls during Dormant Handoff. In case of multiple RP session setup tries for dormant handoff, this OM is pegged after all tries have failed.
sheet 177 of 225
CDMA
NBSS15.0
21-178 MSC OM descriptions Nortel Networks MSC operational measurements Register MTXSYS1 OM group Modified OM group in 13.0 release Description
Reference chapter Call setup performance (page 2-1) Intelligent voice service negotiations performance (page 8-1) Paging performance (page 10-1)
MTX SYStem 1. This OM group is pegged per System-wide basis.
RPGAMPS
RePaGe AMPS. This OM is pegged on the CM when, after paging the mobile in the CDMA cells, an attempt is made to page the mobile in the AMPS cells under the MTXs control. AMPS RESPonse. This OM is only pegged when an AMPS repage (as counted by RPGAMPS) results in a page response from one of the AMPS sectors AMPS Time-Out. This OM is pegged when the repage of the AMPS cells (as counted by RPGAMPS) does not result in a page response. CDma PaGe 1st REQuest. This OM is pegged when the first page is sent to a mobile, regardless of system-wide or zone paging method used. This OM is pegged regardless of system-wide or zone paging method used and is combined for Voice, CSD and Packet Data call terminations. CDma PaGe 2nd REQuest. This OM is pegged when the second page is sent to a mobile if the system times out waiting for the first page response, This OM is pegged regardless of system-wide or zone paging method used and is combined for Voice, CSD and Packet Data call terminations.
sheet 178 of 225
AMPSRESP
AMPSTO
CDPG1REQ Renamed in 13.0 release from CDMAPREQ CDPG2REQ New OM in 13.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CDPG3REQ New OM in 13.0 release Description
Reference chapter
CDma PaGe 3rd REQuest. This OM is pegged when the third page is sent to a mobile if the system times out waiting for the second page response, This OM is pegged regardless of system-wide or zone paging method used and is combined for Voice, CSD and Packet Data call terminations.
CDPG1RES Renamed in 13.0 release from CDMAPRS1
CDma PaGe 1st RESponse. This OM is pegged when a page response is received for the first page request. This OM is pegged combined for Voice, CSD and Packet Data call terminations. Note: When Border Cell Paging is activated, and the page response is received in a Border system, this OM is not pegged in the Anchor system.
CDPG2RES Renamed in 13.0 release from CDMAPRS2
CDma PaGe 2nd RESponse. This OM is pegged when a page response is received for the second page request. This OM is pegged combined for Voice, CSD and Packet Data call terminations. Note: When Border Cell Paging is activated, and the page response is received in a Border system, this OM is not pegged in the Anchor system.
0
CDPG3RES New OM in 13.0 release
CDma PaGe 3rd RESponse. This OM is pegged when a page response is received for the third page request. This OM is pegged combined for Voice, CSD and Packet Data call terminations. Note: When Border Cell Paging is activated, and the page response is received in a Border system, this OM is not pegged in the Anchor system.
sheet 179 of 225
CDMA
NBSS15.0
21-180 MSC OM descriptions Nortel Networks MSC operational measurements Register TDENYCM Description
Reference chapter Chapter 2, Call setup performance Chapter 8, Intelligent voice service negotiations performance
call Termination DENY by CM. This OM is pegged during mobile terminations when there is a mismatch between the mobile's voice service capability stored in the VLR and CDMA_PAGE_WITH_MS_CAP_INFO tuple in the table OFCVAR. This register is pegged on a system wide basis. In this case, the page request message is not sent to the mobile.
CDMASYPG
CDMA SYstem wide PaGe. This OM is pegged in the Border system when paging was performed in the Border system for incoming page request sent by the Anchor System. The Anchor system is where call termination first arrived and with border cell paging is activated, the anchor system sends page request to the Border system. CDPG1REQ, CDPG2REQ and CDPG3REQ OMs are not pegged in the Border system for all incoming border page requests. This OM only applies to border cell paging. This OM is not pegged when BORANCPG OM (OMMTX3 OM group) is pegged in Border system. Pilot Strength Measurement Message ATtempT. This OM is pegged every time MSC sends a PSMM Request Message to BSC during 911 call as part of Enhance Forward Link Trilateration (EFLT) feature. Pilot Strength Measurement Message SUCCess. This OM register is pegged every time the MSC gets the PSMM response from the BSC with the PSMM information and sends the ISPOSREQ RETURN RESULT to the PDE with the PSMM information. Pilot Strength Measurement Message FA I Lure. This OM register is pegged if the MSC does not get the PSMM response from the BSC before the timer expires or if the PSMM response received from the BSC lacks the PSMM information. In this case, MSC sends a default ISPOSREQ RETURN RESULT to the PDE indicating a timeout. The value of this timer can be datafilled using the office parameter MTX_PSMM_TIMEOUT in table OFCVAR.
sheet 180 of 225
PSMMATT Added in 12.0 release PSMMSUCC Added in 12.0 release PSMMFAIL Added in 12.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MTXSYS2 OM group Modified in 14.0 release GECRCVD New OM in 13.0 release GECATTS New OM in 13.0 release Description
Reference chapter Chapter 2, Call setup performance
MTX SYStem 2. The OMs in this group are pegged on a persystem basis.
Global Emergency Calls ReCeiVeD. This register counts the number of times the CM receives an Origination or Flash with Information message in which GEC is indicated. This register can be used to track the penetration of GEC in the office. Global Emergency Call ATTemptS. This register counts the number of times the CM receives an Origination or Flash message in which GEC is indicated and the MTX_GLOBAL_EMERGENCY_DIGITS office variable contains digits. When GECRCVD is greater than zero and GECATTS is zero, this indicates that the MTX_GLOBAL_EMERGENCY_DIGITS office variable contains no digits. Global Emergency Call SUCCess. The CM pegs this register each time a Global Emergency Call is answered. When GECATTS is greater than zero and GECSUCC is zero, this indicates that Global Emergency Calls are not being answered. This could be due to a number of reasons, for example, the emergency services number is incorrectly datafilled in MTX_GLOBAL_EMERGENCY_DIGITS or the call is not being connected after being routed to the PSTN. MEIDATTempts. This OM tracks the number of times CM receives an Origination, Page Response or a Hard Handoff message from an MEID mobile. The existing CAU$ATT OM is pegged along with this OM based on the call type.
Chapter 2, Call setup performance Chapter 2, Call setup performance
GECSUCC New OM in 13.0 release
Chapter 2, Call setup performance
MEIDATTS New OM in 14.0 release
ESNATTS New OM in 14.0 release
ESNATTempts. This OM tracks the number of times CM receives an Origination, Page Response or a Hard Handoff message from an ESN mobile. The existing CAU$ATT OM is pegged along with this OM based on the call type.
sheet 181 of 225
CDMA
NBSS15.0
21-182 MSC OM descriptions Nortel Networks MSC operational measurements Register MEIDQRCC New OM in 14.0 release MEIDQSCC New OM in 14.0 release MEIDQRTC New OM in 14.0 release MEIDQSTC New OM in 14.0 release Description
Reference chapter Chapter 2, Call setup performance
MEIDQueRyCommonChannel. This OM is pegged during registration when CM sends a status request message to retrieve the MEID value of the mobile on the common channel (PCH or F-CCCH). The status request message is sent if the VLR entry does not contain the MEID value of the mobile. MEIDQuerySuccessCommonChannel. This OM is pegged during registration when CM recieves a status response message containing the MEID value of the mobile, on the common channel (ACH or R-EACH). MEIDQueRyTrafficChannel. This OM is pegged after successful call setup when CM sends a status request message on the traffic channel to retrieve the MEID value of the mobile. The status request message is sent if the VLR entry does not contain the MEID value of the mobile. MEIDQuerySuccessTrafficChannel. This OM is pegged after successful call setup when CM receives a status response message containing the MEID value of the mobile, on the traffic channel.
sheet 182 of 225
Chapter 2, Call setup performance Chapter 2, Call setup performance
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register MTXSYSX OM group Modified OM group in 13.0 release RPGAMPS2 Description
MTX SYStem eXtension. This OM group is pegged per Systemwide basis and provides extension registers for some of the OMs in MTXSYS1 and MTXSYS2 OM groups.
RePaGe AMPS 2. This OM is an extension register for RPGAMPS OM in MTXSYS1 OM group. AMPS ReSPonse 2. This OM is an extension register for AMPSRESP OM in MTXSYS1 OM group. AMPS Time-Out 2. This OM is an extension register for AMPSTO OM in MTXSYS1 OM group. CDma Page 1st REQuest eXtension. This OM is an extension register for CDPG1REQ OM in MTXSYS1 OM group.
AMPSRSP2
AMPSTO2
CDP1REQX Renamed in 13.0 release from CDMAPRQ2 CDP2REQX New OM in 13.0 release CDP3REQX New OM in 13.0 release CDP1RESX Renamed in 13.0 release from CDMAPR12
CDma Page 2nd REQuest eXtension. This OM is an extension register for CDPG2REQ OM in MTXSYS1 OM group.
CDma Page 3rd REQuest eXtension. This OM is an extension register for CDPG3REQ OM in MTXSYS1 OM group.
CDma Page 1st RESponse eXtension. This OM is an extension register for CDPG1RES OM in MTXSYS1 OM group.
sheet 183 of 225
CDMA
NBSS15.0
21-184 MSC OM descriptions Nortel Networks MSC operational measurements Register CDP2RESX Renamed in 13.0 release from CDMAPR22 CDP3RESX New OM in 13.0 release
sheet 184 of 225
Description CDma Page 2nd RESponse eXtension. This OM is an extension register for CDPG2RES OM in MTXSYS1 OM group.
Reference chapter
CDma Page 3rd RESponse eXtension. This OM is an extension register for CDPG3RES OM in MTXSYS1 OM group.
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register NWKIC2 OM group Modified OM group in 13.0 release Description
Reference chapter
NetWorK InComing messages 2. This OM group is pegged per System basis. These OMs only apply to Border Cell Paging and they track the count of various incoming intersystem messages (i.e. incoming from the network) on a per intersystem route basis. These OMs are pegged combined for Voice and Packet Data call terminations. The following OMs are removed from this OM group in 13.0 release: IPG2RRRT.
sheet 185 of 225
CDMA
NBSS15.0
21-186 MSC OM descriptions Nortel Networks MSC operational measurements Register IPG2RRIC Description
Reference chapter
Intersystem PaGe 2 Return Result InComing. This OM is pegged at the Anchor System when a valid ispage2 return result message is received from the Border System. At the Anchor System, configurable parameters (OUTGOING_VOICE_CIRCUIT_ISPAGE2 and OUTGOING_PACKET_DATA_ISPAGE2 in Table PAGECTRL) control if and when the Anchor system should send the ispage2 message to Border systems. Note: This OM simply counts incoming ispage2 Return Result networking messages and cannot distinguish between success and failure scenarios. Some events that cause the Border system to send ispage2 Return Result message are: The page response is received in Border System. The mobile is Busy in the Border system. Busy, means if the Border System has already received an origination message from the mobile, or is already in a call on the border MSC. Please note that in this case, Intersystem Setup Invoke is not sent to the border system. If the CDMA border cell SOC (Software Optionality Control) is IDLE on the border MSC and this is a CDMA border cell call. Please note that in this case, Intersystem Setup Invoke is not sent to the border system.
Notes for Anchor System: When Border System sends the ispage2 return result message (with page response) to the Anchor System, the Anchor System will not peg page response OMs (in CDMAPAGE and MTXSYS1 OM groups), page timeout OMs (in CDMAPAGE OM group) and the IZP zone based page response OMs (in CDMAPGZN OM group). If the ispage2 return result message indicates that the mobile is busy, the page timeout is still cancelled and the IZP zone based page timeout OMs (in CDMAPGZN OM group) will not be pegged as long as an ispage2 Return Result is received.
sheet 186 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register ISETRRIC Description
Reference chapter
Intersystem SETup Return Result InComing. This OM is pegged at the Anchor System when a valid issetup return result is received by the Anchor System from the Border System. The receipt of the issetup return result indicates that the Border system has processed the ISSETUP invoke message sent from the Anchor System. Note: The issetup return result message that pegs ISETRRIC OM is just an ACK to the ISSETUP Invoke message.
0
IANSIVIC
Intersystem ANSwer InVoke Incoming. This OM is pegged at the Anchor System when a valid ISANSWER invoke message from the Border System is received by the Anchor System. The receipt of the ISANSWER invoke message indicates that the Border system is reporting a mobile answer event of a border cell termination anchored in this System. Note: When the IANSIVIC OM is pegged, the mobile user has successfully answered the call. The IANSIVIC OM will not get pegged if the Mobile did not Answer and the Border System did not send the ISANSWER invoke message. Some of the reasons why the Mobile did not answer are: it was busy, the mobile user choose not to answer, there was an Access Failure (Mobile did not arrive on the Traffic Channel), there was no resources at the Border System, there was some S/W time out. Currently the ISETIVOG OM can be considered as an Attempt to setup the traffic Channel. The IANSIVIC OM can be considered as the mobile has Successfully arrived on the traffic Channel and the user has answered the call. These OMs can be used to estimate call setup success or failure percentage.
sheet 187 of 225
CDMA
NBSS15.0
21-188 MSC OM descriptions Nortel Networks MSC operational measurements Register RELIVIC New OM in 13.0 release Description
Reference chapter
RELease InVoke InComing. This OM is pegged at the Border System when a valid RELEASE Invoke message is received by the Border System from the Anchor System. The receipt of the RELEASE Invoke message notifies the Border system to cancel all page attempts in that system related to the previously received ISPAGE2 Invoke message. Note: The OM simply counts incoming RELEASE Invoke messages at the Border system and cannot distinguish the cause of page cancellation. Some events that cause the Anchor system to send RELEASE Invoke message to the Border system are: The page response is received in Anchor system. The page response is received in another Border system and the Anchor system received an ISPAGE2 Return Result message from that Border system. The call is abandoned (call originator released the call) or dropped due to RF failure (for mobile to mobile call, originator side link failure) or in some scenarios for VPAD feature when page request is sent again due to data call origination received from the mobile.
Note: In the Anchor system, the SENDREL field in Table ADJSYS indicates whether a Border system (i.e. adjacent route) is capable of handling the RELEASE Invoke message. The Anchor system sends RELEASE Invoke message to a Border system only when SENDREL is configured as Y. When Border System receives a RELEASE Invoke message from the Anchor System, it also pegs the appropriate page released OM (i.e. IP2B1VRL, IP2B2VRL, IP2B3VRL, IP2B1DRL, IP2B2DRL or IP2B3DRL) in CDMABIPG OM group. Notes for Anchor System: When Anchor System sends a RELEASE Invoke message to the Border System, it pegs the RELIVOG OM in NWKOG2 OM group.
sheet 188 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RELRRIC New OM in 13.0 release Description
Reference chapter
RELease Return Result InComing. This OM is pegged at the Anchor System when a valid RELEASE Return Result message is received by the Anchor System from the Border System. The receipt of the RELEASE Return Result message indicates that the Border system has processed the RELEASE invoke message sent by the Anchor System to cancel paging in the Border system. Note: The RELEASE Return Result message is just an ACK to the RELEASE Invoke message. Notes for Border System: When Border System sends a RELEASE Return Result message to the Anchor System, it pegs the RELRROG OM in NWKOG2 OM group.
sheet 189 of 225
CDMA
NBSS15.0
21-190 MSC OM descriptions Nortel Networks MSC operational measurements Register NWKOG2 OM group Modified OM group in 13.0 release Description
Reference chapter
NetWorK OutGoing messages 2. This OM group is pegged per System basis. These OMs only apply to Border Cell Paging and they track the count of various outgoing intersystem messages (i.e. outgoing to the network) on a per intersystem route basis. These OMs are pegged combined for Voice and Packet Data call terminations. The following OMs are removed from this OM group in 13.0 Release: IPG2IVRT.
sheet 190 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register IPG2IVOG Description
Reference chapter
Intersystem PaGe 2 InVoke OutGoing. This OM is pegged at the Anchor System when a valid ISPAGE2 Invoke message is sent to the Border System. The sending of the ISPAGE2 invoke indicates that the anchor system is requesting paging or listening of a mobile that was last known to be near the system boundary with the Border System. At the Anchor System, configurable parameters (OUTGOING_VOICE_CIRCUIT_ISPAGE2 and OUTGOING_PACKET_DATA_ISPAGE2 in Table PAGECTRL) control if and when the Anchor system should send the ISPAGE2 Invoke message to Border systems. In addition, the ISPAGING parameter in Table ADJSYS indicates whether the ISPAGE2 Invoke message can be sent to a specific Border system (i.e. adjacent route). Note: This OM simply counts outgoing ISPAGE2 Invoke networking messages. Notes for Border System: For Border Cell Paging, when the ISPAGE2 Invoke Message from the Anchor System is received by the Border System, the CDPG1REQ, CDPG2REQ, CDPG3REQ OMs (MTXSYS1 OM group) will not be pegged and the CAUPGREQ OM (CAUCPSYS OM group) will be pegged in the Border System. For Border Cell Paging, after the Border System receives ISPAGE2 Invoke Request from the Anchor System, in the Border System the Page Request is sent from CM to CAU. In the Border System, if page response is received in the border system, CAUPGRES OM (in CAUCPSCT, CAUSCT3V and/or CAUSCT3D OM group depending on Table CDMAPART.OM3G value and call type) will be pegged. CDPG1RES, CDPG2RES, CDPG3RES OMs (MTXSYS1 OM group) will not be pegged.
In the Border system, if BCP zone paging method is configured for intersystem page requests, then BCP zone based OMs (CDMAPGZN group) will be pegged for the intersystem pages. However, IZP zone based OMs (CDMAPGZN group) will never be pegged for the intersystem pages.
sheet 191 of 225
CDMA
NBSS15.0
21-192 MSC OM descriptions Nortel Networks MSC operational measurements Register ISETIVOG Description
Reference chapter
Intersystem SETup InVoke OutGoing. This OM is pegged at the Anchor System when a valid ISSETUP Invoke message is sent by the Anchor System to Border System. The sending of the ISSETUP Invoke message indicates that the Anchor System is requesting the Border System to setup resources for the mobile that has responded to a page request in the Border system. Notes for the Border System: For Border Cell Paging, during call setup in the Border system after getting a page response back from the mobile and receiving the ISSETUP Invoke message, call termination OMs in the CAUCPSCT, CAUSCT3V and CAUCPSYS OM groups will be pegged in the Border System.
IANSRROG
Intersystem ANSwer Return Result Outgoing. This OM is Pegged at the Anchor System when a valid isanswer return result is sent by the Anchor System to the Border System. The sending of the isanswer return result indicates that the Anchor System has processed an ISANSWER Invoke Message received from the Border system. Note: If the IANSRROG OM is pegged it indicates that Anchor System has acknowledged receipt of the ISANSWER message from the Border System.
sheet 192 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register RELIVOG New OM in 13.0 release Description
Reference chapter
RELease InVoke OutGoing. This OM is pegged at the Anchor System when a RELEASE Invoke message is sent by the Anchor System to the Border System. The RELEASE Invoke message notifies the Border system to cancel all page attempts in that system related to the ISPAGE2 Invoke message previously sent by the Anchor System. Note: The OM simply counts incoming RELEASE Invoke messages at the Anchor system and cannot distinguish the cause of page cancellation. Some events that cause the Anchor system to send RELEASE Invoke message to the Border system are: The page response is received in Anchor system. The page response is received in another Border system and the Anchor system received an ISPAGE2 Return Result message from that Border system. The call is abandoned (call originator released the call) or dropped due to RF failure (for mobile to mobile call, originator side link failure) or in some scenarios for VPAD feature when page request is sent again due to data call origination received from the mobile.
Note: In the Anchor system, the SENDREL field in Table ADJSYS indicates whether a Border system (i.e. adjacent route) is capable of handling the RELEASE Invoke message. The Anchor system sends RELEASE Invoke message to a Border system only when SENDREL is configured as Y. Notes for Border System: When Border System receives a RELEASE Invoke message from the Anchor System, it pegs the RELIVIC OM in NWKIC2 OM group. The Border system also pegs the appropriate page released OM (i.e. IP2B1VRL, IP2B2VRL, IP2B3VRL, IP2B1DRL, IP2B2DRL or IP2B3DRL) in CDMABIPG OM group.
sheet 193 of 225
CDMA
NBSS15.0
21-194 MSC OM descriptions Nortel Networks MSC operational measurements Register RELRROG New OM in 13.0 release Description
Reference chapter
RELease Return Result OutGoing. This OM is pegged at the Border System when a RELEASE Return Result message is sent to the Anchor System by the Border System. The sending of the RELEASE Return Result message indicates that the Border system has processed the RELEASE invoke message sent by the Anchor System to cancel paging in the Border system. Note: The RELEASE Return Result message is just an ACK to the RELEASE Invoke message. Note: When Anchor System receives a RELEASE Return Result message from the Border System, it pegs the RELRRIC OM in NWKIC2 OM group.
sheet 194 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register NWKIC3 OM group Description
Reference chapter Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1)
NetWorK InComing messages 3. This OM group is pegged by CM per each route in table SYSCON.
LPRQIVIC Added in 12.0 release IPRQIVIC
LPREQ InVoke InComing. This OM is pegged when LPREQ message is received by HLR for which the Home MPC needed serving network routing information. ISPOSREQ InVoke InComing. This OM is pegged when an ISPOSREQ message from MPC for MSs position information is received by the MSC. This request can be for coarse or precise location of the mobile. ISPOSREQ Return Result InComing. This register is pegged when an ISPOSREQ message is received by the Serving MSC from Serving MPC in response to an ISPOSREQ message sent from the MSC to MPC. This can happen after an inter-system hard handoff (ISHHO). ISPOSREQFWD InVoke InComing. This OM is pegged when an ISPOSREQFWD message from Anchor MSC is received by the tandem or Serving MSC after an inter-system hard handoff scenario. ISPOSREQFWD Return Result InComing. This OM is pegged when an ISPOSREQFWD message from serving MSC is received by the Anchor or Tandem MSC. After an inter-system hard handoff scenario, this message is routed to the Anchor MSC by the Serving MSC. Origination REQuest InVoke InComing. This OM is pegged when an ORREQ message is received by the HLR for a mobile during an origination. Only a subset of this OM value is related to E-911 or LCS positioning. Origination REQuest Return Result InComing. This OM is pegged when an orreq message is received by the HLR or the Anchor MSC or Serving in response to an ORREQ.
IPRQRRIC
IPRFIVIC
IPRFRRIC
OREQIVIC
OREQRRIC
sheet 195 of 225
CDMA
NBSS15.0
21-196 MSC OM descriptions Nortel Networks MSC operational measurements Register ISSMIVIC New OM in 14.0 release ISSMRRIC New OM in 14.0 release Description
Reference chapter Border paging performance (page 11-1) Border paging performance (page 11-1)
ISSMdpp InVoke InComing. This register counts the number of incoming ISSMDPP INVOKE messages received by the Border MSC from the Anchor MSC. ISSMdpp Return Result InComing. This register counts the number of issmdpp RETURN RESULT messages received from a Border MSC in response to a ISSMDPP INVOKE message sent from the Anchor MSC.
sheet 196 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register NWKOG3 OM group Description
Reference chapter Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Location services performance (page 13-1) Border paging performance (page 11-1)
NetWorK OutGoing messages 3. This OM group is pegged by CM per each route in table SYSCON.
LPRQRROG Added in 12.0 release IPRQIVOG
LPREQ Return Result OutGoing. This OM is pegged when LPREQ message is sent by the HLR to the Home MPC in response to MPC requesting serving network routing information. ISPOSREQ InVoke OutGoing. This OM is pegged when a ISPOSREQ message is sent by the Serving MSC toward the Serving MPC to query the mobiles position information after an intersystem hard handoff. ISPOSREQ Return Result OutGoing. This OM is pegged when an isposreq is sent by the MSC toward the MPC.
IPRQRROG
IPRFIVOG
ISPOSREQFWD InVoke OutGoing. This OM is pegged when a ISPOSREQFWD message is sent by the Anchor or Tandem MSC toward the Serving MSC to query to mobiles position after an inter-system hard handoff. ISPOSREQFWD Return Result OutGoing. This OM is pegged when a isposreqfwd message is sent by the Serving or Tandem MSC toward the Anchor MPC. Origination REQuest InVoke OutGoing. This OM is pegged when a ORREQ message is sent by the Anchor or Serving MSC or the HLR to SCP (Service Control Point) for a mobile during an origination. Only a subset of this OM value is related to E-911 or LCS positioning. Origination REQuest Return Result OutGoing. This OM is pegged when an orreq message is sent by the HLR for a mobile during an origination in response to an ORREQ received. ISSMdpp InVoke OutGoing. This register counts the number of incoming ISSMDPP INVOKE messages sent from a Anchor MSC to Border MSC.
sheet 197 of 225
IPRFRROG
OREQIVOG
OREQRROG
ISSMIVOG New OM in 14.0 release
CDMA
NBSS15.0
21-198 MSC OM descriptions Nortel Networks MSC operational measurements Register ISSMRROG New OM in 14.0 release Description
ISSMdpp Return Result OutGoing. This register counts the number of issmdpp RETURN RESULT messages sent from a Border MSC in response to a ISSMDPP INVOKE message received from the Anchor MSC.
sheet 198 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register NWKIVHHO OM group New OM group in MTX13 release IVHOATTV Description
This OM group is pegged on the source CM to collect the outgoing Inter Vendor Handoff Attempts, Successes, Blocks and Failure events for 1xRTT Voice and Packet Data Calls. These OMs are only pegged when the IS880 bool value in the SYSCON table is set to Y.
InterVendor Hard handOff ATTempts for 3G Voice. This OM is pegged when the source CM receives a handoff candidate message (indicating that an outgoing hard handoff is being requested) from source CAU. InterVendor Hard handOff SUCcesses for 3G Voice. This OM is pegged when source CM receives an indication that the mobile has arrived on the target traffic channel. InterVendor Hard handOff BLocKs for 3G Voice. This OM is pegged either when the source CM is unable to send the FACDIR2 message to target CM over the IS41 link or when the source CM receives an indication from the target CM that the handoff is blocked due to target cell resource allocation problem. This can happen when either a facdir2 response is not received at all (time out) or when the response indicates resource shortage. InterVendor Hard handOff FaiLuRes for 3G Voice. This OM is pegged when the mobile fails to arrive on the target cells traffic channel. InterVendor Hard handOff ATTempts for packet Data. This OM is pegged when the source CM receives a handoff candidate message (indicating that an outgoing hard handoff is being requested) from source CAU. InterVendor Hard handOff SUCcesses for packet Data. This OM is pegged when source CM receives an indication that the mobile has arrived on the target traffic channel.
sheet 199 of 225
Handoff performance (page 7-1) Handoff performance (page 7-1) Handoff performance (page 7-1)
IVHOSUCV
IVHOBLKV
IVHOFLRV
Handoff performance (page 7-1) Handoff performance (page 7-1) Handoff performance (page 7-1)
IVHOATTD
IVHOSUCD
CDMA
NBSS15.0
21-200 MSC OM descriptions Nortel Networks MSC operational measurements Register IVHOBLKD Description
InterVendor Hard handOff BLocKs for packet Data. This OM is pegged either when the source CM is unable to send the FACDIR2 message to target CM over the IS41 link or when the source CM receives an indication from the target CM that the handoff is blocked due to target cell resource allocation problem. This can happen when either a facdir2 response is not received at all (time out) or when the response indicates resource shortage. InterVendor Hard handOff FaiLuRes for packet Data. This OM is pegged when the mobile fails to arrive on the target cells traffic channel.
sheet 200 of 225
IVHOFLRD
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register OMMTX3 OM group Description
Reference chapter
OM MTX 3. This OM group is pegged on a per Sector basis. Note: Existing OMs for normal paging are not pegged in the Border system, when page request received from anchor system or response is received in the Border system for border cell paging.
BORANCPG
BORder ANChor Cell PaGe. This OM is pegged against ANCHOR CELL in Border system when an incoming border page (regardless of border page option in Anchor system) is sent to a zone in the Border system. ISPAGE2 invoke message contains cell ID for the anchor cell when sent to the Border system. The Border system uses table BRDRCELL to determine a border zone within Border system from ANCHOR CellID to send a page. This OM is not pegged when CDMASYPG OM (MTXSYS1 OM group) is pegged for system-wide page. BORder PaGE RESponse. This is pegged against a cell of Border system for page response received from the mobile when incoming border page (regardless of border page option in Anchor system) is sent in Border system for either zone or system-wide paging. This OM helps configure border zone for improving border cell paging.
sheet 201 of 225
BORPGRES
CDMA
NBSS15.0
21-202 MSC OM descriptions Nortel Networks MSC operational measurements Register SRTDBORG Description
Reference chapter
Silent ReTry DouBle ORiGination. This OM is pegged at the CM when an origination message is received and the time interval between the current origination message and the previous origination message (from the same mobile) is within a datafilled time (defined by the SILENT_RETRY_TIMER) and the call is still being setup for the previous origination message and a SAT present message has not been received for the call on the first origination attempt and the mobile has not released the call.
It should be noted that the above OM is pegged irrespective of the mobile doing the silent retry or user doing the manual retry (provided the above conditions are met). Note: The SRTDBORG OM is pegged for the cell and sector of the previous origination attempt.
SRTDBO2G
Silent ReTry DouBle Origination 2G. This OM is pegged along with the SRTDBORG OM if the call type in the origination message is a 2G Voice Call. Silent ReTry DouBle Origination 3G Voice. This OM is pegged along with the SRTDBORG OM if the call type in the origination message is a 3G Voice Call. Silent ReTry DouBle Origination 3G Data. This OM is pegged along with the SRTDBORG OM if the call type in the origination message is a 3G Data Call.
sheet 202 of 225
SRTDBO3V
SRTDBO3D
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SLNTRTAF Description
Reference chapter
SiLeNT ReTry Access Failure. This OM is pegged at the CM when an origination message is received and the previous origination failed due to an Access Failure and time interval between the current origination message and the previous origination message (from the same mobile) is within a datafilled time (defined by the SILENT_RETRY_TIMER). It should be noted that the above OM is pegged irrespective of the mobile doing the silent retry or user doing the manual retry (provided the above conditions are met). Note: The SLNTRTAF OM is pegged for the cell and sector of the previous origination attempt.
SLNTRT2G
SiLeNT ReTry 2G. This OM is pegged along with the SLNTRTAF OM if the call type in the origination message is a 2G Voice Call. SiLeNT ReTry 3G Voice. This OM is pegged along with the SLNTRTAF OM if the call type in the origination message is a 3G Voice Call. SiLeNT ReTry 3G Data. This OM is pegged along with the SLNTRTAF OM if the call type in the origination message is a 3G Data Call.
sheet 203 of 225
SLNTRT3V
SLNTRT3D
CDMA
NBSS15.0
21-204 MSC OM descriptions Nortel Networks MSC operational measurements Register OMMTXHO2 OM group CHOSRCAT Description
Reference chapter Handoff performance (page 7-1) Handoff performance (page 7-1)
OM MTX Handoff 2. This OM group is pegged per Sector basis on source CM. Cm Hard handOff SouRCe ATtempts. This OM is pegged when the CM receives a handoff candidate message (indicating that a hard handoff is being requested) from the CAU. Note: OM is pegged for both intra and intersystem handoff scenarios and against the source (primary) cell/sector.
CHOSRCSU
Cm Hard handOff SouRCe SUccess. This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from the CAU (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). Note: OM is pegged for both intra and intersystem handoff scenarios and against the source (primary) cell/sector.
CHOBLKS
Cm Hard handOff BLocKS. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. Note: OM is pegged for both intra and intersystem handoff scenarios and against the source (primary) cell/sector. Cm Hard handOff SouRCe FaiL. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the CAU (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). Note: OM is pegged for both intra and intersystem handoff scenarios and against the source (primary) cell/sector. This OM pegs for both RF and network related failure reasons.
sheet 204 of 225
CHOSRCFL
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register CHOSRRLS Description
Cm Hard handOff SouRce ReLeaSe. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated (after CHOSRCAT). Note: OM is pegged for both intra and intersystem handoff scenarios and against the source (primary) cell/sector. Cm Hard handOff No SouRCe Response. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the receipt of the Handoff candidate message). CHONSRCR indicates that a handoff never occurred and does not indicate a dropped call. Note: OM is pegged for both intra and intersystem handoff scenarios and against the source (primary) cell/sector. Cm Hard handOff REJeCTed. This OM is pegged in rare conditions during which hard handoff can not take place. For example, if the mobile is moved to traffic channel for the purpose of receiving an announcement treatment, and if hard handoff is triggered, it will be rejected by the source CM. CHOREJCT indicates that a hard handoff never occurred and does not indicate a dropped call. Note: This OM is pegged for both intra and intersystem handoff scenarios and against the source (primary) cell/sector. InterVendor Hard handOff 3G Voice ATTempts. This OM is pegged for inter system outgoing 3G voice call handoff attempts with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOSRCAT is also pegged. InterVendor Hard handOff 3G Voice SUCcesses. This OM is pegged for inter system outgoing 3G voice call handoff successes with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOSRCSU is also pegged. InterVendor Hard handOff 3G Voice BLocKs. This OM is pegged for inter system outgoing 3G voice call handoff blocks with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOBLKS is also pegged.
sheet 205 of 225
CHONSRCR
CHOREJCT
IVHOVATT New OM in MTX13 release
IVHOVSUC New OM in MTX13 release IVHOVBLK New OM in MTX13 release
CDMA
NBSS15.0
21-206 MSC OM descriptions Nortel Networks MSC operational measurements Register IVHOVFLR New OM in MTX13 release IVHODATT New OM in MTX13 release IVHODSUC New OM in MTX13 release IVHODBLK New OM in MTX13 release IVHODFLR New OM in MTX13 release Description
Reference chapter
InterVendor Hard handOff 3G Voice FaiLuRes. This OM is pegged for inter system outgoing 3G voice call handoff failures with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOSRCFL is also pegged. InterVendor Hard handOff packet Data ATTempts. This OM is pegged for inter system outgoing packet data call handoff attempts with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOSRCAT is also pegged. InterVendor Hard handOff packet Data SUCcesses. This OM is pegged for inter system outgoing packet data call handoff successes with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOSRCSU is also pegged. InterVendor Hard handOff packet Data BLocKs. This OM is pegged for inter system outgoing packet data call handoff blocks with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOBLKS is also pegged. InterVendor Hard handOff packet Data FaiLuRes. This OM is pegged for inter system outgoing packet data call handoff failures with the Nortel MSC as the source switch. This is applicable for both IS41 P and IS41C links when IS880 bool in SYSCON table is set to Y. When this OM is pegged, the corresponding OM CHOSRCFL is also pegged.
sheet 206 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register OMMTXH03 OM group New OM group in MTX13 release EHOSATT Description
OM MTX HandOff 3. This OM group is pegged on per sector, frequency basis with all call types combined on source CM for EHHO, Border, Pilot Beacon and 3G to 2G mechanism. When the OMs in this OM group are pegged, their corresponding OMs (CHO* OMs) in the OMMTXHO2 group are also pegged.
Ehho Hard handOff Source ATTempts. This OM is pegged when the CM processes a handoff candidate message (indicating that a hard handoff is being requested) with EHHO trigger. Ehho Hard handOff Source SUccesses. This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from the CAU (for intrasystem handoffs) or mobile on channel message from the IS-41 link (for intersystem handoffs). This OM is pegged for the EHHO trigger only. Ehho Hard handOff source BLocKS. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. This OM is pegged for the EHHO trigger only. Ehho Hard handOff Source FaiLures. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the MTX peripheral component (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). This OM is pegged for the EHHO trigger only. Ehho Hard handOff Source ReLeaseS. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated. This OM is pegged for the EHHO trigger only.
sheet 207 of 225
Handoff performance (page 7-1) Handoff performance (page 7-1)
EHOSSU
EHOBLKS
EHOSFL
EHOSRLS
CDMA
NBSS15.0
21-208 MSC OM descriptions Nortel Networks MSC operational measurements Register EHONSR Description
Ehho Hard handOff Source No Source Responses. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the processing of the Handoff candidate message). EHONSR indicates that a handoff never occurred and does not indicate a dropped call. This OM is pegged for the EHHO trigger only. Ehho Hard handOff Source ReJecTs. This OM is pegged in rare conditions when the CM cannot allocate the handoff data block due to resource problems or any other reasons, or when CM is processing the handoff candidate message, it finds that the VLR entry for the request MIN is not found, or when CM is in outpulsing, dialing, or collecting state when the handoff candidate message is received. This OM is pegged for the EHHO trigger only. Border RTD hard handOff source ATTempts. This OM is pegged when the CM processes a handoff candidate message (indicating that a hard handoff is being requested) with RTD trigger. Border RTD hard handOff source SUCcesses. This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from the CAU (for intrasystem handoffs) or mobile on channel message from the IS-41 link (for intersystem handoffs). This OM is pegged for the RTD trigger only. Border RTD hard handOff source BLocKs. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. This OM is pegged for the RTD trigger only. Border RTD hard handOff Source FaiLures. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the MTX peripheral component (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). This OM is pegged for the RTD trigger only.
sheet 208 of 225
EHOSRJT
BRTDATT New OM in 14.0 release BRTDSUC New OM in 14.0 release
Handoff performance (page 7-1) Handoff performance (page 7-1)
BRTDBLK New OM in 14.0 release
BRTDSFL New OM in 14.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register BRTDRLS New OM in 14.0 release Description
Border RTD hard handOff source ReLeaseS. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated. This OM is pegged for the RTD trigger only.
BRTDNSR New OM in 14.0 release
Border RTD hard handOff source No Source Responses. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the processing of the Handoff candidate message). BRTDNSR indicates that a handoff never occurred and does not indicate a dropped call. This OM is pegged for the RTD trigger only. Border RTD hard handOff source ReJecTs. This OM is pegged in rare conditions when the CM cannot allocate the handoff data block due to resource problems or any other reasons, or when CM is processing the handoff candidate message, it finds that the VLR entry for the request MIN is not found, or when CM is in outpulsing, dialing, or collecting state when the handoff candidate message is received. This OM is pegged for the RTD trigger only. Pilot BeaCON hard handOff source ATTempts. This OM is pegged when the CM processes a handoff candidate message (indicating that a hard handoff is being requested) with Pilot Beacon trigger.
BRTDRJT New OM in 14.0 release
PBCONATT New OM in 14.0 release
PBCONSUC New OM in 14.0 release
Pilot BeaCON hard handOff source SUCcesses. This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from the CAU (for intrasystem handoffs) or the mobile on channel message from the IS-41 link (for intersystem handoffs). This OM is pegged for the Pilot Beacon trigger only. Pilot BeaCON hard handOff source BLocKs. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. This OM is pegged for the Pilot Beacon trigger only.
sheet 209 of 225
PBCONBLK New OM in 14.0 release
CDMA
NBSS15.0
21-210 MSC OM descriptions Nortel Networks MSC operational measurements Register PBCONSFL New OM in 14.0 release Description
Pilot BeaCON hard handOff Source FaiLures. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the MTX peripheral component (for intrasystem handoffs) or from the IS41 link (for intersystem handoffs). This OM is pegged for the Pilot Beacon trigger only. Pilot BeaCON hard handOff source ReLeaseS. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated. This OM is pegged for the Pilot Beacon trigger only.
PBCONRLS New OM in 14.0 release
PBCONNSR New OM in 14.0 release
Pilot BeaCON hard handOff source No Source Responses. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the processing of the Handoff candidate message). PBCONNSR indicates that a handoff never occurred and does not indicate a dropped call. This OM is pegged for the Pilot Beacon trigger only. Pilot BeaCON hard handOff source ReJecTs. This OM is pegged in rare conditions when the CM cannot allocate the handoff data block due to resource problems or any other reasons, or when CM is processing the handoff candidate message, it finds that the VLR entry for the request MIN is not found, or when CM is in outpulsing, dialing, or collecting state when the handoff candidate message is received. This OM is pegged for the Pilot Beacon trigger only. Hard handoff 3G to 2G source ATTempts. This OM is pegged when the CM processes a handoff candidate message (indicating that a hard handoff is being requested) with 3G to 2G trigger. As 3G to 2G trigger only applies for intra-system hard handoffs, this OM pegs for intra-system handoff only.
PBCONRJT New OM in 14.0 release
H3G2GATT New OM in 14.0 release
sheet 210 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register H3G2GSUC New OM in 14.0 release Description
Hard handoff 3G to 2G source SUCcesses. This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from the CAU (for intrasystem handoffs) or the mobile on channel message from the IS-41 link (for intersystem handoffs). This OM is pegged for the 3G to 2G trigger only. As 3G to 2G trigger only applies for intra-system hard handoffs, this OM pegs for intra-system handoff only. Hard handoff 3G to 2G source BLocKs. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. This OM is pegged for the 3G to 2G trigger only.As 3G to 2G trigger only applies for intra-system hard handoffs, this OM pegs for intra-system handoff only. Hard handoff 3G to 2G Source FaiLures. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the MTX peripheral component (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). This OM is pegged for the 3G to 2G trigger only. As 3G to 2G trigger only applies for intra-system hard handoffs, this OM pegs for intra-system handoff only. Hard handoff 3G to 2G source ReLeaseS. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated. This OM is pegged for the 3G to 2G trigger only. As 3G to 2G trigger only applies for intra-system hard handoffs, this OM pegs for intra-system handoff only. Hard handoff 3G to 2G No Source Responses. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the processing of the Handoff candidate message). H3G2GNSR indicates that a handoff never occurred and does not indicate a dropped call. This OM is pegged for the 3G to 2G trigger only. As 3G to 2G trigger only applies for intra-system hard handoffs, this OM pegs for intra-system handoff only.
sheet 211 of 225
H3G2GBLK New OM in 14.0 release
H3G2GSFL New OM in 14.0 release
H3G2GRLS New OM in 14.0 release H3G2GNSR New OM in 14.0 release
CDMA
NBSS15.0
21-212 MSC OM descriptions Nortel Networks MSC operational measurements Register H3G2GRJT New OM in 14.0 release Description
Hard handoff 3G to 2G source ReJecTs. This OM is pegged in rare conditions when the CM cannot allocate the handoff data block due to resource problems or any other reasons, or when CM is processing the handoff candidate message, it finds that the VLR entry for the request MIN is not found, or when CM is in outpulsing, dialing, or collecting state when the handoff candidate message is received. This OM is pegged for the 3G to 2G trigger only. As 3G to 2G trigger only applies for intra-system hard handoffs, this OM pegs for intra-system handoff only.
sheet 212 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register OMMTXH04 OM group New OM group in MTX13 release SQECSATT Description
OM MTX HandOff 4. This OM group is pegged on per sector, frequency basis on source CM for Signal Quality Hard Handoff (SQHHO) mechanism. When the OMs in this group are pegged, their corresponding OMs (CHO* OMs) in the OMMTXHO2 group are also pegged.
Signal Quality hard handoff EC/Io triggered Source hard handoff ATTempts. This OM is pegged when the CM processes a handoff candidate message (indicating that a hard handoff is being requested) with Ec sub trigger. This OM is pegged for IS95B+ mobile calls only. Signal Quality hard handoff EC/Io triggered Source hard handoff Successes. This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from CAU (for intrasystem handoffs) or the mobile on channel message from the IS-41 link (for intersystem handoffs). This register is pegged for the Ec sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff EC/Io triggered Source hard handoff BLocKs. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. This register is pegged for the Ec sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff EC/Io triggered Source hard handoff FaiLures. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the CAU (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). This register is pegged for the Ec sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff EC/Io triggered Source hard handoff ReLeases. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated. This register is pegged for the Ec sub trigger (IS95B+ mobile calls) only.
sheet 213 of 225
SQECSSU
SQECBLKS
SQECSFL
SQECSRLS
CDMA
NBSS15.0
21-214 MSC OM descriptions Nortel Networks MSC operational measurements Register SQECNSR Description
Signal Quality hard handoff EC/Io triggered Source hard handoff No Source Response. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the processing of the Handoff candidate message). SQECNSR indicates that a handoff never occurred and does not indicate a dropped call. This register is pegged for the Ec sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff EC/Io triggered Source hard handoff ReJecTs. This OM is pegged in rare conditions when the CM cannot allocate the handoff data block due to resource problems or any other reasons, or when CM is processing the handoff candidate message, it finds that the VLR entry for the request MIN is not found, or when CM is in outpulsing, dialing, or collecting state when the handoff candidate message is received. This register is pegged for the Ec sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff RTDmax triggered Source hard handoff ATTempts. This OM is pegged when the CM processes a handoff candidate message (indicating that a hard handoff is being requested) with RTDmax sub trigger. This OM is pegged for IS95B+ mobile calls only. Signal Quality hard handoff RTDmax triggered Source hard handoff Successes. This OM is pegged when the CM receives an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from CAU (for intrasystem handoffs) or the mobile on channel message from the IS-41 link (for intersystem handoffs). This register is pegged for the RTDmax sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff RTDmax triggered Source hard handoff BLocKs. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. This register is pegged for the RTDmax sub trigger (IS95B+ mobile calls) only.
sheet 214 of 225
SQECSRJT
SQRMSATT
SQRMSSU
SQRMBLKS
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SQRMSFL Description
Signal Quality hard handoff RTDmax triggered Source hard handoff FaiLures. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the CAU (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). This register is pegged for the RTDmax sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff RTDmax triggered Source hard handoff ReLeases. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated. This register is pegged for the RTDmax sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff RTDmax triggered Source hard handoff No Source Response. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the processing of the Handoff candidate message). SQECNSR indicates that a handoff never occurred and does not indicate a dropped call. This register is pegged for the RTDmax sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff RTDmax triggered Source hard handoff ReJecTs. This OM is pegged in rare conditions when the CM cannot allocate the handoff data block due to resource problems or any other reasons, or when CM is processing the handoff candidate message, it finds that the VLR entry for the request MIN is not found, or when CM is in outpulsing, dialing, or collecting state when the handoff candidate message is received. This register is pegged for the RTDmax sub trigger (IS95B+ mobile calls) only. Signal Quality hard handoff RTD triggered Source hard handoff ATTempts. This OM is pegged when the CM receives a handoff candidate message (indicating that a hard handoff is being requested) with RTD sub trigger. This OM is pegged for IS95A mobile calls only.
sheet 215 of 225
SQRMSRLS
SQRMNSR
SQRMSRJT
SQRTSATT
CDMA
NBSS15.0
21-216 MSC OM descriptions Nortel Networks MSC operational measurements Register SQRTSSU Description
Signal Quality hard handoff RTD triggered Source hard handoff Successes. This OM is pegged when the CM processes an indication that the mobile arrived on the target traffic channel. This OM is pegged when CM call processing receives a SAT present message from CAU (for intrasystem handoffs) or the mobile on channel message from the IS-41 link (for intersystem handoffs). This register is pegged for the RTD sub trigger (IS95A mobile calls) only. Signal Quality hard handoff RTD triggered Source hard handoff BLocKs. This OM is pegged when the CM receives an indication that the handoff is being blocked due to target cell resource allocation problems. This can happen when either a response is not received at all or when the response indicates resource shortages. This register is pegged for the RTD sub trigger (IS95A mobile calls) only. Signal Quality hard handoff RTD triggered Source hard handoff FaiLures. This OM is pegged when the mobile does not arrive on the target cells traffic channel. This OM is pegged when CM call processing does not receive a SAT present message from the CAU (for intrasystem handoffs) or from the IS-41 link (for intersystem handoffs). This register is pegged for the RTD sub trigger (IS95A mobile calls) only. This OM pegs for both RF and network related failure reasons. Signal Quality hard handoff RTD triggered Source hard handoff ReLeases. This OM is pegged when the call is released by either one of the participants after a hard handoff has been initiated. This register is pegged for the RTD sub trigger (IS95A mobile calls) only. Signal Quality hard handoff RTD triggered Source hard handoff No Source Response. This OM is pegged when neither SAT present (from the target cell) nor handoff response (from the source cell) is received within 10 seconds of the handoff process starting (after the processing of the Handoff candidate message). SQECNSR indicates that a handoff never occurred and does not indicate a dropped call. This register is pegged for the RTD sub trigger (IS95A mobile calls) only.
sheet 216 of 225
SQRTBLKS
SQRTSFL
SQRTSRLS
SQRTNSR
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register SQRTSRJT Description
Signal Quality hard handoff RTD triggered Source hard handoff ReJecTs. This OM is pegged in rare conditions when the CM cannot allocate the handoff data block due to resource problems or any other reasons, or when CM is processing the handoff candidate message, it finds that the VLR entry for the request MIN is not found, or when CM is in outpulsing, dialing, or collecting state when the handoff candidate message is received. This register is pegged for the RTD sub trigger (IS95A mobile calls) only.
sheet 217 of 225
CDMA
NBSS15.0
21-218 MSC OM descriptions Nortel Networks MSC operational measurements Register OMMTX2 OM group VPADIC Added in 12.0 release Description
Reference chapter Call setup performance (page 2-1) Call setup performance (page 2-1) Paging performance (page 10-1)
OM MTX 2. This CM based OM group is pegged on a per Sector basis. VPAD InComing. The VPADIC OM register measures the number of incoming calls which cause the data call preemption by VPAD feature. The VPADIC OM register is pegged when the VPAD feature decides to force an active Data Call into dormant mode. This corresponds to the page request message being sent to the mobile after the call goes dormant. This is pegged in the CM based OM group OMMTX2 against the sector in which the data call is currently active. Note: When the page request is sent, then other existing paging OMs are pegged appropriately (MTXSYS1, CDMAPAGE, and IZP OMs). The CAUPGREQ OM in CAUCPSYS is also pegged when the page request is sent.
sheet 218 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register OMMTXSY2 OM group VPADATT Added in 12.0 release Description
Reference chapter Call setup performance (page 2-1) Call setup performance (page 2-1) Paging performance (page 10-1)
OM MTX SYStem 2. This CM based OM group is pegged on a per System basis. VPAD ATTempt. The VPADATT OM measures the number of voice call setup attempts by the VPAD feature after the data call is preempted. The VPADATT OM is pegged when the Page Response message has been received from the mobile. Note: The CAUPGRES OM in CAUSCT3V OM group and the appropriate OMs in the CDMAPAGE OM group are also pegged when the Page Response is received from the mobile.
VPADSUC Added in 12.0 release
VPAD SUCcess. The VPADSUC OM measures the number of voice call setup attempts successfully setup by the VPAD feature. The VPADSUC OM is pegged when the voice call is answered or the CM gets a no answer time out (indicating that the subscriber chose not to answer the voice call). Note: CAUTSUCC OM in CAUSCT3V OM group is also pegged.
VPADFL Added in 12.0 release
VPAD FaiLure. The VPADFL OM measures the number of voice call setup attempts which failed to setup for the VPAD feature. The VPADFL OM is pegged when the CM receives a Call Failure after a page response but before the call is answered or answer time out occurs. The CAUTBLKS, CAUTRLS, CAUERLFL, CAUEDLOT, and the appropriate BTS blocking reason OMs in the CAUSCT3V OM group will also be pegged.
sheet 219 of 225
CDMA
NBSS15.0
21-220 MSC OM descriptions Nortel Networks MSC operational measurements Register OTASYS OMs group COTPATPP Added in 11.0 release COTPATPT Added in 11.0 release COTPUNSP Added in 11.0 release COTPNALC Added in 11.0 release Description
Reference chapter OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1)
OTAPA SYStem. This OM group tracks events on a system wide basis. Cdma OTaPa ATtemPt Page. This OM is pegged when the Serving MSC receives a SMDPP message with the ACTCODE value of allocate resources and the Serving MSC must page the mobile in order to move it to a traffic channel. Cdma OTaPa ATtemPT. This OM is pegged when the Serving MSC receives a SMDPP message with the ACTCODE value of allocate resources. Cdma OTaPa UNSupported. This OM is pegged when the mobile responds to the OTAPA page request and does not support Service Option 18. An smdpp is returned to the OTAF with the SMS_CauseCode value of Service Not Supported. Cdma OTaPA Not ALloCated. This OM is pegged when the Serving MSC sends a smdpp return result with CauseCode parameter and the SMDPP invoke identified allocate resources. This is NOT pegged when COTPUNSP is pegged. Examples of when this register is pegged is page time-out, SOC disabled, and time-out on data delivery. Cdma OTaPa ABoRTed. This OM is pegged on premature releases of an OTAPA session. The following items are premature releases: (a) MS originated during an OTAPA session (release message received at Serving MSC, (b) MS was terminated to during an OTAPA session, (c) Clear Forward or Clear Back during an OTAPA session. (MS ended a voice call during an OTAPA session), (d) Unsupported handoff occurred during OTAPA session (CDMA to Analog, Intersystem Handoff). This OM is pegged when the OTAPA audit identifies a hung OTAPA session. Cdma OTaPa PaGe ReSponse. The OM is pegged when a page response is received for an OTAPA session.
COTPABRT Added in 11.0 release
OTAPA performance (page 19-1)
COTPPGRS Added in 11.0 release
OTAPA performance (page 19-1)
sheet 220 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register COTAPREL Added in 11.0 release COTPDATP Added in 11.0 release COTPDSUC Added in 11.0 release COTPDFLR Added in 11.0 release COTAPREQ Added in 11.0 release COTPREQS Added in 11.0 release COTPREQF Added in 11.0 release COTPRREQ Added in 11.0 release COTAPNOT Added in 11.0 release Description
Reference chapter OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1) OTAPA performance (page 19-1)
Cdma OTaPA RELease. This OM is pegged when the Serving MSC receives a SMDPP message with the ACTCODE value of release resources that results in deallocation of MSC and BSC OTAPA resources. Cdma OTaPa Data delivery ATtemPts. This OM is pegged when the Serving MSC receives a SMDPP message with the SRVIND = cdma otapa and has Bearer_Data. Cdma OTaPa Delivery SUCcess. This OM is pegged when the smdpp return result is sent with no Cause Code.
Cdma OTaPA Data delivery FaiLuRe. This OM is pegged when the Serving MSC sends a smdpp return result with CauseCode parameter. Cdma OTaPa REQuest. This OM is pegged when the HLR receives a SMSREQ with the SRVIND value of cdma otapa.
Cdma OTaPa REQuest Successful. This OM is pegged when the HLR sends a SMSREQ with the routing address of the Serving MSC. Cdma OTaPA REQuest Failure. This OM is pegged when the HLR sends a SMSREQ with the SMS Access Denied parameter with the value of either Denied or Unavailable. Cdma OTaPa Redundant REQuest. This OM is pegged when the HLR receives a SMSREQ and the pending flag is already set at the HLR. Cdma OTaPa NOTification. This OM is pegged when the HLR receives a SMSNOT setting the pending flag back to false at the HLR.
sheet 221 of 225
CDMA
NBSS15.0
21-222 MSC OM descriptions Nortel Networks MSC operational measurements Register RMU3G OM group Modified OM group in 13.0 release Description
Reference chapter Call resource allocation and management (page 16-1)
Resource Manager Unit 3G. This OM group tracks events on a per-RMU basis. These OMs are pegged by RMU to measure resource allocations and failures for 3G Voice Calls. Note: The following OMs from this group are removed in 13.0 release: REQ19K, SUC19K, NORS19K, REQ38K, SUC38K, NORS38K, REQ76K, SUC76K, NORS76K, REQ153K, SUC153K, NORS153K
REQ3GV
REQuest for 3G Voice call. This OM is pegged when there is an attempt made by RMU to allocate resources for a 3G Voice call attempt based on a resource request from CAU. Note: This is a 3G related OM.
SUC3GV
SUCcess for 3G Voice call. This OM is pegged when the RMU successfully allocates resources for a 3G Voice call based on a resource request from CAU. Note: This is a 3G related OM. NO ReSource for 3G Voice call. This OM is pegged when the RMU fails to allocate resources for a 3G Voice call based on a resource request from CAU. Note: This is a 3G related OM. REQuest for 3G Voice call 2 (extension). This OM is the extension of REQ3GV.
Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
NORS3GV
REQ3GV2
SUC3GV2
SUCcess for 3G Voice call 2 (extension). This OM is the extension of SUC3GV.
NORS3GV2
NO ReSource for 3G Voice call 2 (extension). This OM is the extension of NORS3GV.
sheet 222 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register Statistics OM group New OM group in 14.0 release connectionsS etup Description
These OMs are pegged by PVG up on successful codec negotiation for various codec types. These OMs peg at PVG irrespective of the call is originating or terminating.
This OM provides the number connections (regardless of the connection type) successfully established by PVG.
trfoConnectio nsSetup
This OM provides the number of TrFO connections successfully established by the TrFO capable PVG.
evrcConnectio nsSetup
This OM provides the number of EVRC (codec type) media connection type successfully established by PVG.
evrc0Connecti onsSetup
This OM provides the number of EVRC0 (header free EVRC codec type) media connection type successfully established by PVG.
sheet 223 of 225
CDMA
NBSS15.0
21-224 MSC OM descriptions Nortel Networks MSC operational measurements Register TRMTRS OM group TRSGNCT Description This OM group is pegged per system-wide basis.
Reference chapter Call setup performance (page 2-1) Call setup performance (page 2-1)
Trunk Routing System General No Circuit. This OM indicates that a GNCT (generalized no circuit) treatment was set when routing. This OM normally reflects performance problems during mobile originated calls.
sheet 224 of 225
411-2133-525
Standard
06.12
April 2008
Nortel Networks MSC operational measurements Register WPSOM1 OM group New OM group in MTX13 release WQTOUT Description
Wireless Priority Service Operational Measurements 1. This OM group is pegged at the CM on a system-wide basis for Wireless Priority Service events only when WPS is turned ON. Only a subset of the OMs in this group are presented in this table. Applicable only to WPS activated CDMA carriers. WPS Queue failure due to queue TimeOUT.
WQOVFL
WPS Queue failure due to a queue OVerFLow.
WINVALDQ
WPS total INVALiD originations while Queued.
sheet 225 of 225
CDMA
NBSS15.0
21-226 MSC OM descriptions Nortel Networks
411-2133-525
Standard
06.12
April 2008
Nortel Networks
BSC OM descriptions 22-1 Copyright 2008 Nortel Networks
BSC OM descriptions
22
This chapter lists all the BSC OMs discussed in the CDMA System Performance Operational Measurements guide. This chapter also includes other CDMA specific BSC OMs which are not used in any metric but are useful for more information. This chapter contains the detailed descriptions, reference chapter, and sequence number (if applicable) for each of the OMs. The OMs are sorted first by OM type (BSC, CDMA-LTX, or Link) and then, within that type, by OM group. Each performance attribute (OM) in the BSC has a unique sequence number which helps identify it from the raw data in text format. When logfilter is applied to the OM data received from the BSC, a text file is generated which provides the name of the performance attribute along with its value. The EBID based performance attributes are reported separately from the Node based (system-wide) performance attributes when raw data is parsed. Therefore, the sequence numbers of EBID based and Node based performance attributes belonging to the same Managed objects may be the same in some cases. Note: OMs with no reference chapter are listed merely for completeness.
BSC operational measurements
22
List of BSCRLP setup OM group (page -4) contains BSC OMs (also called Performance Attributes). The description of OMs also includes some important notes regarding them. Sequence number for each OM is provided to help understand OMs when reviewing raw OM data (before log filter is applied). Please refer to NTP NN20000-104 for more information regarding logfilter. Starting with the NBSS 12.0 release, the BSC OMs are grouped and reported into several new OM groups. This section has the following OM groups. RLP Setup OM group SCH Burst Setup OM group SCH Burst Release OM group SCH Primary Radio Link Setup OM group SCH Handoff Radio Link Setup OM group SCH Radio Link Release OM group RLP Data Throughput OM group
CDMA
NBSS15.0
22-2 BSC OM descriptions Nortel Networks

411-2133-525
Packet Session Signaling OM group Packet Session Data OM group RP Session Signaling OM group RP Session Data OM group PCU Manager OM group CPU Usage OM group RP Session L2TP OM group RFCH Gating OM group Reference Sector Frame Count OM group Reference Sector FER OM group Hard Handoff Trigger OM group Pegging Limitation Exceeded OM group PCU Queue Occupancy OM group SDU (Selection and Distribution Unit) Queue Occupancy OM group Call Resource Request Processing OM group Call Resource Setup OM group Service Resource Setup OM group Resource Availability Check OM group Platform Selection OM group DHO Platform Selection Overload OM group DTA Platform Selection Overload OM group Platform Selection Overload OM group BSC Resource Request Processing OM group BSC Resource Setup OM group DTA Call Resource Setup OM group DTA BSC PCU Lookup OM group DHO Call Resource Request Processing OM group DHO Call Resource Setup OM group DHO Service Resource Setup OM group Resource Utilization OM group ACP Resource Capacity Connection Call Resource Setup OM group
06.12 April 2008
Standard
Nortel Networks
Connection Resource Availability Check OM group BSC Connection Resource Availability Check OM group Connection Resource Redirection OM group Connection Resource Setup OM group Short Data Burst OM group Note: In the NBSS 12.0 release and in subsequent releases, the BSC OM Framework has the capability of turning ON or OFF the pegging of OMs in an OM group on a per OM basis via an OM Bit Mask. This introduces the capability to selectively collect individual OMs within an OM group or certain groups of OMs from the SBS to the BSSM. When the pegging of a certain OM is turned OFF, the OM will be reported as having a zero value. The OM Management tool generates a log output that can be used to reference the OM bit mask values at a particular time. This is needed in order to be able to distinguish between an OM having a zero value as a result of the OM being set to OFF or an OM having a zero value as a result of lack of events that cause the OM to peg.
The CPDS platform also provides the following OM groups that provide hardware/protocol level information for design support personnel. As they do not pertain to system performance in the scope of this document, they are not included in this NTP. For more information about the following OMs, see EBSC and BSC Performance Management: Operational Measurements Reference (NN20000255). BCN Socket Layer OMs BCN STLA Transport Layer OMs BCN STLD Transport Layer OMs BCN Link Layer OMs BCN Enhanced Socket (ACNES) OMs
CDMA
NBSS15.0
The following table shows a list of OMs in the RLP Setup OM group
List of BSCRLP setup OM group Register Description Sequence number (if applicable) OM group ID is 8 Reference chapter Call setup performance (page 2-1)
RLP Setup OM group
This OM group provides number of RLP setup attempts, Successes and Failures. Note: The RLPSetup** OMs are required since RLP is synchronized after the Service Connect Completion message is sent, that is, after all of the radio resources have been successfully allocated.
RLPSetupAtt empts RLPSetupSu ccesses
This OM is pegged when RLP setup is attempted during call setup. For each call setup, RLP setup is attempted once. This OM is pegged for successful RLP setup during call setup. If RLP sync is required and is found then this OM is pegged. This OM is also pegged for successful RLP setup when RLP sync is not required. This OM provides number of failed RLP setups. Please note that for dormant to null transitions, mobiles have to go dormant to active transitions first before they can release the call. And for certain types of mobiles, e.g.Samsung i700 and Audiovox Thera, mobiles may send release order before dormant to active session setup completes. Therefore this OM will also get pegged for these scenarios.
RLPSetupFai lures
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Table 22-1 shows a list of BSC OMs for the SCH burst setup OM group.
Table 22-1 List of BSC OMsSCH burst setup OM group Register Description Sequence number (if applicable) OM group ID is 9 Reference chapter 1xRTT packet data performance (page 3-1)
SCH Burst Setup OM group
This OM group is pegged for forward & Reverse data burst setup Attempts, Successes, Failures (regardless of the requested data rate for the burst), Downgrade, Non-downgrade and delay. The OMs in this group are pegged per PCU and available in BSC and EBSC. Note: The FwdBurstSetup* & RevBurstSetup*OMs provide a measure of whether data bursts in the forward & Reverse direction is successful. It is important to separate this from SCH setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
FwdBurstSet upAttempts
This OM is pegged when a forward data burst setup is attempted (regardless of the requested data rate for the burst). This OM is pegged when a forward data burst is successfully set up (regardless of the data rate for the burst) i.e. resources on ESEL/ACP and at least one BTS are allocated and mobile successfully arrives on the SCH. This OM is pegged when a forward data burst could not be set up (regardless of the requested data rate for the burst) i.e. resources on ESEL/ACP or primary sector(s) are not available or mobile does not arrive on the SCH. This OM is pegged when a reverse data burst setup is attempted (regardless of the requested data rate for the burst).
1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
FwdBurstSet upSuccesses
FwdBurstSet upFailures
RevBurstSet upAttempts
sheet 1 of 30
CDMA
NBSS15.0
22-6 BSC OM descriptions Nortel Networks Table 22-1 List of BSC OMsSCH burst setup OM group (continued) Register Description
Sequence number (if applicable) 5
Reference chapter 1xRTT packet data performance (page 3-1)
RevBurstSet upSuccesses
This OM is pegged when a reverse data burst is successfully set up (regardless of the data rate for the burst) i.e. resources on ESEL/ACP and at least one BTS are allocated and mobile successfully arrives on the SCH. Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction is successful. This OM is pegged when a reverse data burst could not be set up (regardless of the requested data rate for the burst), i.e., resources on ESEL/ACP or primary sector(s) are not available or mobile does not arrive on the SCH. Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction is successful. This OM is pegged whenever a request to setup a Forward SCH is downgraded to a lower data rate by the ESEL/ACP based on ESEL/ACP card capacity limitation (i.e., prior to BTS resource considerations). Prior to release 12.0 this OM used to be known as FwdBurst_ESEL_Downgrade. This OM is also pegged when FwdBurstBSC_DowngradeCHange OM is pegged. This OM is pegged whenever a request to setup a Forward SCH is granted by the ESEL/ACP, without being downgraded based on the ESEL/ACP card capacity (i.e., prior to BTS resource considerations). Prior to release 12.0 this OM used to be known as FwdBurst_ESEL_Non_Downgrade. This OM is pegged whenever a Forward SCH request waits in the queue (due to BSC fair share algorithm) for more than zero seconds and less or equal to one second. Prior to release 12.0 this OM used to be known as FwdBurst_Delay>0_and_ <=1sec
sheet 2 of 30
RevBurstSet upFailures
1xRTT packet data performance (page 3-1)
FwdBurstBS C_Downgrad e
FwdBurstBS C_NonDown grade
FwdBurstDel ayIndex_1 Added in 11.0 release
411-2133-525
Standard
06.12
April 2008
Nortel Networks Table 22-1 List of BSC OMsSCH burst setup OM group (continued) Register Description
FwdBurstDel ayIndex_2 Added in 11.0 release FwdBurstDel ayIndex_3 Added in 11.0 release RevBurstBS C_Downgrad e
This OM is pegged whenever a Forward SCH request waits in the queue (due to BSC fair share algorithm) for more than one second and less or equal to three seconds. Prior to release 12.0 this OM used to be known as FwdBurst_Delay>1_and_ <=3sec This OM is pegged whenever a Forward SCH request waits in the queue (due to BSC fair share algorithm) for more than three seconds. Prior to release 12.0 this OM used to be known as FwdBurst_Delay>3 This OM is pegged whenever a request to setup a Reverse SCH is downgraded to a lower data rate by the ESEL/ACP based on ESEL/ACP card capacity limitation (i.e., prior to BTS resource considerations). Prior to release 12.0 this OM used to be known as RevBurst_ESEL_Downgrade. This OM is pegged whenever a request to setup a Reverse SCH is granted by the ESEL/ACP, without being downgraded based on the ESEL/ACP card capacity (i.e., prior to BTS resource considerations). Prior to release 12.0 this OM used to be known as RevBurst_ESEL_Non_Downgrade. This OM is pegged whenever a Reverse SCH request waits in the queue (due to BSC fair share algorithm) for more than zero seconds and less or equal to one second. Prior to release 12.0 this OM used to be known as RevBurst_Delay>0_and_ <=1sec. This OM is pegged whenever a Reverse SCH request waits in the queue (due to BSC fair share algorithm) for more than one second and less or equal to three seconds. Prior to release 12.0 this OM used to be known as RevBurst_Delay>1_and_ <=3sec.
sheet 3 of 30
11
1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
12
RevBurstBS C_NonDown grade
13
RevBurstDel ayIndex_1 Added in 11.0 release RevBurstDel ayIndex_2 Added in 11.0 release
14
15
CDMA
NBSS15.0
Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
RevBurstDel ayIndex_3 Added in 11.0 release FwdBurstSet upAttempts_ 2X Added in 12.0 release
This OM is pegged whenever a Reverse SCH request waits in the queue (due to BSC fair share algorithm) for more than three seconds. Prior to release 12.0 this OM used to be known as RevBurst_Delay>3. This OM is pegged when a 2X forward data burst setup is attempted. Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed. This OM is pegged when a 4X forward data burst setup is attempted (the requested data rate of 4X is prior to any possible downgrade by the BSC Fairshare algorithm). Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
sheet 4 of 30
17
FwdBurstSet upAttempts_ 4X Added in 12.0 release
18
411-2133-525
Standard
06.12
April 2008
This OM is pegged when a 8X forward data burst setup is attempted (the requested data rate of 8X is prior to any possible downgrade by the BSC Fairshare algorithm). Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed. This OM is pegged when a 16X forward data burst setup is attempted (the requested data rate of 16X is prior to any possible downgrade by the BSC Fairshare algorithm). Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
sheet 5 of 30
20
CDMA
NBSS15.0
FwdBurstSet upSuccesses _2X Added in 12.0 release
This OM is pegged when a 2X forward data burst is successfully set up i.e. resources on ESEL/ACP and at least one BTS are allocated and mobile successfully arrives on the SCH (note that the requested data rate for the burst could have been 2X or higher). Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
22
sheet 6 of 30
411-2133-525
Standard
06.12
April 2008
This OM is pegged when a 16X forward data burst is successfully set up i.e. resources on ESEL/ACP and at least one BTS are allocated and mobile successfully arrives on the SCH. Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
24
sheet 7 of 30
CDMA
NBSS15.0
FwdBurstSet upFailures_2 X Added in 12.0 release
This OM is pegged when a 2X forward data burst could not be set up i.e. resources on ESEL/ACP or primary sector(s) are not available or mobile does not arrive on the SCH. Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
This OM is pegged when a 4X forward data burst could not be set up i.e. resources on ESEL/ACP or primary sector(s) are not available or mobile does not arrive on the SCH (the 4X data rate represents the requested burst data rate prior to any possible downgrade by the BSC Fairshare algorithm). Note: The FwdBurstSetup* OMs provide a measure of whether data bursts in the forward direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
sheet 8 of 30
26
411-2133-525
Standard
06.12
April 2008
FwdBurstSet upFailures_1 6X Added in 12.0 release
28
sheet 9 of 30
CDMA
NBSS15.0
RevBurstSet upAttempts_ 2X Added in 12.0 release
This OM is pegged when a 2X reverse data burst setup is attempted. Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed. This OM is pegged when a 4X reverse data burst setup is attempted (the requested data rate of 4X is prior to any possible downgrade by the BSC Fairshare algorithm). Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
30
sheet 10 of 30
411-2133-525
Standard
06.12
April 2008
This OM is pegged when a 8X reverse data burst setup is attempted (the requested data rate of 8X is prior to any possible downgrade by the BSC Fairshare algorithm). Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
This OM is pegged when a 16X reverse data burst setup is attempted (the requested data rate of 16X is prior to any possible downgrade by the BSC Fairshare algorithm). Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
32
sheet 11 of 30
CDMA
NBSS15.0
RevBurstSet upSuccesses _2X Added in 12.0 release
This OM is pegged when a 2X reverse data burst is successfully set up i.e. resources on ESEL/ACP and at least one BTS are allocated and mobile successfully arrives on the SCH (note that the requested data rate for the burst could have been 2X or higher). Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
34
sheet 12 of 30
411-2133-525
Standard
06.12
April 2008
This OM is pegged when a 16X reverse data burst is successfully set up i.e. resources on ESEL/ACP and at least one BTS are allocated and mobile successfully arrives on the SCH. Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
36
sheet 13 of 30
CDMA
NBSS15.0
RevBurstSet upFailures_2 X Added in 12.0 release
This OM is pegged when a 2X reverse data burst could not be set up i.e. resources on ESEL/ACP or primary sector(s) are not available or mobile does not arrive on the SCH. Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
This OM is pegged when a 4X reverse data burst could not be set up i.e. resources on ESEL/ACP or primary sector(s) are not available or mobile does not arrive on the SCH (the 4X data rate represents the requested burst data rate prior to any possible downgrade by the BSC Fairshare algorithm). Note: The RevBurstSetup* OMs provide a measure of whether data bursts in the reverse direction are successful. It is important to separate this from SCH Link setup, as the mobile involved in the burst could have more than one pilot in its Active Set. When this is the case, a SCH could be setup successfully on one of the pilots in the set, but not the others, resulting in a successful data burst, even though SCH allocation on one or more of the radio links failed.
38
sheet 14 of 30
411-2133-525
Standard
06.12
April 2008
RevBurstSet upFailures_1 6X Added in 12.0 release
40
sheet 15 of 30
CDMA
NBSS15.0
FwdBurstDo wngrade_4X _To_2X New OM in 12.1 release FwdBurstDo wngrade_8X _To_2X New OM in 12.1 release
This OM is pegged whenever a request to setup a Forward 4X SCH is downgraded to 2X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Forward 8X SCH is downgraded to 2X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is also pegged when FwdBurstDowngradeChange_8X_To_4X is pegged. This OM is only available on the CPDS platform
42
FwdBurstDo wngrade_8X _To_4X New OM in 12.1 release FwdBurstDo wngrade_16 X_To_2X New OM in 12.1 release
This OM is pegged whenever a request to setup a Forward 8X SCH is downgraded to 4X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Forward 16X SCH is downgraded to 2X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is also pegged when FwdBurstDowngradeChange_16X_To_4X is pegged. This OM is pegged when FwdBurstDowngradeChange_16X_To_8X is pegged and new data rate is 2X. This OM is only available on the CPDS platform
sheet 16 of 30
43
44
411-2133-525
Standard
06.12
April 2008
FwdBurstDo wngrade_16 X_To_4X New OM in 12.1 release
This OM is pegged whenever a request to setup a Forward 16X SCH is downgraded to 4X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is pegged when FwdBurstDowngradeChange_16X_To_8X is pegged and new data rate is 4X. This OM is only available on the CPDS platform.
FwdBurstDo wngrade_16 X_To_8X New OM in 12.1 release FwdBurstNo nDowngrade _2X New OM in 12.1 release FwdBurstNo nDowngrade _4X New OM in 12.1 release FwdBurstNo nDowngrade _8X New OM in 12.1 release
This OM is pegged whenever a request to setup a Forward 16X SCH is downgraded to 8X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform. This OM is pegged whenever a request to setup a Forward 2X SCH is granted based only on ACP capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform. This OM is pegged whenever a request to setup a Forward 4X SCH is granted (at 4X without being downgraded) based only on ACP capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform. This OM is pegged whenever a request to setup a Forward 8X SCH is granted (at 8X without being downgraded) based only on ACP capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform.
sheet 17 of 30
46
47
48
49
CDMA
NBSS15.0
FwdBurstNo nDowngrade _16X New OM in 12.1 release RevBurstDo wngrade_4X _To_2X New OM in 12.1 release RevBurstDo wngrade_8X _To_2X New OM in 12.1 release RevBurstDo wngrade_8X _To_4X New OM in 12.1 release RevBurstDo wngrade_16 X_To_2X New OM in 12.1 release RevBurstDo wngrade_16 X_To_4X New OM in 12.1 release
This OM is pegged whenever a request to setup a Forward 16X SCH is granted (at 16X without being downgraded) based only on ACP card capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 4X SCH is downgraded to 2X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 8X SCH is downgraded to 2X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 8X SCH is downgraded to 4X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 16X SCH is downgraded to 2X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 16X SCH is downgraded to 4X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform
sheet 18 of 30
51
52
53
54
55
411-2133-525
Standard
06.12
April 2008
RevBurstDo wngrade_16 X_To_8X New OM in 12.1 release RevBurstNon Downgrade_ 2X New OM in 12.1 release RevBurstNon Downgrade_ 4X New OM in 12.1 release RevBurstNon Downgrade_ 8X New OM in 12.1 release RevBurstNon Downgrade_ 16X New OM in 12.1 release FwdBurstUp gradeAttempt s_2X_To_4X New OM in 12.1 release
This OM is pegged whenever a request to setup a Reverse 16X SCH is downgraded to 8X by Fair Share algorithm based only on ACP card capacity limitation (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 2X SCH is granted based only on ACP card capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 4X SCH is granted (at 4X without being downgraded) based only on ACP card capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 8X SCH is granted (at 8X without being downgraded) based only on ACP card capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged whenever a request to setup a Reverse 16X SCH is granted (at 16X without being downgraded) based only on ACP card capacity (i.e. prior to BTS resources considerations). This OM is only available on the CPDS platform This OM is pegged after a 2X forward infinite Burst is taken down for the purpose of upgrading its datarate, and an attempt is made to upgrade the data rate to 4X. Note that the existing FwdBurstSetupAttempts_4X and FwdBurstSetupAttempts OMs are also pegged alongside this OM.
sheet 19 of 30
57
58
59
60
61
CDMA
NBSS15.0
FwdBurstUp gradeAttempt s_2X_To_8X New OM in 12.1 release FwdBurstUp gradeAttempt s_2X_To_16 X New OM in 12.1 release FwdBurstUp gradeAttempt s_4X_To_8X New OM in 12.1 release FwdBurstUp gradeAttempt s_4X_To_16 X New OM in 12.1 release FwdBurstUp gradeAttempt s_8X_To_16 X New OM in 12.1 release
This OM is pegged after a 2X forward infinite Burst is taken down for the purpose of upgrading its datarate, and an attempt is made to upgrade the data rate to 8X. Note that the existing FwdBurstSetupAttempts_8X and FwdBurstSetupAttempts OMs are also pegged alongside this OM. This OM is pegged after a 2X forward infinite Burst is taken down for the purpose of upgrading its datarate, and an attempt is made to upgrade the data rate to 16X. Note that the existing FwdBurstSetupAttempts_16X and FwdBurstSetupAttempts OMs are also pegged alongside this OM. This OM is pegged after a 4X forward infinite Burst is taken down for the purpose of upgrading its datarate, and an attempt is made to upgrade the data rate to 8X. Note that the existing FwdBurstSetupAttempts_8X and FwdBurstSetupAttempts OMs are also pegged alongside this OM. This OM is pegged after a 4X forward infinite Burst is taken down for the purpose of upgrading its datarate, and an attempt is made to upgrade the data rate to 16X. Note that the existing FwdBurstSetupAttempts_16X and FwdBurstSetupAttempts OMs are also pegged alongside this OM. This OM is pegged after a 8X forward infinite Burst is taken down for the purpose of upgrading its datarate, and an attempt is made to upgrade the data rate to 16X. Note that the existing FwdBurstSetupAttempts_16X and FwdBurstSetupAttempts OMs are also pegged alongside this OM.
sheet 20 of 30
63
64
65
66
411-2133-525
Standard
06.12
April 2008
FwdBurstUp gradeSucces ses_2X_To_ 4X New OM in 12.1 release
This OM is pegged when a 2X forward infinite Burst is upgraded successfully to a higher data rate of 4X. This means BSC & BTS resources are setup successfully, and BSC received the Ack from the mobile for the ESCAM message. The attempt could have been to upgrade to a higher rate than 4X. Note that the existing FwdBurstSetupSuccesses_4X and FwdBurstSetupSuccesses OMs are also pegged alongside this OM. This OM is pegged when a 2X forward infinite Burst is upgraded successfully to a higher data rate of 8X. This means BSC & BTS resources are setup successfully, and BSC received the Ack from the mobile for the ESCAM message. The attempt could have been to upgrade to a higher rate than 8X. Note that the existing FwdBurstSetupSuccesses_8X and FwdBurstSetupSuccesses OMs are also pegged alongside this OM. This OM is pegged when a 2X forward infinite Burst is upgraded successfully to a higher data rate of 16X. This means BSC & BTS resources are setup successfully, and BSC received the Ack from the mobile for the ESCAM message. Note that the existing FwdBurstSetupSuccesses_16X and FwdBurstSetupSuccesses OMs are also pegged alongside this OM. This OM is pegged when a 4X forward infinite Burst is upgraded successfully to a higher data rate of 8X. This means BSC & BTS resources are setup successfully, and BSC received the Ack from the mobile for the ESCAM message. The attempt could have been to upgrade to a higher rate than 8X. Note that the existing FwdBurstSetupSuccesses_8X and FwdBurstSetupSuccesses OMs are also pegged alongside this OM.
sheet 21 of 30
FwdBurstUp gradeSucces ses_2X_To_ 8X New OM in 12.1 release
68
FwdBurstUp gradeSucces ses_2X_To_ 16X New OM in 12.1 release FwdBurstUp gradeSucces ses_4X_To_ 8X New OM in 12.1 release
69
70
CDMA
NBSS15.0
FwdBurstUp gradeSucces ses_4X_To_ 16X New OM in 12.1 release FwdBurstUp gradeSucces ses_8X_To_ 16X New OM in 12.1 release
This OM is pegged when a 4X forward infinite Burst is upgraded successfully to a higher data rate of 16X. This means BSC & BTS resources are setup successfully, and BSC received the Ack from the mobile for the ESCAM message. Note that the existing FwdBurstSetupSuccesses_16X and FwdBurstSetupSuccesses OMs are also pegged alongside this OM. This OM is pegged when a 8X forward infinite Burst is upgraded successfully to a higher data rate of 16X. This means BSC & BTS resources are setup successfully, and BSC received the Ack from the mobile for the ESCAM message. Note that the existing FwdBurstSetupSuccesses_16X and FwdBurstSetupSuccesses OMs are also pegged alongside this OM.
sheet 22 of 30
72
411-2133-525
Standard
06.12
April 2008
FwdBurstUp gradeFailure s_2X_To_4X New OM in 12.1 release
This OM is pegged when there is a failure to upgrade the data rate of a 2X forward infinite Burst to 4X due to lack of BSC or BTS resources. (Note that the 2X forward infinite burst is released prior to the upgrade attempt). This OM is also pegged along with existing OMs FwdBurstSetupFailures and FwdBurstSetpFailures_4X if the mobile does not arrive on the FSCH after the burst is upgraded. When upgrade fails due to BSC or BTS resources but the burst setup is successful at other data rate and the mobile arrives on the FSCH, this OM is also pegged with existing OMs FwdBurstSetupSuccesses and FwdBurstSetupSuccesses_XX (GrantedRate). When upgrade fails due to BSC or BTS resources but the burst setup is successful at other data rate and the mobile does not arrives on the FSCH, this OM is also pegged with existing OMs FwdBurstSetupFailures and FwdBurstSetupFailures_XX (GrantedRate).
sheet 23 of 30
CDMA
NBSS15.0
sheet 24 of 30
411-2133-525
Standard
06.12
April 2008
FwdBurstUp gradeFailure s_2X_To_16 X New OM in 12.1 release
sheet 25 of 30
CDMA
NBSS15.0
sheet 26 of 30
411-2133-525
Standard
06.12
April 2008
sheet 27 of 30
CDMA
NBSS15.0
FwdBurstBS C_Downgrad eChange New OM in 12.1 release
This OM is pegged along with appropriate FwdBurstDowngradeChange_XX_To_XX when the BSC fair share algorithm further downgrades a forward burst data-rate (due to contention for BSC resources) that was previously downgraded by the fair share algorithm before it was queued by the BTS scheduler. After the downgrade change, appropriate OMs FwdBurstSetup** and FwdBurstSetup**_datarate OMs for successes or failures are pegged against the final granted datarate.
sheet 28 of 30
79
411-2133-525
Standard
06.12
April 2008
FwdBurstBS C_NonDown gradeChang e New OM in 12.1 release
This OM is pegged along with appropriate FwdBurstNonDowngradeChange_XX when the BSC fair share algorithm downgrades a forward burst data-rate after it is queued by the BTS scheduler if originally the request was not downgraded by the fair share algorithm prior to being queued by the BTS scheduler. After the non-downgrade change, appropriate OMs FwdBurstSetup** and FwdBurstSetup**_datarate OMs for successes or failures are pegged against the final granted datarate. This OM is pegged when the BSC fair share algorithm further downgrades a forward burst datarate (due to contention for BSC resources) that was previously downgraded from 8X to 4X by the fair share algorithm before it was queued by the BTS scheduler. This OM is only available on the CPDS platform.
FwdBurstDo wngradeCha nge_8X_To_ 4X New OM in 12.1 release FwdBurstDo wngradeCha nge_16X_To _4X New OM in 12.1 release FwdBurstDo wngradeCha nge_16X_To _8X New OM in 12.1 release
81
This OM is pegged when the BSC fair share algorithm further downgrades a forward burst datarate (due to contention for BSC resources) that was previously downgraded from 16X to 4X by the fair share algorithm before it was queued by the BTS scheduler. This OM is only available on the CPDS platform. This OM is pegged when the BSC fair share algorithm further downgrades a forward burst datarate (due to contention for BSC resources) that was previously downgraded from 16X to 8X by the fair share algorithm before it was queued by the BTS scheduler. This OM is only available on the CPDS platform.
sheet 29 of 30
82
83
CDMA
NBSS15.0
FwdBurstNo nDowngrade Change_4X New OM in 12.1 release
This OM is pegged when the BSC fair share algorithm downgrades a 4X forward burst data-rate to a lower rate after it is queued by the BTS scheduler. Note that the 4X rate request was not originally downgraded by the fair share algorithm prior to being queued by the BTS scheduler. This OM is only available on the CPDS platform.
85
sheet 30 of 30
86
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of BSC OMs for the SCH burst release OM group.
List of BSC OMsSCH burst release OM group Register Description Sequence number (if applicable) OM group ID is 20 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
SCH Burst Release OM group FwdBurstBS C_Release_ 2X New OM in 12.1 release
This OM group is pegged for infinite forward & Reverse data burst release events. The OMs in group are pegged per node in BSC and EBSC. This OM is pegged when a 2X infinite forward burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is different from and not related to the FwdBurstUpgradeFailures related OMs. This OM is pegged when a 4X infinite forward burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is different from and not related to the FwdBurstUpgradeFailures related OMs. This OM is pegged when a 8X infinite forward burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is different from and not related to the FwdBurstUpgradeFailures related OMs. This OM is pegged when a 16X infinite forward burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is different from and not related to the FwdBurstUpgradeFailures related OMs.
sheet 1 of 4
FwdBurstBS C_Release_ 4X New OM in 12.1 release
CDMA
NBSS15.0
22-36 BSC OM descriptions Nortel Networks List of BSC OMsSCH burst release OM group Register Description
RevBurstBS C_Release_ 2X New OM in 12.1 release RevBurstBS C_Release_ 4X New OM in 12.1 release RevBurstBS C_Release_ 8X New OM in 12.1 release RevBurstBS C_Release_ 16X New OM in 12.1 release FwdBurstBT S_PilotRelea se_2X New OM in 12.1 release
This OM is pegged when a 2X infinite reverse burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is pegged when a 4X infinite reverse burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is pegged when a 8X infinite reverse burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is pegged when a 16X infinite reverse burst is taken down due to resource contention on the BSC (i.e. other burst requests are waiting in the BSC Fair Share Queue). The burst is taken down only after the expiration of a timer defined by the parameter MinActiveTime. This OM is pegged when a 2X infinite forward burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the FSCH_PilotRelease_2X or FSCH_BTS_Release_2X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set.
sheet 2 of 4
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsSCH burst release OM group Register Description
FwdBurstBT S_PilotRelea se_4X New OM in 12.1 release
This OM is pegged when a 4X infinite forward burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the FSCH_PilotRelease_4X or FSCH_BTS_Release_4X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set. This OM is pegged when a 8X infinite forward burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the FSCH_PilotRelease_8X or FSCH_BTS_Release_8X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set. This OM is pegged when a 16X infinite forward burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the FSCH_PilotRelease_16X or FSCH_BTS_Release_16X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set. This OM is pegged when a 2X infinite reverse burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the RSCH_PilotRelease_2X or RSCH_BTS_Release_2X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set.
sheet 3 of 4
11
12
RevBurstBT S_PilotRelea se_2X New OM in 12.1 release
13
CDMA
NBSS15.0
22-38 BSC OM descriptions Nortel Networks List of BSC OMsSCH burst release OM group Register Description
This OM is pegged when a 4X infinite reverse burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the RSCH_PilotRelease_4X or RSCH_BTS_Release_4X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set. This OM is pegged when a 8X infinite reverse burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the RSCH_PilotRelease_8X or RSCH_BTS_Release_8X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set. This OM is pegged when a 16X infinite reverse burst is taken down due to resource contention on the BTS. It is pegged when the burst is released due to the same events that caused the pegging of the RSCH_PilotRelease_16X or RSCH_BTS_Release_16X OMs. Note that the release of only one link (due to contention at BTS) may not necessarily cause the BSC to take down the burst (and the pegging of this OM) unless there is only one pilot in the SCH active set.
sheet 4 of 4
15
16
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table lists the BSC OMs for the SCH Primary radio link setup OM group.
List of BSC OMsSCH primary radio link setup OM group Register Description Sequence number (if applicable) OM group ID is 10 Reference chapter 1xRTT packet data performance (page 3-1)
SCH Primary Radio Link Setup OM group Modified OM group in 14.0 Release FSCHLinkSe tupAttempt
This OM group captures supplemental channel (SCH) link set up attempts, blocks, successes, and radio link access failures in the forward and reverse directions on the primary link only, and abnormal SCH drops in the forward and reverse directions on all active links. The first successfully setup link is considered the primary/initial link. The SCH Primary Radio Link Setup OMs are pegged on a per carriersector basis and are available on BSC and EBSC. This OM provides number of forward supplemental channel (FSCH) setup attempts for all data rates combined. This OM provides the number of FSCH setup attempts that are blocked due to either lack of resources (reason OMs are given below - see sequence numbers 6 through 10, and 62 to 64) or failed communications between the (E)BSC and BTS (see sequence number 71). This OM is pegged for all data rates combined. This OM provides number of FSCH setup attempts that are not granted the requested data rate due to lack of BTS resources, but are granted a lower data rate by the BTS. This OM provides number of FSCH setup successes for all data rates combined.
FSCHLinkSe tupBlock
FSCHLinkDo wngrade Modified in 13.0 Release FSCHLinkSe tupSuccess
1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
FSCHRadioL inkAccessFai lure
This OM is pegged in the event the resources for the FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against the initial link in the SCH active set for all data rates combined.
sheet 1 of 14
CDMA
NBSS15.0
List of BSC OMsSCH primary radio link setup OM group (continued) Register Description Sequence number (if applicable) 6 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
FSCHNoFwd Power
This OM is pegged if the FSCHBlock reason indicates a lack of available forward power.
FSCHNoWal shCode
This OM is pegged if the FSCHBlock reason indicates a lack of available Walsh codes.
FSCHNoPhy sRes
This OM is pegged if the FSCHBlock reason indicates there are no available channel elements.
FSCHNoFra meOffset Obselet in 15.0 release
This OM is pegged if the FSCHBlock reason indicates there is no available frame offset. Note: This OM is not implemented as Qualcomm ASIC has higher processing capacity in the forward direction and the current usage cannot exceed this. As of this release, this OM exists but will not be pegged under any scenarios.
FSCHTimeo ut
This OM is pegged if a response to the BTS Resource Request is never received due to failed communications with the BTS. This OM is not currently pegged and will be removed in a future release.
10
FSCH_CFDS _RadioConfi g RSCHLinkSe tupAttempt
11
This OM provides number of reverse supplemental channel (RSCH) setup attempts for all data rates combined. It is pegged against each link in the SCH active set.
sheet 2 of 14
12
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsSCH primary radio link setup OM group (continued) Register Description Sequence number (if applicable) 13 Reference chapter 1xRTT packet data performance (page 3-1)
RSCHLinkSe tupBlock
This OM provides number of RSCH setup attempts that are blocked for either lack of resources (reason OMs are given below - see sequence numbers 18 through 21) or failed communications between the (E)BSC and BTS (see sequence number 72). This OM is pegged for all data rates combined. This OM provides number of RSCH setup attempts that are not granted the requested data rate due to lack of resources, but are granted a lower data rate. It is pegged against the primary pilot in the SCH active set. This OM provides number of RSCH setup successes for all data rates combined.
RSCHLinkDo wngrade
14
1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
RSCHLinkSe tupSuccess
15
RSCHRadioL inkAccessFai lure
This OM is pegged in the event the resources for the RSCH are setup successfully, but the mobile does not arrive on the RSCH. It is pegged against the initial link in the SCH active set for all data rates combined. This OM is not currently pegged and will be removed in a future release.
16
RSCH_CFD S_RadioConf ig RSCH_CFD S_HighSpee d RSCHNoPhy sRes
17
This OM is pegged if the RSCHBlock reason indicates high speed RSCH has not been enabled through CFDS. Prior to Release 12.0 this OM used to be known as RSCHCFDSHighSpeed. This OM is pegged if the RSCHBlock reason indicates there are no available channel elements.
18
19
RSCHNoFra meOffset
This OM is pegged if the RSCHBlock reason indicates there is no available frame offset.
20
sheet 3 of 14
CDMA
NBSS15.0
List of BSC OMsSCH primary radio link setup OM group (continued) Register Description Sequence number (if applicable) 21 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
RSCHTimeo ut
This OM is pegged if a response to the BTS Resource Request is never received due to failed communications with the BTS. This OM is pegged if the forward or reverse supplemental channel gets abnormally dropped. This OM is pegged against every pilot in the SCH active set for all data rates combined. Note: The SCHDrop OM will only be pegged if the supplemental channels and the data burst have been successfully established before the SCH drops. This OM provides number of forward supplemental channel (FSCH) setup attempts for the 2X data rate. (Note that for the initial SCH link, this OM only includes initial 2X attempts and does not also include attempts at higher data rates that could not be setup at that rate, and therefore were attempted at 2X. For additional SCH links (i.e., SCH SHO links) this OM only represents 2X.) This OM provides number of forward supplemental channel (FSCH) setup attempts for the 4X data rate. (Note that for the initial SCH link, this OM only includes initial 4X attempts and does not also include attempts at higher data rates that could not be setup at that rate, and therefore were attempted at 4X. For additional SCH links (i.e., SCH SHO links) this OM only represents 4X.) This OM provides number of forward supplemental channel (FSCH) setup attempts for the 8X data rate. (Note that for the initial SCH link, this OM only includes initial 8X attempts and does not also include attempts at higher data rates that could not be setup at that rate, and therefore were attempted at 8X. For additional SCH links (i.e., SCH SHO links) this OM only represents 8X.)
sheet 4 of 14
SCHDrop
22
FSCHLinkSe tupAttempts_ 2X Added in 12.0 release
23
24
25
411-2133-525
Standard
06.12
April 2008
Nortel Networks
FSCHLinkSe tupAttempts_ 16X Added in 12.0 release FSCHLinkSe tupBlock_2X Added in 12.0 release FSCHLinkSe tupBlock_4X Added in 12.0 release
This OM provides number of forward supplemental channel (FSCH) setup attempts for the 16X data rate.
This OM provides number of FSCH setup attempts at the 2X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of FSCH setup attempts at the 4X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. (Note that for the initial F-SCH link, this OM represents attempts that could not be setup at the 4X data rate or any lower data rate. For additional SCH link setup attempts (i.e., SCH SHO links), this OM only represents attempts that could not be setup at 4X.) This OM provides number of FSCH setup attempts at the 8X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. (Note that for the initial F-SCH link, this OM represents attempts that could not be setup at the 8X data rate or any lower data rate. For additional SCH link setup attempts (i.e., SCH SHO links), this OM only represents attempts that could not be setup at 8X.) This OM provides number of FSCH setup attempts at the 16X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. (Note that for the initial F-SCH link, this OM represents attempts that could not be setup at the 16X data rate or any lower data rate. For additional SCH link setup attempts (i.e., SCH SHO links), this OM only represents attempts that could not be setup at 16X.)
sheet 5 of 14
27
28
FSCHLinkSe tupBlock_8X Added in 12.0 release
29
FSCHLinkSe tupBlock_16 X Added in 12.0 release
30
CDMA
NBSS15.0
FSCHLinkSe tupSuccess_ 2X Added in 12.0 release FSCHLinkSe tupSuccess_ 4X Added in 12.0 release FSCHLinkSe tupSuccess_ 8X Added in 12.0 release FSCHLinkSe tupSuccess_ 16X Added in 12.0 release FSCHRadioL inkAccessFai lure_2X Added in 12.0 release FSCHRadioL inkAccessFai lure_4X Added in 12.0 release
This OM provides number of FSCH setup successes for the 2X data rate. (Note that for the initial SCH link only, the requested data rate for the FSCH could have been 2X or higher.)
32
33
This OM provides number of FSCH setup successes for the 16X data rate.
34
This OM is pegged in the event the resources for the 2X data rate FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against the initial link in the SCH active set.
35
36
sheet 6 of 14
411-2133-525
Standard
06.12
April 2008
Nortel Networks
FSCHRadioL inkAccessFai lure_8X Added in 12.0 release FSCHRadioL inkAccessFai lure_16X Added in 12.0 release RSCHLinkSe tupAttempts_ 2X Added in 12.0 release
38
This OM provides number of reverse supplemental channel (RSCH) setup attempts for the 2X data rate. (Note that for the initial SCH link, this OM only includes initial 2X attempts and does not also include attempts at higher data rates that could not be setup at that rate, and therefore were attempted at 2X. For additional SCH links (i.e., SCH SHO links) this OM only represents 2X.) This OM provides number of reverse supplemental channel (RSCH) setup attempts for the 4X data rate. (Note that for the initial SCH link, this OM only includes initial 4X attempts and does not also include attempts at higher data rates that could not be setup at that rate, and therefore were attempted at 4X. For additional SCH links (i.e., SCH SHO links) this OM only represents 4X.) This OM provides number of reverse supplemental channel (RSCH) setup attempts for the 8X data rate. (Note that for the initial SCH link, this OM only includes initial 8X attempts and does not also include attempts at higher data rates that could not be setup at that rate, and therefore were attempted at 8X. For additional SCH links (i.e., SCH SHO links) this OM only represents 8X.)
sheet 7 of 14
39
RSCHLinkSe tupAttempts_ 4X Added in 12.0 release
40
RSCHLinkSe tupAttempts_ 8X Added in 12.0 release
41
CDMA
NBSS15.0
RSCHLinkSe tupAttempts_ 16X Added in 12.0 release RSCHLinkSe tupBlock_2X Added in 12.0 release RSCHLinkSe tupBlock_4X Added in 12.0 release
This OM provides number of reverse supplemental channel (RSCH) setup attempts for the 16X data rate.
This OM provides number of RSCH setup attempts at the 2X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of RSCH setup attempts at the 4X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. (Note that for the initial R-SCH link, this OM represents attempts that could not be setup at the 4X data rate or any lower data rate. For additional SCH link setup attempts (i.e., SCH SHO links), this OM only represents attempts that could not be setup at 4X.) This OM provides number of RSCH setup attempts at the 8X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. (Note that for the initial R-SCH link, this OM represents attempts that could not be setup at the 8X data rate or any lower data rate. For additional SCH link setup attempts (i.e., SCH SHO links), this OM only represents attempts that could not be setup at 8X.) This OM provides number of RSCH setup attempts at the 16X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. (Note that for the initial R-SCH link, this OM represents attempts that could not be setup at the 16X data rate or any lower data rate. For additional SCH link setup attempts (i.e., SCH SHO links), this OM only represents attempts that could not be setup at 16X.)
sheet 8 of 14
43
44
RSCHLinkSe tupBlock_8X Added in 12.0 release
45
RSCHLinkSe tupBlock_16 X Added in 12.0 release
46
411-2133-525
Standard
06.12
April 2008
Nortel Networks
RSCHLinkSe tupSuccess_ 2X Added in 12.0 release RSCHLinkSe tupSuccess_ 4X Added in 12.0 release RSCHLinkSe tupSuccess_ 8X Added in 12.0 release RSCHLinkSe tupSuccess_ 16X Added in 12.0 release RSCHRadioL inkAccessFai lure_2X Added in 12.0 release RSCHRadioL inkAccessFai lure_4X Added in 12.0 release
This OM provides number of RSCH setup successes for the 2X data rate. (Note that for the initial SCH link only, the requested data rate for the RSCH could have been 2X or higher.)
48
49
This OM provides number of RSCH setup successes for the 16X data rate.
50
This OM is pegged in the event the resources for the 2X data rate RSCH are setup successfully, but the mobile does not arrive on the RSCH. It is pegged against the initial link in the SCH active set.
51
52
sheet 9 of 14
CDMA
NBSS15.0
RSCHRadioL inkAccessFai lure_8X Added in 12.0 release RSCHRadioL inkAccessFai lure_16X Added in 12.0 release SCHDrop_2 X Added in 12.0 release
54
This OM is pegged if a 2X data rate forward or reverse supplemental channel gets abnormally dropped. This OM is pegged against every pilot in the SCH active set. Note: The SCHDrop OMs will only be pegged if the supplemental channels and the data burst have been successfully established before the SCH drops.
0
55
SCHDrop_4 X Added in 12.0 release
This OM is pegged if a 4X data rate forward or reverse supplemental channel gets abnormally dropped. This OM is pegged against every pilot in the SCH active set. Note: The SCHDrop OMs will only be pegged if the supplemental channels and the data burst have been successfully established before the SCH drops.
56
sheet 10 of 14
411-2133-525
Standard
06.12
April 2008
Nortel Networks
This OM is pegged if a 8X data rate forward or reverse supplemental channel gets abnormally dropped. This OM is pegged against every pilot in the SCH active set. Note: The SCHDrop OMs will only be pegged in the supplemental channels and the data burst have been successfully established before the SCH drops.
This OM is pegged if a 16X data rate forward or reverse supplemental channel gets abnormally dropped. This OM is pegged against every pilot in the SCH active set. Note: The SCHDrop OMs will only be pegged if the supplemental channels and the data burst have been successfully established before the SCH drops. This OM is pegged when the BSC fair share algorithm downgrades a 4X forward SCH request that is already queued at the BTS by the scheduler. The FSCHLinkSetupAttempt and appropriate FSCHLinkSetupAttempt_<data_rate> OMs will also be pegged. This OM is pegged when the BSC fair share algorithm downgrades a 8X forward SCH request that is already queued at the BTS by the scheduler. The FSCHLinkSetupAttempt and appropriate FSCHLinkSetupAttempt_<data_rate> OMs will also be pegged. This OM is pegged when the BSC fair share algorithm downgrades a 16X forward SCH request that is already queued at the BTS by the scheduler. The FSCHLinkSetupAttempt and appropriate FSCHLinkSetupAttempt_<data_rate> OMs will also be pegged.
sheet 11 of 14
58
FSCHLinkSe tupAttempts_ Change_4X New OM in 12.1 release FSCHLinkSe tupAttempts_ Change_8X New OM in 12.1 release FSCHLinkSe tupAttempts_ Change_16X New OM in 12.1 release
59
60
61
CDMA
NBSS15.0
FSCHBackH aulExhaustio n New OM in 13.0 release FSCHBCNLi nkExhaustion New OM in 13.0 release FSCHAcnIdE xhaustion New OM in 13.0 release FSCHDowng radePowerR eqChange_4 X_To_2X New OM in 13.0 release
This OM is pegged when the forward SCH blocking reason indicates the setup request failed due to BTS Backhaul Link Exhaustion. It is pegged along with the FSCHLinkSetupBlock OM and the appropriate FSCHLinkSetupBlock_<data_rate> OM. This OM is pegged along with the when the forward SCH blocking reason indicates that the setup request failed due to BTS BCN Link exhaustion. It is pegged along with the FSCHLinkSetupBlock OM and the appropriate FSCHLinkSetupBlock_<data_rate> OM. This OM is pegged when the forward SCH blocking reason indicates that the setup request failed due to BTS ACN ID Exhaustion. It is pegged along with the FSCHLinkSetupBlock OM and the appropriate FSCHLinkSetupBlock_<data_rate> OM. This OM is pegged when the BTS allocates a queued (initial) burst at 4X and the BSC downgrades it from 4X to 2X because the power requirement for the requested data rate changed after the burst was queued. Note: FSCHLinkDowngrade OM will be pegged along with this OM if the original BSC requested data rate was 16X or 8X.
0
63
64
65
FSCHDowng radePowerR eqChange_8 X_To_2X New OM in 13.0 release
This OM is pegged when the BTS allocates a queued (initial) burst at 8X and the BSC downgrades it from 8X to 2X because the power requirement for the requested data rate changed after the burst was queued. Note: FSCHLinkDowngrade OM will be pegged along with this OM if the original BSC requested data rate was 16X.
66
sheet 12 of 14
411-2133-525
Standard
06.12
April 2008
Nortel Networks
FSCHDowng radePowerR eqChange_8 X_To_4X New OM in 13.0 release
This OM is pegged when the BTS allocates a queued (initial) burst at 8X and the BSC downgrades it from 8X to 4X because the power requirement for the requested data rate changed after the burst was queued. Note: FSCHLinkDowngrade OM will be pegged along with this OM if the original BSC requested data rate was 16X.
FSCHDowng radePowerR eqChange_1 6X_To_2X New OM in 13.0 release FSCHDowng radePowerR eqChange_1 6X_To_4X New OM in 13.0 release FSCHDowng radePowerR eqChange_1 6X_To_8X New OM in 13.0 release FSCHLinkSe tupBlockSW_ Error New OM in 14.0 release
This OM is pegged when the BTS allocates a queued (initial) burst at 16X and the BSC downgrades it from 16X to 2X because the power requirement for the requested data rate changed after the burst was queued.
68
69
70
This OM is pegged when the forward SCH blocking reason indicates the that the setup request failed due to non-resource and non-timeout related software conditions/errors for primary FSCH links. It is pegged along with the FSCHLinkSetupBlock OM and the appropriate FSCHLinkSetupBlock_<data_rate> OM.
sheet 13 of 14
71
CDMA
NBSS15.0
RSCHLinkSe tupBlockSW_ Error New OM in 14.0 release
This OM is pegged when the reverse SCH blocking reason indicates the that the setup request failed due to non-resource and non-timeout related software conditions/errors for primary RSCH links. It is pegged along with the RSCHLinkSetupBlock OM and the appropriate RSCHLinkSetupBlock_<data_rate> OM.
sheet 14 of 14
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table lists the BSC OMs for the SCH Handoff radio link setup OM group.
List of BSC OMsSCH handoff radio link setup OM group Register Description Sequence number (if applicable) OM group ID is 70 Reference chapter 1xRTT packet data performance (page 3-1)
SCH Handoff Radio Link Setup OM group New OM group in 14.0 release SHO_FSCHL inkSetupAtte mpt SHO_FSCHL inkSetupBloc k
This OM group captures supplemental channel (SCH) link set up attempts, blocks, successes, and radio link access failures in the forward and reverse directions on the handoff link only. Any link setup after the primary/initial link is considered a soft handoff link. The SCH Handoff Radio Link Setup OMs are pegged on a per carrier-sector basis and available on BSC and EBSC. This OM provides number of forward supplemental channel (FSCH) setup attempts for all data rates combined. This OM provides the number of FSCH setup attempts that are blocked due to either lack of resources (failure reason OMs are given below - see sequence numbers 5 to 9, and 50 to 53) or failed communications between the BSC/EBSC and BTS. This OM is pegged for all data rates combined. This OM provides number of FSCH setup successes for all data rates combined.
SHO_FSCHL inkSetupSuc cess SHO_FSCH RadioLinkAc cessFailure
This OM is pegged in the event the resources for the FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against each handoff link in the SCH active set for all data rates combined. This OM is pegged if the FSCHBlock reason indicates a lack of available forward power.
SHO_FSCH NoFwdPower
sheet 1 of 8
CDMA
NBSS15.0
List of BSC OMsSCH handoff radio link setup OM group (continued) Register Description Sequence number (if applicable) 6 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
SHO_FSCH NoWalshCod e SHO_FSCH NoPhysRes
This OM is pegged if the FSCHBlock reason indicates a lack of available Walsh codes.
This OM is pegged if the FSCHBlock reason indicates there are no available channel elements.
SHO_FSCH NoFrameOffs et Obselete in 15.0 release
This OM is pegged if the FSCHBlock reason indicates there is no available frame offset. Note: This OM is not implemented as Qualcomm ASIC has higher processing capacity in the forward direction and the current usage cannot exceed this. As of this release, this OM exists but will not be pegged under any scenarios. This OM is pegged if a response to the BTS Resource Request is never received due to failed communications with the BTS. This OM provides number of reverse supplemental channel (RSCH) setup attempts for all data rates combined. This OM provides number of RSCH setup attempts that are blocked for either lack of resources (failure reason OMs are given below - see sequence numbers 14 to 17, and 54) or failed communications between the SBS and BTS. This OM is pegged for all data rates combined. This OM provides number of RSCH setup successes for all data rates combined.
SHO_FSCH Timeout
SHO_RSCH LinkSetupAtt empt SHO_RSCH LinkSetupBlo ck
10
11
SHO_RSCH LinkSetupSu ccess
12
sheet 2 of 8
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsSCH handoff radio link setup OM group (continued) Register Description Sequence number (if applicable) 13 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
SHO_RSCH RadioLinkAc cessFailure
This OM is pegged in the event the resources for the RSCH are setup successfully, but the mobile does not arrive on the RSCH. It is pegged against each handoff link in the SCH active set for all data rates combined. This OM is pegged if the RSCHBlock reason indicates high speed RSCH has not been enabled through CFDS. This OM is pegged if the RSCH Block reason indicates there are no available channel elements.
SHO_RSCH _CFDS_High Speed SHO_RSCH NoPhysRes
14
15
SHO_RSCH NoFrameOffs et SHO_RSCH Timeout
This OM is pegged if the RSCH Block reason indicates there is no available frame offset.
16
This OM is pegged if a response to the BTS Resource Request is never received due to failed communications with the BTS. This OM provides number of forward supplemental channel (FSCH) setup attempts for the 2X data rate.
17
SHO_FSCHL inkSetupAtte mpts_2X SHO_FSCHL inkSetupAtte mpts_4X SHO_FSCHL inkSetupAtte mpts_8X
18
19
20
sheet 3 of 8
CDMA
NBSS15.0
List of BSC OMsSCH handoff radio link setup OM group (continued) Register Description Sequence number (if applicable) 21 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
SHO_FSCHL inkSetupAtte mpts_16X SHO_FSCHL inkSetupBloc k_2X SHO_FSCHL inkSetupBloc k_4X SHO_FSCHL inkSetupBloc k_8X SHO_FSCHL inkSetupBloc k_16X SHO_FSCHL inkSetupSuc cess_2X SHO_FSCHL inkSetupSuc cess_4X SHO_FSCHL inkSetupSuc cess_8X SHO_FSCHL inkSetupSuc cess_16X
This OM provides number of forward supplemental channel (FSCH) setup attempts for the 16X data rate. This OM provides number of FSCH setup attempts at the 2X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of FSCH setup attempts at the 4X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of FSCH setup attempts at the 8X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of FSCH setup attempts at the 16X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of FSCH setup successes for the 2X data rate.
22
23
24
25
26
27
28
29
sheet 4 of 8
411-2133-525
Standard
06.12
April 2008
Nortel Networks
SHO_FSCH RadioLinkAc cessFailure_ 2X SHO_FSCH RadioLinkAc cessFailure_ 4X SHO_FSCH RadioLinkAc cessFailure_ 8X SHO_FSCH RadioLinkAc cessFailure_ 16X SHO_RSCH LinkSetupAtt empts_2X SHO_RSCH LinkSetupAtt empts_4X SHO_RSCH LinkSetupAtt empts_8X SHO_RSCH LinkSetupAtt empts_16X SHO_RSCH LinkSetupBlo ck_2X
This OM is pegged in the event the resources for the 2X data rate FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against each handoff link in the SCH active set. This OM is pegged in the event the resources for the 4X data rate FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against each handoff link in the SCH active set. This OM is pegged in the event the resources for the 8X data rate FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against each handoff link in the SCH active set. This OM is pegged in the event the resources for the 16X data rate FSCH are set up successfully, but the mobile does not arrive on the FSCH. It is pegged against each handoff link in the SCH active set. This OM provides number of reverse supplemental channel (RSCH) setup attempts for the 2X data rate.
31
32
33
34
35
36
This OM provides number of reverse supplemental channel (RSCH) setup attempts for the 16X data rate. This OM provides number of RSCH setup attempts at the 2X data rate that are blocked for lack of resources or failed communications between the SBS and BTS.
sheet 5 of 8
37
38
CDMA
NBSS15.0
SHO_RSCH LinkSetupBlo ck_4X SHO_RSCH LinkSetupBlo ck_8X SHO_RSCH LinkSetupBlo ck_16X SHO_RSCH LinkSetupSu ccess_2X SHO_RSCH LinkSetupSu ccess_4X SHO_RSCH LinkSetupSu ccess_8X SHO_RSCH LinkSetupSu ccess_16X SHO_RSCH RadioLinkAc cessFailure_ 2X SHO_RSCH RadioLinkAc cessFailure_ 4X
This OM provides number of RSCH setup attempts at the 4X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of RSCH setup attempts at the 8X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of RSCH setup attempts at the 16X data rate that are blocked for lack of resources or failed communications between the SBS and BTS. This OM provides number of RSCH setup successes for the 2X data rate.
40
41
42
43
44
45
This OM is pegged in the event the resources for the 2X data rate RSCH are setup successfully, but the mobile does not arrive on the RSCH. It is pegged against each handoff link in the SCH active set. This OM is pegged in the event the resources for the 4X data rate RSCH are setup successfully, but the mobile does not arrive on the RSCH. It is pegged against each handoff link in the SCH active set.
sheet 6 of 8
46
47
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsSCH handoff radio link setup OM group (continued) Register Description Sequence number (if applicable) 48 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
SHO_RSCH RadioLinkAc cessFailure_ 8X SHO_RSCH RadioLinkAc cessFailure_ 16X SHO_FSCH BackHaulExh austion
This OM is pegged in the event the resources for the 8X data rate RSCH are setup successfully, but the mobile does not arrive on the RSCH. It is pegged against each handoff link in the SCH active set. This OM is pegged in the event the resources for the 16X data rate RSCH are setup successfully, but the mobile does not arrive on the RSCH. It is pegged against each handoff link in the SCH active set. This OM is pegged when the forward SCH blocking reason indicates the setup request failed due to BTS Backhaul Link Exhaustion. It is pegged along with the SHO_FSCHLinkSetupBlock OM and the appropriate SHO_FSCHLinkSetupBlock_<data_rate> OM. This OM is pegged along with the when the forward SCH blocking reason indicates that the setup request failed due to BTS BCN Link exhaustion. It is pegged along with the SHO_FSCHLinkSetupBlock OM and the appropriate SHO_FSCHLinkSetupBlock_<data_rate> OM. This OM is pegged when the forward SCH blocking reason indicates the that the setup request failed due to BTS ACN ID Exhaustion. It is pegged along with the SHO_FSCHLinkSetupBlock OM and the appropriate SHO_FSCHLinkSetupBlock_<data_rate> OM. This OM is pegged when the forward SCH blocking reason indicates the that the setup request failed due to non-resource and non-timeout related software conditions/errors for FSCH handoff links. It is pegged along with the SHO_FSCHLinkSetupBlock OM and the appropriate SHO_FSCHLinkSetupBlock_<data_rate> OM.
sheet 7 of 8
49
50
SHO_FSCH BCNLinkExh austion
51
SHO_FSCH AcnIdExhaus tion
52
SHO_FSCHL inkSetupBloc kSW_Error New OM in 14.0 release
53
CDMA
NBSS15.0
List of BSC OMsSCH handoff radio link setup OM group (continued) Register Description Sequence number (if applicable) 54 Reference chapter 1xRTT packet data performance (page 3-1)
SHO_RSCH LinkSetupBlo ckSW_Error New OM in 14.0 release
This OM is pegged when the reverse SCH blocking reason indicates the that the setup request failed due to non-resource and non-timeout related software conditions/errors for RSCH handoff links. It is pegged along with the SHO_RSCHLinkSetupBlock OM and the appropriate SHO_RSCHLinkSetupBlock_<data_rate> OM.
sheet 8 of 8
The following table shows a list of BSC OMs for the SCH handoff radio link release OM group.
List of BSC OMsSCH radio link release OM group Register Description Sequence number (if applicable) OM group ID is 21 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
SCH Radio Link Release OM group FSCH_Requ estRetract_2 X New OM in 12.1 release
This OM group is pegged for infinite forward & Reverse SCH Link release events. These SCH Radio Link release OMs are pegged on a per carriersector basis and available on BSC and EBSC. This OM is pegged when the BSC retracts (i.e. releases) the queued 2X FSCH request at the BTS. Reasons for retraction could be such as call ended, FSCH no longer needed (due to mobility). The rate that it is pegged against is the last rate requested by the BSC of the BTS.
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsSCH radio link release OM group (continued) Register Description
FSCH_Requ estRetract_4 X New OM in 12.1 release FSCH_Requ estRetract_8 X New OM in 12.1 release FSCH_Requ estRetract_1 6X New OM in 12.1 release FSCH_BTS_ Release_2X New OM in 12.1 release
This OM is pegged when the BSC retracts (i.e. releases) the queued 4X FSCH request at the BTS. Reasons for retraction could be such as call ended, FSCH no longer needed (due to mobility). The rate that it is pegged against is the last rate requested by the BSC of the BTS. This OM is pegged when the BSC retracts (i.e. releases) the queued 8X FSCH request at the BTS. Reasons for retraction could be such as call ended, FSCH no longer needed (due to mobility). The rate that it is pegged against is the last rate requested by the BSC of the BTS. This OM is pegged when the BSC retracts (i.e. releases) the queued 16X FSCH request at the BTS. Reasons for retraction could be such as call ended, FSCH no longer needed (due to mobility). The rate that it is pegged against is the last rate requested by the BSC of the BTS. This OM is pegged when a 2X forward supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. This OM is pegged when a 4X forward supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set.
FSCH_BTS_ Release_4X New OM in 12.1 release
CDMA
NBSS15.0
22-62 BSC OM descriptions Nortel Networks List of BSC OMsSCH radio link release OM group (continued) Register Description
This OM is pegged when a 8X forward supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. This OM is pegged when a 16X forward supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. This OM is pegged when a 2X reverse supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. This OM is pegged when a 4X reverse supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. This OM is pegged when a 8X reverse supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set.
RSCH_BTS_ Release_2X New OM in 12.1 release
10
11
411-2133-525
Standard
06.12
April 2008
This OM is pegged when a 16X reverse supplemental channel is taken down as requested by the BTS due to contention at the BTS. The SCH is taken down only after the expiration of a timer defined by the parameter MinActiveTime. Note that the release of only one link (due to contention at BTS) may not necessarily cause the release of the burst unless there is only one pilot in the SCH active set. This OM is pegged when a 2X forward burst is released due to the fact that the current Fwd SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Fwd SCH active set. This OM is pegged when a 4X forward burst is released due to the fact that the current Fwd SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Fwd SCH active set. This OM is pegged when a 8X forward burst is released due to the fact that the current Fwd SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Fwd SCH active set. This OM is pegged when a 16X forward burst is released due to the fact that the current Fwd SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Fwd SCH active set.
FSCH_PilotR elease_2X New OM in 12.1 release
13
14
15
16
CDMA
NBSS15.0
22-64 BSC OM descriptions Nortel Networks List of BSC OMsSCH radio link release OM group (continued) Register Description
RSCH_Pilot Release_2X New OM in 12.1 release
This OM is pegged when a 2X reverse burst is released due to the fact that the current Rev SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Rev SCH active set. This OM is pegged when a 4X reverse burst is released due to the fact that the current Rev SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Rev SCH active set. This OM is pegged when a 8X reverse burst is released due to the fact that the current Rev SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Rev SCH active set. This OM is pegged when a 16X reverse burst is released due to the fact that the current Rev SCH active set pilots are no longer viable (i.e. are weak) and BTS resources could not be setup on the stronger pilots as selected by the SCH active set management algorithm. This OM is pegged against all pilots in the current Rev SCH active set. This OM is pegged when the 2X forward burst is released so that an attempt can be made to upgrade the data rate to 4X or higher. Note that prior to the release, both BSC and BTS resources were queried to check if resources are available to support an upgrade to 4X, and the response is positive from both. This OM is pegged against all pilots in the current Fwd SCH active set.
18
19
20
FSCH_Upgra deRelease_2 X_To_4X New OM in 12.1 release
21
411-2133-525
Standard
06.12
April 2008
FSCH_Upgra deRelease_2 X_To_8X New OM in 12.1 release FSCH_Upgra deRelease_2 X_To_16X New OM in 12.1 release FSCH_Upgra deRelease_4 X_To_8X New OM in 12.1 release
This OM does NOT get pegged. This is due to the fact that both BSC and BTS are queried only for resources availability to support the next higher data rate (i.e. 4X in this case). For upgrade attempts to an active 2X burst, when releasing the burst, only the FSCH_UpgradeRelease_2X_To_4X OM get pegged. This OM does NOT get pegged. This is due to the fact that both BSC and BTS are queried only for resources availability to support the next higher data rate (i.e. 4X in this case). For upgrade attempts to an active 2X burst, when releasing the burst, only the FSCH_UpgradeRelease_2X_To_4X OM get pegged. This OM is pegged when the 4X forward burst is released so that an attempt can be made to upgrade the data rate to 8X or higher. Note that prior to the release, both BSC and BTS resources were queried to check if resources are available to support an upgrade to 8X, and the response is positive from both. This OM is pegged against all pilots in the current Fwd SCH active set. This OM does NOT get pegged. This is due to the fact that both BSC and BTS are queried only for resources availability to support the next higher data rate (i.e. 8X in this case). For upgrade attempts to an active 4X burst, when releasing the burst, only the FSCH_UpgradeRelease_4X_To_8X OM get pegged This OM is pegged when the 8X forward burst is released so that an attempt can be made to upgrade the data rate to 16X. Note that prior to the release, both BSC and BTS resources were queried to check if resources are available to support an upgrade to 4X, and the response is positive from both. This OM is pegged against all pilots in the current Fwd SCH active set.
23
24
FSCH_Upgra deRelease_4 X_To_16X New OM in 12.1 release FSCH_Upgra deRelease_8 X_To_16X New OM in 12.1 release
25
26
CDMA
NBSS15.0
The following table shows a list of BSC-RLP data throughput OM group.

List of BSCRLP data throughput OM group Register Description Sequence number (if applicable) OM group ID is 11 Reference chapter RLP throughput performance (page 4-1)
RLP Data Throughput OM group
The RLP Data Throughput OMs are defined on a per data rate basis. These OMs indicate the number of Physical frames, RLP frames, transmitted RLP data bytes and re-transmitted RLP data bytes on the fundamental and supplemental channels in both the forward and reverse directions. These Data Throughput OMs are pegged on a per carrier-sector basis. This OM counts the total number of physical frames with RLP signalling or RLP bearer data that are sent on all forward FCH setup in a given sector-carrier (EBID). This OM is pegged against each EBID involved in the FCH active set. Note that the FFCH_PhysicalFrames OM is different from the FrameCntFCH BTS OM. Unlike the FrameCntFCH BTS OM, the FFCH_PhysicalFrames OM does not get pegged during IS-2000 signaling frames (e.g. during Universal Handoff Direction Message UHDM related frames). Also the FFCH_PhysicalFrames OM start getting pegged from the beginning of the RLP3 link establishment between the SBS and the mobile (after the RP packet session has already been successfully setup). This OM counts the total number of physical frames with RLP data that are sent on all forward 2X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set.
FFCH_Physi calFrames Added in 12.0 release
RLP throughput performance (page 4-1)
FSCH_Physi calFrames_2 X Added in 12.0 release
sheet 1 of 9
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSCRLP data throughput OM group (continued) Register Description
Reference chapter RLP throughput performance (page 4-1)
FSCH_Physi calFrames_4 X Added in 12.0 release FSCH_Physi calFrames_8 X Added in 12.0 release FSCH_Physi calFrames_1 6X Added in 12.0 release FFCH_RLP_ DataBytes Added in 12.0 release FSCH_RLP_ DataBytes_2 X Added in 12.0 release FSCH_RLP_ DataBytes_4 X Added in 12.0 release
This OM counts the total number of physical frames with RLP data that are sent on all forward 4X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set.
This OM counts the total number of original RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward FCH setup in a given sector-carrier (EBID). This OM is pegged against each EBID involved in the FCH active set. This OM counts the total number of original RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 2X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of original RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 4X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set.
sheet 2 of 9
RLP throughput performance (page 4-1) RLP throughput performance (page 4-1)
CDMA
NBSS15.0
22-68 BSC OM descriptions Nortel Networks List of BSCRLP data throughput OM group (continued) Register Description
FSCH_RLP_ DataBytes_8 X Added in 12.0 release FSCH_RLP_ DataBytes_1 6X Added in 12.0 release FFCH_ReTx RLP_DataBy tes Added in 12.0 release FSCH_ReTx RLP_DataBy tes_2X Added in 12.0 release FSCH_ReTx RLP_DataBy tes_4X Added in 12.0 release FSCH_ReTx RLP_DataBy tes_8X Added in 12.0 release
This OM counts the total number of original RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 8X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of original RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 16X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward FCH setup in a given sector-carrier (EBID). This OM is pegged against each EBID involved in the FCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 2X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 4X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 8X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set.
sheet 3 of 9
10
11
12
13
14
411-2133-525
Standard
06.12
April 2008
FSCH_ReTx RLP_DataBy tes_16X Added in 12.0 release FFCH_RLP_ Frames Added in 12.0 release FSCH_RLP_ Frames_2X Added in 12.0 release FSCH_RLP_ Frames_4X Added in 12.0 release FSCH_RLP_ Frames_8X Added in 12.0 release FSCH_RLP_ Frames_16X Added in 12.0 release
This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all forward 16X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of RLP frames (containing bearer data) sent on all forward FCH setup in a given sector-carrier (EBID). This OM is pegged against each EBID involved in the FCH active set. This OM counts the total number of RLP frames sent on all forward 2X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of RLP frames sent on all forward 4X SCH setup in a given sector-carrier. Each 4X Physical Frame may carry up to 2 RLP Frames. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of RLP frames sent on all forward 8X SCH setup in a given sector-carrier. Each 8X Physical Frame may carry up to 4 RLP Frames.This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of RLP frames sent on all forward 16X SCH setup in a given sectorcarrier. Each 16X Physical Frame may carry up to 8 RLP Frames.This OM is pegged against each EBID involved in the SCH active set.
sheet 4 of 9
16
RLP throughput performance (page 4-1) RLP throughput performance (page 4-1) RLP throughput performance (page 4-1) RLP throughput performance (page 4-1) RLP throughput performance (page 4-1)
17
18
19
20
CDMA
NBSS15.0
RFCH_Physi calFrames Added in 12.0 release
This OM counts the total number of physical frames with RLP signalling or bearer data that are sent on all reverse FCH setup in a given sector-carrier (EBID). This OM is pegged against each EBID involved in the FCH active set. Note that this OM gets pegged during DTX frames and erasures on the reverse FCH. It will not be pegged for frames carrying IS2000 signalling frames. This OM counts the total number of physical frames with RLP data that are sent on all reverse 2X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. Note that this OM gets pegged during DTX frames on the reverse 2X SCH. It will not be pegged for erasures. This OM counts the total number of physical frames with RLP data that are sent on all reverse 4X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. Note that this OM gets pegged during DTX frames on the reverse 4X SCH. It will not be pegged for erasures. This OM counts the total number of physical frames with RLP data that are sent on all reverse 8X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. Note that this OM gets pegged during DTX frames on the reverse 8X SCH. It will not be pegged for erasures. This OM counts the total number of physical frames with RLP data that are sent on all reverse 16X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. Note that this OM gets pegged during DTX frames on the reverse 16X SCH. It will not be pegged for erasures.
sheet 5 of 9
RSCH_Physi calFrames_2 X Added in 12.0 release RSCH_Physi calFrames_4 X Added in 12.0 release RSCH_Physi calFrames_8 X Added in 12.0 release RSCH_Physi calFrames_1 6X Added in 12.0 release
22
23
24
25
411-2133-525
Standard
06.12
April 2008
RFCH_RLP_ DataBytes Added in 12.0 release
This OM counts the total number of original and firstreceived retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse FCH setup in a given sector-carrier (EBID). Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged. This OM is pegged against each EBID involved in the FCH active set. This OM counts the total number of original and firstreceived retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse FCH setup in a given sector-carrier (EBID). Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of original and firstreceived retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse FCH setup in a given sector-carrier (EBID). Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of original and firstreceived retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse FCH setup in a given sector-carrier (EBID). Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged This OM is pegged against each EBID involved in the SCH active set.
sheet 6 of 9
RSCH_RLP_ DataBytes_2 X Added in 12.0 release
27
28
29
CDMA
NBSS15.0
RSCH_RLP_ DataBytes_1 6X Added in 12.0 release
This OM counts the total number of original and firstreceived retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse FCH setup in a given sector-carrier (EBID). Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse FCH setup in a given sector-carrier (EBID). Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged. This OM is pegged against each EBID involved in the FCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse 2X SCH setup in a given sector-carrier. Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse 4X SCH setup in a given sector-carrier. Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged. This OM is pegged against each EBID involved in the SCH active set.
sheet 7 of 9
RFCH_ReTx RLP_DataBy tes Added in 12.0 release
31
RSCH_ReTx RLP_DataBy tes_2X Added in 12.0 release
32
33
411-2133-525
Standard
06.12
April 2008
This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse 8X SCH setup in a given sector-carrier. Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of retransmitted RLP user-data-bytes (bearer data only, i.e. excluding overhead/signaling) sent on all reverse 16X SCH setup in a given sector-carrier. Please see the example in the RLP Throughput Performance chapter for more information on how this OM is pegged. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of RLP frames (containing bearer data) sent on all reverse FCH setup in a given sector-carrier (EBID). This OM is pegged against each EBID involved in the FCH active set. This OM counts the total number of RLP frames sent on all reverse 2X SCH setup in a given sector-carrier. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of RLP frames sent on all reverse 4X SCH setup in a given sector-carrier. Each 4X Physical Frame may carry up to 2 RLP Frames. This OM is pegged against each EBID involved in the SCH active set. This OM counts the total number of RLP frames sent on all reverse 8X SCH setup in a given sector-carrier. Each 8X Physical Frame may carry up to 4 RLP Frames. This OM is pegged against each EBID involved in the SCH active set.
sheet 8 of 9
35
RFCH_RLP_ Frames Added in 12.0 release RSCH_RLP_ Frames_2X Added in 12.0 release RSCH_RLP_ Frames_4X Added in 12.0 release RSCH_RLP_ Frames_8X Added in 12.0 release
36
RLP throughput performance (page 4-1) RLP throughput performance (page 4-1) RLP throughput performance (page 4-1) RLP throughput performance (page 4-1)
37
38
39
CDMA
NBSS15.0
Reference chapter RLP throughput performance (page 4-1) RLP throughput performance (page 4-1)
RSCH_RLP_ Frames_16X Added in 12.0 release FFCH_RLP_ OverheadFra mes Added in 14.0 release FFCH_RLP_ ZeroPayload Frames Added in 14.0 release RFCH_RLP_ OverheadFra mes Added in 14.0 release RFCH_RLP_ ZeroPayload Frames Added in 14.0 release
This OM counts the total number of RLP frames sent on all reverse 16X SCH setup in a given sectorcarrier. Each 16X Physical Frame may carry up to 8 RLP Frames. This OM is pegged against each EBID involved in the SCH active set. This OM provides the number of RLP overhead signaling frames sent over FCH in the forward direction. The overhead frames are SYNC, SYNC/ ACK, NAK, and ACK. This OM is pegged against all the EBIDs in the active set. This OM provides the number of RLP zero payload frames sent over FCH in the forward direction. The zero payload frames are FILL, IDLE, BLANK, and NULL. This OM is pegged against all the EBIDs in the active set. This OM provides the number of RLP overhead signaling frames sent over FCH in the reverse direction. The overhead frames are SYNC, SYNC/ ACK, NAK, and ACK. This OM is pegged against all the EBIDs in the active set. This OM provides the number of RLP zero payload frames sent over FCH in the reverse direction. The zero payload frames are FILL, IDLE, BLANK, NULL and ERASURE. This OM is pegged against all the EBIDs in the active set.
41
42
43
44
sheet 9 of 9
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of BSC OMs for the packet session signaling OM group.
List of BSC OMspacket session signaling OM group Register Description Sequence number (if applicable) OM group ID is 12 Reference chapter Call setup performance (page 2-1)
Packet Session Signalling OM group TotalSession SetupInitialAt tempts TotalSession SetupRecon nectAttempts
This OM group provides information on R-P session setup Attempts, R-P Reconnect Attempts, Successful session setups and Failed session setups. These per PCU OMs are pegged on the BSC and EBSC. This OM provides number of R-P session setup attempted for initial R-P session setup. Note: This OM is used to make the distinction between Initial RP session setups and R-P Session Handoffs. This OM provides number of R-P session reconnect attempts due to PCU change. Possible reasons for PCU change are 1) a data call transitions from dormant to active, but the original shelf has no available resources 2) a dormant handoff but remain on the same serving PDSN. This OM provides number of successful R-P session setups during initial or reconnect attempts. This OM provides number of failed R-P session setups either during initial or reconnect attempts. This OM is pegged when an initial R-P session setup attempt fails. This OM is pegged only when the PCU gives up on setting up the session for any reason after trying all the PDSNs.
TotalSession SetupSucces s TotalSession SetupFailure s TotalInitialRP SessionSetu pFailures Modified OM in release 13.0
sheet 1 of 2
CDMA
NBSS15.0
List of BSC OMspacket session signaling OM group (continued) Register Description Sequence number (if applicable) 6 Reference chapter Call setup performance (page 2-1)
TotalRPSess ionHandoffFa ilures Modified OM in release 13.0 TotalRelease sBeforeInitial SessionSetu p New OM in release 13.0 TotalRelease sBeforeHand offSessionSe tup New OM in 13.0 release RP_Dormant SessionDelet ions New OM in 14.0 release
This OM is pegged when a R-P session handoff attempt fails. This OM is pegged when the PCU gives up on a Inter-PCU or Inter-PDSN R-P session handoff attempt.
This OM provides the number of user-initiated data call releases before the initial RP session was completely setup. This OM will be pegged whenever user initiates a new call and decides to release the call before RP session setup is complete.
This OM provides the number of user-initiated data call releases before the RP session was completely setup during the handoffs (during the RP Reconnect scenario). This OM will be pegged whenever user is in the process of handoff and decides to release the call before the RP session setup is completed (during handoff). This OM pegs for the number of old dormant RPsessions that were released so that the requested dormant RP-session could be setup.
23
sheet 2 of 2
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table lists the BSC OMs for the packet session data OM group.
List of BSC OMspacket session data OM group Register Description Sequence number (if applicable) OM group ID is 13 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
Packet Session Data OM group TotalFwdPac ketsDropped
This OM group provides information on PPP Forward Packets drops, Reverse Packets drops, DCR Buffer Overflow and RR Buffer Overflow. These per PCU OMs are pegged on the BSC and EBSC. This OM provides number of PPP packets dropped in the forward direction per PCU. This OM is pegged when forward packets are dropped due to the DCR buffer for a packet session overflows or due to the Dormant buffer limit of a PCU is exceeded. This OM provides number of PPP packets dropped in the reverse direction per PCU. Note: The RR has been engineered such that the data throughput in the reverse direction, when the ESEL/ACP is carrying the maximum number of high speed data calls, should not exceed the RR buffer capacity. Should this happen, the number of packets that are dropped by the RR are counted by this OM. This OM provides number of DCR buffer overflows for all active packet data sessions per PCU. Note: It counts the number of times the buffer capacities are exceeded during the reporting period. This OM provides number of Stop Transmit messages sent from RLPQ per PCU. Note: This OM counts the number of times the RLPQ entity in the ESEL/ACP card sends a stop transmit message to the DCR. This would happen if the RLPQ buffer is congested and cannot transmit data to the mobile as fast as the DCR is delivering it. Prior to release 12.0 this OM used to be known as DCR_NumOfStopTransmitMsgsSent. This OM provides number of RR buffer overflows for all active packet data sessions on a PCU. Note: It counts the number of times the buffer capacities are exceeded during the reporting period.
sheet 1 of 3
TotalRevPac ketsDropped
DCRBufferO verflows
DCRNumOfS topTransmit MsgsSent
RRBufferOve rflows
CDMA
NBSS15.0
22-78 BSC OM descriptions Nortel Networks List of BSC OMspacket session data OM group (continued) Register Description
PeakNumber OfAttachedD ormantUsers New OM in release 12.1
This OM provides peak number of attached Dormant users on a PCU at a given time during an OM period. This is a high watermark which represents peak number of Dormant sessions supported by a PCU at a given time. Keep in mind that if this OM is summed across all PCUs on a single PCUFP, the peaks on each PCU may not have been simultaneous. Therefore, the aggregate would reflect the upper bound of the peak number. This OM is not configurable through CEMS and is always ON.
AttachedActi veUsers New OM in release 12.1
This OM provides number of attached active users on a PCU when Peak number of Dormant users are determined during an OM period. This OM is pegged for number of active users when PeakNumberOfAttachedDormantUsers OM is pegged for peak dormant users. This OM is not configurable through CEMS and is always ON.
PeakNumber OfAttachedA ctiveUsers New OM in release 12.1
This OM provides peak number of attached Active users on a PCU at a given time during an OM period. This is a high watermark which represents peak number of Active sessions supported by a PCU at a given time. Keep in mind that if this OM is summed across all PCUs on a single PCUFP, the peaks on each PCU may not have been simultaneous. Thus, the aggregate would reflect the upper bound of the peak number. This OM is not configurable through CEMS and is always ON.
sheet 2 of 3
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMspacket session data OM group (continued) Register Description
AttachedDor mantUsers New OM in release 12.1
This OM provides number of attached dormant users on a PCU when Peak number of Active users are determined during an OM period. This OM is pegged for number of dormant users when PeakNumberOfAttachedActiveUsers OM is pegged for peak active users. This OM is not configurable through CEMS and is always ON.
NumberOfDo rmantCallsG oingActive New OM in release 12.1
This OM provides information regarding the total number of dormant calls going to active over the OM period. Note: This OM is pegged for Network Initiated and Mobile Initiated Dormant to Active Transitions for all the dormant calls on that PCU. This OM will only peg on the CPDS.
10
TotalActiveS essionSecon ds New OM in 13.0 release TotalDorman tSessionSec onds New OM in 13.0 release
This OM provides the total number of seconds for all active sessions per PCU.
15
This OM provides the total number of seconds for all dormant sessions per PCU.
16
sheet 3 of 3
CDMA
NBSS15.0
The following table lists the BSC OMs for the RP session signaling OM group.
List of BSC OMsRP session signaling OM group Register Description Sequence number (if applicable) OM group ID is 22 Reference chapter Call setup performance (page 2-1)
RP Session Signaling OM group
This OM group provides information on Open R-P initial Session Setup and Handoff Attempts, Reconnect Attempts, Successful Attempts and Failures Reasons per IP (PDSN). The group also has OMs for Registration Requests and Reject Reasons per IP (PDSN). These OMs are pegged on the EBSC. This OM is pegged when a R-P session setup is attempted for the first time. It is pegged against the first PDSN where the R-P session setup in question is attempted. If first PDSN rejects a setup attempt and other PDSN(s) is (are) tried to setup the call, this OM is not pegged against any additional PDSN(s). This OM is pegged when a R-P session is successfully setup. The OM is pegged against the PDSN (PDSN that handled the initial setup attempt, or it could be another PDSN) where the R-P session was successfully setup.
sheet 1 of 7
TotalInitialRP _SessionSet upAttempts New OM in release 12.1 TotalInitialRP _SessionSet upSuccesses New OM in release 12.1
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsRP session signaling OM group (continued) Register Description
TotalInitialRP _SessionSet upRejectRea sonOther New OM in release 12.1
This OM is pegged against a PDSN for all the other reject reasons (that are not captured by specific reason OM below) provided by the PDSN when it rejects an RP Session setup request.There may be more than one PDSN tried by PCU for one session setup and all reject reasons are captured via specific reason OM against the PDSN rejecting a session setup. All reason OMs are used to determine PDSN HOPS. This OM is pegged against a PDSN for the reject reason ID Mismatch provided by the PDSN when it rejects an RP Session setup request.
TotalInitialRP _SessionSet upRejectRea sonIdMismat ch New OM in release 12.1 TotalInitialRP _SessionSet upRejectRea sonInsufficie ntResources New OM in release 12.1 TotalInitialRP _SessionSet upRejectRea sonMobileAu thFailure New OM in release 12.1
This OM is pegged against a PDSN for the reason Insufficient Resources provided by the PDSN when it rejects an RP Session setup request.
This OM is pegged against a PDSN for the reason Mobile Authentication provided by the PDSN when it rejects an RP Session setup request. There may be more than one PDSN tried by PCU for one session setup.
sheet 2 of 7
CDMA
NBSS15.0
22-82 BSC OM descriptions Nortel Networks List of BSC OMsRP session signaling OM group (continued) Register Description
TotalInitialRP _SessionSet upFailuresRe asonPDSN_ NotRespondi ng New OM in release 12.1 TotalRP_Ses sionHandoffA ttempts New OM in release 12.1 TotalRP_Ses sionHandoffS uccesses New OM in release 12.1 TotalRP_Ses sionHandoff RejectReaso nOther New OM in release 12.1
This OM is pegged against a PDSN for the reason PDSNNotResponding (meaning: RRQ timed out and max # of retransmission attempts have been reached). There may be more than one PDSN tried by PCU for one session setup.
This OM is pegged when a R-P session Handoff is attempted for Dormant or Active packet data call. It is pegged against the first PDSN where the R-P session handoff in question is attempted. If first PDSN rejects a handoff attempt and other PDSN(s) is (are) tried to handoff the R-P session, this OM is not pegged against any additional PDSN(s). This OM is pegged against a PDSN when R-P session handoff for Dormant or Active packet data call is successful. It is pegged by the target PCU against the PDSN where R-P session handoff is successful. This OM is pegged against a PDSN for all the other reject reasons (that are not captured by specific reason OM below) provided by the PDSN when it rejects an RP Session handoff request for Dormant or Active packet data call. There may be more than one PDSN tried by PCU for one session setup and all reject reasons are captured via specific reason OM against the PDSN rejecting a session setup. All reason OMs are used to determine PDSN HOPS. This OM is pegged against a PDSN for the reject reason ID Mismatch provided by the PDSN when it rejects an RP Session handoff request for Dormant or Active packet data call.
10
TotalRP_Ses sionHandoff RejectReaso nIdMismatch New OM in release 12.1
11
sheet 3 of 7
411-2133-525
Standard
06.12
April 2008
TotalRP_Ses sionHandoff RejectReaso nInsufficient Resources New OM in release 12.1 TotalRP_Ses sionHandoff RejectReaso nMobileAuth Failure New OM in release 12.1 TotalRP_Ses sionHandoffF ailuresReaso nPDSN_Not Responding New OM in release 12.1 PCU_Initiate dSessionRel easePacketS essionDiscon nect New OM in release 12.1
This OM is pegged against a PDSN for the reject reason Insufficient Resources provided by the PDSN when it rejects an RP Session handoff request for Dormant or Active packet data call.
This OM is pegged against a PDSN for the reject reason Mobile Authentication Failure provided by PDSN when it rejects an RP Session handoff request for Dormant or Active packet data call.
13
This OM is pegged against a PDSN for the reject reason PDSNNotResponding (i.e. RRQ timed out and max # of retransmissions have been reached) for a R-P session handoff attempt for Dormant or Active packet data call.
14
This OM is pegged against a PDSN when PCU releases R-P session for a release received from the BSC. The ESEL/ACP sends session release to the PCU when an active packet call is normally ended by the mobile user. In this case, the mobile also sends the release using PPP to the PDSN. The PDSN also sends session release to the PCU. If the R-P session is release by the PCU due to receiving release from the PDSN, this OM will not be pegged. Thus, this OM may not capture all the PCU initiated releases for RP sessions due to normal call releases.
sheet 4 of 7
16
CDMA
NBSS15.0
PCU_Initiate dSessionRel easePacketS essionDrop New OM in release 12.1 PCU_Initiate dSessionRel easePDSN_ Reject New OM in release 12.1 PCU_Initiate dSessionRel easeOther New OM in release 12.1 TotalRegistra tionRequest MsgSent New OM in release 12.1
This OM is pegged against a PDSN when PCU drops R-P session due to PCU lock or PDSN deleted actions.
This OM is pegged against a PDSN when PDSN sends RegistrationResPonse (RRP) with a failure code. This OM is also pegged when Registration Request retries exhausted.
20
This OM is pegged against a PDSN when PCU releases packet session for reasons other than individual pegging reasons captured by PCU_InitiatedSessionRelease** (seq # 16 to 20) OMs in this OM group. This OM is pegged against a PDSN every time a registration request message is sent to the PDSN after R-P session setup or handoff is completed This OM is not pegged for RRQ sent for session setup, handoff, session release (i.e. RRQ with lifetime 0) and RRQ retransmissions. This OM is pegged when RRQ is sent for session refresh or for transmitting accounting records during Dormant to Active and Active to Dormant transitions. This OM is pegged against a PDSN every time a registration request message is resent to the PDSN. The registration request messages include Refresh and Release Registration ReQuests (RRQ). The registration request is sent again when the PCU timesout waiting for the registration response message.
sheet 5 of 7
21
22
TotalRegistra tionRequest Retries New OM in release 12.1
23
411-2133-525
Standard
06.12
April 2008
TotalRegistra tionRequest RejectReaso nOther New OM in release 12.1 TotalRegistra tionRequest RejectReaso nIdMismatch New OM in release 12.1 TotalRegistra tionRequest RejectReaso nInsufficient Resources New OM in release 12.1 TotalRegistra tionRequest RejectReaso nMobileAuth Failure New OM in release 12.1 TotalRegistra tionRequest RejectReaso nPDSN_Not Responding New OM in release 12.1
This OM is pegged against a PDSN every time a registration request message is rejected by the PDSN for all reasons (not captured by the reason OMs) provided by PDSN after R-P session setup or handoff is complete (i.e RRQ sent for setup and handoff are not included). This OM is pegged against a PDSN every time a registration request message is rejected by the PDSN for ID Mismatch reason after R-P session setup or handoff is complete (i.e RRQ sent for setup and handoff are not included).
25
This OM is pegged against a PDSN every time a registration request message is rejected by the PDSN due to Insufficient Resources after R-P session setup or handoff is complete (i.e RRQ sent for setup and handoff are not included).
26
This OM is pegged against a PDSN every time a registration request message is rejected by the PDSN due to Mobile Authentication failure after R-P session setup or handoff is complete (i.e RRQ sent for setup and handoff are not included).
27
This OM is pegged against a PDSN every time when PDSN does not send response to a registration request message after session setup or handoff is complete (i.e RRQ sent for setup and handoff are not included).
28
sheet 6 of 7
CDMA
NBSS15.0
TotalSignalin gMsgReceiv ed New OM in release 12.1
This OM is pegged against a PDSN for each signaling message (RRP, or RUPD- Registration UPDate) received from that PDSN. This OM is not pegged when unroutable signaling messages (i.e. messages with unrecognized or erroneous RPSession Id) and unknown message types are received.
sheet 7 of 7
The following table shows a list of BSC OMs for the RP session data OM group.
List of BSC OMsRP session data OM group Register Description Sequence number (if applicable) OM group ID is 23 Reference chapter
RP Session Data OM group RPTotalOuto fSequenceP acketsReceiv ed New OM in release 12.1 RPTotalUnrel iableBytesTr ansmitted New OM in release 12.1
This OM group counts the Unreliable Bytes Transmitted and Received by the PCU or PCF on a per IP (PDSN) Basis. These OMs are pegged on EBSC only. This OM is pegged for all out of sequence GRE packets received over R-P link in the forward direction and dropped by the PCU. All the packets having lower than expected sequence number are dropped by the PCU. This OM provides good information regarding link performance between PCU and PDSN, Congestion on the link, as well as router issues. This OM provides the cumulative number of bytes the R-P sessions in the PCU transmitted to the PDSN. This OM is pegged per PDSN basis.
1xRTT packet data performance OM descriptions (page -1)
1xRTT packet data performance OM descriptions (page -1)
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsRP session data OM group (continued) Register Description
Reference chapter 1xRTT packet data performance OM descriptions (page -1)
RPTotalUnrel iableBytesRe ceived New OM in release 12.1
This OM provides the cumulative number of bytes the R-P sessions in the PCU received from the PDSN. This OM is pegged per PDSN basis.
The following table shows a list of the BSC OMs for the PCU manager OM group.
List of BSC OMsPCU manager OM group Register Description Sequence number (if applicable) OM group ID is 24 Reference chapter Call setup performance (page 2-1) Call setup performance (page 2-1)
PCU Manager OM group DormantToA ctiveHandoff s New OM in release 12.1 DormantHan doffRequests New OM in release 12.1
This OM group provides information on PCU Allocation Requests, Failure and Successes per PCU manager. These OMs are Pegged at the EBSC only. This counts number of dormant to active transitions for which different PCU had to be assigned because original PCU was too busy or no longer available.
This OM counts number of dormant handoffs. This OM is pegged when the dormant handoff message is received from MSC CAU.
sheet 1 of 3
CDMA
NBSS15.0
22-88 BSC OM descriptions Nortel Networks List of BSC OMsPCU manager OM group (continued) Register Description
PCU_AllocR equests New OM in release 12.1
This OM counts total PCU allocation requests received by the PCU manager, that is, requests for a new dormant session or a transition to an active session on a PCU. This OM is pegged on Null to Active transition Dormant to Active transition Active packet data hard handoff Dormant handoff
PCU_AllocFa ilures New OM in release 12.1 PCU_AllocS uccessful New OM in release 12.1 IMSI_TableF ull New OM in release 12.1 PCUM_Total RSDB_Recei ved New OM in release 14.0 PCUM_Total RSDB_Forw arded New OM in release 14.0
This OM counts number of PCU allocation failures due to IMSI table full or no PCU is available.
This OM counts number of PCU allocation requests fulfilled successfully.
This OM counts number of PCU allocation failures due to the IMSI table being full (these are a subset of the failures captured by PCU_AllocFailures OM). It means that there is no space left in the IMSI table to add entry for the session being setup. This OM is pegged when a R-SDB is received at the PCU-M from the CAU/ESEL/ACP.
Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
This OM is pegged when a R-SDB is sent by the PCU-M to the PCU (PCUFP).
sheet 2 of 3
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsPCU manager OM group (continued) Register Description
PCUM_Total RSDB_Drop ped New OM in release 14.0
This OM is pegged when a R-SDB is not sent by the PCU-M to the PCU (PCUFP).
sheet 3 of 3
The following table shows a list of the BSC OMs for the CPU usage OM group.
List of BSC OMsCPU usage OM group Register Description Sequence number (if applicable) OM group ID is 19 Reference chapter
CPU Usage OM group Modified in 14.0 release CPU_UsageI ndex_1 CPU_UsageI ndex_2 CPU_UsageI ndex_3 CPU_UsageI ndex_4 CPU_UsageI ndex_5
This OM group consists of OMs related to CPU Usage. These OMs are Pegged at the EBSC, and are reported for the CAC, ACP, and PCU nodes on the CNFP, DSFP and PCUFP cards. These OMs are not configurable through CEMS and are always ON. The number of times the CPU Usage in a monitoring period is less than 30% The number of times the CPU Usage in a monitoring period is greater than 30% and less than equal to 40%. The number of times the CPU Usage in a monitoring period is greater than 40% and less than equal to 50%. The number of times the CPU Usage in a monitoring period is greater than 50% and less than equal to 60%. The number of times the CPU Usage in a monitoring period is greater than 60% and less than equal to 70%
1 2
CDMA
NBSS15.0
22-90 BSC OM descriptions Nortel Networks List of BSC OMsCPU usage OM group (continued) Register Description
Reference chapter
CPU_UsageI ndex_6 CPU_UsageI ndex_7 CPU_Usage ExceededThr eshold
The number of times the CPU Usage in a monitoring period is greater than 70% and less than equal to 80% The number of times the CPU Usage in a monitoring period is greater than 80% The number of times the CPU Usage has exceeded a pre-defined CPU threshold (the CPUOverloadThreshold attribute) for a certain monitoring time-period. If the CPU Usage becomes equal to or exceeds this value an Alarm will be generated, and overload controls are activated. Once the CPU Usage drops 10 points below this value for two consecutive monitoring periods (two 4 second periods), the Alarm will be cleared and the overload controls will be discontinued.
7 8
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the BSC OMs for the RP session L2TP OM group.
List of BSC OMsRP session L2TP OM group Register Description Sequence number (if applicable) OM group ID is 14 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
RP Session L2TP OM group
This OM group consists of OMs to capture L2TP reliable packets sent, retransmitted, received, tunnel failures per PDSN. Also deals with Unreliable bytes transmitted and received per PDSN. These OMs are Pegged only at the BSC and not at the EBSC This OM provides the number of ACKs received as a result of reliable packets being sent to any given PDSN. Note: This OM applies to L2TP tunnel control and R-P session establishment messages, measuring the number of reliable packets that are sent successfully. Note: This OM has been converted to a 32-bit register as of release 12.0 and hence there is no need for the Overflow OM.
ReliablePack etSentSucce ss
ReliablePack etReTransmit ted
This OM provides the number of reliable packets that had to be retransmitted because no ACK was received. Note: This OM applies to L2TP tunnel control and R-P session establishment messages, measuring the number of reliable packets that needed to be retransmitted. Note: This OM has been converted to a 32-bit register as of release 12.0 and hence there is no need for the Overflow OM.
sheet 1 of 6
CDMA
NBSS15.0
22-92 BSC OM descriptions Nortel Networks List of BSC OMsRP session L2TP OM group (continued) Register Description
ReliablePack etReceived
This OM provides the number of messages the PCU received with reliable delivery acknowledgement requested. Note: This OM applies to L2TP tunnel control and R-P session establishment messages, measuring the number of reliable packets that are received. Note: This OM has been converted to a 32-bit register as of release 12.0 and hence there is no need for the Overflow OM.
NumberOfTu nnelFailures
This OM provides the number of times a L2TP tunnel was torn down due to failure of reliable packet transmission. This OM provides the cumulative number of bytes each R-P session in the PCU transmitted to PDSN. Note: This OM, together with TotalUnreliableBytesReceived, provides the operator with a picture of the total data throughput for a given R-P session during the OM reporting period. Note: This OM has been converted to a 32-bit register as of release 12.0 and hence there is no need for the Overflow OM.
TotalUnreliab leBytesTrans mitted
TotalUnreliab leBytesRecei ved
This OM provides the cumulative number of bytes each session in the PCU received from PDSN. Note: This OM, together with TotalUnreliableBytesTransmitted provides the operator with a picture of the total data throughput for a given R-P session during the OM reporting period. Note: This OM has been converted to a 32-bit register as of release 12.0 and hence there is no need for the Overflow OM.
sheet 2 of 6
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsRP session L2TP OM group (continued) Register Description
Reference chapter
TunnelSetup FailuresReas onUnexpecte d New OM in 13.0 release TunnelSetup FailuresReas onReserved New OM in 13.0 release TunnelSetup FailuresReas onVendorErr or New OM in 13.0 release TunnelSetup FailuresReas onBadProtoc olVersion New OM in 13.0 release TunnelSetup FailuresReas onRequester Shutdown New OM in 13.0 release
This OM counts the number of L2TP tunnel setup failures with an unexpected result code from the PDSN per PDSN IP address.
This OM counts the number of L2TP tunnel setup failures with a reserved result code from the PDSN per PDSN IP address.
This OM counts the number of L2TP tunnel setup failures classified as general errors indicating vendor-specific error on the PDSN per PDSN IP address.
This OM counts the number of L2TP tunnel setup failures due to unsupported protocol version on the PDSN per PDSN IP address.
10
This OM counts the number of L2TP tunnel setup failures due to requestor being shut down on the PDSN per PDSN IP address.
11
sheet 3 of 6
CDMA
NBSS15.0
Reference chapter
TunnelSetup FailuresReas onSystemOv erload New OM in 13.0 release RP_Session SetupAttemp ts New OM in 13.0 release RP_Session SetupSucces ses New OM in 13.0 release RP_Session SetupReject ReasonGenE rr New OM in 13.0 release RP_Session SetupReject ReasonNoCa rrier New OM in 13.0 release
This OM counts the number of L2TP tunnel setup failures due to overload conditions on the PDSN per PDSN IP address.
This OM measures number of Session Setup Attempts per PDSN. This OM shall be pegged when a session setup is attempted for the first time. It shall not be pegged during handoffs. So if a PDSN rejects a setup attempt and another PDSN is tried to setup the call, this OM shall be pegged only on the first PDSN and not the second. This OM measures number of PDSN Session Setup Successes on each PDSN. This OM shall be pegged only when a session is successfully setup, and only against the PDSN on which the session was successfully setup. It shall not be pegged during the handoffs. This OM measures number of rejections due to General Error per PDSN. This OM shall be pegged whenever CDN message is received from the PDSN indicating General Error (result code = 2, 6, 10, 11). It shall not be pegged for handoffs.
13
14
15
This OM measures number of rejections due to No Carrier per PDSN. This OM shall be pegged whenever CDN message is received from the PDSN indicating No Carrier (result code = 1, 7, 8, 9). It shall not be pegged for handoffs.
16
sheet 4 of 6
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsRP session L2TP OM group (continued) Register Description
RP_Session SetupReject ReasonAdmi nReason New OM in 13.0 release RP_Session SetupReject ReasonNoTe mpRsrcs New OM in 13.0 release RP_Session SetupReject ReasonNoPe rmRsrcs New OM in 13.0 release RP_Session SetupReject ReasonSysO verload New OM in 13.0 release RP_Session SetupReject ReasonOther New OM in 13.0 release
This OM measures number of rejections due to Administrative Reason per PDSN. This OM shall be pegged whenever CDN message is received from the PDSN indicating Administrative Reason (result code = 3). It shall not be pegged for handoffs.
This OM measures number of rejections due to lack of temporary facilities per PDSN. This OM shall be pegged whenever CDN message is received from the PDSN indicating lack of temporary facilities (result code = 4). It shall not be pegged for handoffs.
18
This OM measures number of rejections due to lack of permanent facilities per PDSN. This OM shall be pegged whenever CDN message is received from the PDSN indicating lack of permanent facilities (result code = 4). It shall not be pegged for handoffs.
19
This OM measures number of rejections due to system overload per PDSN. This OM shall be pegged whenever CDN message is received from the PDSN indicating system overload (result code = 12). It shall not be pegged for handoffs.
20
This OM measures number of rejections due to reasons other than specified per PDSN. This OM shall be pegged whenever CDN message is received from the PDSN indicating rejections due to reasons other than specified for which the OMs are already pegged. It shall not be pegged for handoffs.
sheet 5 of 6
21
CDMA
NBSS15.0
RP_Session SetupReject ReasonNoP DSNRsp New OM in 13.0 release
This OM measures number of Instances of no response from PDSN for session setup request per PDSN. This OM shall be pegged whenever PCU times out on Session Setup Response from PDSN (no ICRP or CDN message received). It shall not be pegged for handoffs.
sheet 6 of 6
The following table shows a list of the BSC OMs for the RFCH gating OM group.
List of BSC OMsRFCH gating OM group Register Description Sequence number (if applicable) OM group ID is 27 Reference chapter Call resource allocation and management OMs (page 1)
RFCH Gating OM group
This OM group consists of OMs that provide information on how many mobile users in a CarrierSector were allowed to gate the transmission of eighth rate frames on the reverse fundamental channel with a 50% duty cycle. The OMs are pegged on a per-EBID basis on both the BSC and EBSC, though the pegs will be zero for the CPDS as these OMs apply only to voice calls. This OM is pegged for link setups for which gating is requested by the mobile in Origination or Page Response messages. It is pegged only when resources are available for the call (i.e. it will not be blocked). This OM is pegged whenever a call is setup with 1/8 rate FCH gating enabled.
RFCHGating Requests New OM in release 12.1 RFCHGating GrantedRequ ests New OM in release 12.1
Call resource allocation and management OMs (page 1) Call resource allocation and management OMs (page 1)
sheet 1 of 2
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsRFCH gating OM group (continued) Register Description
Reference chapter Call resource allocation and management OMs (page 1) Call resource allocation and management OMs (page 1) Call resource allocation and management OMs (page 1)
RFCHGating DeniedRequ ests New OM in release 12.1 RFCHGating EnabledHan doffs New OM in release 12.1 RFCHGating Deactivations New OM in release 12.1
This OM is pegged whenever the BTS denies a 1/8 rate RFCH gating request from the BSC due to the forward power in use being above the ReverseFCHGatingCapacityThreshold set in the AdvancedSector MO of the BTS. This OM is pegged when a soft handoff link is added for a call that has 1/8 rate FCH gating enabled. Gating is maintained regardless of the forward power level in the sector, i.e. ReverseFCHGatingCapacityThreshold is not checked for soft/softer handoff.This peg is made for all of the links added. This OM is pegged whenever 1/8 rate FCH gating is deactivated on soft handoff for a call in progress due to differences in values in reverse power control delay values between 2 BTSs. Also pegged for soft handoff to a BTS that does not support gating. Each EBID that has gating deactivated is pegged. Gating is deactivated after the resources are setup successfully (i.e. RFCHGatingEnabledHandoffs will be pegged first, then RFCHGatingDeactivations will be pegged).
sheet 2 of 2
CDMA
NBSS15.0
The following table shows a list of the BSC OMs for the reference sector frame count OM group.
List of BSC OMsreference sector frame count OM group Register Description Sequence number (if applicable) OM group ID is 28 Reference chapter Call resource allocation and management OMs (page 1)
Reference Sector Frame Count OM group Modified group in 15.0 release
This OM group consists of OMs that count the total forward frames sent to the mobile on the FCH and SCH. The frame counts are pegged against the reference sector where reference is defined as the strongest pilot in the active set reported in the most recent PSMM / PPSMM. The OMs get pegged upon the changing of reference sector or call release. If the reference sector changes during the life of a call, then the subsequent frames are pegged against the new reference sector. Note: These are Multi-ID pegging type OMs. Granularity is provided on per EBID, per RC and per SO basis. The OMs in this group start pegging after the mobile acknowledges the base station acknowledgement order. These OM counts include the NULL traffic frames sent from the selector element to the mobile during call setup. The OMs in this group peg only for the following service options: 13K voice, EVRC, EVRCB, SMS, asynchronous data services, group 3 fax, analog fax, Markov, OTAPA, Loopback, Packet Data, Location Services and CSD (separate for each CSD type)
ReferenceSe ctorFrameCo unt_FFCH
This OM is the total number of forward fundamental channel frames sent to the mobiles in a carrier-sector for a specific radio configuration and service option.
Call resource allocation and management OMs (page 1) Call resource allocation and management OMs (page 1)
ReferenceSe ctorFrameCo unt_FSCH
This OM is the total number of forward supplemental channel frames sent to the mobiles in a carrier-sector for a specific radio configuration and service option.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the BSC OMs for the reference sector FER OM group.
List of BSC OMsreference sector FER OM group Register Description Sequence number (if applicable) OM group ID is 29 Reference chapter RF performance (page 17-1)
Reference Sector FER OM group New OM group in 13.0 release
This OM group consists of OMs that count the total number of bad frames and total frames that are received on the forward and reverse FCH and SCH. The frame counts are maintained only for the reference sector where reference is defined as the strongest pilot in the active set reported in the most recent PSMM / PPSMM. The forward frame counts are updated based on the information in the PMRM. The reverse link OMs are pegged after the reverse link frame selection process at the BSC. The OMs get pegged upon the receipt of a PSMM / PPSMM. If the reference sector changes during the life of a call, then the subsequent frames are counted for the new reference sector. Note: These are Multi-ID pegging type OMs. Granularity is provided per EBID per RC. This feature differentiates between non-packet data (voice, CSD, markov, etc.) and packet data service groups. For RC3, RC4 and RC5 PMRM reporting, PWR_THRESH_ENABLE bit located in the SectorSystemParameters attribute of the AdvancedSector MO has to be set. For SCH frame count reporting in the PMRM, OMCollection bit located in the OMCollectionControl attribute of the SBSC MO (DSInterface MO for EBSC) has to be set.
FFCH_BadN onDataFram es FFCH_Total NonDataFra mes
This OM is the total number of bad forward fundamental channel frames reported by the mobiles, for all non-packet data calls in a carriersector for a specific radio configuration. This OM is the total number of forward fundamental channel frames reported by the mobiles, for all nonpacket data calls in a carrier-sector for a specific radio configuration.
sheet 1 of 4
RF performance (page 17-1) RF performance (page 17-1)
CDMA
NBSS15.0
22-100 BSC OM descriptions Nortel Networks List of BSC OMsreference sector FER OM group (continued) Register Description
Reference chapter RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1)
RFCH_BadN onDataFram es RFCH_Total NonDataFra mes FFCH_BadD ataFrames
This OM is the total number of bad reverse fundamental channel frames, for all non-packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of reverse fundamental channel frames, for all non-packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of bad forward fundamental channel frames reported by the mobiles, for all packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of forward fundamental channel frames reported by the mobiles, for all packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of bad reverse fundamental channel frames, for all packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of reverse fundamental channel frames, for all packet data calls in a carriersector for a specific radio configuration. This OM is the total number of bad forward supplemental channel frames reported by the mobiles, for all 2X packet data calls in a carriersector for a specific radio configuration. This OM is the total number of bad forward supplemental channel frames reported by the mobiles, for all 4X packet data calls in a carriersector for a specific radio configuration. This OM is the total number of bad forward supplemental channel frames reported by the mobiles, for all 8X packet data calls in a carriersector for a specific radio configuration.
sheet 2 of 4
FFCH_Total DataFrames
RFCH_BadD ataFrames RFCH_Total DataFrames FSCH_BadFr ames_2X
FSCH_BadFr ames_4X
10
FSCH_BadFr ames_8X
11
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsreference sector FER OM group (continued) Register Description
Reference chapter RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1)
FSCH_BadFr ames_16X
This OM is the total number of bad forward supplemental channel frames reported by the mobiles, for all 16X packet data calls in a carriersector for a specific radio configuration. This OM is the total number of forward supplemental channel frames reported by the mobiles, for all 2X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of forward supplemental channel frames reported by the mobiles, for all 4X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of forward supplemental channel frames reported by the mobiles, for all 8X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of forward supplemental channel frames reported by the mobiles, for all 16X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of bad reverse supplemental channel frames, for all 2X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of bad reverse supplemental channel frames, for all 4X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of bad reverse supplemental channel frames, for all 8X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of bad reverse supplemental channel frames, for all 16X packet data calls in a carrier-sector for a specific radio configuration.
sheet 3 of 4
FSCH_Total Frames_2X
13
14
15
16
RSCH_BadF rames_2X
17
RSCH_BadF rames_4X
18
RSCH_BadF rames_8X
19
RSCH_BadF rames_16X
20
CDMA
NBSS15.0
22-102 BSC OM descriptions Nortel Networks List of BSC OMsreference sector FER OM group (continued) Register Description
Reference chapter RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1) RF performance (page 17-1)
RSCH_Total Frames_2X RSCH_Total Frames_4X RSCH_Total Frames_8X RSCH_Total Frames_16X
This OM is the total number of reverse supplemental channel frames, for all 2X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of reverse supplemental channel frames, for all 4X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of reverse supplemental channel frames, for all 8X packet data calls in a carrier-sector for a specific radio configuration. This OM is the total number of reverse supplemental channel frames, for all 16X packet data calls in a carrier-sector for a specific radio configuration.
sheet 4 of 4
22
23
24
The following table shows a list of the BSC OM for the hard handoff trigger OM group.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMshard handoff trigger OM group Register Description Sequence number (if applicable) OM group ID is 30 Reference chapter Handoff performance (page 7-1)
Hard Handoff Trigger OM group New OM group in 13.0 release
This OM group consists of OMs (i.e. RTD_AboveRTDmin and RTD_DroppedBelowRTDmin) that are related to Signal Quality hard handoff trigger for EC cell and OMs (i.e. RTDdelayTimerHHO_Attempts, RTDdelayTimerHHO_Triggers, RTDdelayTimerHHO_Blocks) that are related to RTD delay timer for EC and Border cells. These OMs are pegged on per EBID basis.
RTD_Above RTDmin
This OM is pegged when the measured RTD in the received RTD report becomes greater than the datafilled value of RTDmin. This OM is pegged only against the reference sector (sector with smallest RTD value) where the call is going on. Note: reference sector is determined by the smallest RTD value in each RTD report. In case that the current reference sector (determined by the current RTD report) becomes different than the previous reference sector (determined by previous RTD report) and the measured RTD is greater than the current reference sectors datafilled value of RTDmin, this OM is pegged against the current reference sector. This OM is only pegged for EC cell for IS95B+ mobile calls. This OM is pegged when the measured RTD in the received RTD report becomes less than the datafilled value of RTDmin. This OM is pegged only against the reference sector (sector with smallest RTD) where the call is currently going on. Note: reference sector is determined by the smallest RTD value in each RTD report. This OM is only pegged for EC cell for IS95B+ mobile calls.
sheet 1 of 2
RTD_Droppe dBelowRTD min
CDMA
NBSS15.0
22-104 BSC OM descriptions Nortel Networks List of BSC OMshard handoff trigger OM group (continued) Register Description
RTDdelaytim erHHO_Atte mpts
This OM is pegged when the call came to this target sector after a successful hard handoff and the RTD report shows that RTD hard handoff trigger conditions or EC hard handoff trigger conditions are met and RTD delay timer has been started. This OM is pegged only against the reference sector (sector with smallest RTD) where the call is going on. This OM is only pegged for EC cell or Border cell for all call types combined. This OM is pegged when the call came to this target sector after a successful hard handoff and the RTD report shows that RTD hard handoff trigger conditions or EC cell hard handoff trigger conditions are met and RTD delay timer has expired. Thus the BSC will send hard handoff request to MSC. This OM is pegged against the reference sector (sector with smallest RTD) where the call is going on. This OM is only pegged for EC cell or Border cell for all call types combined. This OM is pegged when the call came to this target sector after a successful hard handoff and the RTD report shows that RTD hard handoff trigger conditions or EC hard handoff trigger conditions are met but RTD delay timer has not expired. Thus no hard handoff is possible due to unexpired delay timer. This OM is pegged against the reference sector (sector with smallest RTD) where the call is going on. This OM is only pegged for EC cell or Border cell for all call types combined.
sheet 2 of 2
RTDdelaytim erHHO_Trigg ers
RTDdelaytim erHHO_Bloc ks
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the BSC OMs for the pegging limitation exceeded OM group.
List of BSC OMspegging limitation exceeded OM group Register Description Sequence number (if applicable) OM group ID is 31 Reference chapter
Pegging Limitation Exceeded OM group New OM group in 13.0 release ReferenceSe ctorFrameCo untgroupPeg gingAttempts ReferenceSe ctorFrameCo untgroupPeg gingFailures FrameErrorR ategroupPeg gingAttempts FrameErrorR ategroupPeg gingFailures SCH_Primar yRadioLinkS etupgroupPe ggingAttempt s SCH_Primar yRadioLinkS etupgroupPe ggingFailures SCH_Handof fRadioLinkSe tupgroupPeg gingAttempts
This OM group consists of OMs to count the number of attempts and failures to peg the Reference Sector Frame Count OM group and Reference Sector FER OM group for a specific EBID
This OM is the total number of attempts to peg the reference sector frame count OM group for a specific EBID. This OM is the total number of failures to peg the reference sector frame count OM group for a specific EBID. This OM is the total number of attempts to peg the reference sector FER OM group for a specific EBID. This OM is the total number of failures to peg the reference sector FER OM group for a specific EBID. This OM is the total number of attempts to peg the SCH Primary Radio Link Setup OM group for a specific EBID.
This OM is the total number of failures to peg the SCH Primary Radio Link Setup OM group for a specific EBID. This OM is the total number of attempts to peg the SCH Handoff Radio Link Setup OM group for a specific EBID.
CDMA
NBSS15.0
List of BSC OMspegging limitation exceeded OM group (continued) Register Description Sequence number (if applicable) 8 Reference chapter
SCH_Handof fRadioLinkSe tupgroupPeg gingFailures RLP_DataTh roughputgrou pPeggingAtt empts RLP_DataTh roughputgrou pPeggingFail ures
This OM is the total number of failures to peg the SCH Handoff Radio Link Setup OM group for a specific EBID. This OM is the total number of attempts to peg the RLP Data Throughput OM group for a specific EBID.
This OM is the total number of failures to peg the RLP Data Throughput OM group for a specific EBID.
10
The following table shows a list of the BSC OMs for the PCU Queue Occupancy OM group.
List of BSC OMsPCU Queue Occupancy OM group Register Description Sequence number (if applicable) OM group ID is 72 Reference chapter
PCU Queue Occupancy OM group New OM group in 14.0 release
This OM group contains OMs that provide the queue occupancy for the DCR (Dedicated Common Router, data destined for the mobile) and RR (Reverse Router, data destined for the network) queues on the PCU. The OMs are pegged per PCU. For the DormantDCR_QueueAtD2A_* histogram OMs, the queue depth is measured when the session transitions from Dormant to Active.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsPCU Queue Occupancy OM group (continued) Register Description Sequence number (if applicable) 1 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
DormantDCR _QueueAtD2 A_10 DormantDCR _QueueAtD2 A_20 DormantDCR _QueueAtD2 A_30 DormantDCR _QueueAtD2 A_40 DormantDCR _QueueAtD2 A_50 DormantDCR _QueueAtD2 A_60 DormantDCR _QueueAtD2 A_70 DormantDCR _QueueAtD2 A_80 DormantDCR _QueueAtD2 A_90
This OM provides the number of times the percentage DCRQ queue depth is 0<=x<10 percent.
This OM provides the number of times the percentage DCRQ queue depth is 10<=x<20 percent. This OM provides the number of times the percentage DCRQ queue depth is 20<=x<30 percent. This OM provides the number of times the percentage DCRQ queue depth is 30<=x<40 percent. This OM provides the number of times the percentage DCRQ queue depth is 40<=x<50 percent. This OM provides the number of times the percentage DCRQ queue depth is 50<=x<60 percent. This OM provides the number of times the percentage DCRQ queue depth is 60<=x<70 percent. This OM provides the number of times the percentage DCRQ queue depth is 70<=x<80 percent. This OM provides the number of times the percentage DCRQ queue depth is 80<=x<90 percent.
CDMA
NBSS15.0
List of BSC OMsPCU Queue Occupancy OM group (continued) Register Description Sequence number (if applicable) 10 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
DormantDCR _QueueAtD2 A_100 PeakActiveD CR_QueueD epth AvgActiveDC R_QueueDe pth PeakActiveR R_QueueDe pth AvgActiveRR _QueueDept h
This OM provides the number of times the percentage DCRQ queue depth is 90<=x<=100 percent. This OM provides the peak queue depth in percentage among all DCRQs measured in the forward direction during the OM reporting period. This OM provides the average queue depth in percentage over all DCRQs measured in the forward direction during the OM reporting period. This OM provides the peak queue depth in percentage among all RRQs measured in the reverse direction during the OM reporting period. This OM provides the average queue depth in percentage over all RRQs measured in the reverse direction during the OM reporting period.
11
12
13
14
The following table shows a list of the BSC OMs for the Selection and Distribution Unit Queue Occupancy OM group.
List of BSC OMsSelection and Distribution Unit Queue Occupancy OM group Register Description Sequence number (if applicable) OM group ID is 71 Reference chapter
SDU Queue Occupancy OM group New OM group in 14.0 release
This OM group consists of OMs that provide the queue occupancy for the RLPQ on the ESEL/ACP. The OMs are pegged per ESEL/ACP. For the FwdRLPQ_BurstRequestDepth_* histogram OMs, the bin represents the rolling average of the queue occupancy at the time burst allocation is requested.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsSelection and Distribution Unit Queue Occupancy OM group (continued) Register Description Sequence number (if applicable) 1 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
FwdRLPQ_B urstRequest Depth_1 FwdRLPQ_B urstRequest Depth_2 FwdRLPQ_B urstRequest Depth_3 FwdRLPQ_B urstRequest Depth_4 FwdRLPQ_B urstRequest Depth_5 FwdRLPQ_B urstRequest Depth_6 FwdRLPQ_B urstRequest Depth_7 FwdRLPQ_B urstRequest Depth_8 FwdRLPQ_B urstRequest Depth_9
This OM provides the number of times the RLPQ queue depth is 0<=x<200 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 200<=x<400 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 400<=x<600 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 600<=x<800 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 800<=x<1000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 1000<=x<1250 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 1250<=x<1500 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 1500<=x<1750 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 1750<=x<2000 bytes when a forward burst is requested.
CDMA
NBSS15.0
FwdRLPQ_B urstRequest Depth_10 FwdRLPQ_B urstRequest Depth_11 FwdRLPQ_B urstRequest Depth_12 FwdRLPQ_B urstRequest Depth_13 FwdRLPQ_B urstRequest Depth_14 FwdRLPQ_B urstRequest Depth_15 FwdRLPQ_B urstRequest Depth_16 FwdRLPQ_B urstRequest Depth_17 FwdRLPQ_B urstRequest Depth_18
This OM provides the number of times the RLPQ queue depth is 2000<=x<2250 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 2250<=x<2500 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 2500<=x<2750 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 2750<=x<3000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 3000<=x<3500 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 3500<=x<4000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 4000<=x<4500 bytes when a forward burst is requested This OM provides the number of times the RLPQ queue depth is 4500<=x<5000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 5000<=x<7500 bytes when a forward burst is requested.
11
12
13
14
15
16
17
18
411-2133-525
Standard
06.12
April 2008
Nortel Networks
FwdRLPQ_B urstRequest Depth_19 FwdRLPQ_B urstRequest Depth_20 FwdRLPQ_B urstRequest Depth_21 FwdRLPQ_B urstRequest Depth_22 FwdRLPQ_B urstRequest Depth_23 FwdRLPQ_B urstRequest Depth_24 FwdRLPQ_B urstRequest Depth_25 FwdRLPQ_S CH_BurstAv gDepth_2x FwdRLPQ_S CH_BurstAv gDepth_4x
This OM provides the number of times the RLPQ queue depth is 7500<=x<10,000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 10,000<=x<15,000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 15,000<=x<20,000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 20,000<=x<30,000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 30,000<=x<40,000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 40,000<=x<50,000 bytes when a forward burst is requested. This OM provides the number of times the RLPQ queue depth is 50,000<=x bytes when a forward burst is requested. This OM provides the average queue depth in percentage over all 2X bursts measured in the forward direction during the OM reporting period. This OM provides the average queue depth in percentage over all 4X bursts measured in the forward direction during the OM reporting period.
20
21
22
23
24
25
26
27
CDMA
NBSS15.0
FwdRLPQ_S CH_BurstAv gDepth_8x FwdRLPQ_S CH_BurstAv gDepth_16x RevRLPQ_S CH_BurstAv gDepth_2x RevRLPQ_S CH_BurstAv gDepth_4x RevRLPQ_S CH_BurstAv gDepth_8x RevRLPQ_S CH_BurstAv gDepth_16x FwdRLPQ_S CH_BurstPe akDepth_2x FwdRLPQ_S CH_BurstPe akDepth_4x FwdRLPQ_S CH_BurstPe akDepth_8x
This OM provides the average queue depth in percentage over all 8X bursts measured in the forward direction during the OM reporting period. This OM provides the average queue depth in percentage over all 16X bursts measured in the forward direction during the OM reporting period. This OM provides the average queue depth in percentage over all 2X bursts measured in the reverse direction during the OM reporting period. This OM provides the average queue depth in percentage over all 4X bursts measured in the reverse direction during the OM reporting period. This OM provides the average queue depth in percentage over all 8X bursts measured in the reverse direction during the OM reporting period. This OM provides the average queue depth in percentage over all 16X bursts measured in the reverse direction during the OM reporting period. This OM provides the peak queue depth in percentage of any given 2X burst measured in the forward direction during the OM reporting period. This OM provides the peak queue depth in percentage of any given 4X burst measured in the forward direction during the OM reporting period. This OM provides the peak queue depth in percentage of any given 8X burst measured in the forward direction during the OM reporting period.
29
30
31
32
33
34
35
36
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsSelection and Distribution Unit Queue Occupancy OM group (continued) Register Description Sequence number (if applicable) 37 Reference chapter 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1) 1xRTT packet data performance (page 3-1)
FwdRLPQ_S CH_BurstPe akDepth_16x RevRLPQ_S CH_BurstPe akDepth_2x RevRLPQ_S CH_BurstPe akDepth_4x RevRLPQ_S CH_BurstPe akDepth_8x RevRLPQ_S CH_BurstPe akDepth_16x
This OM provides the peak queue depth in percentage of any given16X burst measured in the forward direction during the OM reporting period. This OM provides the peak queue depth in percentage of any given 2X burst measured in the reverse direction during the OM reporting period. This OM provides the peak queue depth in percentage of any given 4X burst measured in the reverse direction during the OM reporting period. This OM provides the peak queue depth in percentage of any given 8X burst measured in the reverse direction during the OM reporting period. This OM provides the peak queue depth in percentage of any given 16X burst measured in the reverse direction during the OM reporting period.
38
39
40
41
List of BSC OMs -- PLCMPerformance OM group Register Description Sequence number (if applicable) OM group ID is 68 Reference chapter Call setup performance (page 2-1)
PLCMPerfor mance OM group New OM group in 14.0 release PLCM_CallS etupAttempts PseudoESN
This OM group consists of OMs that peg on a system level basis at the DSFP-V/ESEL. These OMs capture the number of Call attempts, successes, failures and drops on a per PLCM basis
This OM is pegged when BSC sends a radio link resource indicationmessage to the CAU (radio link setup response in the case of Hard Handoff) indicating that a pESN based PLCM will be used during call setup. This means that the MEID mobile should use pESN based PLCM on the traffic channel.
CDMA
NBSS15.0
22-114 BSC OM descriptions Nortel Networks PLCM_CallS etupAttempts BS_Assigned
Copyright 2008 Nortel Networks 2 Call setup performance (page 2-1)
This OM is pegged when BSC sends a radio link resource indicationmessage to the CAU (radio link setup response in the case of Hard Handoff) indicating that a BTS assigned PLCM will be used during call setup. This means that the MEID mobile should use BTS assigned PLCM on the traffic channel. This OM is pegged when BSC sends a radio link resource indicationmessage to the CAU (radio link setup response in the case of Hard Handoff) indicating that a MEID based PLCM will be used during call setup. This means that the MEID mobile should use MEID based PLCM on the traffic channel. This OM is pegged when BSC sends a service connect response message to the CAU indicating that a MEID mobile successfully setup the call on pESN based PLCM. The existing CAU$SUCC is pegged along with this OM. $= O,T,H
PLCM_CallS etupAttempts MEID
PLCM_CallS etupSuccess esPseudoES N
PLCM_CallS etupSuccess esBS_Assign ed
This OM is pegged when BSC sends a service connect response message to the CAU indicating that a MEID mobile successfully setup the call on BTS assigned PLCM. The existing CAU$SUCC is pegged along with this OM. $= O,T,H
PLCM_CallS etupSuccess esMEID
This OM is pegged when BSC sends a service connect response message to the CAU indicating that a MEID mobile successfully setup the call on MEID based PLCM. The existing CAU$SUCC is pegged along with this OM. $= O,T,H
PLCM_CallS etupFailures PseudoESN
This OM is pegged when a call setup fails due to RF related reasons and a response from a request made to the BTS to check for a pESN PLCM type collision, indicates there is a possible collision. Collision means that the pESN PLCM used for call setup is already in use by a different mobile. The existing CAUERLFL/CAUHRLFL is pegged along with this OM.
411-2133-525
Standard
06.12
April 2008
Nortel Networks PLCM_CallS etupFailures BS_Assigned
BSC OM descriptions 22-115 Copyright 2008 Nortel Networks This OM is pegged when a call setup fails due to RF related reasons and a response from a request made to the BTS to check for a BTS assigned PLCM type collision, indicates there is a possible collision. Collision means that the BTS assigned PLCM used for call setup is already in use by a different mobile. The existing CAUERLFL/CAUHRLFL is pegged along with this OM. 8 Call setup performance (page 2-1)
PLCM_CallS etupFailures MEID
This OM is pegged when a call setup fails due to RF related reasons and a response from a request made to the BTS to check for a MEID PLCM type collision, indicates there is a possible collision. Collision means that the MEID PLCM used for call setup is already in use by a different mobile. The existing CAUERLFL/CAUHRLFL is pegged along with this OM.
PLCM_CallD ropsPseudoE SN
This OM is pegged after successful call setup when the call fails due to RF related reasons and a response from a request made to the BTS to check for a pESN PLCM type collision, indicates there is a possible collision. Collision means that the pESN PLCM used during the call is already in use by a different mobile. The existing CAUDROPR OM is pegged along with this OM.
10
PLCM_CallD ropsBS_Assi gned
This OM is pegged after successful call setup when the call fails due to RF related reasons and a response from a request made to the BTS to check for a BTS Assigned PLCM type collision, indicates there is a possible collision. Collision means that the BTS Assigned PLCM used during the call is already in use by a different mobile. The existing CAUDROPR OM is pegged along with this OM.
11
CDMA
NBSS15.0
22-116 BSC OM descriptions Nortel Networks PLCM_CallD ropsMEID
Copyright 2008 Nortel Networks 12 Call setup performance (page 2-1)
This OM is pegged after successful call setup when the call fails due to RF related reasons and a response from a request made to the BTS to check for a MEID PLCM type collision, indicates there is a possible collision. Collision means that the MEID PLCM used during the call is already in use by a different mobile. The existing CAUDROPR OM is pegged along with this OM.
The following table shows a list of the CNFP OMs for the call resource request processing OM group.
List of BSC OMscall resource request processing OM group Register Description Sequence number (if applicable) OM group ID is 33 Reference chapter Call resource allocation and management (page 16-1)
Call Resource Request Processing OM group New OM group in 14.0 release AllocationRe questReceiv ed
This OM group consists of OMs that are pegged at the NRM and it provides an indication of the total resource allocation request traffic received by the NRM. For resource allocation requests that are actually accepted by the NRM and processed further, refer to the Call Resource Setup OM group. This OM is pegged when the NRM receives a resource allocation request message from CAU.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMscall resource request processing OM group (continued) Register Description Sequence number (if applicable) 2 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
AllocationRe questRejecte dDueToOverl oad AllocationRe questDenied
This OM is pegged when the NRM rejects the resource allocation request message from the CAU due to NRM CPU overload condition by responding with a reject message to the CAU. This OM is pegged when the NRM denies the incoming resource allocation request from the CAU. Possible reasons for request denial are: CAU provides an empty service option list, invalid service option, NRM is administratively locked or message cannot be decoded. In that case, the NRM does not accept the request for further processing, and if not locked, sends a resource allocation response message to the CAU indicating the reason for denial.
The following table shows a list of the CNFP OMs for the call resource setup OM group.
List of BSC OMscall resource setup OM group Register Description Sequence number (if applicable) OM group ID is 34 Reference chapter Call resource allocation and management (page 16-1)
Call Resource Setup OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the NRM and it provides an indication of the resource allocation request traffic processed by the NRM on a per Service group basis. There are three Service groups: voice, packetData and other. The voice Service group pegs for voice and CSD services; The packetData Service group pegs for the Packet PPP service; The other Service group pegs for all other services such as SMS, OTAPA, Location Services, Markov and Loopback.
CDMA
NBSS15.0
22-118 BSC OM descriptions Nortel Networks List of BSC OMscall resource setup OM group (continued) Register Description
AllocationRe questAccept ed
This OM is pegged when the NRM accepts the resource allocation request message from the CAU and continues to process that request. Note that NRM may reject or deny the CAUs resource allocation request and hence not accept all incoming requests. Refer to Call Resource Request Processing OM group.
AllocationRe questResour ceUnavailabl e
This OM is pegged when the NRM has determined that requested service option resources are unavailable in the entire system. The NRM consults its own internal resource availability status information to determine this condition. In this case, call setup is blocked. This OM is pegged when the NRM is successful in allocating resources for the incoming resource allocation request from the CAU.
Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
AllocationRe questSucces ses
AllocationRe questFailures
This OM is pegged when the NRM determines that resources are available to satisfy the CAUs resource allocation request, but fails to allocate them within the system for that request. In this case, call setup is blocked. These resource allocation failures are typically due to error conditions such as: internal failures, timeouts, mismatch in resource availability status information between NRM and platform resource managers, etc.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the BSC OMs for the Resource Availability Check OM group.
List of BSC OMsResource Availability Check OM group Register Description Sequence number (if applicable) OM group ID is 47 Reference chapter Call resource allocation and management (page 16-1)
Resource Availability Check OM group
This OM group consists of OMs to track the number of times SBS or CSVS/CPDS resources are unavailable for resource allocation for a particular service type. (Pegging granularity of OMs from this group is on a per service basis) OMs from this group are pegged by NRM during Resource Availability Check Phase after NRM accepts the Resource allocation request and before the Platform Selection Phase starts. For more information about the NRM resource allocation call flow diagram, see Call flow diagrams with OMs (page 20-1). The Service Types are: packetPpp, smsRateSet1, markov, msLoopback, otapa1, lcsRateSet1, evrc8k,evrcb, highRateVoice13k and csd. OMs from this OM group are pegged for every time when the resource allocation for a particular service type (either preferred or re-directed) is attempted. Hence, these OMs may be pegged multiple times. Note: The service redirection is applicable to voice services only. First service is Preferred service and the next services are Alternate Service in the list sent in the Resource Allocation Request. Service Redirection occurs when the NRM re-directs the resource request from the Preferred service to an Alternate service.
ResourceCh eckAttempts
This OM is pegged when NRM checks resource availability in the entire system for a service.
CDMA
NBSS15.0
List of BSC OMsResource Availability Check OM group (continued) Register Description Sequence number (if applicable) 2 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
ResourceCh eckUnavailab le
This OM is pegged when NRM determines that there are no resources available in the entire system for a service.
ResourceCh eckAvailable
This OM is pegged when NRM determines that the resources are available in the system for a service.
411-2133-525
Standard
06.12
April 2008
Nortel Networks Table 22-2 List of BSC OMsPlatform Selection OM group Register Description
Sequence number (if applicable) OM group ID is 48
Platform Selection OM group New OM group in 14.0 release
This OM group consists of OMs to measure the NRM Platform selection Performance. The OMs peg at NRM during Platform Selection Phase to count number of attempts and successes on Primary and Secondary Platforms for a service. For more information about the NRM resource allocation call flow diagram, see Chapter 20, Call flow diagrams with OMs. (Pegging granularity of these OMs is on a per service type basis) Primary and Secondary platform choices can be configured at the NRM preference table for service that is supported on both platforms. Selection Attempt OM on Primary and Secondary platform peg only once per CAU request regardless of any internal hopping during algorithm execution. Pegging of Selection success OM on Primary and Secondary platform does not mean the resources are actually allocated but it means that resources to be allocated on that selected platform. The platform selection OMs from this group dont peg for the followings: When sub-resource managers (CSRM and / or SBSRM) are in CPU overload or Transaction queue associated with a platform is beyond threshold. For packet data calls for mobiles with P_REV = 7 and ADS required flag is true (These calls are always directed to CPDS and Platform selection is not performed) For DTA calls and DHO requests (These calls have different platform selection algorithm) Directed calls (These are test calls which direct allocation request to a particular platform) For Service types supported on both platforms, if the secondary platform is set to None, then secondary platform OMs for that service type will not be pegged.
CDMA
NBSS15.0
Table 22-2 List of BSC OMsPlatform Selection OM group (continued) Register Description Sequence number (if applicable) 1 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
SelectionAtte mptsOnPrim aryPlatform
This OM is pegged when the NRM attempts to select the primary platform for a service.
SelectionSuc cessOnPrima ryPlatform
This OM is pegged when NRM selects the primary platform for a service.
SelectionAtte mptsOnSeco ndaryPlatfor m SelectionSuc cessOnSeco ndaryPlatfor m
This OM is pegged when the NRM attempts to select the secondary platform for a service.
This OM is pegged when NRM selects the secondary platform for a service.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the CNFP OMs for the service resource setup OM group.
List of BSC OMsservice resource setup OM group Register Description Sequence number (if applicable) OM group ID is 36 Reference chapter Call resource allocation and management (page 16-1)
Service Resource Setup OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the NRM and it provides an indication of the resource allocation request traffic that is directed by the NRM to the SBS and CPDS/CSVS platform resource managers on a per Service group and per Service Type basis. All OMs in this group are pegged during NRM processing of a resource allocation request from the CAU and after NRM has selected either the SBS or CPDS/CSVS platform for allocating resources. If the selected platform fails to allocate resources, then the NRM alternatively tries to obtain them (i.e., if they are available) from the alternate platform. If the alternate platform does not exist or if required resources are unsupported or unavailable on the alternate platform, then the NRM returns a failed resource allocation response to the CAU. In which case, call setup may be blocked. For more information about NRM call resource allocation flow diagrams, see Call flow diagrams with OMs (page 20-1). Service groups: voice, packetData and other. and the Service Types: packetPpp, smsRateSet1, markov, msLoopback, otapa1, lcsRateSet1, evrc8k, evrcb, highRateVoice13 and csd. 1. Service group voice includes evrc8k,evrcb, highRateVoice13k, and csd. 2. Service group packetData includes only packetPpp. 3. Service group other includes smsRateSet1, markov, msLoopback, otapa1, and lcsRateSet1.
CDMA
NBSS15.0
22-124 BSC OM descriptions Nortel Networks List of BSC OMsservice resource setup OM group (continued) Register Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
SelectedEBS C_Allocation Attempts
This OM is pegged when the NRM has selected the CPDS/CSVS platform for allocating resources and sends a resource allocation request to the CSRM (in the case of voice Service group) or SDRM (in the case of a Service group of packetData or other) for the required service option. This OM is pegged when the NRM receives successful resource allocation response(s) from both the CSRM and SDRM (in the case of voice Service group) or SDRM only (in the case of a Service group of packetData or other), where the CPDS/CSVS platform was initially selected for allocating resources. This OM is pegged when the NRM fails to allocate the Media Gateway resource (i.e., DSP, CIC) in the case of voice Service group only, when the CSVS platform was initially selected for resource allocation. The resource allocation failure may be due to resource unavailability at the CSRM, due to internal failure at the CSRM or due to NRM timeout waiting for response from CSRM. This OM is pegged when the NRM fails to allocate the SDU (Selection and Distribution Unit) resource, when the CSVS/CPDS platform was initially selected for resource allocation. The resource allocation failure may be due to resource unavailability at the SDRM, due to internal failure at the SDRM or due to the NRM timeout waiting for response from SDRM. In the case of voice Service group, the resource allocation failure may be due to the NRM failure in sending a resource allocation request to the SDRM. This OM is pegged when the NRM sends an alternate resource allocation request to the CSRM (in the case of voice Service group) or SDRM (in the case of a Service group of packetData or other) for the required service option, after a failed resource allocation attempt on the initially selected SBS platform.
SelectedEBS C_Allocation Successes
SelectedEBS C_MG_Alloc ationFailures
SelectedEBS C_SDU_Allo cationFailure s
AlternateEBS C_Allocation Attempts
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsservice resource setup OM group (continued) Register Description
AlternateEBS C_Allocation Successes
This OM is pegged when the NRM receives successful resource allocation response(s) from both the CSRM and SDRM (in the case of voice Service group) or SDRM only (in the case of a Service group of packetData or other) for an alternate resource allocation request that was made after a failed resource allocation attempt on the initially selected SBS platform. This OM is pegged when the NRM fails to allocate the Media Gateway resource (i.e., DSP, CIC) in the case of voice Service group only, for an alternate resource allocation request (to the CPDS/CSVS platform) that was made after a failed resource allocation attempt on the initially selected SBS platform. The resource allocation failure may be due to resource unavailability at the CSRM, due to internal failure at the CSRM or due to NRM timeout waiting for response from CSRM. In this scenario, the NRM returns a failed resource allocation response to the CAU. Hence, call setup is blocked.
AlternateEBS C_MG_Alloc ationFailures
AlternateEBS C_SDU_Allo cationFailure s
This OM is pegged when the NRM fails to allocate the SDU (Selection and Distribution Unit) resource, for an alternate resource allocation request (to the CPDS/CSVS platform) that was made after a failed resource allocation attempt on the initially selected SBS platform. The resource allocation failure may be due to resource unavailability at the SDRM, or due to internal failure at the SDRM, due to the NRM timeout waiting for response from SDRM. In the case of voice Service group, the resource allocation failure may be due to the NRM failure in sending the alternate resource allocation request to the SDRM. In this scenario, the NRM returns a failed resource allocation response to the CAU. Hence, call setup is blocked.
CDMA
NBSS15.0
22-126 BSC OM descriptions Nortel Networks List of BSC OMsservice resource setup OM group (continued) Register Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
SelectedBSC _AllocationAt tempts
This OM is pegged when the NRM has selected the SBS platform for allocating resources and sends a resource allocation request to the SBSRM for the required service option. This OM is pegged when the NRM receives successful resource allocation response from SBSRM, where the SBS platform was initially selected for allocating resources. This OM is pegged when the NRM fails to allocate the SBS resource, when the SBS platform was initially selected for resource allocation. The resource allocation failure may be due to resource unavailability at the SBSRM, due to internal failure at the SBSRM or due to NRM timeout waiting for response from SBSRM. This OM is pegged when the NRM sends an alternate resource allocation request to the SBSRM for the required service option, after a failed resource allocation attempt on the initially selected CPDS/ CSVS platform. This OM is pegged when the NRM receives successful resource allocation response from SBSRM for an alternate resource allocation request that was made after a failed resource allocation attempt on the initially selected CPDS/CSVS platform.
SelectedBSC _AllocationS uccesses
10
SelectedBSC _AllocationF ailures
11
AlternateBS C_Allocation Attempts
12
Call resource allocation and management (page 16-1) Chapter 16, Call resource allocation and management
AlternateBS C_Allocation Successes
13
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsservice resource setup OM group (continued) Register Description
AlternateBS C_Allocation Failures
This OM is pegged when the NRM fails to allocate the SBS resource, for an alternate resource allocation request (to the SBS platform) that was made after a failed resource allocation attempt on the initially selected CPDS/CSVS platform. The resource allocation failure may be due to resource unavailability at the SBSRM, due to internal failure at the SBSRM or due to NRM timeout waiting for response from SBSRM. In this scenario, the NRM returns a failed resource allocation response to the CAU. Hence, call setup is blocked.
The following table shows a list of the CNFP OMs for the BSC resource request processing OM group.
List of BSC OMsBSC resource request processing OM group Register Description Sequence number (if applicable) OM group ID is 46 Reference chapter Call resource allocation and management (page 16-1)
BSC Resource Request Processing OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the SBSRM (SBS Resource Manager) and it provides an indication of the total resource allocation request traffic received by the SBSRM. For more information about SBSRM call resource allocation flow diagram, see Call flow diagrams with OMs (page 20-1). For resource allocation requests that are actually accepted by the SBSRM and processed further, refer to the BSC Resource Setup OM group. This OM is pegged when the SBSRM receives a resource allocation request message from NRM.
BSC_Allocati onRequestR eceived
CDMA
NBSS15.0
List of BSC OMsBSC resource request processing OM group (continued) Register Description Sequence number (if applicable) 2 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
BSC_Allocati onRequestDi scardedDueT oOverload BSC_Allocati onRequestD enied
This OM is pegged when the SBSRM discards or drops the resource allocation request message from the NRM due to SBSRM CPU overload condition.
This OM is pegged when the SBSRM denies the incoming resource allocation request from the NRM. Possible reasons for request denial are: request message cannot be decoded, SBSRM is administratively locked or message cannot be decoded. If the SBSRM denies an incoming resource allocation request while unlocked, it sends a resource allocation response message to the NRM indicating the reason for denial.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the CNFP OMs for the BSC resource setup OM group.
List of BSC OMsBSC resource setup OM group Register Description Sequence number (if applicable) OM group ID is 45 Reference chapter Call resource allocation and management (page 16-1)
BSC Resource Setup OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the SBSRM and it provides an indication of the resource allocation request traffic processed by the SBSRM on a per Service group and per Service Type basis. These OMs also measure the SBSRMs resource allocation performance. For more information about SBSRM call resource allocation flow diagram, see Call flow diagrams with OMs (page 20-1). Service groups are: voice, packetData and other. and Service Types are: packetPpp, smsRateSet1, markov, msLoopback, otapa1, lcsRateSet1, evrc8k,highRateVoice13K and csd. 1. Service group voice includes evrc8k,evrcb, highRateVoice13k, and csd. 2. Service group packetData includes only packetPpp. 3. Service group other includes smsRateSet1, markov, msLoopback, otapa1, and lcsRateSet1.
BSC_Allocati onRequestAc cepted
This OM is pegged when the SBSRM accepts the resource allocation request message from the NRM and continues to process that request. Note that SBSRM may discard or deny the NRMs resource allocation request and hence not accept all incoming requests. Refer to BSC Resource Request Processing OM group.
BSC_Resour ceUnavailabl eOnInitialAtte mpt
This OM is pegged when the SBSRM has determined that requested SBS service option resources are unavailable. The SBSRM consults its own internal resource availability status information to determine this condition.
CDMA
NBSS15.0
22-130 BSC OM descriptions Nortel Networks List of BSC OMsBSC resource setup OM group (continued) Register Description
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
BSC_Allocati onInitialAtte mpts
This OM is pegged when the SBSRM selects a available ESEL Service Resource Manager (SRM) and sends a resource allocation request message to it, for the first SBSRM attempt. This OM is pegged when SBSRM receives an resource allocation failure response (for any failure reason) from SRM, on the first SBSRM attempt. This is a failure scenario that may indicate mismatch between the SBSRM and SRM resource availability status information for resources that are actually depleted. In this scenario, the SBSRM retries allocation using another available SRM. If another SRM is not available, then SBSRM sends failed resource allocation response to NRM.
BSC_Allocati onInitialFailur es
BSC_Allocati onInitialTime outs
This OM is pegged when SBSRM does not receive resource allocation response from the SRM within the stipulated time period, on the first SBSRM attempt. In this scenario, SBSRM sends failed resource allocation response to NRM. This OM is pegged when SBSRM is successful in allocating resources at the SRM on the first SBSRM attempt, for the incoming resource allocation request from the NRM.
BSC_Allocati onInitialSucc esses
BSC_Resour ceUnavailabl eOnRetryAtt empt
This OM is pegged when the SBSRM is ready to retry for resource allocation but has determined that requested SBS service option resources are unavailable. The SBSRM consults its own internal resource availability status information to determine this condition. This OM is pegged when the SBSRM selects another available ESEL Service Resource Manager (SRM) and sends a resource allocation request message to it, for the retry SBSRM attempt.
BSC_Allocati onRetryAtte mpts
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsBSC resource setup OM group (continued) Register Description
BSC_Allocati onRetryFailur es
This OM is pegged when SBSRM receives an resource allocation failure response (for any failure reason) from SRM, on the retry SBSRM attempt. This is a failure scenario that may indicate mismatch between the SBSRM and SRM resource availability status information for resources that are actually depleted. In this scenario, SBSRM sends failed resource allocation response to NRM.
BSC_Allocati onRetryTime outs
This OM is pegged when SBSRM does not receive resource allocation response from the SRM within the stipulated time period, on the retry SBSRM attempt. In this scenario, SBSRM sends failed resource allocation response to NRM. This OM is pegged when SBSRM is successful in allocating resources at the SRM on the retry SBSRM attempt, for the incoming resource allocation request from the NRM.
10
BSC_Allocati onRetrySucc esses
11
BSC_Allocati onInternalFai lures
This OM is pegged when an internal failure at the SBSRM causes it to send failed resource allocation response to NRM, for an incoming resource allocation request that is already accepted for processing.
12
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the DTA call resource setup OM group.
List of BSC OMsDTA call resource setup OM group Register Description Sequence number (if applicable) OM group ID is 49 Reference chapter Call resource allocation and management (page 16-1)
DTA Call Resource Setup OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the NRM and it indicates the SDU (Selection and Distribution Unit) resource allocation success rate for Dormant-to-Active (DTA) requests processed by the NRM. These OMs also measure how often the PCU is changed between SBS and CPDS platforms and vice versa for DTA resource allocation requests. For more information about NRM packet data call resource allocation flow diagrams, see Call flow diagrams with OMs (page 20-1). This OM group is pegged on a per Service Type basis, and the only applicable Service Type is packetPpp.
DTA_BSC_A llocationReq uestAccepte d DTA_EBSC_ AllocationRe questAccept ed DTA_Allocati onRequestR esourceUnav ailable
This OM is pegged when a DTA resource allocation request is received from the CAU and is accepted by the NRM for processing, where the request indicates that dormant session exists on SBS platform. This OM is pegged when a DTA resource allocation request is received from the CAU and is accepted by the NRM for processing, where the request indicates that dormant session exists on CPDS platform. This OM is pegged when the NRM has determined that selector element (i.e. SDU) resources are unavailable in the entire system to satisfy the DTA Resource Allocation request. The NRM consults its own internal resource availability status information to determine this condition. In this case, DTA call setup is blocked. This OM is pegged when the NRM is successful in allocating selector element (i.e. SDU) resource on the SBS platform, where the incoming resource allocation request from the CAU indicated that dormant session exists on SBS platform.
DTA_BSC_R equestedSuc cessOnBSC
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsDTA call resource setup OM group (continued) Register Description Sequence number (if applicable) 5 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
DTA_BSC_R equestedSuc cessOnEBS C DTA_EBSC_ RequestedS uccessOnEB SC DTA_EBSC_ RequestedS uccessOnBS C DTA_Allocati onRequestsF ailures
This OM is pegged when the NRM is successful in allocating selector element (i.e. SDU) resource on the CPDS platform, where the incoming resource allocation request from the CAU indicated that dormant session exists on SBS platform. This OM is pegged when the NRM is successful in allocating selector element (i.e. SDU) resource on the CPDS platform, where the incoming resource allocation request from the CAU indicated that dormant session exists on CPDS platform. This OM is pegged when the NRM is successful in allocating selector element (i.e. SDU) resource on the SBS platform, where the incoming resource allocation request from the CAU indicated that dormant session exists on CPDS platform. This OM is pegged when the NRM determines that selector element (i.e. SDU) resources are available to satisfy the CAUs DTA resource allocation request, but fails to allocate them within the system for that request. In this case, call setup is blocked. These resource allocation failures are typically due to error conditions such as: internal failures, time-outs, mismatch in resource availability status information between NRM and platform resource managers, etc.
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the DTA BSC PCU lookup OM group.
List of BSC OMsDTA BSC PCU lookup OM group Register Description Sequence number (if applicable) OM group ID is 50 Reference chapter Call resource allocation and management (page 16-1)
DTA BSC PCU Lookup OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the SBSRM and it indicates how often the PCU is changed within the SBS platform when processing Dormant-to-Active (DTA) requests. PCU is changed within the SBS platform if the SBS shelf where the dormant packet session resides has no available selector element resources for the DTA transition, and hence a new packet session must be setup on another SBS shelf. This OM group is pegged on a per Service Type basis, and the only applicable Service Type is packetPpp.
DTA_Packet SessionFoun d
This OM is pegged when the SBS PCU Manager reports to SBSRM that it successfully found the PCU associated with the Mobile IMSI (i.e. the PCU where the dormant packet session resides). This OM is pegged when the PCU associated with the Mobile IMSI (i.e. the PCU where the dormant packet session resides) is successfully found but the SBSRM failed to allocate selector element (i.e. SDU) resource on the same SBS shelf as the found PCU. Hence, PCU (and packet session) must change to another SBS shelf. This OM is pegged when the PCU associated with the Mobile IMSI (i.e. the PCU where the dormant packet session resides) is successfully found and the SBSRM successfully allocated selector element (i.e. SDU) resource on the same SBS shelf as the found PCU.
DTA_PCU_C hanged
DTA_PCU_N otChanged
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the CNFP OMs for the DHO call resource request processing OM group.
Table 22-3 List of BSC OMsDHO call resource request processing OM group Register Description Sequence number (if applicable) OM group ID is 51 Reference chapter Call resource allocation and management (page 16-1)
DHO Call Resource Request Processing OM group New OM group in 14.0 release DHO_Allocati onRequestR eceived
This OM group consists of OMs that are pegged at the NRM and it provides an indication of the total PCU allocation request traffic received by the NRM for Dormant Handoff (DHO). For more information about the DHO PCU allocation flow diagram, see Call flow diagrams with OMs (page 20-1). For PCU allocation requests that are actually accepted by the NRM and processed further, refer to the DHO Call Resource Setup OM group. This OM is pegged when the NRM receives a DHO PCU allocation request message from CAU.
DHO_Allocati onRequestR ejectedDueT oOverload DHO_Allocati onRequestD enied
Currently there are no scenarios in which this OM gets pegged.
This OM is pegged when the NRM denies the incoming DHO PCU allocation request from the CAU. Possible reasons for request denial are: request message cannot be decoded, NRM is administratively locked. In that case, the NRM does not accept the request for further processing, and if not locked, sends a PCU allocation response message to the CAU indicating the reason for denial.
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the DHO call resource setup OM group.
List of BSC OMsDHO call resource setup OM group Register Description Sequence number (if applicable) OM group ID is 52 Reference chapter Call resource allocation and management (page 16-1)
DHO Call Resource Setup OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the NRM and it provides an indication of the PCU allocation success rate for Dormant Handoff (DHO). For more information about the DHO PCU allocation flow diagram, Call flow diagrams with OMs (page 201). This OM group is pegged on a per Service Type basis, and the only applicable Service Type is packetPpp. This OM is pegged when the NRM is successful in allocating PCU on either SBS or CPDS platform, for the incoming DHO PCU Allocation request received from the CAU. This OM is pegged when the NRM fails to allocate PCU on SBS and/or CPDS platform, for the incoming DHO PCU Allocation request received from the CAU. These PCU allocation failures are typically due to error conditions such as internal failures and timeouts.
DHO_Allocati onRequestS uccesses
DHO_Allocati onRequestFa ilures
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the CNFP OMs for the DHO service resource setup OM group.
List of BSC OMsDHO service resource setup OM group Register Description Sequence number (if applicable) OM group ID is 53 Reference chapter Call resource allocation and management (page 16-1)
DHO Service Resource Setup OM group New OM group in 14.0 release
This OM group consists of OMs that are pegged at the NRM and it provides an indication of how the PCU allocation (for DHO requests processed by the NRM) is distributed between the SBS and CPDS platforms. OMs in this group are pegged during NRM processing of a DHO PCU allocation request from the CAU and after NRM has selected either the SBS or CPDS platform for allocating PCU. For more information about the DHO PCU allocation flow diagram, see Call flow diagrams with OMs (page 201). This OM group is pegged on a per Service Type basis, and the only applicable Service Type is packetPpp.
DHO_Select edEBSC_All ocationAttem pts DHO_Select edEBSC_All ocationSucce sses DHO_Select edEBSC_All ocationFailur es DHO_Alterna teBSC_Alloc ationAttempt s
This OM is pegged when the NRM has selected the CPDS platform and sends PCU allocation request to the CPDS PCU Manager.
This OM is pegged when the NRM is successful at PCU allocation for a DHO request on the CPDS platform (by interaction with CPDS PCU Manager), where the CPDS platform was initially selected for PCU allocation. This OM is pegged when the NRM fails at PCU allocation for a DHO request on the CPDS platform (by interaction with CPDS PCU Manager), where the CPDS platform was initially selected for PCU allocation. This OM is pegged when the NRM attempts PCU allocation for a DHO request on the SBS platform (by interaction with SBS PCU Manager) after a failed PCU allocation attempt on the initially selected CPDS platform.
CDMA
NBSS15.0
List of BSC OMsDHO service resource setup OM group (continued) Register Description Sequence number (if applicable) 5 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
DHO_Alterna teBSC_Alloc ationSuccess es DHO_Alterna teBSC_Alloc ationFailures
This OM is pegged when the NRM is successful at PCU Allocation for a DHO request on the SBS platform (by interaction with SBS PCU Manager) after a failed PCU allocation attempt on the initially selected CPDS platform. This OM is pegged when the NRM fails at PCU Allocation for a DHO request on the SBS platform (by interaction with SBS PCU Manager) after a failed PCU allocation attempt on the initially selected CPDS platform. This OM is pegged when the NRM has selected the SBS platform for allocating PCU and sends PCU allocation request to the SBS PCU Manager.
DHO_Select edBSC_Alloc ationAttempt s DHO_Select edBSC_Alloc ationSuccess es DHO_Select edBSC_Alloc ationFailures
This OM is pegged when the NRM is successful at PCU allocation for a DHO request on the SBS platform (by interaction with SBS PCU Manager), where the SBS platform was initially selected for PCU allocation. This OM is pegged when the NRM fails at PCU allocation for a DHO request on the SBS platform (by interaction with SBS PCU Manager), where the SBS platform was initially selected for PCU allocation. This OM is pegged when the NRM attempts PCU allocation for a DHO request on the CPDS platform (by interaction with CPDS PCU Manager) after a failed PCU allocation attempt on the initially selected SBS platform. This OM is pegged when the NRM is successful at PCU Allocation for a DHO request on the CPDS platform (by interaction with CPDS PCU Manager) after a failed PCU allocation attempt on the initially selected SBS platform.
DHO_Alterna teEBSC_Allo cationAttemp ts DHO_Alterna teEBSC_Allo cationSucces ses
10
11
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsDHO service resource setup OM group (continued) Register Description Sequence number (if applicable) 12 Reference chapter Call resource allocation and management (page 16-1)
DHO_Alterna teEBSC_Allo cationFailure s
This OM is pegged when the NRM fails at PCU Allocation for a DHO request on the CPDS platform (by interaction with CPDS PCU Manager) after a failed PCU allocation attempt on the initially selected SBS platform.
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the Platform Selection Overload OM group.
List of BSC OMsPlatform Selection Overload OM group Register Description Sequence number (if applicable) OM group ID is 65 Reference chapter Call resource allocation and management (page 16-1)
Platform Selection Overload OM group New OM group in 14.0 release PlatformSele ctionFailures DueToTQ_E xceeded
This OM group consists of OMs to measure effects on resource allocation at NRM (such as failures or change in platform selection) due to CPU Overload of situation of CSRM / SBSRM for Voice, Null to Active Packet Data and other service types calls. Primary and Secondary platform choices are configured at the NRM preference table. This OM pegs when Resource Allocation fails due to Transaction Queue (TQ) associated with all applicable platforms (EBSC and/or BSC) exceeds internal thresholds. Failure can also happen when TQ exceeding has eliminated any one platform and remaining platform has no resources. This event also leads to the pegging of Call Resource Setup:AllocationRequestFailures OM.
PlatformPref erenceChang e
This OM pegs when Primary and Secondary platforms are exchanged compared to the Platform table configuration for services that are supported on both platforms. This exchange can occur because Transaction queue exceeds the internal thresholds associated with primary platform and/or SBSRM/ CSRM is in overload. This OM pegs when NRM drops Secondary Platform choice from consideration for services supported on both platforms. This can happen due to Transaction Queue size associated with secondary platform exceeds internal thresholds.
SecondaryPl atformDropp edDueToTQ _Exceeded
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the CNFP OMs for the DTA Platform Selection Overload OM group.
List of BSC OMsDTA Platform Selection OM group Register Description Sequence number (if applicable) OM group ID is 64 Reference chapter Call resource allocation and management (page 16-1)
DTA Platform Selection Overload OM group New OM group in 14.0 release
This OM group consists OMs to measure effects on resource allocation at NRM (such as failures or change in platform selection) during CPU Overload of SBSRM / SDRM for Dormant to Active Packet data calls. For Dormant to Active packet data requests, CAU indicates the platform in resource occultation request where the dormant session exists. This platform is considered as Primary Platform and the remaining platform is considered secondary platform. This OM pegs when Resource Allocation fails due to Transaction Queue (TQ) associated with both platforms (EBSC and BSC) exceeds internal thresholds. Failures can also happen when TQ exceeding has eliminated any one platform and remaining platform has no resources. This event also leads to the pegging of DTA Call Resource Setup:DTA_AllocationRequestsFailures OM.
DTA_Platfor mSelectionF ailuresDueTo TQ_Exceede d
DTA_Platfor mPreference Change
This OM pegs when Primary and Secondary platforms are exchanged compared the platform requested by CAU. This exchange can occur because Transaction queue exceeds the internal thresholds for primary platform. This OM pegs when NRM drops Secondary Platform choice from consideration. This can happen due to Transaction Queue size associated with secondary platform exceeds internal thresholds.
DTA_Second aryPlatformD roppedDueT oTQ_Exceed ed
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the DHO Platform Selection Overload OM group.
List of BSC OMsDHO Platform Selection Overload OM group Register Description Sequence number (if applicable) OM group ID is 63 Reference chapter Call resource allocation and management (page 16-1)
DHO Platform Selection Overload OM group New OM group in 14.0 release DHO_Platfor mSelectionF ailuresDueTo TQ_Exceede d
This OM group consists OMs to measure effects on Resource Allocation at NRM (such as failures or change in platform selection) during CPU Overload of SBSPCUM for Dormant Handoff Packet data requests. Primary and Secondary platform choices are configured at the NRM preference table. This OM pegs when dormant handoff request fails due to Transaction Queue (TQ) associated with both platforms (EBSC and BSC) exceeds internal thresholds. Failures can also happen when TQ exceeding has eliminated any one platform and remaining platform selection fails due to any error condition (such as SBSPCUM unavailability). This event also leads to the pegging of DHO Call Resource Setup:AllocationRequestFailures OM.
DHO_Platfor mPreference Change
This OM pegs when Primary and Secondary platforms are exchanged compared to the Platform table configuration. This exchange can occur because Transaction queue exceeds the internal thresholds associated with primary platform and/or SBSPCUM is in overload where BSC is the primary platform. This OM pegs when NRM drops Secondary Platform choice from consideration. This can happen due to Transaction Queue size associated with secondary platform exceeds internal thresholds.
DHO_Secon daryPlatform DroppedDue ToTQ_Excee ded
The following table shows a list of the CNFP OMs for the EBSC Voice
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Resource Request Process OM group.

List of BSC OMsEBSC Resource Request Processing OM group Register Description Sequence number (if applicable) OM group ID is 61 Reference chapter Call resource allocation and management (page 16-1)
EBSC Voice Resource Request Processing OM group New OM group in 14.0 release EBSC_Voice AllocationRe questReceiv ed EBSC_Voice AllocationRe questAccept ed
This OM group consists of OMs that are pegged at the CSRM (Circuit Switched Resource Manager) and it provides an indication of the total resource allocation request traffic received by the CSRM.
This OM is pegged when the CSRM receives a resource allocation request message from NRM.
This OM is pegged when the CSRM accepts the resource allocation request message from the NRM and continues to process that request. Note that CSRM may discard or deny the NRMs resource allocation request and hence not accept all incoming requests.
EBSC_Voice AllocationRe questDenied
This OM is pegged when the CSRM denies the incoming resource allocation request from the NRM. Possible reasons for request denial are: invalid SO, request message cannot be decoded, CSRM is administratively locked, etc. This OM is pegged when the CSRM discards or drops the resource allocation request message from the NRM due to CSRM CPU overload condition.
EBSC_Voice AllocationRe questDiscard edDueToOve rload
CDMA
NBSS15.0
22-144 BSC OM descriptions Nortel Networks List of BSC OMsResource Utilization OM group Register Description
Resource Utilization OM group New OM group in 14.0 release
This OM group indicates the resource utilization for various resources within the EBSC and BSC. The OMs in this group are pegged on a per Resource Type basis. The resource can be of type: cic, ebscSduVoiceAndOther, ebscSduPacketDataAndOther, ebscCct, ebscPkt, ebscTrfo, bscCct, bscPkt, ebscEvrcLicense and ebscEvrcbLicense. For more information, see Call resource allocation and management (page 16-1). The CICDB reports cic resource utilization within the entire EBSC. The utilization of cic Resource Type reflects the CIC (Circuit Identification Code) utilization. The SDRM reports ebscSduVoiceAndOther and ebscSduPacketDataAndOther resource utilization within the entire EBSC. This utilization reflects the CCDS licensed capacity as reported from DSFP cards. The utilization of ebscSduVoiceAndOther Resource Type reflects the EBSC SDU (Selection/Distribution Unit) Voice and Other (non-voice and non-packet data) utilization for DSFP-V cards. The utilization of ebscSduPacketDataAndOther Resource Type reflects the EBSC SDU Packet Data and Other (non-packet data and non-voice) utilization for DSFP-D cards. This assumes that all DSFP-D cards are fully licensed. Therefore, if any DSFPD cards are not fully licensed, the utilization will not reflect the actual packet data utilization. The CSRM reports ebscCct,ebscPkt, ebscTrfo, ebscEvrcLicense and ebscEvrcbLicense resource utilization within the entire EBSC. The ebscCct resource utilization reflects the vocoding resource utilization reported from 2pVS cards connected to DTCs and SPMs. This 2pVS resource utilization takes into accout the usage by both the EVRC and EVRCB service options. Similarly the utilization of ebscPkt Resource type reflects the vocoding resource utilization reported from 2pVS cards connected to Trunk
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMsResource Utilization OM group (continued) Register Description
Sequence number (if applicable)
Reference chapter
PVGs where utilization takes into account the usage of 2pVS resources by both the EVRC and EVRCB service options. The utilization of ebscTrfo Resource Type reflects the vocoding resource utilization reported from 2pVS cards connected to TrFO capable PVGs. These are reported without consideration of CIC and by taking the less of CSVS EVRC CCDS licensed capacity and CCDS licensed capacity as reported by the 2pVS cards. The utilization of ebscEvrcLicense and ebscEvrcbLicense Resource Type reflects the system wide CCDS licensing utilization for EVRC and EVRCB service options respectively. This utilization is calculated based on the current usage of each service option over the configured licenses for that particular service option. The license utilization are required due to the fact that these service options are licensed. The SBSRM reports bscCct and bscPkt resource utilization within the entire BSC. The utilization of bscCct Resource Type reflects the BSC SE (Selector Element) utilization for ESEL cards connected to DTCs (Digital Trunk Controller). The utilization of bscPkt Resource Type reflects the BSC SE (Selector Element) utilization for ESEL cards connected to PVGs (Packet Voice Gateway).
Note 1: If no resources are configured for a particular resource type in the system, then the resource utilization OMs for that resource type are not pegged and the OMs for that resource type do not show up at all in the CEMS file Note 2: For CFDS / CCDS licensing information, please refer to NTP: NN20000-272
CDMA
NBSS15.0
22-146 BSC OM descriptions Nortel Networks List of BSC OMsResource Utilization OM group (continued) Register Description
MaxAvailable ConfiguredC apacity
This OM indicates the maximum number of licensed resources which are available for carrying traffic (i.e. Voice, Packet Data, SMS, OTAPA etc.) in the collection interval. This OM value is sampled every 1 seconds. This OM value is not sensitive to the number of calls in the system, but may be reduced due to equipment failure that persists for the duration of any particular collection interval. Equipment failure refers to both the failure of physical components (such as ESEL, 2pVS, DSFP cards, T1s, etc.) and application/logical components (such PCU, PCU-M, L2TP tunnels, CICs etc.) that directly or indirectly reduce or affect the system's call carrying capacity.
ResourceUtili zationIndex_ 1
This OM counts the number of times the instantaneous resource utilization was greater than or equal to 0% and less than 1% in the collection interval This OM counts the number of times the instantaneous resource utilization was greater than or equal to 1% and less than 5% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 5% and less than 10% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 10% and less than 15% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 15% and less than 20% in the collection interval.
411-2133-525
Standard
06.12
April 2008
This OM counts the number of times the instantaneous resource utilization was greater than or equal to 20% and less than 25% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 25% and less than 30% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 30% and less than 35% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 35% and less than 40% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 40% and less than 45% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 45% and less than 50% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 50% and less than 55% in the collection interval.
10
11
12
13
CDMA
NBSS15.0
This OM counts the number of times the instantaneous resource utilization was greater than or equal to 55% and less than 60% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 60% and less than 65% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 65% and less than 70% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 70% and less than 75% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 75% and less than 80% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 80% and less than 85% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 85% and less than 90% in the collection interval.
15
16
17
18
19
20
411-2133-525
Standard
06.12
April 2008
This OM counts the number of times the instantaneous resource utilization was greater than or equal to 90% and less than 91% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 91% and less than 92% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 92% and less than 93% in the collection interval.
22
23
This OM counts the number of times the instantaneous resource utilization was greater than or equal to 93% and less than 94% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 94% and less than 95% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 95% and less than 96% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 96% and less than 97% in the collection interval.
24
25
26
27
CDMA
NBSS15.0
Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
This OM counts the number of times the instantaneous resource utilization was greater than or equal to 97% and less than 98% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 98% and less than 99% in the collection interval. This OM counts the number of times the instantaneous resource utilization was greater than or equal to 99% and less than 100% in the collection interval. This OM counts the number of times the instantaneous resource utilization was equal to 100% in the collection interval.
29
30
31
Table 22-4 List of BSC OMs OM group Register Description Sequence number (if applicable) OM group ID is 43 Reference chapter
ACP Resource Capacity New OM group in 14.0 release AvailablePhy sicalSDU_Ca pacity
The ACP Resource Capacity group provides an indication of the capacity of the ACPs. This OM pegs at CAC node of DSFP card. This OM is peg on a per Voice or Packet Data service type depending on the DSFP-V or DSFP-D card type.
This OM captures the installed SDU capacity (i.e. number of Selector Elements) in the entire system. The entire installed SDU capacity may not be available to carry traffic due to license limitations. The value of this OM is not affected by changes in ACP states such as Lock or out-of-service situation.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the OMs for the NRM MessageRequest Processing OM group.
List of BSC OMs NRM Message Request Processing OM group Register Description Sequence number (if applicable) OM group ID is 62 Reference chapter
NRM Message Request Processing OM group New OM group in 14.0 release ACN_NOIS_ MsgDiscarde dDueToOverl oad
NRM Message Request Processing group provides an indication of messages discarded by NRM.
This OM is pegged whenever NRM discards every NOIS message (regardless of message type) received over ACN due to CPU overload condition. Other entities are not informed about the NRM discards and they shall time out.
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the Connection Call Resource setup OM group
List of BSC OMsConnection Call Resource Setup OM group Register Description Sequence number (if applicable) OM group ID is 75 Reference chapter Call resource allocation and management (page 16-1)
Connection Call Resource Setup OM group New OM group in 14.0 release ConnectionAl locationRequ estReceived
This OM group consists of OMs to track the resource allocation attempts, resource unavailable, and successful resource allocations and failure situations. Pegging granularity is on a per connection type basis. The possible connection types are trfo, packet, circuit, unspecified. These OMs peg for voice services only. Refer to Call Flow diagram for a connection type with OMs in Call flow diagrams with OMs (page 20-1) for pegging details. This OM is pegged when NRM receives resource allocation request for a connection type.
ConnectionAl locationReso urceUnavaila ble ConnectionAl locationReso urceAvailable
This OM is pegged when NRM could not allocate resource for a requested connection type even after resource re-direction. In this case, call setup is blocked and NRM sends failure response to CAU.
This OM is pegged when NRM successfully allocates resources for a requested connection type.
ConnectionAl locationReso urceFailures
This OM is pegged when the NRM fails to allocate the resource from any or both systems (i.e., BSC and EBSC systems as datafilled in NRM preference table). These failures are typically due to internal error conditions and communication errors such as: internal failures, timeouts, mismatch in resource availability status information etc. In this case, call setup is be blocked.
The following table shows a list of the CNFP OMs for the Connection
411-2133-525
Standard
06.12
April 2008
Nortel Networks
Resource Availability Check OM group.

List of BSC OMsConnection Resource Availability Check OM group Register Description Sequence number (if applicable) OM group ID is 74 Reference chapter Call resource allocation and management (page 16-1)
Connection Resource Availability Check OM group Modified OM group in 15.0 release
This OM group consists of OMs to track the number of times resources are unavailable for resource allocation for EVRC and EVRC-B on per connection type basis. OMs from this group are pegged by NRM during Resource Availability Check Phase after NRM accepts the Resource allocation request and before the Platform Selection Phase starts. NRM may check resource availability multiple times during resource allocation for a single CAU EVRC resource request. Hence, these OMs may be pegged multiple times during each resource availability check. Refer to Call Flow diagram for a connection type with OMs in Call flow diagrams with OMs (page 20-1) for pegging details. These OMs peg for EVRC service and EVRC-B service only. Pegging granularity of the OMs is on a per connection type and service option basis as follows: Circuit (means CircuitEvrc), Packet (means PacketEvrc), Trfo(means TrfoEvrc), Unspecified, CircuitEvrcB and PacketEvrcB
ConnectionR esourceChec kAttempts
This OM is pegged when NRM checks resource availability in the entire system for a connection type.
ConnectionR esourceChec kUnavailable
This OM is pegged when NRM determines that there are no resources available in the entire system for a connection type.
CDMA
NBSS15.0
List of BSC OMsConnection Resource Availability Check OM group (continued) Register Description Sequence number (if applicable) 3 Reference chapter Call resource allocation and management (page 16-1)
ConnectionR esourceChec kAvailable
This OM is pegged when NRM determines that resources are available in the entire system for a connection type.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of the CNFP OMs for the BSC Connection Resource Availability Check OM group.
List of BSC OMsBSC Connection Resource Availability Check OM group Register Description Sequence number (if applicable) OM group ID is 77 Reference chapter Call resource allocation and management (page 16-1)
BSC Connection Resource Availability Check OM group New OM group in 14.0 release
This OM group consists of OMs to track the number of times resources are unavailable for resource allocation for 13K on per connection type basis. OMs from this group are pegged by SBSRM during Resource Availability Check after SBSRM accepts the Resource allocation request. SBSRM may check resource availability multiple times during resource allocation. Hence, these OMs may be pegged multiple times during each resource availability check. Refer to Call Flow diagram for a connection type with OMs in Call flow diagrams with OMs (page 20-1) for pegging details. These OMs peg for 13K service only. Pegging granularity of the OMs is on a per connection type as follows: packet and circuit.
BSC_Conne ctionResourc eCheckAttem pts BSC_Conne ctionResourc eCheckUnav ailable BSC_Conne ctionResourc eCheckAvail able
This OM is pegged when SBSRM checks resource availability for a connection type.
This OM is pegged when SBSRM determines that there are no resources available for a connection type.
This OM is pegged when SBSRM determines that resources are available for a connection type.
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the Connection Resource Redirection OM group.
List of BSC OMsConnection Resource Redirection OM group Register Description Sequence number (if applicable) OM group ID is 73 Reference chapter Call resource allocation and management (page 16-1)
Connection Resource Redirection OM group New OM group in 14.0 release AllocationRe questRedirec tionTrFO_To Cct AllocationRe questRedirec tionTrFO_To Pkt AllocationRe questRedirec tionPktToTrF O AllocationRe questRedirec tionPktToCct
This OM group consists of OMs that peg at NRM to measure the re-direction from preferred connection type to next suitable connection type that is also available. This OM pegs after Platform Selection Phase. Refer to Call Flow diagram for a connection type with OMs in Call flow diagrams with OMs (page 20-1) for pegging details. This OM is pegged when resources for TrFO connection type are requested by CAU but instead, NRM successfully finds resources for circuit connection type. This OM is pegged when resources for TrFO connection type are requested by CAU but instead, NRM successfully finds resources for packet connection type. This OM is pegged when resources for packet connection type are requested by CAU but instead, NRM successfully finds resources for trfo connection type. This OM is pegged when resources for packet connection type are requested by CAU but instead, NRM successfully finds resources for circuit connection type. This OM is pegged when resources for circuit connection type are requested by CAU but instead, NRM successfully finds resources for trfo connection type.
AllocationRe questRedirec tionCctToTrF O
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsConnection Resource Redirection OM group (continued) Register Description Sequence number (if applicable) 6 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
AllocationRe questRedirec tionCctToPkt
This OM is pegged when resources for circuit connection type are requested by CAU but instead, NRM successfully finds resources for packet connection type. This OM is pegged when CAU requests resources with an empty Connection Type indicator and NRM successfully finds resources for circuit connection type. This OM is pegged when CAU requests resources with an empty Connection Type indicator and NRM successfully finds resources for packet connection type. This OM is pegged when CAU requests resources with an empty Connection Type indicator and NRM successfully finds resources for trfo connection type.
AllocationRe questRedirec tionUnspecifi edToCct AllocationRe questRedirec tionUnspecifi edToPkt AllocationRe questRedirec tionUnspecifi edToTrFO
CDMA
NBSS15.0
The following table shows a list of the CNFP OMs for the Connection Resource Setup OM group
List of BSC OMsConnection Resource Setup OM group Register Description Sequence number (if applicable) OM group ID is 76 Reference chapter Call resource allocation and management (page 16-1)
Connection Resource Setup OM group New OM group in 14.0 release
OMs from this OM group are pegged by NRM for each connection type to track the attempts, success and failures on a per platform basis (i.e CSVS or SBS) after NRM has successfully determined the platform for resource allocation. The OMs for CSVS platform peg on a per TrFO, circuit or packet connection type. The OMs for SBS platform peg on a per circuit or packet connection type. These OMs peg after Platform Selection Phase. Refer to Call Flow diagram for a connection type with OMs in Call flow diagrams with OMs (page 20-1) for pegging details. This OM is pegged when the NRM sends a resource allocation request to the CSRM for the required Connection Type.
EBSC_Conn ectionAllocati onAttempts
EBSC_Conn ectionAllocati onSuccesses
This OM is pegged when the NRM receives a successful resource allocation response for a Connection Type from both the CSRM and SDRM.
EBSC_MG_ ConnectionAl locationFailur es
This OM is pegged when the NRM fails to allocate the MG (Media Gateway) resource (i.e. DSP, CIC) for a requested Connection Type. This can happen upon failure response from CSRM due to resource unavailability, internal failure or if NRM times out waiting for response from CSRM.
EBSC_SDU_ ConnectionAl locationFailur es
This OM is pegged when the NRM fails to allocate the SDU (Selection Distribution Unit) resource for a requested Connection Type. The resource allocation fails upon failure response from SDRM due to resource unavailability, internal failure or if NRM times out waiting for response from SDRM.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
List of BSC OMsConnection Resource Setup OM group (continued) Register Description Sequence number (if applicable) 5 Reference chapter Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1) Call resource allocation and management (page 16-1)
BSC_Conne ctionAllocatio nAttempt
This OM is pegged when the NRM sends a resource allocation request to the SBSRM for a requested Connection Type.
BSC_Conne ctionAllocatio nSuccess
This OM is pegged when the NRM receives a successful resource allocation response for a Connection Type from the SBSRM.
BSC_Conne ctionAllocatio nFailures
This OM is pegged when the NRM fails to allocate the SBS resource for a requested connection type. The resource allocation fails upon failure response from SBSRM due to resource unavailability, internal failure or if NRM times out waiting for response from SBSRM.
CDMA
NBSS15.0
The following table shows a list of the EVRC-B Distribution OM group. This group is new in NBSS15.0 release.
List of BSC OMs EVRC-B Distribution OM group Register Description Sequence number (if applicable) OM Group ID is 78 Reference chapter Call resource allocation and management (page 16-1)
EVRCB Distribution
This OM group is pegged on per BSC basis. It contains seperate OMs that are pegged; based on the BTS loading report and the mode threshold selection table (event-based); based on the number of frames sent for each selected mode (time-based). These OMs are pegged for modes selected in both the forward and reverse directions. The event-based OMs are pegged after the BSC received the CATSOM_SOMServiceConnectReq message and successfully initialized the service.The frame-based OMs are pegged for the duration of the call. So if the mode changes after initial selection it will still be captured. The ACP sends the selected forward mode to the 2pVS and the reverse mode to the mobile using the Service Option Control Message (SOCM).
EVRCB_Fra meCountFwd Mode_0
This OM counts the forward mode 0 frames sent for all the EVRC-B calls in the entire system.
This OM counts the forward mode 4frames sent for all the EVRC-B calls in the entire system.
This OM counts the forward mode 6frames sent for all the EVRC-B calls in the entire system.
EVRCB_Fra meCountRev Mode_0
This OM counts the reverse mode 0 frames received for the EVRC-B calls in the entire system.
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMs EVRC-B Distribution OM group (continued) Register Description
15
EVRCB_Sele ctionCountF wdMode_0
This OM counts the number of times Mode 0 is selected in the forward direction, during call setup based on the BTS loading report and the mode selection threshold table. This OM counts the number of times Mode 4 is selected in the forward direction, during call setup based on the BTS loading report and the mode selection threshold table. This OM counts the number of times Mode 6 is selected in the forward direction, during call setup based on the BTS loading report and the mode selection threshold table. This OM counts the number of times Mode 0 is selected in the reverse direction, during call setup based on the BTS loading report and the mode selection threshold table. This OM counts the number of times Mode 4 is selected in the reverse direction, during call setup based on the BTS loading report and the mode selection threshold table.
17
21
23
EVRCB_Sele ctionCountR evMode_0
25
29
CDMA
NBSS15.0
22-162 BSC OM descriptions Nortel Networks List of BSC OMs EVRC-B Distribution OM group (continued) Register Description
This OM counts the number of times Mode 6 is selected in the reverse direction, during call setup based on the BTS loading report and the mode selection threshold table.
411-2133-525
Standard
06.12
April 2008
Nortel Networks
The following table shows a list of OMs in the Short Data Burst OM group.
List of BSC OMs - Short Data Burst OM group Register Description Sequence number (if applicable) OM group ID is 66 Reference chapter Data burst message delivery performance (page 12-1)
Short Data Burst OM group New OM group in 14.0 release
This OM group consists of OMs that count the total number of R-SDBs (Reverse Short Data Bursts) received at the PCU (PCUFP in eBSC) from the PCU-M, total number of R-SDBs forwarded to the PDSN and the total number of R-SDBs dropped at the PCU (PCUFP in eBSC). This OM group is defined in PCU for eBSC only. The OMs in this OM group peg on a per PCU basis. Note: The EACH_RSDB_Histogram and RFCH_RSDB_Histogram OMs peg for the entire size (in bytes) of the CHARi fields of the Mobile-initiated R-SDB, which contains the SDB header and the data block. These histogram OMs peg for the Mobile-initiated R-SDBs that were received by the CPDS PCU (from the PCU-M).
EACH_RSD B_Histogram _1
This OM is pegged when a R-SDB of size 1 - 25 bytes is received by the PCU (PCUFP). The R-SDB was sent by the mobile on the R-EACH.
Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
CDMA
NBSS15.0
22-164 BSC OM descriptions Nortel Networks List of BSC OMs - Short Data Burst OM group Register Description
10
RFCH_RSD B_Histogram _1
This OM is pegged when a R-SDB of size 1 - 25 bytes is received by the PCU (PCUFP). The R-SDB was sent by the mobile on the R-FCH.
11
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of BSC OMs - Short Data Burst OM group Register Description
13
14
15
16
17
18
CDMA
NBSS15.0
22-166 BSC OM descriptions Nortel Networks List of BSC OMs - Short Data Burst OM group Register Description
Reference chapter Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1) Data burst message delivery performance (page 12-1)
This OM is pegged when a R-SDB of size 201 - 225 bytes is sent over the R-FCH and received by the PCU (PCUFP).
20
TotalRSDB_ Forwarded
This OM is pegged when a R-SDB is sent by the PCU (PCUFP) to the PDSN.
21
TotalRSDB_ Dropped
This OM is pegged when a R-SDB is not sent by the PCU (PCUFP) to the PDSN.
22
411-2133-525
Standard
06.12
April 2008
Nortel Networks
CDMA-LTX operational measurements
22
The following table contains OMs (also called Performance Attributes) and the related Managed Objects for the V5.2 product. This product is also called the CDMA Fixed Wireless System. The description of OMs also includes some important notes regarding them. The sequence number for each OM is provided to help distinguish the OMs when reviewing raw OM data (before the logfilter tool is applied). Please refer to NTP NN20000-104 for more information regarding the logfilter tool.
List of CDMA-LTX OMs Register Description Sequence number (if applicable) OM group ID is 2 Reference chapter CDMA-LTX performanc e (page 181)
FW BCM EBID OMs
Fixed Wireless Base station Call Manager EBID OMs. The OMs in this group are pegged on a per EBID basis, except for CallingNumberDuringTermination, FlashMessage, LandRelease, LAUInitiatedRelease, OriginationAttempts, OriginationBlocked, OriginationReleased, OriginationSuccess, PageResponse, and SoftHandoff which are pegged on a System-wide basis. The BCM pegs this OM whenever the BCM receives a page response from a LAU. This OM is independent of the paging method used (slotted mode, page retry, quick repeat). This OM is pegged when the BSC receives a Service Connect Complete message from the LAU during an termination call setup. Note: Used to classify calls as established. This OM is pegged any time a LAU-terminated call setup fails due to resource shortage. It represents all of the termination setup failures in a sector, regardless of resource. The same failure reasons that are pegged for OriginationBlocked are be pegged in conjunction with TerminationBlocked. This OM is pegged when a network-originated call is released before the LAU arrives on the traffic channel. It should be noted that this OM will only get pegged if the originating party disconnects between the time that the LAUs page response has been received by the BCM and before the LAU actually arrives on the traffic channel.
sheet 1 of 18
PageRespon se
CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181)
TerminationS uccess
TerminationB locked
TerminationR eleased
CDMA-LTX performanc e (page 181)
CDMA
NBSS15.0
22-168 BSC OM descriptions Nortel Networks List of CDMA-LTX OMs (continued) Register Description
Reference chapter CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181)
OriginationAt tempts
This OM is pegged when the BCM receives an origination forwarded to it by the FWPAM.
OriginationS uccess
This OM is pegged when the BSC receives a Service Connect Complete message from the LAU during an origination call setup. This includes all originations placed on the traffic channel to receive treatment. Note: Used to classify calls as established. This OM is pegged any time a LAU-originated call setup fails due to resource shortage. It represents the total number of origination setup failures in a sector, regardless of resource. One or more of the following call setup failure reasons is pegged in conjunction with OriginationBlocked: RMNoAvailableResources, RMServiceResourceNAK, RMSRMTimeOut, FailedCallSoftwareTimeout, RadioLinkSetupError, TCEUnavailable, WalshCodeUnavailable, ForwardCapacityFull, MCTACDABlocked, and a MCTACDA* blocking reason. This OM is pegged with the appropriate blocking OM and either a blocking reason OM or a MCTA CDA failure OM. RadioLinkSetupError is pegged whenever a call setup fails due to the fact that some BTS resource is not available. This OM is also pegged when the BTS does not respond or responds with a negative acknowledgment to resource requests. If MCTA is on, this OM is also pegged when CDA cant select a carrier due to resource shortages. This OM is pegged, along with RadioLinkSetupError and the appropriate blocking OM, any time a BTS reports no traffic channel element via NOIS messages regardless of origination or termination. This OM is never pegged with MCTACDABlocked since that error cases precedes radio link setup.
sheet 2 of 18
OriginationBl ocked
RadioLinkSet upError
10
TCEUnavaila ble
11
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of CDMA-LTX OMs (continued) Register Description
Reference chapter CDMA-LTX performanc e (page 181)
WalshCodeU navailable
This OM is pegged, along with RadioLinkSetupError and the appropriate blocking OM, any time a BTS reports no walsh code via NOIS messages regardless of origination or termination. This OM is never pegged with MCTACDABlocked since that error cases precedes radio link setup. This OM is pegged, along with RadioLinkSetupError and the appropriate blocking OM, any time a BTS reports forward capacity full via NOIS messages regardless of origination or termination. This OM is never pegged with MCTACDABlocked since that error cases proceeds radio link setup. This OM is coded for pegging, along with RadioLinkSetupError and the appropriate blocking OM, any time a BTS reports reverse capacity full via NOIS messages regardless of origination or termination. This OM is never pegged with MCTACDABlocked since that error cases proceeds radio link setup. However, currently there is no reliable mechanism for estimating reverse link capacity and so this response is disabled on the BTS. Consequently, this OM is never pegged. This OM is pegged when the LAU drops of the traffic channel after the CATRLM_RLMRadioLinkSetupRsp is received but before the CATSOM_SOMServiceConnectRsp is received. This scenario is considered an access failure. The register RadioLinkFailNoTrafficChannel is also pegged in conjunction with this register. This OM is pegged, along with the appropriate blocking OM, whenever a call setup fails due to time outs between software entities that should not occur (e.g. no response from the CN, failure message received from SBS, etc.). This OM is pegged when a LAU doesnt successfully arrive on the traffic channel due to RF problems. This peg could indicate inadequate coverage, interference issues, slow handoff, or simply an RF fade at a vulnerable time in the call setup.
sheet 3 of 18
ForwardCap acityFull
13
ReverseCap acityFull
14
CallDropLoss OfTraffic
15
FailedCallSof twareTimeou t
16
CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181)
RadioLinkFai lNoTrafficCh annel
17
CDMA
NBSS15.0
CallDropRadi oRelated
This OM is pegged by the BCM against the primary pilot when a call is dropped by the FWSBS due to loss of traffic or due to HCM (handoff completion message) timeout for soft or softer handoff. These are RF-related call failures as detected by the FWSBS. Note: The BCM pegs either CallDropRadioRelated or CallDropNetworkRelated whenever a call is dropped. This OM is pegged by the BCM when any of the other (non-RF) drop indication reasons are sent from the FWSBS in the radio link drop indication message. The following are the network-related call drop reasons that will cause CallDropNetworkRelated to be pegged: (1) RLM locked: Initiated by the network management during maintenance, the RLM is locked and hence the calls handled by that RLM should be dropped. (2) TCE locked: Initiated by the network management during maintenance, the TCE is locked and hence the calls using that TCE should be dropped. (3) Trunk problem: The selector (i.e. FWSBS) is taking down the call due to the DS0 becoming unavailable/unequipped (detected during maintenance). (4) Selector problem: The selector receives a request from the BCM to release FWSBS resources without going through the proper procedure of releasing the call. This is an error case. Note: The BCM pegs either CallDropRadioRelated or CallDropNetworkRelated whenever a call is dropped. This OM is pegged when the BCM receives a FWPAMI message during setup of a LAU-terminated call. The BCM pegs this OM on a system-wide basis. This OM is pegged when the BCM forwards a reverse link flash message to the LE. The BCM pegs this OM on a system-wide basis. This OM is pegged when the call is released by the LAU served by the BCM pegging this register. The BCM pegs this OM on a system-wide basis.
CallDropNet workRelated
19
CallingNumb erDuringTer mination FlashMessag e
CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181)
LAUInitiated Release
sheet 4 of 18
411-2133-525
Standard
06.12
April 2008
Reference chapter CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181)
LandRelease
This OM is pegged when the call is released by a party other than the LAU being served by the BCM pegging this register. This in not necessarily a Land Release. The BCM pegs this OM on a system-wide basis This OM is pegged when a frequency was successfully selected by MCTA but one or more of the BTSs never responded to a capacity request or responded with a resource full or not available response. This OM is pegged against each EBID which MCTA was unable to consider. MCTABTSFailure pegging is unlikely under low traffic load conditions. Under high traffic conditions, it may be pegged for multiple carriers. This OM is pegged along with a appropriate MCTACDAFailure* whenever MCTA cant select a frequency. This OM is pegged against the EBID on which the LAU made an access attempt. RadioLinkSetupError and the corresponding TerminationBlocked or OriginationBlocked are pegged with this OM. Note: The MCTA error case OMs are never pegged with the BTS blocking reason OMs (TCEUnavailable, WalshCodeUnavailable, ForwardCapacityFull). The MCTA error case OMs may only be pegged after a capacity query results in frequency selection failure due to BTS resource shortages. The BTS blocking reason OMs may only be pegged as a result of a resource shortage after a BTS resource is requested for the successfully selected frequency.
sheet 5 of 18
MCTABTSFa ilure
20
MCTACDABl ocked
10
CDMA
NBSS15.0
MCTACDAF ailureAllFull
This OM is pegged when NO frequency was successfully selected by MCTA because none of the BTSs had resources available. This OM is pegged against the EBID on which the LAU made an access attempt. RadioLinkSetupError, MCTACDABlocked, and the corresponding TerminationBlocked or OriginationBlocked are pegged with this OM. Note: The MCTA error case OMs are never pegged with the BTS blocking reason OMs (TCEUnavailable, WalshCodeUnavailable, ForwardCapacityFull). The MCTA error case OMs may only be pegged after a capacity query results in frequency selection failure due to BTS resource shortages. The BTS blocking reason OMs may only be pegged as a result of a resource shortage after a BTS resource is requested for the successfully selected frequency. This OM is pegged when NO frequency was successfully selected by MCTA because none of the BTSs responded to the capacity request query. This OM is pegged against the EBID on which the LAU made an access attempt. RadioLinkSetupError, MCTACDABlocked, and the corresponding TerminationBlocked or OriginationBlocked are pegged with this OM. Note: The MCTA error case OMs are never pegged with the BTS blocking reason OMs (TCEUnavailable, WalshCodeUnavailable, ForwardCapacityFull). The MCTA error case OMs may only be pegged after a capacity query results in frequency selection failure due to BTS resource shortages. The BTS blocking reason OMs may only be pegged as a result of a resource shortage after a BTS resource is requested for the successfully selected frequency.
sheet 6 of 18
MCTACDAF ailureAllTime dOut
22
411-2133-525
Standard
06.12
April 2008
MCTACDAF ailureMixed
This OM is pegged when NO frequency was successfully selected by MCTA because some BTSs timed-out while some responded with a resource full or not available response. This OM is pegged against the EBID on which the LAU made an access attempt. RadioLinkSetupError, MCTACDABlocked, and the corresponding TerminationBlocked or OriginationBlocked are pegged with this OM. Note: The MCTA error case OMs are never pegged with the BTS blocking reason OMs (TCEUnavailable, WalshCodeUnavailable, ForwardCapacityFull). The MCTA error case OMs may only be pegged after a capacity query results in frequency selection failure due to BTS resource shortages. The BTS blocking reason OMs may only be pegged as a result of a resource shortage after a BTS resource is requested for the successfully selected frequency. This OM is pegged when a LAU-originated call is released by the LAU or BSC before the LAU sends a service completion message. This OM is pegged when a frequency selected by MCTA is successfully setup at the BTS. This does not indicate that the entire call has been setup. This OM is pegged against the EBID which MCTA selected.
sheet 7 of 18
OriginationR eleased
CDMA-LTX performanc e (page 181) CDMA-LTX performanc e (page 181)
RadioResour ceAllocated
21
CDMA
NBSS15.0
FW PAM MO OMs
Fixed Wireless Paging and Access Manager. The OMs in this group are pegged on a System-wide basis. This OM is pegged each time a LAU is paged. This includes page retries in quick repeats. The FWPAM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Paging Performance.
PageReques ts
PageTimeOu t
This OM is pegged when the BSC does not receive a page response to any page. This includes each and every page timeout. If either page retry or quick-repeat paging is turned on, and both pages timeout, the OM gets pegged twice. The FWPAM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Paging Performance.
RspToPage1
The FWPAM pegs this OM when a terminating LAU responds on the first page attempt when page retries are turned on. If quick-repeated paging is turned on, this OM pegs when the LAU responds to any of the quick-repeated pages. The FWPAM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
12
sheet 8 of 18
411-2133-525
Standard
06.12
April 2008
RspToPage2
The FWPAM pegs this OM when a terminating LAU responds on a page retry attempt. This OM is not pegged if quick-repeated paging is turned on. The FWPAM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
Originations
This OM is pegged immediately when the FWPAM receives an origination from the LAU. This OM is pegged before any screening is performed on the LAU. The FWPAM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
Registrations
This OM is pegged when the FWPAM receives a registration notification from the LAU. The FWPAM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
UnexpectedP ageRespons e
This OM is pegged when a page response has been received after the corresponding page attempt has timed out or at any other time a page response is not expected. The FWPAM pegs this OM on a systemwide basis. Note: This OM is used to measure CDMA-LTX Paging Performance.
sheet 9 of 18
CDMA
NBSS15.0
OrigSubscrib erUnavailabl e
This OM is pegged when the originating subscriber lookup fails in the FSD. OriginationAttempts is never pegged with this OM. The FWPAM pegs this on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
TermSubscri berUnavailab le
This OM is pegged when the terminating subscriber lookup fails in the FSD. PageReponse is never pegged with this OM. The FWPAM pegs this on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
OrigSubscrib erMobilityRe stricted
This OM is pegged when a call setup is denied because a LAU attempted an origination outside its serving cell list defined by the FSD. OriginationAttempts is never pegged with this OM. The FWPAM pegs this on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
TermSubscri berMobilityR estricted
This OM is pegged when a call setup is denied because a LAU attempted a termination outside its serving cell list defined by the FSD. PageReponse is never pegged with this OM. The FWPAM pegs this on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
sheet 10 of 18
411-2133-525
Standard
06.12
April 2008
FW BCM MO OMs
Resource Manager. The OMs in this group are pegged on a System-wide basis.
RMServiceR esourceNAK
This OM is pegged, along with the appropriate blocking OM, by the SBS when a Resource Manager receives a resource allocation failure indication from an SRM. This is an error condition, indicating mismatches between the RM and the FWSBS SRM. The RM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
RMSRMTime Out
This is pegged, along with the appropriate blocking OM, by SBS when a RM times out waiting on a request for call resources from a SRM. The RM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
RMNoAvaila bleResource s
This OM is pegged, along with the appropriate blocking OM, by the SBS when a Resource Manager has no available resources to allocate for a call. In this case, the RM does not message to any SBS entity to determine availability, only internal data structures are checked. The RM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
sheet 11 of 18
CDMA
NBSS15.0
RMUnsuppor tedServiceO ption
This OM is pegged whenever an origination setup fails because the origination message contained an unknown or unsupported service option. This OM can also be pegged whenever a page response message indicates an unknown or unsupported service option. RMUnsupportedServiceOption is not pegged in cases where the blocking OMs are pegged. The RM pegs this OM on a system-wide basis. Note: This OM is used to measure CDMA-LTX Call Setup Performance.
sheet 12 of 18
411-2133-525
Standard
06.12
April 2008
FW CSD OMs
Fixed Wireless Circuit Switched. The OMs in this group are pegged on a per Service Option basis, except for PortUsage which pegs on a per V5.2 Interface basis. This OM is pegged when the SCI-S receives an origination for a LAU-originated data call. Note: This OM is used to measure CDMA-LTX CSD Performance.
DataCallOrigi nationAttemp t
DataCallOrigi nationCompl eted
This OM is pegged when the SCI-S receives an indication that the IWF connection between the originator and the terminator is established. Note: This OM is used to measure CDMA-LTX CSD Performance.
DataCallTer minationAtte mpt
This OM is pegged when the SCI-S receives the page response message from the LAU terminating a data call. Note: This OM is used to measure CDMA-LTX CSD Performance.
DataCallTer minationCom pleted
This OM is pegged when the SCI-S receives an indication that the IWF connection between the originator and the terminator is established. Note: This OM is used to measure CDMA-LTX CSD Performance.
sheet 13 of 18
CDMA
NBSS15.0
DataCallAbn ormalReleas e
This OM is pegged when the SCI-S receives an abnormal release from the IWF before an IWF connection is established between the originator and the terminator. Note: This OM is used to measure CDMA-LTX CSD Performance.
DataCallMIT Request
This OM is pegged when the SCI-S receives a MIT request. Note: This OM is used to measure CDMA-LTX CSD Performance.
DataCallMIT Acknowledge
This OM is pegged when the SCI-S acknowledges a MIT request. Note: This OM is used to measure CDMA-LTX CSD Performance.
PortUsage
This OM is pegged when the SCI-S sends or receives an Establish message to the LE. This message indicates the V5.2 port (subscriber) is in use. This OM is useful in monitoring the load distribution across V5.2 interfaces. There number of pegs in this OM should roughly match BCCSuccessfulAllocations. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
sheet 14 of 18
411-2133-525
Standard
06.12
April 2008
V5.2 Interface Layer 3 OMs BCCSuccess fulAllocations
V5.2 Interface Layer 3. The OMs in this group are pegged on a per V5.2 Interface basis.
This OM is pegged when the SCI-S receives an Allocate message from LE to allocate a circuit for a LAU during call setup. The VPA pegs this OM on a per-V5.2 Interface basis. This OM is useful in monitoring the load distribution across V5.2 interfaces. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
BCCAllocatio nRejects
This OM is pegged during a race condition or during a software anomaly where the VPA is not able to setup a V5.2 circuit for the call. This OM should be very rarely pegged. The VPA pegs this OM on a per-V5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
BCCSuccess fulDeallocatio ns
This OM is pegged when the VPA tears down the V5.2 circuit at the end of a call. The VPA pegs this OM on a per-V5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
sheet 15 of 18
CDMA
NBSS15.0
BCCDealloca tionRejects
This OM is pegged when the VPA cant tear down the V5.2 circuit. This OM should never be pegged. The VPA pegs this OM on a per-V5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
sheet 16 of 18
411-2133-525
Standard
06.12
April 2008
V5.2 Link Layer 2 OMs
V5.2 Link Layer 2. The OMs in this group are pegged on a per V5.2 link layer 2 Interface basis.
EFBytesRec eived
This OM is pegged once for each byte received in a valid Envelope Function frame. The VPA pegs this OM on a per-V5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
EFFramesRe ceived
This OM is pegged once for each valid Envelope Function frame received. The VPA pegs this OM on a per-V5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
EFFramesAb orted
This OM is pegged once for each received Envelope Function frame that was aborted. The VPA pegs this OM on a per-V5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
sheet 17 of 18
CDMA
NBSS15.0
EFFramesBa dFCS
This OM is pegged once for each Envelope Function frame received with bad error checking information. The VPA pegs this OM on a per-V5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
EFFramesTo oShort
This OM is pegged once Envelope Function frames received which were too short. Frames less than 5 bytes are too short. The VPA pegs this OM on a perV5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
Chapter 18, CDMA-LTX performanc e
EFFramesTo oLong
This OM is pegged once Envelope Function frames received which were too long. Frames longer than 266 bytes are too long. The VPA pegs this OM on a perV5.2 Interface basis. Note: This OM is used to measure CDMA-LTX V5.2 Protocol Adaptor Performance. OM is provided as required by the V5.2 specification requirements. This OM provides information to monitor load distribution and general V5.2 protocol operation.
sheet 18 of 18
411-2133-525
Standard
06.12
April 2008
Nortel Networks
BTS OM descriptions 23-1 Copyright 2008 Nortel Networks
BTS OM descriptions
23
This chapter lists all the BTS OMs discussed in the CDMA System Performance Operational Measurements guide. This chapter also includes other CDMA specific BTS OMs which are not used in any metric but are useful for more information. This chapter contains the detailed descriptions, reference chapter, and sequence number (if applicable) for each of the OMs. The OMs are sorted by OM group. Each performance attribute (OM) in the BTS has a unique sequence number which helps identify it from the raw data in text format. When logfilter is applied to the OM data received from the BTS, a text file is generated which provides the name of the performance attribute along with its value. The EBID based performance attributes are reported separately from the Node based (system-wide) performance attributes when raw data is parsed. Thus, the sequence numbers of EBID based and Node based performance attributes belonging to the same Managed objects may be the same in some cases. When MCTA is enabled and there is more than one DCG co-located per site (i.e. more than one DCG per Metro cell or more than one Metro cell per site), the BSC sends a Capacity Request message to each co-located DCG in the site in order to get the capacity estimates for all the co-located carriers. The call setup BTS OMs do not get pegged as a result of the Capacity Request message from the SBS. Only when the BSC sends a Resource Request message to the DCG in order to setup BTS resources for the call, the appropriate BTS OMs would get pegged. Note: OMs with no reference chapter are listed merely for completeness.
CDMA
NBSS15.0
23-2 BTS OM descriptions Nortel Networks
Metro Cell BTS operational measurements
23
The following table contains performance attributes from Advanced Frequency Assignment MO, Advanced Sector MO, BTS Call Processing MO, Power Management MO, BTSC MO and Radio sector MO for Metro cell.
List of Metro Cell BTS OMs Register Description Sequence number (if applicable) Reference chapter BTS performance (page 9-1) 23 BTS performance (page 9-1)
Advanced FA MO OMs NumOfTCAvail able Modified in Release 12.0 TCEUtilMaxim um TotalForwardP hysicalResourc es Modified in Release 12.0 SchMaximumF orwardPhysical ResourcesUse d Fch2GMaximu mForwardPhys icalResources Used Fch3GMaximu mForwardPhys icalResources Used
These OMs are pegged on a per carrier basis for a BTS. Pegged to indicate the number of traffic channel elements available for traffic on a CCEM/ECEM, whether they are active or idle at report time, and exclude the channel elements that are being used for overhead channels for the carrier. This OM provides the peak number of channel elements in use simultaneously during this half hour Pegged to indicate the number of forward physical resources that are available for traffic on a XCEM, whether they are active or idle at report time, and exclude the physical resources that are being used for overhead channels for the carrier. This OM is a high water mark for the number of XCEM resources being used for the forward supplemental channel at any time during the reporting period. This OM is a high water mark for the number of XCEM resources being used for 2G calls on the forward fundamental channel at any time during the reporting period. This OM is a high water mark for the number of XCEM resources being used for 3G calls on the forward fundamental channel at any time during the reporting period.
sheet 1 of 92
24
BTS performance (page 9-1) BTS performance (page 9-1)
72
74
BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
75
76
411-2133-525
Standard
06.12
April 2008
Nortel Networks List of Metro Cell BTS OMs (continued) Register Description
Reference chapter BTS performance (page 9-1)
TotalReverseP hysicalResourc es Modified in Release 12.0 SchMaximumR eversePhysical ResourcesUse d Fch2GMaximu mReversePhys icalResources Used Fch3GMaximu mReversePhys icalResources Used MaxFwdPhysic alResourcesUs ed New OM in 13.0 release MaxRevPhysic alResourcesUs ed New OM in 13.0 release MaxFCHVoice ResourcesUse d New OM in 13.0 release
Pegged to indicate the number of reverse physical resources that are available for traffic on a XCEM, whether they are active or idle at report time, and exclude the physical resources that are being used for overhead channels for the carrier. This OM is a high water mark for the number of XCEM resources being used for the reverse supplemental channel at any time during the reporting period. This OM is a high water mark for the number of XCEM resources being used for 2G calls on the reverse fundamental channel at any time during the reporting period. This OM is a high water mark for the number of XCEM resources being used for 3G calls on the reverse fundamental channel at any time during the reporting period. This OM represents the peak number of XCEM physical resources being used simultaneously for all calls on the forward channel (FCH and SCH) at any time during the reporting period.
79
BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
80
81
88
This OM represents the peak number of XCEM physical resources being used simultaneously for all calls on the reverse channel (FCH and SCH) at any time during the reporting period.
89
BTS performance (page 9-1)
This OM represents the peak number of XCEM physical resources being used simultaneously for Voice calls (2G and 3G) on the fundamental channel (forward and reverse) at any time during the reporting period.
sheet 2 of 92
90
CDMA
NBSS15.0
23-4 BTS OM descriptions Nortel Networks List of Metro Cell BTS OMs (continued) Register Description
MaxFCHDataR esourcesUsed New OM in 13.0 release
This OM represents the peak number of XCEM physical resources being used simultaneously for 3G packet data calls on the fundamental channel (forward and reverse) at any time during the reporting period.
sheet 3 of 92
411-2133-525
Standard
06.12
April 2008
Advanced Sector MO OMs
The OMs in this group are pegged on a per SectorFreq basis for conventional sectors. For AABS sectors, the OMs are pegged on a per BeamFrequency basis. Please note that the OMs with sequence number 47 to 49, 97 to 107, 128, 130, 132, 235 to 259 are replaced by 309 to 350 respectively in 14.0 release. This OM is an array of access attempts, successes, and failures for each Rural Cell access ring in the sector This OM provides number of radial handoff attempts (ECEMs only) 70
PerRingAccess Counts RadialHandoff Attempts
BTS performance (page 9-1) BTS performance (page 9-1) Handoff performance (page 7-1)
71
RadialHandoff Successes
This OM provides number of successful radial handoffs attempts (ECEMs only)
72
BTS performance (page 9-1) Handoff performance (page 7-1)
RadialHandoff Failures
This OM provides number of failed radial handoff attempts (ECEMs only)
73
sheet 4 of 92
CDMA
NBSS15.0
FchOrigination NonBlocking2 G
This OM provides number of successful BTS resource allocations for 2G calls. This is not an indication of successful call attempts. This metric does not include calls that were allocated for 2G after being downgraded from 3G. This metric also does not include non-reference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. This OM is an array of 2 elements indicating the number of successful BTS resource allocations for 2G handoffs. The first element in the array (i.e. FchHandoffNonBlocking2G[0]) represents the number of successful BTS resource allocations for a 2G non VPN-based soft handoff. The second element in the array (i.e. FchHandoffNonBlocking2G[1]) represents the number of successful BTS resource allocations for a 2G VPN-based soft handoffs. Note that This OM is not an indication of successful handoffs. Note that this metric also includes non-reference pilot links setup for CASHO. This OM provides number of successful BTS resource allocations for 3G voice calls on the fundamental channel. This is not an indication of successful call attempts. This metric does not include non-reference pilot links setup for CASHO. 3G voice links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking3GVoice. This OM provides number of successful BTS resource allocations for 3G data calls on the fundamental channel. This is not an indication of successful call attempts. This metric does not include non-reference pilot links setup for CASHO. 3G data links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking3GData.
sheet 5 of 92
FchHandoffNo nBlocking2G
109
FchOrigination NonBlocking3 GVoice
110
FchOrigination NonBlocking3 GData
111
411-2133-525
Standard
06.12
April 2008
FchOrigination NonBlocking3 GDowngrade2 G
This OM provides number of successful BTS resource allocations for fundamental channel 2G calls which were downgraded from 3G calls attempts. This metric does not include nonreference pilot links setup for CASHO. 2G links, other than the reference pilots link, setup for CASHO are pegged under FchHandoffNonBlocking2G. This OM provides number of successful BTS resource allocations for 3G voice handoffs on the fundamental channel. Note that This is not an indication of successful handoffs.
FchHandoffNo nBlocking3GVo ice
113
FchHandoffNo nBlocking3GD ata
This OM provides number of successful BTS resource allocations for 3G data handoffs on the fundamental channel. Note that This is not an indication of successful handoffs.
114
SchBurstNonBl ocking3G
This OM provides number of successful BTS resource allocations for 3G data bursts on the supplemental channel. This is not an indication of successful data bursts. Note: This OM is removed in the 12.1 release, and is replaced by (NonQueuedFwdSchBurstNonBlocking3G, QueuedFwdSchBurstNonBlocking3G, and RevSchBurstNonBlocking3G) OM arrays. See seq # 207, 208, and 209
115
sheet 6 of 92
CDMA
NBSS15.0
Reference chapter BTS performance (page 9-1) Handoff performance (page 7-1)
SchHandoffNo nBlocking3G
This OM provides number of successful BTS resource allocations for 3G data handoffs on the supplemental channel. Note that This is not an indication of successful handoffs.
BlockedFchOri ginations2G Modified in 12.1 Release BlockedFchOri ginations2G[0]: No physical resources BlockedFchOri ginations2G[1]: No forward capacity BlockedFchOri ginations2G[2]: No reverse capacity BlockedFchOri ginations2G[3]: No walsh code
This OM is an array indicating the number of 2G call attempts blocked on the fundamental channel. Each array element corresponds to a different blocking reason. The blocking reasons are described below beginning with the first array element. This element is pegged when the CCEMs and XCEMs in the sector could not support additional calls. More CCEMs or XCEMs may be needed. This element is pegged when the BTS forward power level surpassed the level defined by the CallBlockingThreshold or MaxVoiceResources. Reverse link blocking is not supported.
117
Chapter 9, BTS performance
part of 117
part of 117
part of 117
This element is pegged when blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxVoiceResources. If this blocking reason is consistently higher than No forward capacity, the system may be walsh code limited. In that case (if the carrier supports 2G and 3G Calls), the operator should consider an optimum setting for RCDA_Voice_Selection Parameter to bias call setup using RC4 or consider setting RC4_Preferred = True to increase Walsh code availability at the expense of forward power and/or add another carrier. Please refer to NTP 411-2133-526 for RCDA (Radio Configuration Determination Algorithm).
sheet 7 of 92
part of 117
411-2133-525
Standard
06.12
April 2008
Sequence number (if applicable) part of 117
BlockedFchOri ginations2G[4]: No frame offset
The XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. This element in the array is not valid for 2G Calls.
BlockedFchOri ginations2G[5]: No Extended Cell Support BlockedFchOri ginations2G[6]: CFDS Radio Config State
part of 117
BTS performance (page 9-1) BTS performance (page 9-1) Handoff performance (page 7-1)
This element is pegged when blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Re configuration of this attribute may be needed.
part of 117
BlockedFchOri ginations2G[7]: CFDS HS RSCH BlockedFchOri ginations2G[8]: Exceeded Max Data Rate New OM in 12.1 release BlockedFchOri ginations2G[9]: Exceeded CPU Capacity New OM in 12.1 release
This element in the array is not valid for 2G Calls.
part of 117
This element in the array is not a valid blocking reason for 2G calls.
part of 117
This element is pegged when the XCEM cards CPU in the sector could not support additional 2G calls. More XCEMs may be needed.
part of 117
sheet 8 of 92
CDMA
NBSS15.0
BlockedFchOri ginations2G[10 ]: Queue Full New OM in 12.1 release BlockedFchOri ginations2G[11 ]: Exceeded BCN Capacity New OM in 13.0 release BlockedFchOri ginations2G[12 ]: Exceeded Backhaul Capacity New OM in 13.0 release
This element in the array is not a valid blocking reason for 2G calls.
This OM corresponds to blocks of new call setups that would have exceeded the available capacity of the BCN link(s) between the CEM(s) and the DCG. This blocking prevents BCN link over utilization in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision additional CEM resources (e.g., CCEMS, XCEMs, etc.). This OM corresponds to blocks of new call setups that would have exceeded the available capacity of the BTS backhaul link(s). This blocking prevents over utilization of backhaul resources in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision either additional backhaul resources (e.g., T1s, E1s, etc.) in the current cell, or a new cell (if all available backhaul ports are utilized on current cell). This OM corresponds to blocks of new call setups when an ACN ID cannot be allocated due to lack of available addresses. Frequent pegging of this OM may indicate the need to provision an additional cell.
part of 117
part of 117
BlockedFchOri ginations2G[13 ]: Out of ACN Addresses New OM in 13.0 release
part of 117
Note: This blocking reason, although theoretically possible, is very unlikely to occur.
sheet 9 of 92
411-2133-525
Standard
06.12
April 2008
BlockedFchHa ndoffs2G
Array indicating the number of 2G soft handoffs blocked on the fundamental channel. Each array element corresponds to a different blocking reason. The blocking reasons are the same as those described under BlockedFchOriginations2G with the following exceptions: The element BlockedFchHandoffs2G[1]: No forward capacity will get pegged if the BTS forward power level surpassed the level HandoffBlockingThreshold. The element BlockedFchHandoffs2G[5]: No Extended Cell Support in the array is valid. It is pegged when either the ECEMs in the sector could not support additional handoffs, or no ECEMs are available at all to support any VPN-based soft handoffs. More ECEMs may be needed.
BlockedFchOri ginations3GVoi ce Modified in 12.1 Release BlockedFchOri ginations3GVoi ce[0]: No physical resources BlockedFchOri ginations3GVoi ce[1]: No forward capacity BlockedFchOri ginations3GVoi ce[2]: No reverse capacity
This OM is an array indicating the number of 3G voice call attempts blocked on the fundamental channel. Each array element corresponds to a different blocking reasons. The blocking reasons are described below beginning with the first array element. This element is pegged when the XCEMs in the sector could not support additional 3G voice calls. More XCEMs may be needed. This element would also get pegged if the call could not get downgraded to 2G, due to lack of physical resources at the BTS. This element is pegged when the BTS forward power level surpassed the level defined by the call blocking threshold or MaxVoiceResources.
119
part of 119
part of 119
Reverse link blocking is not supported.
part of 119
sheet 10 of 92
CDMA
NBSS15.0
BlockedFchOri ginations3GVoi ce[3]: No walsh code
This element is pegged when blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxVoiceResources. If this blocking reason is consistently higher than No forward capacity, the system may be walsh code limited. In that case, the operator should consider an optimum setting for RCDA_Voice_Selection Parameter to bias call setup using RC4 or consider setting RC4_Preferred = True to increase Walsh code availability at the expense of forward power and/or add another carrier. Please refer to NTP 411-2133526 for RCDA (Radio Configuration Determination Algorithm). The XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. This element in the array is not valid for 3G Voice Calls.
BlockedFchOri ginations3GVoi ce[4]: No frame offset BlockedFchOri ginations3GVoi ce[5]: No Extended Cell Support BlockedFchOri ginations3GVoi ce[6]: CFDS Radio Config State
part of 119
part of 119
This element is pegged when blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Reconfiguration of this attribute may be needed.
part of 119
Call setup performance (page 2-1) BTS performance (page 9-1)
BlockedFchOri ginations3GVoi ce[7]: CFDS HS RSCH
This element in the array is not valid for 3G Voice Calls.
part of 119
sheet 11 of 92
411-2133-525
Standard
06.12
April 2008
BlockedFchOri ginations3GVoi ce[8]: Exceeded Max Data Rate New OM in 12.1 release BlockedFchOri ginations3GVoi ce[9]: Exceeded CPU Capacity New OM in 12.1 release BlockedFchOri ginations3GVoi ce[10]: Queue Full New OM in 12.1 release BlockedFchOri ginations3GVoi ce[11]: Exceeded BCN Capacity New OM in 13.0 release
This element in the array is not a valid blocking reason for 3G voice calls.
This element is pegged when the XCEM cards CPU in the sector could not support additional 3G voice calls. More XCEMs may be needed.
part of 119
This element in the array is not a valid blocking reason for 3G voice calls.
part of 119
This OM corresponds to blocks of new call setups that would have exceeded the available capacity of the BCN link(s) between the CEM(s) and the DCG. This blocking prevents BCN link over utilization in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision additional CEM resources (e.g., XCEMs, etc.).
sheet 12 of 92
part of 119
CDMA
NBSS15.0
BlockedFchOri ginations3GVoi ce[12]: Exceeded Backhaul Capacity New OM in 13.0 release BlockedFchOri ginations3GVoi ce[13]: Out of ACN Addresses New OM in 13.0 release BlockedFchOri ginations3GDat a Modified in 12.1 Release BlockedFchOri ginations3GDat a[0]: No physical resources BlockedFchOri ginations3GDat a[1]: No forward capacity
This OM corresponds to blocks of new call setups that would have exceeded the available capacity of the BTS backhaul link(s). This blocking prevents over utilization of backhaul resources in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision either additional backhaul resources (e.g., T1s, E1s, etc.) to the current cell, or a new cell (if all available backhaul ports are utilized on the current cell). This OM corresponds to blocks of new call setups when an ACN ID cannot be allocated due to lack of available addresses. Frequent pegging of this OM may indicate the need to provision an additional cell. Note: This blocking reason, although theoretically possible, is very unlikely to occur.
part of 119
This OM is an array indicating the number of 3G data sessions blocked on the fundamental channel. Each array element corresponds to a different blocking reason. The blocking reasons are described below beginning with the first array element. This element is pegged when XCEMs in the sector could not support additional calls. More XCEMs may be needed.
120
part of 120
This element is pegged when the BTS forward power level surpassed the level defined by the CallBlockingThreshold or MaxDataResources.
part of 120
sheet 13 of 92
411-2133-525
Standard
06.12
April 2008
BlockedFchOri ginations3GDat a[2]: No reverse capacity BlockedFchOri ginations3GDat a[3]: No walsh code
Reverse link blocking is not supported.
This element is pegged when Blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxDataResources. If this blocking reason is consistently higher than No forward capacity, the system may be walsh code limited. In that case, the operator should consider setting RC4_Preferred = True to increase Walsh code availability at the expense of forward power. This element is pegged when the XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. This element in the array is not valid for 3G Data Calls.
part of 120
BlockedFchOri ginations3GDat a[4]: No frame offset BlockedFchOri ginations3GDat a[5]: No Extended Cell Support BlockedFchOri ginations3GDat a[6]: CFDS Radio Config State
part of 120
part of 120
This element is pegged when blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Reconfiguration of this attribute may be needed.
part of 120
Call setup performance (page 2-1) BTS performance (page 9-1)
BlockedFchOri ginations3GDat a[7]: CFDS HS RSCH
This element in the array is not valid for 3G Data Calls FCH Setup.
part of 120
sheet 14 of 92
CDMA
NBSS15.0
BlockedFchOri ginations3GDat a[8]: Exceeded Max Data Rate New OM in 12.1 release BlockedFchOri ginations3GDat a[9]: Exceeded CPU Capacity New OM in 12.1 release BlockedFchOri ginations3GDat a[10]: Queue Full New OM in 12.1 release BlockedFchOri ginations3GDat a[11]: Exceeded BCN Capacity New OM in 13.0 release BlockedFchOri ginations3GDat a[12]: Exceeded Backhaul Capacity New OM in 13.0 release
This element in the array is not a valid blocking reason for 3G Data calls.
This element is pegged when the XCEM cards CPU in the sector could not support additional 3G Data calls. More XCEMs may be needed.
part of 120
This element in the array is not a valid blocking reason for 3G Data calls.
part of 120
This OM corresponds to blocks of new call setups that would have exceeded the available capacity of the BCN link(s) between the CEM(s) and the DCG. This blocking prevents BCN link over utilization in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision additional CEM resources (e.g., XCEMs, etc.). This OM corresponds to blocks of new call setups that would have exceeded the available capacity of the BTS backhaul link(s). This blocking prevents over utilization of backhaul resources in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision either additional backhaul resources (e.g., T1s, E1s, etc.) in the current cell, or a new cell (if all available backhaul ports are utilized in the current cell).
sheet 15 of 92
part of 120
part of 120
411-2133-525
Standard
06.12
April 2008
BlockedFchOri ginations3GDat a[13]: Out of ACN Addresses New OM in 13.0 release BlockedFchHa ndoffs3GVoice
This OM corresponds to blocks of new call setups when an ACN ID cannot be allocated due to lack of available addresses. Frequent pegging of this OM may indicate the need to provision an additional cell. Note: This blocking reason, although theoretically possible, is very unlikely to occur.
This OM is an array indicating the number of 3G voice soft handoffs blocked on the fundamental channel. Each array element corresponds to a different blocking reason. The blocking reasons are the same as those described under BlockedFchOriginations3GVoice with the following exceptions: The element BlockedFchHandoffs3GVoice[1]: No forward capacity will get pegged if the BTS forward power level surpassed the level of HandoffBlockingThreshold. The element BlockedFchHandoffs3GVoice[5]: No Extended Cell Support is valid. This element is pegged every time there is a 3G VPN - based soft handoff attempt.
sheet 16 of 92
121
CDMA
NBSS15.0
BlockedFchHa ndoffs3GData
This OM is an array indicating the number of 3G data soft handoffs blocked on the fundamental channel. Each array element corresponds to a different blocking reason. The blocking reasons are the same as those described under BlockedFchOriginations3GData with the following exceptions: For the element BlockedFchHandoffs3GData[1]: No forward capacity will get pegged if the BTS forward power level surpassed the level of HandoffBlockingThreshold. The element BlockedFchHandoffs3GData[5]: No Extended Cell Support in the array is valid. This element is pegged every time there is a 3G VPN based soft handoff attempt.
BlockedSchBur sts Modified in 12.1 Release BlockedSchBur sts[0]: No physical resources BlockedSchBur sts[1]: No forward capacity BlockedSchBur sts[2]: No reverse capacity
This OM is an array indicating the number of 3G data bursts blocked on the supplemental channel. Each array element corresponds to a different blocking reason. The blocking reasons are described below beginning with the first array element. This element is pegged when XCEMs in the sector could not support additional calls. More XCEMs may be needed. This element is pegged when the BTS forward power level surpassed the level defined by the call blocking threshold or MaxDataResources. Reverse link blocking is not supported.
123
part of 123
part of 123
part of 123
sheet 17 of 92
411-2133-525
Standard
06.12
April 2008
BlockedSchBur sts[3]: No walsh code
This element is pegged when blocking occurred because all Walsh codes had been allocated. This includes scenarios where Walsh codes are regulated by MaxVoiceResources. If this blocking reason is consistently higher than No forward capacity, the system may be walsh code limited. In that case, the operator should consider setting RC4_Preferred to increase Walsh code availability at the expense of forward power. The XCEM supports a fixed number of calls per frame offset. This metric corresponds to blocks that were a result of an XCEMs inability to support the needed frame offset. This metric is not applicable to CCEMs. This element in the array is not a valid blocking reason for SCH Bursts.
BlockedSchBur sts[4]: No frame offset
part of 123
BlockedSchBur sts[5]: No Extended Cell Support BlockedSchBur sts[6]: CFDS Radio Config State
part of 123
BTS performance (page 9-1) Call setup performance (page 2-1) BTS performance (page 9-1)
Blocking occurred because the CFDS RadioConfigState attribute is configured in such a way that does not allow the specific type of call requested to be setup. Reconfiguration of this attribute may be needed.
part of 123
BlockedSchBur sts[7]: CFDS HS RSCH
This element in the array is valid only for R-SCH Bursts. It is pegged when the EnableHSReverseSchFeature attribute is set to FALSE. This attribute is used to screen for high data rate R-SCH bursts (i.e. when set to FALSE, only data rates of 9600 bps are allowed). Re configuration of this attribute may need to be considered.
sheet 18 of 92
part of 123
CDMA
NBSS15.0
BlockedSchBur sts[8]: Exceeded Max Data Rate New OM in 12.1 release BlockedSchBur sts[9]: Exceeded CPU Capacity New OM in 12.1 release BlockedSchBur sts[10]: Queue Full New OM in 12.1 release
This element in the array is not a valid blocking reason for SCH Bursts.
This element is pegged when the XCEM cards CPU in the sector could not support additional bursts. More XCEMs may be needed.
part of 123
This element is pegged when BTS resources could not be setup for the SCH burst setup request, and the request could not even be placed in the scheduler queue as it is full. When Queue Full is pegged, one of the other reason codes (i.e. other elements of this array) that prevented the burst from being allocated is also pegged (as allocation attempt is made prior to queuing the burst). This OM corresponds to blocks of F-SCH setups that would have exceeded the available capacity of the BCN link(s) between the CEM(s) and the DCG. This blocking prevents BCN link over utilization in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision additional CEM resources (e.g., XCEMs, etc.). This OM corresponds to blocks of F-SCH setups that would have exceeded the available capacity of the BTS backhaul link(s). This blocking prevents over utilization of backhaul resources in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision either additional backhaul resources (e.g., T1s, E1s, etc.) in the current cell, or a new cell (if all available backhaul ports are utilized in the current cell).
sheet 19 of 92
part of 123
BlockedSchBur sts[11]: Exceeded BCN Capacity New OM in 13.0 release BlockedSchBur sts[12]: Exceeded Backhaul Capacity New OM in 13.0 release
part of 123
part of 123
411-2133-525
Standard
06.12
April 2008
BlockedSchBur sts[13]: Out of ACN Addresses New OM in 13.0 release
This OM corresponds to blocks of F-SCH call setups when an ACN ID cannot be allocated due to lack of available addresses. Frequent pegging of this OM may indicate the need to provision an additional cell. Note: This blocking reason, although theoretically possible, is very unlikely to occur.
BlockedSchHa ndoffs Modified in 12.1 release
This OM is an array indicating the number of 3G data soft handoffs blocked on the supplemental channel. Each array element corresponds to a different blocking reason. The blocking reasons are the same as those described under BlockedSchBursts with the following exceptions: The element BlockedSchHandoffs[1]: No forward capacity in the array will get pegged if the BTS forward power level surpassed the level HandoffBlockingThreshold. The elements {(BlockedSchHandoffs[5]: No Extended Cell Support), (BlockedSchHandoffs[8]: Exceeded Max Data Rate)} are not valid blocking reasons for SCH Handoffs as well. The element {BlockedSchHandoffs[10]: Queue Full}is not a valid blocking reason for SCH Handoffs.
124
PagingChannel MessageCount Deleted in 14.0 release PagingChannel MessageDropp ed Deleted in 14.0 release Note: This OM has been deleted. Information provided by this OM is captured by PagingChannelMessageReceivedCount OM (Sequence number 268) introduced in 14.0 release.
Note: This OM has been deleted. Information provided by this OM is captured by PagingChannelMessageDroppedCount OM (Sequence number 269) introduced in 14.0 release.
sheet 20 of 92
CDMA
NBSS15.0
PagingChannel UsageInfo Added in 11.0 release
This is an array representing the paging channel usage during 30 minutes (1800 seconds) indicating the time duration in seconds during which the paging channel was operating within a certain occupancy range of 5% (i.e. 0% - 4%, 5% - 9%,... and 95%- 100%). Range N1% - N2% encompasses all values between N1 and less than (N2+1). For example, range 0% - 4% encompasses all values between 0 and < 5. The sample period for calculating the occupancy range is 1.28 seconds, equivalent to 16 slots. The first field of the array represents the number of supported paging channels, and then followed by 25 fields in the array for each supported paging channel. Thus the size of the array is dependent upon how many paging channels are configured. The different fields of the array are described below.
PagingChannel UsageInfo[0]: NumberOfPagi ngChannels PagingChannel UsageInfo[1]: PagingChannel Number PagingChannel UsageInfo[2]: PeakOccupanc y PagingChannel UsageInfo[3]: PeakDuration PagingChannel UsageInfo[4]: LowerBoundOf AvgOccupancy
The number of configured paging channels for the sector-carrier.
part of 141
BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
Identify a paging channel for the sector-carrier for which the following usage data are describing
part of 141
The upper bound + 1 of the peak occupancy range for the paging channel.
part of 141
The number of seconds indicating how long the paging channel was operating within the peak occupancy range. The lower bound of the average occupancy for the paging channel.
part of 141
part of 141
sheet 21 of 92
411-2133-525
Standard
06.12
April 2008
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
PagingChannel UsageInfo[5]: UpperBoundOf AvgOccupancy PagingChannel UsageInfo[6]: Range0to4 PagingChannel UsageInfo[7]: Range5to9 PagingChannel UsageInfo[8]: Range10to14 PagingChannel UsageInfo[9]: Range15to19 PagingChannel UsageInfo[10]: Range20to24 PagingChannel UsageInfo[11]: Range25to29 PagingChannel UsageInfo[12]: Range30to34 PagingChannel UsageInfo[13]: Range35to39 PagingChannel UsageInfo[14]: Range40to44 PagingChannel UsageInfo[15]: Range45to49
The upper bound of the average occupancy for the paging channel.
The number of seconds that the paging channel was operating within the occupancy range of 0% to 4%. The number of seconds that the paging channel was operating within the occupancy range of 5% to 9% The number of seconds that the paging channel was operating within the occupancy range of 10% to 14% The number of seconds that the paging channel was operating within the occupancy range of 15% to 19% The number of seconds that the paging channel was operating within the occupancy range of 20% to 24% The number of seconds that the paging channel was operating within the occupancy range of 25% to 29% The number of seconds that the paging channel was operating within the occupancy range of 30% to 34% The number of seconds that the paging channel was operating within the occupancy range of 35% to 39% The number of seconds that the paging channel was operating within the occupancy range of 40% to 44% The number of seconds that the paging channel was operating within the occupancy range of 45% to 49%
sheet 22 of 92
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
CDMA
NBSS15.0
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
PagingChannel UsageInfo[16]: Range50to54 PagingChannel UsageInfo[17]: Range55to59 PagingChannel UsageInfo[18]: Range60to64 PagingChannel UsageInfo[19]: Range65to69 PagingChannel UsageInfo[20]: Range70to74 PagingChannel UsageInfo[21]: Range75to79 PagingChannel UsageInfo[22]: Range80to84 PagingChannel UsageInfo[23]: Range85to89 PagingChannel UsageInfo[24]: Range90to94 PagingChannel UsageInfo[25]: Range95to99
The number of seconds that the paging channel was operating within the occupancy range of 50% to 54% The number of seconds that the paging channel was operating within the occupancy range of 55% to 59% The number of seconds that the paging channel was operating within the occupancy range of 60% to 64% The number of seconds that the paging channel was operating within the occupancy range of 65% to 69% The number of seconds that the paging channel was operating within the occupancy range of 70% to 74% The number of seconds that the paging channel was operating within the occupancy range of 75% to 79% The number of seconds that the paging channel was operating within the occupancy range of 80% to 84% The number of seconds that the paging channel was operating within the occupancy range of 85% to 89% The number of seconds that the paging channel was operating within the occupancy range of 90% to 94% The number of seconds that the paging channel was operating within the occupancy range of 95% to 100%
sheet 23 of 92
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
part of 141
411-2133-525
Standard
06.12
April 2008
AccessChanne lUsageInfo Added in 11.0 release
This is an array representing the access channel usage during 30 minutes (1800 seconds) indicating the time duration in seconds during which the access channel was operating within a certain occupancy range of 5% (i.e. 0% - 4%, 5% 9%,...,95% - 100%). Range N1% - N2% encompasses all values between N1 and less than (N2+1). For example, range 0% - 4% encompasses all values between 0 and < 5. The sample period for calculating the occupancy range is 20 access channel slots. The first field of the array represents the number of sub-arrays within the AccessChannelUsageInfo array (the number of sub-arrays = number of access channels* number of rings per access channel. Each sub-array contains 27 fields of info). Thus the size of the array depends upon how many paging channels, access channels and rings are configured. The different fields of the array are described below.
AccessChanne lUsageInfo[0]: Counts AccessChanne lUsageInfo[1]: PagingChannel Number AccessChanne lUsageInfo[2]: RingIndex AccessChanne lUsageInfo[3]: AccessChanne lNumber AccessChanne lUsageInfo[4]: PeakOccupanc y
The number of sub-arrays in the "AccessChannelUsageInfo" array as described in the above row. Identify a paging channel with which the access channel is associated.
part of 142
part of 142
Identify the ring with which the access channel is associated Identify an access channel that the usage data are describing
part of 142
part of 142
The lower bound of the peak occupancy range for the access channel.
part of 142
sheet 24 of 92
CDMA
NBSS15.0
AccessChanne lUsageInfo[5]: PeakDuration AccessChanne lUsageInfo[6]: LowerBoundOf AvgOccupancy AccessChanne lUsageInfo[7]: UpperBoundOf AvgOccupancy AccessChanne lUsageInfo[8]: Range0to4 AccessChanne lUsageInfo[9]: Range5to9 AccessChanne lUsageInfo[10]: Range10to14 AccessChanne lUsageInfo[11]: Range15to19 AccessChanne lUsageInfo[12]: Range20to24 AccessChanne lUsageInfo[13]: Range25to29 AccessChanne lUsageInfo[14]: Range30to34 AccessChanne lUsageInfo[15]: Range35to39
The number of seconds indicating how long the access channel was operating within the peak occupancy range. The lower bound of the average occupancy for the access channel.
part of 142
The upper bound of the average occupancy for the access channel.
part of 142
The number of seconds that the access channel was operating within the occupancy range of 0% to 4%. The number of seconds that the access channel was operating within the occupancy range of 5% to 9% The number of seconds that the access channel was operating within the occupancy range of 10% to 14% The number of seconds that the access channel was operating within the occupancy range of 15% to 19% The number of seconds that the access channel was operating within the occupancy range of 20% to 24% The number of seconds that the access channel was operating within the occupancy range of 25% to 29% The number of seconds that the access channel was operating within the occupancy range of 30% to 34% The number of seconds that the access channel was operating within the occupancy range of 35% to 39%
sheet 25 of 92
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
411-2133-525
Standard
06.12
April 2008
AccessChanne lUsageInfo[16]: Range40to44 AccessChanne lUsageInfo[17]: Range45to49 AccessChanne lUsageInfo[18]: Range50to54 AccessChanne lUsageInfo[19]: Range55to59 AccessChanne lUsageInfo[20]: Range60to64 AccessChanne lUsageInfo[21]: Range65to69 AccessChanne lUsageInfo[22]: Range70to74 AccessChanne lUsageInfo[23]: Range75to79 AccessChanne lUsageInfo[24]: Range80to84 AccessChanne lUsageInfo[25]: Range85to89 AccessChanne lUsageInfo[26]: Range90to94
The number of seconds that the access channel was operating within the occupancy range of 40% to 44% The number of seconds that the access channel was operating within the occupancy range of 45% to 49% The number of seconds that the access channel was operating within the occupancy range of 50% to 54% The number of seconds that the access channel was operating within the occupancy range of 55% to 59% The number of seconds that the access channel was operating within the occupancy range of 60% to 64% The number of seconds that the access channel was operating within the occupancy range of 65% to 69% The number of seconds that the access channel was operating within the occupancy range of 70% to 74% The number of seconds that the access channel was operating within the occupancy range of 75% to 79% The number of seconds that the access channel was operating within the occupancy range of 80% to 84% The number of seconds that the access channel was operating within the occupancy range of 85% to 89% The number of seconds that the access channel was operating within the occupancy range of 90% to 94%
sheet 26 of 92
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
part of 142
CDMA
NBSS15.0
Reference chapter BTS performance (page 9-1) MCTA performance (page 14-1)
AccessChanne lUsageInfo[27]: Range95to99 2G_MctaFull Added in 11.0 release
The number of seconds that the access channel was operating within the occupancy range of 95% to 100% This is an array indicating the number of 2G MCTA call attempts and reasons for the carrier-sector to have zero capacity estimate for these 2G MCTA call attempts (i.e. NO TCE, NO WCD, FWCAP, RECAP, Radio_Config). There are 9 elements in the array and they are described below. Please refer to Note on page 71 for Capacity calculation. Pegged every time a carrier is queried as a result of either Capacity Request or Resource Request. Pegged when the capacity estimate for the carrier is zero due to no TCE available for the carrier.
143
2G_MctaFull[0] : MctaAttempt 2G_MctaFull[1] : MctaFull_NoT CE 2G_MctaFull[2] : MctaFull_NoW CD 2G_MctaFull[3] : MctaFull_FWC AP 2G_MctaFull[4] : MctaFull_REC AP 2G_MctaFull[5] : MctaFull_Radi o_config
part of 143
MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1)
part of 143
Pegged when the capacity estimate for the carrier is zero due to no Walsh Codes available for the carrier.
part of 143
Pegged when the capacity estimate for the carrier is zero due to no forward capacity (i.e. power) available for the carrier. Pegged when the capacity estimate for the carrier is zero due to no reverse capacity available for the carrier. Pegged when the capacity estimate for the carrier is zero due to no Radio Config for the carrier that does not allow the type of call being requested.
part of 143
part of 143
part of 143
sheet 27 of 92
411-2133-525
Standard
06.12
April 2008
2G_MctaFull[6] : MctaFull_NoBc n New OM in13.0 Release 2G_MctaFull[7] : MctaFull_NoBa ckhaul New OM in13.0 Release
Pegged when the capacity estimate for the carrier is zero due to no available capacity on the BCN link(s) between the CEM(s) and the DCG. This blocking prevents BCN link over utilization in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision additional CEM resources (e.g., CCEMS, XCEMs, etc.). Pegged when the capacity estimate for the carrier is zero due to no available capacity on the BTS backhaul link(s). This blocking prevents over utilization of backhaul resources in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision either additional backhaul resources (e.g., T1s, E1s, etc.) in the current cell, or a new cell (if all available backhaul ports are utilized in the current cell). Pegged when the capacity estimate for the carrier is zero due to no available ACN IDs. Frequent pegging of this OM may indicate the need to provision an additional cell. Note: This blocking reason, although theoretically possible, is very unlikely to occur.
part of 143
2G_MctaFull[8] : MctaFull_NoAc n New OM in13.0 Release
part of 143
3GV_MctaFull Added in 11.0 release
This is an array indicating the number of 3G Voice MCTA call attempts and reasons for the carriersector to have zero capacity estimate for these 3G Voice MCTA call attempts (i.e. NO TCE, NO WCD, FWCAP, RECAP, Radio_Config). There are 9 elements in the array and they are described below. Pegged every time a carrier is queried as a result of either Capacity Request or Resource Request. Please refer to Note on page 71 for Capacity calculation.
sheet 28 of 92
144
3GV_MctaFull[ 0]: MctaAttempt
part of 144
CDMA
NBSS15.0
Reference chapter MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1)
3GV_MctaFull[ 1]: MctaFull_NoT CE 3GV_MctaFull[ 2]: MctaFull_NoW CD 3GV_MctaFull[ 3]: MctaFull_FWC AP 3GV_MctaFull[ 4]: MctaFull_REC AP 3GV_MctaFull[ 5]: MctaFull_Radi o_config 3GV_MctaFull[ 6]: MctaFull_NoBc n New OM in13.0 Release 3GV_MctaFull[ 7]: MctaFull_NoBa ckhaul New OM in13.0 Release
Pegged when the capacity estimate for the carrier is zero due to no TCE available for the carrier.
part of 144
Pegged when the capacity estimate for the carrier is zero due to no forward capacity (i.e. power) available for the carrier. Pegged when the capacity estimate for the carrier is zero due to no reverse capacity available for the carrier. Pegged when the capacity estimate for the carrier is zero due to no Radio Config for the carrier that does not allow the type of call being requested. Pegged when the capacity estimate for the carrier is zero due to no available capacity on the BCN link(s) between the CEM(s) and the DCG. This blocking prevents BCN link over utilization in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision additional CEM resources (e.g., XCEMs, etc.). Pegged when the capacity estimate for the carrier is zero due to no available capacity on the BTS backhaul link(s). This blocking prevents over utilization of backhaul resources in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision either additional backhaul resources (e.g., T1s, E1s, etc.) in the current cell, or a new cell (if all available backhaul ports are utilized in the current cell).
sheet 29 of 92
part of 144
part of 144
part of 144
part of 144
part of 144
411-2133-525
Standard
06.12
April 2008
3GV_MctaFull[ 8]: MctaFull_NoAc n New OM in13.0 Release
Pegged when the capacity estimate for the carrier is zero due to no available ACN IDs. Frequent pegging of this OM may indicate the need to provision an additional cell. Note: This blocking reason, although theoretically possible, is very unlikely to occur.
3GD_MctaFull Added in 11.0 release
This OM is an array indicating the number of 3G Data MCTA call attempts and reasons for the carrier-sector to have zero capacity estimate for these 3G Data MCTA call attempts (i.e. NO TCE, NO WCD, FWCAP, RECAP, Radio_Config). There are 9 elements in the array and they are described below. Pegged every time a carrier is queried as a result of either Capacity Request or Resource Request. Please refer to Note on page 71 for Capacity calculation. Pegged when the capacity estimate for the carrier is zero due to no TCE available for the carrier.
145
3GD_MctaFull[ 0]: MctaAttempt 3GD_MctaFull[ 1]: MctaFull_NoT CE 3GD_MctaFull[ 2]: MctaFull_NoW CD 3GD_MctaFull[ 3]: MctaFull_FWC AP 3GD_MctaFull[ 4]: MctaFull_REC AP
part of 145
MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1) MCTA performance (page 14-1)
part of 145
part of 145
Pegged when the capacity estimate for the carrier is zero due to no forward capacity (i.e. power) available for the carrier. Pegged when the capacity estimate for the carrier is zero due to no reverse capacity available for the carrier.
sheet 30 of 92
part of 145
part of 145
CDMA
NBSS15.0
Reference chapter MCTA performance (page 14-1) MCTA performance (page 14-1)
3GD_MctaFull[ 5]: MctaFull_Radi o_config 3GD_MctaFull[ 6]: MctaFull_NoBc n New OM in13.0 Release 3GD_MctaFull[ 7]: MctaFull_NoBa ckhaul New OM in13.0 Release
Pegged when the capacity estimate for the carrier is zero due to no Radio Config for the carrier that does not allow the type of call being requested. Pegged when the capacity estimate for the carrier is zero due to no available capacity on the BCN link(s) between the CEM(s) and the DCG. This blocking prevents BCN link over utilization in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision additional CEM resources (e.g., XCEMs, etc.). Pegged when the capacity estimate for the carrier is zero due to no available capacity on the BTS backhaul link(s). This blocking prevents over utilization of backhaul resources in order to maintain the quality of service of existing calls. Frequent pegging of this OM may indicate the need to provision either additional backhaul resources (e.g., T1s, E1s, etc.) in the current cell, or a new cell (if all available backhaul ports are utilized in the current cell). Pegged when the capacity estimate for the carrier is zero due to no available ACN IDs. Frequent pegging of this OM may indicate the need to provision an additional cell. Note: This blocking reason, although theoretically possible, is very unlikely to occur.
part of 145
part of 145
3GD_MctaFull[ 8]: MctaFull_NoAc n New OM in13.0 Release
part of 145
sheet 31 of 92
411-2133-525
Standard
06.12
April 2008
Reference chapter
PagingChannel OverloadOM
This OM provides the period of time (in seconds) that each paging channel was in each overload level (1,2,3) and the amount of time (in seconds) that an excessive number of buffers was in use the last 30 mintues. Note: Additional information (Metric formula, recommended usage etc.) on these OMs can now be found in the Nortel CDMA Performance Management -- Overload Controls NTP NN20000307.
LevelOnePerio d LevelTwoPerio d LevelThreePeri od BufferOverload Period AccessChanne lTimeInOverloa d
The period of time (in seconds) that the paging channel was at an overload level of 1. The period of time (in seconds) that the paging channel was at an overload level of 2. The period of time (in seconds) that the paging channel was at an overload level of 3. The period of time (in seconds) that the paging channel was using an excessive number of buffers The period of time (in seconds) that the access channel was in an overload condition. There is an entry in the array for each access channel in the sector. There are four fields in the array: 1) the paging channel the access channel is associated with, 2) the access channel number, 3) the ring index associated with the access channel, and 4) the time in seconds the access channel was in an overload condition. Note: Additional information (Metric formula, recommended usage etc.) on these OMs can now be found in the Nortel CDMA Performance Management -- Overload Controls NTP NN20000307.
sheet 32 of 92
Part of 152 Part of 152 Part of 152 Part of 152 157
CDMA
NBSS15.0
Reference chapter
AccessChanne lOverloadContr olLevels
The period of time (in seconds) that the sector spent in each of the defined overload control levels. The length of the array corresponds to the number of overload levels. The index of each entry in the array is associated with the level being tracked (e.g. the first entry in the array (index 0) corresponds to the time in overload level 1). The time in overload level 0 is not reported as there is no overload control being applied at level 0. Note: Additional information (Metric formula, recommended usage etc.) on these OMs can now be found in the Nortel CDMA Performance Management -- Overload Controls NTP NN20000307.
FschDowngrad eDueToFwdPw r Added in 12.0 release FschDowngrad eDueToFwdPw r[0]: From 16x to 8x FschDowngrad eDueToFwdPw r[1]: From 16x to 4x FschDowngrad eDueToFwdPw r[2]: From 16x to 2x
This OM Array shall peg when a F-SCH downgrade occurs due to a lack of enough forward power on the BTS. The OM Array shall indicate the number of times a type of downgrade takes place. The data rates of the downgrades are from 16x to 8x, 16x to 4x, 16x to 2x, 8x to 4x, 8x to 2x, 4x to 2x. The number of times a 16x F-SCH downgraded to a 8x F-SCH due to lack of Forward Power.
159
part of 159
The number of times a 16x F-SCH downgraded to a 4x F-SCH due to lack of Forward Power.
part of 159
part of 159
sheet 33 of 92
411-2133-525
Standard
06.12
April 2008
FschDowngrad eDueToFwdPw r[3]: From 8x to 4x FschDowngrad eDueToFwdPw r[4]: From 8x to 2x FschDowngrad eDueToFwdPw r[5]: From 4x to 2x FschDowngrad eDueToWC Added in 12.0 release FschDowngrad eDueToWC [0]: From 16x to 8x FschDowngrad eDueToWC [1]: From 16x to 4x FschDowngrad eDueToWC [2]: From 16x to 2x FschDowngrad eDueToWC [3]: From 8x to 4x
part of 159
part of 159
This OM Array shall peg when a F-SCH downgrade occurs due to a lack of enough walsh codes on the BTS. The OM Array shall indicate the number of times a type of downgrade takes place. The data rates of the downgrades are from 16x to 8x, 16x to 4x, 16x to 2x, 8x to 4x, 8x to 2x, 4x to 2x. The number of times a 16x F-SCH downgraded to a 8x F-SCH due to lack of enough Walsh Codes.
160
part of 160
The number of times a 16x F-SCH downgraded to a 4x F-SCH due to lack of enough Walsh Codes.
part of 160
part of 160
part of 160
sheet 34 of 92
CDMA
NBSS15.0
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
FschDowngrad eDueToWC [4]: From 8x to 2x FschDowngrad eDueToWC [5]: From 4x to 2x FschDowngrad eDueToPhysR es Added in 12.0 release FschDowngrad eDueToPhysR es[0]: From 16x to 8x FschDowngrad eDueToPhysR es[1]: From 16x to 4x FschDowngrad eDueToPhysR es[2]: From 16x to 2x FschDowngrad eDueToPhysR es[3]: From 8x to 4x
part of 160
This OM Array shall peg when a F-SCH downgrade occurs due to a lack of enough physical resources on the BTS. A lack of XCEM CPU is also included in this OM Array. The OM Array shall indicate the number of times a type of downgrade takes place. The data rates of the downgrades are from 16x to 8x, 16x to 4x, 16x to 2x, 8x to 4x, 8x to 2x, 4x to 2x. The number of times a 16x F-SCH downgraded to a 8x F-SCH due to lack of enough physical resources.
161
part of 161
The number of times a 16x F-SCH downgraded to a 4x F-SCH due to lack of enough physical resources.
part of 161
part of 161
part of 161
sheet 35 of 92
411-2133-525
Standard
06.12
April 2008
FschDowngrad eDueToPhysR es[4]: From 8x to 2x FschDowngrad eDueToPhysR es[5]: From 4x to 2x FschDowngrad eDueToExceed ingMaxDataRat e Added in 12.0 release FschDowngrad eDueToExceed ingMaxDataRat e[0]: From 16x to 8x FschDowngrad eDueToExceed ingMaxDataRat e[1]: From 16x to 4x FschDowngrad eDueToExceed ingMaxDataRat e[2]: From 16x to 2x
part of 161
This OM Array shall peg when a F-SCH downgrade occurs due to Exceeding the MaxFwdDataRate parameter value which limits the Max Forward Data rate on the BTS. The OM Array shall indicate the number of times a type of downgrade takes place. The data rates of the downgrades are from 16x to 8x, 16x to 4x, 16x to 2x, 8x to 4x, 8x to 2x, 4x to 2x. The number of times a 16x F-SCH downgraded to a 8x F-SCH due to Exceeding the MaxFwdDataRate parameter value (which limits the Max Forward Data rate).
162
part of 162
The number of times a 16x F-SCH downgraded to a 4x F-SCH due to Exceeding the MaxFwdDataRate parameter value (which limits the Max Forward Data rate).
part of 162
part of 162
sheet 36 of 92
CDMA
NBSS15.0
FschDowngrad eDueToExceed ingMaxDataRat e[3]: From 8x to 4x FschDowngrad eDueToExceed ingMaxDataRat e[4]: From 8x to 2x FschDowngrad eDueToExceed ingMaxDataRat e[5]: From 4x to 2x RschDowngrad eDueToPhysR es Added in 12.0 release RschDowngrad eDueToPhysR es[0]: From 16x to 8x RschDowngrad eDueToPhysR es[1]: From 16x to 4x
part of 162
part of 162
This OM Array shall peg when a R-SCH downgrade occurs due to a lack of enough physical resources on the BTS. A lack of XCEM CPU is also included in this OM Array. The OM Array shall indicate the number of times a type of downgrade takes place. The data rates of the downgrades are from 16x to 8x, 16x to 4x, 16x to 2x, 8x to 4x, 8x to 2x, 4x to 2x. The number of times a 16x R-SCH downgraded to a 8x R-SCH due to lack of enough physical resources.
163
part of 163
The number of times a 16x R-SCH downgraded to a 4x R-SCH due to lack of enough physical resources.
part of 163
sheet 37 of 92
411-2133-525
Standard
06.12
April 2008
RschDowngrad eDueToPhysR es[2]: From 16x to 2x RschDowngrad eDueToPhysR es[3]: From 8x to 4x RschDowngrad eDueToPhysR es[4]: From 8x to 2x RschDowngrad eDueToPhysR es[5]: From 4x to 2x RschDowngrad eDueToExceed ingMaxDataRat e Added in 12.0 release RschDowngrad eDueToExceed ingMaxDataRat e[0]: From 16x to 8x
part of 163
part of 163
part of 163
This OM Array shall peg when a R-SCH downgrade occurs due to Exceeding the MaxRevDataRate parameter value which limits the Max Reverse Data rate on the BTS. The OM Array shall indicate the number of times a type of downgrade takes place. The data rates of the downgrades are from 16x to 8x, 16x to 4x, 16x to 2x, 8x to 4x, 8x to 2x, 4x to 2x. The number of times a 16x R-SCH downgraded to a 8x R-SCH due to Exceeding the MaxRevDataRate parameter value (which limits the Max Reverse Data rate).
164
part of 164
sheet 38 of 92
CDMA
NBSS15.0
RschDowngrad eDueToExceed ingMaxDataRat e[1]: From 16x to 4x RschDowngrad eDueToExceed ingMaxDataRat e[2]: From 16x to 2x RschDowngrad eDueToExceed ingMaxDataRat e[3]: From 8x to 4x RschDowngrad eDueToExceed ingMaxDataRat e[4]: From 8x to 2x RschDowngrad eDueToExceed ingMaxDataRat e[5]: From 4x to 2x PeakWalshCod eUsage Added in 12.0 release
The number of times a 16x R-SCH downgraded to a 4x R-SCH due to Exceeding the MaxRevDataRate parameter value (which limits the Max Reverse Data rate).
part of 164
part of 164
part of 164
part of 164
Pegged to indicate the highest number of walsh codes in simultaneous use during the OM collection period. Note: The above OM pegs 2 times the actual walsh code usage for RC3 calls and the actual walsh code usage for RC4 calls.
165
sheet 39 of 92
411-2133-525
Standard
06.12
April 2008
WalshCodeUs ageDistribution Added in 12.0 release WalshCodeUs ageDistribution [0]: Range 0 to 30 WalshCodeUs ageDistribution [1]: Range 31 to 60 WalshCodeUs ageDistribution [2]: Range 61 to 70 WalshCodeUs ageDistribution [3]: Range 71 to 80 WalshCodeUs ageDistribution [4]: Range 81 to 90 WalshCodeUs ageDistribution [5]: Range 91 to 100
Pegged to indicate the number of walsh codes being used simultaneously in specific usage ranges. Each element of the array contains a different usage range. The ranges are: 0 to 30, 31 to 60, 61 to 70, 71 to 80, 81 to 90, 91 to 100, 101 to 110, 111 to 120, 121 to 128. Pegged to indicate the number of walsh codes being used simultaneously is in the range of 0 to 30.
part of 166
Pegged to indicate the number of walsh codes being used simultaneously is in the range of 31 to 60.
part of 166
part of 166
part of 166
part of 166
part of 166
sheet 40 of 92
CDMA
NBSS15.0
WalshCodeUs ageDistribution [6]: Range 101 to 110 WalshCodeUs ageDistribution [7]: Range 111 to 120 WalshCodeUs ageDistribution [8]: Range 121 to 128 InitialFwdSchB urstQueued2X New OM array in 12.1 release
part of 166
part of 166
This OM is an array indicating the number of times the BTS scheduler initially queues a 2X SCH setup request. Each array element corresponds to a different queuing reason. Queuing reasons are the same as blocking reasons, and are the same as those described under BlockedSchBursts with the following exceptions: The elements {(InitialFwdSchBurstQueued2X[5]: No Extended Cell Support), (InitialFwdSchBurstQueued2X[8]: Exceeded Max Data Rate)} are not valid queuing reasons as well. The elements {(InitialFwdSchBurstQueued2X[6]: CFDS Radio Config State), (InitialFwdSchBurstQueued2X[7]: CFDS HS RSCH), (InitialFwdSchBurstQueued2X[10]: Queue Full)} are not valid queuing reasons.
sheet 41 of 92
176
411-2133-525
Standard
06.12
April 2008
InitialFwdSchB urstQueued4X New OM array in 12.1 release
This OM is an array indicating the number of times the BTS scheduler initially queues a 4X SCH setup request. Each array element corresponds to a different queuing reason. Queuing reasons are the same as blocking reasons, and are the same as those described under BlockedSchBursts with the following exceptions: The elements {(InitialFwdSchBurstQueued4X[5]: No Extended Cell Support), (InitialFwdSchBurstQueued4X[8]: Exceeded Max Data Rate)} are not valid queuing reasons as well. The elements {(InitialFwdSchBurstQueued4X[6]: CFDS Radio Config State), (InitialFwdSchBurstQueued4X[7]: CFDS HS RSCH), (InitialFwdSchBurstQueued4X[10]: Queue Full)} are not valid queuing reasons. (Note: since the BTS will attempt to downgrade the rate in an attempt to fulfill the request, the queuing reason used is the one from the lowest requested rate that failed to get resources.)
sheet 42 of 92
CDMA
NBSS15.0
InitialFwdSchB urstQueued8X New OM array in 12.1 release
This OM is an array indicating the number of times the BTS scheduler initially queues a 8X SCH setup request. Each array element corresponds to a different queuing reason. Queuing reasons are the same as blocking reasons, and are the same as those described under BlockedSchBursts with the following exceptions: The elements {(InitialFwdSchBurstQueued8X[5]: No Extended Cell Support), (InitialFwdSchBurstQueued8X[8]: Exceeded Max Data Rate)} are not valid queuing reasons as well. The elements {(InitialFwdSchBurstQueued8X[6]: CFDS Radio Config State), (InitialFwdSchBurstQueued8X[7]: CFDS HS RSCH), (InitialFwdSchBurstQueued8X[10]: Queue Full)} are not valid queuing reasons. Note: Since the BTS will attempt to downgrade the rate in an attempt to fulfill the request, the queuing reason used is the one from the lowest requested rate that failed to get resources.
sheet 43 of 92
411-2133-525
Standard
06.12
April 2008
InitialFwdSchB urstQueued16 X New OM array in 12.1 release
This OM is an array indicating the number of times the BTS scheduler initially queues a 16X SCH setup request. Each array element corresponds to a different queuing reason. Queuing reasons are the same as blocking reasons, and are the same as those described under BlockedSchBursts with the following exceptions: The elements {(InitialFwdSchBurstQueued16X[5]: No Extended Cell Support), (InitialFwdSchBurstQueued16X[8]: Exceeded Max Data Rate)} are not valid queuing reasons as well. The elements {(InitialFwdSchBurstQueued16X[6]: CFDS Radio Config State), (InitialFwdSchBurstQueued16X[7]: CFDS HS RSCH), (InitialFwdSchBurstQueued16X[10]: Queue Full)}are not valid queuing reasons. Note: Since the BTS will attempt to downgrade the rate in an attempt to fulfill the request, the queuing reason used is the one from the lowest requested rate that failed to get resources.
sheet 44 of 92
CDMA
NBSS15.0
UpdateFwdSch BurstQueued2 X New OM array in 12.1 release
This OM is an array indicating the number of times the BTS queued SCH setup request (by the scheduler) has its data rate changed (i.e downgraded) to 2X due to contention at BSC resources (i.e. Fairshare algorithm). Each array element corresponds to a different queuing reason. Queuing reasons are the same as blocking reasons, and are the same as those described under BlockedSchBursts with the following exceptions: The elements {(UpdateFwdSchBurstQueued2X[5]: No Extended Cell Support), (UpdateFwdSchBurstQueued2X[8]: Exceeded Max Data Rate)} are not valid queuing reasons as well. The elements {(UpdateFwdSchBurstQueued2X[6]: CFDS Radio Config State), (UpdateFwdSchBurstQueued2X[7]: CFDS HS RSCH), (UpdateFwdSchBurstQueued2X[10]: Queue Full)}are not valid queuing reasons.
sheet 45 of 92
181
411-2133-525
Standard
06.12
April 2008
UpdateFwdSch BurstQueued1 6X New OM array in 12.1 release DistributionOfP riorityClass0De lay New OM array in 12.1 release
This OM is an array indicating the number of times the BTS queued SCH setup request (by the scheduler) has its data rate changed (i.e downgraded) to 16X due to contention at BSC resources (i.e. Fairshare algorithm). Thus this OM array does not get pegged. This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 0 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 0). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 4-6, 6-8, 810, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc.
sheet 46 of 92
183
184
CDMA
NBSS15.0
DistributionOfP riorityClass1De lay New OM array in 12.1 release
This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 1 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 1). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 4-6, 6-8, 810, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc. This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 2 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 2). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 4-6, 6-8, 810, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc. This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 3 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 3). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 4-6, 6-8, 810, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc.
sheet 47 of 92
186
187
411-2133-525
Standard
06.12
April 2008
sheet 48 of 92
189
190
CDMA
NBSS15.0
sheet 49 of 92
192
193
411-2133-525
Standard
06.12
April 2008
DistributionOfP riorityClass10D elay New OM array in 12.1 release
This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 10 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 10). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 46, 6-8, 8-10, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc. This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 11 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 11). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 46, 6-8, 8-10, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc. This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 12 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 12). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 46, 6-8, 8-10, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc.
sheet 50 of 92
195
196
CDMA
NBSS15.0
This OM is an array indicating how long the forward SCH setup requests wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. This OM array gives time delay for priority class 13 (i.e. when the data-filled QOSPI value for the mobiles making the data calls is 13). The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 46, 6-8, 8-10, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged,.etc. This OM is an array indicating how long a forward SCH setup request waited in the BTS scheduler queue before being allocated at 2X. The delay time is measured from when the BTS receives the initial resource request from the BSC until it responds back with the resource allocation. Note that the allocated rate may not match the initially requested data rate since the BSC may have downgraded the rate while the request was queued. The delay time is not reset when an update (downgrade) occurs. The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 46, 6-8, 8-10, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged, etc.
sheet 51 of 92
DistributionOf2 XDataRateDel ay New OM array in 12.1 release
198
411-2133-525
Standard
06.12
April 2008
This OM is an array indicating how long a forward SCH setup request waited in the BTS scheduler queue before being allocated at 4X. The delay time is measured from when the BTS receives the initial resource request from the BSC until it responds back with the resource allocation. Note that the allocated rate may not match the initially requested data rate since the BSC may have downgraded the rate while the request was queued. The delay time is not reset when an update (downgrade) occurs. The distribution (entries in the array) will be the following intervals, specified in seconds (0-2, 2-4, 46, 6-8, 8-10, 10-15, 15-20, 20-30, 30+). Note that if the delay is exactly 2 sec, then the 2-4 interval is pegged. Similarly if the delay is exactly 4 sec, then the 4-6 interval is pegged, etc.
sheet 52 of 92
200
CDMA
NBSS15.0
DistributionOf1 6XDataRateDe lay New OM array in 12.1 release
FwdSCHBurst SetupPeakDel ay New OM in 12.1 release
This OM represents the longest delay that any forward SCH setup request had to wait in the BTS scheduler queue. The time measured is from when the BTS receives the resource request until it responds back with the resources. It defines the maximum value that causes a peg in the DistributionOfDataRateDelay for the reporting period. This OM represents the maximum number of forward SCH setup requests that are queued simultaneously by the BTS scheduler during the reporting interval. This OM Array is pegged when a forward burst resource request is allocated successfully without BTS scheduler queuing. The array elements represent the data rates 2X, 4X, 8X, and 16X. The
202
MaximumFSC HQueueLength New OM in 12.1 release NonQueuedFw dSchBurstNon Blocking3G New OM array in 12.1 release
203
207
OM is pegged for the allocated data rate.

This OM is renamed from SchBurstNonBlocking3G.
sheet 53 of 92
411-2133-525
Standard
06.12
April 2008
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
NonQueuedFw dSchBurstNon Blocking3G[0]: 2X NonQueuedFw dSchBurstNon Blocking3G[1]: 4X NonQueuedFw dSchBurstNon Blocking3G[2]: 8X NonQueuedFw dSchBurstNon Blocking3G[3]: 16X QueuedFwdSc hBurstNonBloc king3G New OM array in 12.1 release QueuedFwdSc hBurstNonBloc king3G[0]: 2X QueuedFwdSc hBurstNonBloc king3G[1]: 4X QueuedFwdSc hBurstNonBloc king3G[2]: 8X QueuedFwdSc hBurstNonBloc king3G[3]: 16X
This element is pegged when a forward burst resource request is allocated successfully at 2X without BTS scheduler queuing. This element is pegged when a forward burst resource request is allocated successfully at 4X without BTS scheduler queuing. This element is pegged when a forward burst resource request is allocated successfully at 8X without BTS scheduler queuing. This element is pegged when a forward burst resource request is allocated successfully at 16X without BTS scheduler queuing. This OM Array is pegged when a forward burst resource request is allocated successfully after it has been queued by the BTS scheduler. The array elements represent the data rates 2X, 4X, 8X, and 16X. The OM is pegged for the allocated data rate. This element is pegged when a forward burst resource request is allocated successfully at 2X after it has been queued by the BTS scheduler. This element is pegged when a forward burst resource request is allocated successfully at 4X after it has been queued by the BTS scheduler. This element is pegged when a forward burst resource request is allocated successfully at 8X after it has been queued by the BTS scheduler. This element is pegged when a forward burst resource request is allocated successfully at 16X after it has been queued by the BTS scheduler.
sheet 54 of 92
part of 207
part of 207
part of 207
208
part of 208
part of 208
part of 208
part of 208
CDMA
NBSS15.0
RevSchBurstN onBlocking3G New OM array in 12.1 release RevSchBurstN onBlocking3G[ 0]: 2X RevSchBurstN onBlocking3G[ 1]: 4X RevSchBurstN onBlocking3G[ 2]: 8X RevSchBurstN onBlocking3G[ 3]: 16X AccessChanne lPageRespons eReceived Deleted in 14.0 release PagingChannel MessageRecei vedDroppedInf o Deleted in 14.0 release
This OM Array is pegged when a reverse burst resource request is allocated successfully by the BTS. The array elements represent the data rates 2X, 4X, 8X, and 16X This OM Array is pegged when a reverse burst resource request is allocated successfully at 2X by the BTS. This OM Array is pegged when a reverse burst resource request is allocated successfully at 4X by the BTS. This OM Array is pegged when a reverse burst resource request is allocated successfully at 8X by the BTS. This OM Array is pegged when a reverse burst resource request is allocated successfully at 16X by the BTS.
part of 209
part of 209
part of 209
part of 209
Note: This OM has been deleted. Information provided by this OM is captured by ACHMessagesReceived OM (Sequence number 300) introduced in 14.0 release.
Note: This OM has been deleted. Information provided by this OM is captured by FPCHMessagesReceivedDropped OM (Sequence number 354) introduced in 15.0 release.
sheet 55 of 92
411-2133-525
Standard
06.12
April 2008
FPCHMessage sDroppedByRe ason Renamed from PagingChannel MsgDroppedBy Reason in Release 15 FPCHMessage sDroppedByRe ason[0]:Paging ChannelNumb er FPCHMessage sDroppedByRe ason[1]:Droppe dByOutOfBuffe r
This array counts the Paging Channel Messages that are dropped by reason.
The element is the Paging Channel Number.
part of 355
The element counts the number of Paging Channel Messages dropped for the reason of out of buffer. Note: Out of buffer shall be pegged when a message is dropped due to CCEM/XCEM card running out of buffer.
part of 355
FPCHMessage sDroppedByRe ason[2]:Droppe dStaleMessage
The element counts the number of Paging Channel Messages dropped for the reason of stale messages. Note: Stale message reason shall be pegged when the message can not be sent in time.
part of 355
FPCHMessage sDroppedByRe ason[3]:Droppe dByEROCPagi ng
The element counts the number of Paging Channel Messages dropped by EROC Paging feature. Note: EROC paging dropped message reason shall be pegged when message is discarded by the EROC paging overload mechanism.
sheet 56 of 92
part of 355
CDMA
NBSS15.0
FPCHMessage sDroppedByRe ason[4]:Droppe dBySizeLimit FPCHMessage sDroppedByRe ason[5]:Droppe dByBroadcast QueueOverFlo w ResourceRelea seReqTCELink Error
The element counts the number of Data Burst Messages discarded because the message size exceeds the sector limit. Note: Reserved for NBSS 16.0, not pegged in 15.0 The element counts the number of broadcast Data Burst Messages discarded because there is no room in the broadcast queue. Note: Reserved for NBSS 16.0, not pegged in 15.0 This OM replaces the Warning - CALLP Processing Warning // TCEStatus: Timing Fault alarm. This OM is pegged whenever the SBS sends a resource release request message to the BTS with an error value in the link status field. If the OM has a consistently high value, then there is potentially a noisy T1/E1 link to the BTS that needs to be fixed. This OM array is pegged when an F-SCH downgrade occurs due to lack of enough BCN resources on the BTS. Each element of the array describes the data rate of the downgrade. The changes in data rate from first to last element are: 0) 16x to 8x, 1) 16x to 4x, 2) 16x to 2x, 3) 8x to 4x, 4) 8x to 2x, and 5) 4x to 2x. This OM array is pegged when an F-SCH downgrade occurs due to lack of enough backhaul resources on the BTS. Each element of the array describes the data rate of the downgrade. The changes in data rate from first to last element are: 0) 16x to 8x, 1) 16x to 4x, 2) 16x to 2x, 3) 8x to 4x, 4) 8x to 2x, and 5) 4x to 2x.
sheet 57 of 92
part of 355
213
FschDowngrad eDueToNoBcn New OM array in 13.0 Release
260
FschDowngrad eDueToNoBac khaul New OM array in 13.0 Release
261
411-2133-525
Standard
06.12
April 2008
FchOrigination NonBlocking3g Downgrade2g NoAcn New OM in 13.0 Release
This OM is pegged when an FCH is downgraded from 3G Voice to 2G Voice due to the lack of ACN addresses. This occurs when the XCEMs are unable to allocate the call due to the lack of ACN node IDs in the system, but there exists a CCEM on the same carrier with an available ACN ID. Note that downgrades due to lack of ACN IDs is only applicable to the eDCG Metro Cell. Note: This blocking reason, although theoretically possible, is very unlikely to occur.
FchOrigination NonBlocking3g Downgrade2g NoBcn New OM in 13.0 Release PagingChannel MessageRecei vedCount New OM in 14.0 release PagingChannel MessageRecei vedCount[0]: NumberOfPagi ngChannels PagingChannel MessageRecei vedCount[1]: PagingChannel Number
This OM is pegged when an FCH is downgraded from 3G Voice to 2G Voice due to the lack of BCN link capacity. This occurs when the XCEMs on the carrier are unable to allocate the call due to the lack of BCN link capacity, but there exists a CCEM on the same carrier with available BCN bandwidth. This OM array provides a count of all paging messages received by each configured paging channel element in a carrier-sector. This includes overhead and mobile-directed paging channel messages. The count also includes messages which may be dropped by the paging channel element. This elements identifies the number of configured paging channels in a carrier-sector
265
268
part of 268
This element identifies the paging channel number.
part of 268
sheet 58 of 92
CDMA
NBSS15.0
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1)
PagingChannel MessageRecei vedCount[2]: MessageCount PagingChannel MessageDropp edCount New OM in 14.0 release
This element provides the messages received count for the paging channel element.
This OM array provides count of paging channel messages dropped by each configured paging channel element in a carrier-sector due to paging channel overload on that paging channel. This is typically a result of insufficient paging channel bandwidth. This OM is also pegged when paging channel messages are dropped due to EROC feature for paging channel given that the CEM and BSSM are both at 12.1 load. If BSSM is 12.0 or earlier, this OM will not capture messaged dropped due to paging channel EROC. This elements identifies the number of configured paging channels in a carrier-sector
269
PagingChannel MessageDropp edCount[0]: NumberOfPagi ngChannels PagingChannel MessageDropp edCount[1]: PagingChannel Number PagingChannel MessageDropp edCount[2]: MessageCount PrimaryFBCCH LinkUtilAvg New OM in Release 14.0
part of 269
This element identifies the paging channel number.
part of 269
This element provides the messages dropped count for the paging channel element.
part of 269
This OM provides average of sum of digital gain squared for the BCCH Channel. The average is calculated only the entire OM collection interval i.e. the DTX factor for the BCCH channel is included. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array.
sheet 59 of 92
288
411-2133-525
Standard
06.12
April 2008
Reference chapter
FCCCHLinkUtil Avg New OM in Release 14.0
This OM provides average of sum of digital gain squared for the FCCCH Channel. The average is calculated only the entire OM collection interval i.e. the DTX factor for the FCCCH channel is included. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This OM array provides a count of all PREV >= 7 mobile directed messages received by each configured FCCCH channel element in a carriersector. The count includes messages which may be dropped by the FCCCH channel element. This OM has the same structure as the PagingChannelMessageReceivedCount (page -59) OM.
FCCCHTotalM essagesReceiv edCount New OM in Release 14.0
290
FCCCHTotalM essagesDropp edCount New OM in Release 14.0
This OM provides count of FCCCH channel messages dropped by the channel element due to channel overload. This is typically a result of insufficient FCCCH channel bandwidth. This OM has the same structure as the PagingChannelMessageDroppedCount (page -60) OM. This OM array counts the forward common control channel (FCCCH) messages that are dropped by reason This OM has the same structure as FPCHMessagesDroppedByReason (page -57) OM. Note: Since EROC is not been implemented for BAM, OM counts for the reason code of DroppedByEROCPaging should be zero for FCCCH.
sheet 60 of 92
291
FCCCHMessa gesDroppedBy ReasonType New OM in Release 14.0
292
CDMA
NBSS15.0
FCCCHMessa gesReceivedDr opped New OM in Release 14.0
This OM counts the FCCCH Channel messages received and messages dropped by the BTS at the CCEM/XCEM on a per carrier-sector basis. The information or array elements are categorized by message type (GPM, Databurst, FN, ECAM, CAM, Order, Service Redirection, Authentication, Status Request). Message can be dropped at the BTS due to buffer overflow, message being stale or due to BTS being in overload condition. This OM has the same structure as FPCHMessagesReceivedDropped (page -66) OM. Note: The CAM messages received and dropped should have zero counts since mobiles using BAM require ECAM or MECAM messages to be sent by the network.
FCCCHUsageI nfo New OM in Release 14.0
This is an array representing the FCCCH usage during 30 minutes (1800 seconds) indicating the time duration in seconds during which the FCCCH was operating within a certain occupancy range of 5% (i.e. 0% - 4%, 5% - 9%,... and 95%- 100%). Range N1% - N2% encompasses all values between N1 and less than (N2+1). For example, range 0% - 4% encompasses all values between 0 and < 5. The sample period for calculating the occupancy range is 1.28 seconds, equivalent to 16 slots. The first field of the array represents the number of supported FCCCH's, and then followed by 25 fields in the array for each supported FCCCH. Thus the size of the array is dependent upon how many FCCCHs are configured. The different fields of the array are described below. This OM has the same structure as the PagingChannelUsageInfo (page -22) OM.
sheet 61 of 92
296
411-2133-525
Standard
06.12
April 2008
REACHMessa gesReceived New OM in Release 14.0
This OM array counts the Enhanced Access Channel messages received by the BTS on a per carrier-sector basis. This information or array elements are categorized by message type (RGM, ORM, PRM, MSACKORDM, OtherORDM, DBM, AUCRM, STRPM, ESTRPM, BadCRC, InvalidMsg, UnsupportedMsg) This OM has the same structure as ACHMessagesReceived (page -64) OM. Note: The Status Response Message array element will not peg since only PREV>=7 MSs will be on BAM which use Extended Status Response Message only.
REACHUsageI nfo New OM in Release 14.0
This is an array representing the enhanced access channel usage during 30 minutes (1800 seconds) indicating the time duration in seconds during which the REACH was operating within a certain occupancy range of 5% (i.e. 0% - 4%, 5% 9%,...,95%- 100%). Range N1% - N2% encompasses all values between N1 and less than (N2+1). For example, range 0% - 4% encompasses all values between 0 and < 5. The sample period for calculating the occupancy range is 4 seconds. The first field of the array represents the number of subarrays within the "R-EACHUsageInfo" array (the number of sub-arrays = number of enhanced access channels* number of rings per enhanced access channel. Each sub-array contains 27 fields of info). Thus the size of the array depends upon how many FCCCH channels, enhanced access channels and rings are configured. This OM has the same structure as the AccessChannelUsageInfo (page -25) OM. The ring index field is not applicable but is included for consistency with Access Channel data structure Note: The peak occupancy for REACH is defined as the upper bound + 1 of the peak occupancy range for REACH.
sheet 62 of 92
298
CDMA
NBSS15.0
Reference chapter Data burst message delivery performance (page 12-1) BTS performance (page 9-1)
REACHShortD ataBurstReceiv ed New OM in Release 14.0 ACHMessages Received New OM in Release 14.0
This OM is pegged when a R-SDB is received at the BTS. This R-SDB was sent by the mobile on the REACH.
This OM array counts the Access Channel messages received by the BTS on a per carriersector basis. This information or array elements are categorized by message type (RGM, ORM, PRM, MSACKORDM, OtherORDM, DBM, AUCRM, STRPM, ESTRPM, BadCRC, InvalidMsg, UnsupportedMsg). The first field of the array represents the number of sub-arrays within the ACHMessagesReceived array (the number of sub-arrays = number of paging channels * number of access channels * number of rings per access channel. Each sub-array contains 15 fields of info). Thus the size of the array depends upon how many paging channels, access channels and rings are configured. The different fields of the array are described below.
300
ACHMessages Received: Count ACHMessages Received [0]: PagingChannel Number ACHMessages Received [1]: AccessChanne lNumber ACHMessages Received [2]:RIngIndex
This element identifies the number of configured access channels in a carrier-sector. This element identifies the Paging Channel Number.
part of 300
part of 300
This element identifies the Access Channel Number.
part of 300
This element identifies the Ring Index Number.
part of 300
sheet 63 of 92
411-2133-525
Standard
06.12
April 2008
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
ACHMessages Received [3]: RGMReceived ACHMessages Received [4]: ORMReceived ACHMessages Received [5]: PRMReceived ACHMessages Received [6]: MSACKORDM Received ACHMessages Received [7]: OtherORDMRe ceived ACHMessages Received [8]: DBMReceived ACHMessages Received [9]: AUCRMReceiv ed ACHMessages Received [10]: STRPMReceiv ed ACHMessages Received [11]: ESTRPMRecei ved
This element counts the number of Registration messages received. This element counts the number of Origination messages received. This element counts the number of Page Response messages received. This element counts the number of Mobile Station Acknowledgement Order messages received.
part of 300
part of 300
part of 300
This element counts the total number of Order messages (except Mobile Station Acknowledgement Order) received. This element counts the number of Data burst messages received. This element counts the number of Authentication Challenge Response messages received.
part of 300
part of 300
part of 300
This element counts the number of Status Response messages received.
part of 300
This element counts the number of Extended Status Response messages received.
part of 300
sheet 64 of 92
CDMA
NBSS15.0
ACHMessages Received [12]: BadCRCMsgR eceived ACHMessages Received [13]: InvalidMsgRec eived ACHMessages Received [14]: UnsupportedM sgReceived FPCHMessage sReceivedDrop ped Renamed from PCHMessages ReceivedDropp ed in Release 15.0
This element counts the number of messages received that fail the CRC check.
This element counts the number of messages received that are not supported by the Nortel system or have parameters with values outside their allowed range as defined in the standards. These messages are discarded by the BTS. This element counts the number of messages received that are not supported by the BTS due to configuration reasons. E.g. RTD of message exceeds the ASW configured range. These messages are discarded by the BTS. This OM array counts the Paging Channel messages received and messages dropped by the BTS at the CCEM/XCEM on a per carrier-sector basis. The information or array elements are categorized by message type (GPM, Databurst, FN, MECAM, ECAM, CAM, MECAM, BSACKORD, Other Order, Service Redirection, Authentication, Status Request). Message can be dropped at the BTS due to buffer overflow, message being stale or due to BTS being in overload condition.
part of 300
part of 300
354
FPCHMessage sReceivedDrop ped [0]: Count FPCHMessage sReceivedDrop ped [1]: PagingChannel Number
This element identifies the number of configured paging channels in a carrier-sector. This element identifies the Paging Channel Number.
part of 354
part of 354
sheet 65 of 92
411-2133-525
Standard
06.12
April 2008
FPCHMessage sReceivedDrop ped [2]:GPMReceiv ed FPCHMessage sReceivedDrop ped [3]:GPMDropp ed FPCHMessage sReceivedDrop ped [4]:DBMReceiv ed FPCHMessage sReceivedDrop ped [5]:DBMDroppe d FPCHMessage sReceivedDrop ped [6]:FNMReceiv ed FPCHMessage sReceivedDrop ped [7]:FNMDroppe d FPCHMessage sReceivedDrop ped [8]:ECAMRecei ved
This element counts the number of GPM (General Page Messages) messages received.
This element counts the number of GPM messages dropped.
part of 354
This element counts the number of Databurst messages received.
part of 354
This element counts the number of Databurst messages dropped.
part of 354
This element counts the number of Feature Notification messages received.
part of 354
This element counts the number of Feature Notification messages dropped.
part of 354
This element counts the number of ECAM messages received.
part of 354
sheet 66 of 92
CDMA
NBSS15.0
FPCHMessage sReceivedDrop ped [9]:ECAMDrop ped FPCHMessage sReceivedDrop ped [10]:ECAMRep eatStaleDropp ed
This element counts the number of ECAM messages dropped, by the reason of out of buffer.
This element counts the number of 2nd and 3rd attempt of ECAM messages dropped by the reason of being too old (or being a stale message). Note: Since ECAM messages are always sent on the 1st attempt, only the dropping of the quick repeat attempts would be counted, as they may be rescheduled to later paging slots to make room for higher priority messages.
part of 354
FPCHMessage sReceivedDrop ped [11]:CAMRecei ved FPCHMessage sReceivedDrop ped [12]:CAMDropp ed FPCHMessage sReceivedDrop ped [13]:CAMRepe atStaleDroppe d
This element counts the number of CAM messages received.
part of 354
This element counts the number of CAM messages dropped by the reason of out of buffer.
part of 354
This number of 2nd and 3rd attempt of CAM messages dropped by the reason of being too old (or being stale messages). Note: Since CAM messages are always sent on the 1st attempt, only the dropping of the quick repeat attempts would be counted, as they may be rescheduled to later paging slots to make room for higher priority messages.
sheet 67 of 92
part of 354
411-2133-525
Standard
06.12
April 2008
FPCHMessage sReceivedDrop ped [14]:MECAMR eceived FPCHMessage sReceivedDrop ped [15]:MECAMO utOfBufferDrop ped FPCHMessage sReceivedDrop ped [16]:MECAMR epeatStaleDro pped FPCHMessage sReceivedDrop ped [17]:BSACKOR DMReceived FPCHMessage sReceivedDrop ped [18]:OtherORD MReceived FPCHMessage sReceivedDrop ped [19]:BSACKOR DMDropped FPCHMessage sReceivedDrop ped [20]:OtherORD MDropped
This element counts the number of MECAM messages received.
This element counts the number of MECAM messages dropped, by the reason of out of buffer.
part of 354
This element counts the number of 2nd and 3rd attempt of MECAM messages dropped by the reason of being too old (or being a stale message).
part of 354
This element counts the number of Base Station Acknowledgement Order messages received.
part of 354
This element counts the total number of Order messages (except Base Station Acknowledgement Order) received.
part of 354
This element counts the number of Base Station Acknowledgement Order messages dropped.
part of 354
This element counts the total number of Order messages (except Base Station Acknowledgement Order) dropped.
part of 354
sheet 68 of 92
CDMA
NBSS15.0
FPCHMessage sReceivedDrop ped [21]:STRQMRe ceived FPCHMessage sReceivedDrop ped [22]:STRQMDr opped FPCHMessage sReceivedDrop ped [23]:AUCMRec eived FPCHMessage sReceivedDrop ped [24]:AUCMDro pped FPCHMessage sReceivedDrop ped [25]:SRDMRec eived FPCHMessage sReceivedDrop ped [26]:SRDMDro pped FPCHMessage sReceivedDrop ped [27]:SRDMDro pped
This element counts the number of Status Request messages received.
This element counts the number of Status Request messages dropped.
part of 354
This element counts the number of Authentication Challenge messages received.
part of 354
This element counts the number of Authentication Challenge messages dropped.
part of 354
This element counts the number of Service Redirection messages received.
part of 354
This element counts the number of Service Redirection messages dropped.
part of 354
This element counts the number of Service Redirection messages dropped. Note: Resvered for NBSS 16.0, not pegged in 15.0.
sheet 69 of 92
part of 354
411-2133-525
Standard
06.12
April 2008
FPCHMessage sReceivedDrop ped [28]:BCDBMRe ceived
This element counts the number of broadcast Data Burst messages received. Note: Resvered for NBSS 16.0, not pegged in 15.0.
Note: Capacity Estimate Calculation: The Capacity Estimate is the number of new calls that could be handled at the BTS in the specified EBID (i.e., carrier-sector). It is determined by the minimum of available radio resources such as AvailableTCEs, ForwardTxPower, AvailableWalshCodes, and available CPU capacity. CPU Capacity is included as a part of the capacity estimate only for calls being setup on an XCEM. For example, if ForwardTxPower is still enough to support 30 calls, AvailableTCEs = 20, AvailableWalshCodes = 18, but (XCEM) CPU capacity = 15, then CapacityEstimate is set to 15. Available TCE is the total number of traffic channel elements available for the carrier specified in the CDMA_FREQ portion of the EBID. ForwardTxPower is the amount of power currently transmitting in the specified sector, which only includes the power contributions from the traffic channels. Available WalshCodes is the total number of available Walsh codes in the specified EBID. Available CPU capacity is based on whether or not adding the new call will exceed the XCEM CPU usage threshold.
FrameCountFC H Modified in 14.0 release
This is an array for conventional sector or 3 arrays for AABS sector indicating the total number of frames sent on the forward link for every user on the fundamental channel with a distinction between Voice and Data. There are eight elements in the array which are: 0 - RC1 (voice only) 1 - RC2 (voice only) 2 - RC3 voice 3 - RC3 data 4 - RC4 voice 5 - RC4 data 6 - RC5 voice 7 - RC5 data Equivalent to FrameCntFCH, with each frame being divided by the number of softer handoff links. There are eight elements in the array which are: 0 - RC1 (voice only) 1 - RC2 (voice only) 2 - RC3 voice 3 - RC3 data 4 - RC4 voice 5 - RC4 data 6 - RC5 voice 7 - RC5 data. For AABS sector, there are three arrays. Each one relates to one beam. For conventional sector, there is only one array.
sheet 70 of 92
309
CEFrameCoun tFCH Modified in 14.0 release
310
CDMA
NBSS15.0
PrimaryFrame CountFCH Modified in 14.0 release
Equivalent to FrameCntFCH, with each frame being divided by the product of the number of softer handoff links and the number of soft handoff links. There are eight elements in the array which are: 0 RC1 (voice only) 1 - RC2 (voice only) 2 - RC3 voice 3 - RC3 data 4 - RC4 voice 5 - RC4 data 6 - RC5 voice 7 - RC5 data. For AABS sector, there are three arrays. Each one relates to one beam. For conventional sector, there is only one array. This OM is an array (for conventional sector) indicating the total number of 2X forward frames for every user on the supplemental channel. Each element in the array represents one radio configuration from RC3 through RC5. It gets pegged once for each 2X forward SCH frame. For AABS sector, there are three arrays, one for each beam. This OM is an array (for conventional sector) indicating the total number of 4X forward frames for every user on the supplemental channel. Each element in the array represents one radio configuration from RC3 through RC5. It gets pegged once for each 4X forward SCH frame. For AABS sector, there are three arrays, one for each beam. This OM is an array (for conventional sector) indicating the total number of 8X forward frames for every user on the supplemental channel. Each element in the array represents one radio configuration from RC3 through RC5. It gets pegged once for each 8X forward SCH frame. For AABS sector, there are three arrays, one for each beam. This OM is an array (for conventional sector) indicating the total number of 16X forward frames for every user on the supplemental channel. Each element in the array represents one radio configuration from RC3 through RC5. It gets pegged once for each 16X forward SCH frame. For AABS sector, there are three arrays, one for each beam.
sheet 71 of 92
FrameCountFw dSCH_2X Modified in 14.0 Release
312
313
314
315
411-2133-525
Standard
06.12
April 2008
CEFrameCoun tFwdSCH_2X Modified in 14.0 Release CEFrameCoun tFwdSCH_4X Modified in 14.0 Release CEFrameCoun tFwdSCH_8X Modified in 14.0 Release CEFrameCoun tFwdSCH_16X Modified in 14.0 Release PrimaryFrame CountFwdSCH _2X Modified in 14.0 Release PrimaryFrame CountFwdSCH _4X Modified in 14.0 Release PrimaryFrame CountFwdSCH _8X Modified in 14.0 Release
This OM is equivalent to FrameCntFwdSCH_2X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntFwdSCH_4X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntFwdSCH_8X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntFwdSCH_16X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntFwdSCH_2X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntFwdSCH_4X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntFwdSCH_8X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam.
sheet 72 of 92
317
318
319
320
321
322
CDMA
NBSS15.0
PrimaryFrame CountFwdSCH _16X Modified in 14.0 Release FrameCountRe vSCH_2X Modified in 14.0 Release
This OM is equivalent to FrameCntFwdSCH_16X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is an array (for conventional sector) indicating the total number of 2X reverse frames for every user on the supplemental channel. There are two elements in the array, one for RC3 and another for RC4. It gets pegged once for each 2X reverse SCH frame. For AABS sector, there are three arrays, one for each beam. This OM is an array (for conventional sector) indicating the total number of 4X reverse frames for every user on the supplemental channel. There are two elements in the array, one for RC3 and another for RC4. It gets pegged once for each 4X reverse SCH frame. For AABS sector, there are three arrays, one for each beam. This OM is an array (for conventional sector) indicating the total number of 8X reverse frames for every user on the supplemental channel. There are two elements in the array, one for RC3 and another for RC4. It gets pegged once for each 8X reverse SCH frame. For AABS sector, there are three arrays, one for each beam. This OM is an array (for conventional sector) indicating the total number of 16X reverse frames for every user on the supplemental channel. There are two elements in the array, one for RC3 and another for RC4. It gets pegged once for each 16X reverse SCH frame. For AABS sector, there are three arrays, one for each beam. This OM is equivalent to FrameCntRevSCH_2X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam.
sheet 73 of 92
324
FrameCountRe vSCH_4X Modified in 14.0 Release
325
326
327
CEFrameCoun tRevSCH_2X Modified in 14.0 Release
328
411-2133-525
Standard
06.12
April 2008
CEFrameCoun tRevSCH_4X Modified in 14.0 Release CEFrameCoun tRevSCH_8X Modified in 14.0 Release CEFrameCoun tRevSCH_16X Modified in 14.0 Release PrimaryFrame CountRevSCH _2X Modified in 14.0 Release PrimaryFrame CountRevSCH _2X Modified in 14.0 Release PrimaryFrame CountRevSCH _4X Modified in 14.0 Release
This OM is equivalent to FrameCntRevSCH_4X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntRevSCH_8X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntRevSCH_16X, with each peg being divided by the number of softer handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntRevSCH_2X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntRevSCH_2X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntRevSCH_4X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam.
sheet 74 of 92
330
331
332
332
333
CDMA
NBSS15.0
PrimaryFrame CountRevSCH _8X Modified in 14.0 Release PrimaryFrame CountRevSCH _16X Modified in 14.0 Release TCEFwdLinkUt ilUWAvg Modified in Release 14.0
This OM is equivalent to FrameCntRevSCH_8X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM is equivalent to FrameCntRevSCH_16X, with each peg being divided by the product of the number of softer handoff links and the number of soft handoff links. Similarly, there is only one array for conventional sector and there are three arrays for AABS sector, one for each beam. This OM provides average of sum of digital gain squared for all traffic channels. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array.
335
336
OverheadFwdL inkUtilUWAvg Modified in Release 14.0
This OM provides average of sum of digital gain squared for all overhead channels. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. Note: This OM was modified to include the power used by BCCH and FCCCH channels when BAM is enabled
337
OCNSFwdLink UtilTWAvg Modified in Release 14.0
This OM provides average of sum if digital gain squared for all OCNS channels. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array.
sheet 75 of 92
338
411-2133-525
Standard
06.12
April 2008
VoiceFchFwdLi nkUtilAvg Modified in Release 14.0
This OM is an array for conventional sector containing the average forward power (i.e. average of sum of digital gain squared) used by RCs supporting voice or circuit-switched data calls on the fundamental channel. Each element corresponds to a different RC. The first element is for RC1 and the last element is for RC5. This information is useful in evaluating time impact of voice, data, and various radio configurations on forward power. The element values for RC3 through RC5 will be zero for non-3G deployments. For AABS sector, there are three arrays, each relates to one beam. This OM is an array for conventional sector containing the average forward power (i.e. average of sum of digital gain squared) used by RCs supporting packet data sessions on the fundamental channel. Each element corresponds to a different RC. The first element is for RC3 and the last element is for RC5. This information is useful in evaluating time impact of voice, data, and various radio configurations on forward power. For AABS sector, there are three arrays, each relates to one beam. This OM is an array for conventional sector containing the average forward power (i.e. average of sum of digital gain squared) used by RCs supporting packet data sessions on the supplemental channel. Each element corresponds to a different RC. The first element is for RC3 and the last element is for RC5. This information is useful in evaluating time impact of voice, data, and various radio configurations on forward power. For AABS sector, there are three arrays, each relates to one beam.
sheet 76 of 92
DataFchFwdLi nkUtilAvg Modified in Release 14.0
340
SchFwdLinkUtil Avg Modified in Release 14.0
341
CDMA
NBSS15.0
PercentTimeAb oveFwdCallBlo ckThreshold Modified in Release 14.0
This OM provides the percentage of the measuring interval time, based on 2-second samples, that forward link power exceeds the forward call blocking threshold. This indicates the percentage of time that originations and terminations would be blocked due to forward power. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This OM provides the percentage of the measuring interval time, based on 2-second samples, that forward link power exceeds the forward handoff blocking threshold. This indicates the percentage of handoff attempts that would be blocked due to forward power during the measurement interval. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This OM provides the percentage of the measuring interval time, based on 2-second samples, that voice and 2G circuit-switched data calls would be blocked based on the MaxVoiceResources attribute in the AdvancedSector MO. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This OM value is dependent on the RadioConfigState of the AdvancedFA MO. For example, if RadioConfigState = Data_3G, indicating lack of voice resources, then this OM value will be 100%.
sheet 77 of 92
PercentTimeAb oveFwdHandof fBlockThreshol d Modified in Release 14.0
343
PercentTimeAb oveFwdVoiceC allBlockThresh old Modified in Release 14.0
344
411-2133-525
Standard
06.12
April 2008
PercentTimeAb oveFwdDataCa llBlockThreshol d Modified in Release 14.0
This OM provides the percentage of the measuring interval time, based on 2-second samples, that data calls would be blocked based on the MaxDataResources and MaxDataFCHResources attributes in the AdvancedSector MO. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This OM value is dependent on the RadioConfigState of the AdvancedFA MO. For example, if RadioConfigState = Voice_2G_3G, indicating lack of data resources, then this OM value will be 100%.
ConfiguredFwd CallBlockThres hold Modified in Release 14.0 ConfiguredFwd HandoffBlockT hreshold Modified in Release 14.0 ConfiguredFwd VoiceCallBlock Threshold Modified in Release 14.0 ConfiguredFwd DataCallBlockT hreshold Modified in Release 14.0
This threshold applies to both voice and data calls. It represents the total amount of power available for new originations and terminations. Units are bits squared. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This threshold applies to both voice and data calls. It represents the total amount of power available for soft and hard handoff attempts into the BTS. Units are bits squared. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This metric represents the amount of power available for voice originations, terminations, and handoffs into the BTS. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array. This metric represents the amount of power available for data originations, terminations, and handoffs into the BTS. For AABS sector, there are three elements in the array. Each one relates to one beam. For conventional sector, there is only one element in the array.
sheet 78 of 92
346
347
348
349
CDMA
NBSS15.0
FwdTxPowerU sageHistogram Modified in 14.0 release
This OM array (for conventional sector) provides the transmit power usage information. It indicates the time duration in seconds during which the forward transmit power is distributed within a certain occupancy range. It is pegged every 2 seconds in the appropriate occupancy range based on the forward transmit power level. The value pegged is in seconds. At the end of 30 minutes each occupancy range mentioned below will have the total time in seconds the power level spent in each range. The total value of the all the occupancy range should be equal to 1800 seconds. The forward transmit power includes voice FCH, data FCH, SCH power, OCNS and overhead power. For AABS sector, there are three such arrays, one for each beam. This OM represents the number of seconds the forward transmit power is within the occupancy range of 0%-9% This OM represents the number of seconds the forward transmit power is within the occupancy range of 10%-19% This OM represents the number of seconds the forward transmit power is within the occupancy range of 20%-29% This OM represents the number of seconds the forward transmit power is within the occupancy range of 30%-39% This OM represents the number of seconds the forward transmit power is within the occupancy range of 40%-49%
sheet 79 of 92
ForwardTxPow erUsageHistog ram[0]:Range0t o9 ForwardTxPow erUsageHistog ram[1]:Range1 0to19 ForwardTxPow erUsageHistog ram[2]:Range2 0to29 ForwardTxPow erUsageHistog ram[3]:Range3 0to39 ForwardTxPow erUsageHistog ram[4]:Range4 0to49
part of 350
part of 350
part of 350
part of 350
part of 350
411-2133-525
Standard
06.12
April 2008
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
ForwardTxPow erUsageHistog ram[5]:Range5 0to59 ForwardTxPow erUsageHistog ram[6]:Range6 0to69 ForwardTxPow erUsageHistog ram[7]:Range7 0to79 ForwardTxPow erUsageHistog ram[8]:Range8 0to89 ForwardTxPow erUsageHistog ram[9]:Range9 0to100
This OM represents the number of seconds the forward transmit power is within the occupancy range of 50%-59% This OM represents the number of seconds the forward transmit power is within the occupancy range of 60%-69% This OM represents the number of seconds the forward transmit power is within the occupancy range of 70%-79% This OM represents the number of seconds the forward transmit power is within the occupancy range of 80%-89% This OM represents the number of seconds the forward transmit power is within the occupancy range of 90%-100%. Note: This OM also gets pegged for occupancy ranges above 100%.
sheet 80 of 92
part of 350
part of 350
part of 350
part of 350
CDMA
NBSS15.0
BTSCallProce ssing MO OMs PagingChannel MessageCount
The OMs in this group are pegged on a per BTS basis. This OM provides number of paging channel messages sent to the BTS by the PAM in the CAU. This includes pages, repages, SMS, etc. The number of pegs is the sum of all events in every frequency and every sector hosted by the BTS. This OM provides number of paging channel messages dropped by the BTSC due to BTSC CPU overload. The number of pegs is the sum of all events in every frequency and every sector hosted by the BTS.
sheet 81 of 92
52
PagingChannel MessagesDrop ped
53
411-2133-525
Standard
06.12
April 2008
CBCM MO OMs
Cdma Btsc Control Module. The CBCM provides management of the entire MCBTS, communications over the T1/E1 and to the mate DCG.The CBCM hardware is composed of the BTS controller and the BTS Interface. This MO OMs peg on a per BTS basis. CPU usage for BTSC is provided as an array. There are 10 indexes in the array. The first index represents a CPU utilization between 0 to 9 percent, the second index represents a CPU utilization between 10 to 19 percent and so on. The tenth index represents a CPU utilization between 90 to 100 percent. Each index of the array provides the time (in seconds), CPU utilization was within the range represented by the index. The CPU utilization is measured over a period of 4 seconds so time duration provided by each index is a multiple of 4. Counts of paging spikes within the half hour OM collection interval. Counts of paging storms within the half hour OM collection interval. Total counts of paging spikes from the start of OM collection. Total counts of paging storms from the start of OM collection.
sheet 82 of 92
BtscCpuUsage Histogram
34
CongCtrlHalfH ourSpikeCount CongCtrlHalfH ourStormCount CongCtrlTotalS pikeCount CongCtrlTotalS tormCount
42
43
44
45
CDMA
NBSS15.0
Power Management MO OMs
The OMs in this group peg on a per Sector per Freq. basis for conventional sectors. For AABS sectors, the OMs in this group peg on a per beam per Frequency basis. That means there are 3 sets of OM data for an AABS sector compared to one set of OM data for a conventional sector. This OM provides the average transmitted power for the carrier-sector over the thirty minute observation period (1/16 dBm). In previous releases, the averaging was incorrectly performed in logarithmic units. For NBSS14, averaging occurs in linear units for all radios. This OM provides the maximum transmitted power for the carrier-sector over the thirty minute observation period (1/16 dBm). This OM provides the average receive power for the main branch (1/16 dB relative to -120 dBm). In previous releases, the averaging was incorrectly performed in logarithmic units. For NBSS14, averaging occurs in linear units for all radios. This OM provides the average receive power for the diversity branch (1/16 dB relative to -120 dBm). In previous releases, the averaging was incorrectly performed in logarithmic units. For NBSS14, averaging occurs in linear units for all radios. This OM provides the maximum receive power for the main branch (1/16 dB relative to -120 dBm). This OM provides the maximum receive power for the diversity branch (1/16 dB relative to -120 dBm). This OM provides the percentage of time the carriersector was in power limiting state over the thirty minute observation period.
sheet 83 of 92
CarrierTxPowe rAvg Modified in Release 14.0
59
CarrierTxPowe rMax CarrierRx0Pow erAvg Modified in Release 14.0 CarrierRx1Pow erAvg Modified in Release 14.0 CarrierRx0Pow erMax CarrierRx1Pow erMax PercentPowerL imiting
60
62
63
64
65
67
411-2133-525
Standard
06.12
April 2008
ConfiguredPow erLimitingThres hold Added in 11.0 release TPTLMapping Added in 11.0 release AvgTxPowerAb oveMaxSPP Added in 14.0.1 Release
Power level in mW at which power limiting will be activated.
Power level in mW corresponding to a digital gain of 254^2
92
The average transmit power transmitted above the configured power limiting threshold for a carriersector. This OM will be zero when sector power pooling is disabled (i.e. attribute RFM MO: SectorPowerPoolingEnabled = False). Measured in units of dB/16, the value has a range of 0 to 160. This OM is collected on MFRM3 only.
94
ConfiguredPow erLimitingThre sholdSPP Added in 14.0.1 Release
The power level at which power limiting in the carrier-sector will be activated referenced on the module output (i.e. at the DPM antenna port). This OM includes the allowed increase in carrier-sector power when sector power pooling is enabled (i.e. (i.e. attribute RFM MO: SectorPowerPoolingEnabled = True). Measured in mW. This OM is collected on MFRM3 only.
sheet 84 of 92
103
CDMA
NBSS15.0
DemandedPow erStats Added in 14.0.1 Release
"DemandedPowerStats" provides a CDF (cumulative distribution function) of the demanded transmit power for the carrier-sector over the 30 minute observation period. The statistics are contained in an eight field array as follows: 1. 2. 3. 4. 5. 6. 7. 8. 50th Percentile 80th Percentile 90th Percentile 95th Percentile 98th Percentile 99th Percentile PercentTimeAboveConfiguredPowerLimitingThreshol d PercentTimeAboveConfiguredPowerLimitingThreshol dSPP
Values returned in the array elements 1-6 correspond to the power value (relative to the ConfiguredPowerLimitingThreshold) where x% of the time (x is the corresponding array element percentile), the demanded transmit power in the carrier-sector was less than or equal to this power value. Units are percentage of ConfiguredPowerLimitingThreshold/10. For example, a value of 1400 returned in the second field (80th Percentile) indicates that 80% of the time, the demanded transmit power in the carrier-sector was less than or equal to 140% of ConfiguredPowerLimitingThreshold. Value returned in the 7th field (PercentTimeAboveConfiguredPowerLimitingThres hold) of the array corresponds to the percentage of time the demanded transmit power in the carriersector was above ConfiguredPowerLimitingThreshold. Units are percent/10. For example, a value of 200 returned in the 7th field indicates that 20% of the time the demanded transmit power in the carrier-sector
sheet 85 of 92
411-2133-525
Standard
06.12
April 2008
Reference chapter
was above ConfiguredPowerLimitingThreshold. Similarly, value returned in the 8th field of the array corresponds to the percentage of time demanded transmit power in the carrier-sector was above ConfiguredPowerLimitingThresholdSPP. Units are percent/10. These OMs are collected on MFRM3 only.
sheet 86 of 92
CDMA
NBSS15.0
DeliveredPowe rStats Added in 14.0.1 Release
"DeliveredPowerStats" provides a CDF (cumulative distribution function) of the delivered transmit power for the carrier-sector over the 30 minute observation period. The statistics are contained in an seven field array as follows: 1. 2. 3. 4. 5. 6. 7. 50th Percentile 80th Percentile 90th Percentile 95th Percentile 98th Percentile 99th Percentile PercentTimeAboveConfiguredPowerLimitingThreshol d
Values returned in the array elements 1-6 correspond to the power value (relative to the ConfiguredPowerLimitingThreshold) where x% of the time (x is the corresponding array element percentile), the delivered transmit power in the carrier-sector was less than or equal to this power value. Units are percentage of ConfiguredPowerLimitingThreshold/10. For example, a value of 900 returned in the second field (80th Percentile) indicates that 80% of the time, the delivered transmit power in the carrier-sector was less than or equal to 90% of ConfiguredPowerLimitingThreshold. Value returned in the 7th field (PercentTimeAboveConfiguredPowerLimitingThres hold) of the array corresponds to the percentage of time the delivered transmit power in the carriersector was above ConfiguredPowerLimitingThreshold. Units are percent/10. For example, a value of 100 returned in the 7th field indicates that 10% of the time the delivered transmit power in the carrier-sector was above ConfiguredPowerLimitingThreshold. These OMs are collected on MFRM3 only.
sheet 87 of 92
411-2133-525
Standard
06.12
April 2008
Radio Sector MO OMs SectorPercent PowerLimiting
This MO OMs peg on a per Sector basis.
This OM provides the percentage of time the sector was in a power limiting state over the thirty minute observation period. A sector is defined to be in a power limiting state when all carrier-sectors configured in that sector are in a power limiting state. This OM provides the maximum sector transmit power at the module output (i.e. at the DPM antenna port) during the thirty minute observation period. Range is 0 1120 (Units = dBm/16). This OM provides the lowest (worst) return loss measured for the sector during the 30 minute observation period. This OM helps the customer detect changes in the performance of RF equipment external to the MFRM-3 radio (i.e. antennas, cabling, etc.) prior to service impacts. (Units = dB/16). This OM provides the average sector transmit power at the module output (i.e. at the DPM antenna port) over the thirty minute observation period. Measured in units of dBm/16, the value has a range of 0 to 1120.
sheet 88 of 92
SectorTxPower Max
BTS performance (page 9-1) 48 BTS performance (page 9-1)
VSWRReturnL oss Added in 14.0.1 Release
SectorTxPower Avg Added in 14.0.1 Release
55
CDMA
NBSS15.0
RFM MO
The OMs in this MO peg on a per-radio basis.
RadioTxPower Max Added in 14.0.1 Release
This OM provides the maximum transmitted power for the radio over the thirty minute observation period. The radio transmit power is defined as the aggregate sum of power transmitted for all carriers in all sectors. Measured in units of dBm/16, the attribute has a range of 0 to 1120 (0-70 dBm). This OM is collected on MFRM3 only.
66
RadioTxPower Avg Added in 14.0.1 Release
This OM provides the average transmitted power for the radio over the thirty minute observation period. The radio transmit power is defined as the aggregate sum of power transmitted for all carriers in all sectors. Measured in units of dBm/16, the attribute has a range of 0 to 1120 (0-70 dBm). This OM is collected on MFRM3 only.
68
MultiSectorCar rierPowerStats Added in 14.0.1 Release
This is an array containing sub-arrays (one for each carrier). Each sub-array provides the CCDF (complementary cumulative distribution function) of the demanded transmit power of the configured carrier across all sectors (i.e. demanded transmit power on F1 across alpha, beta and gamma sectors) over the 30 minute observation period. These OMs are collected on MFRM3 only. The first field of the array MultiSectorCarrierPowerStats represents the number of configured carriers (the number of subarrays = number of carriers. Each sub-array contains 8 fields of info). Thus the size of this array depends upon how many carriers are configured. The different fields of this array are described below.
70
MultiSectorCar rierPowerStats [0]: Count
This gives the number of configured carriers.
Part of 70
sheet 89 of 92
411-2133-525
Standard
06.12
April 2008
Sequence number (if applicable) Part of 70
Reference chapter BTS performance (page 9-1) BTS performance (page 9-1) BTS performance (page 9-1)
MultiSectorCar rierPowerStats [1]: CDMA_FREQ MultiSectorCar rierPowerStats [2]: BAND_CLASS MultiSectorCar rierPowerStats [3]: Count
This gives the frequency of the CDMA carrier.
This gives the band class of the CDMA carrier.
Part of 70
The number of elements in the sub-array PowerStats below. Note: This is not an OM. The value of this field will always be 5 since there are 5 elements in the subarray PowerStats. This info (i.e. length of the array) is given out by default by the BSSM software whenever the data type of the attribute is Word16Array. This Count field is included here to avoid confusion and assist the reader in reading these OMs better.
sheet 90 of 92
Part of 70
CDMA
NBSS15.0
Sequence number (if applicable) Part of 70
MultiSectorCar rierPowerStats [4] to MultiSectorCar rierPowerStats [8]: PowerStats
A CCDF (complementary cumulative distribution function) histogram of the demanded transmit power for the carrier over all the three sectors over the 30 minute observation period. The statistics are contained in a five field array. The contents of the arrays are as follows: 1. PerCarrierPowerLimitingThreshold - 2 dB 2. PerCarrierPowerLimitingThreshold - 1 dB 3. PerCarrierPowerLimitingThreshold 4. PerCarrierPowerLimitingThreshold + 1 dB 5. PerCarrierPowerLimitingThreshold + 2 dB Values returned in the array correspond to the percentage of time that the transmit power demanded was greater than the fields corresponding power. Units are percent/200. For example, a value of 1000 returned in the third field (PerCarrierPowerLimitingThreshold) indicates that the transmit power demanded by the carrier across sectors was greater than the PerCarrierPowerLimitingThreshold (i.e. maximum power available to the carrier), 5% of the time (1000 / 200). In other words, the carrier was in power limiting 5% of the time. The sampling period of these OMs is 100ms.
sheet 91 of 92
411-2133-525
Standard
06.12
April 2008
RadioPowerSt ats Added in 14.0.1 Release
A CCDF (complementary cumulative distribution function) histogram of the demanded transmit power of the radio over the 30 minute observation period. This value is an aggregate sum of the power demanded for all carriers in all sectors. The statistics are contained in a five field array and defined as follows: 1. 2. 3. 4. 5. PerTransmitChainPowerLimitingThreshold - 2dB PerTransmitChainPowerLimitingThreshold - 1dB PerTransmitChainPowerLimitingThreshold PerTransmitChainPowerLimitingThreshold + 1 dB PerTransmitChainPowerLimitingThreshold + 2 dB
Values returned in the array correspond to the percentage of time that the transmit power demanded was greater than the fields corresponding power. Units are percent/200. For example, a value of 1000 returned in the third field (PerTransmitChainPowerLimitingThreshold) indicates that the transmit power demanded was greater than the PerTransmitChainPowerLimitingThreshold, 5% of the time (1000 / 200). In other words, the radio was in power limiting 5% of the time. The sampling period of these OMs is 100ms. These OMs are collected on MFRM3 only.
sheet 92 of 92
CDMA
NBSS15.0
23-94 BTS OM descriptions Nortel Networks
411-2133-525
Standard
06.12
April 2008
test
Family Product Manual Contacts Copyright Confidentiality Legal
CDMA
Operational Measurements Reference

System Performance Metrics
Copyright 2008 Nortel Networks, All Rights Reserved Document number: 411-2133-525 Product release:NBSS15.0 Date:April 2008 To order documentation from Nortel Networks Global Wireless Knowledge Services, call (1) (877) 662-5669 To report a problem in this document, call (1) (877) 662-5669 or send e-mail from the Nortel Networks Customer Training & Documentation World Wide Web site at http://www.nortel.com/documentfeedback
This document is protected by copyright laws and international treaties. All information, copyrights and any other intellectual property rights contained in this document are the property of Nortel Networks. Except as expressly authorized in writing by Nortel Networks, the holder is granted no rights to use the information contained herein and this document shall not be published, copied, produced or reproduced, modified, translated, compiled, distributed, displayed or transmitted, in whole or part, in any form or media. Information is subject to change without notice. Nortel Networks reserves the right to make changes in design or components as progress in engineering and manufacturing may warrant. * Nortel Networks, the Nortel Networks logo, the Globemark, and Unified Networks are trademarks of Nortel Networks. Trademarks are acknowledged with an asterisk (*) at their first appearance in the document. Originated in the United States of America

411 2133 525 06 12

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

411 2133 525 06 12

Caricato da

Copyright:

Formati disponibili

411-2133-525

Operational Measurements Reference System Performance Metrics

Operational Measurements Reference System Performance Metrics

Copyright Country of printing Confidentiality Legal statements Trademarks

Copyright 2008 Nortel Networks

v Copyright 2008 Nortel Networks

New in this release

CDMA OM design overview

Call setup performance

System Performance System Performance Metrics

vi Contents Nortel Networks

1xRTT packet data performance

3-47 3-47 3-48 3-49

RLP throughput performance

Access robustness package performance

Dropped call performance

System Performance System Performance Metrics

Copyright 2008 Nortel Networks

Intelligent voice service negotiations performance

System Performance System Performance Metrics

x Contents Nortel Networks

Copyright 2008 Nortel Networks

Border paging performance

Data burst message delivery performance

Location services performance

Contents xi Copyright 2008 Nortel Networks

Call resource allocation and management

System Performance System Performance Metrics

xii Contents Nortel Networks

Nortel Networks SCH formula 17-4 Recommendations 17-5

Contents xiii Copyright 2008 Nortel Networks

Call flow diagrams with OMs

System Performance System Performance Metrics

xiv Contents Nortel Networks

Nortel Networks Table 13-1

Front xv Copyright 2008 Nortel Networks

System Performance System Performance Metrics

xvi Front Nortel Networks

Copyright 2008 Nortel Networks

xvii Copyright 2008 Nortel Networks

About this document

System Performance System Performance Metrics

xviii About this document Nortel Networks

Copyright 2008 Nortel Networks

About this document xix Copyright 2008 Nortel Networks

System Performance System Performance Metrics

xx About this document Nortel Networks

Copyright 2008 Nortel Networks

Indication of hypertext links

1-xxi Copyright 2008 Nortel Networks

New in this release

System Performance System Performance Metrics

1-xxii New in this release Nortel Networks

Copyright 2008 Nortel Networks

1-1 Copyright 2008 Nortel Networks

CDMA OM design overview

System Performance System Performance Metrics

1-2 CDMA OM design overview Nortel Networks

Copyright 2008 Nortel Networks

CDMA OM design overview 1-3 Copyright 2008 Nortel Networks

1-4 CDMA OM design overview Nortel Networks

Copyright 2008 Nortel Networks