MSC SErver O&M Guide

All-IP CDMA2000
Sonata Core Voice Network

Release 4.5.3
MSC Server
Operations and Maintenance Guide
Part Number D02115 Rev A0

All-IP CDMA2000
Sonata Core Voice Network
Release 4.5.3
MSC Server
Operations and Maintenance Guide

Copyright 2009, Global Star Solutions ULC. All rights reserved. No part of this documentation may be reproduced in any form
or by any means or used to make any derivative work (such as translation, transformation, or adaptation) without prior written
permission from Global Star Solutions ULC.
Global Star Solutions ULC reserves the right to revise this documentation and to make changes in content from time to time
without obligation on the part of Global Star Solutions ULC to provide notification of such revision or change.
Global Star Solutions ULC provides this documentation without warranty of any kind, either implied or expressed, including, but
not limited to, the implied warranties of merchantability and fitness for a particular purpose. Star Solutions may make
improvements or changes in the product(s) and/or the program(s) described in this documentation at any time.
UNITED STATES GOVERNMENT LEGENDS:
If you are a United States government agency, then this documentation and the software described herein are provided to you
subject to the following:
United States Government Legend: All technical data and computer software is commercial in nature and developed solely at
private expense. Software is delivered as Commercial Computer Software as defined in DFARS 252.227-7014 (June 1995) or as a
commercial item as defined in FAR 2.101(a) and as such is provided with only such rights as are provided in Star Solutions's
standard commercial license for the Software. Technical data is provided with limited rights only as provided in DFAR
252.227-7015 (Nov 1995) or FAR 52.227-14 (June 1987), whichever is applicable. You agree not to remove or deface any portion
of any legend provided on any licensed program or documentation contained in, or delivered to you in conjunction with, this
User Guide.
Star Solutions, the Star Solutions logo, iCell, Softexchange, Sonata, Sonata Access Tandem, Sonata HLR, Sonata IP, Sonata MSC,
Sonata WLL, and Telos are registered trademarks or trademarks of Global Star Solutions ULC and its subsidiaries.
CDMA2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA).
Intel and Pentium are registered trademarks of the Intel Corporation or its subsidiaries in the United States and other countries.
Microsoft, Windows, Windows NT, and NetMeeting are registered trademarks of Microsoft Corporation. Sun, Java, and Solaris
are trademarks or registered trademarks of Sun Microsystems, Inc. Oracle is a registered trademark of Oracle Corporation. HP,
HP-UX, and HP Openview are trademarks or registered trademarks of the Hewlett-Packard Company. UTStarcom, the
UTStarcom logo, MovingMedia, mSwitch, and Total Control are registered trademarks or trademarks of UTStarcom, Inc. and its
subsidiaries.
Other brand and product names may be registered trademarks or trademarks of their respective holders.
CONTENTS
ABOUT THIS GUIDE

Prerequisite - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6
Conventions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6
Notices - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6
Figures and Screen Captures- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7
Text - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7
Related Documentation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7
Core Voice Network Documents- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 8
Technical Support - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11
Obtaining Technical Assistance - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11
Service Centers Operational Hours - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11
Warranty Support - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 11
Contacting Technical Documentation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 12
PART I OVERVIEW
1 OVERVIEW
MSC Server Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 16
Sonata System Architecture - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 16
Core Voice Network Elements- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 16
Network Element Interactions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 17
MSC and SSVR Configurations- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 17
MSC Server - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 17
PART II OPERATIONS, ADMINISTRATION AND MAINTENANCE
2 OPERATIONS, ADMINISTRATION, AND MAINTENANCE OVERVIEW

Prerequisite - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 20
MSC Operations, Administration and Maintenance- - - - - - - - - - - - - - - - - - - - - - - - - - - 20
Operating Tasks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 20
Task and Shift Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 20
Recording Faults - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 21
MSC Operator Tasks- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 22
New Shift Handover - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23
Prerequisite - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23
Check CDR Usage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23
Check Subscriber Numbers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 23
Check Trunk Status - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 24
Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Part Number D02115 Rev A0 | March 2009
6 Contents
Check MGCP Link Status - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 25

Check SCCP-Lite Link Status - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 25
Make Test Calls- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 26
Making Test Calls - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 26
End of Shift - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 26
Administrator and Maintenance Tasks - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 26
3 USER ACCOUNTS AND F ILESYSTEMS

MSC User Accounts - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 28
MSC Application Account - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 29
4 CONFIGURING CALL DETAIL RECORDS

Call Detail Records Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 30
What are Call Detail Records - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 30
Call Detail Record Handling - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 31
CDR Format - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 31
CDR Collection Process - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 31
Generating CDRs (at the MSC) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 32
Retrieving CDR Files (from the MSC by the OMC) - - - - - - - - - - - - - - - - - - - - - - - - - 32
Providing CDR Files (to the Billing Server by the OMC) - - - - - - - - - - - - - - - - - - - - - 32
Pull Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 32
Push Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 32
CDR File Storage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 33
CDR Generation in HA Configuration- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 33
CDR Storage Capacity at the MSC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 33
Traffic and Capacity Estimates - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 34
CDR Storage Capacity at the OMC- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 34
Configuring CDR Generation at the MSC- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 35
Configuring the CDR Flush Timer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 35
Configuring the CDR File Generation Timer- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 36
Configuring CDR File Naming - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 38
Configuring the Maximum Number of CDR Files on MSC Disk - - - - - - - - - - - - - - - - 39
Configuring the CDR Version - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 40
Configuring CDR Retrieval at the OMC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 41
crontab - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 41
To Verify, Add, or Change CDR Transfer cron Job: - - - - - - - - - - - - - - - - - - - - - - - 42
Configuration Settings in ~/CONF/trans.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 42
Configuring LDAP or Local Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 42
Configuring MSC User Account Information- - - - - - - - - - - - - - - - - - - - - - - - - - - 43
Configuring CDR File Format - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 43
Configuring File Renaming - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 44
Configuring the OMC Directory for the CDR Files - - - - - - - - - - - - - - - - - - - - - - - 44
Configuring the OMC CDR Directory Structure - - - - - - - - - - - - - - - - - - - - - - - - - 44
Sample trans.conf Files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 45
Configuring CDR Files for a Billing Server - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 48
Configuring the OMC for the Pull Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 48

Contents 7
Configuring the OMC for the Push Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 49

To View and Edit crontab: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 49
Configuration Settings in ~/CONF/trans.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 49
Billing Server IP Address / Hostname - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 50
Billing Server Login - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 50
Retries After Failure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 50
CDR File Compression - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 50
CDR File Directory on the Billing Server - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 50
Retention Period for Pushed Files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 51
CDR Directory Structure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 51
Sample trans.conf Files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 51
CDR File Persistence on OMC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 53
5 VIEWING AND MANAGING CALL DETAIL RECORDS

CDR File Operations at the MSC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 54
Listing CDR Files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 54
Displaying CDRs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 54
cdr_reporter Tool Usage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 55
Viewing Current Day CDR Log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 56
Viewing CDR Log for Multiple Days - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 57
CDR File Operations at the OMC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 58
Archiving Transferred CDR Files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 58
Manually Removing Pushed CDR Files- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 58
Automating CDR Archival and Removal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 59
CDR File Maintenance at the MSC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 59
Verifying CDR Generation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 59
Verifying CDR File Generation- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 60
cdr_info Tool - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 60
Usage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 60
Viewing CDR Transaction Summary- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 61
Checking for CDR Record Corruption- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 62
Checking Available Disk Space for CDRs- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 63
Freeing Space in ~/DATA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 64
CDR File Maintenance at the OMC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 65
Verifying Persistence of Retrieved CDR Files - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 65
Manually Removing CDR Files- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 65
Checking the CDR File Conversion Log- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 66
Push Model Only: Verifying CDR Transfer to Billing Server - - - - - - - - - - - - - - - - - - - 66
Binary CDR Format - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 67
Data Types - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 67
Field Descriptions- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 69
CDR Disconnect Codes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 74
C Language Structure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 78
XML CDR Format - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 78
XML CDR Tag Description - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 79
XML CDR Examples- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 80
ASCII CDR Format - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 82

8 Contents
Mobile-Originated Voice Scenarios - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 83

Land-Terminated- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 83
Mobile-Terminated (Local MSC is Serving MSC) - - - - - - - - - - - - - - - - - - - - - - - - 83
Mobile-Terminated (Serving MSC is a Different MSC) - - - - - - - - - - - - - - - - - - - - 84
Mobile-Terminated Mobile (Unconditional Forwarding)- - - - - - - - - - - - - - - - - - 86
Land-Originated Voice Scenarios- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 88
Land-Terminated- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 88
Mobile-Terminated Land (TLDN on Local MSC/VLR) - - - - - - - - - - - - - - - - - - - - - 88
Mobile-Terminated Land (TLDN on Remote MSC/VLR) - - - - - - - - - - - - - - - - - - - 89
Mobile-Terminated Land (Unconditional Forwarding) - - - - - - - - - - - - - - - - - - - 91
In-Call Feature Scenarios - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 92
Forwarding - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 92
Multiple Call Forwarding - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 92
Call Waiting - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 96
Three-Way Call - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 97
Call Transfer - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 99
PCO Calls - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 102
Short Message Service Scenarios - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 105
Mobile-Originated SMS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 105
Mobile-Terminated SMS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 106
6 PERFORMANCE MANAGEMENT
Performance Management on the MSC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 108
Prerequisite - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 108
MSC Statistics Collection Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 108
Building a Short-Term Performance History- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 109
Building a Long-Term Performance History - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 110
Trunk Group Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 110
Trunk Group Summary Report - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 110
Trunk Group Detail Report - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 112
Call Processing and Mobility Management Statistics - - - - - - - - - - - - - - - - - - - - - - - - - 114
Emergency Calls - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 114
HLR Interrogations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 116
Inter MSC Handoff - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 117
Intra MSC Handoff - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 121
Mobile Originated Calls - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 122
Mobile Terminated Calls - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 123
Mean Call Time - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 123
---------------------------------------------------------- 125
Paging - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 125
Performance Characteristics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 126
SMS Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 127
All Statistics Report - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 128
BSC Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 129
Emergency Calls (BSC facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 130
Features (BSC facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 131
Handoff (BSC facing)- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 132

Contents 9
Location Updates (BSC facing)- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 134

MO Calls (BSC facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 135
MT Calls (BSC facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 136
Mean Call Time (BSC facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 139
Mobile Lost - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 140
Paging - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 140
SMS (BSC Facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 142
Usage- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 146
All Statistics Report (BSC Facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 149
Performance Analysis - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 150
Traffic Engineering - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 150
Traffic Engineering for Trunk Groups - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 150
Traffic Engineering for Call Processing and Mobility Management - - - - - - - - - 151
Basic Performance Calculations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 151
7 ALARM MANAGEMENT
Alarms Overview - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 152
Alarm Severity - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 152
Critical - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 152
Major - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 152
Minor - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 152
Warning - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153
Alarm Types - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153
Processing Error - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153
Equipment - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153
Communications- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153
Automatic and Manual Alarm Clearing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153
Automatic Alarm Clearing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 153
Manual Alarm Clearing - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
Alarm Root Causes- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
Communications Protocol Error- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
Configuration or Customization Error - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
Congestion - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
Corrupt Data- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
File Error - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
Out of Memory- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 154
Out of Service - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 155
Power Problem - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 155
Resource at or Nearing Capacity - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 155
Response Time Excessive - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 155
Software Program Abnormally Terminated - - - - - - - - - - - - - - - - - - - - - - - - - - 155
Software Error - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 155
Transmit Failure - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 155
uUnderlying Resource Unavailable - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 155
Unspecified Reason- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156
Fault Localization - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156
Common Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156

10 Contents
MSC and VLR Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156

Critical MSC Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156
MegSpanAlarm - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156
Major MSC Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156
AspAlarmNoFreeCall - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 157
AspAlarmNoFreeParty- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 157
LfmAlarmNoFreePort - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 158
SsfAlarmNoFreeCS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 158
SsfAlarmNoFreeCSA - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 158
SsfAlarmNoFreeOBCSM - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 159
SsfAlarmNoFreeTBCSM - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 159
SsfAlarmNoFreeSSF- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 159
Minor MSC Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 160
Warning MSC Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 160
VsmAlarmTrunkCongestion - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 160
VsmAlarmTrunkFault- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 160
VsmAlarmStateChngFail - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 161
VsmAlarmInvalidPort - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 161
MegGatewayAlarm - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 161
8 TROUBLE LOCATING AND CLEARING

Viewing MSC Event Logs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 162
Viewing Call Detail Records- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 162
Viewing SMS Detail Records - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 163
Viewing Call and SMS Detail Records- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 164
MSC Subsystems - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 166
Trace Manager- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 169
MSC Traceable Modules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 169
Selective Call Trace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 169
Example of a Selective Call Trace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 170
Deleting a Subscriber from the VLR - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 171
A ACRONYMS
INDEX

1 Tables
LIST OF TABLES
Table 1 Notice Icon Descriptions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 6
Table 2 Text Convention Descriptions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 7
Table 3 Operator Shift Checklist - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 22
Table 4 MSC Account and Task Mapping - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 29
Table 5 MSC Account Default Logon Details- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 29
Table 6 73 GB MSC Disk Allocations- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 34
Table 7 BHCA CDR Estimates - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 34
Table 8 73 GB OMC Disk Allocations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 35
Table 9 t_file Timer Parameters - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 37
Table 10 num_files Parameters - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 39
Table 11 trans.conf Settings for LDAP Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 46
Table 12 trans.conf Settings for Local Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 47
Table 13 CDR FTP Configuration Parameters - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 52
Table 14 cdr_reporter Command Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 55
Table 15 cdr_info Command Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 60
Table 16 cdr_info Field Description - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 61
Table 17 Call and SMS Summary Table Field Descriptions - - - - - - - - - - - - - - - - - - - - 62
Table 18 du Command Options - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 64
Table 19 CDR Data Types- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 67
Table 20 CDR Version 11 Field Descriptions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 69
Table 21 CDR Disconnect Codes - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 74
Table 22 XML Tag Descriptions - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 79
Table 23 Derived Trunk Group Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 111
Table 24 Trunk Group Detail Report Fields- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 113
Table 25 MegSpanAlarm Clearing Information- - - - - - - - - - - - - - - - - - - - - - - - - - - - 156
Table 26 AspAlarmNoFreeCall Clearing Information- - - - - - - - - - - - - - - - - - - - - - - - 157
Table 27 AspAlarmNoFreeParty Clearing Information - - - - - - - - - - - - - - - - - - - - 157
Table 28 LfmAlarmNoFreePort Clearing Information- - - - - - - - - - - - - - - - - - - - - - 158
Table 29 SsfAlarmNoFreeCS Clearing Information - - - - - - - - - - - - - - - - - - - - - - - 158
Table 30 SsfAlarmNoFreeCSA Clearing Information- - - - - - - - - - - - - - - - - - - - - - 158
Table 31 SsfAlarmNoFreeOBCSM Clearing Information- - - - - - - - - - - - - - - - - - - 159
Table 32 SsfAlarmNoFreeTBCSM Clearing Information - - - - - - - - - - - - - - - - - - - 159
Table 33 SsfAlarmNoFreeSSF Clearing Information - - - - - - - - - - - - - - - - - - - - - - 159
Table 34 VsmAlarmTrunkCongestion Clearing Information - - - - - - - - - - - - - - - - 160
Table 35 VsmAlarmTrunkFault Clearing Information - - - - - - - - - - - - - - - - - - - - - - 160
Table 36 VsmAlarmStateChngFail Clearing Information - - - - - - - - - - - - - - - - - - - 161
Table 37 VsmAlarmInvalidPort Clearing Information - - - - - - - - - - - - - - - - - - - - - - 161
Table 38 MegGatewayAlarm Clearing Information - - - - - - - - - - - - - - - - - - - - - - - 161
Table 39 MSC Subsystems and Diagnostics - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 167
Table 40 Traceable Modules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 169
Table 41 Selective Call Trace Resources - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 169
Table 42 Selective Call Trace Scenarios - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 170
Table 43 List of Acronyms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 172

Figures 2
LIST OF F IGURES
Figure 1 Core Voice Network Document Map - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 10
Figure 2 Sonata Release 4.5.3 System Architecture - - - - - - - - - - - - - - - - - - - - - - - - - 16
Figure 3 Operator Task Flowchart - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 21
Figure 4 CDR Collection Process - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 32
Figure 5 MSC Disk Allocation - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 34
Figure 6 OMC Disk Allocations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 35
Figure 7 Example: Using CLI to Change t_log_flush - - - - - - - - - - - - - - - - - - - - - - - - - 36
Figure 8 Example: Using CLI to Change t_file - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 38
Figure 9 Example: Using CLI to Change MSCID - - - - - - - - - - - - - - - - - - - - - - - - - - - - 39
Figure 10 Example: Using CLI to Change num_files - - - - - - - - - - - - - - - - - - - - - - - - - - 40
Figure 11 Example: Using CLI to Change out_version - - - - - - - - - - - - - - - - - - - - - - - - 41
Figure 12 Example: acc_trans_sub Entry in crontab - - - - - - - - - - - - - - - - - - - - - - - - - 41
Figure 13 Example: trans.conf Settings for LDAP Mode - - - - - - - - - - - - - - - - - - - - - - - 42
Figure 14 Example: trans.conf Settings for Local Mode - - - - - - - - - - - - - - - - - - - - - - - 43
Figure 15 Example: trans.conf Settings for MSC User Account Information - - - - - - - - 43
Figure 16 Example: trans.conf Setting to Save CDR Files in Binary Format - - - - - - - - - 43
Figure 17 Example: trans.conf Setting to Save CDR Files in XML Format - - - - - - - - - - 43
Figure 18 Example: trans.conf Setting to Replace MSCID in CDR File Names - - - - - - - 44
Figure 19 Example: trans.conf Setting to Add a Suffix to CDR File Names - - - - - - - - - 44
Figure 20 Example: trans.conf Setting for Where to Put CDR Files on the OMC - - - - - 44
Figure 21 Directory Structure for CDRs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 44
Figure 22 Example: trans.conf for LDAP Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 45
Figure 23 Example: trans.conf for Local Mode - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 46
Figure 24 CDR Collection Process - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 48
Figure 25 Example:acc_trans_oss_sub Entry in crontab - - - - - - - - - - - - - - - - - - - - - - 49
Figure 26 Directory Structure for CDRs - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 51
Figure 27 Example: trans.conf for CDR File Push to Billing Server - - - - - - - - - - - - - - - 51
Figure 28 Example: Multiple Day CDR Log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 57
Figure 29 Example: Call and SMS Summary Table - - - - - - - - - - - - - - - - - - - - - - - - - - - 61
Figure 30 CDR Record Checksum - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 62
Figure 31 Example: CDR File with Error Checking - - - - - - - - - - - - - - - - - - - - - - - - - - - 63
Figure 32 Example: du Command Output - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 64
Figure 33 Example: Voice CDR in XML - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 81
Figure 34 Example: SMS CDR in XML - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 82
Figure 35 Example: Land Terminated - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 83
Figure 36 Example: Mobile Terminated (Local MSC is Serving MSC) - - - - - - - - - - - - - 84
Figure 37 Example: Mobile Terminated (Serving MSC is Different MSC) - - - - - - - - - - 85
Figure 38 Example: Record from Second MSC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 85
Figure 39 Example: Mobile Terminated (Unconditional Forwarding) - - - - - - - - - - - - - 86
Figure 40 Example: Record from Second MSC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 87
Figure 41 Example: Land Terminated - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 88
Figure 42 Example: Mobile Terminated (TLDN on Local MSC/VLR) - - - - - - - - - - - - - - 89
Figure 43 Example: Mobile Terminated (TLDN on Remote MSC / VLR) - - - - - - - - - - - 90
Figure 44 Example (cont.): Record from Second MSC - - - - - - - - - - - - - - - - - - - - - - - - 90
Figure 45 Example: Mobile Terminated (Unconditional Forwarding) - - - - - - - - - - - - - 91
Figure 46 Example: Multiple Call Forward, First MSC, A Calls B - - - - - - - - - - - - - - - - - 93
Figure 47 Example: Multiple Call Forward, First MSC, B Forwards to C - - - - - - - - - - - 93
Figure 48 Example: Multiple Call Forward, First MSC, C Forwards to D - - - - - - - - - - - 94
Figure 49 Example: Multiple Call Forward, Second MSC, C Forwards to D - - - - - - - - - 94
Figure 50 Example: Multiple Call Forward, Second MSC, D Forwards to E - - - - - - - - - 95
Figure 51 Example: Multiple Call Forward, Second MSC, E Forwards to F - - - - - - - - - 95
Figure 52 Example: Call Waiting - Original Call - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 96

3 Figures
Figure 53 Example: Call Waiting - Call Waiting Call - - - - - - - - - - - - - - - - - - - - - - - - - - 97

Figure 54 Example: 3-Way Call (First Part) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 98
Figure 55 Example: 3-Way Call (Second Part) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 98
Figure 56 Example: CT from Holding 2-way State, first CDR - - - - - - - - - - - - - - - - - - 100
Figure 57 Example: CT from Holding 2-way State, second CDR - - - - - - - - - - - - - - - - 100
Figure 58 Example: CT from 3-way State, first CDR - - - - - - - - - - - - - - - - - - - - - - - - - 101
Figure 59 Example: CT from 3-way State, second CDR - - - - - - - - - - - - - - - - - - - - - - 102
Figure 60 Example: Prepaid PCO to Local Mobile with SCP Charge Rate ID - - - - - - - 103
Figure 61 Example: Prepaid PCO Call to Land with CRG Charge Rate ID - - - - - - - - - - 104
Figure 62 Example: Prepaid PCO to Land with Charge Rate in DMH Service ID, but ISUP
Message Indicates Free Call 105
Figure 63 Example: Mobile Originated SMS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 106
Figure 64 Example: Mobile Terminated SMS - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 106
Figure 65 Performance Architecture - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 109
Figure 66 MSC Statistics Collection Points - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 109
Figure 67 Trunk Group Summary Report - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 111
Figure 68 Collection Points for Trunk Group Statistics - - - - - - - - - - - - - - - - - - - - - - - 112
Figure 69 Trunk Group Detail Report - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 112
Figure 70 Emergency Calls Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 115
Figure 71 HLR Interrogations Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 116
Figure 72 Successful LocationRequest - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 116
Figure 73 Successful TransferToNumberRequest - - - - - - - - - - - - - - - - - - - - - - - - - - 117
Figure 74 Successful TLDN Returned - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 117
Figure 75 Inter MSC Handoff Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 118
Figure 76 Collection Points for Inter MSC Handoff Performance Statistics - - - - - - - - 118
Figure 77 Handoff Out Completed (Backward) Statistics Collection Point - - - - - - - - 119
Figure 78 Handoff Out Completed (Forward) Statistics Collection Point - - - - - - - - - 119
Figure 79 Handoff In Attempts (FACDIR) Statistics Collection Point - - - - - - - - - - - - - 120
Figure 80 Handoff In Attempts (HANDBACK) Statistics Collection Point - - - - - - - - - - 120
Figure 81 Intra MSC Handoff Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 121
Figure 82 Collection Points for Intra MSC Performance Statistics - - - - - - - - - - - - - - 121
Figure 83 Mobile Originated Calls Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 122
Figure 84 Mobile Originated Call Statistic Collection Points - - - - - - - - - - - - - - - - - - 122
Figure 85 Mobile Terminated Calls Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 123
Figure 86 Mobile Terminated Call Statistic Collection Points - - - - - - - - - - - - - - - - - - 123
Figure 87 Mean Time Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 124
Figure 88 Mean Time to Establish Calls - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 124
Figure 89 Mean Time for Location Update - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 125
Figure 90 Paging Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 126
Figure 91 Collection Points for Paging Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - 126
Figure 92 SMS Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 128
Figure 93 Collection Points for SMS Call Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - 128
Figure 94 All Statistics Report - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 129
Figure 95 Emergency Calls Graph (BSC Facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - 130
Figure 96 Feature Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 131
Figure 97 Collection Point for Feature Update Request Statistics - - - - - - - - - - - - - - 131
Figure 98 Handoff Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 132
Figure 99 Collection Points for Handoff In and Handoff Out Statistics - - - - - - - - - - - 133
Figure 100 Collection Point for Handoff Failed Statistic - - - - - - - - - - - - - - - - - - - - - - 133
Figure 101 Location Updates Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 134
Figure 102 Location Update Attempts Collection Point - - - - - - - - - - - - - - - - - - - - - - - 135
Figure 103 MO Calls Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 136
Figure 104 MT Calls Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 137
Figure 105 Collection Points for Mobile Terminated Statistics - - - - - - - - - - - - - - - - - - 138
Figure 106 Mean Time Graph (Handoff Out) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 139

Figures 4
Figure 107 Mean Time Interval for Handoff Out - - - - - - - - - - - - - - - - - - - - - - - - - - - - 139

Figure 108 Mobile Lost Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 140
Figure 109 Pages Graph (BSC Facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 141
Figure 110 Collection Point for Paging Statistics - - - - - - - - - - - - - - - - - - - - - - - - - - - - 141
Figure 111 SMS Graph (BSC Facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 142
Figure 112 Collection Point for MO SMS on Signaling Channel - - - - - - - - - - - - - - - - - 143
Figure 113 Collection Point for Completed MO SMS on Signaling Channel - - - - - - - - 144
Figure 114 Collection Point for Completed MO SMS on Traffic Channel\ - - - - - - - - - - 144
Figure 115 Collection Point for MT SMS on Signaling Channel - - - - - - - - - - - - - - - - - 145
Figure 116 Collection Point for MT SMS on Traffic Channel - - - - - - - - - - - - - - - - - - - 145
Figure 117 Collection Point for Completed MT SMS on Signaling Channel - - - - - - - - - 145
Figure 118 Collection Point for Completed MT SMS on Traffic Channel - - - - - - - - - - - 146
Figure 119 Usage Graph - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 146
Figure 120 Mobile Originated Usage Counter Interval - - - - - - - - - - - - - - - - - - - - - - - 147
Figure 121 Mobile Terminated Usage Counter Interval - - - - - - - - - - - - - - - - - - - - - - - 148
Figure 122 Handoff In Usage Counter Interval - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 149
Figure 123 All Statistics Report (BSC Facing) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 150
Figure 124 MSC Subsystems - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 167

ABOUT THIS GUIDE
This guide describes how to operate and maintain a Sonata MSC Server. This
guide applies after the MSC Server has been installed, initially configured, and
provisioned with both site and subscriber data.
This guide is intended for network architects, designers, and operations and
support engineers responsible for the design, development, day-to-day
operations, and maintenance of the MSC Server within the Sonata product. Prior
experience with Star Solutions products is helpful but not required. The guide
assumes its readers have a thorough understanding of telecommunications and
Internet Protocol (IP) telephony. This guide also assumes its readers have
adequate knowledge of the existing network and system administrator privileges.
Prerequisite The Operations and Maintenance Center User Interface Guide and Core Voice
Network Operations, Maintenance, and Provisioning Guide should be read first
since they cover common procedures for all the Core Voice Network Elements
(NE). Refer to Related Documentation.
The About this Guide section includes:

Conventions
Related Documentation
Technical Support
Warranty Support
Contacting Technical Documentation
Release notes are issued with some products. If the information in the release
notes differs from the information in this guide, follow the instructions in the
release notes.
Conventions This guide may contain notices, figures, screen captures, and certain text
conventions.
Notices Table 1 lists notice icons used in this guide.
Table 1 Notice Icon Descriptions
Icon Notice Type Description

Information Note Information that contains important features or
instructions but is not hazard-related.

7 Chapter : About This Guide
Table 1 Notice Icon Descriptions (continued)
Icon Notice Type Description

Caution or Cautions are preceded with the word Caution. This
Warning type of caution indicates a potentially hazardous
situation which, if not avoided, may result in minor
or moderate injury. It may also alert against unsafe
practices and potential program, data, system, or
device damage.
Warnings are preceded with the word Warning. This
type of warning indicates a potentially hazardous
situation which, if not avoided, could result in death
or serious injury.
Caution or Cautions due to potential electrical hazards are
Warning due to preceded with the word Caution. This type of
potential caution indicates a potential electrical hazard. This
electrical hazard hazard, if not avoided, may result in minor or
moderate injury. It may also alert against unsafe
practices and potential program, data, system, or
device damage.
Warnings due to potential electrical hazards are
preceded with the word Warning. This type of
warning indicates a potential electrical hazard. This
hazard, if not avoided, could result in death or
serious injury.
ESD Information that indicates proper grounding
precautions are required before handling a product.
Figures and Screen Captures This guide provides figures and screen captures as examples. These examples
contain sample data. This data may vary from the actual data on an installed
system.
Text Table 2 lists text conventions in this guide.

Table 2 Text Convention Descriptions
Convention Description
Text represented as screen This typeface represents text that appears on a
display terminal screen, for example: login:.
Text represented as user This typeface represents commands entered by the
entry. user, for example, cd $HOME.
Text represented as menus, This typeface represents all menus, sub-menus, buttons,
sub-menus, buttons, tabs, tabs, directories, and field names within procedures, for
directories, and field names example:
On the File menu, click New.
Text represented by This typeface represents a required variable, for
<variable> example: <filename>
Related Documentation The documentation is divided into Core Voice Network documentation and
Access Network documentation.

Related Documentation 8
Core Voice Network Figure 1 maps the Core Voice Network documents and relationships between the
Documents documents. Refer to Figure 1 to determine the order in which to read the
documents.
For example, to operate and maintain the MSC Server, the document map
suggests reading the documents in the following order:
1 Core Voice Network Overview
2 Any relevant release notes
3 OMC User Interface Guide
4 Core Voice Network Operations, Maintenance, and Provisioning Guide
5 MSC Server Operations and Maintenance Guide (this guide)
The Core Voice Network Operations, Maintenance, and Provisioning Guide and
the OMC User Interface Guide contain common procedures and information for
all Core Voice Network nodes (except for the Call Conference Server and IMG),
and should be read prior to reading the node-specific guides. The other
node-specific guides are:
MSC Server Provisioning Guide, which contains the MSC-specific tables and
how to provision them.
MSC Server Operations and Maintenance Guide, which contains the
MSC-specific procedures for operating and maintaining the MSC Server, such
as procedures related to upper layer call processing protocols, Call Detail
Records (CDR), and MSC-specific alarms.
HLR and Authentication Center Guide, which contains all HLR-specific
provisioning, operations and maintenance procedures, and HLR-specific
alarms etc.
Signaling Server and Signaling Server Application Guide, which contains a
description of the Signaling Server Application and the various configurations
that accommodate the application. This guide contains SS7 operations and
maintenance procedures and SS7 alarm information, as well as Signaling
Server (SSVR) node-specific operations and maintenance procedures.
Access Server (MRF) Guide, which contains a description of the tones and
announcements available to the MSC, a description of the Media Resource
Function (MRF), and operations, maintenance, and provisioning procedures
specific to the Access Server.
Lawful Intercept Server Guide, which contains a description of the Lawful
Intercept Service, the components that are involved the service, and the
operations, maintenance, and provisioning specific to the Lawful Intecept
Server and Service.
Media / Signaling Gateway Server Operations, Maintenance, and Provisioning
Guide, which contains the specific procedures for operating and maintaining
the MGW / SGW.
The Call Conference Server Guide does not use the OMC or the common
operations and procedures that the other core nodes use. The Call Conference
Server Guide contains a description of the Call Conference Server, a description of
Sonata Core Voice Network Release 4.5.3 MSC ServerOperations and Maintenance Guide
the three-way call functionality, and operations, maintenance, and provisioning

procedures specific to the Call Conference Server.

Related Documentation 10
Figure 1 Core Voice Network Document Map
Technical Support The Star Solutions Product Support Team delivers the support services required
for business and professional needs. Our product experts deliver Tier 1, 2 and 3
technical support directly to new and contract-entitled customers including the
following services:
Basic Support Package: Non-emergency technical support
Premium Support Package: 24 hours a day, 7 days a week, and 365 days a year
Emergency technical support
The Star Solutions Service Guide outlines the specific details for obtaining
technical support. The guide is available from a sales account manager. Refer to
the Service Guide for services and options specific to individual support plans,
including guidelines for problem severity and the technical resolution escalation
process.
Obtaining Technical Star Solutions maintains a global presence through its Technical Response and
Assistance Service Centers. These centers are available for technical telephone support to
entitled customers during normal business hours.
Before contacting technical support, have this information available:

Product information
Software and hardware revisions
Serial numbers
Problem description
Symptoms
Known causes
Trouble locating and clearing attempts.
For information about customer service, including support, training, code

releases and updates, contracts, and documentation, contact us at:
http://www.starsolutions.com/support
Service Centers Operational Hours

North America/CALA Region:
09:0018:00 Pacific Time (UTC-8:00)
EMEA/Asia Pacific Region:

09:3018:30 Indian Standard Time (UTC+5:30)
Warranty Support Star Solutions provides its customers warranty support per the terms of the Star
Solutions Warranty Statement for their equipment. Customers who require
warranty support should contact the Star Solutions Customer Service Center as
specified in the customer service guide or at:
http://www.starsolutions.com/service-support

Contacting Technical Documentation 12
Contacting Technical To provide comments on this documentation, send an e-mail to:

Documentation dl-techcom@starsolutions.com
Please include the name and part number of the guide being referenced. If
applicable, provide the chapter and page number.
OVERVIEW
I
Chapter 1 Overview
OVERVIEW
1
This chapter describes the MSC server within the Sonata product and its
functionality.
This chapter includes:

MSC Server Overview
MSC Server Overview The MSC Server is part of the Core Network in the Star Solutions Sonata.
Sonata System Architecture The high-level architecture of the Sonata system is shown in Figure 2. The
features and functionality of the Sonata system are not discussed further in this
guide. Refer to the Core Voice Network Overview for more information about the
Star Solutions Sonata.
Figure 2 Sonata Release 4.5.3 System Architecture
CDMAAir PrivateIPNetwork Telco
MSC/VLR* OMC/FS HLR
SSVR NarrowbandSS7
ISUPTrunks
PRI
LIS* AS* CCS E1/R2
SGW SS7
BTS BSC MGW PSTN
OM C OperationsandM aintenanceCenter MSC M obileSwitchingCenter HLR Hom eLocationRegister

LIS Lawful Intercept Server VLR Visitor LocationRegister SGW SignalingGateway
BTS BaseTransceiver Station AS AccessServer MGW M ediaGateway
BSC BaseStationController CCS Call ConferencingServer Media- or Call-Control Signaling
Anasterisk(*) indicatesthat thenetworkelement ismanagedbytheOM C MediaStream ing
Core Voice Network Elements The Sonata Core Voice Network contains the following network elements:
Mobile Switching Center (MSC)
Home Location Register (HLR) and Authentication Center (AC)
Signaling Server (SSVR)
Access Server / MRF
Lawful intercept Server (LIS)
Call Conference Server (CCS)
Intelligent Media Gateway (IMG)

17 Chapter 1: Overview
The Operations and Maintenance Center (OMC) is used for element and
subnetwork management of the Core Network.
Network Element Interactions Refer to the MSC Server Provisioning Guide for information on intereractions
between the Core Voice Network Elements (NE). This guide also covers how to
provision the interactions between the NEs.
MSC and SSVR Configurations Refer to the Signaling Server Application Guide for information on the various
MSC and SSVR configurations.
MSC Server The Mobile Switching Center Server (MSC Server) incorporates traditional MSC
functionality, as well as next-generation softswitch functionality.
A Softswitch is software that decomposes call logic from a traditional

central-office type of switch and directs the switching activities of Media
Gateways. The Media Gateways do not have to be co-located with the Softswitch.
The only communication between them is signaling to set up a call and/or a
calling feature, which is a low-bandwidth communication. The Softswitch may set
up the path but the Media Gateway controls the flow of the medium (either voice
or data) over the path.
In this model, while call control and routing are the primary objectives, protocols
exist to enable a number of different devices to cooperate, especially Media
Gateways, and a way to create complex call features and applications on top of
basic call control. These applications can be called a feature server. The Sonata
Home Location Register is a feature server.
The MSC Server System is independent of the transmission backbone and

separates call control and signaling (control plane) and traffic (user plane) into
separate network elements. The MSC Server handles call control and signaling,
while the Media Gateway takes care of switching and carries the actual traffic.
This division allows a totally new style of structure for the core network. Call
control can be amalgamated into very large centers, while the actual voice traffic
flow can be optimized by locating the Media Gateways close to traffic hot spots
and the interconnection points closer to other networks.
Media Gateways can be deployed within networks where PSTN connections are
required instead of being centralized, as MSCs are today. Backhaul costs are
reduced as well as using more efficient packet-based transport for voice bearer
traffic. Deploying the MSC Server centrally reduces the costs of operating and
maintaining an MSC, a primary reason for centralized MSCs in legacy networks.
The MSC Server provides the call control function of the legacy MSC and the
Media Gateway provides the user traffic switching functions. The MSC Server
contains all of the control software of the MSC, including the call translators, call
state machine, billing generation and storage, call features, etc. The Media
Gateway is basically the switching portion of the MSC.
OPERATIONS, ADMINISTRATION AND
II MAINTENANCE
Chapter 2 Operations, Administration, and Maintenance Overview
Chapter 3 User Accounts and Filesystems
Chapter 4 Configuring Call Detail Records
Chapter 5 Viewing and Managing Call Detail Records
Chapter 6 Performance Management
Chapter 7 Alarm Management
Chapter 8 Trouble Locating and Clearing

OPERATIONS, ADMINISTRATION, AND
2 MAINTENANCE OVERVIEW
This Chapter describes the MSC operations, administration and maintenance.

This is for the use of the Operator and/or Administrator.

Operating Tasks
MSC Operator Tasks
Administrator and Maintenance Tasks
Prerequisite The operator and administrator must have read the Core Voice Network
Operations, Maintenance, and Provisioning Guide.
MSC Operations, This chapter includes an overview of the basic operating, administration, and
Administration and maintenance tasks.
Maintenance
MSC-specific operations topics are covered in:
Chapter 3, User Accounts and Filesystems
Chapter 4, Configuring Call Detail Records
Chapter 6, Performance Management
MSC-specific maintenance topics are covered in:

Chapter 7, Alarm Management
Chapter 8, Trouble Locating and Clearing
Operating Tasks Task and Shift Overview

The flowchart in Figure 3 shows the tasks that an MSC Operator should perform
on each shift. The tasks common across all Core Voice Network Elements are
covered in the Core Voice Network Operations, Maintenance, and Provisioning
Guide. The MSC-specific tasks are covered in this chapter.
The common tasks are:

Monitor Alarms
Check CPU Utilization
Check Memory Utilization
Check Disk Space
Check Log Usage
Check Performance Statistics

21 Chapter 2: Operations, Administration, and Maintenance Overview
Figure 3 Operator Task Flowchart
Shift Documentation
Check CDR Usage
and Handover
Check Subscriber
Monitor Alarms Numbers
Check CPU Utilization Check Trunk Status
Check Memory Check MGCP Link

Utilization Status
Check SCCP-Lite Link

Check Disk Space Status
Check Log Usage Make Test Calls
Check Performance Shift Documentation

Statistics and Handover
D00506-122.gif
Recording Faults
The Operator should maintain a shift record of all faults reported by the system.
The Operator should inform Network Operating Center (NOC) personnel of the
faults reported during the shift. The shift record should include information as
follows:
date and time a fault was reported or actually occurred
the nature of the reported fault
the reported location
the location of the fault, when found
the actual fault condition found and the corrective action taken
MSC Operator Tasks 22
MSC Operator Tasks This section describes the tasks that operators typically perform during each
shift.
The common procedures are described in the Core Voice Network Operations,
Maintenance, and Provisioning Guide. There is a brief procedure included in this
chapter for each MSC-specific task, which should be all the Operator needs to
know. There are referrals to subsequent chapters for more in-depth information.
Table 3 provides a table to use as a operator's shift checklist. Copy this table, or
create one to use as a shift checklist for operators.
Table 3 Operator Shift Checklist
Step Task Done Record / Comment

1 New Shift Handover
2 Monitor Alarms Previous Unresolved Active Alarms:
Refer to the Core Voice
Network OAMP Guide New Active Alarms:
3 Check CPU Utilization

Network OAMP Guide
4 Check Memory
Utilization
Network OAMP Guide
5 Check Disk Space Capacity root slice (%):
Refer to the Core Voice Capacity application slice (%):
Network OAMP Guide
6 Check Log Usage
Network OAMP Guide
8 Check Performance
Statistics
Network OAMP Guide
13 Check CDR Usage
14 Check Subscriber
Numbers
15 Check Trunk Status
16 Check MGCP Link Status
17 Check SCCP-Lite Link
Status
18 Make Test Calls
19 End of Shift

New Shift Handover Collect and review the shift documentation from the previous shift Operator, and
also do the following:
Review previous shift documentation with the supervisor.
Get familiar with any known or active issue in the network.
Get familiar with any configuration changes or additions to the network.
Monitor any active alarms.
Review any other shift log information.
Prepare new Operator Shift Checklist for current shift.
Prerequisite An msc user session should already be established. Refer to the User Accounts
chapter of the Core Voice Network Operations, Maintenance, and Provisioning
Guide for how to connect to, and log in to the MSC.
Check CDR Usage Check that CDRs are being generated.
To Check CDR Usage:

1 List CDR files.
See Listing CDR Files on page 54.
2 Confirm that CDR files exist, and are not empty.
3 Check CDR generation
See Verifying CDR Generation on page 59.
4 Confirm that a random CDR files is correctly generated.
5 Check CDR disk space usage.
See Checking Available Disk Space for CDRs on page 63.
6 Confirm that CDR space limits are not exceeded.
7 Record the result of this activity in the Operator Shift Checklist.
To Generate a Trunk Group Summary Report:

1 Generate a Trunk Group Summary Report.
See Trunk Group Statistics on page 110 for more information on this report.
To Generate a Trunk Group Detail Report:

1 Generate a Trunk Group Detail report.
See Trunk Group Detail Report on page 112 for more information on this report.
Check Subscriber Numbers Check the number of subscribers in the VLR.
To Check Subscriber Numbers:

1 Run the RTD diagnostic tool and use grep to search for subscriber numbers.
msc > rtd_dump -k | grep VLR_SUB_KEY_TABLE
The VLR_SUB_KEY_TABLE is displayed. The first column shows the number of
current subscribers in the VLR database. The second column shows the peak
MSC Operator Tasks 24
number of subscribers attained in the VLR database since the last restart of the
MSC.
Refer to the Trouble Locating and Clearing chapter of the Core Voice Network
Operations, Maintenance, and Provisioning Guide for information on the RTD
subsystem diagnostic tool.

Record the number of current subscribers and the number of peak subscribers.
See Example: Check Subscriber Numbers
Example: Check Subscriber Numbers

msc > rtd_dump -k | grep VLR_SUB_KEY_TABLE
VLR_SUB_KEY_TABLE 5 5 0 0
Check Trunk Status Check the trunk (port) status at the software level and at the hardware level. The
trunks should be INSERVICE and all hardware for MGCP endpoints should be INS.
To Check Trunk Status:

1 Check the service state of all trunks.
msc > vsm_dump
2 Confirm that all ports have Service State of INSERVICE.
See Example: Check Trunk Service State.
3 Check the service state of all MGCP endpoints.
msc > meg_res_dump -C
4 Confirm that all MGCP endpoints have state INS.
See Example: Check MGCP Endpoint Service State.
Record any ports that are not INSERVICE.
Record any MGCP endpoints that are not INS.
Example: Check Trunk Service State

msc > vsm_dump
Port CP State Service State Media State Ans Feat Group

====== =============== ============= =========== === ==== =====
1000 NULL INSERVICE INS 0 0 11
...

Example: Check MGCP Endpoint Service State

msc > meg_res_dump -C
MEG MGCP RESOURCE TABLE
res_id port gwid call_id state term cp_state

====== ===== ==== ======= ===== ========================== ========
1 1000 1 0 INS ds/tr0/2@mgw1 IDLE
...
31 2000 2 0 INS 1@172.25.143.157 IDLE
*** Total number of MGCP resource is 31 ***
Check MGCP Link Status Check the status of all MGCP links. MGCP links connect the MSC to all Media
Gateways, including all attached BSC.
To Check MGCP Link Status:

1 Check the status of all MGCP links.
msc > meg_dump -l
2 Confirm that the SVC_STATE for all gateways shows INS.
Record the name and ID of any gateway that has SVC_STATE as OOS (out of
service).
See Example: Check MGCP Link Status.
Example: Check MGCP Link Status

msc > meg_dump -l
ID GATEWAY_NAME SVC_STATE AUDIT_REPLIED GATEWAY_SYNCED AUD_TID

== ========================= ========= ============= ============== =======
1 mgw1 INS 1 1 3939
2 bsc1 INS 1 1 3940
Check SCCP-Lite Link Status Check the status of all SCCP-Lite links.
To Check SCCP-Lite Link Status:

1 Check the status of all SCCP-Lite links.
msc > csi_dump -Z | grep default
2 Confirm that the SSN for all BSC show inservice=TRUE.
See Example: Check SCCP-Lite Link Status.
Administrator and Maintenance Tasks 26

Record any BSC ID that show SSN inservice=FALSE.
Example: Check SCCP-Lite Link Status

msc > csi_dump -Z | grep default
(1) BSC=1 default_lac=1 SSN inservice=TRUE IN SYNC with BSC
(2) BSC=2 default_lac=2 SSN inservice=TRUE IN SYNC with BSC
(3) BSC=3 default_lac=3 SSN inservice=FALSE
(4) BSC=4 default_lac=4 SSN inservice=FALSE
Make Test Calls Make test calls from the test call list. The test call list is both site-specific and
customer-specific, but could include calls like emergency calls (911), local and
long distance calls, and more. The test call list should list all of the types of test
calls to be performed on each trunk group.
Making Test Calls

The purpose of test calls is to generate test data (e.g., frame error rate (FER),
forward and reverse link capacity estimates, etc.) for performance analysis. These
calls may not require any trunks (DS0 circuits). A test call can be initiated by the
mobile station or the MSC.
Record any failed test calls, with any supporting information.
End of Shift Prepare the shift documentation for the next shift Operator. In particular:
Make note of any known or active issue in the network.
Make note of any configuration or network change during the shift.
Ensure the Operator Shift Checklist is completed.
Administrator and The administrator's tasks are mainly tasks that are common across all Core Voice
Maintenance Tasks Network Elements. These are:
Monitoring Logs, Alarms, and Events
Displaying the HLR Application Status
Starting and Stopping the HLR Application
Stopping the Operating System
Rebooting the HLR
Trouble Locating and Clearing
System Time Maintenance
Hardware Maintenance
Database and System Backup and Restore

Refer to the Core Voice Network Operations, Maintenance, and Provisioning

Guide for the common administration and maintenance procedures.
USER ACCOUNTS AND F ILESYSTEMS
3
This chapter describes the MSC user accounts and the associated filesystem.

MSC User Accounts
MSC User Accounts The MSC application sits on top of the operating system, and uses the services
that the operating system provides.
The msc account is used to manage the MSC and has a home directory. When
logging in to the MSC as msc user, the home directory is represented by the ~.
The msc home directory maps to an actual path in the UNIX filesystem
(/telos/msc). When working in the MSC filesystem, all paths to working
directories are relative to the msc home directory (~).
User accounts are set up on the MSC during initial installation. These accounts
are set up with specific environments to provide user access to system tools. The
accounts are also used by internal MSC processes to perform automatic and
ongoing activities on the MSC.
Changing account names, or deleting accounts on the MSC will severely impact
the operation of the MSC. Passwords for the root and msc accounts can be
changed (refer to the Core Voice Network Operations, Maintenance, and
Provisioning Guide).
The following user accounts are supported on the MSC:

root: used for system administration, such as backup, reboot, and power off
commands.
msc: the msc account is used for maintaining all MSC applications.
pro: This account exists on the MSC if the Signaling Server application is
running on the MSC. If the Signaling Server application is running on the MSC,
then it may run under the pro or msc account. Refer to the Signaling Server
Application Guide for more information.
drum: used for maintaining data accessed by the OMC. DRUM is the OMC
proxy that runs on the MSC and is used by the OMC to send and receive
management data, including operating system and application performance
files.

29 Chapter 3: User Accounts and Filesystems
Refer to the Core Voice Network Operations, Maintenance, and Provisioning

Guide for more information on:
User accounts
UNIX and application filesystems
Connecting to the MSC
Logging in and out
Changing User Passwords
MSC Application Account The msc account is used for management of the MSC application. Both the
Operator and the System Administrator can use the msc account, but only the
System Administrator should use the root account.
A single account is used to manage the MSC application, therefore Operators

using the msc account should restrict their management activities to the general
task areas outlined for Operators. However, there is no way to prevent a user of
the msc account from performing all activities permitted by the msc account
privileges.
Table 4 lists the general tasks areas and roles for msc account users.
Table 4 MSC Account and Task Mapping
Account Role General Task Area

msc Operator General Operator tasks.
msc Operator Fault Management activities.
msc Operator Some software upgrades, mostly at Emergency
System Administrator Patch level.
msc Operator Executing CLI commands.
System Administrator
msc System Administrator Backup and restore database.
msc System Administrator Configuration Management activities.
Table 5 lists the default msc account logon details.
Table 5 MSC Account Default Logon Details

Parameter Default Value
msc Account msc
msc Password ms c
CONFIGURING CALL DETAIL RECORDS
4
This chapter explains how the Sonata MSC generates and processes Call Detail
Records (CDRs) and how to configure CDR generation and processing. Chapter 5,
Viewing and Managing Call Detail Records describes how to view and manage
CDRs.

Call Detail Records Overview
Call Detail Record Handling
CDR Collection Process
CDR File Storage
Configuring CDR Generation at the MSC
Configuring CDR Retrieval at the OMC
Configuring CDR Files for a Billing Server
Call Detail Records What are Call Detail Records

Overview A Call Detail Record (CDR) is a set of information that records the details of a call.
Each voice call that uses system resources produces one or more records
describing events that occurred during the life of a call.
There are two main call detail formats used in voice networks:
Billing AMA Format (BAF)
The generic requirements of BAF for all services are set forth in GR-
1100-CORE, Billing Automatic Message Accounting Format (BAF)
Requirements. The switching system generic requirements for generating
AMA are described in GR-508-CORE, Automatic Message Accounting.
Call Detail Record (CDR)
The ITU-T Recommendation Q.825 specifies how CDRs are produced and
managed in Network Element, including the MSC. Standardization of CDR
formats allows inter-operability between the Network Elements that create
and process CDRs, and between telecommunications equipment suppliers.
The MSC uses the CDR (ITU-T Q.825) format to record call details.
A CDR is generated on the MSC in binary format and collected on the OMC from
which a billing server pulls the CDR files.
Call detail records can be generated in real time (single CDRs), near real-time
(blocks of CDRs), or as batch files of CDRs.
A CDR is generated for voice calls and SMS calls only.

31 Chapter 4: Configuring Call Detail Records
CDRs record the use of system resources for voice and SMS calls. Accounting for
data calls is handled by Network Elements in the packet switched network. The
sections that follow describe how CDRs are handled in the circuit-switched
networks.
Call Detail Record Handling CDRs provide information about each call the MSC handles. Providers can gather
CDRs for use in customer billing, performance analysis, and troubleshooting.
CDRs typically include:

Call type and features
Originating and terminating party identification
Digits dialed
Cell site and land facilities involved
MSC identification
Time and date the call was started, answered, and terminated
Disconnect code that indicates whether the call was completed and, if not,
gives a reason
The MSC creates at least one CDR for each voice or SMS call that uses system
resources. The MSC records call details as soon as system resources are used, but
a CDR is generated only when the resources are released, typically when a call is
terminated.
Records for data calls are created by Authentication, Authorization and

Accounting (AAA) servers in the data network. CDRs do not provide information
on data calls.
The OMC periodically retrieves CDR files from the MSC. Configure the OMC
either to upload the files periodically to a billing server or to make the files
available for download by a billing server.
CDR Format The Sonata MSC uses the CDR format described in ITU-T Q.825 to record call
details. The operator can generate CDRs on the MSC in binary format, export
them to XML format or view them in ASCII format.
CDR Collection Process The Sonata system can either send CDR files to a billing server (the push model)
or offer the files for a billing server to download (the pull model). In both cases,
the MSC generates the CDR files, and OMC retrieves them from the MSC. The
process is summarized in Figure 4.
CDR Collection Process 32
Figure 4 CDR Collection Process
Send Receive Push model
Generate Retrieve
Offer Retrieve Pull model
MSC OMC Billing Server

Generating CDRs (at the MSC) At the end of each call, the MSC writes one or more CDRs to its working memory.
Each record has a fixed length of 512 bytes.
When the timer cdr-config: t_log_flush expires, or when the cache is full at
100 records, the MSC appends the records to a CDR file in the ~/DATA directory
on its hard disk.
The MSC continues appending records to the CDR file until the timer
cdr-config: t_file expires, when the MSC closes the file and opens a new
one, incrementing a number in the file name.
When the number of CDR files in the ~/DATA directory reaches the value in
cdr-config: num_files, the newest CDR file overwrites the old one.
Retrieving CDR Files (from the The OMC initiates retrieval of new, closed CDR files when a cron job is run (by
MSC by the OMC) default, every five minutes). The cron job that runs acc_trans_sub causes the
OMC to download the CDR files according to settings in the OMC's
~/CONF/trans.conf file.
The trans.conf file indicates:

Whether to store teh last transferred CDR filename locally or via an LDAP
server (for high-availability OMC configurations)
How the CDR files are to be renamed
Whether to convert the CDR files, which are transferred in binary format, to
XML format
Additional configuration for pushing CDR files to a billing server
CDR files are stored on the OMC in ~/DATA/CDR/transferred.
Providing CDR Files (to the The OMC is responsible for providing CDR files to a billing server. The OMC can
Billing Server by the OMC) either send the CDR files to the billing server (the push model) or offer the CDR
files for the billing server to download (the pull model).
Pull Model
In the pull model, the OMC makes the CDR files available to a billing server. The
billing server needs to be configured to pull the CDR files from the OMC.
Push Model
In the push model, the OMC initiates the upload of CDR files when a cron job is
run. The cron job that runs acc_trans_oss_sub causes the OMC to upload the
CDR files according to settings in the OMC's ~/CONF/trans.conf file.

The trans.conf file indicates:

FTP details, including the billing server's hostname or IP address and login
Whether to compress the CDR files using gzip before uploading them
How long to retain the pushed CDR files
Additional configuration for retrieving CDR files from the MSC
The billing server must be running an FTP server and be on a reachable subnet.
CDR File Storage The MSC has two hard disks that are mirrored and synchronized. CDR files write
to both disks. A failure of a single disk on the MSC will not result in CDR data loss.
The OMC also has two hard disks that are mirrored and synchronized.
CDR Generation in HA In a high-availability (HA) configuration, the MSC is deployed as a redundant pair.
Configuration If the active MSC fails, the standby MSC takes over call processing and CDR
generation.
The basic CDR-generation concept does not change in an HA configuration: The

active MSC processes calls and generates CDRs. The OMC retrieves the CDR files
and provides them to the billing server.
The OMC pulls CDR files from both the active and standby MSC according to a
cron job. The CDR for a call, however, is generated only at the active MSC (the
one processing the calls).
The active and standby MSC both run the cdr_transfer process, which
establishes a connection between them. The active MSC continually sends CDR
sequence and file-sequence information to the standby MSC. This information is
used to establish the correct sequencing of CDRs if the active MSC fails. This
synchronization ensures that no call data written to disk is lost.
During failover, all calls in progress at the failed MSC are dropped. The CDRs for
the dropped calls are flushed to disk, and each record is given the disconnect
code FORCED_DISCONNECT. The new active MSC begins processing calls and
generating CDRs that immediately follow the last sequence on the failed MSC.
Synchronization does not apply to CDR records still in memory. CDRs are written
to disk when the t_log_flush timer expires, or when the cache is full.
Depending on traffic levels and CDR configuration, some CDRs may be lost.
CDR Storage Capacity at the An MSC is typically dimensioned with disk partitions that allocate more than 50%
MSC of the disk to CDR files and trace log files. Available space for CDRs at any given
time is dependent on trace log activity (see Traffic and Capacity Estimates for
further information on space requirements for CDR files).
Do not fill up a disk - the OS runs best when at least 20% of the disk is free.
Figure 5 shows the percentage breakdown of MSC disk allocation.
CDR File Storage 34
Figure 5 MSC Disk Allocation
Table 6 lists the partition breakdown for a 73 GB MSC disk.
Table 6 73 GB MSC Disk Allocations
Size Percentage Content

15 GB 15 Other (including OS)
23 GB 32 MSC application
35 GB 53 CDR files and Trace log files
Traffic and Capacity Estimates

Table 7 shows the estimates for the CDR space requirements for given busy-hour
call attempts (BHCA).
Table 7 BHCA CDR Estimates
BHCA CDR per Call CDR File Size Total Size

360 000 1.5 512 bytes 218 MB
A typical day (24 hours) could generate the equivalent of 10 busy hours.
Therefore, a typical day could require 2.18 GB of (218 MB * 10 BHCA) space for
CDR files. Assuming use of the full 35 GB partition (no Trace log files), the MSC
has sufficient disk space for 16 days (35 GB / 2.18 GB per day).
Warning:
Trace log files can be large, and may significantly reduce the amount of space
available for CDR files.
CDR Storage Capacity at the The OMC is typically dimensioned with disk partitions that allocate more than
OMC two-thirds of the disk to OMC applications, alarm data, CDR files, and statistical
data.
Figure 6 shows the breakdown of the OMC disk allocation in percentage.

Figure 6 OMC Disk Allocations
Table 8 lists the partition breakdown for a 73 GB OMC disk.
Table 8 73 GB OMC Disk Allocations
Size Percentage Content

23 GB 32 Other
50 GB 68 OMC applications, alarm data, CDR files, statistical
data
The OMC stores Performance Management, Fault Management, and Accounting

Management files on the same partition (50 GB). With normal traffic patterns,
the OMC can store approximately 7 days worth of CDR files, about 15 GB (7 days
* 2.18 GB).
Configuring CDR This section describes how to configure the MSC's CDR handing, which includes
Generation at the MSC configuring the CDR flush timer, the CDR file generation timer, CDR file naming,
and the maximum number of CDR files on the MSC disk.
Configuring the CDR Flush Generated CDRs are kept in memory until written to disk. The cdr-config:
Timer t_log_flush timer specifies the period (in seconds) that CDRs remain in
memory before being written to disk.
CDRs are also written to disk when the cache is full. The CDR cache holds 100
records, and this is not configurable.
t_log_flush has a range of 130 seconds, with a default of 10 seconds.
Change the default timer value only if the cache routinely dumps before the timer
expires.
Configuring CDR Generation at the MSC 36
To Configure the CDR Flush Timer:

This configuration change takes effect only after the MSC resets.
1 Query cdr-config to determine primary key value and the current value for
t_log_flush.
CLI > query cdr-config %
2 Change the current timer value with the new value.
CLI > change cdr-config t_log_flush = 30
t_log_flush? [30] 20
3 Verify the table.
CLI > verify cdr-config
4 Report on the change.
CLI > report cdr-config %
See Figure 7 for a sample of how to change t_log_flush from 30 seconds

(default) to 20 seconds.
Figure 7 Example: Using CLI to Change t_log_flush
CLI> query cdr-config %
Field Value Description
----- ----- -----------
t_log_flush 30 Flush cached CDRs to disk (sec)
...
b_cell_id 1 Record terminating cell id
CLI>
CLI> change cdr-config t_log_flush = 30
t_log_flush? [30] 20
...
b_cell_id? [1]
Total number of records changed: 1
CLI> verify cdr-config

Number of invalid entries: 0
CLI>
CLI> report cdr-config %

----- ----- -----------
...
1 entries found at 10:22:10 on 2005/07/22
Line 1/16(END) Press h for help, q to quit
Configuring the CDR File A CDR file is generated from the collected CDRs that are written to disk. CDRs still
Generation Timer in memory are not in the CDR files. The cdr-config: t_file timer specifies the
period (in minutes) after which the MSC closes the old CDR file and opens a new
one.
The OMC retrieves CDR files from the MSC at a default interval of 5 minutes. The
frequency is configured in the OMC's crontab (see Configuration Settings in
~/CONF/trans.conf). Generating a CDR file more frequently than the OMC's
retrieval period will consume resources and provide no benefit.

Table 9 lists the parameter values for t_file.
Table 9 t_file Timer Parameters
Value Period (Minutes) Period (Hours)

5 5 minutes
10 10 minutes
15 15 minutes 0.25 hours
720 720 minutes 12 hours
1440 1440 minutes 24 hours
To Configure the CDR File Generation Timer:

This configuration change takes effect only after the MSC resets.
1 Query cdr-config to determine the primary key value and the current value for
t_file.
2 Change the current timer value with the new value.
CLI > change cdr-config t_file = 720
t_log_flush? [10]
t_xn_flush? [10]
t_poll_send? [15]
t_file? [1440] 720
3 Verify the table.
See Figure 8 for a sample of how to change the value of the t_file timer from
1440 seconds to 720 seconds.
Figure 8 Example: Using CLI to Change t_file
----- ----- -----------
...
t_file 1440 new CDR file generated interval (min)
...
CLI> change cdr-config t_log_flush=10

t_log_flush? [10]
...
t_file? [1440] 720
...
b_cell_id? [0]
----- ----- -----------
...
t_file 720 new CDR file generated interval (min)
...
Configuring CDR File Naming CDR files on the MSC are named CDRxxxxxxyyyyyy, where xxxxxx is a unique
6-digit MSCID as configured at initial configuration stage in the mscid field in the
cdr-msc table in hexadecimal format. yyyyyy is an MSC-generated 6-digit
sequence number starting from 000001 and rolling back to 000001 after reaching
99999. This number increments when a new file is written to disk.
To change an MSCID of an existing MSC, or to provision a new MSC with CDR

details use the following procedure.
To Configure the MSCID for CDR File Naming:

Warning:
The MSC resets in the following procedure.
1 Query cdr-msc to determine the current MSCID.

CLI > query cdr-msc all
2 Change the current MSCID with the new MSCID.
CLI > change cdr-msc <rest of command here>
3 Verify the change is valid.
CLI > verify cdr-msc

See Figure 9 for a sample output.

Figure 9 Example: Using CLI to Change MSCID
CLI > query cdr-msc all
MSC ID IPC Name
--------- ------------------------
3078 local
CLI > change cdr-msc
SEARCH{mscid[key:PU] ipc_host_name[key:U] cancel exit}
UPDATE{mscid ipc_host_name cancel exit}
CLI > change cdr-msc
CLI > verify cdr-msc
CLI >
Configuring the Maximum CDR files are written to the MSC disk. All the closed CDR files on disk at the time
Number of CDR Files on MSC of OMC retrieval are transferred to the OMC.
Disk
Table 10 lists the parameter values for num_files.
Table 10 num_files Parameters

Value Number of Files
1 1
24 24
48 48
96 96
144 144
To Configure the Maximum CDR Files on the MSC Disk:

num_file.
2 Change the current value with the new value.
CLI > change cdr-config t_log_flush=10
t_log_flush? [10]
num_files [96] 144
t_xn_flush? [10]
t_poll_send? [15]
t_file? [1440] 720
3 Verify the table.
See Figure 10 for a sample of how to change the value of num_files from 96 to
144.
Figure 10 Example: Using CLI to Change num_files
----- ----- -----------
...
num_files 96 max files number kept
...
CLI> change cdr-config t_log_flush=10

t_log_flush? [10]
...
num_files? [96] 144
...
b_cell_id? [0]
----- ----- -----------
...
t_file 720 CDR file generated interval (min)
num_files 144 new max files number kept
...
Configuring the CDR Version CDR files can be generated and stored as different versions, for example, version
8 or version 11.
To Configure the CDR Version:

out_version:
2 Change the current value for the new value.
CLI > change cdr-config b_cell_id=1
b_cell_id? [1]
out_version? [8] 11
3 Verify the table.

See Figure 11 for a sample of how to change the value of num_files from 96 to
144.
Figure 11 Example: Using CLI to Change out_version
----- ----- -----------
...
out_version 8 Define cdr version to output file <-----
CLI> change cdr-config b_cell_id=0

...
b_cell_id? [1]
out_version [8] 11
----- ----- -----------
...
out_version 8 Define cdr version to output file <-----
Configuring CDR Retrieval This section explains how to control the way the OMC retrieves CDR files from
at the OMC MSCs and saves them to disk. Pushing CDRs to a third-party billing system is
covered in Configuring the OMC for the Push Model.
The OMC's crontab file controls two CDR-related activities:

Retrieving CDR files from MSCs and saving them to disk
Pushing CDR files to a third-party billing system.
crontab The instruction to retrieve CDR files from MSCs is configured in the OMC's
crontab file. The cron job acc_trans_sub controls CDR retrieval and is inserted
into the crontab file by default during initial installation. The configuration file
for acc_trans_sub is ~/CONF/trans.conf.
trans.conf is the configuration file for acc_trans_sub, acc_trans_oss_sub,

per_trans_sub, and sara_trans_sub.
The frequency to run acc_trans_sub (in other words, the frequency to

download CDR files from the MSCs) is indicated by a comma-delimited string of
digits at the start of its crontab entry. By default, acc_trans_sub runs every five
minutes, starting at one minute past the hour.
Figure 12 Example: acc_trans_sub Entry in crontab

1,6,11,16,21,26,31,36,41,46,51,56 * * * * [ -x
$HOME/TOOL/acc_trans_sub ] && $HOME/TOOL/acc_trans_sub >
/tmp/acc_trans.log 2>&1
Configuring CDR Retrieval at the OMC 42
Change the OMC retrieval frequency only if the default settings are not suitable.
To Verify, Add, or Change CDR Transfer cron Job:

1 Log on to the OMC.
> telnet <hostname>
2 List the cron jobs in crontab.
omc > crontab -l
3 Verify visually that the CDR transfer cron job exists and with the required
settings.
4 Take no action if the job exists with the required settings.
5 If the job does not exist, open the file for editing and add the job. If settings are
not correct, change the settings.
omc > crontab -e
6 Save and close the file.
Configuration Settings in Whenever acc_trans_sub runs, it reads configuration settings from

~/CONF/trans.conf ~/CONF/trans.conf. From trans.conf it learns:
Whether to get the IP addresses/hostnames for the MSCs from an LDAP
server (already running on the OMC) or from the trans.conf file itself
The user account information necessary to log on to the MSCs
Whether to convert the CDR files (which always arrive in binary format) to
XML format
Whether and how to rename the CDR files
The OMC directory to put the retrieved CDR files in
Each of these is explained in detail in the following sections.
Configuring LDAP or Local Mode

LDAP server is running on a majority of deployments. Use LDAP mode for MSC
identification unless directed otherwise.
In LDAP mode,
acc_trans_sub gets the hostnames of the MSCs from which to retrieve CDR files
from the LDAP server that runs on the OMC. The trans.conf file provides the
information necessary to contact and enter the LDAP server. Make sure
local_mode => false when using LDAP Mode.
Figure 13 Example: trans.conf Settings for LDAP Mode
ldap_hostname => localhost
ldap_port => 6699
ldap_user => Directory Manager
ldap_passwd => directory
ldap_base => dc=teloseng,dc=com
local_mode => false
These lines are exactly as they should be in trans.conf.

In Local Mode,
the IP addresses or hostnames of the MSCs are in the trans.conf file in lines
that start with NE =>. Local Mode is enabled by the trans.conf setting
local_mode => true.
Figure 14 Example: trans.conf Settings for Local Mode
Example: trans.conf Settings for Local Mode
local_mode => true
NE => 192.168.0.101
NE => 192.168.128.101
NE => 192.168.254.101
The NEs are examples of MSC addresses.
Configuring MSC User Account Information

The trans.conf line Acc_user_account indicates the type of account,
username, password, and directory where the CDR files are to be found. Spaces
are significant.
Figure 15 Example: trans.conf Settings for MSC User Account Information
Example: trans.conf Setting for MSC User Account Information
Acc_user_account => MSC,msc,ms c,~/DATA
This line is exactly as it should be in trans.conf.
Configuring CDR File Format

CDR files are generated in binary format at the MSC and also transferred to the
OMC in binary format. Leave the CDR files in binary format or convert them to
XML.
keep_as_binary => true leaves the CDR files in binary format.

Figure 16 Example: trans.conf Setting to Save CDR Files in Binary Format
Example: trans.conf Setting to Save CDR Files in Binary Format
keep_as_binary => true
keep_as_binary => false converts the CDR files to XML format.

Figure 17 Example: trans.conf Setting to Save CDR Files in XML Format
Example: trans.conf Setting to Save CDR Files in XML Format
keep_as_binary => false
Files successfully retrieved and, optionally, converted to XML format are saved in
~/DATA/CDR/transferred. Files that fail XML conversion are saved in
~/DATA/CDR/error.
Configuring File Renaming trans.conf provides two ways of changing a CDR filename before saving the
file: replacing the MSCID with text and adding a suffix.
Remember that the filenames on the MSC follow the format CDRxxxxxxyyyyyy,
where xxxxxx is the MSCID from the cdr-msc table and yyyyyy is the sequence
number. When the OMC retrieves and writes the CDR files, by default, it extracts
the MSCID from the old filename and renames the new file with the MSCID
followed by the current date and time in UTC.
The trans.conf file configures the way that the files are renamed, shown in the
following examples.
Replace the MSCID with an alphanumeric string of up to six characters by typing

the MSCID followed by the MSC name string.
Figure 18 Example: trans.conf Setting to Replace MSCID in CDR File Names
0a0b01 => mscOne
Result
CDR0a0b01001009 is saved as mscOne20061004204249.
Add a suffix to the new filename:

Figure 19 Example: trans.conf Setting to Add a Suffix to CDR File Names
suffix => .xsd
Result
mscOne20061004204249 is saved as mscOne20061004204249.xsd.
Configuring the OMC Directory for the CDR Files

acc_data_dir indicates the directory to create the CDR directory structure
within.
Figure 20 Example: trans.conf Setting for Where to Put CDR Files on the OMC
acc_data_dir => ~/DATA
This line is exactly as it should be in trans.conf.
Configuring the OMC CDR Directory Structure

Within the directory indicated in acc_data_dir, acc_trans_sub creates a CDR
folder, and within that the four folders at the right of Figure 21.
Figure 21 Directory Structure for CDRs
transferred
error
DATA CDR
pushed
pushed_archived

The folders in the CDR directory are:

transferred - all CDR files successfully retrieved and processed are saved
here.
error - all CDR files that were attempted to be converted to XML and failed
are saved here.
pushed - all CDR files successfully pushed to a third-party billing server are
moved here from transferred. This is covered in Configuring the OMC for
the Push Model.
pushed_archived - all CDR files in pushed after the retention period are
moved here. This is covered in Configuring the OMC for the Push Model.
Sample trans.conf Files

Figure 22 shows an example which obtains the MSC address from the LDAP
server, keeps the CDR files in binary format, and substitutes mscOne for 0a0b01
in the filename.
Figure 22 Example: trans.conf for LDAP Mode
ldap_hostname => localhost
ldap_port => 6699
ldap_user => Directory Manager
ldap_passwd => directory
ldap_base => dc=teloseng,dc=com
local_mode => false
#NE =>
keep_as_binary => true
#keep_as_binary => false
0a0b01 => mscOne
#suffix => .xsd
Example Result
Based on the MSC IP addresses provided by the LDAP server, the OMC:
ftps CDR files from the MSCs in binary format
Saves them without conversion in ~/DATA/transferred
Renames the files from, for example, CDR0a0b01000001 to
mscOne200610042228
Figure 23 shows an example which obtains the MSC addresses or hostnames

from the NE entries in trans.conf, converts the incoming CDR files to XML
format, and adds the suffix .xsd to the filename.
Figure 23 Example: trans.conf for Local Mode
#ldap_hostname => localhost
#ldap_port => 6699
#ldap_user => Directory Manager
#ldap_passwd => directory
#ldap_base => dc=teloseng,dc=com
local_mode => true
NE => 192.168.0.101
NE => 192.168.128.101
NE => 192.168.254.101
#keep_as_binary => true
keep_as_binary => false
#0a0b01 => mscOne
suffix => .xsd
Example Result
Based on the MSC IP addresses/hostnames in the trans.conf file, the OMC:
ftp's CDR files from the MSCs in binary format
Converts them to XML files and saves them in ~/DATA/transferred
Saves files that fail conversion in ~/DATA/error
Renames the files from, for example, CDR0a0b01000001 to
0a0b01200610042228.xsd
To View and Edit trans.conf:

1 telnet to the OMC.
> telnet <IP address>
2 Log on as user omc.
3 Change to the configuration directory.
omc > cd ~/CONF
4 Open trans.conf for editing.
omc > vi trans.conf
5 Locate the relevant parameters and edit them according to the values listed in
Table 11 or Table 12.
Table 11 lists the parameters and values in trans.conf that are relevant to
configuring LDAP mode.
Table 11 trans.conf Settings for LDAP Mode

trans.conf Parameter Value Description
ldap_hostname localhost Hostname of the OMC or localhost
(the OMC is the LDAP server).
ldap_port 6699 The TCP port used by LDAP server. Do not
use the well-known port for LDAP of 389.

Table 11 trans.conf Settings for LDAP Mode

ldap_user cn=Directory The user name needed to log on to the
Manager LDAP server.
ldap_passwd directory The password needed to log on to the
LDAP server.
ldap_base dc=teloseng, The starting point for an LDAP search.
dc=com
acc_data_dir ~/DATA The working directory for CDR files on
the OMC.
Acc_user_account MSC,msc, How to log in to the MSC and where to
ms c,~/DATA find the CDR files.
keep_as_binary true Do not convert the files to XML format
before saving them in acc_data_dir.
false Convert the CDR files to XML format
local_mode false and/or # Must be set to false and/or commented
out.
NE # Must be commented out.
suffix # or .xml Allows a suffix to appended to CDR files
If keep_as_binary => true, must be
commented out.
If keep_as_binary => false, must
be .xml.
(MSCID) MSCID => Name Allows the six-digit MSCID in the CDR file
name to replaced with an
up-to-six-character string before the CDR
file is saved in acc_data_dir. See
Configuring CDR File Naming for more
information.
Table 12 lists the parameters and values in trans.conf that are relevant to
configuring Local Mode.
Table 12 trans.conf Settings for Local Mode

acc_data_dir ~/DATA The working directory for CDR files on
the OMC.
Acc_user_account MSC,msc, How to log in to the MSC and where to
ms c,~/DATA find the CDR files.
keep_as_binary true Do not convert the files to XML format
false Convert the CDR files to XML format
local_mode true Use local mode. All LDAP settings are
overridden.
Configuring CDR Files for a Billing Server 48
Table 12 trans.conf Settings for Local Mode

NE Hostname or IP Lists an MSC from which the OMC is to
address retrieve CDR files. Each MSC needs its
own NE line.
suffix # or .xml Allows a suffix to appended to CDR files
If keep_as_binary => true, must be
commented out.
If keep_as_binary => false, must
be .xml.
(MSCID) MSCID => Name Allows the six-digit MSCID in the CDR file
name to replaced with an
up-to-six-character string before the CDR
file is saved in acc_data_dir. See
Configuring CDR File Naming for more
information.
When listing the MSCs in trans.conf by hostname, the MSCs must have entries in
the /etc/hosts file on the OMC.
Configuring CDR Files for a In addition to retrieving CDR files from the MSCs, the OMC is responsible for
Billing Server providing the files to third-party billing servers.
The OMC can be part of a push or a pull model for CDR files.
In the pull model, the OMC makes the ~/DATA/CDR/transferred folder (see
Configuring the OMC CDR Directory Structure) available for the billing server
to use FTP to download files.
In the push model, whenever the acc_trans_oss_sub cron job runs, the
OMC FTPs to a billing server and uploads the contents of
~/DATA/CDR/transferred (see Configuring the OMC CDR Directory
Structure), based on settings in ~/CONF/trans.conf
Figure 24 CDR Collection Process
Send Receive Push model
Generate Retrieve
Offer Retrieve Pull model
MSC OMC Billing Server
Configuring the OMC for the Configure the third-party billing server to pull CDRs from the MSC. Refer to the
Pull Model billing server documentation for details.
Make sure the acc_trans_oss_sub cron job is not present in crontab. If it is,
comment it out.

To provide CDRs that are formatted to the billing server's specifications, see
Configuring CDR File Format (binary or XML) and Configuring File Renaming
(rename files, add a suffix).
After the billing server pulls the CDR files, the OMC retains them in its
~/DATA/transferred directory. The billing server removes the CDR files or they
can be removed manually. See Manually Removing CDR Files.
Configuring the OMC for the Configure the instruction to push CDR files to a third-party billing server in the
Push Model OMC's crontab file. The cron job acc_trans_oss_sub controls CDR retrieval.
The configuration file for acc_trans_oss_sub is ~/CONF/trans.conf.
trans.conf is the configuration file for acc_trans_sub, acc_trans_oss_sub,

per_trans_sub, and sara_trans_sub.
A comma-delimited string of digits at the start of its crontab entry indicates the
frequency to run acc_trans_oss_sub (in other words, the frequency to upload
CDR files to the billing server).
In Figure 25, acc_trans_oss_sub runs every ten minutes, starting at one minute
past the hour.
Figure 25 Example:acc_trans_oss_sub Entry in crontab
1,11,21,31,41,51 * * * * [ -x $HOME/TOOL/acc_trans_oss_sub ] &&
$HOME/TOOL/acc_trans_oss_sub > /tmp/acc_trans_oss.log 2>&1
The billing server must be running an FTP server and be on a reachable subnet.
To View and Edit crontab:

3 Open the crontab file for editing.
omc > crontab -e
4 Make the desired changes.
Configuration Settings in Whenever acc_trans_oss_sub runs, it reads configuration settings from

~/CONF/trans.conf ~/CONF/trans.conf. From trans.conf it learns:
The IP address or hostname of the billing server
The user account information necessary to log in to the billing server
How many times to retry if there is a failure and how long to wait between
tries
Whether to compress the CDR files using gzip before uploading them
The billing server directory to put the pushed CDR files in
How long to retain pushed CDR files in the pushed folder before moving them
to the pushed_archived folder
Each of these is explained in detail in the following sections.
Billing Server IP Address / Hostname

ftp_host indicates the IP address or hostname of the billing server.
Example: trans.conf Setting for Billing Server IP Address/Hostname

ftp_host => 192.168.254.3
When indicating the billing server by hostname, there must be an entry for the
billing server in the /etc/hosts file on the OMC.
Billing Server Login

ftp_user indicates the username for the OMC to use when logging on to the
billing server, while ftp_pwd indicates the password.
Example: trans.conf Settings for Billing Server Logon

ftp_user => omc_push
ftp_pwd => cdrpush
Retries After Failure

retry indicates how many times the OMC should retry if there is a failure during
ftp, while retry_wait indicates how long the OMC should wait between retries,
in seconds.
Example: trans.conf Settings for Retries After Failure

retry => 5
retry_wait => 2
CDR File Compression

compress indicates whether the OMC should compress the files using gzip
before pushing them to the billing server. Files that have been compressed are
given a .gz suffix. To bypass compression, set compress => false.
Example: trans.conf Setting for CDR File Compression

compress => true
CDR File Directory on the Billing Server

ftp_dest indicates the billing server directory to which the OMC should upload
CDR files.
Example: trans.conf Setting for Billing Server CDR File Directory

ftp_dest => ~/CDRimport

Retention Period for Pushed Files

retention indicates how many days (minimum of two) the OMC should retained
pushed CDR files in its ~/DATA/CDR/pushed folder before moving them to
~/DATA/CDR pushed_archived. See CDR Directory Structure for an explanation
of the CDR directory structure.
Example: trans.conf Setting for Pushed CDR File Retention

retention => 2
CDR Directory Structure

The CDR directory structure is shown in Figure 26.
Figure 26 Directory Structure for CDRs
transferred
error
DATA CDR
pushed
pushed_archived
The folders in the CDR directory are:

transferred - all CDR files successfully retrieved from the MSCs and
processed are saved here. See Configuring CDR Retrieval at the OMC for
details.
error - all CDR files that were attempted to be converted to XML and failed
are saved here. See Configuring CDR Retrieval at the OMC for details.
pushed - all CDR files successfully pushed to a third-party billing server are
moved here from transferred.
pushed_archived - all CDR files in pushed after the retention period are
moved here.
Sample trans.conf Files

When acc_trans_oss_sub runs, it loads the configuration in
~/CONF/trans.conf. In Figure 27, the OMC compresses the new CDR files, logs
in to a billing server, and uploads the files.
Figure 27 Example: trans.conf for CDR File Push to Billing Server
ftp_host => 192.168.254.3
ftp_user => omc_push
ftp_pwd => cdrpush
retry => 5
retry_wait => 2
compress => true
ftp_dest => ~/CDRimport
retention => 2
Example Result
The OMC:
Takes new CDR files from its ~/DATA/CDR/transferred directory
Compresses each CDR file using gzip
ftps to the billing server and puts the compressed CDR files in the
~/CDRimport directory
Moves successfully pushed files to ~/DATA/CDR/pushed
Checks ~/DATA/CDR/pushed for CDR files more than two days old and moves
them to ~/DATA/CDR/pushed_archived
To View and Edit trans.conf:

3 Change to the configuration directory.
omc > cd ~/CONF
4 Open trans.conf for editing.
omc > vi trans.conf
5 Locate the relevant parameters and edit them according to the values listed in
Table 13.
Table 13 lists the parameters for configuring FTP for CDR transfer to the billing
server.
Table 13 CDR FTP Configuration Parameters
Parameter Value Description

ftp_host [IP address | hostname] Specifies the IP address or hostname of
the billing server.
ftp_user [username] Specifies the username to access the FTP
server (billing server). An account is
needed on the billing server to use FTP.
ftp_pwd [password] Specifies the password to access the FTP
server (billing server).
ftp_dest [CDR directory path] Specifies the directory where CDR files are
transferred to on the FTP server (billing
server). The path can be absolute or
relative to the user (ftp_user) home
directory ($HOME).
retry [number] Specifies the number of times to retry FTP
connection if connection attempt fails.
retry_wait [seconds] Specifies the interval (in seconds) to wait
before retrying connection attempt.

CDR File Persistence on OMC

The CDR files remain on the OMC after they have been pushed to the billing
server. These files accumulate until they are removed manually (see Manually
Removing Pushed CDR Files) or automatically (see Automating CDR Archival and
Removal).
VIEWING AND MANAGING CALL DETAIL
5 RECORDS
This chapter explains how to use several tools to operate and maintain CDRs.

CDR File Operations at the MSC
CDR File Operations at the OMC
CDR File Maintenance at the MSC
CDR File Maintenance at the OMC
Binary CDR Format
XML CDR Format
ASCII CDR Format
CDR File Operations at the This section describes CDR file operations at the MSC, which include how to
MSC display CDR files, how to view the current day CDR log, and how to view the CDR
log for multiple days.
Before displaying the CDRs from a file, to find out the CDR files that are available
on the system, list the CDR files.
Listing CDR Files CDR files are written to /telos/msc/DATA on the MSC. Use UNIX commands to
list the generated CDR files on the MSC.
To List CDR Files:

1 Log on as user msc and change to the ~/DATA directory.
msc > cd DATA
2 List all CDR files.
msc > ls -l CDR*
Example 1 Listing CDR Files
msc > pwd

~
msc > cd DATA
msc > pwd
~/DATA
msc > ls -l CDR*
-rw-rw-r-- 1 msc telos 6144 Jun 29 18:52 CDR000001000044
-rw-rw-r-- 1 msc telos 2048 Jul 5 17:56 CDR000001000045
Displaying CDRs The cdr_reporter tool displays individual CDRs and prints CDRs to standard
output.

55 Chapter 5: Viewing and Managing Call Detail Records
cdr_reporter is located in the /TOOL directory.
Warning:
Using cdr_reporter can overload the system.
To Display Records in a CDR File:

1 Get the CDR filename using the procedure in Listing CDR Files on page 54.
1 Stay in the ~/DATA directory.
2 Execute the tool:
cdr_reporter <CDR filename>
3 To display the CDRs one page at a time:
cdr_reporter <CDR filename> | more
cdr_reporter Tool Usage

The cdr_reporter tool command options specify the type of call records to
show, allow a range of CDR records within the file to be displayed, print dates in
several formats, and also perform error checking on the specified CDR records.
A CDR file sequence number is different from a CDR record sequence number. A
CDR file contains multiple records, each with its own sequence number.
The cdr_reporter Tool Usage is shown below with following examples:

cdr_reporter [-Y [012]] [-s seq#] [-e seq#] [-t[uiy]] [-f[vtb]]
[-E] <cdr_filename1 cdr_filename2 ... >
Table 14 lists the options for the cdr_reporter command.
Table 14 cdr_reporter Command Options
Option Description
-Y [0 | 1 | 2] Specifies the call record type.
0 All record types
1 Call Detail only (default)
2 SMS Detail only
-s [seq #] Specifies the starting CDR record sequence number.
-e [seq #] Specifies ending CDR record sequence number.
-t [u | i | y] Specifies the time output format for the Seized, Answered, and
Disconnected fields in the CDR records.
u UNIX time (Tue Nov 26 23:07:14 1996)
i Integer time (2147482656)
y YMD time (20050719091534)
-f [v | t | b] Specifies the CDR record output format.
v Verbose (default - equivalent to -tu)
t Terse (equivalent to -ty)
b Binary (literal record)
-E Specifies that error checking should be performed on CDR records
using checksum. Corrupt records are not displayed.
CDR File Operations at the MSC 56
Example 2 shows the output from a simple cdr_reporter command.

Individual records are identified with a sequence number (show in bold).
Example 2 cdr_reporter Tool Output
msc > cdr_reporter CDR000001017881

A:302370107153495 type:MOBILE digits:4050 trunk:2001 ESN:0x0 ce
B:310972148534022 type:MOBILE digits:4002479000 trunk:2002 ESN: cell:
Originating MSISDN:14002474495
Terminating MSISDN:14002474050
Originating Exchange:
Terminating Exchange:
A Feature Bits:
B Feature Bits: CLIP
Seized: 20070809135143
Answered: 20070809135156
Disconnected: 20070809135201
Disc code: A_PARTY_NORMAL_DISC
Sequence: 8421
MscId: 1
Orig Call Ref: 0
GMSC Call Ref: 0
Orig MSC Addr:
GMSC Addr:
A Trunk Group: 8
B Trunk Group: 8
Orig Calling Pty No: 14002474495
Imm Cllg Pty|Rdrct#:
Last Interim Time:
cdr_reporter command variations include:

cdr_reporter -Y 0 -t y -f v CDR000c06008296 : All CDR record types, uses YMD
time, and verbose output.
cdr_reporter -E -Y 0 -t y -f v CDR000c06008296 : Also performs
error checking and prints out number of corrupt records.
cdr_reporter -Y 0 -s 226227313 -e 226227333 -t u -f v
CDR000c06008296 : All CDR record types, specifies range of CDR record
sequence numbers, uses UNIX time, and verbose output.
Viewing Current Day CDR Log Use the vlog utility to view a log of the CDR files generated during the current
day (24:00 onward). (Refer to the Viewing Logs and Events chapter of the Core
Voice Network Operations, Maintenance, and Provisioning Guide for information
on vlog.)
If the system has restarted during the current day, the log will show CDR activity
only since the restart.

To View CDR Log for Current Day:

Caution:
If the MSC is processing a large number of calls (more than 100,000 calls per day),
this option can degrade call processing performance. To view large numbers of
records, use a billing system.
1 Run the vlog utility.

2 Select the second option, 2. View Call Detail Records: Latest.
3 Exit vlog.
Viewing CDR Log for Multiple Use vlog to display historic CDR files. The number of CDR files kept on disk is
Days controlled by the value of num_files. To change the value of num_files, see
Configuring the Maximum Number of CDR Files on MSC Disk on page 39.
Use cdr_stats to view specific CDR records.
To View Multiple Day CDR Log:

Caution:
If the MSC is processing a large number of calls (more than 100,000 calls per day),
this option can degrade call processing performance. To view large numbers of
records, use a billing system.

2 Select the first option, 1. View Call Detail Records.
vlog displays a list of CDR files by date (see Figure 28).
3 Type the number next to the desired date.
The CDR records in the CDR file for that date are displayed.
4 Select another log file to view, or exit to the vlog menu.
5 Exit vlog.
See Figure 28 for an example that displays multiple day CDR log.
Figure 28 Example: Multiple Day CDR Log

Select a file to view from the list:
1) (1)-000044-2005-Jul-4
2) (1)-000045-2005-Jul-5
3) (1)-000046-2005-Jul-6
4) (1)-000047-2005-Jul-7
5) (1)-000048-2005-Jul-8
6) (1)-000049-2005-Jul-9
7) (1)-000050-2005-Jul-10
8) (1)-000051-2005-Jul-11
9) (1)-000052-2005-Jul-12
10) (1)-000053-2005-Jul-13
11) (1)-000054-2005-Jul-14
12) (1)-000055-2005-Jul-15
13) (1)-000056-2005-Jul-16
14) (1)-000057-2005-Jul-17
15) Exit
Type the number of the selection then press ENTER:
CDR File Operations at the OMC 58
CDR File Operations at the The file provisioning procedures on the OMC relate to the push model only:
OMC Archiving Transferred CDR Files
Manually Removing Pushed CDR Files
Automating CDR Archival and Removal
Archiving Transferred CDR CDR files are automatically archived from pushed to pushed_archived after the
Files expiry of the retention period - no extra configuration is required (see Retention
Period for Pushed Files on page 51). Only CDR files that have been pushed to the
billing server are archived.
Archived CDR files will remain in pushed_archived until they are removed.
Remove archived CDR files to free up disk space on OMC. Archived CDR files can
be moved to another storage location (off OMC disk) or deleted.
Archiving the transferred CDR files could be part of a regular maintenance

routine or performed periodically based on disk space analysis or quotas.
An automated approach to managing archiving and removing CDR files is to set

up a cron job (see Automating CDR Archival and Removal on page 59).
To Manually Archive Transferred CDR Files:

1 Log on to the storage machine and change to the CDR storage directory.
This procedure assumes CDR in GZIP format is stored on
<machine>/ftp/cdr/pushed.
2 FTP to OMC.
> ftp <IP address>
4 Change to the directory with the archived CDR files.
ftp> cd ~/DATA/CDR/pushed_archived
5 Set to binary transfer.
ftp > bi
6 Transfer the GZIP CDR files.
ftp > mget *.gz .
7 Log off OMC.
ftp > bye
8 Optionally, test the integrity of the transferred GZIP files on the storage machine.
<machine> > gzip -tv <filename>.gz
<filename>.gz: OK
<machine> >
Manually Removing Pushed Remove CDR files that have been pushed to the billing server on OMC, as they
CDR Files have no purpose. Removing transferred and archived CDR files could be part of a
regular maintenance routine or performed periodically based on disk space
analysis or quotas.

To Delete Transferred CDR Files:

1 telnet to OMC.
3 Change to the directory with the archived CDR files.
omc > cd ~/DATA/CDR/pushed_archived
4 Remove the CDR files.
omc > rm -i *
If the -i option is not supported, then accept prompts to remove desired files.
Automating CDR Archival and In practice, push CDR files to the billing server during off peak hours (say 02:00).
Removal Add a cron job to the OMC crontab file to archive the CDR files to another
storage location, and then remove the CDR files from OMC. Schedule the job to
run immediately after the CDR push.
CDR File Maintenance at This section describes CDR file maintenance at the MSC, which includes:
the MSC
Verifying CDR Generation
Verifying CDR File Generation
cdr_info Tool
Viewing CDR Transaction Summary
Checking for CDR Record Corruption
Checking Available Disk Space for CDRs
Freeing Space in ~/DATA
Verifying CDR Generation Use the cdr_reporter tool to verify that CDR records are being generated. See
cdr_reporter Tool Usage for more information on this tool.
The generation of CDR records can only be checked after they have been written
to disk (this occurs no less frequently than every 30 seconds).
The working file is only closed and written as a CDR file when t_file expires.
Because writing CDR records and files is based on timers, it is possible CDR files
will be empty (contain no records). This is especially true if timers are set too
strictly (for example, t_log_flush=30 seconds and t_file=5 minutes).
To Verify CDR Generation:

1 List the CDR files in ~/DATA.
2 Examine the output from the command.
If a CDR file shows 0 bytes then it contains no records.
3 Execute cdr_reporter on the latest CDR file that contains records.
msc > cdr_reporter -Y 0 -t u -f v <CDR filename>
CDR File Maintenance at the MSC 60
4 Examine the timestamp of the latest record.

Verify that it was generated from the most recent CDR file write (see value of
t_file for period).
Verifying CDR File Generation Use the cdr_info tool to verify that CDR files are being properly generated. See
cdr_info Tool for more information on this tool.
Warning:
Do not edit a CDR record or file, change the timestamp, or change a sequence
number.
To Verify CDR File Generation:

1 List the CDR files in ~/DATA.
2 Examine the output from the command.
If CDR files are not generated with the frequency specified by t_file then check
the value for t_file (see Configuring the CDR File Generation Timer on
page 36).
3 Execute cdr_info on the latest CDR file.
msc > cdr_info -v <CDR filename>
4 Compare the timestamp from the cdr_info with the timestamp from ls -l
command.
Verify that they are consistent, and that the file contains no corrupt records (see
cdr_info Tool).
cdr_info Tool The cdr_info CLI tool provides meta-information about CDR records and CDR
files themselves - not the content of the record or file. The tool has a single
option that provides information on number of records in a file, starting and
ending sequence numbers for records, the CDR version, and the file timestamp.
No CRC check is performed.
Usage
cdr_info -v [<cdr_filename1 cdr
cdr_info -v [<cdr_filename1 cdr_filename2 ... >
Table 15 lists the options for the cdr_info command.
Table 15 cdr_info Command Options
Option Description
-v Verify that the CDR records in the specified CDR files are CDR files for a
supported CDR version. Does not perform CRC check.
Examples
cdr_info -v CDR000c06008296 CDR000c06008297 CDR000c06008298

Verify the specified CDR files.
Example: cdr_info Command Output

msc > cdr_info -v CDR000C06008296 CDR000C06008297 CDR000C06008298
VERIFY RECORDS START END VERS TIME
CDR000C06008296 ok 6 226227310 226227315 8 Tue Jul 19 07:45:31
2005
CDR000C06008297 ok 9 226227316 226227324 8 Tue Jul 19 09:26:31
2005
CDR000C06008298 ok 9 226227325 226227333 8 Tue Jul 19 10:49:01
2005
msc >
Table 16 describes the fields in the cdr_info output.
Table 16 cdr_info Field Description
Field Description
VERIFY Specifies the state of the CDR records in the file. Can be either OK |
CORRUPT
OK means the record is a CDR file that conforms to a CDR version.
CORRUPT means that the file does not conform to a CDR version, has a
sequence mis-match, or other unspecified problem.
RECORDS Lists the number of CDR records in the CDR file.
START Lists the starting CDR record sequence number in the given CDR file.
END Lists the ending CDR record sequence number in the given CDR file.
VERS Lists the CDR version number.
TIME Lists the timestamp when the CDR file was written to disk.
Viewing CDR Transaction View a summary of the state of CDR transactions (processed CDR files) on the
Summary MSC with vlog. A CDR is in the transacted state when it has been processed
through to the billing system.
To View Transacted Call Detail Summary:

2 Select option 11. View Call and SMS Detail Summary.
vlog displays a summary table (see Figure 29).
3 Select another option from the menu, or exit to the prompt.
Figure 29 Example: Call and SMS Summary Table

Mscid-Seq-Date NumRecords Transacted BeginSeq EndSeq
============== ========== ========== ======== ======
(1)-000044-2004-Oct-4 1 inprogress 194 194
(1)-000045-2004-Oct-5 34 unknown 195 228
(1)-000046-2004-Oct-6 0 pending 0 0
(1)-000047-2004-Oct-7 0 pending 0 0
(1)-000048-2004-Oct-8 0 pending 0 0
(1)-000049-2004-Oct-9 0 pending 0 0
(1)-000050-2004-Oct-10 0 pending 0 0
Table 17 describes the fields in the Call and SMS Summary Table.
Table 17 Call and SMS Summary Table Field Descriptions
Field Description
Mscid-Seq-Date Specifies the start sequence date on the MSC.
NumRecords Specifies the number of records transacted on that date.
The number of records should equal end sequence number less
beginning sequence number plus 1 (NumRecords = EndSeq -
BeginSeq +1).
Transacted Specifies the transacted status for records of that date.
Can either be:
inprogress
pending
unknown
BeginSeq Specifies the beginning sequence number.
EndSeq Specifies the ending sequence number.
Checking for CDR Record Each CDR record is appended with a checksum when it is written to the MSC disk.
Corruption The CDR record (V9) is 508 bytes and the checksum is 4 bytes, creating a CDR
record of 512 bytes (see Figure 30).
Figure 30 CDR Record Checksum
The CDR checksum is used to validate each CDR record as it is processed. CDR
files can be checked for corrupt CDR records.
To Check CDR File for Corrupt CDR Records:

1 Get the CDR filename.
Use the procedure in Listing CDR Files on page 54.
2 Execute the cdr_reporter tool with error checking option.
cdr_reporter -E <CDR filename>.
See Figure 31 for a sample of error checking on a CDR file. If the CDR file contains
a corrupt CDR record, the corrupt CDR record is not displayed and an error is sent
to stderr (standard output). The valid CDR records are displayed.

Always use the -E option to check for corrupt CDR files. Corrupt CDR records may
appear normal upon display but the data may be inconsistent.
Figure 31 Example: CDR File with Error Checking

msc > cdr_reporter -E CDR000C06008189
...
0 corrupt / 65 records
msc >
Checking Available Disk Space The MSC allocates more than 50% of the disk space to CDR files and trace files.
for CDRs On a 73 GB disk, this is approximately 35 GB (see CDR Storage Capacity at the
MSC on page 33). Depending on BHCA, the available disk space can quickly fill
with CDR files. This is especially true if trace files are also generated.
To save disk space, the MSC only keeps a limited number of CDR files. How
frequently the file is generated and how many files to keep are configured in
cdr-config table. By default, the CDR file is generated every 24 hours at the
beginning of the 24-hour cycle and 96 files are kept. When the number of files
exceeds 96, the oldest files are removed
Do not fill up a disk. The OS runs best when at least 20% of the disk is free.
CDR files are stored in ~DATA (/export/home/msc/DATA) but check disk space
usage for the entire partition. Logging in as user msc sets the current (~) directory
to /export/home/msc.
To Check CDR Disk Space Usage:

1 Log on to the MSC as user msc.
Use telnet or Reachthrough to MSC.
2 Check disk usage on ~ and record the value.
msc > du -s -k
3 Check disk usage on ~/DATA and record the value.
msc > cd DATA
msc > du -s -k
4 Calculate available disk space in ~/DATA.
Use either of the following formulas to calculate available disk space:
GB available = (Disk partition size * utilization factor) - (# of kilobyte blocks /
1,000,000)
GB available = (Disk partition size * utilization factor) - (# of 512 byte blocks /
2,000,000)
5 If the amount of available disk space is not sufficient, free up some space.
See Freeing Space in ~/DATA on page 64.
See Figure 32 for a sample output from the du command.

Figure 32 Example: du Command Output
msc > pwd
~
msc > du -s -k
7623574 .
msc > cd DATA
msc > du -s -k
337734 .
msc >
The du command reports on the number of 512 byte blocks the directory (and
subdirectories) uses. Disk space usage can also be reported in kilobyte blocks
instead of 512 byte blocks with the -k option.
Table 18 lists the relevant options for the du command.
Table 18 du Command Options
Option Description
-k Displays size in 1024 byte block size instead of 512 byte default size.
-s Displays only the total for each directory or file.
Freeing Space in ~/DATA If the number of CDR files on disk reaches the maximum permitted (num_files)
before the OMC retrieves them (5-minute intervals, minimum 5 minutes), then
files are overwritten.
Do not remove CDR files to free up disk space. Instead, remove trace files and
abort (system dump) files. Trace files are in ~/RUN and Abort files are in ~/RJE.
Abort (system, or core dumps) filenames have the following syntax:

ABORT-MMM-DD-YYYY-HH:MM:SS. The .env file (sourced at startup) configures
the number of kept abort files to a maximum of 5 (default). Oldest files are
removed. RJE acts as a kind of temporary directory (holds installed patches,
abort files, etc) and everything in this directory can be deleted if disk space is
required.
Trace files can be generated for many subsystems and can be quite large. The
system maintains an active trace file with filename syntax <subsystem>.trace.
Do not delete this file. When the trace file is written it is renamed to
<subsystem>.trace.prev. These files can be removed, if necessary.
The MSC also runs a cron job that backs up trace files using file size and file
number as criteria. These trace backup files have the following syntax:
<subsystem>.trace.trc_roll.<timestamp>. These files are useful for
maintenance and troubleshooting but can be removed, if necessary.

To Free Space by Removing Trace and Abort Files:

Caution:
Do not delete <subsystem>.trace files in ~/RUN.
Delete only files named *.trace.* in ~/RUN.
1 Logon to the MSC as user msc.

Use telnet or Reachthrough to MSC.
2 Change to ~/RJE and delete all files.
msc > cd RJE
msc > rmdir *
3 Change to ~/RUN and delete trace files and trace file backups.
msc > cd ../RUN
msc > rm *.trace.*
CDR File Maintenance at CDR file maintenance at the OMC includes:

the OMC
Verifying Persistence of Retrieved CDR Files
Checking the CDR File Conversion Log
Push Model Only: Verifying CDR Transfer to Billing Server
Manually Removing CDR Files
Verifying Persistence of The OMC retrieves CDR files from the MSC and puts them in the /transferred
Retrieved CDR Files directory on the OMC. The OMC records collection errors in
/tmp/acc_trans.log.
To Verify Persistence of Retrieved CDR Files:

1 telnet to OMC.
3 Change to the transfer directory.
omc > cd ~/DATA/CDR/transferred
4 List the files and use the timestamp to verify that CDR files are being collected.
omc > ls -l
If CDR files are not collected as expected then check the log file.
omc > cd /tmp/acc_trans.log
Manually Removing CDR Files Manually remove CDR files from the OMC using UNIX commands.
3 Change to the directory with the retrieved CDR files.
omc > cd ~/DATA/CDR/transferred
4 Remove all CDR files.
omc > rm *
CDR File Maintenance at the OMC 66
Log off from the OMC.

omc > exit
Checking the CDR File CDR files can be converted from the native binary format to XML format. If a
Conversion Log single binary file cannot be converted then the entire conversion is halted and all
of the binaries are moved to error . A log file (acc_trans.log) is generated in
the /tmp directory when the conversion process is halted.
To Check CDR Conversion Log:

1 telnet to OMC.
3 Change to the temporary directory.
omc > cd /
omc > cd tmp
View the log file.

omc > more acc_trans.log
Push Model Only: Verifying After CDR files are uploaded to the billing server, they are moved from the
CDR Transfer to Billing Server transferred directory to the pushed directory.
If a CDR file is in pushed then it has been pushed to the billing server. When its
file age exceeds the retention period (see Retention Period for Pushed Files), the
file is moved to pushed_archived.
Optionally, check the billing server itself for the presence of CDR files. This guide
does not discuss how to check for CDR files on a third party billing server.
To Verify CDR Transfer to the Billing Server:

1 telnet to OMC.
3 Change to /DATA/CDR/pushed.
omc > cd ~/DATA/CDR/pushed
4 List files and visually verify that the desired file exists with the correct timestamp.
omc > ls -l
The presence of the CDR file with the correct timestamp depends on the
configuration performed in Configuring the OMC for the Push Model on page 49.
To Verify CDR on Billing Server:

See the product documentation for the third-party billing server to determine
how to check for successfully transferred CDR files.

Binary CDR Format The MSC writes CDRs in binary format at a fixed length of 512 bytes. Each of the
CDR elements is structured as one of 10 data types. The CDR format is based on
Version 11.
Data Types Each of the data types is based on the equivalent C language integral type
(integers) and/or the aggregate type (character arrays).
Table 19 CDR Data Types
Data Type Description

unsigned char One (1) byte long, this holds a numeric value from 0 to 255.
unsigned short Two (2) bytes long, this holds numeric values. Conforms to
the underlying machine architecture format. There are two
possible formats: Intel x86 and Sun SPARC.
Intel x86: The (hexadecimal) integer value 0x0102 will be
stored as the following character values:
02 01
A A+1
Sun SPARC: The (hexadecimal) integer value 0x0102 will be

stored as the following character values:
01 02
A A+1
A null integer value is zero (0).

integer; unsigned long Four (4) bytes long, this holds numeric values. Conforms to
the underlying machine architecture format. There are two
possible formats: Intel x86 and Sun SPARC.
Intel x86: The (hexadecimal) integer value 0x01020304 will
be stored as the following character values:
04 03 02 01
A A+1 A+2 A+3
Sun SPARC: The (hexadecimal) integer value 0x01020304 will

be stored as the following character values:
01 02 03 04
A A+1 A+2 A+3
A null integer value is zero (0).

number A digit string a character array of the ASCII digits
0123456789. A number array is 17 bytes long: 16 bytes plus
one terminating ASCII null (0x00) character.
A null number value is the empty array (the first character is
the null character). Array elements after the terminating null
character are undefined.
Binary CDR Format 68
Table 19 CDR Data Types (continued)

hexnumber A digit string a character array of the hexadecimal ASCII
digits 0123456789ABCDEF. A hexnumber array is 17 bytes
long: 16 bytes plus one terminating ASCII null (0x00)
character.
A null number value is the empty array (the first character is
the null character). Array elements after the terminating null
digits A digit string a character array of ASCII values
0123456789*#. The storage format is the same as the
number type. A digits array is 33 bytes long: 32 bytes plus
one terminating ASCII null (0x00) character.
A null digits value is an empty array (the first character is the
null character). Array elements after the terminating null
trunk A trunk type represents the switch's trunking resources.
Valid trunk values are as defined in the port database table.
A null trunk value is zero (0).
Trunk is stored the same way as integer.
time A time type represents the date and time of day value. It is
represented as the number of seconds since 00:00:00
Universal Coordinated Time (UTC), January 1, 1970. This is an
integer type. There is no null time value.
Note: All time stamps are based on the local time of the MSC
that produced the CDR.
Time is stored the same way as integer.
party-type A party-type is used to qualify a call party. This is an integer
type. Valid party types are (integer values are inside the
parentheses):
UNKNOWN (0) the party type is unknown
MOBILE (1) the party is a mobile subscriber
LAND (2) the party is a PSTN (land) type
FEATURE (5) the party accessed a vertical feature (e.g.
enable call forward busy, disable call waiting, etc.)
FORWARD (6) the party type resulted from a call forward
scenario (i.e. providing forward-to digits)
THREEWAYCALL (8) the party was involved in a three-way
call
CALLWAITING (9) the party was involved in a call-waiting
call
ANI_SUB (10) the party has a valid entry in the ani-sub
database table
CALLING_CARD (11) the party used a calling card feature
SIP (12) the party was involved in an IP inter-MSC trunked
call
Party-type is stored the same way as integer.

Table 19 CDR Data Types (continued)

feature-bit A feature-bit type represents features accessed during the
call. The value is interpreted as an array of bits. Each bit has
an assigned meaning. A feature-bit field is an integer type.
Valid feature bits are:
NORMAL (0) normal call without any feature involved.
EMERGENCY (1 or bit 1) emergency call establishment
RETRIEVE (2 or bit 2) retrieve call from hold
JOIN (4 or bit 3) join to multi-party call
HOLD (8 or bit 4) call set on hold
CW (16 or bit 5) party was call waited
CLIR (32 or bit 6) calling line identity restriction
CLIP (64 or bit 7) calling line identity presentation
CFU (128 or bit 8) call forwarding unconditional
CFB (256 or bit 9) call forwarding on mobile subscriber busy
CFNRy (512 or bit 10) call forwarding on no reply
CFNRc (1024 or bit 11) call forwarding on mobile subscriber
not reachable
WO (2048 or bit 12) wireless office (intelligent network)
PPOB (4096 or bit 13) pre-paid offline billing a pre-paid
mobile made a call but the pre-paid SCP could not be
reached
PCO (8192 or bit 14) the A party is a public call office
CRG (16384 or bit 15) the charge rate was derived from an
ISUP CRG message
DMHCHG (32768 or bit 16) the charge rate was derived
from a DMH_ServiceID
ECT (65536 or bit 17) - Explicit call transfer
SPINI (131072 or bit 18) - Subscriber PIN Intercept
SPINA (262144 or bit 19) - Subscriber PIN Access
CNAR (524288 or bit 20) - Calling Name Restriction
CNAP (1048576 or bit 21) - Calling Name Presentation
Feature-bit is stored the same way as integer.
Field Descriptions Table 20 describes the contents of each field and gives the field size for each and
the offset from the start of the record.
Table 20 CDR Version 11 Field Descriptions
Field Offset Length Data Type Description

version 0 bytes 4 bytes integer Record version. Identifies a format of record. Valid
versions are:
V11 (11) current CDR version

seq_num 4 bytes 4 bytes unsigned Sequence number. Indicates a unique instance of a record
long over the switch lifespan. This number is unique only on
the system that generated it. Valid sequence number
values range from 1 to 2147483648.
type 8 bytes 4 bytes integer Record type. Indicates what kind of record the CDR is.
Valid record types are:
CALL_RECORD (1) Service completion type
SMS_RECORD (2) Short Message Service completion
type
a_party_num 12 bytes 33 bytes digits A-party number. The call originating (i.e. calling) party.
This contains the following:
The IMSI if the party is a mobile subscriber
The ANI of the party if resulting from land origination (It
is taken from the CALLING buffer, or for the call feature,
from the ANI buffer)
For CDMA SMS record:
A-party's MIN for mobile originated SMS
B-party's MDN for mobile teminated SMS
b_party_num 45 bytes 33 bytes digits B-party number. The call terminating (i.e. called) party.
This contains the following:
The IMSI if the party is a mobile subscriber
It will be empty (blank) for land termination unless the
party was found in the ani-sub or card-sub database
tables
For CDMA SMS record:
Empty for mobile originated SMS
B-party's MIN for mobile teminated SMS
[filler] 78 bytes 2 bytes n/a n/a
a_party_type 80 bytes 4 bytes party-type A-party type. The type associated with the originating
(integer) party.
For a CDMA SMS record:
MOBILE for mobile-originated SMS
UNKNOWN for mobile-terminated SMS
Valid A-party types are:
UNKNOWN; MOBILE; LAND; FEATURE; FORWARD;
THREEWAYCALL; CALLWAITING; ANI_SUB; CALLING_CARD
b_party_type 84 bytes 4 bytes party-type B-party type. The type associated with the terminating
(integer) party.
UNKNOWN for mobile originated SMS
MOBILE for mobile terminated SMS
Valid B-party types are:
UNKNOWN; MOBILE; LAND; FEATURE; FORWARD;
THREEWAYCALL; CALLWAITING


a_party_digit 88 bytes 33 bytes digits Calling party digits. Digits dialed by the originating party. If
s this is a gateway feature call, the digits are taken from the
CALLING buffer.
Empty for mobile originated SMS
Empty for mobile terminated SMS
b_party_digit 121 bytes 33 bytes digits Called party digits. Digits resulting from translation (i.e.
s routing digits). They are taken from the CALLED buffer.
B-party's MDN for mobile originated SMS
B-party's MDN for mobile terminated SMS
a_party_trun 156 bytes 4 bytes trunk A-party trunk. The system port number the originating
k (integer) party used to originate the call.
Message Reference for mobile originated SMS
Empty for mobile terminated SMS
b_party_trun 160 bytes 4 bytes trunk B-party trunk. The system port number the terminating
k (integer) party used during the call. For an SMS record, this field is
empty.
seize_time 164 bytes 4 bytes time (integer) Seize time. When an origination event arrives at the MSC.
For an SMS record, this is the Event Time Stamp, which is
the same as answer_time and disc_time.
answer_time 168 bytes 4 bytes time (integer) Answer time. When the terminating party answered call. If
the call was not answered, it contains the disconnect time.
For an SMS record, this is the Event Time Stamp, which is
the same as seize_time and disc_time.
disc_time 172 bytes 4 bytes time (integer) Disconnect time. When the call leg has ended. For an SMS
record, this is the Event Time Stamp, which is the same as
seize_time and answer_time.
disc_code 176 bytes 4 bytes integer Disconnect code. The reason that a call could not be
completed or was eventually disconnected. Valid
disconnect codes are listed in CDR Disconnect Codes.
54 (Protocol Failure) implies failure, see disc_reason
201 (A Party Normal Disconnect) implies success
59 (Teleservice Unavailable) implies failure, user did not
have SMS provisioned
Other values may be used in abnormal cases such as
resource shortage, etc.
disc_reason 180 bytes 4 bytes integer Disconnect reason.
msc_id 184 bytes 4 bytes integer MSC identifier. The MSC where this record was created. Its
value is defined in the cdr-msc table.
orig_esn 188 bytes 17 bytes hexnumber For future enhancement.
term_esn 205 bytes 17 bytes hexnumber For future enhancement.

cell_id 224 bytes 4 bytes integer Cell identifier. The originating/terminating mobiles cell. Its
value is defined in the bsc-cell database table.
If b_cell_id in the cdr-config database is set to 1, the
highest 16 bits contain b_cell_id (terminating mobile's
cell, type is unsigned short) and the lowest 16 bits
contain a_cell_id (originating mobile's cell, type is
unsigned short) for voice calls.
If b_cell_id in cdr-config database is set to 0, only the
lowest 16 bits are used.

Cell id value 0 indicates that the cell id does not exist.
a_feature_bit 228 bytes 4 bytes feature-bit For an SMS record, this field is empty.
s (integer) Valid A-feature bits are: NORMAL; EMERGENCY; RETRIEVE;
JOIN; HOLD; CW; CLIR; WO; PPOB; PCO; CRG; DMHCHG;
ETC; SPINI; SPINA; CNAR
b_feature_bit 232 bytes 4 bytes feature-bit For an SMS record, this field is empty.
s (integer) Valid B-feature bits are: NORMAL; RETRIEVE; JOIN; HOLD;
CW; CLIP; CFU; CFB; CFNRy; CFNRc; WO; ECT; SPINI; SPINA;
CNAP
o_msisdn 236 bytes 17 bytes number Identifies the calling party. This field records a mobile
subscriber's MDN.
t_msisdn 253 bytes 17 bytes number Identifies the called party. This field records a mobile
subscriber's MDN.
o_exchange 270 bytes 17 bytes number Identifies call origination's JIP. The field has non-empty
values only if the call is originated from this switch and the
bsc-cell table has JIP values configured or the incoming
IAM has a JIP value.
t_exchange 287 bytes 17 bytes number Identifies the called party's LRN. The field has non-empty
values only if the call is terminated to a LNP (Local Number
Portability) mobile and this MSC has queried an NP
database.
o_market_id 304 bytes 2 bytes unsigned These three fields identify the billing record id of this CDR
short if this is origination call. Otherwise these three fields
o_switch_nu 306 bytes 1 byte unsigned identify the billing record id of the terminating CDR that
m char corresponds to this CDR.
[filler] 307 bytes 1 byte n/a

o_billing_id 308 bytes 4 bytes unsigned
long
t_market_id 312 bytes 2 bytes unsigned These three fields identify the billing record id of this CDR
short if this is terminated call. Otherwise these three fields
t_switch_nu 314 bytes 1 byte unsigned identify the billing record of the originating CDR that
m char corresponds to this CDR.
[filler] 315 bytes 1 byte n/a

t_billing_id 316 bytes 4 bytes unsigned
long


o_billing_digi 320 bytes 33 bytes digits The billing digits associated with the A party mobile. The
ts digits could be from subscriber's profile in HLR or from
SCF. If this is not a mobile originated call or both the HLR
and the SCF do not have billing digits, it is '0'.
t_billing_digit 353 bytes 33 bytes digits The billing digits associated with the B party mobile. The
s digits could be from subscriber's profile in HLR or from
SCF. If this is not a mobile terminated call or both the HLR
and the SCF do not have billing digits, it is '0'.
a_party_trkgr 386 bytes 2 bytes unsigned The A party trunk group. The system trunk group number
p short used for call origination.
EMPTY (0) for SMS
b_party_trkg 388 bytes 2 bytes unsigned The B party trunk group. The system trunk group number
rp short used for call termination.
EMPTY (0) for SMS
o_serviceid 390 bytes 2 bytes unsigned The DMH Service ID for origination mobile from the SCP.
short For example, WIN PrePaid Server, either via orreq or
analyzed info responses.
t_serviceid 392 bytes 2 bytes unsigned The DMH Service ID for termination mobile from the SCP.
short For example, WIN PrePaid Server, either via orreq or
analyzed info responses.
crg_charge_i 394 bytes 1 byte unsigned For WIN 16 kHz calls - the charge information passed in
nfo char the ISUP CRG message. Filled in only if the A-party CRG
feature bit is set.
ocpn 395 bytes 33 bytes digits Calling party number. If mobile-originated, contains the
A-party MDN. If land-originated, contains A-party number.
If A-party type is FORWARD, contains the original A-party
MDN (if A-party is a mobile) or number (if A-party is a land
line).
icprn 428 bytes 33 bytes digits Immediate calling party number or redirect number. If
A-party type is FORWARD, contains the number of the
party that either called or was redirected to the A-party
number. If not, contains the redirect number.
last_interim 461 bytes 4 bytes time (integer) last interim time - indicates timestamp when the last
intermediary CDR was created for this call. For example,
three CDRs are created for the same call. The first CDR's
disconnect code is INTERMEDIARY_RECORD and
last_interim is 0. The second CDR's disconnect code is
INTERMEDIARY_RECORD and last_interim is the first CDR's
creation time. The last CDR's disconnect code is normal
disconnect code and last_interim is the second CDR's
creation time.
a_transfer_ti 465 bytes 4 bytes time (integer) a_transfer_time indicates when the A party explicitly
me requests call transfer.
b_transfer_ti 469 bytes 4 bytes time (integer) b_transfer_time - indicates when the B party explicitly
me requests call transfer.
[filler] 473 bytes 35 bytes N/A N/A
[checksum] 508 bytes 4 bytes n/a n/a
CDR Disconnect Codes Table 21 lists the CDR disconnect codes with integer values in parentheses.
Table 21 CDR Disconnect Codes
Disconnect Code Description

NO_ANSWER (1) The call could not be completed because the
B-Party did not answer within the allocated
time.
B_PARTY_BUSY (2) The call could not be completed because the
B-Party was busy and did not have call
forward immediate, call forward on busy, or
call waiting enabled.
NO_PAGE_RESP (3) The call could not be completed because the
called mobile was either turned off or not in
the serving area.
BAD_DIGITS (4) The call could not be completed because the
dialed digits specified in the translation entry
did not match any pattern in digit
translations.
UNKNOWN_MOBILE (5) The call could not be completed because the
A-Party dialed an unassigned number within
the MSC's DN blocks.
VACANT_CODE (6) The call could not be completed because the
A-Party dialed an unassigned number that
routed to land.
B_PARTY_DENIED (8) The call could not be completed because of a
restriction on the B-Party.
NO_CIRCUITS (9) The call could not be completed because
there were no circuits available.
EQUIPMENT_FAIL (10) The call could not be completed because of
an equipment failure that could not be
circumvented by re-routing or a call in
progress was disconnected because the
equipment carrying the call failed.
A_PARTY_SAT_LOSS (11) The call was disconnected because the MSC
could no longer detect SAT from the A-Party
mobile during conversation.
B_PARTY_SAT_LOSS (12) The call was disconnected because the MSC
could no longer detect SAT from the B-Party
mobile during conversation.
A_PARTY_HANDOFF_FAIL (13) The call was disconnected because handoff
involving the A-Party failed.
B_PARTY_HANDOFF_FAIL (14) The call was disconnected because handoff
involving the B-Party failed.
MISHANDLED (15) The call could not be completed or was
disconnected because of internal
mishandling of the call by the MSC.


NO_VOICE_CHANNELS (18) The call could not be completed because
there were no RF voice channels available.
SETUP_SAT_LOSS (19) The call could not be completed because the
MSC lost SAT from a mobile before
conversation began.
MOB_BELOW_DISC_THRESH (24) The call was disconnected because the signal
strength from the mobile was too low to
maintain reasonable voice quality.
ALERT_FAIL (25) The call could not be completed because a
mobile was alerted but did not respond
(alerting causes the mobile to ring).
SIGNALING_FAILURE (26) The call could not be completed because the
MSC detected an error during Channel
Associated Signaling (CAS), indicating an
incompatibility between the MSC and the
PSTN.
INTERNAL_ROUTING_FAILURE (27) The call could not be completed because of
an inconsistency in the MSC routing tables
(trans, route, cs, group).
CONGESTION (28) The call could not be completed because of
facility shortage within the switching
network.
INTERNAL_RESOURCE_SHORTAGE (50) The call could not be completed because an
internal resource required to complete the
call was not available.
CLONE_ORIGINATION (51) The call could not be completed because
mobile origination had the same MIN and
ESN as a mobile that was already in a call.
DATABASE_ERROR (52) The call could not be completed because of a
database inconsistency within the MSC.
TRANSLATE_LIMIT (53) The call could not be completed because the
dialed digits were passed through the
translation table too many times. This may
indicate a translation configuration problem.
PROTOCOL_FAILURE (54) The call could not be completed because of a
protocol error. This is used in an
SMS_RECORD to indicate general failure.
RESOURCE_SHORTAGE (55) The call could not be completed because a
required network resource was temporarily
unavailable.
NETWORK_CALL_FAIL (56) The call could not be completed because a
required resource (database access, network
element, etc.) was not accessible due to a
failure. Operator intervention may be
required for resolution.
MISROUTED_LNP_CALL (57) For future enhancement.
BEARER_SERVICE_UNAVAILABLE (58) For future enhancement.

TELESERVICE_UNAVAILABLE (59) For future enhancement.
DELINQUENT_ACCOUNT (101) The call could not be completed because the
originating mobile had an account status of
delinquent_account.
FEATURE_DENIED (102) The feature access failed because the
subscriber attempted to enable a disallowed
vertical service feature.
TOLL_DENIED (103) The call could not be completed because the
originating mobile has its origination
indicator set to not allow toll calls (e.g.
local_only).
ORIGINATIONS_DENIED (104) The call could not be completed because the
subscriber attempted to originate a call
without the required service feature.
UNKNOWN_SUB_ORIGINATION (106) The call could not be completed because an
unregistered roamer attempted to make a
call.
BAD_ESN (107) The call could not be completed because the
terminating mobiles serial number (ESN) did
not match its station identification (MIN).
INTERNATIONAL_DENIED (108) The call could not be completed because the
originating mobile has its origination
indicator set to not allow international calls
(e.g.. local_only, npa_nxx).
CFWD_LIMIT_EXCEEDED (109) The call could not be completed because the
number of forwards exceeded system limit.
BANDIT_MOBILE (111) The call could not be completed because a
mobile recognized as a bandit (MIN and ESN
do match) attempted to make a call.
FEATURE_CONFIRMATION (112) The feature access succeeded. A mobile
successfully enabled or disabled a vertical
feature.
AUTHENTICATION_FAILURE (113) The call could not proceed because the
authentication procedure failed to
authenticate a mobile.
CALL_BARRED (114) The call could not be completed because
either it met a barring condition set by
subscriber or for operator reasons.
ROAMING_BARRED (115) The call could not proceed because a
roaming is barred for a mobile.
UNKNOWN_LOCATION_AREA (116) The call could not proceed because a target
location area was not known in the VLR
(Visitor Location Register).
FEATURE_FAILED (150) The feature access failed because the
subscriber dialed invalid feature access
digits.


MOBILE_INACTIVE (151) The call could not be completed because the
terminating mobile was not registered in the
VLR (Visitor Location Register).
MOBILE_UNAVAILABLE (152) The call could not be completed because the
terminating mobile could not be accessed
(e.g. Call delivery is disabled and call
forwarding is not set).
STOLEN_UNIT (153) The call could not be completed because the
mobile was blacklisted (e.g. illegal).
SUBSCRIBER_DISABLED (154) The call could not be completed because
subscriber was disabled.
A_PARTY_NORMAL_DISC (201) The call was disconnected because the
A-Party went on-hook after the call was
answered. This is used in an SMS_RECORD to
indicate success.
B_PARTY_NORMAL_DISC (202) The call was disconnected because the
B-Party went on-hook after the call was
answered.
A_PARTY_ABORT (203) The call could not be completed because the
A-Party went on-hook before the B-Party
answered.
FORCED_DISC (204) The call was disconnected because system
personnel forced the call to disconnect.
LONG_CALL_TIMEOUT (205) The call was disconnected because it was
connected longer than the system allows.
B_PARTY_ABORT (206) The call was disconnected because the
B-Party rejected the call before it was
answered.
TRANSFER (250) The call was forwarded to another
mobile/land number. Another CDR
corresponding to the forwarded leg of the
call follows.
INTERMEDIARY_RECORD (252) The CDR is created due to intermediary cdr
timer expired. The Call is still in progress.
USER_DEFINED_1 (300) This disconnect code as well as all other
USER_DEFINED disconnect codes
correspond to USER_DEFINED treatment
values entered into the trans database table.
For example, an entry of:
Class:7 Pattern: *77 Route:
trm_user_defined_1
in the translation table causes the call to end
with a disconnect code of USER_DEFINED_1.
USER_DEFINED_2 (301) Same as USER_DEFINED_1.
XML CDR Format 78

C Language Structure The following is the C data structure definition for a CDR record. The disk copy is
identical to this:
#define CDR_DIGITS_LEN 32
#define CDR_NUM_LEN 16
struct cdr_record_t
{
long version;
unsigned long seq_num;
long type;
char a_party_num[CDR_DIGITS_LEN + 1];
char b_party_num[CDR_DIGITS_LEN + 1];
long a_party_type;
long b_party_type;
char a_party_digits[CDR_DIGITS_LEN + 1];
char b_party_digits[CDR_DIGITS_LEN + 1];
long a_party_trunk;
long b_party_trunk;
long seize_time;
long answer_time;
long disc_time;
long disc_code;
long disc_reason;
long msc_id;
char orig_esn[CDR_NUM_LEN + 1];
char term_esn[CDR_NUM_LEN + 1];
long cell_id;
long a_feature_bits;
long b_feature_bits;
char o_msisdn[CDR_NUM_LEN + 1];
char t_msisdn[CDR_NUM_LEN + 1];
char o_exchange[CDR_NUM_LEN + 1];
char t_exchange[CDR_NUM_LEN + 1];
unsigned short o_market_id;
unsigned char o_switch_num;
unsigned long o_billing_id;
unsigned short t_market_id;
unsigned char t_switch_num;
unsigned long t_billing_id;
char o_billing_digits[CDR_DIGITS_LEN + 1];
char t_billing_digits[CDR_DIGITS_LEN + 1];
unsigned short a_party_trkgrp;
unsigned short b_party_trkgrp;
unsigned short o_serviceid;
unsigned short t_serviceid;
unsigned char crg_charge_info;
char ocpn[CDR_DIGITS_LEN + 1];
char icprn [CDR_DIGITS_LEN + 1];
char filler [47];
unsigned long checksum;
};
XML CDR Format CDRs in XML format are generated at the OMC and are intended for upload to
third-party billing applications.

XML CDR Tag Description Table 22 describes the tags used in the XML CDR format.
Table 22 XML Tag Descriptions
XML Tag Description

Telos_CDRS The root element of an XML-formatted CDR file.
CDRecord Starts a new CDR record.
version String representation of version field (integer).
seq_num String representation of seq_num field (integer).
record_type String representation of type field (integer). Allowable values are 1
and 2.
a_party_num String representation of a_party_num field (number).
b_party_num String representation of b_party_num field (number).
a_party_type String representation of a_party_type field (the integer part of
party-type).
b_party_type String representation of a_party_type field (the integer part of
party-type).
a_party_digits String representation of a_party_digits field (digits).
b_party_digits String representation of a_party_digits field (digits).
a_party_trunk String representation of a_party_trunk (trunk).
b_party_trunk String representation of b_party_trunk (trunk).
a_party_trkgrp String representation of a_party_trkgrp (trunk).
b_party_trkgrp String representation of b_party_trkgrp (trunk).
seize GMT time string representation of seize_time field (time), e.g.
2006-08-05T20:19:24Z.
answer GMT time string representation of answer_time field (time), e.g.
2004-08-05T20:19:24Z.
disc GMT time string representation of disc_time field (time), e.g.
2004-08-05T20:19:24Z.
disc_code String representation of the disc_code field (integer).
disc_reason String representation of the disc_reason field (integer).
msc_id String representation of the msc_id field (integer).
orig_esn String representation of the orig_esn field (number).
term_esn String representation of the term_esn field (number).
b_cell_id Optional. It appears only if the b_cell_id in cdr_config database is
set to 1 and the call is mobile terminated voice call. The value is the
string representation of the highest 16 bits of cell_id and is the
mobile termination cell id.
cell_id String representation of the lowest 16 bits of cell_id field (integer). If
it is a voice call, it is the mobile origination cell id.
a_feature_bits Concatenation of the feature names of the a_feature_bits field
separated by a space, e.g. CW JOIN HOLD.
b_feature_bits Concatenation of the feature names of the b_feature_bits field
separated by a space, e.g. CW JOIN HOLD.
o_msisdn String representation of the o_msisdn field (number).
XML CDR Format 80
Table 22 XML Tag Descriptions
XML Tag Description

t_msisdn String representation of the t_msisdn field (number).
o_exchange String representation of the o_exchange field (number).
t_exchange String representation of the t_exchange field (number).
o_market_id Value of o_market_id.
o_swno Value of o_switch_num.
o_bin Value of o_billing_id.
t_market_id Value of t_market_id.
t_swno Value of t_switch_num.
t_bin Value of t_billing_id.
o_billdgts String representation of o_billing_digits.
t_billdgts String representation of t_billing_digits.
o_serviceid String representation of o_serviceid.
t_serviceid String representation of t_serviceid.
crg_charge_info String representation of crg_charge_info.
ocpn String representation of ocpn.
icprn String representation of icprn.
last_interim GMR timer string representation of last_interim (time). e.g.
2007-08-05T20:19:24Z. Empty if no intermediary CDR is created
before for this call.
a_transfer_time GMT time string representation of a_transfer_time field (time), e.g.
2007-08-05T20:19:24Z. The value is empty if no a transfer happens.
b_transfer_time GMT time string representation of b_transfer_time field (time), e.g.
2007-08-05T20:19:24Z. The value is empty if no b transfer happens.
XML CDR Examples Figure 33 describes an XML CDR generated for a voice call.

Figure 33 Example: Voice CDR in XML

<Telos_CDRS>
<CDRecord>
<version>11</version>
<seq_num>3950</seq_num>
<record_type>3</record_type>
<a_party_num>001010000000020</a_party_num>
<b_party_num>001010000000019</b_party_num>
<a_party_type>1</a_party_type>
<b_party_type>1</b_party_type>
<a_party_digits>4021</a_party_digits>
<b_party_digits>4040000</b_party_digits>
<a_party_trunk>12000</a_party_trunk>
<b_party_trunk>12001</b_party_trunk>
<a_party_trkgrp>12</a_party_trkgrp>
<b_party_trkgrp>12</b_party_trkgrp>
<seize>2002-08-05T20:19:15Z</seize>
<answer>2002-08-05T20:19:24Z</answer>
<disc>2002-08-05T20:19:46Z</disc>
<disc_code>201</disc_code>
<disc_reason>0</disc_reason>
<msc_id>1</msc_id>
<orig_esn>0</orig_esn>
<term_esn/>
<b_cell_id>3</b_cell_id>
<cell_id>4</cell_id>
<a_feature_bits>CLIR</a_feature_bits>
<b_feature_bits>Normal</b_feature_bits>
<o_msisdn>4020</o_msisdn>
<t_msisdn>4021</t_msisdn>
<o_exchange/>
<t_exchange/>
<o_market_id>12</o_market_id>
<o_swno>1</o_swno>
<o_bin>18</o_bin>
<t_market_id>12</t_market_id>
<t_swno>1</t_swno>
<t_bin>19</t_swno>
<o_billdgts></o_billdgts>
<t_billdgts></t_billdgts>
<o_serviceid></o_serviceid>
<t_serviceid></t_serviceid>
<crg_charge_info>0</crg_charge_info>
<ocpn>4020</ocpn>
<icprn></icprn>
<last_interim></last_interim>
<a_transfer_time></a_transfer_time>
<b_transfer_time></b_transfer_time>
Figure 34 describes an XML CDR generated for an SMS call.
ASCII CDR Format 82
Figure 34 Example: SMS CDR in XML
<CDRecord>
<version>11</version>
<seq_num>621</seq_num>
<record_type>4</record_type>
<a_party_num>274040199000001</a_party_num>
<b_party_num>3108012345680</b_party_num>
<a_party_type>1</a_party_type>
<b_party_type>0</b_party_type>
<a_party_digits>4001</a_party_digits>
<b_party_digits />
<a_party_trunk>1</a_party_trunk>
<b_party_trunk>0</b_party_trunk>
<a_party_trkgrp>0</a_party_trkgrp>
<b_party_trkgrp>0</b_party_trkgrp>
<seize>2004-02-02T17:20:07Z</seize>
<answer>2004-02-02T17:20:07Z</answer>
<disc>2004-02-02T17:20:07Z</disc>
<disc_code>201</disc_code>
<disc_reason>0</disc_reason>
<msc_id>1</msc_id>
<orig_esn>0</orig_esn>
<term_esn>0</term_esn>
<cell_id>1</cell_id>
<a_feature_bits>Normal</a_feature_bits>
<b_feature_bits>Normal</b_feature_bits>
<o_msisdn/>
<t_msisdn/>
<o_exchange/>
<t_exchange/>
<o_market_id>12</o_market_id>
<o_swno>1</o_swno>
<o_bin>18</o_bin>
<t_market_id>12</t_market_id>
<t_swno>1</t_swno>
<t_bin>19</t_swno>
<o_billdgts></o_billdgts>
<t_billdgts></t_billdgts>
<o_serviceid></o_serviceid>
<t_serviceid></t_serviceid>
<crg_charge_info>0</crg_charge_info>
<ocpn></ocpn>
<icprn></icprn>
<last_interim></last_interim>
<a_transfer_time></a_transfer_time>
<b_transfer_time></b_transfer_time>
</CDRecord>
ASCII CDR Format View the CDR in ASCII format either using the MSC Log Viewer or by using
cdr_reporter to convert the binary file into ASCII (do this from the MSC
command line).
This section includes:

Mobile-Originated Voice Scenarios
Land-Originated Voice Scenarios
In-Call Feature Scenarios
Short Message Service Scenarios

Mobile-Originated Voice The following scenarios are included in this section:

Scenarios
Land-Terminated
Mobile-Terminated (Local MSC is Serving MSC)
Mobile-Terminated Mobile (Unconditional Forwarding)
Land-Terminated
The mobile A party (MIN=6191234530) dialed a number (digits=80268) to
originate a call to a land B party (See Figure 35):
Trunk 1024 was from the radio interface.
Trunk 12000 was to the PSTN.
The call was released by the B party.
Figure 35 Example: Land Terminated

A:6191234530 type:MOBILE digits:80268 trunk:1024 ESN:0 cell:17
B: type:LAND digits:268 trunk:12000 ESN: cell:0
Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Wed Oct 27 16:34:24 2004
Answered: Wed Oct 27 16:34:31 2004
Disconnected: Wed Oct 27 16:34:52 2004
Disc code: B_PARTY_NORMAL_DISC
Sequence: 373
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 18
Term Market ID 0
Term Switch Num: 0
Term Billing ID 0
Orig Billing Digits: <As billing digits or NULL>
Term Billing Digits:
A Trunk Group: 1
B Trunk Group: 12
Orig DMH Service ID: 0
Term DMH Service ID: 0
Imm Cllg Pty|Rdrct #:
Last Interim Time:
A Transfer Time:
B Transfer Time:
Mobile-Terminated (Local MSC is Serving MSC)

The mobile A party (MIN = 6191234530) dialed a number (digits=634502) to
originate a call to a mobile B party:
The TLDN on the local VLR/MSC was 1201.
Both trunk 1026 and trunk 1027 were from/to the radio interface.
The call was released by the Bparty.
See Figure 36.
ASCII CDR Format 84
Figure 36 Example: Mobile Terminated (Local MSC is Serving MSC)

B:6191234502 type:MOBILE digits:1201 trunk:1027 ESN: cell:17
A Feature Bits:
B Feature Bits:
Seized: Wed Oct 27 16:41:35 2004
Sequence: 375
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 19
Term Market ID 12
Term Switch Num: 1
Term Billing ID 20
Term Billing Digits: <Bs billing digits or NULL>
A Trunk Group: 1
B Trunk Group: 1
Last Interim Time:
A Transfer Time:
B Transfer Time:
Mobile-Terminated (Serving MSC is a Different MSC)

originate a call to mobile B party (See Figure 37 and Figure 38):
Mobile B party was roaming in remote VLR/MSC.
The TLDN on remote VLR/MSC was 4001.
Trunk 1029 was from radio interface.
Trunk 17001 was to PSTN.
The call was released by B party.

Figure 37 Example: Mobile Terminated (Serving MSC is Different MSC)

A Feature Bits:
B Feature Bits:
Seized: Wed Oct 27 17:10:22 2004
Sequence: 379
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 20
Term Market ID 12
Term Switch Num: 2
Term Billing ID 27
A Trunk Group: 1
B Trunk Group: 17
Last Interim Time:
A Transfer Time:
B Transfer Time:
Figure 38 Example: Record from Second MSC

A:634530 type:LAND digits:4001 trunk:10002 ESN:0 cell:0
Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Wed Oct 27 16:57:52 2004
Sequence: 127906
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 20
Term Market ID 12
Term Switch Num: 2
Term Billing ID 27
Orig Billing Digits:
A Trunk Group: 10
B Trunk Group: 92
Last Interim Time:
A Transfer Time:
B Transfer Time:
ASCII CDR Format 86
Mobile-Terminated Mobile (Unconditional Forwarding)

originate a call to mobile B party. Mobile B party (MIN=6191234530) had CFU
(Unconditional Forwarding) activated to a number (digits=734525) which is
served by a second MSC (See Figure 39 and Figure 40):
The TLDN is 4002.
Trunk 1003 was from radio interface.
The call was released by A party.
Figure 39 Example: Mobile Terminated (Unconditional Forwarding)

A Feature Bits:
B Feature Bits: CFU
Seized: Thu Oct 28 11:37:21 2004
Answered: Thu Oct 28 11:37:27 2004
Disconnected: Thu Oct 28 11:37:30 2004
Disc code: TRANSFER
Sequence: 441
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 38
Term Market ID 12
Term Switch Num: 1
Term Billing ID 39
A Trunk Group: 1
B Trunk Group: 0
Orig Calling Party No: 634501
Last Interim Time:
A Transfer Time:
B Transfer Time:

A:6191234530 type:FORWARD digits:734525 trunk:1003 ESN: cell:0

A Feature Bits:
B Feature Bits:
Seized: Thu Oct 28 11:37:21 2004
Sequence: 442
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 39
Term Market ID 12
Term Switch Num: 2
Term Billing ID 28
Orig Billing Digits: <Bs billing digits or NULL>
Term Billing Digits: <forwarded mobiles billing digits or NULL>
A Trunk Group: 1
B Trunk Group: 17
Imm Cllg Pty|Rdrct #: 634501
Last Interim Time:
A Transfer Time:
B Transfer Time:
Figure 40 Example: Record from Second MSC

Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Thu Oct 28 11:24:50 2004
Sequence: 127914
MscId: 2
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 39
Term Market ID 12
Term Switch Num: 2
Term Billing ID 28
Term Billing Digits: <forwarded mobiles billing digits or NULL>
A Trunk Group: 10
B Trunk Group: 92
Last Interim Time:
A Transfer Time:
B Transfer Time:
ASCII CDR Format 88
Land-Originated Voice The following scenarios are included in this section:

Scenarios
Land-Terminated
Mobile-Terminated Land (TLDN on Local MSC/VLR)
Mobile-Terminated Land (TLDN on Remote MSC/VLR)
Example (cont.): Record from Second MSC
Land-Terminated
The land A party dialed a number (digits=38830) to originate a call to land B party
(see Figure 41):
The digits were translated to a different number (digits=35430) and
terminated to land B party (VMS).
Trunk 21025 was from PSTN.
Trunk 3017 was to VMS.
Figure 41 Example: Land Terminated

A: type:LAND digits:38830 trunk:21025 ESN:0 cell:0
Originating MSISDN:
Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Thu Jan 2 01:15:12 2003
Answered: Thu Jan 2 01:15:28 2003
Disconnected: Thu Jan 2 01:16:51 2003
Sequence: 11940
MscId: 1
Orig Market ID: 0
Orig Switch Num: 0
Orig Billing ID 0
Term Market ID 0
Term Switch Num: 0
Term Billing ID 0
A Trunk Group: 21
B Trunk Group: 3
Last Interim Time:
A Transfer Time:
B Transfer Time:
Mobile-Terminated Land (TLDN on Local MSC/VLR)

The land A party (ANI=268) dialed a number (digits=634530) to originate a call to
mobile B party (MIN=6191234530) (See Figure 42):
The TLDN on local VLR/MSC was 1200.
Trunk 1025 was to radio interface.

Figure 42 Example: Mobile Terminated (TLDN on Local MSC/VLR)

A Feature Bits:
B Feature Bits:
Seized: Wed Oct 27 16:38:58 2004
Sequence: 374
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 48
Term Market ID 12
Term Switch Num: 1
Term Billing ID 49
A Trunk Group: 12
B Trunk Group: 1
Last Interim Time:
A Transfer Time:
B Transfer Time:
Mobile-Terminated Land (TLDN on Remote MSC/VLR)

The land A party (no ANI) dialed a number (digits=734525) to originate a call to
mobile B party (See Figure 43).
The TLDN on remote VLR/MSC was 4000.

Both trunk 12015 and trunk 17000 were from/to PSTN.
The call was released by the A party.
ASCII CDR Format 90
Figure 43 Example: Mobile Terminated (TLDN on Remote MSC / VLR)

A Feature Bits:
B Feature Bits:
Seized: Wed Oct 27 17:05:25 2004
Sequence: 378
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 50
Term Market ID 12
Term Switch Num: 2
Term Billing ID 48
A Trunk Group: 12
B Trunk Group: 17
Last Interim Time:
A Transfer Time:
B Transfer Time:
Figure 44 Example (cont.): Record from Second MSC

Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Wed Oct 27 16:52:56 2004
Sequence: 127905
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 50
Term Market ID 12
Term Switch Num: 2
Term Billing ID 48
A Trunk Group: 10
B Trunk Group: 92
Last Interim Time:
A Transfer Time:
B Transfer Time:

Mobile-Terminated Land (Unconditional Forwarding)

Land A party (578) dialed a number (digits=634530) to mobile B party. B party
(MIN=6191234530) had CFU (Unconditional Forwarding) activated to a mobile
number (digits=734525), served by another MSC (see Figure 45):
The call was released by the A party.
Figure 45 Example: Mobile Terminated (Unconditional Forwarding)

B: 6191234530 type:MOBILE digits:734525 trunk:0 ESN: cell:0
Originating MSISDN:
Terminating MSISDN: 634530
A Feature Bits:
B Feature Bits: CFU
Seized: Thu Jan 2 09:49:25 2003
Disc code: TRANSFER
Sequence: 11955
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 48
Term Market ID 12
Term Switch Num: 1
Term Billing ID 49
A Trunk Group: 12
B Trunk Group: 0
Last Interim Time:
A Transfer Time:
B Transfer Time:
ASCII CDR Format 92
A: 6191234530 type:FORWARD digits:734525 trunk:12015 ESN: cell:0

B: type:LAND digits:4002 trunk:17001 ESN: cell: 0
Originating MSISDN: 634530
Terminating MSISDN: 734525
A Feature Bits:
B Feature Bits:
Seized: Thu Jan 2 09:49:25 2003
Sequence: 11956
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID 49
Term Market ID 12
Term Switch Num: 2
Term Billing ID 38
Orig Billing Digits: <Bs billing digits>
Term Billing Digits: <forwarded mobiles billing digits>
A Trunk Group: 12
B Trunk Group: 17
Imm Cllg Pty|Rdrct #: 578
Last Interim Time:
A Transfer Time:
B Transfer Time:
In-Call Feature Scenarios The following scenarios are included in this section:
Forwarding
Call Waiting
Three-Way Call
Some of these calls produce multiple Call Detail Records, as shown in the
examples.
Forwarding
See Mobile-Terminated Mobile (Unconditional Forwarding) and Example (cont.):
Record from Second MSC as well as Multiple Call Forwarding (below).
Multiple Call Forwarding

Mobile A (MIN = 6191234514, DN = 4564) called B (MIN = 7191235581, DN =
4581) who forwarded to C (MIN = 7191235582, DN = 4582). C then forwarded to
D (MIN = 7191234590, DN = 4590) served by another MSC. D forwarded to E
(MIN = 7191234595, DN = 4595) and then E to a Land Party F (digits = 4002372
244). The call finally terminates at F. The Inter-MSC communications use SIP
trunking. (See Figure 46 to Figure 51.)

Figure 46 Example: Multiple Call Forward, First MSC, A Calls B

A:6191234514 type:MOBILE digits:4581 trunk:14000 ESN:0x2ae68b12 cell:17
B:7191235581 type:MOBILE digits:4582 trunk:0 ESN:0x2ad220b9 cell:0
A Feature Bits: CLIR
B Feature Bits: CFU
Seized: Tue Apr 11 14:51:11 2006
Answered: Tue Apr 11 14:51:21 2006
Disconnected: Tue Apr 11 14:51:36 2006
Disc code: TRANSFER
Sequence: 138
MscId: 3
Orig Market ID: 12
Orig Switch Num: 9
Orig Billing ID: 12
Term Market ID: 12
Term Switch Num: 9
Term Billing ID: 13
Orig Billing Digits: 4564
A Trunk Group: 1
B Trunk Group: 0
CRG Charge Info: 0
Last Interim Time:
A Transfer Time:
B Transfer Time:
Figure 47 Example: Multiple Call Forward, First MSC, B Forwards to C

A:7191235581 type:FORWARD digits:4582 trunk:14000 ESN:0x2ad220b9 cell:0
B:7191235582 type:MOBILE digits:4002370190 trunk:0 ESN:0x2ad220ba cell:0
A Feature Bits:
B Feature Bits: CFU
Seized: Tue Apr 11 14:51:11 2006
Disc code: TRANSFER
Sequence: 139
MscId: 3
Orig Market ID: 12
Orig Switch Num: 9
Orig Billing ID: 13
Term Market ID: 12
Term Switch Num: 9
Term Billing ID: 14
A Trunk Group: 1
B Trunk Group: 0
CRG Charge Info: 0
Imm Cllg Pty|Rdrct#: 4564
...
ASCII CDR Format 94
Figure 48 Example: Multiple Call Forward, First MSC, C Forwards to D

A:7191235582 type:FORWARD digits:4002370190 trunk:14000 ESN:0x2ad220ba
cell:0
B: type:SIP digits:4002370190 trunk:7003 ESN: cell:0
Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Tue Apr 11 14:51:11 2006
Sequence: 140
MscId: 3
Orig Market ID: 12
Orig Switch Num: 9
Orig Billing ID: 14
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 80
CRG Charge Info: 0
...
Figure 49 Example: Multiple Call Forward, Second MSC, C Forwards to D

cell:0
Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Tue Apr 11 14:51:11 2006
Sequence: 140
MscId: 3
Orig Market ID: 12
Orig Switch Num: 9
Orig Billing ID: 14
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 80
CRG Charge Info: 0
...

Figure 50 Example: Multiple Call Forward, Second MSC, D Forwards to E

cell:0
Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Tue Apr 11 14:51:11 2006
Sequence: 140
MscId: 3
Orig Market ID: 12
Orig Switch Num: 9
Orig Billing ID: 14
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 80
CRG Charge Info: 0
...
Figure 51 Example: Multiple Call Forward, Second MSC, E Forwards to F

cell:0
Terminating MSISDN:
A Feature Bits:
B Feature Bits:
Seized: Tue Apr 11 14:51:11 2006
Sequence: 140
MscId: 3
Orig Market ID: 12
Orig Switch Num: 9
Orig Billing ID: 14
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 80
CRG Charge Info: 0
...
ASCII CDR Format 96
Call Waiting
In the following example, a mobile (MIN=6191234599) calls land 208. Land 207
called the mobile and the mobile is in call waiting stage. The mobile toggles
around and land 207 releases first. Then land 208 releases. (See Figure 52 and
Figure 53.)
Figure 52 Example: Call Waiting - Original Call

B:6191234599 type:CALLWAITING digits:1236 trunk:1004 ESN: cell:17
Originating MSISDN:
A Feature Bits:
B Feature Bits: RETRIEVE HOLD CW
Seized: Thu Dec 2 17:24:21 2004
Answered: Thu Dec 2 17:24:30 2004
Disconnected: Thu Dec 2 17:24:56 2004
Sequence: 1932
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID: 58
Term Market ID: 12
Term Switch Num: 1
Term Billing ID: 59
A Trunk Group: 14
B Trunk Group: 1
Last Interim Time:
A Transfer Time:
B Transfer Time:

Figure 53 Example: Call Waiting - Call Waiting Call

Terminating MSISDN:
A Feature Bits: RETRIEVE HOLD
B Feature Bits:
Seized: Thu Dec 2 17:24:07 2004
Answered: Thu Dec 2 17:24:09 2004
Disconnected: Thu Dec 2 17:25:13 2004
Sequence: 1933
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID: 59
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 14
Last Interim Time:
A Transfer Time:
B Transfer Time:
Three-Way Call
In a three-way call, the controlling party on the first leg is set to FEATURE and on
the second leg the A party type is set to THREEWAYCALL.
In the first call, the A party (MIN=6191234507) puts the call on hold and
originates the second call to another B party (MIN=6191234519). After
establishing the second call, the A party joins two calls into a mutual three-way
conversation. (See Figure 54 and Figure 55.)
ASCII CDR Format 98
Figure 54 Example: 3-Way Call (First Part)

A:6191234507 type:FEATURE digits:450014 trunk:1002 ESN:0 cell:17
A Feature Bits: JOIN HOLD
Seized: Mon Nov 29 10:53:39 2004
Answered: Mon Nov 29 10:53:44 2004
Disconnected: Mon Nov 29 10:55:46 2004
Sequence: 3003
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID: 69
Term Market ID: 12
Term Switch Num: 1
Term Billing ID: 70
A Trunk Group: 1
B Trunk Group: 1
Last Interim Time:
A Transfer Time:
B Transfer Time:
Figure 55 Example: 3-Way Call (Second Part)

A:6191234507 type:THREEWAYCALL digits:450019 trunk:1002 ESN:0 cell:17
A Feature Bits:
Seized: Mon Nov 29 10:54:28 2004
Answered: Mon Nov 29 10:54:33 2004
Disconnected: Mon Nov 29 10:55:46 2004
Sequence: 3004
MscId: 1
Orig Market ID: 12
Orig Switch Num: 1
Orig Billing ID: 69
Term Market ID: 12
Term Switch Num: 1
Term Billing ID: 71
Term Billing Digits: <new Bs billing digits or NULL>
A Trunk Group: 1
B Trunk Group: 1
Last Interim Time:
A Transfer Time:
B Transfer Time:

Call Transfer
The CDR requirements related to Call Transfer feature are specified by
TIA/EIA/664-506.
The MSC generates two CDRs for a transferred call. The first CDR is for the initial
call to/from the first party to the controlling subscriber. The second CDR is for the
call from the controlling subscriber to the 3rd party.
The Call Transfer invoking party (that is involved in 2 calls) CDRs will include:
the ECT feature bit set
the transfer time: <time of call transfer invocation>
This allows:
Billing for airtime usage of the call transfer invoking party, on both calls, up to
the moment when it transfers the call.
Billing for transfer-to call leg usage of the call transfer invoking party, up to the
moment when the transferred call ends.
When interpreting the CDRs:

The seized time indicate the time when each call was originated.
The answered time indicates the time when each call was answered.
The disconnected time indicates the time when the transferred call was
released (in most cases it will be identical in both CDRs). (See Figure 56 to
Figure 59.)
ASCII CDR Format 100
Figure 56 Example: CT from Holding 2-way State, first CDR

A:7191235595 type:MOBILE digits:5591 trunk:2000 ESN:0x2a78a35d cell:17
B:7191235591 type:MOBILE digits:1234 trunk:2001 ESN:0x2a6169af cell:17
A Feature Bits:
B Feature Bits: HOLD CLIP ECT
Seized: Thu Jun 15 15:00:17 2006
Answered: Thu Jun 15 15:00:23 2006
Disconnected: Thu Jun 15 15:01:21 2006
Sequence: 8543
MscId: 1
Orig Market ID: 12
Orig Switch Num: 3
Orig Billing ID: 1
Term Market ID: 12
Term Switch Num: 3
Term Billing ID: 2
Term Billing Digits: 5591
A Trunk Group: 1
B Trunk Group: 1
CRG Charge Info: 0
A Transfer Time: Thu Jun 15 15:01:21 2006
B Transfer Time: Thu Jun 15 15:00:49 2006
Figure 57 Example: CT from Holding 2-way State, second CDR

A:7191235591 type:MOBILE digits:5597 trunk:2001 ESN:0x0 cell:17
B:7191235597 type:MOBILE digits:1235 trunk:2002 ESN:0x2a7970b6 cell:17
A Feature Bits: ECT
B Feature Bits:
Seized: Thu Jun 15 15:00:33 2006
Sequence: 8544
MscId: 1
Orig Market ID: 12
Orig Switch Num: 3
Orig Billing ID: 3
Term Market ID: 12
Term Switch Num: 3
Term Billing ID: 4
A Trunk Group: 1
B Trunk Group: 1
CRG Charge Info: 0

Figure 58 Example: CT from 3-way State, first CDR

A:7191235591 type:THREEWAYCALL digits:288 trunk:2003 ESN:0x2a6169af
cell:17
Terminating MSISDN:
A Feature Bits: ECT
B Feature Bits:
Seized: Thu Jun 15 16:20:56 2006
Sequence: 8564
MscId: 1
Orig Market ID: 12
Orig Switch Num: 3
Orig Billing ID: 36
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 14
CRG Charge Info: 0
Figure 59 Example: CT from 3-way State, second CDR

A:7191235591 type:FEATURE digits:598 trunk:2003 ESN:0x2a6169af cell:17
Terminating MSISDN:
A Feature Bits: JOIN HOLD ECT
B Feature Bits:
Seized: Thu Jun 15 16:20:44 2006
Sequence: 8565
MscId: 1
Orig Market ID: 12
Orig Switch Num: 3
Orig Billing ID: 35
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 14
CRG Charge Info: 0
PCO Calls The CDRs for three successful prepaid public call office (PCO) calls are shown in
Figure 60 to Figure 62.

Figure 60 Example: Prepaid PCO to Local Mobile with SCP Charge Rate ID
A:1084200035 type:MOBILE digits:598 trunk:2007 ESN:0x1d3490c3 cell:17
Terminating MSISDN:
A Feature Bits: WIN PCO DMHCHG
B Feature Bits:
Seized: Mon Feb 6 15:36:44 2006
Answered: Mon Feb 6 15:36:48 2006
Disconnected: Mon Feb 6 15:37:00 2006
Sequence: 7807
MscId: 1
Orig Market ID: 12
Orig Switch Num: 3
Orig Billing ID: 8
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 14
CRG charge Info: 1
Orig Calling pty No: 5593
Last Interim Time:
A Transfer Time:
B Transfer Time:
Figure 61 Example: Prepaid PCO Call to Land with CRG Charge Rate ID
A:1084200035 type:MOBILE digits:4002148888 trunk:2006 ESN:0x1d3490c3
cell:17
Terminating MSISDN:
A Feature Bits: WIN PCO CRG
B Feature Bits:
Seized: Fri Feb 10 11:53:57 2006
Answered: Fri Feb 10 11:53:58 2006
Disconnected: Fri Feb 10 11:54:19 2006
Sequence: 7904
MscId: 1
Orig Market ID: 12
Orig Switch Num: 3
Orig Billing ID: 31
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 10
CRG Charge Info: 3
Last Interim Time:
A Transfer Time:
B Transfer Time:

Figure 62 Example: Prepaid PCO to Land with Charge Rate in DMH Service ID, but ISUP
Message Indicates Free Call
A:1084200035 type:MOBILE digits:4002148888 trunk:2006 ESN:0x1d3490c3
cell:17
Terminating MSISDN:
A Feature Bits: WIN PCO
B Feature Bits:
Seized: Fri Feb 10 11:53:57 2006
Answered: Fri Feb 10 11:53:58 2006
Disconnected: Fri Feb 10 11:54:19 2006
Sequence: 7905
MscId: 1
Orig Market ID: 12
Orig Switch Num: 3
Orig Billing ID: 31
Term Market ID: 0
Term Switch Num: 0
Term Billing ID: 0
A Trunk Group: 1
B Trunk Group: 10
CRG Charge Info: 0
Last Interim Time:
A Transfer Time:
B Transfer Time:
Short Message Service This section includes the following scenarios:

Scenarios
Mobile-Originated SMS
Mobile-Terminated SMS
Mobile-Originated SMS
The A party (MIN=6191234501) with MDN=401201 originated an SMS from
cell=17. The B party digits 6191234513 with MDN=402336 are for the intended
mobile. One SMS CDR is generated. (See Figure 63.)
Figure 63 Example: Mobile Originated SMS

A:6191234501 type:MOBILE digits: reference:0 cell:17
B: type:OTHER digits: 402336
Originated: Fri Dec 10 14:33:58 2004
Disc reason: 0
Sequence: 1295
MscId: 1
Orig Market ID: 0
Orig Switch Num: 0
Orig Billing ID 0
Term Market ID 0
Term Switch Num: 0
Term Billing ID 0
Mobile-Terminated SMS
The A party (MIN=6191234501) with MDN=401201 originated an SMS from
cell=17. The B party digits 6191234513 with MDN=402336 are for the intended
mobile. One SMS CDR is generated. (See Figure 64.)
Figure 64 Example: Mobile Terminated SMS

A:6191234501 type:MOBILE digits: reference:0 cell:17
B: type:OTHER digits: 402336
Originated: Fri Dec 10 14:33:58 2004
Disc reason: 0
Sequence: 1295
MscId: 1
Orig Market ID: 0
Orig Switch Num: 0
Orig Billing ID 0
Term Market ID 0
Term Switch Num: 0
Term Billing ID 0

PERFORMANCE MANAGEMENT
6
This chapter describes Performance Management for the MSC, which includes
performance monitoring and data collection, performance analysis, and
performance management activities.

Performance Management on the MSC
Performance Analysis
Performance Management Performance data is continuously generated on the MSC and periodically sent to
on the MSC the OMC. OMC is used to view performance data and generate reports.
Prerequisite Refer to the Performance Monitoring and Management chapter of the Core Voice
Network Operations, Maintenance, and Provisioning Guide for information on
how to generate and manage performance reports.
MSC Statistics Collection Performance data is generated on the MSC and sent to the OMC using FTP. A
Model cron job sends the performance data to the OMC in 5 minute intervals, and the
reporting period (level of granularity) for reports and graphs is 5 minutes.
Performance data can also be gathered by a Network Management System

(NMS), as shown in Figure 65, but this is customer-specific and not detailed here.
This guide focuses on using the OMC to manage performance on the MSC.

109 Chapter 6: Performance Management
Figure 65 Performance Architecture
Performance statistics are generated and collected on the MSC. Detailed

descriptions of the performance statistics are listed in Table 23 and Table 24, but
Figure 66 provides a general graphical view of the performance statistics
collection points.
Figure 66 MSC Statistics Collection Points
Note that performance statistics for incoming calls and outgoing calls are
collected on ISUP trunks only.
Each performance graph has its own set of statistics collection points, and these
are detailed in the relevant graph sections.
Building a Short-Term Building a short-term performance history means using performance graphs
Performance History (24-hour reporting period) to assess the performance of the MSC and the
network. WSISYG graphs can be printed, but they cannot be exported, which
limits their use for later analysis.
Trunk Group Statistics 110
However, the graphs are useful for real-time (5-minute intervals) performance
data collection. Print graphs that exhibit unusual performance behavior for help
in troubleshooting the system.
Some graphs (like CPU Utilization) are generated as part of the Operator daily
tasks (see MSC Operator Tasks on page 22) and are an easy way to generate a
short-term history.
Use reports for building a short-term performance history. Reports can be

generated with the same performance data but the reporting interval for reports
is at the top of the hour (12:00, 13:00, 14:00, etc.). Save reports in ASCII format
for printing and archiving.
Building a Long-Term Graphs have no utility for building a long-term performance history, but reports
Performance History can be generated for any reporting interval. Building a long-term performance
history would include generating reports on a daily, weekly, and monthly period.
Saving these reports and then using a spreadsheet to analyze them further would
help create a performance history.
The All Statistics reports (see All Statistics Report) is especially useful for creating
a performance history.
A performance history helps in the troubleshooting and performance tuning of

the system. It allows for benchmarks to be established and the impact of any
network changes (hardware, software, network expansion, or configuration
changes) to be evaluated.
Trunk Group Statistics

Trunk Group Detail Report
Call Processing and Mobility Management Statistics
BSC Statistics
Trunk Group Statistics Trunk group statistics include trunk group summary and detail reports.
Trunk Group Summary Report The Trunk Group Summary report presents a summarized version of incoming
and outgoing circuit statistics for each trunk group. A detailed trunk group report
can also be generated (see Trunk Group Detail Report on page 112).
The Trunk Group counters (Incoming Attempts, Outgoing Attempts, Outgoing

Overflows) are collected on ISUP trunks only. Usage statistics (Incoming usage,
outgoing usage, Out of Service usage) are collected on all trunk groups.
The trunk group usages statistics are measured in seconds. The reports shows the
sum of all the seconds used by for each member of the trunk group. Usage
includes the trunk groups to the peer switch and the trunk groups to BSC. See
Table 24 for what is measured in a Trunk Group Summary report.

Figure 67 shows a sample Trunk Group Summary Report.

Figure 67 Trunk Group Summary Report
Table 23 lists the trunk group statistics that are derived from the performance
statistics.
Table 23 Derived Trunk Group Statistics
Derived Statistic Source Statistic

Incoming Attempts Land Orig Call Attempts, succIncSeizures
Outgoing Attempts Land Term Call Attempts, outBids
Outgoing Overflows Land Term Calls Overflow
Incoming Usage ansIncSeizureTraffic
Outgoing Usage ansOutSeizureTraffic
Out Of Service Usage Out Of Service
Trunk Group Statistics 112
Figure 68 shows the collection points for Trunk Group statistics.

Figure 68 Collection Points for Trunk Group Statistics
Trunk Group Detail Report The Trunk Group Detail Report provides a detailed view of the performance
counters generated on each trunk group.
Figure 69 shows a sample Trunk Group Detail Report.
Figure 69 Trunk Group Detail Report

Table 24 lists all the performance counters collected for the Trunk Group Detail
Report.
Table 24 Trunk Group Detail Report Fields

Land Orig Call Failures
Calls Mishandled
Calls Busy
Calls Vacant
Signaling Failure
Calls Abandoned
Calls No answer
Calls Congested
Failed with Unknown Cause
LongCall timeout
Incoming INAP Trigger
Land Orig Calls
Call attempts
Calls completed
Calls answered
Incoming Forwarded
Incoming Call Delivery
Land Term Call Failures
Calls Mishandled
Calls Overflow
Calls Busy
Calls Vacant
Calls Abandoned
Calls No Answer
LongCall Timeout
Outgoing INAP Trigger
Land Term Calls
Call Attempts
Calls Completed
Calls Effective
Outgoing Forwarded
Outgoing Call Delivery
Usage
LO Call Attempts
LO Calls Effective
LT Calls Attempts
LT Calls Effective
OOS
Call Processing and Mobility Management Statistics 114
Table 24 Trunk Group Detail Report Fields

Timeout
Short hold calls
The Trunk Group Detail Report provides the raw data (generated by the
performance counters) needed to make traffic engineering decisions and
performance tuning adjustments to the network.
Call Processing and Call Processing and Mobility Management graphs and reports include:
Mobility Management Emergency Calls
Statistics
HLR Interrogations
Inter MSC Handoff
Intra MSC Handoff
Mobile Originated Calls
Mobile Terminated Calls
Mean Call Time
Paging
SMS Statistics
All Statistics Report
See Table 23 and Table 24 for what is measured in Call Processing and Mobility
Management graphs and reports.
Emergency Calls The Emergency Calls graph displays the actual number of calls in the given
interval. The number of Emergency Call Attempts in itself does not provide any
information about performance, except that the number of calls should, over
time, begin to show a predictable pattern.
Generate Emergency Calls graphs to monitor the number of emergency calls in

real-time, 95-minute intervals). Generate Emergency Calls reports to create a
short-term performance history (daily, weekly) and a long-term history (monthly,
yearly).
Figure 70 shows a sample Emergency Calls graph.

Figure 70 Emergency Calls Graph
Performance Characteristics
A quick look at the graph can reveal any major discrepancies for emergency call
statistics. Further calculations are required to further enhance call performance.
To Calculate
Emergency Call Completion Rate
EmergencyCallAttempts -
------------------------------------------------------------------------------- 100
EmergencyCallsCompleted
Emergency Calls Answered Rate EmergencyCallsCompleted

-------------------------------------------------------------------------------- 100
EmergencyCallsAnswered
A low Emergency Call Completion Rate may indicate that the call attempts (MSC
has received call from BSS without blocking) are not connecting to the PSTN
(does not receive ACM message). Check the links from the MSC to the PSTN.
A low Emergency Calls Answered Rate may indicate that the emergency calls
have reached the PSTN but have not reached the Public Service Access Point
(PSAP). Check PSTN to PSAP links.
HLR Interrogations Figure 71 shows a sample HLR Interrogations graph.

Figure 71 HLR Interrogations Graph
Figure 72 Successful LocationRequest
Route Call Attempts is equivalent to the number of mobile terminated call

attempts. MIN Successes is equivalent to the number of mobile terminated calls
completed. FTN Successes is equivalent to the number of calls using Call
Forwarding (any variety). TLDN Successes is equivalent to the number of roams in
the system.
The LocationRequest (LOCREQ) operation is used by an Originating MSC to obtain

call treatment instructions from the HLR. The call is identified by the dialed
mobile address digits received by the Originating MSC.

Figure 73 Successful TransferToNumberRequest
Figure 74 Successful TLDN Returned
Inter MSC Handoff The FacilitiesDirective2 (FACDIR2) operation is used by the Anchor MSC,
the Serving MSC (or tandem MSC) to request that the Target MSC initiate the
Handoff-Forward task.
The MobileOnChannel operation is then used by the Target MSC to inform the
requesting system that the Target MSC has successfully completed the
Handoff-Forward task.
Figure 75 shows a sample Inter MSC Handoff graph.
Figure 75 Inter MSC Handoff Graph
Figure 76 shows the collection points for Inter MSC performance statistics.
Figure 76 Collection Points for Inter MSC Handoff Performance Statistics

Figure 77 shows the collection point for Handoff Out Completed (handoff
backward) call statistics and Figure 78 shows the collection point for handoff
forward.
Figure 77 Handoff Out Completed (Backward) Statistics Collection Point
Figure 78 Handoff Out Completed (Forward) Statistics Collection Point
Figure 79 shows the collection point for Handoff In Attempts (FACDIR) call
statistics.
Figure 79 Handoff In Attempts (FACDIR) Statistics Collection Point
Figure 80 Handoff In Attempts (HANDBACK) Statistics Collection Point

Intra MSC Handoff Figure 81 shows a sample Intra MSC Handoff graph.
Figure 81 Intra MSC Handoff Graph
Figure 82 shows the collection points for Intra MSC handoff performance
statistics.
Figure 82 Collection Points for Intra MSC Performance Statistics
Mobile Originated Calls Figure 83 shows a sample Mobile Originated Call graph.
Figure 83 Mobile Originated Calls Graph
Figure 84 shows the collection points for mobile originated call statistics.
Figure 84 Mobile Originated Call Statistic Collection Points

Mobile Terminated Calls Figure 85 shows a sample Mobile Terminated Calls graph.
Figure 85 Mobile Terminated Calls Graph
Figure 86 shows the collection points for mobile terminated call statistics.
Figure 86 Mobile Terminated Call Statistic Collection Points
Mean Call Time Time needed for all calls made in the 5-minute interval divided by the number of
calls. Time is shown in milliseconds.
Figure 87 shows a sample Mean Time graph.

Figure 87 Mean Time Graph
Figure 88 shows the interval for collecting mean time to Establish Calls, and
Figure 89 shows the interval for Location Update.
Figure 88 Mean Time to Establish Calls

Figure 89 Mean Time for Location Update
Paging
A Paging Request (BSMAP) message is sent from the MSC to the BSC to initiate
a mobile terminated call setup scenario (this message may also be sent for
location purposes).
The MSC determines that an incoming call (either land or mobile originated)
terminates to a MS within its serving region and initiates the paging procedure. It
starts a timer (T3113) and sends the Paging Request message to the BS, and
waits for the Paging Response message.
When the BSC receives the Paging Request message from the MSC, it
determines from which cell(s) to broadcast the page request. The page messages
are then distributed to the appropriate cell(s), which then broadcast the page
message over their paging channels.
If the Paging Response message is not received by the MSC before the timer
expires then the MSC may repeat the Paging Request message. No action is
taken at the BS on failure to receive a Paging Response from the MS.
A Paging Failure is recorded after 1 Paging Request retry, and the timer expires
(giving a total of 2 Paging Requests).
Figure 90 shows an example of a Paging graph.

Figure 90 Paging Graph
Figure 91 shows the collection point for paging statistics.

Figure 91 Collection Points for Paging Statistics
Performance Characteristics
The Paging graph shows the raw number of Paging Attempts, Paging Successes,
and Paging Failure.
The number of Paging Attempts is equivalent to the number of attempted Mobile

Terminated calls. The number of Paging Successes is equivalent to the number of
times a MS sent a Page Response Message (allows BSC to send Paging
Response to MSC). The number of Paging Failure is equivalent to the number of
times the MS did not send a Page Response Message (which means that an
unreachable MS will generate, at most, 2 Paging Failure before the MSC sends a
Termination Reject message).

A quick look at the graph can reveal any major discrepancies in paging statistics.
Further calculations are required to further determine system performance.
To Calculate
Page Success Rate (%)
PagingSuccesses
---------------------------------------------------- 100
PagingAttempts
Page Failure Rate (%)

PagingFailure -
---------------------------------------------- 100
PagingAttempts
A high Page Success Rate may indicate that mobiles are successfully receiving
pages for a Mobile Terminated call.
A high Page Failure Rate may indicate that mobiles are not receiving pages. Note
that the pages statistics are for all mobiles in the network (attached to this MSC)
and will reflect the general paging performance of the network. Page Failure rate
could be impacted by radio performance (like a BTS shadow, BTS out of service,
and MS is out of service).
SMS Statistics The Short Message Service (SMS) provides for the transfer of short messages
between an application residing on a MS and an application within the network,
Message Center (MC). The MSC and BS provide a conduit for short messages
between the application in the network (at MC) and the application in the MS.
A mobile originated SMS (SMS-MO) message may be sent from the MS to the BS
on either a control (access) or traffic channel. An SMS Mobile Terminated
(SMS-MT) message can be transmitted from the BS to the MS on either a control
(paging) or traffic channel.
The SMS graph shows SMS Attempts and SMS Completed for both Mobile
Originated and Mobile Terminated calls.
Figure 92 shows a sample SMS graph.

Figure 92 SMS Graph
Figure 93 shows the collection point for SMS statistics.

Figure 93 Collection Points for SMS Call Statistics
All Statistics Report The All Statistics report is a convenient way to generate all call statistics in a
single report. The All Statistics report uses same performance data collection
points used by graphs.
Generate and export this report on a daily, weekly, and monthly basis to create a
performance history for the system.

Figure 94 shows a sample All Statistics Report.

Figure 94 All Statistics Report
BSC Statistics The BSC graphs and reports do not report on the performance of the BSC itself
but rather use performance counters generated by messages on the A1/A2/A5
interfaces (BSC facing interfaces). All performance statistics are collected on a per
BSC basis.
The A1 interface carries signaling information between the MSC (Call Control and
Mobility Management functions) and the BSC (call control function). The A2
interface carries PCM information (voice/data) between the MSC (switch
component) and the BSC (SDU). The A5 interface carries a byte stream between
the IWF (via MSC) and BSC (SDU).
This section provides information on:

Emergency Calls (BSC facing)
Features (BSC facing)
Handoff (BSC facing)
Location Updates (BSC facing)
MO Calls (BSC facing)
BSC Statistics 130
MT Calls (BSC facing)

Mean Call Time (BSC facing)
Mobile Lost
Paging
SMS (BSC Facing)
Usage
All Statistics Report (BSC Facing)
Emergency Calls (BSC facing) The Emergency Calls graph displays:

Emergency Call Attempts
Emergency Calls Completed
Emergency Calls Answered
Emergency Call Mishandled
Figure 95 shows a sample Emergency Calls graph (BSC facing).

Figure 95 Emergency Calls Graph (BSC Facing)
A Mobile Originated emergency call is handled like any other Mobile Originated
call. The Emergency Call Attempts counter is incremented when the MSC receives
the CM Service Request message with dialed digit analysis. A Mobile
Originated emergency call is differentiated from a non-emergency Mobile
Originated call by an analysis of the dialed digits. If the dialed digits match the
digits in the emgno field in the bsi-timer configuration table for the MSC, then
the call is flagged as an emergency call.
Emergency Calls Completed is incremented when the MSC receives the

Assignment Complete message from the BSC (originating).

Emergency Calls Answered is incremented when the MSC receives an ANM

message from the terminating side.
Emergency Calls Mishandled is incremented when the MSC receives a

Assignment Failure message.
When the MSC does not receive an Assignment Complete message or an

Assignment Failure message before timer T10 expires, call clearing is initiated.
Features (BSC facing) The Feature graph displays the Feature Update Request
Figure 96 shows a sample Feature graph.
Figure 96 Feature Graph
The Feature Update Req is incremented when the MSC sends a FEATREQ message
to a location register (VLR/HLR). The Feature Request operation is used to
request feature-related treatment on behalf of a registered mobile.
Figure 97 shows the collection point for Feature Update statistics.

Figure 97 Collection Point for Feature Update Request Statistics
BSC Statistics 132
Dialed digits are received by the Serving MSC. During analysis of the dialed digits,
the Serving MSC detects a feature code string. The dialed digits are included in a
FEATREQ and sent from the Serving MSC to the HLR associated with the mobile.
The HLR sends a featreq message to the MSC that contains the feature request
confirmation indication and, optionally, parameters which specifically indicate
the treatment the MSC shall provide to the mobile. When the featreq is
received from the HLR, the Serving MSC provides treatment to the mobile based
on the information contained in the response.
Handoff (BSC facing) The Handoff graph displays:

Handoff out
Handoff In
Handoff Failed
Handoff Overflow
Figure 98 shows a sample Handoff graph.

Figure 98 Handoff Graph
The handoff statistics are collected on inter-BSC handoffs.
The Handoff out counter is incremented when the MSC sends a Clear Command
to the source BSC.
The Handoff In counter is incremented when the MSC receives a Handoff

Complete message from the target BSC.

The Handoff Failed counter is incremented when the MSC receives a Handoff
Failure message from the source or target BSC.
The Handoff Overflow counter is incremented when there are no A2 circuits

available to the BSC.
Figure 99 shows the collection points for Handoff In and Handoff out statistics
and Figure 100 shows the collection point for Handoff Failed.
Figure 99 Collection Points for Handoff In and Handoff Out Statistics
Figure 100 Collection Point for Handoff Failed Statistic
The MSC is responsible for clearing any A1, A2, and/or A5 connections associated
with a call. To release the resources allocated to the call, the MSC sends a Clear
BSC Statistics 134
Command message to the BSC. The BSC responds with a Clear Complete message
and stop timer T300.
Call clearing is used in hard handoff scenarios to release the source RF channel
and terrestrial resource after either the mobile has been acquired by the target
BSC or the call is dropped.
The MSC uses call clearing to tear down the source channel, the target channel,
or both in the event of a failure in the handoff process.
Location Updates (BSC facing) The Location Updates graph displays:

Location Update Attempts
Location Update Denied
Figure 101 shows a sample Location Updates graph.

Figure 101 Location Updates Graph
The mobile may initiate registration for a number of reasons. Successful location
registration requests involve the exchange of the following MSC-BSC messages:
Location Updating Request
Authentication Request / Authentication Response (optional)
Location Updating Accept
The Location Updating Request message is sent by the BSC to notify the MSC
of a registration attempt by the mobile. The Location Update Attempts counter is
incremented when the MSC receives a Location Updating Request message.

Figure 102 shows the collection point for location update attempts.
Figure 102 Location Update Attempts Collection Point
If the mobile cannot register, the MSC will send a Location Updating Reject
message to the BSC that contains the reason for the rejection. The Location
Update Denied counter is incremented when the MSC sends a Location Update
Reject message.
If timer 3210 (on the BSC) expires before it receives a Location Updating
Accept or a Location Updating Reject message then the BSC may resend the
Location Updating Request message.
MO Calls (BSC facing) The MO Calls graph displays:

Mobile Originated Call Attempts
Mobile Originated Calls Completed
Mobile Originated Calls Answered
Mobile Originated Calls Blocked
Mobile Originated Call Overflow
BSC Statistics 136
Figure 103 shows a sample MO Calls graph.

Figure 103 MO Calls Graph
Emergency calls do not increment Mobile Originated Call counters.
The Mobile Originated Call Attempts counter is incremented when the MSC
receives CM Service Request message. See Figure 83 for details on the statistic
collection point. This counter is similar to attMobileOriginatingCallMSC (see
Mobile Originated Calls on page 122), except that the statistic shows calls per
BSC.
The Mobile Originated Calls Completed counter is incremented when the MSC
receives an Assignment Complete message from the BSC. See Figure 83 for
details on the statistic collection point. This counter is similar to
cmplMobileOriginatingCallMSC (see Mobile Originated Calls on page 122),
except that the statistic records the Assignment Complete message from the
BSC side, and shows calls per BSC.
The Mobile Originated Calls Answered counter is incremented when the MSC
receives the ANM message from the terminating side.
A blocked origination is caused by an internal resource shortage, invalid cell, or

an incorrectly formatted A-interface message.
The Mobile Originated Call Overflow counter is incremented when no A2 circuits

are available to the BSC for call setup.
MT Calls (BSC facing) The MT Calls graph displays:

Paging Responses 1
Paging Responses 2

Mobile Terminated Call Attempts

Mobile Terminated Calls Completed
Mobile Terminated Calls Answered
Mobile Terminated Call Overflow
Figure 104 shows a sample MT Calls graph.

Figure 104 MT Calls Graph
The Paging Responses 1 counter is incremented when the MSC receives a Paging
Response message from the BSC for the first Paging Request message.
Response message from the BSC for the second Paging Request message.
The Mobile Terminated Call Attempts counter is incremented when the MSC
receives a Paging Response message from the BSC and the Service Option field
in the message indicates a voice call.
The Mobile Terminated Calls Completed counter is incremented when the MSC
receives an Assignment Complete message from the BSC.
The Mobile Terminated Calls Answered counter is incremented when the MSC
receives a Connect message from the BSC.
The Mobile Terminated Call Overflow counter is incremented when no A2 circuits

are available for the call after the MSC has received the Paging Response
message from the BSC (no Assignment Request message is sent to the BSC).
BSC Statistics 138
Figure 105 shows the collection points for Mobile Terminated Call statistics.
Figure 105 Collection Points for Mobile Terminated Statistics
The MSC sends a maximum of two Paging Request messages to the BSC. If the
MSC does not receive a Paging Response message for the first Paging Request
before timer T3113 expires, it resends the Paging Request.

Mean Call Time (BSC facing) The Mean Time graph displays Handoff Out
Figure 106 shows a sample Mean Time graph (Handoff Out).
Figure 106 Mean Time Graph (Handoff Out)
The mean time for the Handoff Out statistic is calculated from the average time,
from when the MSC receives a Handoff Required message from the source BSC
to when the MSC sends the Clear Command message to the source BSC.
The mean time would include any failed handoffs.
Figure 106 shows the time calculation interval between the messages.
Figure 107 Mean Time Interval for Handoff Out
BSC Statistics 140
Mobile Lost The Mobile Lost graph displays Mobile Lost.

Figure 108 shows a sample Mobile Lost graph.
Figure 108 Mobile Lost Graph
The Mobile Lost counter is incremented under two of the following conditions:
The call is in the answered state and the MSC receives a Clear Request
message from the BSC with a cause value of Radio Interface failure (0x01).
The MSC has sent the Handoff Command message to the source BSC, the
timer T8 expires, and the MSC receives a Clear Request message from the
BSC with a cause value of Radio Interface failure (0x01).
Paging The Paging graph displays:

Paging Requests 1
Paging Requests 2
Paging Responses 1
Paging Responses 2

Figure 109 shows a sample Pages (BSC Facing) graph.

Figure 109 Pages Graph (BSC Facing)
The MSC sends up to two Paging Request messages only.
The Paging Requests 1 counter is incremented when the MSC sends the initial
Paging Request message to the BSC.
The Paging Requests 2 counter is incremented when the MSC sends the
subsequent Paging Request message to the BSC.
Response message from the BSC for an initial Paging Request message.
Response message from the BSC for the subsequent Paging Request message.
Figure 110 shows the collection points for Pages statistics.

Figure 110 Collection Point for Paging Statistics
BSC Statistics 142
The MSC will send the second and final Paging Request message if it does not
receive a Paging Response message from the BSC before timer T3113 expires. If
the mobile does not respond to the second Paging Request (Page Message
from BSC) message before timer T3113 expires, the MSC determines from the
service profile of the mobile if call forwarding should be performed when no
page response is received.
If call forwarding should be performed, the Serving MSC sends a REDREQ message
to the Originating MSC indicating that the redirect is due to no page response
from the mobile. The Originating MSC queries the HLR for the forwarding
number, releases the inter MSC call resources, and sets up the redirect call.
SMS (BSC Facing) The SMS graph displays:

Mobile Originated SMS Attempts
Mobile Originated SMS Completed
Mobile Terminated SMS Attempts
Mobile Terminated SMS Completed
Figure 111 shows a sample SMS (BSC Facing) graph.

Figure 111 SMS Graph (BSC Facing)
The Mobile Originated SMS Attempts counter is incremented when the MSC
receives a ADDS Transfer message or CM Service Request message with
Service Option value set to 8.
The Mobile Originated SMS Completed counter is incremented when the MSC
sends an ADDS Transfer Ack message (signaling channel) or ADDS Deliver
Ack message (traffic channel) to the BSC.

The Mobile Terminated SMS Attempts counter is incremented when the MSC
sends an ADDS Page message or ADDS Deliver message to the BSC.
The Mobile Terminated SMS Completed counter is incremented when the MSC
receives a ADDS Page Ack message or ADDS Deliver Ack message from the
BSC.
Three types of basic short messaging are possible: mobile originated

point-to-point, mobile terminated point-to-point, and broadcast (currently not
supported). No broadcast SMS are calculated in Mobile Originated SMS and
Mobile Terminated SMS statistics.
Short messages can be exchanged between the mobile and BSC on both the
control and traffic channels. An active mobile station can send and receive short
messages at any time.
A Mobile Originated SMS message can be sent from the mobile to the BSC on
either the signaling channel or the traffic channel. A mobile already using a traffic
channel will send the SMS on the same traffic channel. An idle mobile can use
the signalling (access) channel for SMS or use the traffic channel.
If the signaling channel is used, then the BSC sends the ADDS Transfer
(Application Data Delivery Service) message to the MSC. If the traffic channel is
used, then the BSC sends the ADDS Deliver message to the MSC.
Figure 112 shows the collection point for Mobile Originated SMS on signaling
(access) channel.
Figure 112 Collection Point for MO SMS on Signaling Channel
A Mobile Originated SMS is completed when the MSC receives the delivery
acknowledgement from the BSC.
Figure 113 shows the collection point for completed Mobile Originated SMS
using signaling (paging) channel and Figure 114 shows the collection point for
completed Mobile Originated SMS using traffic channel.
BSC Statistics 144
Figure 113 Collection Point for Completed MO SMS on Signaling Channel
Figure 114 Collection Point for Completed MO SMS on Traffic Channel\
A Mobile Terminated SMS message can be sent to the mobile on either the
signaling (paging) channel or traffic channel. If a mobile is idle, then the SMS is
sent using the signaling (paging) channel with the ADDS Page message. If the
mobile is using a traffic channel, then the SMS is sent using the traffic channel
and the ADDS Deliver message.
Figure 115 shows the collection point for Mobile Terminated SMS on signaling
(paging) channel and Figure 116 shows the collection point for Mobile
Terminated SMS on traffic channel.

Figure 115 Collection Point for MT SMS on Signaling Channel
Figure 116 Collection Point for MT SMS on Traffic Channel
A Mobile Terminated SMS is completed when the MSC sends the delivery
acknowledgement to the BSC.
Figure 117 shows the collection point for completed Mobile Terminated SMS on
the signaling (paging) channel and Figure 118 shows the collection point for
completed Mobile Terminated SMS on traffic channel.
Figure 117 Collection Point for Completed MT SMS on Signaling Channel
BSC Statistics 146
Figure 118 Collection Point for Completed MT SMS on Traffic Channel
Usage The usage graph displays:

Mobile Originated Usage
Mobile Terminated Usage
Handoff In Usage
Out of Service Usage
Figure 119 shows a sample Usage graph.

Figure 119 Usage Graph
The Mobile Originated Usage counter calculates the total number of seconds that
virtual ports on the BSC are engaged in a Mobile Originated call.
The Mobile Terminated Usage counter calculates the total number of seconds
that virtual ports on the BSC are engaged in a Mobile Terminated call.

The Handoff In Usage counter calculates the total number of seconds that virtual
ports are engaged in a handoff in.
The Out of Service Usage counter calculates the total number of seconds that
virtual ports are out of service.
The Mobile Originated Usage counter starts timing when the MSC receives an
Assignment Complete message (with the virtual port reference) from the BSC,
and ends timing when the MSC receives the Clear Complete message
(referencing the same virtual port).
Figure 120 shows the start and end points for the Mobile Originated Usage
counter interval.
Figure 120 Mobile Originated Usage Counter Interval
The Mobile Terminated Usage counter starts timing when the MSC receives an
Assignment Complete message (with the virtual port reference) from the BSC,
and ends timing when the MSC receives the Clear Complete message
(referencing the same virtual port).
Figure 121 shows the start and end points for the Mobile Terminated Usage
counter interval.
BSC Statistics 148
Figure 121 Mobile Terminated Usage Counter Interval
The Handoff In Usage counter starts timing when the MSC sends a Handoff
Request message to the target BSC, and ends timing when the MSC receives a
Handoff Complete message from the target BSC. This usage counter records the
interval for the target BSC, not the source BSC.

Figure 122 shows the start and end points for the Handoff In Usage counter.
Figure 122 Handoff In Usage Counter Interval
The Out of Service Usage counter starts timing when the MSC receives no
response from the heartbeat message sent to the BSC, and ends timing when it
does receive a response. There will be no response to the heartbeat message
when either the MSC <--> BSC link is down or if the BSC is down. Heartbeat
failure is more likely due to link problems than BSC problems. There is no way to
determine which end of the link has failed from the heartbeat message.
All Statistics Report (BSC The All Statistics Report is a convenient way to generate all A1/A2/A3 interface
Facing) statistics in a single report. The All Statistics report uses the same performance
data collection points used by graphs.
Generate and export this report on a daily, weekly, and monthly basis to create a
performance history for the system.
Performance Analysis 150
Figure 123 shows a sample All Statistics Report (BSC Facing) graph.
Figure 123 All Statistics Report (BSC Facing)
Performance Analysis Performance analysis is the further processing of the raw performance data
collected during the performance monitoring and data collection phase. The
result of performance analysis is used to make decisions about traffic
engineering.
Traffic Engineering Traffic engineering is the optimization of network resource usage while
maintaining QoS requirements. Traffic engineering is a part of network
engineering which deals with the performance optimization of operational
networks.
This section provides information on:

Traffic Engineering for Trunk Groups
Traffic Engineering for Call Processing and Mobility Management
Basic Performance Calculations
Traffic Engineering for Trunk Groups

Traffic engineering for trunk groups involves enhancing the performance of the
operational network, at both the traffic and resource levels. This is accomplished
by addressing traffic oriented performance requirements, while using network
resources economically and reliably.
An important objective of traffic engineering is to facilitate reliable network

operations. Reliable network operations can be facilitated by providing
mechanisms that enhance network integrity and by adhering to policies that
emphasize network survivability. This minimizes network vulnerability to service

outages resulting from errors, faults, and failures occurring within the
infrastructure.
Inputs to making decisions about trunk group traffic engineering are the Trunk
Group Summary Report (see Trunk Group Statistics on page 110) and especially,
the Trunk Group Detail Reports (see Trunk Group Detail Report on page 112).
The report provides the raw trunk group performance data. Network engineers
should use this data, along with their experience and knowledge of the network
topology, to make decisions about traffic engineering.
Traffic Engineering for Call Processing and Mobility Management

Traffic engineering for Call Processing and Mobility Management involves
enhancing the performance of the remainder of the operational network (trunk
groups excluded). Here, the focus is on the traffic on the MSC and Access
Network.
Some of the inputs to making decisions about Call Processing and Mobility
Management traffic engineering are the Call Processing and Mobility
Management graphs and statistics reports (see Call Processing and Mobility
Management Statistics on page 114).
The process is the same as for trunk group traffic engineering. Reports provide
the raw performance data. Network engineers should use this data, along with
their experience and knowledge of the network topology, to make decisions
about traffic engineering.
Basic Performance Calculations

The table below lists some commonly needed performance figures, and how to
calculate them. How to perform the actual calculations (as well as to derive new
performance figures) is part of performance analysis. See Performance Analysis
on page 150 for more information on performance analysis.
To Calculate
Busy Hour
Call Attempts
(Mobile
Originated
and Land CallAttempts + EmergencyCallAttempts + MOSMSAttempts + MTSMSAttempts + LandOrigCallAttem
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Originated
(including
SMS))
% Trunk
Utilization
(Hourly, in
Erlang, ( succIncSeizureTraffic + succOutSeizureTraffic ) 3600
------------------------------------------------------------------------------------------------------------------------------------------------------------------ 100
within a NumberOfTrunksInService
trunk group)
ALARM MANAGEMENT
7
This chapter provides an overview of Alarms Management in the MSC.

Alarms Overview
Alarm Root Causes
Common Alarms
MSC and VLR Alarms
Alarms Overview The OMC Console Active Alarms Display displays alarms on the MSC. Alarm
monitoring is performed on a routine basis by the Operator.
Alarm Severity Alarms raised on the MSC are categorized by level of severity. Alarms where the
severity level cannot be determined are labeled indeterminate. Indeterminate
alarms are informational and are not critical or major alarms. there is no
corrective action for indeterminate alarms.
These alarm severity levels are:

Critical
Critical alarms indicate that a service affecting condition has occurred, and that
immediate corrective action is required.
For example, a critical alarm is reported when a Managed Object fails and goes
out of service. If the Managed Object is not restored, then it might cause other
Managed Objects to go out of service as well.
Major
Major alarms indicate that a service-affecting condition has developed and
urgent corrective action is required.
For example, a major alarm occurs when there is a severe degradation in the
capability of a managed object to deliver service. However, the degradation in
service does not affect other Managed Objects.
Minor
Minor alarms indicate that a non-service affecting fault condition has occurred,
and that corrective action should be taken to prevent a more serious
service-affecting fault.
For example, a minor alarm is reported when the detected alarm condition is not
currently degrading the capacity of the managed object. No service degradation
153 Chapter 7: Alarm Management
has yet been detected, but if the situation persists, it will cause a degradation in
service.
Warning
Warning alarms indicate that a potentially service affecting fault has been
detected before any significant effects have been felt. Take further action to
diagnose and correct the problem to prevent a more serious service affecting
fault.
Alarm Types Alarms raised on the MSC are typed according to the functional area to help
locate and isolate the alarms.
The alarm types are:

Processing Error
Equipment
Communications
Processing Error
Processing errors occur when internal an software process fails, shuts down, or
nears capacity. They are also caused by corrupt data in the database.
Equipment
Equipment alarms occur when a hardware device or subsystem is out of service,
such as span, port, or trunk. Use the OMC Console reachthrough feature to check
transmission equipment for alarms.
Communications
Communication alarms occur when TCP/IP or SS7 communication links are down
or not configured properly. In the MSC, these alarms are typically reported when
the system restarts.
Automatic and Manual Alarm Alarms are triggered by events. Alarms may clear automatically or may require
Clearing manual clearing.
Automatic Alarm Clearing

Some alarms are cleared automatically when the triggering condition is resolved.
Generally, these alarms are related to thresholds, or connections to other
Network Elements (like the Intelligent Media Gateway or Base Station
Controller).
These alarms are cleared automatically when the fault on the responsible
Network Element is cleared, or when values do not exceed threshold values.
The corrective procedure for the alarm will indicate if the alarm is cleared
automatically.
Alarm Root Causes 154
Manual Alarm Clearing

Other alarms require Operator intervention to manually clear the alarm. Some of
these alarms result in termination of the MSC application. For these alarms, the
MSC application is restarted, and the alarm is silently cleared.
Event-based alarms must be manually cleared by resolving the underlying event

that is triggering the alarm. The alarm is raised each time the triggering event
occurs (there is no alarm correlation or suppression).
The corrective procedure for the alarm will indicate if the alarm must be cleared
manually.
Alarm Root Causes A probable cause defines the likely reason for the event that caused the alarm.
One or more alarms can share the same probable cause.
The probable causes identified in the MSC follow ITU-X7.33. The following
sections describe the probable causes used by alarms on the MSC.
Communications Protocol Error

A Communications Protocol Error indicates that a communications protocol has
been violated.
Configuration or Customization Error

A Configuration or Customization Error indicates that a customizable parameter
for a system or device is incorrectly specified, or is inconsistent with the actual
configuration.
Most of the alarms are MAJOR because they will impede or otherwise negatively
impact service.
Congestion
Congestion indicates the system, or network component, has reached its capacity
or is approaching it.
Corrupt Data
Corrupt Data indicates that an error (unspecified) has caused some data to be
incorrect and therefore, unreliable.
The CRITICAL alarm indicates a read/write error in the configuration database.

The MINOR alarms are raised when circuits receive improper blocking messages.
File Error
File Error indicates that the format of a file (or set of files) is incorrect and thus
cannot be used reliably in processing.
Out of Memory
Out of Memory indicates that no program-addressable storage available.

Out of Service
Out of Service indicates that the network component can no longer provide an
expected service.
The WARNING alarms with Out of Service as a probable cause indicate that there
is a problem with the Intelligent Media Gateway or PSTN trunks.
Power Problem
Power Problem indicates that there is a problem with the power supply to one or
more resources.
Resource at or Nearing Capacity

Resource at or Nearing Capacity indicates that the usage of a resource is at or
nearing the maximum allowable capacity.
The MAJOR alarms with Resource at or Nearing Capacity as a probable cause

indicate a problem at the Intelligent Media Gateway or with Call Processing.
Response Time Excessive

Response Time Excessive indicates that the elapsed time between the end of an
internal subsystem message and the start of the answer to the internal
subsystem message is outside of acceptable limits.
The CRITICAL alarm is raised when all inter-process communication (ipc) fails. The
WARNING alarm indicates that inter-process communication is back online.
Software Program Abnormally Terminated

A Software Program Abnormally Terminated indicates that a software program
has terminated due to some unrecoverable error condition.
All but one of the alarms with Software Program Abnormally Terminated as a
probable cause are CRITICAL alarms - these alarms indicate that the MSC
application has stopped due to a software error. The WARNING alarm indicates
that the MSC application was stopped by an Operator command.
Software Error
A Software Error indicates an error in software for which no more specific
probable cause can be assigned. The CRITICAL alarm results from a lower layer
event in the MSC application, and requires a restart of the application.
Transmit Failure
A Transmit Failure indicates a failure to receive an expected message. There is a
single alarm of MINOR severity due to expiry of internal timers.
uUnderlying Resource Unavailable

Underlying Resource Unavailable indicates that an entity upon which the
reporting object depends has become unavailable.
Common Alarms 156
Unspecified Reason
Unspecified Reason indicates that the underlying event causing the alarm is not
specified.
Fault Localization Fault localization is used to help locate the fault in the network. The OMC Active
Alarms Display displays the Managed Object and the Managed Object instance to
help localize the fault in the MSC. For faults in other Network Elements, the IP
address or hostname is displayed to locate the fault.
Use the information provided by fault localization to locate the Network Element
that generates the fault, and to locate the Managed Object in the configuration
database for the affected Network Element (if applicable).
For faults related to configuration errors, refer to the MSC Server Provisioning
Guide as a guide to the tables in the configuration database, and the default and
recommended parameter settings.
Common Alarms Refer to the Core Voice Network Operations, Maintenance, and Provisioning
Guide for information on alarms common to nodes that make up the Sonata core
network nodes. These common alarms can be raised on each of the nodes,
including the MSC.
MSC and VLR Alarms MSC and VLR alarms are raised on the MSC.
Critical MSC Alarms Critical alarms for the MSC are:

MegSpanAlarm
MegSpanAlarm
Table 25 MegSpanAlarm Clearing Information
Alarm Name MegSpanAlarm
Alarm Severity Critical
Managed Object See Managed Object Instance field in OMC Active Alarms
Display
Description Equipment
System Impact Span out of service.
Root Cause(s) Out of Service
Clearing Actions Automatic Alarm Clearing
No other information currently available
Major MSC Alarms Major alarms for the MSC are:

AspAlarmNoFreeCall
AspAlarmNoFreeParty
LfmAlarmNoFreePort
SsfAlarmNoFreeCS
SsfAlarmNoFreeCSA
SsfAlarmNoFreeOBCSM
SsfAlarmNoFreeTBCSM
SsfAlarmNoFreeSSF
AspAlarmNoFreeCall
The ASP subsystem assigns a reference ID number to each call. Each party
involved in the call (PARTY A, PARTY B) is also assigned a reference ID number.
The number of available reference ID numbers limits the number of calls that the
system can handle. There is no default value for pool size of reference ID
numbers available. This value is set according to the network dimensioning
requirements.
Number of switch ports configured for the system divided by 2. The available free
reference ID numbers in ASP_PARTY_TABLE is always twice that of
ASP_CALL_TABLE.
Table 26 AspAlarmNoFreeCall Clearing Information

Alarm Name AspAlarmNoFreeCall
Alarm Severity Major
Display
Description Processing Error No free buffers left to get a new call.
System Impact The system will reject any new call attempts until resources
are released.
Root Cause(s) Resource at or Nearing Capacity
Clearing Actions Manual Alarm Clearing
AspAlarmNoFreeParty
Table 27 AspAlarmNoFreeParty Clearing Information
Alarm Name AspAlarmNoFreeParty
Display
Description Processing Error No free buffers left to get a new party.
are released.
MSC and VLR Alarms 158
LfmAlarmNoFreePort
Table 28 LfmAlarmNoFreePort Clearing Information

Alarm Name LfmAlarmNoFreePort
Display
Description Processing Error No free buffers left to get a new port.
are released.
SsfAlarmNoFreeCS
Table 29 SsfAlarmNoFreeCS Clearing Information

Alarm Name SsfAlarmNoFreeCS
Display
Description Processing Error No free buffers left to get a new cs state
machine.
are released.
SsfAlarmNoFreeCSA
Table 30 SsfAlarmNoFreeCSA Clearing Information

Alarm Name SsfAlarmNoFreeCSA
Display
Description Processing Error No free buffers left to get a new csa state
machine.
are released.

SsfAlarmNoFreeOBCSM
Table 31 SsfAlarmNoFreeOBCSM Clearing Information
Alarm Name SsfAlarmNoFreeOBCSM
Display
Description Processing Error No free buffers left to get a new o_bcsm
state machine.
are released.
SsfAlarmNoFreeTBCSM
Table 32 SsfAlarmNoFreeTBCSM Clearing Information
Alarm Name SsfAlarmNoFreeTBCSM
Display
Description Processing Error No free buffers left to get a new t_bcsm
state machine.
are released.
SsfAlarmNoFreeSSF
Table 33 SsfAlarmNoFreeSSF Clearing Information
Alarm Name SsfAlarmNoFreeSSF
Display
Description Processing Error No free buffers left to get a new ssf state
machine.
are released.
MSC and VLR Alarms 160
Table 33 SsfAlarmNoFreeSSF Clearing Information

Minor MSC Alarms There are no Minor alarms for the MSC.
Warning MSC Alarms Warning alarms for the MSC are:

VsmAlarmTrunkCongestion
VsmAlarmTrunkFault
VsmAlarmStateChngFail
VsmAlarmInvalidPort
MegGatewayAlarm
VsmAlarmTrunkCongestion
Table 34 VsmAlarmTrunkCongestion Clearing Information
Alarm Name VsmAlarmTrunkCongestion
Alarm Severity Warning
Display
Description Equipment Blocked port number of this trunk group hit the
threshold.
System Impact Trunk congestion.
VsmAlarmTrunkFault
Table 35 VsmAlarmTrunkFault Clearing Information
Alarm Name VsmAlarmTrunkFault
Display
Description Equipment Port out of service.
System Impact Port out of service.

VsmAlarmStateChngFail
The VsmAlarmStateChngFail alarm is raised when the MSC receives a
VSM_SS_EVT_CHANGE_NCFM event for a port. The event is generated by the
Intelligent Media Gateway.
The VSM_SS_EVT_CHANGE_NCFM event is not written to the Event Log or to a trace

file.
Table 36 VsmAlarmStateChngFail Clearing Information

Alarm Name VsmAlarmStateChngFail
Display
Description Equipment Trunk status change between OOS and INS with
CLI but fail.
System Impact Unknown.
VsmAlarmInvalidPort
Table 37 VsmAlarmInvalidPort Clearing Information
Alarm Name VsmAlarmInvalidPort
Display
Description Equipment Port entry is unconfigured.
MegGatewayAlarm
Table 38 MegGatewayAlarm Clearing Information
Alarm Name MegGatewayAlarm
Display
Description Equipment Gateway out of service.
TROUBLE LOCATING AND CLEARING
8
This chapter describes how to locate and clear issues in the MSC system.

Viewing MSC Event Logs
MSC Subsystems
Trace Manager
Deleting a Subscriber from the VLR
Viewing MSC Event Logs Event Log Records provide records of events that happened in the past, events
that happened more recently, and events that are currently happening.
Refer to the Viewing Logs and Events chapter of the Core Voice Network
Operations, Maintenance, and Provisioning Guide for information on how to view
logs using the vlog tool.
Select the timeframe for each Event Log Record to view.
Viewing Call Detail Records Display Call Detail Records chronologically.
To View Call Detail Records:

1 Start vlog.
2 Select a Call Detail Record timeframe.
a View Call Detail Records
b View Call Detail Records: LATEST
3 For Call Detail Records, page through to the end of the list and select a CDR file to
view.
See Example: Display Call Detail Records.
4 For Call Detail Records: LATEST, the CDR file is displayed.
5 Page through the displayed CDR file, and search for the desired call details.
6 Exit Call Detail Records and then exit vlog when finished.

163 Chapter 8: Trouble Locating and Clearing
Example: Display Call Detail Records shows the listed CDR files.
Example: Display Call Detail Records

1) (25610)-003704-2005-Nov-22
2) (25610)-003705-2005-Nov-22
3) (25610)-003706-2005-Nov-22
4) (25610)-003707-2005-Nov-22
...
141) (25610)-003844-2005-Nov-25
142) (25610)-003845-2005-Nov-25
143) (25610)-003846-2005-Nov-25
144) (25610)-003847-2005-Nov-25
145) Exit
Type the number of the selection then press ENTER:144
Viewing SMS Detail Records SMS Detail Records display call details for SMS calls. Historical SMS Records can
be displayed, as well as SMS Records.
To View SMS Detail Records:

1 Start vlog.
2 Select an SMS Detail Records timeframe.
a View SMS Detail Records
b View SMS Detail Records: LATEST
3 For historical SMS Detail Records, page through to the end of the list and select a
file.
See Example: Historical SMS Detail Records.
For SMS Detail Records: LATEST, the SMS Detail Record is displayed.
4 Page through the displayed SMS record, and search for the desired SMS details.
5 Exit SMS Detail Records and then exit vlog when finished.
Viewing MSC Event Logs 164
Example: Historical SMS Detail Records shows a sample file listing by date for
historical SMS Detail Records.
Example: Historical SMS Detail Records

Select one of the options:
1. View Call Detail Records
2. View Call Detail Records: LATEST
3. View Event Log Records
4. View Event Log Records: TODAYS
5. View Event Log Records: FUTURE
6. View Alarm Records
7. View Alarm Records: ACTIVE
8. View SMS Detail Records
9. View SMS Detail Records: LATEST
10. View Call and SMS Detail Records
11. View Call and SMS Detail Summary
Qq. Exit
Type the number of the selection then press ENTER: 8
1) (3078)-010357-2005-Nov-17
2) (3078)-010360-2005-Nov-17
3) (3078)-010361-2005-Nov-17
...
94) (3078)-010505-2005-Nov-29
95) (3078)-010506-2005-Nov-29
96) (3078)-010507-2005-Nov-29
97) Exit
Viewing Call and SMS Detail Call Detail Records and call records for SMS call can be displayed together.
Records
To View Call and SMS Detail Records:
1 Start vlog.
2 Select a Call and SMS Detail Record format.
a View Call and SMS Detail Records
b View Call and SMS Detail Summary
3 For Call and SMS Detail Records, page through to the end of the list and select a
file.
See Example: Historical Call and SMS Detail Records.
4 Page through the displayed record, and search for the desired details.
See Example: Call Detail Record.
5 For Call and SMS Detail Summary, the information is presented in a summary
format.

See Example: Summary of Call and SMS Detail Records. Example: Historical Call
and SMS Detail Records shows a sample file listing by date for historical Call and
SMS Detail Records.
Example: Historical Call and SMS Detail Records

Qq. Exit
1) (3078)-010357-2005-Nov-17
2) (3078)-010360-2005-Nov-17
3) (3078)-010361-2005-Nov-17
...
95) (3078)-010506-2005-Nov-29
96) (3078)-010507-2005-Nov-29
97) Exit
Example: Call Detail Record shows an example Call Detail Record.
Example: Call Detail Record

MscId: 3078
Orig Market ID: 12
Orig Switch Num: 2
Orig Billing ID: 2
Term Market ID: 12
Term Switch Num: 2
Term Billing ID: 3
A Trunk Group: 1
B Trunk Group: 1
A:7191235582 type:MOBILE digits:4564 trunk:2005 ESN:0x2ad220ba cell:17
B:6191234514 type:MOBILE digits:1236 trunk:0 ESN:0x2ae68b12 cell:0
A Feature Bits:
B Feature Bits:
Seized: Thu Nov 17 17:31:49 2005
Answered: Thu Nov 17 17:31:49 2005
Disconnected: Thu Nov 17 17:31:49 2005
Disc code: B_PARTY_BUSY
Sequence: 226228614
MSC Subsystems 166
Example: Summary of Call and SMS Detail Records shows the Call and SMS Detail
Records in summary format.
Example: Summary of Call and SMS Detail Records


Qq. Exit
Mscid-Seq-Date NumRecords Transacted BeginSeq EndSeq

============== ========== ========== ======== ======
(3078)-010361-2005-Nov-17 14 done 226228612
226228625
(3078)-010369-2005-Nov-18 1 done 226228626
226228626
(3078)-010370-2005-Nov-18 31 done 226228627
226228657
(3078)-010373-2005-Nov-18 4 done 226228658
226228661
MSC Subsystems At a very high level, the MSC performs three distinct operations: Mobility
Management, Call Processing, and Media Control. These three operations are
implemented in the MSC application by numerous subsystems. These subsystems
use events and messages to communicate and perform their functions.
Understanding the low-level communication between MSC subsystems can help

troubleshoot or otherwise reslove issues in the system when higher-level Fault
Management activities are not sufficient.
Figure 124 shows the MSC subsystems relevant to Mobility Management, Call
Processing, and Media Control.

Figure 124 MSC Subsystems
There are many subsystems, or modules, in the MSC. The subsystems in the MSC
register events and exchange messages to perform their functions. The
diagnostic files list information about subsystem events.
Operations, Maintenance, and Provisioning Guide for detailed information on the
subsystems and events within the subsystems.
Not all subsystems have diagnostics associated with them. Table 39 lists the
subsystems in the MSC that have diagnostics associated with them.
Operations, Maintenance, and Provisioning Guide for how to generate diagnostic
files.
Table 39 MSC Subsystems and Diagnostics
Subsystem Diagnostic Command

AIN ain_dump
ALM alm_dump
ALM alm_o_dump
ASP asp_dump
AUA aua_dump
AUE aue_dump
AUI aui_dump
AUP aup_dump
AUR aur_dump
AUS aus_dump
BSM bsm_dump
CALL call_dump
MSC Subsystems 168

CDR cdr_dump
COM com_dump
CSI csi_dump
DGT dgt_dump
DLG dlg_dump
EVL evl_dump
FSM fsm_dump
GAP gap_dump
GSS gss_dump
IAU iau_dump
IMP imp_dump
IRI iri_dump
ISI isi_dump
ISP isp_dump
LFM lfm_dump
MAU mau_dump
MCI mci_dump
MEG meg_dump
MEG meg_res_dump
MIP mip_dump
NAU nau_dump
ORQ orq_dump
PPI ppi_dump
PPX ppx_dump
RCI rci_dump
REQ req_dump
RTD rtd_dump
RTD rtd_flk_dump
RTD rtd_xn_dump
SMI smi_dump
SNA sna_dump
SSF ssf_dump
SSP ssp_dump
STA sta_dump
STC stc_dump
TIN tin_dump
TPM tpm_dump
TYP typ_dump
VAU vau_dump


VLR vlr_dump
VSM vsm_dump
WJT wjt_dump
Trace Manager The Trace Manager is described in the Core Voice Network Operations,
Maintanance, and Provisioning Guide.
MSC Traceable Modules Table 40 lists the modules that are traceable using the Trace Manager on the
MSC.
Table 40 Traceable Modules
Traceable Modules
nam dna msg xcp rtd tpm
evl utl sys ipc cpu stk
unx req typ trc fsm orq
tlv asn alm cdr oam sta
cli dbl nem ntk adl olm
mmi mip gta tia iai iar
iau iri iat cmn bfm fei
tcm scm ssp isp gpi dgt
sna nau nai nar nat nap
tin ain gin nsc cpt nso
stc tca tsl csl dlg tct
imi imu asp ecc lfm ppi
ppf cma ppx ssf vsm cpi
acc meg lia lit bsc pom
qmm rmi gap cap bsm com
wjt csi mci imp xvr csc
win isi smi rci vlr vau
aai aal hab vsp tss mvu
zmv tsm
Selective Call Trace The most useful call tracing is to turn tracing on for a module and then trace by
MIN, DN, and/or Port. Resource tracing can use a combination of MINs, DNs, and
PORTs. The tracing priority is: MIN > DN > PORT.
Table 41 shows which of these resources can be traced on each module.
Table 41 Selective Call Trace Resources
Module Name MIN DN PORT

SSF X
Trace Manager 170
Table 41 Selective Call Trace Resources
Module Name MIN DN PORT

ASP X
LFM X X
VSM X X
MEG X
MCI X X
RCI X
IMP X X
SMI X
CSI X X
MIPD X
VLR X
Table 42 shows the tracing to use for some troubleshooting scenarios.
Table 42 Selective Call Trace Scenarios
Scenario Notes
Cannot make calls from a mobile Use resource tracing with mobile's MIN
Cannot terminate calls to a mobile Use resource tracing with the mobile's DN
Calls cannot be made via a specific Use resource tracing with the trunk PORT
trunk
Resource leakage problem Use basic tracing to identify MIN, DN, or PORT
Use resource tracing with the MIN, DN, or
PORT
Example of a Selective Call Trace

The Trace Manager commands and syntax are described fully in the Core Voice
Network Operations, Maintenance, and Provisioning Guide. The following shows
one example of a selective call trace:
#
# Initialization
#
tm -T 0
tm -C
#
# CPE Trace Setting
#
tm -P ASP -M "ASP,SSF,NAU,GIN" -T 1-16,32
tm -P LFM -M "LFM,NSO,NSC,NAU,NAI" -T 1-16,32
tm -P VSM -M "VSM,MEG" -T 1-16,32
#
# MOB Trace Setting
#
tm -P CSI -M "CSI,CAP" -T 1-16,32
tm -P IMP -M "RCI,MCI,WIN,SMI,NAU,ISI,IMP,MIP,IMU,IAU" -T 1-16,32
tm -P VLR -M "VLR,MIP,IMU,IAU" -T 1-16,32
tm -P MIPD -M "MIP,IAU,IRI,IAR" -T 1-16,32
#
# Add Appropriate Resources
#
tm -A MIN 6191234506
tm -A DN 4508
tm -A PORT 9023
#
# Display All Trace Setting
#
tm -Q
Deleting a Subscriber In some troubleshooting scenarios, a subscriber may need to be deleted from the
from the VLR VLR.
Use the vdel command to delete a subscriber from the VLR:
vdel <subscriber's MIN>

ACRONYMS
A
This appendix defines acronyms used in this guide.
Table 43 List of Acronyms
Acronym Definition
AAA authentication, authorization, and accounting
AC Access Center or Authentication Center or Alternating
Current
ACM Alarm Control Module or Address Complete Message or
Automatic Call Manager
AIN Advanced Intelligent Network
ALM Alarm Module or AppWare Loadable Module
AMA Automatic Message Accounting
ANI Automatic Number Identification
ANM Answer Message
ASCII American Standard Code for Information Interchange
ASP Advanced Switch Processor or Active Server Pages or
Application Service Provider
AUP Acceptable Use Policy
AUR Access Usage Record
BAF Bell core Automatic Message Accounting Format
BCSM Basic Call State Machine
BHCA Busy Hour Call Attempt
BS Base Station
BSC Base Station Controller or Binary Synchronous
Communications
BSS Base Station System or Broadband Switching System
BTS Base Transceiver Station
CAS Centralized Attendant Service or Channel Associated
Signaling
CCS Centi Call Seconds or Common Channel Signaling or Custom
Calling Services or Call Control Signaling
CDMA Code Division Multiple Access
CDR Call Detail Record or Clock Data Recovery or Compact Disk
Recordable
CFB Call Forward Busy
CFU Call Forward Unconditional

173 Chapter :
Acronym Definition
CLI Command Line Interface or Cumulative Leakage Index or
Calling Line Identification
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
CM Computing Module or Configuration Management or Cable
Modem or Commercial Grade
COM Continuation of Message or Component Object Model
CP Control Point
CPU Central Processing Unit
CRC Cyclic Redundancy Check
CSI Calling Subscriber Identification or Called Station
Identification
CW Call Waiting
DC Direct Current
DMH Data Message Handler
DN Directory Number
ESD Electrostatic Discharge or Electronic Software Delivery
ESN Emergency Service Number or Electronic Serial Number or
Electronic Switched Network
FEATREQ Feature Request
FER Frame Error Rate
FTN Forward to Number
FTP File Transfer Protocol or Foil Twisted Pair
GAP Generic Access Profile
GB Gigabyte
GMT Greenwich Mean Time
GR Generic Requirement
GSM Global System for Mobile Communications
GSS Group Switch Selector
HA High Availability or Home Agent
HLR Home Location Register
IAM Initial Address Message
III Information Industry Index
IMG Intelligent Media Gateway
IMP Interface Message Processor
IMSI International Mobile Subscriber Identity
IN Intelligent Network
INAP Intelligent Networks Application Protocol
INS In Service
IP Internet Protocol
174
Acronym Definition
IPC Instructions per Clock or Interprocess Communication
ISI Intersymbol Interference
ISP Internet Service Provider
ISUP Integrated Services Digital Network User Part
IWF Inter Working Function
JIP Jurisdiction Information Parameter
LDAP Lightweight Directory Access Protocol
LFM Logical Facility Manager
LIS Link Interface Shelf or Local Interconnection Service or
Lawful Intercept Server
LNP Local Number Portability
LO Local Operator
LOCREQ Location Request
LRN Local Routing Number
LT Line Terminator or Logical Terminal or Lower Tester
MAU Math Acceleration Unit or Multi Station Access Unit
MB Megabyte
MC Message Center or Monitor and Control or Main Cross
Connect
MCI Media Control Interface
MDN Mobile Directory Number or Mobile Dialing Number
MGCP Media Gateway Control Protocol
MIN Mobile Identification Number
MM Mobile Management
MRF Media Resource Function
MS Mobile Station or Microsoft
MSC Mobile Switching Center
MSCID Mobile Switching Center Identifier
MSISDN Mobile Station ISDN
MT Message Type
NAU Network Addressable Unit
NE Network Element
NMS Network Management Station
NOC Network Operations Center
NP Number Portability
OAMP Operation, Administration, Maintenance, Provisioning
OMC Operation and Maintenance Center
OOS Out of Service
OS Outage Seconds or Operating System
175 Chapter :
Acronym Definition
PCI Protocol Control Information or Peripheral Component
Interconnect
PCM Pulse Code Modulation
PCO Public Call Office or Point of Control and Observation or
Private Cable Operator
PPI Pixels per Inch or Presentation Programmers Interface
PPOB Pre-Paid Off-Line Billing
PSAP Public Safety Answering Point
PSTN Public Switched Telephone Network.
PU Physical Unit
RCI Radio Control Interface
RF Radio Frequency
RJE Remote Job Entry
SAT Subscriber Access Termination or Supervisory Audio Tone
SCCP Signaling Connection Control Part
SCF Service Control Function or Shared Channel Feedback
SCP Service Control Point or Signal Control Point
SCSI Small Computer System Interface
SDRAM Synchronized Dynamic Random Access Memory
SDU Service Data Unit
SIP Session Initiation Protocol or Single Inline Package
SMI Structure of Management Information
SMS Service Management System or Short Message Service
SNA Systems Network Architecture
SPARC Sun Microprocessor Architecture RISC
SS7 Signaling System Number Seven
SSF Service Switching Function
SSN Subsystem Number
SSP Service Switching Point
SSVR Signaling Server
STA Spanning Tree Algorithm
STC System Time Clock
TCP Transmission Control Protocol or Test Coordination
Procedure
TLDN Temporary Local Directory Number
TPM Terminating Point Master file
USB Universal Serial Bus
UTC Universal Coordinated Time
VLR Visitor Location Register
VMS Voice Mail System or Virtual Memory System
176
Acronym Definition
WIN Wireless In-building Network or Wireless Intelligent Network
XML Extensible Markup Language
INDEX
Mobile-Terminated Mobile 86 SMS 142

A Mobile-Terminated SMS 106 Usage 146
A_PARTY_ABORT Short Message Service 105
Disconnect code 77 Three-Way Call 97
A_PARTY_HANDOFF_FAIL AspAlarmNoFreeCall 157 C
Disconnect code 74 AspAlarmNoFreeParty 157 Call and SMS Detail Record
A_PARTY_NORMAL_DISC AUTHENTICATION_FAILURE Viewing 164
Disconnect code 77 Disconnect code 76 Call Detail Record Management 30, 54
A_PARTY_SAT_LOSS automatic alarm clearing 153 Call Detail Records
Disconnect code 74 AMA billing format 30
Abort files Archiving transferred CDR files 58
Abort filenames 64 B ASCII CDR format 82
Maximum number of files 64 B_PARTY_ABORT Billing formats 30
Oldest abort files 64 Disconnect code 77 CDR billing format 30
Removing 65 B_PARTY_BUSY CDR transaction summary 61
acc_trans.log Disconnect code 74 Checking available disk space 63
Binary to XML conversion log 66 B_PARTY_DENIED Checking conversion log 66
Accounting Disconnect code 74 Checking for CDR record corruption 62
Data call 31 B_PARTY_HANDOFF_FAIL Configuring CDR flush timer 35
accounts Disconnect code 74 Configuring CDR generation timer 36
drum 28 B_PARTY_NORMAL_DISC configuring CDR record generation using
pro 28 Disconnect code 77 CLI 37
root 28 B_PARTY_SAT_LOSS Data types 67
alarm clearing Disconnect code 74 Disconnect codes 74
automatic 153 Backup Display CDR meta data 60
manual alarm clearing 154 Trace files with cron job 64 Display CDR timestamp 60
Alarm Handling 152 BAD_DIGITS Display CDR version 60
alarm type Disconnect code 74 Display number of records 60
communications 153 BAD_ESN Display sequence numbers 60
equipment 153 Disconnect code 76 Displaying CDR records 54
processing error 153 BANDIT_MOBILE Freeing space for CDR records 64
alarm types 153 Disconnect code 76 Historic CDR records 57
alarms BEARER_SERVICE_UNAVAILABLE Listing CDR files 54
list of probable causes 154 Disconnect code 75 Removing transferred CDR files 58
probable causes 154 BHCA Storage capacity on OMC 35
ALERT_FAIL Traffic estimates 34 Summary of processed CDR files 61
Disconnect code 75 Billing server Traffic estimates and BHCA 34
Architecture configuring CDR push to billing server 49 Use cdr_reporter to display 54
Performance architecture 109 Verify CDR transfer 66 Verify CDR file generation 60
Archiving Binary View CDR for current day 56
Archiving transferred CDR files 58 Binary to XML conversion 66 Viewing CDR records for multiple days 57
ASCII CDR BSC Graphs and Statistics 129 What are Call Detail Records 30
Call Waiting 96 BSC graphs and statistics XML format 78
Forwarding 92 Emergency Calls 130 Call Processing
In-Call Feature 92 Feature 131 And MSC subsystems 166
Land-Originated Voice 88 Handoff 132 Graphs and statistics 114
Land-Terminated 83, 88 Location Updates 134 Traffic engineering 151
Mobile-Originated SMS 105 Mean Time 139 CALL_BARRED
Mobile-Originated Voice 83 MO Calls 135 Disconnect code 76
Mobile-Terminated 83, 84 Mobile Lost 140 Capacity
Mobile-Terminated Land 88, 89, 90, 93, 94, MT Calls 136 BHCA estimates 34
95 Pages 140 Storage capacity of CDR on MSC 33

2 Index
CDR Disconnect Codes 74 contacting 11 TELESERVICE_UNAVAILABLE 76

CDR Storage Capacity 33 TOLL_DENIED 76
cdr_info TRANSFER 77
Command usage 60 D TRANSLATE_LIMIT 75
Description of fields 61 DATA UNKNOWN_LOCATION_AREA 76
Example usage 60 Freeing space in DATA for CDR records 64 UNKNOWN_MOBILE 74
Using to verify CDR file generation 60 Data call UNKNOWN_SUB_ORIGINATION 76
cdr_reporter Accounting 31 USER_DEFINED_1 77
Command usage 55 Data Types USER_DEFINED_2 77
Convert binary CDR to ASCII 82 Binary CDR format 67 USER_DEFINED_3 77
Used to check CDR record corruption 62 DATABASE_ERROR USER_DEFINED_4 77
Used to display CDR records 54 Disconnect code 75 USER_DEFINED_5 78
Using to check CDR record generation 59 Delete USER_DEFINED_6 78
CFWD_LIMIT_EXCEEDED Deleting transferred CDR files 59 USER_DEFINED_7 78
Disconnect code 76 DELINQUENT_ACCOUNT USER_DEFINED_8 78
Checksum Disconnect code 76 USER_DEFINED_9 78
CDR record checking 62 Disconnect code VACANT_CODE 74
Size for CDR records 62 A_PARTY_ABORT 77 Disk
clearing A_PARTY_HANDOFF_FAIL 74 Typical MSC disk partition 33
automatic alarm clearing 153 A_PARTY_NORMAL_DISC 77 Disk Space
manual alarm clearing 154 A_PARTY_SAT_LOSS 74 For generating CDR records 63
CLI tool ALERT_FAIL 75 Disk space
cdr_info 60 AUTHENTICATION_FAILURE 76 Allocation of OMC disk 34
CLONE_ORIGINATION B_PARTY_ABORT 77 Calculating available disk space 63
Disconnect code 75 B_PARTY_BUSY 74 Freeing up space 65
Command B_PARTY_DENIED 74 Displaying CDR records 54
du 63 B_PARTY_HANDOFF_FAIL 74
Command option B_PARTY_NORMAL_DISC 77
cdr_info 60 B_PARTY_SAT_LOSS 74 E
cdr_reporter 55 BAD_DIGITS 74 Emergency Calls
du 64 BAD_ESN 76 BSC graphs and statistics 130
Command usage BANDIT_MOBILE 76 Graphs and statistics 114
cdr_info 60 BEARER_SERVICE_UNAVAILABLE 75 equipment
cdr_reporter 55 CALL_BARRED 76 alarm type 153
communications CFWD_LIMIT_EXCEEDED 76 EQUIPMENT_FAIL
alarm type 153 CLONE_ORIGINATION 75 Disconnect code 74
communications protocol error CONGESTION 75 Error checking
probable cause 154 DATABASE_ERROR 75 Check CDR records with cdr_reporter 55
configuration or customization error DELINQUENT_ACCOUNT 76 Example
probable cause 154 EQUIPMENT_FAIL 74 Call Detail Record 165
Configuration table FEATURE_CONFIRMATION 76 cdr_info usage 60
cdr-config 36 FEATURE_DENIED 76 Display Call Detail Records 163
Configuration window FEATURE_FAILED 76 Historical Call and SMS Detail Records 165
cdr-msc 38 FORCED_DISC 77 Historical SMS Detail Records 164
Configuring INTERNAL_RESOURCE_SHORTAGE 75 Output from cdr_info 61
CDR flush timer 35 INTERNAL_ROUTING_FAILURE 75 Summary of Call and SMS Detail
CDR record generation timer 36 INTERNATIONAL_DENIED 76 Records 166
Change MSCID 38 LONG_CALL_TIMEOUT 77
Configure MSCID using CLI 38 MISHANDLED 74
Configuring MSCID for CDR generation 35 MISROUTED_LNP_CALL 75 F
CONGESTION MOB_BELOW_DISC_THRESH 75 fault localization 156
Disconnect code 75 MOBILE_INACTIVE 77 faults
congestion MOBILE_UNAVAILABLE 77 recording faults 21
probable cause 154 NETWORK_CALL_FAIL 75 Feature
contacting NO_ANSWER 74 BSC graphs and statistics 131
technical documentation department 12 NO_CIRCUITS 74 FEATURE_CONFIRMATION
conventions, text 6 NO_PAGE_RESP 74 Disconnect code 76
Conversion NO_VOICE_CHANNEL 75 FEATURE_DENIED
CDR conversion log 66 ORIGINATIONS_DENIED 76 Disconnect code 76
corrupt data PROTOCOL_FAILURE 75 FEATURE_FAILED
probable cause 154 RESOURCE_SHORTAGE 75 Disconnect code 76
cron job ROAMING_BARRED 76 Field description
Automating transferred CDR file SETUP_SAT_LOSS 75 Description of fileds in cdr_info output 61
removal 59 SIGNALING_FAILURE 75 Transacted CDR fields 62
Backing up Trace files 64 STOLEN_UNIT 77 file error
customer service SUBSCRIBER_DISABLED 77 probable cause 154
Index 3
Filename Graphs and statistics 123 probable cause 154

Abort filenames 64 Media Control Out of Service
Trace file backups 64 And MSC subsystems 166 Probable Cause 155
Trace filename 64 MegGatewayAlarm 161
Filesystem path MISHANDLED
Absolute path 28 Disconnect code 74 P
Relative to home directory 28 MISROUTED_LNP_CALL Pages
Flush Disconnect code 75 BSC graphs and statistics 140
Configuring CDR record flush timer 35 ML CDR description 79 Graphs and statistics 125
FORCED_DISC MO Calls Parameters
Disconnect code 77 BSC graphs and statistics 135 For CDR transfer with FTP 52
Freeing space MOB_BELOW_DISC_THRESH Partition
For CDR records 64 Disconnect code 75 OMC disk partition size 35
Mobile Lost Performance Analysis 150
BSC graphs and statistics 140 Performance Architecture 109
G Mobile Originated Calls Performance History
Graphs Graphs and statistics 122 Long term performance history 110
BSC graphs 129 Mobile Terminated Calls short term performance history 109
Graphs and statistics Graphs and statistics 123 Performance Management 108
Emergency Calls 114 MOBILE_INACTIVE About 108
Inter MSC Handoff 117 Disconnect code 77 Performance Monitoring 110
Intra MSC Handoff 121 MOBILE_UNAVAILABLE Persistence
Mean Time 123 Disconnect code 77 Collect CDR on OMC 65
Mobile Originated Calls 122 Mobility Management power problem
Mobile Terminated Calls 123 And MSC subsystems 166 probable cause 155
Pages 125 Graphs and statistics 114 Probable Cause
SMS 127 Traffic engineering 151 Out of Service 155
MSC account 29 probable cause
MSC Subsystems 166 communications protocol error 154
H MSC subsystems configuration or customization error 154
Handoff Mobility Management, Call Processing, and congestion 154
BSC graphs and statistics 132 Media Control 166 corrupt data 154
Historic msc user file error 154
CDR records for multiple days 57 Default logon 29 out of memory 154
HLR Interrogations 116 Home directory 28 power problem 155
MSCID resource at or nearing capacity 155
Change using CLI 38 response time excessive 155
I Changing MSCID 38 software error 155
MT Calls software program abnormally
icons 6
BSC graphs and statistics 136 terminated 155
Inter MSC Handoff
Graphs and statistics 117 transmit failure 155
INTERNAL_RESOURCE_SHORTAGE underlying resource unavailable 155
Disconnect code 75 N unspecified reason 156
INTERNAL_ROUTING_FAILURE Network Management System 108 Process
Disconnect code 75 NETWORK_CALL_FAIL Binary to XML conversion process 66
INTERNATIONAL_DENIED Disconnect code 75 Processed CDR files 61
Disconnect code 76 NO_ANSWER processing error
Intra MSC Handoff Disconnect code 74 alarm type 153
Graphs and statistics 121 NO_CIRCUITS PROTOCOL_FAILURE
Disconnect code 74 Disconnect code 75
NO_PAGE_RESP
Disconnect code 74
L
LfmAlarmNoFreePort 158 NO_VOICE_CHANNELS R
Disconnect code 75 recording faults 21
Listing CDR files 54
notices 6 Removing
Location Updates
BSC graphs and statistics 134 removing Abort and Trace files 65
Log file Removing transferred CDR files 58
acc_trans.log 66 O Transferred CDR files with cron job 59
LONG_CALL_TIMEOUT OMC Reports
Disconnect code 77 CDR conversion log 66 BSC reports 129
Disk space allocation 34 resource at or nearing capacity
Removing transferred CDR files 58 probable cause 155
Storage capacity for transferred CDR 35 RESOURCE_SHORTAGE
M
manual alarm clearing 153, 154 ORIGINATIONS_DENIED Disconnect code 75
Disconnect code 76 response time excessive
Mean Time
out of memory probable cause 155
BSC graphs and statistics 139

4 Index
ROAMING_BARRED Tracing modules 169 vi

Disconnect code 76 Traffic Engineering 150 Used to edit trans.conf 46, 52
Call Processing 151 Viewing
Mobility Management 151 Call and SMS Detail Records 164
S Traffic engineering 150 SMS Detail Records 163
SETUP_SAT_LOSS Transaction summary vlog
Disconnect code 75 CDR transaction summary 61 Used to view transacted CDR 61
SIGNALING_FAILURE TRANSFER View current day CDR 56
Disconnect code 75 Disconnect code 77 Viewing CDR for multiple days 57
SMS Transfer VsmAlarmInvalidPort 161
BSC graphs and statistics 142 Archiving transferred CDR files 58 VsmAlarmStateChngFail 161
Graphs and statistics 127 TRANSLATE_LIMIT VsmAlarmTrunkFault 160
SMS Detail Records Disconnect code 75
Viewing 163 transmit failure
software error probable cause 155 W
probable cause 155 Trouble Locating and Clearing 162 warranty support 11
software program abnormally terminated Troubleshooting
probable cause 155 Trouble Locating and Clearing 162
SsfAlarmNoFreeCS 158 Trunk Group X
SsfAlarmNoFreeCSA 158 Detail report 112 XML
SsfAlarmNoFreeOBCSM 159 Summary reports 110 Binary to XML conversion 66
SsfAlarmNoFreeSSF 159 Traffic engineering 150 XML CDR
SsfAlarmNoFreeTBCSM 159 Voice call 80
Standard XML tag
GR-508-CORE 30 U Description of XML CDR tags 79
ITU-T Recommendation Q.825 30 underlying resource unavailable
Statistics probable cause 155
BSC statistics 129 UNKNOWN_LOCATION_AREA
STOLEN_UNIT Disconnect code 76
Disconnect code 77 UNKNOWN_MOBILE
Storage Capacity Disconnect code 74
CDR storage capacity 33 UNKNOWN_SUB_ORIGINATION
For CDR on OMC 34 Disconnect code 76
SUBSCRIBER_DISABLED unspecified reason
Disconnect code 77 probable cause 156
System resources Usage
CDR billing 31 BSC graphs and statistics 146
User account
msc account 29
T USER_DEFINED_1
t_file Disconnect code 77
CDR record generation timer 36 USER_DEFINED_2
Parameters 37 Disconnect code 77
t_log_flush USER_DEFINED_3
CDR record flush timer 35 Disconnect code 77
Defaults and range 35 USER_DEFINED_4
technical support Disconnect code 77
hours 11 USER_DEFINED_5
services 11 Disconnect code 78
website 11 USER_DEFINED_6
TELESERVICE_UNAVAILABLE Disconnect code 78
Disconnect code 76 USER_DEFINED_7
Timer Disconnect code 78
CDR record generation timer 36 USER_DEFINED_8
Configuring CDR record flush timer 35 Disconnect code 78
Default and range for t_log_flush 35 USER_DEFINED_9
t_log_flush 35 Disconnect code 78
TOLL_DENIED
Disconnect code 76
Trace file V
Backup Trace files using cron job 64 VACANT_CODE
Trace files Disconnect code 74
Removing 65 Verify
Traceable modules CDR persistence on OMC 65
List of 169 CDR record generation 59
Tracing Verify CDR file generation 60
Copyright 2009 Global Star Solutions ULC
Global Star Solutions ULC

120-4600 Jacombs Road
Richmond, British Columbia V6V 3B1 Canada
www.starsolutions.com

MSC SErver O&amp;M Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

MSC SErver O&amp;M Guide

Загружено:

Авторское право:

Доступные форматы

All-IP CDMA2000

Sonata Core Voice Network

Part Number D02115 Rev A0

Part Number D02115 Rev A0

UNITED STATES GOVERNMENT LEGENDS:

CDMA2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA).

ABOUT THIS GUIDE

PART II OPERATIONS, ADMINISTRATION AND MAINTENANCE

2 OPERATIONS, ADMINISTRATION, AND MAINTENANCE OVERVIEW

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Check MGCP Link Status - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 25

3 USER ACCOUNTS AND F ILESYSTEMS

4 CONFIGURING CALL DETAIL RECORDS

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Configuring the OMC for the Push Model - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 49

5 VIEWING AND MANAGING CALL DETAIL RECORDS

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Mobile-Originated Voice Scenarios - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 83

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Location Updates (BSC facing)- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 134

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

MSC and VLR Alarms - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 156

8 TROUBLE LOCATING AND CLEARING

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Figure 53 Example: Call Waiting - Call Waiting Call - - - - - - - - - - - - - - - - - - - - - - - - - - 97

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Figure 107 Mean Time Interval for Handoff Out - - - - - - - - - - - - - - - - - - - - - - - - - - - - 139

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

The About this Guide section includes:

Notices Table 1 lists notice icons used in this guide.

Table 1 Notice Icon Descriptions

Icon Notice Type Description

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Table 1 Notice Icon Descriptions (continued)

Icon Notice Type Description

Text Table 2 lists text conventions in this guide.

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

the three-way call functionality, and operations, maintenance, and provisioning

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Figure 1 Core Voice Network Document Map

Before contacting technical support, have this information available:

For information about customer service, including support, training, code

Service Centers Operational Hours

EMEA/Asia Pacific Region:

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

Contacting Technical To provide comments on this documentation, send an e-mail to:

This chapter includes:

Figure 2 Sonata Release 4.5.3 System Architecture

CDMAAir PrivateIPNetwork Telco

MSC/VLR* OMC/FS HLR

BTS BSC MGW PSTN

OM C OperationsandM aintenanceCenter MSC M obileSwitchingCenter HLR Hom eLocationRegister

Sonata Core Voice NetworkRelease 4.5.3MSC ServerOperations and Maintenance Guide

A Softswitch is software that decomposes call logic from a traditional

The MSC Server System is independent of the transmission backbone and

Chapter 2 Operations, Administration, and Maintenance Overview

Chapter 3 User Accounts and Filesystems

Chapter 4 Configuring Call Detail Records

Chapter 5 Viewing and Managing Call Detail Records

Chapter 6 Performance Management

Chapter 7 Alarm Management

Chapter 8 Trouble Locating and Clearing

MSC SErver O&M Guide

MSC SErver O&M Guide

* Total number of MGCP resource is 31 *