aDMSCBILL 5 9 PDF

Q272-1
UMTS Network Signalling Systems

GSM/UMTS MSC Billing and Accounting
Specification
SIM Specification (Approved)
MSCS19 APP 5.9 17th July 2006

This is a blank page.
The information disclosed herein is proprietary to Nortel or others, and is not to be used or disclosed to unauthorised persons without
the written consent of Nortel. The recipient of this document shall respect the security status of the information.
This document and the information contained herein is provided as is with no warranty of any kind, expressed or implied.This includes,
but is not limited to, the implied warranties of merchantability or fitness for any particular purpose. The entire risk as to quality and
performance of such information is with the user. Should the information prove defective, the user assumes the cost of all necessary
servicing, repair, or correction. In no event is Nortel liable for any damages, direct, indirect, or consequential.
Nortel may, but is not obliged to, update the information, or arrange for the information to be updated, and make the updates available to
users from time to time.
The master copy of this document is stored in electronic format, and any hard copies or soft copies used for distribution are
uncontrolled. For information on how to obtain the latest version refer to the Product Planning (Switching) Document Control Process
Ref. NQAPR103 .
2005 - 2006 Nortel
GSM/UMTS MSC Billing and Accounting Specification
MSCS19
Document Number: Q272-1
Document Status: APP 5.9
Classification: Standard
Activity: 19412375
Date: 17th July 2006
GSM/UMTS MSC Billing and Accounting Specification
SIGN OFF
Issue: APP 5.9 (Approved)
This document adheres to the Strategic Interface Management (SIM) process. The SIM process is
an administrative process developed to co-ordinate the evolution of interface specifications with
that of the interface implementations they describe. It is described in detail in the following
document:
NQAPR102: Strategic Interface Management (SIM) Process for Product Planning (Switching)
An interface document that follows the SIM process is promoted through the following status
levels:
DRAft During requirements capture and clarification, and in the early stages of high-level
design, DRAft SIM specifications describe the functionality that is required and
what is to be provided.
PREliminary When requirements are understood and the scope of the implementation has been
decided, PREliminary SIM specifications provide an increasingly accurate view of
the functionality that is to be provided, reflecting detailed design decisions and the
progress of interface implementation.
AUThorised When detailed design and implementation are complete, an AUThorised SIM
specification provides a detailed description of interface operation, for use in Nortel
product testing.
APProved When Nortel product testing is complete, an APProved SIM specification provides a
detailed description of the operation of the tested interface, for use in VO / field trial.
VERified Following final verification of the interface in the field, a VERified SIM
specification is made generally available to provide a detailed description of the
operation of the verified interface.
The document uses an x.y numbering format. Changes made to the document within a status level
and as it moves to another status level are indicated by stepping 'y'. Subsequent major updates to
this document require that 'x' is stepped and that the SIM process is reapplied.
Q272-1 GSM/UMTS MSC Billing and Accounting Specification
APP 5.9 Standard MSCS19
17th July 2006 (Approved) Page: v
Revision Information
Revision Issue Date Act ID Description of Changes
DRA 0.1 May 2001 10-01-0047 First draft of the specification for the GSM14/UMTS01 product release.
DRA 0.2 July 2001 10-01-0047 Second draft produced after formal review.
AUT 0.3 July 2001 10-01-0047 Specification raised to AUT status after being signed off.
APP 0.4 (Draft) September 2001 10-01-0047 Specification created to capture comments from product testing, verification etc.
APP 0.5 October 2001 10-01-0047 Specification raised to APP status after being signed off.
DRA 1.0 October 2001 10-01-0063 First draft of the specification for the GSM15/UMTS02 product release.
PRE 1.1 December 2001 10-01-0063 Second draft produced after formal review meeting.
PRE 1.2 January 2002 10-01-0063 Third draft produced after second formal review meeting.
AUT 1.3 March 2002 10-01-0063 Specification raised to AUT status after being signed off.
APP 1.4 March 2002 10-01-0063 Specification updated with further comments.
APP 1.5 April 2002 10-01-0063 Specification raised to APP status after being signed off.
VER 1.6 (Draft) July 2002 10-01-0063 Specification updated with further comments.
VER 1.7 July 2002 10-01-0063 Specification raised to VER status after being signed off.
VER 1.8 August 2002 10-01-0063 Specification updated with final comment post sign-off.
DRA 2.0 August 2002 10-02-0039 First draft of the specification for the GSM16/UMTS03 product release.
PRE 2.1 September 2002 10-02-0039 Second draft produced incorporating review comments.
PRE 2.2 September 2002 10-02-0039 Third draft incorporating further review comments.
PRE2.3 September 2002 10-02-0039 Fourth draft incorporating further review comments.
PRE 2.4 October 2002 10-02-0039 Fifth draft incorporating comments from formal review meeting.
AUT 2.5 October 2002 10-02-0039 Specification raised to AUT status after being signed off.
APP 2.6 (Draft) December 2002 10-02-0039 Specification draft opened to capture further comments.
APP 2.7 December 2002 10-02-0039 Specification raised to APP status after being signed off.
DRA 3.0 March 2003 6936005 First draft of the specification for the NSS17 product release.
DRA 3.1 March 2003 6936005 Second draft of the specification updated with comments.
PRE 3.2 May 2003 6936005 Third draft created after a formal review.
AUT 3.3 June 2003 6936005 Specification raised to AUT status after being signed off.
APP 3.4 (Draft) August 2003 6936005 Specification draft created to capture further comments.
APP 3.5 (Draft) September 2003 6936005 Draft created to capture further comments.
APP 3.6 September 2003 6936005 Specification raised to APP status after being signed off.
VER 3.7 (Draft) February 2004 6936005 Specification reopened to capture further comments.
VER 3.8 (Draft) March 2004 6936005 Draft created to capture further comments.
VER 3.9 March 2004 6936005 Specification raised to VER status after being signed off.
DRA 4.0 October 2004 12557317 First draft of the specification for the NSS18/UMTS04 product release.
DRA 4.1 November 2004 12557317 Specification updated after review meeting.
DRA 4.2 November 2004 12557317 Specification updated.
PRE 4.3 December 2004 12557317 Specification updated after review meeting.
PRE 4.4 December 2004 12557317 Final comments incorporated.
AUT 4.5 December 2004 12557317 Specification raised to AUT status after being signed off.
APP 4.6 (Draft) February 2005 12557317 Specification draft created to capture further comments.
GSM/UMTS MSC Billing and Accounting Specification Q272-1
MSCS19 Standard APP 5.9
Page: vi (Approved) 17th July 2006
APP 4.7 (Draft) March 2005 12557317 Specification draft updated.
APP 4.8 (Draft) March 2005 12557317 Specification updated after a review meeting.
APP 4.9 March 2005 12557317 Specification raised to APP status after being signed off.
VER 4.10 (Draft) March 2006 12557317 Specification reopened to capture further comments.
VER 4.11 (Draft) May 2006 12557317 Further comments added.
VER 4.12 (Draft) June 2006 12557317 Further comments added.
VER 4.13 June 2006 12557317 Specification raised to VER status after being signed off.
DRA 5.0 October 2005 19412375 First draft created for the MSCS19 release.
DRA 5.1 November 2005 19412375 Draft updated after a review meeting.
DRA 5.2 December 2005 19412375 Draft updated after further review.
AUT 5.3 December 2005 19412375 Specification raised to AUT status after being signed off.
APP 5.4 (Draft) April 2006 19412375 Specification draft created to capture further comments.
APP 5.5 (Draft) May 2006 19412375 Further comments added.
APP 5.6 (Draft) May 2006 19412375 Further comments added.
APP 5.7 May 2006 19412375 Specification raised to APP status after being signed off.
APP 5.8 (Draft) July 2006 19412375 Specification draft created to capture further comments.
APP 5.9 July 2006 19412375 Specification signed off and approved.
Revision Issue Date Act ID Description of Changes
17th July 2006 (Approved) Page: vii
About this Specification
Scope
This specification describes the subscriber billing, account settlement and tariff data administration
capabilities of the GSM/UMTS MSC. The specification includes full details of the billing and
accounting record structures and associated data fields supported by the MSC. It also describes the
circumstances in which the records are produced. The tariff data required in the MSC for the
support of the supplementary service Advice of charge is also described. The specification
describes the full capabilities of the MSC and does not take account of service provision or product
packaging which may reduce the amount of billing information generated in particular network
implementations.
In general the procedures and definitions of the 3GPP technical specification (TS) 32.250 are used
in the Nortel implementation. However, the MSC does not support all of the features of 3GPP TS
32.250. The purpose of this specification is to describe (for the features supported) the Nortel
implementation and interpretation of the functionality specified in 3GPP TS 32.250. In other words,
this specification does not specify compliance to 3GPP TS 32.250, though as far as possible it uses
the terms of that reference specification. In addition the specification describes Nortel proprietary
capabilities.
For billing purposes, the MSC is connected to SuperNode Billing Application (SBA) which is
located on the Core and Billing Manager (CBM) hardware platform. The SBA on the CBM
provides a robust, fault-tolerant server which supports the full range of Nortels billing capabilities
and provides a choice of file transfer protocols for transferring the billing information to the billing
domain (billing system or a mediation device).
Page: viii (Approved) 17th July 2006
Structure
The specification is divided into five parts each dealing with a different aspect of billing:
Part A provides an overview of billing and accounting requirements and lists the
features incorporated in recent Nortel GSM/UMTS releases.
Part B describes the circumstances under which GSM/UMTS Call Detail Records
(CDRs) are produced and provides full details of the structure and content of the
records.
Part C describes the tariff administration system which allows operators to specify the
tariff data required to support the Advice of Charge (AoC) supplementary service and
also the AoC for Multiple Rate Plans (AoC MRP) service.
Part D provides answers to some frequently asked questions.
Documentation Conventions
Throughout this document unsupported functions or code points are indicated by the text being
struck through. In this context unsupported functionality means the following:
If entire structures are struck through, these will not be generated by the MSC.
If, however fields within structures are struck through, these fields shall be present in the
overall structure but will be filled with a default value.
New functions or code points are highlighted using underlined text. Modified functions or code
points are also highlighted in this way.
References and Sample Information
Sample Billing CDs
Name NCL Order Code Media Description
GOSSGBSN0190 GBSN0190 CDROM NSS19 Sample Billing SBA North America
GOSSGBSW0190 GBSW0190 CDROM NSS19 Sample Billing SBA World Trade
17th July 2006 (Approved) Page: ix
Standards
[1] 3GPP TS 23.032, version 6.0.0: Universal Geographical Area Description (GAD)
[2] 3GPP TS 23.078 version 6.6.0: Customised Applications for Mobile network
Enhanced Logic (CAMEL) Phase 3 - Stage 2
[3] 3GPP TS 23.107, version 6.3.0: QoS Concept and Architecture
[4] 3GPP TS 23.207, version 6.5.0: End-to-End QoS Concept and Architecture
(Release 5).
[5] 3GPP TS 24.008, version 6.9.0: Mobile radio interface layer 3 specification; Core
Network Protocols - Stage 3
[6] 3GPP TS 24.011, version 6.1.0: Point-to-Point (PP) Short Message Service (SMS)
support on mobile radio interface
[7] 3GPP TS 24.080, version 6.3.0: Mobile radio interface layer 3 Supplementary
services specification Formats and coding.
[8] 3GPP TS 25.305, version 6.1.0: User Equipment (UE) positioning in Universal
Terrestrial Radio Access Network (UTRAN); Stage 2
[9] 3GPP TS 29.002, version 6.10.0: Mobile Application Part (MAP) specification
[10] 3GPP TS 29.078 version 6.4.0: CAMEL Phase 3; CAMEL Application Part
(CAP) specification
[11] 3GPP TS 32.200, version 5.7.0: Charging management; Charging principles
[12] 3GPP TS 32.205, version 5.8.0: Charging management; Charging data description
for the Circuit Switched (CS) domain
[13] 3GPP TS 43.059: Functional stage 2 description of Location Services (LCS) in
GERAN
[14] 3GPP TS 44.068, version 6.0.0: Group Call Control (GCC) protocol
[15] 3GPP TS 44.069, version 6.0.0: Broadcast Call Control (BCC) protocol
[16] 3GPP TS 48.008, version 6.10.0: (MSC - BSS) interface; Layer 3 specification
[17] American National Standard T1.113-1995: Signalling System No. 7 (SS7) --
Integrated Services Digital Network (ISDN) User Part
[18] ITU-T Recommendation Q.850 (03/93): Usage of cause and location in the Digital
Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part
Page: x (Approved) 17th July 2006
Nortel Documentation
[19] 411-4231-301: GSM/UMTS VCN Billing Application OA&M Manual.
[20] 411-2231-451, Volumes 1 and 2: Call Server Customer Data Schema
[21] 411-2231-455: GSM MSC / UMTS CCN CS Office Parameters Reference Manual
Translations
[22] NTP 411-3001-2202: Translations Guide Volume 2 of 2
[23] AD9239: World Trade versus North American ANSI ISUP
Abbreviations
3GPP 3rd Generation Partnership Project
AAL2 ATM Adaptation Layer type 2
AC Apply Charging
ACM Address Complete Message
ACR Apply Charging Report
aTCA Advanced Telecom Computing Architecture
AIN Advanced Intelligent Network
AMA Automatic Message Accounting
AMR Adaptive Multi-Rate
AN Access Number
ANI Automatic Number Identification
ANM The ISUP Answer message
ANN Answer No Charge message
ANSI American National Standards Institute
AoC Advice of Charge
ASSP Assisting Service Switching Point
AT Access Tandem
ATM Asynchronous Transfer Mode
ATUP Australian Telephone User Part
BACCS Billing, Administration and Customer Care System
BAF Bellcore Automatic Message Accounting Format
BCD Binary Coded Decimal
BICC Bearer Independent Call Control
BICN Bearer Independent Core Network
17th July 2006 (Approved) Page: xi
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
BTUP British Telecom User Part
CAI Charge Advice Information
CAMA Centralized Automatic Message Accounting
CAMEL Customised Applications of Mobile-network Enhanced Logic
CBM Core Billing Manager
CA Call Agent
CC Circuit Core
CCS7 Common Channel Signalling System No. 7
CDA Circuit-Switched Duplex Asynchronous (data)
CDN Called Party Number
CDR Call Detail Record
CDS Circuit-Switched Duplex Synchronous (data)
CFT Cause For Termination
CFU Call Forwarding Unconditional
CIC Carrier Identification Code (used in ANSI ISUP for PCS 1900 networks and also in
ITU-T ISUP)
CISS Call Independent Supplementary Service
CLI Calling Line Identity/Identifier
CLIP Calling Line Identity Presentation
CLIR Calling Line Identity Restriction
CNAM Calling Name
COLP Connected Line Identification Presentation
COLR Connected Line Identification Restriction
CPC Calling Party Category
CR Change Request
CRSS Call Related Supplementary Service
CS Circuit-Switched
CSD Circuit-Switched Data
CSI CAMEL Subscription Information
CTM-TTY Cellular Text Modem Text Telephony
CTU CTM capable transcoder units
CUG Closed User Group
CWC City Wide Centrex (used in Singapore)
Page: xii (Approved) 17th July 2006
DIRP Device Independent Recording Package
DMS Digital Multiplex System
DN Directory Number
DP Detection Point
DRM Distributed Recording Manager
DSH Default SMS Handling
DSP Down Stream Processor
EA Equal Access
ECT Explicit Call Transfer
EDP Event Detection Point
EDP-R Event Detection Point Request
EDP-N Event Detection Point Notification
EFD Event Forwarding Discriminator
EIR Equipment Identity Register
EIU Ethernet Interface Unit
eMLPP Enhanced Multi-Level Precedence and Pre-emption (for GSM-R)
EOTD Enhanced Observed Time Difference
ESRD Emergency Service Routing Digits
ESRK Emergency Service Routing Key
ETC EstablishTemporaryConnection
ETSI European Telecommunications Standards Institute
FA Functional address(ing) (for GSM-R)
FAR The ISUP Facility Request Message
FCI The INAP Furnish Charging Information Message
FOC Full Operating Capability
FPE Feature Processing Environment
FSN File Sequence Number
FTP File Transfer Protocol
GAD Geographical Area Description
GCI Global Cell Identifier
GMLC Gateway Mobile Location Centre
GMSC Gateway MSC
GPS Global Positioning System
GRNCid Global Radio Network Controller Identifier
GSM-R GSM for Railways
gsmSCF GSM Service Control Function
17th July 2006 (Approved) Page: xiii
Hex Hexadecimal
HLR Home Location Register
HPLMN Home PLMN
IAM ISUP Initial Address Message
IBN Integrated Business Network
IBN MF IBN Multi-Frequency (a trunk type)
IBN7 IBN CCS7 (a trunk type)
IC Inter-Exchange Carrier
IETF Internet Engineering Task Force
IMEI International Mobile Equipment Identity
IMEISV IMEI Software Version number
IMSI International Mobile Subscriber Identity
IN Intelligent Network
INAP IN Application Part
INC International Carrier
INIC ISDN Network Identifier Code
IOC Input-Output Controller
IP Intelligent Peripheral (in Intelligent Networking)
Internet Protocol (in packet networking)
IPDL Idle Period Downlink
ISDN Integrated Services Digital Network
ISO International Organisation for Standardization
ISUP ISDN User Part
I-ISUP Australian Interconnect ISUP
ITU International Telecommunication Union
ITU-T ITU - Telecommunication Standardisation Sector
IVR Intelligent Voice Recognition
IWF Inter-Working Function
IXC Inter-Exchange Carrier
LAC Location Area Code
LAN Local Area Network
LATA Local Access and Transit Area
LCS Location Services
LEC Local Exchange Carrier
LIU7 Link Interface Unit for CCS7 connectivity
LNP Local Number Portability (a service used in PCS-1900 networks)
Page: xiv (Approved) 17th July 2006
LPP Link Peripheral Processor
LRD Location Related Data
LRN Location Routing Number
MAP Mobile Application Part
MCC Mobile Country Code
MGW Media Gateway
MLC Mobile Location Centre
MMI Man Machine Interface
MNC Mobile Network Code
MNP Mobile Number Portability
MNP-SRF MNP Signalling Relay Function
MOC Mobile Originated Call
MO-LR/MOLRMobile Originated Location Request
MRP Multiple Rate Plan
MSC Mobile Services Switching Centre
MSC/SSP MSC Service Switching Point
MSISDN Mobile Station International ISDN Number
MSRN Mobile Station Roaming Number
MSU MSC Scalable Unit
MTC Mobile Terminated Call
MT-LR/MTLRMobile Terminated Location Request
MTUP Mobile Telephone User Part (used to be CTUP - Chinese Telephone User Part)
NANP North American Numbering Plan
NCOS Network Class of Service
NDUB Network Determined User Busy
NE Network Element
NEF Network Element Function
NI-LR/NILR Network Initiated Location Request
NIRR Negotiation of Intermediate Rate Requested
NOA Nature of Address
NPA Numbering Plan Area
NPDB Number Portability Database
NPI Numbering Plan Indicator
NQI Number Qualifier Indicator
NSEP National Security Emergency Preparedness
NSS Network Sub System
17th July 2006 (Approved) Page: xv
NTP The ANSI ISUP Network Transport Parameter (carried in IAM and ACM)
OACSU Off Air Call Set Up
OMC Operations and Maintenance Centre
OR Optimal Routing
OS Operations System
OSF Operations System Function
OTDOA Observed Time Difference Of Arrival
PAD Packet Assembly/Disassembly
PCS Personal Communications System
PET PCS-1900 Equal-Access Trunk
PET MF PET Multi-Frequency Trunk
PET7 PET CCS7 (ISUP) Trunk
PLMN Public Land Mobile Network
PRI Primary Rate Interface
PRN The MAP ProvideRoamingNumber message
PSAP Public Safety Answering Point
PSL Provide Subscriber Location
PSPDN Packet switched public data network
PSTN Public Switched Telephone Network
RBT Ring Back Tone
RLT Release Link Trunk
RNC Radio Network Controller
RTT Round Trip Time
SAC Service Area Code
SAI Service Area Identifier
SBA Supernode Billing Application
SBS Supernode Billing Server
SCF Service Control Function (IN)
SCP Service Control Point (IN)
SFTP SSH (Secure Shell) File Transfer Protocol
SIM Subscriber Identity Module
SLR Subscriber Location Request
SMB Supernode Multi-computing Base
SMLC Serving Mobile Location Centre
SMS Short Message Service
SMS-SC SMS Service Centre
Page: xvi (Approved) 17th July 2006
SOC Software Optionality Control
SRI The MAP Send Routing Information message
SS Supplementary Service
SSA Supplementary Service Action
SSF Service Switching Function (IN)
SSH Secure Shell
SSP Service Switching Point (IN)
SVN Software Version Number (part of the IMEISV)
TACC Tariff Administration Change Control
TCAP Transaction Capabilities Application Part
TDOA Time-Difference-Of-Arrival
TDP Trigger Detection Point
TMN Telecommunications Management Network
TMSI Temporary Mobile Subscriber Identity
TON Type of Number
TS Technical Specification
TUP Telephone User Part
UDI Unrestricted Digital Information
UE User Equipment
UMTS Universal Mobile Telephony System
USSD Unstructured Supplementary Service Data
UTC Coordinated Universal Time
UXLA Universal Translations
VAS Value Added Service
VBS Voice Broadcast Service (for GSM-R)
VGCS Voice Group Call Service (for GSM-R)
VLR Visitor Location Register
VMCDB Voice mail call dropback
VMSC Visited MSC
VoATM Voice over Asynchronous Transfer Mode
VoIP Voice over Internet Protocol
VPLMN Visited PLMN
WPS Wireless Priority Service
XCLI See CLI
Q272-1 Standard GSM/UMTS MSC Billing and Accounting Specification
APP 5.9 MSCS19
17th July 2006 (Approved) Page: xvii
Table of Contents
About this Specification................................................................................................................... vii
Scope................................................................................................................................................ vii
Structure.......................................................................................................................................... viii
Documentation Conventions........................................................................................................... viii
References and Sample Information............................................................................................... viii
Abbreviations......................................................................................................................................x
Part A
Introduction
A1 Overview of MSC and Billing Requirements...............................................................................3
A1.1 Introduction to the GSM/UMTS MSC .............................................................................3
A1.2 Charging Requirements in GSM/UMTS Standards..........................................................4
A1.3 MSCs Support of Requirements......................................................................................5
A1.4 MSC Configuration...........................................................................................................5
A2 Billing and Accounting Features ..................................................................................................7
A2.1 Billing Feature Development............................................................................................7
A2.1.1 Feature Development ............................................................................................7
A2.1.2 Market-Specific Features....................................................................................10
A2.1.3 Change Request (CR) Updates ...........................................................................11
A2.2 Other Changes.................................................................................................................12
A2.3 List of Changed Pages ....................................................................................................14
A2.4 Feature Information ........................................................................................................16
A2.4.1 UMTS and GSM Features ..................................................................................16
A2.4.2 GSM Railways (GSM-R) Features .....................................................................23
Part B
Billing Records and Formats
B1 Introduction.................................................................................................................................27
B1.1 Overview of Billing Requirements .................................................................................27
B1.2 MSC Billing System.......................................................................................................28
B1.2.1 Overview.............................................................................................................28
B1.2.2 Billing File Storage and Storage Capacity on the CBM.....................................30
B2 Billing Files and CDRs ...............................................................................................................31
B2.1 Production of the Billing File .........................................................................................31
B2.2 Format of the Billing File on Disk..................................................................................32
B2.2.1 File Format..........................................................................................................32
B2.2.2 Production of Auxiliary Records ........................................................................34
B2.3 Sample Billing Information ............................................................................................34
B2.4 File Naming Conventions ...............................................................................................34
B2.4.1 Conventions used by the SBA Management Function .......................................34
GSM/UMTS MSC Billing and Accounting Specification Standard Q272-1
MSCS19 APP 5.9
Page: xviii (Approved) 17th July 2006
B2.5 The MSC CDR Structure................................................................................................35
B3 Production of Call Detail Records ..............................................................................................37
B3.1 General............................................................................................................................37
B3.2 Use of Supplementary Services ......................................................................................38
B3.2.1 CISS Actions.......................................................................................................38
B3.2.2 Call Related SS Actions......................................................................................38
B3.2.3 Use of Call Forwarding.......................................................................................38
B3.2.4 Use of the Call Hold Service ..............................................................................39
B3.2.5 Use of the Multiparty Service.............................................................................39
B3.3 Inter MSC Handover.......................................................................................................40
B3.4 Generation of Partial Records.........................................................................................40
B3.4.1 Overview.............................................................................................................40
B3.4.2 General Information on Partial Records .............................................................41
B3.4.3 Partial Record Production - Exceeding of Record Size Limitation....................42
B3.4.4 Partial Record Production - Expiry of the Partial Record Timer........................42
B3.4.5 Partial Record Production - Call Re-establishment ............................................44
B3.5 Hot Billing ......................................................................................................................44
B3.6 Proprietary Billing Services............................................................................................46
B3.6.1 Distance Based Billing........................................................................................46
B3.6.2 Call Record Type Indication...............................................................................46
B3.7 Call Release Cause Reporting.........................................................................................46
B3.8 Controlling the Information that the MSC Generates.....................................................49
B3.8.1 Office Parameters and Table Datafill .................................................................49
B3.8.2 Software Optionality Control (SOC) ..................................................................56
B3.8.3 Office Alarms for Billing....................................................................................58
B4 Structured Records and Modules................................................................................................59
B4.1 Structured Record Contents ............................................................................................59
B4.1.1 Mobile Originated Call Attempt .........................................................................60
B4.1.2 Mobile Terminated Call Attempt .......................................................................61
B4.1.3 Roaming Call Attempt .......................................................................................62
B4.1.4 Incoming Gateway Call Attempt .......................................................................63
B4.1.5 Outgoing Gateway Call Attempt .......................................................................64
B4.1.6 Transit Call Attempt ..........................................................................................65
B4.1.7 Short Message Service, Mobile Originated .......................................................66
B4.1.8 Short Message Service, Mobile Terminated ......................................................67
B4.1.9 Incoming Intra-PLMN Trunk Record ................................................................68
B4.1.10 Outgoing Intra-PLMN Trunk Record ................................................................69
B4.1.11 Common Equipment Usage Record ..................................................................70
B4.1.12 Supplementary Service Action Record ..............................................................71
B4.1.13 Location Services (LCS) Record .......................................................................73
B4.1.14 Acknowledgement Record .................................................................................74
B4.1.15 Location Update Record ....................................................................................75
B4.1.16 Time Change Record .........................................................................................76
B4.1.17 Switch Restart Record .......................................................................................76
B4.1.18 Billing Block Header Record .............................................................................77
APP 5.9 MSCS19
17th July 2006 (Approved) Page: xix
B4.1.19 Billing File Transfer In Record ..........................................................................77
B4.1.20 Billing File Transfer Out Record .......................................................................78
B4.2 Module Contents.............................................................................................................79
B4.2.1 End of Module List Module................................................................................80
B4.2.2 Bearer Service Information Module ..................................................................80
B4.2.3 Location and Channel Information Module .......................................................81
B4.2.4 Supplementary Services Information Module ...................................................83
B4.2.5 Teleservices Information Module ......................................................................91
B4.2.6 AoC Parameter Information Module .................................................................92
B4.2.7 Tariff Class Information Module........................................................................93
B4.2.8 Data Service Information Module .....................................................................93
B4.2.9 Other Agent Information ....................................................................................95
B4.2.10 Location Only Information Module....................................................................95
B4.2.11 Equal Access Information Module ....................................................................96
B4.2.12 Partial Information Module ................................................................................97
B4.2.13 Trunk Usage Information Module ......................................................................97
B4.2.14 IN Information Module ......................................................................................98
B4.2.15 IN Charging Information Module (CS-1R INAP Services) .............................101
B4.2.16 Generic Address Information Module .............................................................102
B4.2.17 Network Call Reference Information Module .................................................103
B4.2.18 CAMEL Charging Information Module ..........................................................104
B4.2.19 Mobile Number Portability Information Module .............................................105
B4.2.20 GSM Assisting SSP (ASSP) Information Module ...........................................106
B4.2.21 CAMEL Short Message Service (SMS) Information Module..........................107
B4.2.22 Patching Information Module ..........................................................................108
B4.2.23 Bearer Independent Core Network Information Module .................................109
B4.3 Market-Specific Modules .............................................................................................110
B4.3.1 Originator-Terminator Information Module ....................................................110
B4.3.2 Toll Free Information Module .........................................................................111
B4.3.3 Local Number Portability (LNP) Information Module ....................................111
B4.3.4 Singapore Specific Information Module...........................................................112
B4.3.5 Carrier Selection Charging Information Module .............................................113
B5 Data Field Descriptions ............................................................................................................115
B5.1 Overview.......................................................................................................................115
B5.2 Data Fields ....................................................................................................................116
B5.2.1 Access Media Type...........................................................................................123
B5.2.2 Access Network ................................................................................................124
B5.2.3 Additional Information .....................................................................................124
B5.2.4 Advice of Charge Parameter Reason................................................................125
B5.2.5 Age of Location Information ............................................................................125
B5.2.6 Answer Time.....................................................................................................125
B5.2.7 Auxiliary Record Header ..................................................................................126
B5.2.8 Backbone Media Type ......................................................................................126
B5.2.9 BCD or Full Hex String....................................................................................127
B5.2.10 BCD or Hex String(N) ......................................................................................127
MSCS19 APP 5.9
Page: xx (Approved) 17th July 2006
B5.2.11 Bearer Service...................................................................................................128
B5.2.12 Block Count ......................................................................................................128
B5.2.13 Block Number...................................................................................................128
B5.2.14 Boolean Type....................................................................................................129
B5.2.15 Call Duration.....................................................................................................129
B5.2.16 Call Forward Indicator......................................................................................131
B5.2.17 Call Indicator ....................................................................................................131
B5.2.18 Call Reference...................................................................................................132
B5.2.19 Call Type Code .................................................................................................132
B5.2.20 Called Equipment (or Served Equipment)........................................................133
B5.2.21 Called IMSI Number ........................................................................................134
B5.2.22 Called Number (or Served Number).................................................................134
B5.2.22.1 Mobile Originated Record .....................................................................135
B5.2.22.2 Mobile Terminated Record ....................................................................135
B5.2.22.3 Roaming Record ....................................................................................135
B5.2.22.4 Incoming (Gateway/Intra-PLMN) Trunk and Outgoing (Gateway/Intra-
PLMN/Transit) Trunk Record ...............................................................135
B5.2.22.5 Short Message Service Mobile Terminated Record ...........................136
B5.2.22.6 Determination of the Nature of Address (NOA)....................................136
B5.2.22.7 Short Message Service - Mobile Originated Record (SMS-MO) ..........136
B5.2.23 Called Party (or Served Party) ..........................................................................137
B5.2.24 Called Subscriber Category ..............................................................................137
B5.2.25 Calling Equipment (or Served Equipment) ......................................................138
B5.2.26 Calling Number (or Served Number) ...............................................................139
B5.2.27 Calling Party (or Served Party).........................................................................142
B5.2.28 Calling Subscriber Category.............................................................................143
B5.2.29 Carrier Connect Timestamp..............................................................................143
B5.2.30 Cause for Termination ......................................................................................143
B5.2.31 Cell-SAC Id ......................................................................................................144
B5.2.32 Channel Allocation Time..................................................................................145
B5.2.33 Channel Description .........................................................................................145
B5.2.34 Channel Type....................................................................................................145
B5.2.35 Charge Number.................................................................................................147
B5.2.36 Charge Zone......................................................................................................147
B5.2.37 Classmark Time Stamp.....................................................................................147
B5.2.38 Connection Element..........................................................................................148
B5.2.39 Correlation ID...................................................................................................148
B5.2.40 Correlation ID / ETC Parm2.............................................................................149
B5.2.41 Counter..............................................................................................................149
B5.2.42 CSI (CAMEL Subscription Information) .........................................................150
B5.2.43 Data Compression.............................................................................................151
B5.2.44 Data Rate...........................................................................................................152
B5.2.45 Data Volume.....................................................................................................153
B5.2.46 Date and Time...................................................................................................153
B5.2.47 Default SMS Handling Applied (DSH Applied) ..............................................156
B5.2.48 Default SMS Handling Indicator (DSH Indicator) ...........................................156
APP 5.9 MSCS19
17th July 2006 (Approved) Page: xxi
B5.2.49 Delivery Timestamp .........................................................................................157
B5.2.50 Destination Routing Address ............................................................................157
B5.2.51 Detection Point .................................................................................................158
B5.2.52 Diagnostic .........................................................................................................159
B5.2.52.1 Signalling Agents with Error Codes used for Diagnostic......................160
B5.2.52.2 Signalling Agents and Required Mappings ...........................................164
B5.2.53 Dialled Digits....................................................................................................166
B5.2.54 Disconnect Time ...............................................................................................167
B5.2.55 E Parameter.......................................................................................................167
B5.2.56 Emergency Service Routing Digits (ESRD).....................................................168
B5.2.57 Emergency Service Routing Key (ESRK)........................................................168
B5.2.58 Equipment Identity ...........................................................................................169
B5.2.59 Equipment Type................................................................................................169
B5.2.60 FCI Freeform Parameter ...................................................................................169
B5.2.61 File Sequence Number......................................................................................170
B5.2.62 File Transfer Type ............................................................................................170
B5.2.63 Free Format Data ..............................................................................................171
B5.2.64 Functional Number ...........................................................................................172
B5.2.65 Geographical Location of UE 1........................................................................172
B5.2.70 Group Call Reference .......................................................................................175
B5.2.71 Half Rate in Use................................................................................................175
B5.2.72 Hexadecimal Identity........................................................................................176
B5.2.73 Hot Billing Indicator .........................................................................................176
B5.2.74 IN Call Reference Number ...............................................................................177
B5.2.75 IN Dialogue Result ...........................................................................................177
B5.2.76 IN Protocol........................................................................................................177
B5.2.77 IN Time Stamp1................................................................................................178
B5.2.78 IN Time Stamp2................................................................................................178
B5.2.79 Incoming/Outgoing Metering Class..................................................................179
B5.2.80 Incoming/Outgoing Route Group .....................................................................179
B5.2.81 Incoming/Outgoing Trunk Release Time .........................................................180
B5.2.82 Incoming/Outgoing Trunk Seizure Time..........................................................180
B5.2.83 Incoming Trunk Group .....................................................................................181
B5.2.84 Incoming Trunk Member..................................................................................181
B5.2.85 Information Transfer Capability .......................................................................181
B5.2.86 Inter-Exchange/International Carrier (IC/INC) Call Event Status ...................182
B5.2.87 Inter-Exchange/International Carrier (IC/INC) Prefix .....................................183
B5.2.88 Interworking Function Trunk Group ................................................................183
B5.2.89 Interworking Function Trunk Member .............................................................183
B5.2.90 IP Address Identity ...........................................................................................184
B5.2.91 IP Routing Address...........................................................................................184
B5.2.92 IP SSP Capability..............................................................................................185
MSCS19 APP 5.9
Page: xxii (Approved) 17th July 2006
B5.2.93 IWF Activation Timestamp ..............................................................................185
B5.2.94 IWF Diagnostic Code .......................................................................................186
B5.2.95 LCS Client Identity...........................................................................................186
B5.2.96 LCS Client Type ...............................................................................................187
B5.2.97 LCS Diagnostic.................................................................................................187
B5.2.98 LCS Initiation Time..........................................................................................188
B5.2.99 LCS Priority Level............................................................................................188
B5.2.100 LCS Record Type .............................................................................................189
B5.2.101 LCS Result ........................................................................................................189
B5.2.102 LCS Termination Time.....................................................................................190
B5.2.103 Local Reference Number ..................................................................................191
B5.2.104 Location Area Code ..........................................................................................191
B5.2.105 Logical Network ...............................................................................................192
B5.2.106 Message Reference ...........................................................................................192
B5.2.107 Metering Zone...................................................................................................192
B5.2.108 MGW (Media Gateway) Number .....................................................................193
B5.2.109 MGW Seizure Time..........................................................................................193
B5.2.110 MM (Mobility Management) Event .................................................................194
B5.2.111 Module Code.....................................................................................................194
B5.2.112 MS Classmark...................................................................................................196
B5.2.113 MSC Address....................................................................................................197
B5.2.114 MSC ID.............................................................................................................197
B5.2.115 MSC Number ....................................................................................................198
B5.2.116 MSC/MGW Number.........................................................................................198
B5.2.117 Network Call Reference Number .....................................................................199
B5.2.118 New AN (Access Network) ..............................................................................199
B5.2.119 New Cell-SAC Id..............................................................................................200
B5.2.120 New LAC (Location Area Code)......................................................................200
B5.2.121 New MSC Id .....................................................................................................201
B5.2.122 Number of Fax Pages........................................................................................201
B5.2.123 Number Type ....................................................................................................201
B5.2.124 Numbering Plan Identifier ................................................................................202
B5.2.125 Off Air Call Setup.............................................................................................202
B5.2.126 Off-Board IN Service Identifier........................................................................203
B5.2.127 Off-Board IN Service Indicator ........................................................................203
B5.2.128 Old AN (Access Network)................................................................................204
B5.2.129 Old Cell-SAC Id ...............................................................................................204
B5.2.130 Old LAC (Location Area Code) .......................................................................204
B5.2.131 Old MSC Id.......................................................................................................205
B5.2.132 Operation History .............................................................................................205
B5.2.133 Operation Indication .........................................................................................206
B5.2.134 Original Calling Number ..................................................................................207
B5.2.135 Outgoing Trunk Group .....................................................................................208
B5.2.136 Outgoing Trunk Member ..................................................................................208
B5.2.137 Partial Record Event Code................................................................................208
B5.2.138 Partial Record Reason.......................................................................................209
APP 5.9 MSCS19
17th July 2006 (Approved) Page: xxiii
B5.2.139 Partial Record Reference Number ....................................................................209
B5.2.140 Partial Record Sequence Number .....................................................................209
B5.2.141 Party To Charge ................................................................................................210
B5.2.142 Patch Identity ....................................................................................................210
B5.2.143 Ported Status .....................................................................................................210
B5.2.144 Positioning Data................................................................................................211
B5.2.145 Post-Translated Called Party Number...............................................................212
B5.2.146 Pre-Translated Called Party Number ................................................................213
B5.2.147 Priority Call Cause............................................................................................213
B5.2.148 Priority Call Duration .......................................................................................214
B5.2.149 Priority Call Tag ...............................................................................................214
B5.2.150 Priority Level ....................................................................................................214
B5.2.151 Priority Release Time .......................................................................................215
B5.2.152 Privacy Notification..........................................................................................215
B5.2.153 Privacy Override ...............................................................................................216
B5.2.154 Query Method...................................................................................................216
B5.2.155 Rate Adaptation ................................................................................................217
B5.2.156 Record Count ....................................................................................................217
B5.2.157 Record Header ..................................................................................................218
B5.2.158 Record Number.................................................................................................219
B5.2.159 Record Time .....................................................................................................219
B5.2.160 Recording Entity...............................................................................................219
B5.2.161 Recording Office Identity .................................................................................219
B5.2.162 Recording Office Type / Sensor Type ..............................................................220
B5.2.163 Release Id..........................................................................................................220
B5.2.164 Release Time.....................................................................................................221
B5.2.165 Requested QoS..................................................................................................221
B5.2.166 Requesting Mobile Location Centre (MLC).....................................................221
B5.2.167 Result Indicator.................................................................................................222
B5.2.168 RNC ID.............................................................................................................223
B5.2.169 Roaming Number..............................................................................................223
B5.2.170 Routing Number ...............................................................................................223
B5.2.171 SCF ID..............................................................................................................224
B5.2.172 SCF ID / ETC Parm1........................................................................................224
B5.2.173 SCP Address .....................................................................................................225
B5.2.174 Sensor Identity ..................................................................................................226
B5.2.175 Served IMEI......................................................................................................226
B5.2.176 Served IMSI ......................................................................................................227
B5.2.177 Served MSISDN...............................................................................................227
B5.2.178 Served Party......................................................................................................227
B5.2.179 Service Centre...................................................................................................228
B5.2.180 Service Key.......................................................................................................228
B5.2.181 SMS Message Type ..........................................................................................229
B5.2.182 SMS Release Cause Value................................................................................230
B5.2.183 SMS Result .......................................................................................................231
B5.2.184 SMS Start Time ................................................................................................231
MSCS19 APP 5.9
Page: xxiv (Approved) 17th July 2006
B5.2.185 SMS Stop Time.................................................................................................231
B5.2.186 SMS Timestamp ...............................................................................................232
B5.2.187 SMS Validity Period.........................................................................................232
B5.2.188 Structure Code ..................................................................................................232
B5.2.189 Study Indicator..................................................................................................233
B5.2.190 Subscriber Service ............................................................................................234
B5.2.191 Supplementary Service Action .........................................................................235
B5.2.192 Supplementary Service Code............................................................................235
B5.2.193 Supplementary Service Parameters ..................................................................237
B5.2.194 System Type .....................................................................................................237
B5.2.195 Switch Restart Type..........................................................................................237
B5.2.196 Tariff Class .......................................................................................................238
B5.2.197 Teleservice ........................................................................................................238
B5.2.198 Terminating Location .......................................................................................240
B5.2.199 Trunk Usage Reason.........................................................................................240
B5.2.200 Type of Carrier Identification Code (CIC) .......................................................240
B5.2.201 Unused Number 1 .............................................................................................241
B5.2.202 Unused Number 2 .............................................................................................241
B5.2.203 Unused Timestamp 1 ........................................................................................242
B5.2.204 Unused Timestamp 2 ........................................................................................242
B5.2.205 Update Result....................................................................................................242
B5.2.206 Update Time .....................................................................................................243
B5.3 PCS 1900 Fields............................................................................................................244
B5.3.1 Automatic Number Identification Indicator .....................................................244
B5.3.2 Called Party Off-Hook Indicator ......................................................................245
B5.3.3 Charge Number/Automatic Number Identification (ANI) ...............................246
B5.3.4 Generic Address Parameter ..............................................................................246
B5.3.5 Inter-exchange/International Carrier (IC/INC) Routing Indicator....................247
B5.3.6 LATA................................................................................................................248
B5.3.7 Location ............................................................................................................248
B5.3.8 Location Routing Number (LRN).....................................................................248
B5.3.9 Module Code (PCS 1900 Market-Specific)......................................................249
B5.3.10 Originating Line Information/II Parameter.......................................................249
B5.3.11 Originating Numbering Plan Area (and Area Code) ........................................250
B5.3.12 Overseas Indicator ............................................................................................250
B5.3.13 Party Identifier ..................................................................................................251
B5.3.14 SCP Determined Terminated Number ..............................................................251
B5.3.15 Service Feature Code ........................................................................................252
B5.3.16 Service Provider Identity ..................................................................................252
B5.3.17 Supporting Information.....................................................................................252
B5.3.18 Terminating Numbering Plan Area...................................................................253
B5.3.19 Toll Free Call Type Code .................................................................................254
B5.4 Singapore Specific Fields .............................................................................................254
B5.4.1 Calling Party Category......................................................................................254
B5.4.2 City Wide Centrex ............................................................................................255
B5.4.3 Module Code.....................................................................................................255
APP 5.9 MSCS19
17th July 2006 (Approved) Page: xxv
B5.4.4 National / International Indicator......................................................................256
B5.4.5 Other Subscriber CUSTGRP ............................................................................256
B5.4.6 Other Subscriber NCOS....................................................................................256
B5.4.7 XCLI Indicator..................................................................................................257
B5.5 German and Austrian Market-Specific Fields ..............................................................257
B5.5.1 Default Carrier Identification Code (CIC)........................................................257
B5.5.1.1 German Market Default Carrier CICs ...................................................258
B5.5.1.2 Austrian Market Default Carrier CICs ..................................................258
B5.5.2 Module Code.....................................................................................................258
B5.5.3 Selected Carrier Identification Code (CIC) ......................................................259
B5.5.3.1 German Market Selected CICs ..............................................................259
B5.5.3.2 Austrian Market Selected CICs..............................................................259
B5.5.4 Subscriber Customer Group..............................................................................260
B6 Example Call Scenarios ............................................................................................................261
B6.1 Mobile to Land (Outgoing) Call ...................................................................................262
B6.2 Partial Billing in a Mobile to Land (Outgoing) Call.....................................................264
B6.3 Land to Mobile (Incoming) Call ...................................................................................265
B6.4 Mobile to Mobile Call Within the Same Network........................................................266
B6.5 Calls Involving Roaming Mobile Subscribers..............................................................269
B6.5.1 Call Made by the Roaming Subscriber to Another Mobile Subscriber ............269
B6.5.2 Incoming Call to a Roaming Subscriber...........................................................270
B6.6 Incoming Call to a PLMN Service Centre....................................................................271
B6.7 Call Forwarding ............................................................................................................272
B6.7.1 Example Call Forwarding Scenario..................................................................272
B6.7.2 Location Information and Call Forwarding Records........................................275
B6.8 Delivery and Origination of Short Messages................................................................276
B6.8.1 Delivery of a Mobile Terminated Short Message.............................................276
B6.8.2 Origination of a Short Message ........................................................................276
B6.9 Call Hold and Multi-party Services ..............................................................................277
B6.10 Explicit Call Transfer Service.......................................................................................279
B6.11 Redirection and Call Dropback Services ......................................................................281
B6.11.1 Voice Mail Call Dropback................................................................................281
B6.11.2 The Nortel ETSI ISUP Call Re-Origination Service ........................................283
B6.11.3 The Network Optimisation of Trombone Connections ....................................284
B6.12 Handover.......................................................................................................................285
B6.13 Local Number Portability .............................................................................................288
B6.14 Extension Services........................................................................................................290
B6.15 Intelligent Network (IN) Scenarios...............................................................................291
B6.15.1 IN Nodes and Signalling...................................................................................292
B6.15.2 Mobile Originated IN Billing ...........................................................................293
B6.15.2.1 CAMEL MO Billing ..............................................................................294
B6.15.2.2 CS1-R MO Billing .................................................................................294
B6.15.3 Mobile Terminated IN Billing ..........................................................................294
B6.15.3.1 CAMEL MT Billing...............................................................................295
B6.15.3.2 CS1-R MT Billing..................................................................................296
MSCS19 APP 5.9
Page: xxvi (Approved) 17th July 2006
B6.15.4 Mobile Forwarding IN Billing..........................................................................296
B6.15.4.1 CAMEL MF Billing...............................................................................297
B6.15.4.2 CS1-R MF Billing..................................................................................298
B6.15.5 Proprietary Off-Board IN Services ...................................................................298
B6.16 CAMEL Mobility Management Service.......................................................................299
B6.17 Call Independent Supplementary Service Action.........................................................299
B6.18 Invoking the Billing Zone Query Service Using USSD...............................................300
B6.19 Optimal Routing of a Late Forwarded Call ..................................................................301
B6.20 Mobile Number Portability (MNP)...............................................................................303
B6.21 Location Services (LCS)...............................................................................................306
B6.21.1 3GPP Release 99 Messaging ............................................................................306
B6.21.2 3GPP Release 4 Messaging ..............................................................................307
B6.22 Enhanced Multi-level Precedence And Pre-emption Service (eMLPP) Call ...............308
B6.22.1 Called Party Pre-emption..................................................................................308
B6.22.2 Resource Pre-emption.......................................................................................309
B6.23 GSM-R Call Scenarios..................................................................................................311
B6.23.1 Voice Group and Broadcast Calls.....................................................................311
B6.23.1.1 Mobile Dispatcher Group Call ...............................................................311
B6.23.1.2 Service Subscriber Group Call...............................................................312
B6.23.2 Functional Addressing ......................................................................................313
B6.24 Market-Specific Call Scenarios ....................................................................................314
B6.24.1 Chinese Market CAMEL Phase 2 Service Billing............................................314
Part C
Tariff Administration
C1 Introduction...............................................................................................................................319
C1.1 Overview.......................................................................................................................319
C1.2 Defining Service Areas Covered by the Tariff System................................................319
C1.3 The Tariff System.........................................................................................................320
C1.4 Tariffing for the Advice of Charge (AoC) Service.......................................................322
C1.5 Tariff Administration Change Control (TACC) ...........................................................325
C2 Tariff System Functions............................................................................................................327
C2.1 Tariff Switching Pattern Functions...............................................................................327
C2.1.1 Charging Calendar ............................................................................................327
C2.1.2 Day Class ..........................................................................................................327
C2.1.3 Tariff Switch Pattern.........................................................................................327
C2.2 Advice of Charge Tariff Functions...............................................................................328
C2.2.1 AoC Service (or Subscriber Service)................................................................328
C2.2.2 Charging Destination ........................................................................................328
C2.2.3 Charging Origin ................................................................................................328
C2.2.4 Charging Zone ..................................................................................................329
C2.2.5 Tariff (AoC) ......................................................................................................329
C2.2.6 Tariff Class .......................................................................................................329
APP 5.9 MSCS19
17th July 2006 (Approved) Page: xxvii
C2.3 Tariff Administration....................................................................................................330
C2.3.1 Administration and Control ..............................................................................330
C2.3.2 Tariff System....................................................................................................330
C3 Advice of Charge for Multiple Rate Plans................................................................................333
C3.1 Introduction...................................................................................................................333
C3.2 Setting Up AoC with Multiple Rate Plans....................................................................333
C3.2.1 Software Optionality Control (SOC) ................................................................333
C3.2.2 Provisioning in the HLR and MSC...................................................................334
C3.3 AoC and MRP Data Tables ..........................................................................................335
C3.3.1 AoC and MRP Tables for Intra-PLMN Calls ...................................................335
C3.3.2 AoC and MRP For Roaming Subscribers.........................................................336
C3.4 Examples of AoC and Multiple Rate Plans (MRPs).....................................................336
C3.4.1 Intra-PLMN AoC MRPs...................................................................................336
C3.4.2 Support of AoC with MRPs for Inter-PLMN Roaming ...................................337
C3.4.2.1 Mobile Originating Call with Inter-PLMN Roaming ............................337
C3.4.2.2 Mobile Terminating call with Inter-PLMN Roaming............................338
Part D
Frequently Asked Questions
D1 Enabling and Shutting Down the Hot Billing Stream...............................................................341
MSCS19 APP 5.9
Page: xxviii (Approved) 17th July 2006
MSCS19 Billing and Accounting
Part A:
Introduction
Q272-1 MSCS19 Billing and Accounting
APP 5.9 Standard Part A: Introduction
17th July 2006 (Approved) Page: 3
A1 Overview of MSC and Billing Requirements
This section gives an overview of the GSM/UMTS MSC and the billing requirements. Section A1.1
gives a brief introduction to the MSC. Sections A1.2 gives an overview of billing, tariff and
accounting functions defined in the GSM/UMTS standards and the MSCs support of them. Section
A1.4 provides an overview of the configuration of the MSC and its support of the requirements.
A1.1 Introduction to the GSM/UMTS MSC
Nortels GSM/UMTS MSC is based on the Advanced Telecom Computing Architecture (aTCA)
platform. This platform uses a chassis with call processing and other functions distributed across
blades (specialised call processing cards and general computing cards e.g. for storage). It provides
operators with a high-capacity, modular, and highly reliable switching system that supports a wide
range of advanced services and features.
The Nortel GSM/UMTS MSC has been designed to grow to and meet the increasing processing and
memory demands placed on it by new call models, new subscriber and network features, and
increasingly higher subscriber penetration. If the MSC supports intelligent networking services,
either proprietary or those based on the 3GPP CAMEL (Customised Applications for Mobile-
network Enhanced Logic) standards, it is called an MSC/SSP.
The MSC supports UMTS radio access network and provides access to the new 3rd generation (3G)
UMTS services. It also supports the older GSM radio access and GSM services. The new Access
Network field distinguishes GSM and UMTS access in the billing records. The types of network
access are summarised in Figure 1.
Figure 1 Access Interfaces and the GSM/UMTS MSC
The 3GPP standards also define a network architecture called the Bearer Independent Core
Network (BICN). In this network the MSC acts as a call server handling the call processing and
signalling and the Media Gateway provides the bearer connections for the call. Nortels MSC
supports this configuration as summarised in Figure 2.
BSC
BTS
BTS
Node B
MSC
GSM radio
GSM or UMTS
core network
RNC
Node B
Access to 2nd Generation
(2G) GSM services
access
UMTS radio
access
Access to 3rd Generation
(3G) UMTS services
MSCS19 Billing and Accounting Q272-1
Part A: Introduction Standard APP 5.9
Page: 4 (Approved) 17th July 2006
Figure 2 3GPP Bearer Independent Core Network (BICN)
In different regions and markets, regulatory bodies define specific requirements for operators and
service providers. Different market conditions also mean that some services are more popular in
some areas than others. The MSC provides service variants for a number of different regions.
Though much of the billing information produced is common, the MSC does generate specific
information for the market or region in which it is operating. This specification describes the full
billing capabilities of the MSC be they common or regional.
Throughout this document, the term MSC is used for both the MSC and the MSC server.
A1.2 Charging Requirements in GSM/UMTS Standards
Just as the GSM/UMTS MSC is a development of the GSM MSC, the UMTS specifications and
standards are developments of the earlier GSM standards. This means that, at present, network
functions and nodes are described in a mixture of GSM and UMTS terminology, for example the
intelligent network node the service control function is still called the gsmSCF. The GSM/UMTS
MSC too retains GSM capabilities and some of the office parameters (used to control the
functioning of the MSC) still have GSM in their names.
3GPP TS 32.200 specifies the requirements for billing and accounting procedures in stating:
The charging data records (CDRs) generated by the network elements of the 3G
network, are required for a number of telecom management activities including, but not
limited to, the following:
- the billing of home subscribers, either directly or via service providers, for network
utilisation charges;
- the settlement of accounts for traffic carried or services performed by fixed network
operators and other operators;
- the settlement of accounts with other PLMNs for roaming traffic via the transferred
account procedure;
- statistical analysis of service usage;
- as archival information in dealing with customer service and billing complaints;
In addition to the information collected from network elements, network management
functions are required for the administration of charging data.
A1.3 MSCs Support of Requirements
The MSC, as one of the network elements specified in 3GPP TS 32.200 and 32.205, produces and
stores call detail records (CDRs). CDRs contain information about the call activities on the switch.
The MSC also provides a mechanism for specifying a tariff system to support the Advice of Charge
(AoC) service.
The management functions required to manage the tariff system are provided within the MSC using
DMS table control functions. These functions are accessible via the human machine interface.
Using the terminology of 3GPP TS 32.205 for this support of a tariff system, the MSC has a limited
OSF capability integrated with it.
A1.4 MSC Configuration
To produce billing information, the MSC works with the SuperNode Billing Application (SBA) on
the Core and Billing Manager (CBM) platform. The SDM/SBA server uses a distributed processing
architecture which separates call processing from file processing. It has enhanced fault handling
capabilities to ensure that billing records are captured during fault conditions so that they can be
retrieved later. It provides two file transfer interfaces for transferring files to the downstream nodes:
the IETF file transfer protocol (FTP) interface and secure file transfer using the SSH (Secure Shell)
File Transfer Protocol (SFTP) implemented by the OpenSSH package.
The MSC with the SBA supports the full range of billing capabilities including the capability of
generating billing records in near real time using the Nortel proprietary hot billing service.
A2 Billing and Accounting Features
This section gives a brief description of the MSCS19 developments which have an impact on the
billing functions of the MSC.
A2.1 Billing Feature Development
A2.1.1 Feature Development
A00010549 MSC Enhancements for Improved SMS Delivery
This feature provides enhancements to the Short Message Service (SMS) including
to paging and to the production of statistical and error information. For billing
purposes, it introduces a new office parameter to stop the MSC producing Short
Message Service, Mobile Terminated records (B4.1.8 on page 67) when the delivery
of the message is unsuccessful e.g. because the subscriber is absent or the delivery
times out.
This feature introduces the new Office Parameter MTSMS_BILLING_RECORD_
THROTTLE in OFCVAR (B3.8.1 on page 51) to determine whether or not SMS-MT
records are generated for unsuccessful message delivery. The feature does not alter
the format of any billing record, module or field.
Impact This feature impacts all customers who provide SMS.
A00011440 Indication of Invalid Long Call Duration Billing Record
This feature provides a method to prevent subscribers being billed for long duration
calls which are invalid. For example a system resource could hang and then be
manually reset after a long time and under these conditions the subscriber could be
incorrectly billed.
This feature builds on the Long Call Duration Teardown capability and the use of the
office parameter GSM_LONG_CALL_TEARDOWN in table OFCVAR ((in Table
2, Section B3.8.1 see the entry GSM_LONG_CALL_TEARDOWN on page 50)).
If the existing field glctd_type is AUTO and the new field reset_ildr is set to Y, the
feature is active. When active the feature sets the Call Duration field (B5.2.15 on
page 129) to zero and the Call Indicator field (B5.2.17 on page 131) to indicate no
charge in invalid long call duration records. It works in both the normal and hot
billing streams.
Impact This feature impacts all customers who choose to implement the datafill.
A00011877 eMLPP Support in GSM & UMTS
This feature provides enhancements to the Enhanced Multi-Level Precedence and
Pre-emption service (eMLPP). The service was originally used in GSM Railways
(GSM-R) networks but can now be used in the Bearer Independent Core Network
(BICN). The customer can set call precedence levels for subscribers who do not
subscribe directly to the service. eMLPP information can also be captured during
handover and when the call is not answered.
The feature is controlled by the Software Optionality Control (SOC) option GSM
eMLPP (in Table 4, Section B3.8.2 see the entry GSM eMLPP on page 58). If this
SOC is on, the operation depends on datafill (in Table 2, Section B3.8.1 see the entry
Enhanced Multi-Level Precedence and Pre-emption service (eMLPP) on page 55).
The MSC captures eMLPP billing information in a Supplementary Service
information module (in Section B4.2.4 see the examples in Table 37 on page 89).
For a mobile to mobile call on the MSC the module is appended to the Mobile
Originated Call Attempt record (B4.1.1 on page 60). For a call on an incoming trunk
terminating to the called party, the module is appended to the Mobile Terminated
Call Attempt record (B4.1.2 on page 61).
Impact This feature impacts all customers who implement eMLPP.
A00012075 MSC-HLR based Ring Back Tone feature
This feature provides support for the ring back tone (RBT) service which allows a
subscriber to play a personalised tone to the calling party during call establishment
(there is a similar CAMEL-based service described in feature A00004614). The
RBT service is implemented as a supplementary service (SS). When the subscriber
is called, the Gateway MSC (GMSC) requests the subscribers terminating data from
the HLR. The HLR returns the information, including that for the RBT service. The
GMSC routes the call to the called party and connects to an Intelligent Peripheral
(IP) to play the personalised tone to the calling party.
The MSC captures the billing information for the service in a Supplementary
Services (SS) information module (B4.2.4 on page 83) appended to the terminating
call record which can be one of the following: the Mobile Terminated record (B4.1.2
on page 61), the Roaming record (B4.1.3 on page 62), the Outgoing Gateway Call
Attempt record (B4.1.5 on page 64) or the Outgoing Intra-PLMN Trunk record
(B4.1.10 on page 69). In Section B4.2.4, Table 38, MSC-HLR based ring back tone
service on page 90 provides an example of the contents of the SS information
module. The module contains a new Supplementary Service Code (B5.2.192 on
page 235) to indicate the service and may also contain a new Result Indicator value
(B5.2.167 on page 222) if the service fails.
(continued)
The feature is controlled by the Software Optionality Control (SOC) option MSC-
HLR RBT service (in Table 4, Section B3.8.2, see the entry MSC-HLR based Ring
Back Tone on page 58). If this SOC is on, the operation depends on datafill (in
Table 2, Section B3.8.1, see the entry MSC-HLR based Ring Back Tone (RBT)
service. on page 55). The feature also uses the field CDRREQ in RTEGRP (in Table
2, Section B3.8.1 see the entry CONN, DIR, TRKGRPS and CDRREQ fields on
page 51). This field determines whether the MSC captures a Transit record (B4.1.6
on page 65) to provide information about the use of the connection to the external IP.
Impact This feature impacts all customers who provide the RBT supplementary
service.
A00012077 IMEISV in VLR and GCDR
This feature allows the MSC to the store the International Mobile Equipment
Identity and Software Version number (IMEISV) of the Mobile Station (MS) as well
as the IMEI. The MSC captures the IMEI/IMEISV in the:
- Called Equipment field (B5.2.20 on page 133) in the following records
- Mobile Terminated (for normal calls and forwarded calls (B4.1.2 on page 61)
- SMS-Mobile Terminated (B4.1.8 on page 67)
- Calling Equipment field (B5.2.25 on page 138) in the following records:
- Mobile Originated (for normal calls and forwarded calls) (B4.1.1 on page 60)
- Short Message Service Mobile Originated (SMS-MO) (B4.1.7 on page 66),
- Served IMEI field (B5.2.175 on page 226) in the following record:
- Location Services (LCS) (B4.1.13 on page 73).
The handling of an invalid IMEI/IMESV is controlled by the Software Optionality
Control (SOC) option GSM Invalid IMEISV (in Table 4, Section B3.8.2 see the
entry GSM Invalid IMEISV on page 58).
Impact This feature impacts all customers.
A00012238 Post-Translated Called Party Number in Incoming Gateway Record
This feature allows the MSC to capture the called party number generated by the
MSC translation system. This is the post-translated Mobile Station International
ISDN Number (MSISDN). For example, the original dialled digits for the called
MSISDN could be in international format, but the post-translated MSISDN could
have the international digits stripped from it.
The MSC captures the post-translated MSISDN in the new Post-translated Called
Party Number field (B5.2.145 on page 212). This field is in the Generic Address
information module (B4.2.16 on page 102) appended to the Incoming Gateway Call
Attempt record (B4.1.4 on page 63). The incoming gateway record captures the
number used to route the call, e.g. the Mobile Station Roaming Number (MSRN) in
the Called Number field (B5.2.22 on page 134). This extends the amount of
information captured in the record and the information module for the calling and
called numbers used to connect a call.
Impact This feature impacts all customers.
A00012239 Called Party IMSI in MO and ICG CDRs for MNP
This feature enhances the Mobile Number Portability (MNP) capabilities by
allowing the MSC to capture the called partys International Mobile Subscriber
Identity (IMSI) if this is available in the MNP database, the MNP Signalling Relay
Function (MNP-SRF). During terminating call setup, the MSC sends a MAP
SendRoutingInfo (SRI) query to the MNP-SRF to find out if the ported status of the
subscriber. The MNP-SRF returns the information in the SRI Ack. If this message
contains the called partys IMSI, the MSC captures it.
The MSC captures the IMSI in the new Called IMSI Number field (B5.2.21 on
page 134). This field is in the MNP information module (B4.2.19 on page 105)
appended to the Mobile Originated Call Attempt record (B4.1.1 on page 60), the
Incoming Gateway Call Attempt record (B4.1.4 on page 63) or the Incoming Intra-
PLMN Trunk record (B4.1.10 on page 69). If the subscriber has ported out of the
network, i.e. moved to another service provider, the Called Party IMSI field contains
the default value. If the number is ported in, or has not been ported, this field
captures the IMSI.
This feature is controlled by the new office parameter MNP_CDPN_IMSI_IN_MO_
ICG_CDR in table OFCVAR. (in Table 2, Section B3.8.1 see the entry
MNP_CDPN_IMSI_IN_MO_ICG_CDR on page 56).
Impact This feature impacts all customers who implement MNP.
A2.1.2 Market-Specific Features
A00011185 Directory Assistance Service Billing Duration
This feature updates the Israeli Directory Assistance Service by capturing the service
duration regardless of whether or not the operator succeeds in sending the requested
information to the service user.
When the user dials the service number, the MSC routes the call via the PSTN to the
service centre by sending an Initial Address Message (IAM). The operator takes the
call and sends an Address Complete Message (ACM) to the MSC to initiate the
service. The operator then either succeeds or fails in finding the number for the user
before releasing the service connection by sending a Release (REL) message to the
MSC.
The billing information for the service is captured in a Supplementary Service (SS)
Information Module appended to the Outgoing Gateway Call Attempt record
(B4.1.4 on page 63) or the Outgoing Intra-PLMN Trunk record (B4.1.10 on page 69)
on the MSC. The Date and Time field (B5.2.46 on page 153) captures the time at
which the MSC receives the ACM message. The SS Parameters field (B5.2.193 on
page 237) captures the duration between receiving the ACM and the REL. The
information in this field is in the same format as the Call Duration field (B5.2.15 on
page 129) but padded with leading Fs (because the call duration field is 14
characters long, but the SS parameters field is 32 characters).
Impact This feature impacts customers in the Israeli market who provide the
directory assistance service.
A00011357 E911: IMEI only for SIMless 911 calls
This feature ensures that only the IMEI (International Mobile Equipment Identity) is
captured in the location information for a subscriber who makes an emergency call
using a device without a SIM (Subscriber Identity Module). Previously, the MSC
could derive the MSISDN (mobile number) from the information stored in the VLR
(Visitor Location Register). However, there is a problem with duplicate IMEIs and
so the information in the VLR may not be totally reliable.
The NI-LR (Network Initiated Location Request) method provides information
about the subscribers location during the emergency call. The MSC captures the
location information in a Location Services information module (B4.1.13 on
page 73). The Served MSISDN field (B5.2.177 on page 227) contains the default
value so that only the IMEI is captured in the record. The feature does not change the
format of any billing information.
Impact This feature impacts customers in the North American market who allow
SIMless E911 emergency calls.
A2.1.3 Change Request (CR) Updates
Q00952821-05GSM:GSM17:Calling_party_number field blank in GCDRs for some calls
This CR ensures that in redirecting scenarios where the redirecting number (RDN) is
not signalled in the incoming message, that the Calling Number field (B5.2.26 on
page 139) is populated with the Original Called Number (OCN) rather than with the
default value. In this case the incoming Initial Address Message (IAM) indicates that
the call has been forwarded once but it does not contain a redirecting number. When
this happens the MSC captures the original called number in the Calling Number
field of the following records: Mobile Terminated Call Attempt (B4.1.2 on page 61),
Roaming Call attempt (B4.1.3 on page 62), Incoming Gateway Call Attempt (B4.1.4
on page 63), Outgoing Gateway Call Attempt (B4.1.5 on page 64), Transit Call
Attempt (B4.1.6 on page 65), Incoming Intra-PLMM Trunk Record (B4.1.9 on
page 68), Outgoing Intra-PLMN Trunk Record (B4.1.10 on page 69).
This CR may be overridden by existing parameters or SOCs. The office parameter
Use_original_CGPN_for_billing (B3.8.1, Table 2 on page 52) overrides this CR if it
is set on. In this case the original calling number is captured instead of the original
called number. However SOC option GSM Generic Address Info (B3.8.2, Table 4 on
page 57) overrides Use_original_CGPN_for_billing if it is set on: in this case the
changes of this CR apply if the redirecting number is missing.
Impact This change impacts all customers.
Q01288857-02MSC: calling number blank in GCDR's for redirected PSTN calls
This CR provides a way for customers to capture the original calling number when
the redirecting number and/or the original called number are missing from the call
setup signalling for redirected calls. This CR deals with two scenarios:
- a call has been directed once (redirection counter = 1) and both the original
called number and the redirecting number are missing
- a call has been redirected more than once and the redirecting number is missing
In these cases, the CR provides the operator with the option to capture the original
calling number in the Calling Number field (B5.2.26 on page 139) of the Roaming
Record Call Attempt record, (B4.1.3 on page 62), the Incoming Gateway Call
Attempt record (B4.1.4 on page 63), the Transit record (B4.1.6 on page 65) or the
Incoming Intra-PLMN Trunk record (B4.1.9 on page 68).
This capability is determined by the new office parameter USE_OCGN_IN_CDR_
IF_NO_RDGN_OCN (B3.8.1, Table 2 on page 52). If Q00952821-05 is
implemented and the original called number (OCN) is present in the call setup
signalling then it is captured in the call records regardless of the setting of USE_
OCGN_ IN_CDR_ IF_NO_RDGN_OCN office parameter.
A2.2 Other Changes
This section describes changes in the specification which are not directly related to the MSCS19
GSM/UMTS product release.
Billing Platform
The MSCS19 uses the aTCA architecture and there is a high-level overview of the
billing architecture (B1 on page 27 and B2 on page 31).
Impact This change provides information for all customers.
Call Scenarios
The call scenarios now have some Bearer Independent Core Network (BICN)
examples (B6 on page 261).
Impact This change provides information for all customers, but does not replace
the information available on the billing example CDs (Sample Billing
CDs on page viii).
Channel Type Field Contains More Information About the Speech Encoding Algorithm
The field description contains information about how values in the Speech Encoding
Algorithm sub-field of the Channel Type field (B5.2.34 on page 145) are captured
from data specified in 3GPP TS 48.008.
Impact This change provides information for all customers.
Diagnostic Field Updated for ANSI ISUP
The Diagnostic field values for ANSI ISUP have been reviewed and updated against
the ANSI ISUP specification (Table 108 on page 162 in B5.2.52).
Impact This change impacts customers who use ANSI ISUP.
Explicit Call Transfer (ECT) Partial Billing and Call Duration
Notes in the partial billing section (NOTE on page 43 in Section B3.4.4) and the Call
Duration field (NOTE 6 on page 130 in Section B5.2.15) describe how call timings
are captured in the billing records and how this can affect partial billing.
Impact This change impacts customers who support ECT.
Geozone Tone Service is Supported on a Stand-alone MSC
The MSC can be a stand-alone MSC which terminates call signalling and bearer
traffic, or a call server which processes call signalling and controls media gateways
which terminate the bearer traffic. The geozone tone service is only supported on the
stand-alone MSC or in the non-call server part of a hybrid MSC/MSC call server.
This is noted for the IN information module (B4.2.14 on page 98) and the Operation
Indication field (B5.2.133 on page 206).
Impact This change impacts customers who provide the geozone tone service.
HO_PERFORMED_PROCESSING Office Parameter Description Clarified
This office parameter uses a number of parameters to control information captured
during handover. The office parameter description (B3.8.1, Table 2 on page 53)
clarifies that the LIU_PROCESSING parameter applies to an MSC which uses Link
Peripheral Processor (LIU7s) hardware to terminate the A interface signalling from
the Base Station Controller.
Impact This change provides information to all GSM customers.
MS Classmark Field Updated
In the MS Classmark field (B5.2.112 on page 196) the value Frequency Capability
value Extension Band supported is not supported. The value for A5/1 algorithm
not available is hex (#) F.
Impact The changes impacts all customers.
Network Determined User Busy (NDUB) Call Forwarding
The call forwarding scenario (B6.7.2 on page 275) has been updated to clarify when
and what location information is captured during this type of forwarding.
Impact This change provides clarifications for customers who implement NDUB
call forwarding.
Proprietary Calling Name Delivery Service and the 3GPP Calling Name Presentation Service
Nortels Calling Name Delivery service (CNAM) is a proprietary implementation of
3GPPs Calling Name Presentation service (CNAP). This is clarified in an example
of the Supplementary Service information module (Table 31 on page 85 in section
B4.2.4) and in the Supplementary Service Code field (B5.2.192 on page 235).
Impact This change provides a clarification for customers who provide the
CNAM service.
Release Id Field
This field (B5.2.163 on page 220) captures a new value for the MSCS19 release.
Secure File Transfer using SFTP
The MSC supports the SSH (Secure Shell) File Transfer Protocol for secure file
transfer (B1.2.1 on page 28).
Impact This change provides a new file transfer mechanism for all customers.
A2.3 List of Changed Pages
Table 1 lists the pages in the specification which contain new or altered information for MSCS19.
The changes have an impact on the down stream processor.
Page Section New/Changed Information
28 B1.2.1 The MSC supports SFTP for secure file transfer.
43 B3.4.4 A note explains how partial billing records are created for Explicit Call Transfer.
50 B3.8.1 The office parameter GSM_LONG_CALL_TEARDOWN determines the handling
of invalid long call duration records.
51 B3.8.1 The new office parameter MTSMS_BILLING_RECORD_ THROTTLE in table
OFCVAR determines whether or not SMS-MT records are generated if the message
delivery fails.
52 B3.8.1 The new office parameter USE_OCGN_IN_CDR_IF_NO_RDGN_OCN in table
OFCVAR determines whether or not the original calling number is captured in the
incoming trunk records when the redirecting number and original called number are
missing from the call setup signalling.
53 B3.8.1 The use of the LIU_PROCESSING parameter is clarified.
Table 1 Changed Pages in this Release
55 B3.8.1 The operation of the eMLPP service depends on datafill in tables OFCVAR,
GHLRSSOP and SERVCNFG.
55 B3.8.1 The operation of the RBT service is determined by datafill in table OFCVAR.
56 B3.8.1 The information captured for the MNP service is determined by datafill in table
OFCVAR.
58 B3.8.2 The SOC option GSM eMLPP switches the service off/on.
58 B3.8.2 The SOC option MSC-HLR RBT service switches the service off/on.
58 B3.8.2 The SOC option GSM Invalid IMEISV determines how the MSC handles an invalid
IMEI/IMEISV.
60 B4.1.1 The Calling Equipment field in the Mobile Originated Call Attempt record can
capture the IMEISV.
61 B4.1.2 The Called Equipment field in the Mobile Terminated Call Attempt record can
capture the IMEISV.
66 B4.1.7 The Calling Equipment field in the Short Message Service Mobile Originated record
can capture the IMEISV.
67 B4.1.8 The Called Equipment field in the Short Message Service Mobile Terminated record
can capture the IMEISV.
73 B4.1.13 The Served IMEI field in the Location Services record can capture the IMEISV.
85 B4.2.4 Table 31 clarifies that the Calling Name Delivery service is a Nortel proprietary
equivalent of the 3GPP Calling Name Presentation service.
89 B4.2.4 Table 37 shows information that can be captured in the Supplementary Services
information module for the eMLPP service.
90 B4.2.4 Table 38 shows information that can be captured in the Supplementary Services
information module for the MSC-HLR based ring back tone service.
98 B4.2.14 Footnote added to the IN information module to clarify the support of the geozone
tone service.
102 B4.2.16 The Generic Address information module contains the new Post-translated Called
Party Number field which captures the post-translated MSISDN.
105 B4.2.19 The Mobile Number Portability information module contains the new Called IMSI
Number field to capture MNP information.
110 B4.3 This section has been extended in scope to cover market-specific billing information
as well as market-specific modules.
129
130
B5.2.15 If the office parameter GSM_LONG_CALL_TEARDOWN is set to handle invalid
long call duration records, the Call Duration field is defaulted in the invalid records.
A note explains how the call duration varies in the different records created for
Explicit Call Transfer.
131 B5.2.17 If the office parameter GSM_LONG_CALL_TEARDOWN is set to handle invalid
long call duration records, the Call Indicator field is set to no charge in the invalid
records.
133 B5.2.20 The Called Equipment field can capture the IMEISV.
134 B5.2.21 The Called IMSI field captures the IMSI returned to the MSC from the MNP
database.
138 B5.2.25 The Calling Equipment field can capture the IMEISV
A2.4 Feature Information
A2.4.1 UMTS and GSM Features
Release 19 (MSCS19)
A00010549 MSC Enhancements for Improved SMS Delivery
A00011185 Directory Assistance Service Billing Duration
A00011357 E911: IMEI only for SIMless 911 calls
A00011440 Indication of Invalid Long Call Duration Billing Record
A00011877 eMLPP Support in GSM & UMTS
A00012075 MSC-HLR based Ring Back Tone feature
A00012077 IMEISV in VLR and GCDR
A00012238 Post-Translated Called Party Number in Incoming Gateway Record
A00012239 Called Party IMSI in MO and ICG CDRs for MNP
Q00952821-05GSM:GSM17:Calling_party_number field blank in GCDRs for some calls
Q01288857-02MSC: calling number blank in GCDR's for redirected PSTN calls
140 B5.2.26 The Calling Number field (in NOTE 2) has information on how operators can
capture alternatives to the redirecting number when this is not available in
redirection call scenarios.
145 B5.2.34 The Channel Type field contains additional information about the values captured in
the Speech Encoding Algorithm sub-field.
162 B5.2.52 The Diagnostic field (Table 108) has been reviewed and updated against the ANSI
ISUP specification.
196 B5.2.112 The support of MS classmark values has been altered.
206 B5.2.133 Footnote added to the Operation Indication field to clarify the support of the geozone
tone service.
212 B5.2.145 The Post-translated Called Party Number field captures the MSISDN resulting from
translations.
222 B5.2.167 The Result Indicator field contains a new value for RBT service failure.
226 B5.2.175 The Served IMEI field can capture the IMEISV
235 B5.2.192 The Supplementary Service Code field contains a new value for the RBT service and
clarifies that the Calling Name Delivery service is a Nortel proprietary equivalent of
the 3GPP Calling Name Presentation service.
275 B6.7.2 The information on NDUB call forwarding provides more information about when
and what information is captured in the Location and Channel information module.
Release 18 (NSS18)
A00004084 Location Based Services Enhancements
A00004142 MSC Support of BICN UMTS
A00004147 MC09 Billing Enhancement
A00004164 Advice of Charge Multiple Rate Plans Enhancements
A00004167 MSC Support for TDOA 911 Positioning using INAP
A00004169 Call Forward Records Enhancement for Loc
A00004188 CAMEL enhancement
A00004372 R4 MSC: CONF Service Alignment with MGW
A00004373 R4 MSC: HO Service Alignment with MGW
A00004513 R4 Billing related enhancements
A00004613 Advice of Charge for R2 and TUP
A00004614 Ringback Support for DP12 CAMEL P2 Connect Solution
A00006555 MSC Subscriber Category Enhancement
A00007441 MC09 Billing Module Captured on CF leg for CSD Calls
A00007479 Calling party address (MSISDN) in MO CDR
A00007490 Israeli Directory Assistance Service
Q00609584 CallReferenceNumber need to be presented in V3 SRI without restriction
Q00722754-01 GSM13: XAC PTML ISB MSC: Call duration of MT and IC Gateway CDRs
are different
Q00808848-03 UMTS:XMSC15DK: Field 'CH TYPE' is not filled correctly in UMTS video call
Q00887668 AWS:UMTS:V3:MSC: MM Call does not support Classmark 7 for UMTS mobiles
Q01006934 Enhancement in patching module
Q01067308 GSM18: FG08:LCS Billing: To allow LCS billing to go to hot billing stream
Q01093144 18REG:BILLING:SVE - Documentation - LNP MC not appended on every
LNP query (also see CR Q01054004)
Q01094882 GSM:MSC:GSM15:SMS MT messages and records can not be billed
Release 17 (NSS17)
A00000570 Wireless Priority Service (WPS) -Full Operating Capability (FOC)
A00000993 World Trade Equal Access
A00001007 China CAMEL P2 Enhancements for NQI=80H
A00001042 LRD Messages for 3G Networks
A00001053 H324M 64K UDI productization on DMS-MSC
A00001121 Location Based Services: R99 Compliance
A00001132 MSC/VLR Support for CAMEL P3 M-CSI
A00001134 ETC Error Handling and Billing
A00001143 CF NDUB Enh for Loc
A00001605 Circuit Billing Header Release Field Enhancement
A00001613 MNP: Stripping of RC in ISUP IAM message
A00001891 Explicit Call Transfer Enhancements
A19013161 MSC Support: Multiple Time Zone Billing
Q00427302-01NSS:MSC:GSM13: Questions regarding wrong 'MS Classmark' values in GCDR
Q00547509 GSM:GSM13:MSC: Module Code 18 not appended to PREPAID MT billing
records
Continued
Q00645209-01NSS:GSM15:MSC:LCS GCDR field LCS CLIENT Ext ID
Q00687676 GSM17FG02: Modification to MM EVENT field in STRUC CODE= 10001C
Q00703335 MSC: No MNP info in CDR for home subs
Q00712339 GSM17 FG02: AN, OLD LAC and SAC fields not captured correctly
Release 16 (GSM16/UMTS03)
AA19011671 CAMEL PHASE 3: Network Dialled Services CAMEL Subscription Information
(N-CSI)
A19011684 CAMEL PHASE 3: MSC Dialled Services CAMEL Subscription Information
(D-CSI) Support
A19011816 CAMEL Phase 3 Furnish Charge Information Call Processing enhancements and
Abandon EDP-R
A19012008 Support of Mobile Number Portability based on Query on Release for Portugal ISUP
A19012022 Camel Phase 2 Billing Enhancement
A19012197 CAMEL P3 SMS-CSI Umbrella Document
A19011809 CAMEL P3 FCI SMS
A19011818 CAMEL Phase 3 SOC/Billing Framework
A19012198 CDR Optionality for Unanswered calls
A19012200 Reorigination triggered by Release Cause
A19012258 CAMEL Phase 3: ContinueWithArgument
A19012279 CAMEL Ph2 Assisting SSP and CTR
A19012295 CTM-TTY Circuit Pooling
A19012546 Incoming Trunk Record Enhancement for CAMEL
A89007097 Billing Buffer Overflow
A89007099 Sourcing:cmcc Call Forward Billing Requirement
Q00390220 14.4 Data Calls - Billing Product Improvement
Q00415282-01Called/Calling Subscriber Category
Q00473543-01Channel Type
Q00505445 Create new module code (MC=028C) for patching billing
A60011214 Mobile Number Portability (MNP) Enhancement
A60011241 GSM/UMTS Supplementary Services Location Discrimination
A60011396 UMBRELLA FN for A60011396 and A60011397
A60011396-InitialDP (Initial Detection Point) enhancement to include
naCarrierInformation.
A60011397-CAP2 Establish Temporary Connection (ETC) and Connect Support
for NA Info
A60011410 CAP 2: IN support for Equal Access (EA) Billing
A60011426 LoCation Services (LCS) functionality description
A60011497 USSD Billing
A60010347 CAMEL PHASE 2: Call Re-Origination
A60010354 CAMEL Phase 2: Send Charging Information (SCI)
A60010376 CAMEL Internal SRF support
A60010390 SRF Implementation for GSM 03.66 and 3G TS 23.066 based MNP
A60010812 IT2: UMTS Billing Enhancements
Release 13 (GSM13)
A60009171 Support of ETSI Mobile Number Portability (MNP)
A60009178 Partial Billing Enhancements
A60009179 Enhancements to Incoming Trunk Call Detailed Record
A60009197 Austrian Carrier Selection Phase 2
A60009304 GSM Release Info. Enhancements
Release 12 (GSM12)
No features in GSM12 directly affected the format or content of the billing records and fields.
Release 11 (GSM11)
GR2474 GSM Optimal Routing
GR2638 Anonymous Call Rejection
GR2647 GSM11 Israeli ISUP
GR2659 GSM11 CAMEL Ph2 Furnish Charging
GR2671 File Transfer Sequence Number Optionality
GR2798 GSM11 DMS-MSC Address Enhancements
GR2803 NOA Address Format Customizing
GR2897 GSM11 German Carrier Selection - Part II (Whitelist/Blacklist Screening and
Billing)
GR2905 GSM11 GeoZone Tone Support on ITU-T Recommendation Q.1218 CS1-R
Protocol
GR2926 Service Switching Function (SSF) enhancements for Mobile Originated (MO) Short
Message Service (SMS) calls
GR3105 DNSCRN Enhancements
Release 10 (GSM10)
GR1648 CAMEL Phase 1 Network Call Reference Support
GR2467 GSM 12.05 Value Compliance
GR2479 DMS-MSC 6 port Multi Party (MPTY) service
GR2495 Support of Australian Interconnect ISUP for GSM10
GR2542 Roaming Record and Common Equipment Usage Record Optionality
Release 9 (GSM09)
GR1278 IN Integrated DMS-MSC/SSP
GR1293 Explicit Call Transfer (ECT)
GR1301 GSM Support for 30 Digit Translation (UXLA)
GR1306 MSC Support for 14400bps Data Rate
GR1335 Multiple Network/Country Codes per MSC
GR1346 Network Optimisations for Call Forwarding
GR2082 Generic Billing Enhancements
GR2107 Italian TUP for DMS-MSC
GR2121 ATUP-POI Phase 3 Enhancements on the DMS-MSC
GR2154 CISS Billing
GR2155 AoC Tariff Band Change
GR2329 Indirect Access Screening and NOA routing (for Germany)
Release 8 (GSM08)
AD8029 Call Re-Establishment
AD9035 Calling Name Delivery (CNAM)
AD9036 Irish Blue Book TUP on the DMS
AD9095 Redirection Features Evolution
AD9284 GSM IN Integrated MSC/SSP Product Description
AD9291 Malicious Call Trace
AD9320 Extension Services Simultaneous Alerting
AD9363 Mobile Access Hunting
AD9365 GSM/PCS 1900 Special Translation
AD9388 V.42-bis Data Compression
AD9403 ETSI ISUP Market Enhancements
AD9415 PCS 1900 GSM Local Number Portability
GR1002 National Number Format of OCN/RDN for CF
GR1330 RLT Support for ANSI PRI
Release 7 (GSM07)
AD7988 Account Code
AD7995 ETSI Release Link Trunk
AD8001 GSM07 Integrated MSC/SSP Product Description
AD8005 Mobile Identification for Emergency Calls
AD8006 RLT Implementation for GSM
AD8021 GSM Support of 3 Digit Mobile Network Code
AD8028 Multiple Vocoders
AD8030 ATUP Enhancements for Interworking to the DMS-MSC
AD8966 Billing for Off-Board IN Services
Release 6(GSM.06)
AD7337 DMS-MSC Voice Mail Call Dropback
AD7613 PCS-1900 800 Database Query
AD7614 Phase 2 PRN Support for GSM Data Services
AD7695 SS7 Compliance & Cleanup
AD7744 * and # Translation for GSM
AD7809 MSC COLP/COLR Supplementary Services
AD7839 Functional Support for Phase 2 Bearer Capability
AD7895 Handover Billing Enhancements
AD7903 Billing Enhancements for Diagnostic and Cause for Termination
AD7904 Addition of Cell of Origin as a Suffix to MS Dialled Digits
AD7916 Nortel ETSI ISUP Call Re-origination
Release 5 (GSM.05)
AD6465 Partial billing (Long duration billing)
AD7042 IMEI Checking enhancements
AD7077 PCS 1900 Billing enhancements
AD7082 Operator determined barring
AD7170 CLIP/CLIR enhancements
AD7323 SMS Billing
AD7324 MSC Software optimization (Handover billing generation)
AD7363 Charge analysis
AD7364 Hot billing
AD7365 AoC enhancements
AD7366 GCDR Sequence number
AD7385 Data feature enhancements for GSM dual services
AK4305 Austrian AoC enhancements
Release 4 (GSM.04)
AD5694 ETSI ISUP V1.0 Enhancements
AD6334 DMS-MSC Multi-Party Service
AD6340 GSM Data Services FPE Development
AD6341 BC/LLC/HLC enhancements for GSM data services
AD6458 Billing Record Enhancements
AD6462 Advice of Charge
AD6503 Distance Based Billing and Call Record Type Indication Using Network Transport
Parameter (NTP)
AD6584 Alternate Line Service (ALS) for the DMS - MSC / VLR
AD6875 GSM Billing Enhancements for ANSI-ISUP
AD6876 Billing Enhancements For MF
AE1525 Services Support for BTUP on DMS-MSC
Release 3 (GSM.03)
AD4776 Line Identification Supplementary Services
AD5729 MM support for EIR Interface
AD5765 BC Modifications and Assignment Request in the MSC
AD5768 Provide enhancements to GSM-MSC billing platform and billing capture points
AD6083 Datafillable Cause/Treat Mappings for DMS-MSC
Release 2 (GSM.02)
AD4898 GSM-MSC Mobile Originated and Mobile Terminated Call Record Capturing
AD4662 GSM-MSC Call Forwarding Supplementary Services
Release 1 (GSM.01)
AD4615 DMS-MSC Billing Formatter
AD4616 Billing Framework
AD4617 DMS-MSC Billing Recording Base
A2.4.2 GSM Railways (GSM-R) Features
Release 02 (GSMR02)
GR3049 enhanced Multi-level Precedence and Pre-emption Service for Mobile Subscribers,
Phase 2
GR3115 Integrated Acknowledgment Centre on Digital Multiplex System-Mobile Switching
Centre (DMS-MSC)
Release 01 (GSMR01)
GR2880 eMLPP Enhancements for Mobile Subscribers
GR2898 Phase 1 Voice Group Call Service (VGCS) and Voice Broadcast Service (VBS)
GR3011 DMS-MSC Support for GSM-R Functional Addressing Phase 1 and Presentation
of Functional Numbers to Called and Calling Parties.
Part B:
Billing Records and Formats
APP 5.9 Standard Part B: Billing Records and Formats
B1 Introduction
This section provides an overview of the requirements for GSM/UMTS billing systems and the
support of these requirements by the MSC billing platforms. The remainder of this part of the
specification provides further details of the MSCs billing capabilities:
Section B2, Billing Files and CDRs on page 31 describes the format of the billing file
and the CDRs it contains
Section B3, Production of Call Detail Records on page 37 describes the production of
CDRs for different calls
Section B4, Structured Records and Modules on page 59 describes the call records and
modules which may be captured in CDRs
Section B5, Data Field Descriptions on page 115 describes the data fields in the CDRs
Section B6, Example Call Scenarios on page 261 uses example call scenarios to show
how CDRs are produced for different calls
B1.1 Overview of Billing Requirements
In order to be compliant with the general requirements of 3GPP TS 32.205, a telecommunications
switch in a PLMN must create and store details of all of the calls that it processes. It must also
provide an interface to allow a downstream processor to retrieve a copy of the records from the
switch. The MSC meets these requirements as summarised in Figure 3.
Figure 3 MSC in the telecommunications management network
Billing, Administration
and Customer Care
System
Public Land
Mobile Network
Call Detail
Records
Mediation Device
Telecommunications Management
Network (TMN)
File Transfer Interface
MSC
Part B: Billing Records and Formats Standard APP 5.9
In the PLMN, the MSC provides call switching functions to set up and clear calls for GSM/UMTS
subscribers. As a result of these operations, it produces a number of different Call Detail Records
(CDRs) to capture information about the network facilities and services used for the calls that it
processes. For example it produces mobile originated and terminated CDRs for calls that it connects
to mobile subscribers, and trunk CDRs for calls that it routes over trunk connections. Additional
information may be appended to the main record in a module. For example the use of a
supplementary service (SS) is captured in an appended SS information module. The CDRs are
collected together and stored in billing files on local physical media.
The Telecommunications Management Network (TMN) comprises components which provide
management functions for the network. One of the management systems is the Billing,
Administration and Customer Care System (BACCS)
1
which, among other things, produces
customer bills and the invoices used to settle accounts with other operators. To settle accounts with
other GSM/UMTS PLMN operators, the BACCS uses the collected CDRs to produce Transferred
Account Procedure (TAP) records. The TMN may include intermediate components called
mediation devices. These provide mediation functions which include additional storage and utilities
for converting the collected files into different formats.
B1.2 MSC Billing System
B1.2.1 Overview
The MSC billing system is effectively in two parts: the MSC and the Supernode Billing Application
(SBA). The MSC produces the call detail records (CDRs) for the calls that it processes. The SBA
collects these billing records and puts them into a billing file. The SBA runs on the Core and Billing
Manager (CBM). The CBM is co-located with the MSC and physically connected to it with high
speed data links. It provides the disk storage for the billing files, backup facilities and the file
transfer interfaces to the downstream processor. The MSC with the SBA/CBM is shown in Figure 4.
1.
There are a number of different terms used for the BACCS. These include billing centre and administration
centre (ADC).
Figure 4 MSC with the SBA/CBM billing architecture
In normal operation, the MSU handles the processing of calls, Short Message Service messages
(SMSs) and Call Independent Supplementary Service (CISS) operations. The CA is also used for
call processing e.g. handling trunk connections. A single call may be handled by more than one
MSU. On the MSU(s), once the call is released, or the operation is complete, the AMAPROC CDR
formatter formats the call data. It then sends the data to the formatted billing data sender which
sends it to the CA. The billing data receiver on the CA passes the formatted data to the AMAPROC
formatter. The formatter recognises that the data from the MSU has already been processed and so
passes it directly to the SBA buffer. For call data from the CA the AMAPROC formatter creates the
formatted billing information and passes it to the SBA buffer. The SBA buffer buffers the data
before sending it in the primary substream to the SBA on the CBM. The CBM writes the billing
data to its disks. If the SBA is unable to accept billing records, the CA sends the billing information
to backup disk stores. When the SBA is available again, the billing system enters recovery mode
and the CA sends the backed up records to the CBM disks in the recovery substream. For
information on the production of the billing file refer to Section B2.1. For more information on the
capabilities of the SBA and the CBM, refer to the Billing Application OA&M Manual [19].
Downstream
Processor (DSP)
Call Agent (CA)
Files of billing data transferred to
a downstream processor.
Key
Storage of billing files:
Backup DVDs sent to a
downstream processor.
Primary substream
Recovery substream
CBM
Backup
Disks
FTP
SBA Buffer/Comms System
Transfer of billing files:
(primary and/or recovery files)
Recovery
DVD
backup
SBA
Recovery
Ethernet
LAN
MSC Scalable Unit (MSU)
FTP
Storage
Call Processing
Billing Data
Call Processing
Formatted Billing
AMAPROC
Data Sender
GSM CDR formatter
(MSU)
Receiver
AMAPROC
GSM CDR formatter
Disks
Recovery
Substream
Primary
Substream
SFTP
SFTP
The SBA may be connected through a file transfer interface to a downstream processor (DSP). As
shown in Figure 3, this processor is either the BACCS or a mediation device. The SBA on the CBM
provides the File Transfer Protocol (FTP) interface over an Ethernet network with ISO 8802-3 at
the Data Link Layer. Using FTP a craftsperson can set up a schedule on the SBA to send billing
records to the DSP either after the files are closed with the Outbound FTP feature, or while the file
is open for real time transfer via Open File FTP. Alternatively the DSP can use the FTP connection
to pull records from the SBA. The SBA also supports secure file transfer using the SSH (Secure
Shell) File Transfer Protocol (SFTP) as implemented by the OpenSSH package. The CBM runs the
OpenSSH sftp-client and the DSP runs the sftp-server. The connection established between the
client and server secures passwords and all of the transferred data. For more information, please
refer to the GSM Supernode Billing Application Interface Guide.
2
Some operators do not use the file transfer interface. Instead, they use the backup DVDs for file
transfer. To do this they send the DVDs to the DSP where the files are read. However, even where
operators do use the file transfer interface, they normally send the backups to the DSP on a regular
basis.
As well as the normal billing service, the SBA supports the Nortel proprietary hot billing service.
For the normal service, billing records are generated in the normal billing data stream which uses
the primary and recovery substreams as already described. If configured to support the hot billing
service, the MSC produces CDRs in near real time in a separate hot billing data stream. The hot
billing stream has its own primary and recovery substreams just like the normal billing stream.
B1.2.2 Billing File Storage and Storage Capacity on the CBM
Within the aTCA rack there are two CBMs operating in active/standby mode. The active CBM can
store up to 103 Gigabytes of information on a disk. This information is also mirrored to another disk
within the CBM. This means that if the main disk fails, billing information can continue to be stored
on the mirror disk. The billing data is stored in replicated file systems which means that the billing
data stored on the active CBM is also stored on the standby CBM. Once again, the standby CBM
has mirrored disks internally. This means that there are four copies of the billing data and this
provides resiliency to data loss in the event of a failure.
While it is straightforward to state the storage capacity of each platform, it is much more difficult to
say how many days worth of records these disks can hold. The type of traffic, the volume of traffic
and the number of busy hour call attempts (BHCA) as well as the average traffic all have an impact
on the amount of billing information generated. For example, customers using a pre-paid IN service
generate bigger call records than those sending short messages. This specification provides
information about the size of all records and modules that the MSC generates. Customers can use
this information along with their knowledge of the traffic profiles on their MSCs to calculate the
number of days worth of records that each MSC/billing platform can store.
2.
SBA Audit is not supported over SFTP.
B2 Billing Files and CDRs
This section describes the structure and format of the billing file and the CDRs that it contains. It is
divided into the following sections:
Section B2.1 describes the production of the billing file
Section B2.2 describes the format of the billing file on disk
Section B2.3 describes the billing example CDROM.
Section B2.4 describes the naming convention used for billing files
Section B2.5 describes the structure and format of the CDR
B2.1 Production of the Billing File
This billing system can support the generation of billing records in two different billing streams: the
normal billing stream and the hot billing stream. The format of the records in both streams is the
same, but the hot billing stream provides near real time access to the records. The process for
generating records in the normal billing stream is summarised in Figure 5. Production of hot billing
records is described in sections B3.5 on page 44 and D1 on page 341.
Figure 5 Production of the billing file in the normal billing stream
CDR Formatting
Active primary and recovery billing files
containing CDRs packed into 2Kbyte
Call information in
messages from MSU(s)
SBA Buffer/Comms System
Formatter
Buffers
CDR CDR CDR
CDR CDR CDR
data blocks
CDRs sent in the normal stream
(e.g. GCDR) to disk in primary
and recovery substreams
CDRs written to backup
Backup
Recovery
SBA
Call Agent
Formatted CDRs written
to buffers in the SBA buffer/
Comms system.
storage if communication
with the SBA fails
Call
information
On the MSC, calls are handled and processed on the MSC Scalable Unit (MSU) and the Call Agent
(CA). When a call is disconnected the MSU formats the call information and sends it to the CA. The
CDR formatter packs the CDRs into a buffer. For calls processed on the CA, the CDR formatter
creates the formatted billing information before passing it to the buffer. When the buffer is full,
when an operator-defined timer expires, or when there is not enough room for a new record, the
CDR processor sends the information to the SBA which writes the information to disk. The
information is written to the currently active billing file in 2 Kbyte blocks and the data is transferred
in the primary substream to the disks. This is the normal mode of operation: one billing file is active
and it is updated with records in the primary substream.
If the MSC is unable to communicate with the SBA for any reason, it goes into backup mode and
writes the billing information to backup disks. When the SBA is available, the MSC goes into
recovery mode and sends the backed up billing information to the SBA in the recovery substream.
When recovery starts, the next record sent on the primary substream is out of sequence with the last
record sent on the substream. When this happens the SBA closes the current active file and opens a
new active file. Getting an out-of-sequence record is one of the SBAs file rotation criteria (closing
one file and opening another). The SBA writes the most current records from the SBA Buffer
System on the CA to this new active file.
The records in the backup files on the call agent are sent to the SBA in the recovery substream. The
SBA opens a separate active file in which it writes the recovered records. During recovery,
therefore, there are two active files open: one receiving information from the primary substream
and the other from the recovery substream. Within each billing file, all records are in sequence.
Taken together, all files contain a complete history of all of the billing records.
For more information on the production of billing records, partial billing records and records in the
hot billing stream, refer to Section B3 on page 37.
B2.2 Format of the Billing File on Disk
B2.2.1 File Format
The billing file is a structured object which contains CDRs. It also contains other records which
provide the structure to the file and information about the amount of valid billing information in the
file. The structure of a billing file on disk is shown in Figure 6.
Figure 6 Billing file format on disk
The first data element in a data block is the block descriptor word. The first two bytes of this four
byte data element indicate the total number of valid data bytes in the 2 Kbyte block. The byte count
includes the bytes of the block descriptor word itself. The second two bytes of this data element are
unused and are filled by default with zero in all instances.
Each record in a data block is preceded by a record descriptor word. The first two bytes of this four
byte data element indicate the total number of valid data bytes in the record. The byte count
includes the record descriptor word itself. The second two bytes of this data element are unused and
are default filled with zero in all instances.
In the disk file format the data block size is fixed to 2 Kbytes. The file is padded with an ignored
area if CDRs are not stored in the full 2 Kbytes of the data block. The ignored area may look like
valid billing data as it is not initialised. However, the byte count indicates the amount of valid data
in the block. In normal circumstances, the beginning and end of a billing file are indicated by a file
transfer record: a file transfer in record appears in the first data block of the file; a file transfer out
record appears in the last. However, in exceptional circumstances, this does not apply. For more
information, refer to the end of Section B2.1 which describes the exception and recovery
procedures.
... ... ... ... ... ... ... ...
Block
Descriptor
Word
Record
Descriptor
Word
Block
Header
Record
Record
Descriptor
Word
File
Transfer In
Record
Ignored area
Block
Descriptor
Word
Record
Descriptor
Word
Block
Header
Record
Record
Descriptor
Word
CDR
Block
Descriptor
Word
Record
Descriptor
Word
Block
Header
Record
Record
Descriptor
Word
CDR
Record
Descriptor
Word
File Trans.
Out
Record
Structured Record
Record Header
Data Fields
Module: One
Data Fields
Module Segment
Module: Two
Data Fields
Block 1
Block 2
Block n
Billing File Blocks
Ignored area ............
...... Ignored
area
Module: N
Data Fields
2 Kbytes
A record descriptor word
......
and associated CDR
Key
B2.2.2 Production of Auxiliary Records
The SBA generates the block header records, the file transfer in record and the file transfer out
auxiliary records. The SBA receives the billing records generated by the CDR formatting function
in the core, inserts the auxiliary records and writes them to billing files on the disk in the primary
and recovery substreams. However, the SBA platform uses the clock and restart auxiliary records
generated by the core.
The SBA platform does not populate the record number field in auxiliary records and so the field is
set to the default value.
B2.3 Sample Billing Information
Sample billing CDROMs are available in each product release and they provide examples of billing
records for many common call scenarios. They also contain documentation for each example
scenario. These CDROMs can be used prior to the MSC upgrade to test the downstream billing
system's ability to accept billing records in the format of the new release. There are two different
CDROMs: World Trade and North American. The version chosen is determined by the location of
the MSC. For information on the order codes for the sample billing CDROMs please see
References and Sample Information on page viii.
B2.4 File Naming Conventions
B2.4.1 Conventions used by the SBA Management Function
By default, the SBA management function uses DIRP (Device Independent Recording Package)
file naming conventions. The DIRP file name is seventeen characters long as shown in the
following table.

Character
1
Character 2-
Character 7
Character 8-
Character 11
Character 12 -
Character 13
Character 14 -
Character N
File Type Date Time Sequence Number Steam Name
A - Active YY - Year HH - Hour XX - Integer value Filename
e.g. GCDR
U - Unprocessed MM - Month MM - Minute
P - Processed DD - Day
Example:
Filename: A971031102204GCDR (Active file, 31st October 1997, 10:22am, 04, standard billing file)
B2.5 The MSC CDR Structure
The structure of a MSC billing record is shown in Figure 7. Each record consists of a structured
record and zero or more appended modules. When modules are included an End of module List
module is included immediately following the last appended module. Further, the inclusion of
modules in a MSC billing record is indicated in the Record Header.
Figure 7 The MSC call and event record structure (informative)
The MSC record format is based on the Bellcore Automatic Message Accounting Format (BAF).
The records themselves however are all GSM/UMTS specific and totally independent of BAF.
A structured record consists of a set of ordered data fields and is identified by a single structure
code in the Record Header. The data fields contain information encoded in binary coded decimal
(BCD) or hexadecimal format.
Record Header
Module One
Module Two
End of Module List
Structured Record
Detailed Record
A module consists of a set of ordered data fields (using BCD or hexadecimal encoding) and is
identified by a single module code in the first field of the appended module. Modules provide a
common set of related information required by different records e.g. location information, service
information etc. For each type of billing record only a specific set of modules may be appended.
These modules may be appended in any order. Some types of modules are of a replicative nature
and as such may be appended more than once to a record, while others can be used only once.
The length of a formatted MSC billing record is restricted to 1 Kbyte. There are therefore limits on
the number of modules that can be appended to a record. Upon exceeding this limit or the user
provisioned limit the MSC automatically begins production (if provisioned) of partial records. A
partial record is indicated by the presence of a partial information module. The presence of this
module is the only difference between a standard CDR and a partial record. A full description of
partial record generation is provided later in the document (Section B3.4 on page 40).
NOTE The MSC allows the provisioning of the maximum record size. A value in the
range 400 bytes to 1 Kbyte may be provisioned. The default maximum size is
1 Kbyte.
B3 Production of Call Detail Records
This section describes the generation of call detail records (CDRs) for different types of call.
Section B3.1 lists the CDRs which the MSC produces
Section B3.2 describes the use of CDRs with supplementary services, covering call
forwarding, call hold and multi-party services
Section B3.3 describes CDR production during inter-MSC handover
Section B3.4 describes the creation of partial CDRs
Section B3.5 describes the generation of hot billing records
Section B3.6 describes proprietary billing services
Section B3.7 describes how call release information is captured in the call records
Section B3.8 describes how operators can set which records are generated by the MSC
For information on the structure and format of the records listed in Section B3.1, refer to sections
B4 and B5. These sections describe the content of the CDRs, the billing file records and the call
modules and the encoding of the data fields they contain.
For some example call scenarios illustrating the production of CDRs, refer to Section B6.
B3.1 General
In order to provide the data required for billing purposes the following call related records are
defined for the MSC. The contents and purpose of each of these records are described in Section
B4. Section B4 also contains information on records which provide other billing information and
structure the billing file.
Mobile originated call attempt
Mobile terminated call attempt
Roaming call attempt
Incoming gateway call attempt
Outgoing gateway call attempt
Transit call attempt
Incoming intra-PLMN trunk
Outgoing intra-PLMN trunk
Common equipment usage
Short message service, mobile originated
Short message service, mobile terminated
Supplementary service action
Location Services (LCS)
Acknowledgement
Location Update
B3.2 Use of Supplementary Services
There are two basic kinds of supplementary service actions: non-call related and call-related. Non-
call related actions (also called call independent supplementary services (CISS)) allow a subscriber
to administer a service, for example to change the number to which calls should be forwarded. Call-
related actions are those taken during the establishment of a call, for example the invocation of a
call forwarding service.
B3.2.1 CISS Actions
CISS actions may be recorded in SS action records as defined in Section B4.1.12 on page 71.
Datafill on the MSC determines which supplementary services and service actions are recorded.
B3.2.2 Call Related SS Actions
Call related SS actions (usually invocation) may be included in SS information modules appended
to the appropriate call record. For most services, SS information modules are appended to either
mobile originated call (MOC) attempt or mobile terminated call (MTC) attempt records. However,
for some services which are completed via service nodes, e.g. voicemail systems or IN intelligent
peripherals, the modules are appended to trunk records.
Where the use of a supplementary service results in the production of further connections, e.g. a call
forwarding or multi-party service, additional call records are produced to describe the relevant
connections. The use of such services is described in sections B3.2.3 to B3.2.5. These services are
also illustrated in the example scenarios in Section B6 on page 261.
B3.2.3 Use of Call Forwarding
When one of the call forwarding services is used, the MSC that forwards the call, shall produce the
call records for the service. For example, if mobile subscriber A calls subscriber B who has calls
forwarded to mobile subscriber C, the following records are produced:
A Mobile Originated Call Attempt record (MOC) captures information for A for the
call leg from A to B.
A Mobile Terminated Call Forwarding Attempt record (MTCF) captures information for
B for the call leg from A to B. The appended SS information module captures
information about the type of call forwarding.
A Mobile Originated Call Forwarding Attempt record (MOCF) captures information for
B for the call leg from B to C. The appended SS information module captures call
forwarding information for the call leg.
A Mobile Terminated Call Attempt record (MTC) captured information for C for the
call leg from B to C.
The MTCF/MOCF records for the party using call forwarding (subscriber B) contain SS
information modules in which the SS code indicates the type of call forwarding. For information on
the MOCF/MTCF records and the SS information module, see sections B4.1.1, B4.1.2 and B4.2.4
respectively.
For further information concerning the recording of call forwarding services see the example
scenario in Section B6.7 on page 272.
B3.2.4 Use of the Call Hold Service
The use of the call hold service shall be recorded in an SS information module appended to the
appropriate call record. For the avoidance of doubt, the duration for which the call is held is not
recorded.
B3.2.5 Use of the Multiparty Service
The use of the multi-party service requires a minimum of 3 subscribers and the use of a conference
circuit. For the purpose of the following description the subscriber invoking the service is referred
to as the conference originator (A) and the conference call is regarded as consisting of a number of
individual legs between the organiser and the other parties (B, C, etc.) in the call.
Normal MOC and MTC call records shall be generated for each party and each leg of the call. In
addition a common equipment record shall be produced for the conference originator in order to
record the use of a conference bridge and to record the total duration of the conference connection.
Example: Subscriber C calls subscriber A. Subscriber A places the call from C on hold
and makes a second call to subscriber B. Subscriber A then invokes the multi-
party service in order to set up a conference call with B and C.
Assuming that the appropriate types of record are enabled, the following call records
shall be produced:
- An MOC record for subscriber C and the C ->A leg of the call
- An MTC record for subscriber A and the C -> A leg of the call
- An MOC record for subscriber A and the A -> B leg of the call
- An SS information module is appended to the MTC for the invocation of the call
hold service by subscriber A
- An MTC record for subscriber B and the A -> B leg of the call
- An SS information module is appended to the MOC for the invocation of the
multi-party service by subscriber A
- A common equipment record for the use of the conference bridge by subscriber
A
Each of the MOC/MTC records for the conference originator (A) shall include the supplementary
service code for the multi-party service. Any subsequent action affecting only one leg of the
connection shall be recorded in an SS information module appended to the appropriate call record.
For further information concerning the recording of multi-party services see the example scenario
in Section B6.9 on page 277.
B3.3 Inter MSC Handover
In the case of an inter-MSC handover the controlling MSC, as defined by 3GPP TS 23.009, remains
in control of the connection and shall therefore, produce the call record. For the avoidance of doubt,
it is not necessary to produce call or event records in the subsequent MSC(s). However the MSC
provides an optional mechanism for generating trunk records to capture information about the inter-
MSC connection resulting from handover. The generation of these trunk records depends on
provisioning details on the MSC.
For example, a subscriber resident on MSC A at the start of a call may move to MSC B during the
call. Billing information for the subscriber on MSC A is captured in a MOC or MTC record
depending on whether the subscriber makes or receives a call. When the subscriber moves to MSC
B, MSC A produces an outgoing trunk record and MSC B an incoming trunk record, for example
outgoing and incoming intra-PLMN trunk records. The Called Number field in both trunk records is
populated with the translated Handover Number. This is the number used to route the connection of
the call from MSC-A to MSC-B. Both trunk records have a trunk usage information module
appended to show that they were generated as a result of handover. The incoming trunk record on
MSC B also has location and channel information modules appended to capture information about
the changes the subscribers location. This information is passed back to MSC A which appends
location and channel information modules to the MOC or MTC for the subscriber.
NOTE The MSC supports a software option which allows the provisioning of multiple
Mobile Country Codes (MCC) and Mobile Network Codes (MNC). The HLR
has a similar facility supporting multiple MNCs only. This allows a network
operator to lease spare capacity to/from other operators, or to consolidate the use
of equipment currently in separate networks. If this option is in use, the location
and channel information modules resulting from handover may contain different
MNCs.
B3.4 Generation of Partial Records
B3.4.1 Overview
In order to increase the security of the recording process and to simplify post processing, the MSC
shall provide the capability to generate a sequence of call records to describe a single connection or
transaction.
In case of connections of extended duration, the loss of a single call record may result in an
unacceptable loss of revenue. If the connection is, for example, recorded in a number of consecutive
partial records generated at say hourly intervals, then the maximum loss of revenue is the equivalent
of a one hour continuous connection.
Most modern billing systems employ some form of cumulative credit-limit checking based on the
stream of input call records. If however, a call record is only produced at the end of the connection
then a subscriber may avoid such credit checking by employing a connection for days, weeks or
even months without a single call record being produced.
The MSC shall generate a partial record (if enabled) upon:
a record exceeding the record size limitation
expiry of the partial record timer during long duration calls
the re-establishment of a call after a failure in the radio connection
The structure of a partial record is exactly the same as that of the call detail record for which it was
generated except that a partial record includes a partial information module. This module shall be
the last module appended to each such record.
Section B3.4.2 provides some general information on the production of partial records. Sections
B3.4.3 to B3.4.5 describe the manner in which the three defined types of partial records are
generated by the MSC.
B3.4.2 General Information on Partial Records
The generation of partial records may be disabled entirely. In addition, the generation of partial
records for long duration calls may be disabled via provisioning. If, however, partial record
production is enabled at all, then the generation of partial records due to exceeding the size
limitation shall always be enabled. In other words, long duration partial billing can be disabled
separately, but size limitation partial billing cant be disabled without turning off the entire feature.
All partial records for the same connection shall contain the same partial record reference number
and may be ordered via the partial record sequence number. Both of these parameters are captured
in the partial information module. One of these modules shall be appended to every partial record
generated by the MSC. The presence of this module shall be the only characteristic of
differentiation between a standard call detail record and a partial record. The timestamps in each
partial record shall correspond to the duration of the individual partial record rather than the
connection as a whole i.e. the disconnect field (mobile originating/terminating call attempt records)
or the release field (trunk, roaming, and common equipment usage records) of one record shall
coincide with the answer field of the next. Each time a new partial record is created the cause for
termination of the previous record shall contain the value partial record or partial record - call re-
establishment. The cause for termination of the final partial record shall contain the true cause for
termination of the connection.
NOTE Generation of a partial record can only occur if the generation of the appropriate
billing record is enabled. No partial records shall be generated if the record
generation is disabled.
B3.4.3 Partial Record Production - Exceeding of Record Size Limitation
Most of the records defined in this specification are of variable length and some at least are
potentially unlimited in size. The maximum length, however of a formatted MSC billing and
accounting record is 1K-byte. The MSC shall therefore automatically begin the production of
partial records upon exceeding the record size limitation. For added flexibility the MSC shall allow
definition by provisioning of a maximum record size in the range 400 bytes to 1K-bytes.
Upon the exceeding of the record size limitation a partial record shall be generated. The first record
shall consist of a standard structured record, a number of modules and a partial information module.
The second partial record shall consist of the unmodified (except for the timestamps) standard
structured record, a number of new modules appended during the lifetime of this subsequent record
and a partial information module. The record may also contain a number of defined (see below)
module types that remain un-detached between two contiguous partial records. Any subsequently
generated partial records shall be generated via the same process.
The last bearer service information or teleservice information module appended prior to the
invocation of a subsequent partial record generation shall be reproduced in the subsequent partial
record. If a data service information module has been appended then it shall be reproduced in each
subsequent partial record. If the real time billing supplementary service is active on the party for
whom partial record production has been invoked then a hot billing (SS) module shall be appended
to each partial record produced. Finally, if the option to record only the first and last location and
channel information modules is selected then the first and last location and channel information
modules shall be reproduced in each subsequent partial record. For avoidance of doubt should the
last location change then only those partial and subsequent partial records generated following the
change will be updated with a new last location and channel information module.
B3.4.4 Partial Record Production - Expiry of the Partial Record Timer
Two configurable timers are associated with partial record production. The partial record timer sets
the frequency at which partial records shall be produced throughout the life of a call and the audit
timer sets the frequency at which calls in progress are polled to see if the production of a partial
record is required. Once a poll of a call in progress reveals that a partial record is required, a call
record is generated and subsequently thereafter at the partial record timer interval until the
termination of the call.
Upon the expiry of the partial record timer a partial record shall be generated for those calls that
have been running for longer than a specified time. The first record shall consist of a standard
structured record, a number of modules and a partial information module. The second partial record
shall consist of the unmodified (except for the timestamps) standard structured record, the same
modules contained in the first partial record, any additional modules appended during the lifetime
of this subsequent record and a partial information module. Any subsequently generated partial
records shall be generated via the same process. For avoidance of doubt should a size limitation be
exceeded whilst generating any of these records then the process described in Section B3.4.3 shall
be invoked.
The partial record timer and the audit frequency are set using office parameter GSM_PB_
INTERVAL in table OFCENG. GSM_PB_INTERVAL contains three fields: hours, minutes and
audit interval. The settings in the hours and minutes fields set the frequency at which partial records
are produced for long duration calls. The setting in the audit interval field sets the frequency with
which the MSC checks the active calls to see whether or not to generate partial records. For
example, the setting 0 hours, 15 minutes, audit interval 5 minutes sets the MSC to perform the
partial billing audit every 5 minutes. If it finds any active calls that have been up for more than
15minutes, it generates partial records for them.
The range of settings in the hours field is 0 to 24. The permitted values in the minutes field are 0, 5,
10, 15, 30 and 45. If hours is set to 0, the minutes field can be set to any permitted value. If hours is
set from 1 to 24, the minutes setting is restricted to 0. The timer range is therefore between 5
minutes and 24 hours. A setting of 0 hours 0 minutes disables the timer and switches partial billing
off.
The audit interval can be set to 5, 10, 15, 30 or 45 minutes with settings of AUDIT_5, AUDIT_10,
AUDIT_15, AUDIT_30 or AUDIT_45 respectively. Setting the audit interval to AUDIT_OFF also
switches off partial billing.
NOTE In a call where the Explicit Call Transfer service is invoked, the partial billing
behaviour may differ between the mobile originated and terminated call records
(MOC and MTC). For example, consider the scenario where mobile A calls
mobile B, puts B on hold, then calls mobile C and invokes ECT. At this time
mobile A drops out of the call, while mobile B and C continue talking. Assuming
that no roaming or call forwarding occurs, four records are generated: two
MOCs (A-B, A-C) and two MTCs (A-B, A-C). The Call Duration in the MOCs
contains the time portion before the call was transferred (for more details on
ECT Call Duration please refer to NOTE 5 on page 146 in Section B5.2.15). The
Call Duration in the MTCs contains the entire time period since the time B or C
answered A's call until the time that B or C disconnects. For example,
- A calls B and B answers at 10 o'clock;
- A puts B on hold then calls C and C answers at 10:02;
- A invokes ECT and drops out of the call at 10:03;
- B and C continue and finish talking at 10:09;
The Call Duration in the MOCs is 3 minutes for A-B and 1minute for A-C. The
Call Duration in the MTCs is 9 minutes for A-B and 7 minutes for A-C.
Assuming the partial billing audit interval is set to be 5 minutes and the
frequency is 5 minutes, the partial billing modules will be generated and
appended to the MTCs as the call lasted longer than 5 minutes, but will not be
generated for the MOCs.
B3.4.5 Partial Record Production - Call Re-establishment
After a radio link failure the MS may attempt to re-establish the call. If successful, the MSC
produces partial records to record the duration of the call prior to the radio link failure and the
subsequent duration of the call once the call has been re-established. The cause for termination in
the first partial mobile originating/terminating record indicates partial record call re-
establishment. The appended partial information module also indicates successful re-establishment
in its partial reason field. The last partial record and module contain the reason for the call being
terminated, e.g. normal call release. The chargeable duration stored in the original record is the time
period from answer to detection of the radio link failure by the MSC. Both the seizure and
answer times of the subsequent partial record correspond to the time at which the new traffic
channel is allocated for the re-established call. That is, the answer time is the time at which the new
traffic channel is allocated by the MSC i.e. when the ASSIGN COMMAND is sent to the MS.
If the radio link fails more than once during a call, a partial record is created for each successful re-
establishment as described above. All of the partial records belonging to the same connection are
identified by the same partial record reference number and partial record sequence number captured
in the partial information module.
If the attempt at re-establishment is unsuccessful, a normal call record is generated indicating that
the call was released due to an abnormal termination. The chargeable duration stored in this record
covers the time period from answer to the detection of the radio link failure by the MSC.
NOTE As the MS and MSC may detect the radio link failure at different points in time,
it is not possible to guarantee that the duration used for the AOC display
corresponds to that recorded in the call records. The purpose of the above
procedure is merely to minimise any discrepancies that may occur.
B3.5 Hot Billing
The MSC shall provide the ability to produce call detail records on a real time basis. This ability is
called hot billing. Hot billing is handled by the Nortel elements as a proprietary supplementary
service. The service details are provisioned against subscriber IMSIs in the HLR. The operation of
hot billing also requires the provisioning of a hot billing data stream on individual MSCs. If an
IMSI is provisioned for real time call detail record production in the HLR, call detail records shall
be output on a real time basis on a suitably provisioned MSC.
When the subscriber performs a location update operation, his/her service details, including those
for hot billing, are copied to the MSC/VLR in the MAP InsertSubscriberData message. In this
message hot billing is defined by a proprietary supplementary service code in the normal manner.
However, for some types of mobile terminated call, for example where a subscriber uses call
forwarding unconditional (CFU), the subscriber data in the MSC/VLR is not examined. To ensure
that hot billing records are generated in these cases, the gateway MSC and HLR use the MAP
version 3 signalling of the mobile terminated call setup process to copy the hot billing data. When
the MSC sends the HLR a SendRoutingInformation message to find the subscribers current
location, the HLR responds with a SendRoutingInformation acknowledgement message which
includes the hot billing service information. The gateway MSC, if provisioned, produces a billing
record for the call in the hot billing data stream. If the MSC and HLR use MAP version 2 signalling,
the hot billing of early call forwarding described above is not supported.
The availability of the hot billing stream on the MSC is determined by provisioning. The office
parameter GSM_EMERGENCY_HOT determines whether or not billing records for Type I and
Type II emergency calls are directed to the hot billing stream. At the MSC, a subscriber is
determined to require hot billing if either of the following conditions is true.
if the originating or terminating IMSI is provisioned with the hot billing service,
if the originating or terminating IMSI is an inbound roamer and the office parameter
MARK_ROAMER_HOT is enabled. This discrimination is achieved through
examination of the Mobile country code and the Mobile network code of each IMSI.
If a subscriber is determined to require hot billing, a supplementary service module indicating hot
billing shall be appended to each associated call detail record. These records shall be output in real
time to a different billing file than the standard billing records. If the hot billing stream is not
available (not provisioned on the MSC) the hot billing records are directed to the normal billing
stream.
The rate at which hot billing records are produced shall be provisionable. The maximum rate of hot
billing record generation is defined as approximately 2 seconds after call disconnect (or record
dispatch in the case of partial billing). The provisioning uses a timer which writes the call record
buffers to the billing file at regular intervals, with a maximum rate of every 2 seconds. This means
that after call disconnect, a call record is written to the buffer and then to the billing file at the end of
the next timer period. An exception to this relates to the hot common equipment usage record.
This record shall be generated immediately following the release of an individual multi-party call
connection (that is when one connection is released, the call record is written to the buffer and then
to the billing file at the end of the timer period).
The MSC does not support the real time generation of all defined call detail records. The following
is a list of the records for which real time record generation is supported:
Supplementary Service Action Record
Location Services (LCS) Record
B3.6 Proprietary Billing Services
B3.6.1 Distance Based Billing
Distance based billing allows information about the location of the called party to be captured in the
MOC generated for a mobile to mobile call. This information can then be used to bill the calling
party based on the distance of the call connection.
The location of the called party is specified by the latitude and longitude of the terminating cell site.
The terminating MSC sends the location information in a network transport parameter (NTP) in the
ISUP answer message (ANM). The originating MSC extracts the information and places it in an
Other Agent Information module. It appends the module to the MOC created for the calling party.
The location information may be returned to a calling party in the PSTN. In this case, no records/
modules in the PLMN capture the information. It is up to the PSTN operator to determine what to
do with the information.
NOTE The network transport parameter (NTP) is currently only defined in the ANSI
ISUP standard. Therefore this described functionality is only available in
networks implementing this standard.
B3.6.2 Call Record Type Indication
Multiple billing of an MS may be avoided by setting the call indicator field in the mobile terminated
CDR to No charge. This action shall be performed if an IAM message is received over ISUP with
a call record type indication (in the NTP) set to no charge. If the terminating MSC does not
receive an NTP with a call record type indication parameter then the call indicator field in the
mobile terminated CDR shall be encoded to the default value of no Indication. For avoidance of
doubt the functionality described applies only to the mobile terminating call detail record.
NOTE The Network Transport Parameter (NTP) is currently only defined in the ANSI
ISUP standard. Therefore this described functionality is only available in
networks implementing this standard.
B3.7 Call Release Cause Reporting
In order to be compliant with 3GPP specification 32.205, the cause for termination (CFT) field and
the diagnostic field shall each contain information about the reason a call was released. The cause
for termination field contains a general indication of whether the call was disconnected normally or
not. When available, the diagnostic field contains a detailed technical reason for the release of a
connection. The introduction of the diagnostic field enhances the applicability of Billing Records
for fault identification. For both the cause for termination field and the diagnostic field, the value is
determined by the releasing agent.
The direction of call release determines which type of diagnostic value is selected for the population
of the appropriate MSC call detail record. The signalling agencies which support the diagnostic
field population are covered in the following tables:
Table 107, ITU-T ISUP cause values on page 161
Table 108, ANSI ISUP cause values on page 162
Table 110, GSM TSs 44.068 and 44.069 GCC and BCC cause values on page 164
Table 111, ATUP cause values and error codes on page 165
Table 112, Blue Book TUP cause values and error codes on page 165
Table 113, Italian TUP (ITTUP) cause values and error codes on page 165
Table 114, MTUP cause values and error codes on page 166
Table 115, MF cause values and error codes on page 166
The MAP errors from a mobile agency are not supported. However, the values in the radio layer 3
error messages from a mobile agency are supported (see Table 109, 3GPP TS 24.008 radio layer 3
cause values on page 163). For full information see Section B5.2.52, Diagnostic on page 159.
For any call in which the releasing end point is a mobile, if the releasing mobile disconnects with
any MAP value, the default diagnostic value of FFFFF is captured. If the releasing mobile
disconnects with one of the radio layer 3 protocol values, the diagnostic value indicates the reason
for the call release. For examples of this please refer to Figure 8.
Figure 8 Example call release values in mobile to mobile calls
MSC
A

roaming

Mobile B sends release with CFT value
Radio layer 3

mobile
termination with
CFT=03 and
mobile
origination
with CFT=03 and
diagnostic=00019
diagnostic=00019
User alerting, no answer
MSC
A
roaming

mobile
termination with
CFT=03 and
mobile
origination
with CFT=03 and
diagnostic=00017 diagnostic=00017
User busy
release
Radio layer 3
release
The cause for termination and diagnostic values are propagated from the releasing agents billing
record to the billing record for the other end of that particular call. For example, if the incoming
trunk is an ATUP agency and its call is routed out on an ANSI ISUP agency, there would be an
incoming trunk billing record and an outgoing trunk billing record. If the ATUP end point releases
the call, the ATUP diagnostic value is captured in both the incoming and outgoing trunk billing
records. This algorithm shall be applied in both active call release and unsuccessful call completion
scenarios. Figure 9 illustrates this example where an ATUP PSTN agent releases the call, which
releases the connections at two MSCs and finally at a Mobile. The following steps use the
numbering in Figure 9 to explain this scenario:
1. PSTN agent (ATUP) releases the call with a cause of ATUP Subscriber Busy (SSB),
which is mapped to diagnostic value of 03009.
2. MSC A propagates CFT=03 and diagnostic=03009.
3. Incoming and outgoing billing records from MSC A have CFT=03 and ATUP diagnostic
value of 03009.
4. ANSI ISUP Cause Value User Busy (017) is sent over PSTN network
5. MSC B receives ANSI ISUP release and propagates CFT=03 and ANSI ISUP diagnostic
04017.
6. Incoming trunk record and Mobile termination billing record from MSC B have
CFT=03 and ANSI ISUP diagnostic of 04017.
Figure 9 Example call release values in land to mobile call
This is an example to illustrate how cause values are captured. In call scenarios where different
trunk agents are involved and where there are different reasons for the call to be released, the actual
diagnostic values captured will be different from those shown in this example.
MSC A

outgoing trunk
ATUP releases call

PSTN

ATUP releases
call
ANSI ISUP Cause Value 017

incoming trunk
billing record
with ANSI ISUP
CFT=03 and
Radio layer 3
receives release
from ANSI ISUP
billing record
with CFT=03
and ATUP
of 03009
incoming trunk
billing record
with CFT=03
and ATUP
diagnostic value
diagnostic value
of 04017
diagnostic value
of 04017
with ANSI ISUP
CFT=03 and
mobile termination
diagnostic value
1
2
3
3
6
6
4
of 03009
MSC B
5
NOTE 1 In the event of a timer expiry or an event which should cause a virtual
simultaneous release of both signalling agents involved in the call then the MSC
shall determine the signalling agent responsible for the call release, e.g. the
owning agent of the timer, and select the diagnostic value for insertion into all
the configured call detail records accordingly.
NOTE 2 In circumstances of internal failure i.e. a circumstance where a signalling agent
is not directly responsible for the release of the call connection the MSC shall
determine as accurately as possible an appropriate diagnostic value for the
population of the configured call detail records.
NOTE 3 In the event that a trunk agent is not signalling system number 7, e.g. an MF
trunk, the MSC will determine the diagnostic value as accurately as possible.
NOTE 4 If no cause for termination information is provided the diagnostic protocol of 05,
Unknown shall be selected and the Error code shall be set to 000, Cause for
termination Unknown.
NOTE 5 For calls that are Call Forwarded at the Mobile agency, there are two separate
legs of the call that have two billing records each. When the call is released, the
leg of the call that did not initiate the disconnect will have default values in the
diagnostic fields of its billing records.
B3.8 Controlling the Information that the MSC Generates
This section describes how operators can control the information generated on the MSC for various
reasons, for example so that it is not overloaded with unwanted information. It covers office
parameters and table datafill, software optionality control (SOC) and alarms. For more information
on the MSCs data schema and office parameters, please refer to the Nortel NTPs 411-2231-451 and
411-2231-455.
B3.8.1 Office Parameters and Table Datafill
Record Type/Billing Information Office Parameter/Table Data Table Function
Generation of GCDR 600 logs GSM_BILLING_REPORT OFCVAR Switches the generation of GCDR
600 logs on/off.
Generation of GHOT 600 logs for hot
billing
GSM_HOTBILLING_REPORT OFCVAR Switches the generation of GHOT
600 logs on/off.
Generation of hot billing records for
type I and type II emergency calls
GSM_EMERGENCY_HOT OFCVAR Switches the generation of hot billing
records for emergency calls on/off.
If on, call records for emergency calls
are directed to the hot billing stream.
Generation of hot billing records for
inbound roaming subscribers.
MARK_ROAMER_HOT OFCVAR Switches the generation of hot billing
records for inbound roamers on/off.
If on, billing records for inbound
roamers are directed to the hot billing
stream.
Table 2 Office parameters controlling the generation of billing information
MSC Number (captured in the MSC
Number field and the MSC/MGW
Number field).
GSMMSC_NUMBER OFCVAR Sets the MSC number.
MGW Number (captured in the
MGW Number field and the MSC/
MGW Number field)
IPADDR field GWINV Sets the Media Gateway (MGW)
number. Each MGW has an entry in
the table and the IPADDR for each
MGW sets its MGW Number.
Call duration
These office parameters used to set
the call duration have to be used
together.
If GSM_CALL_DURATION_
GRANULARITY is set to tenths of a
second, the call duration always
contains a tenth of a second value
regardless of the setting of the
GSM_CALL_DURATION_
ROUNDING parameter.
If GSM_CALL_DURATION_
GRANULARITY is set to seconds,
the call duration is measured in a
value rounded according to the setting
of the
GSM_CALL_DURATION_ROUND
ING parameter.
GSM_CALL_DURATION_
GRANULARITY
OFCVAR Sets the granularity of the call
duration to be either seconds or tenths
of seconds. The default is seconds. If
the parameter is set for tenths of
seconds, the call duration is rounded
up to the nearest tenth of a second.
GSM_CALL_DURATION_ROUNDING OFCVAR Sets the way in which the call
duration value is rounded if the
GSM_CALL_DURATION_
GRANULARITY is set to seconds.
The rounding parameter has three
settings: rounded up, rounded down
or rounded to the nearest integer. The
default setting is rounded up.
Call Duration and Call Indicator in
Invalid Long Call Duration Billing
Records
GSM_LONG_CALL_TEARDOWN OFCVAR Sets the way in which long duration
calls are handled. The fields
glctd_hour and glctd_minutes set the
length of the call regarded as long
duration. If the field glctd_type is set
to AUTO and reset_ildr is set to Y,
the Call Duration field is defaulted
and the Call Indicator field is set to
no charge in invalid long duration
records.
Short Message Service, Mobile
Originated
Terminated
IN information module appended to
the Short Message Service, Mobile
Originated
SMS_BILLING
See Table 3 for more information.
OFCVAR Switches SMS record generation on/
off.
If on, the IN information module is
appended to the SMS MO record for
IN SMS services based on CS-1R
INAP, not the UMTS CAMEL
standard.
Terminated
MTSMS_BILLING_RECORD_ THROTTLE OFCVAR Switches the production of SMS-MT
records containing information for
unsuccessful SMSs on/off.
If on, SMS-MT records for
unsuccessful SMSs are not generated.
In this case, the MSC does not
generate SMS-MT records if the
Delivery Timestamp field (B5.2.49
on page 157) contains a default value,
or the SMS Result field (B5.2.183 on
page 231) contains a non-default
value.
CAMEL SMS information module
appended to the Short Message
Service, Mobile Originated record
SMS_IN_BILLING
See Table 3 for more information
OFCVAR Switches module generation on/off
for CAMEL Phase 3 SMS
provisioned using SMS-CSI
(CAMEL subscription information).
Location Update record for the
CAMEL Phase 3 mobility
management service.
This record is produced for CAMEL
subscribers provisioned with M-CSI
(Mobility Management CAMEL
Subscription Information) who trigger
the CAMEL mobility management
service.
MCSI_BILLING OFCVAR Switches the production of the
Location Update record on/off for
subscribers provisioned with
CAMEL M-CSI who trigger the
CAMEL mobility management
service.
If set to Y, the record is produced, but
if set to N, the record is not produced.
The UMTS MSC CAMEL P3 SOC
must also be switched on.
Supplementary Service Action GSM_CISS_BILLING OFCVAR Switches record generation on/off.
If it is on, table GCISSCDR
determines which CISS records are
produced.
Common Equipment Usage ENABLE_CEU_RECORD OFCVAR Switches record generation on/off.
Mobile originated and terminated
Incoming intra-PLMN trunk record
Outgoing intra-PLMN trunk record
Roaming
Common Equipment Usage
UNANSWERED_CALLS_CDR_ON OFCVAR Determines whether or not the
records are generated for unanswered
calls.
Roaming ENABLE_ROAMING_RECORD OFCVAR Switches record generation on/off.
Transit
CONN, DIR, TRKGRPS and CDRREQ fields RTEGRP These fields determine the trunks and
trunk groups for which billing
records are generated.
Partial billing information: the partial
information module is appended to
billing records
GSM_PB_REC_GEN_ENABLED
GSM_PB_INTERVAL
GSM_CDR_MAX_SIZE
OFCVAR
OFCENG
OCFVAR
GSM_PB_REC_GEN_ENABLED
switches partial billing records on/
off.
If it is on, the frequency at which
partial information is generated and
other factors such are record size
limits etc. are then set using the other
office parameters.
Generic Address information module
appended to incoming trunk records
GSM_MSISDN_IN_IC_TRK_RECORD See
Table 4 for information on how this may be
overridden by the GSM Generic Address Info
SOC option.
OFCVAR Switches on/off the generation of the
module.
Original calling number is captured in
the calling number field of the call
records generated for the forwarded
call leg.
USE_ORIGINAL_CGPN_FOR_BILLING
See Table 4 for information on how this may
be overridden by the GSM Generic Address
Info SOC option.
OFCVAR If on, the original calling number not
the redirecting number is captured for
billing purposes.
the calling number field of the
incoming trunk records when the
redirecting and original called
numbers are not available.
USE_OCGN_IN_CDR_IF_NO_RDGN_OCN
This office parameter is overridden if the SOC
Generic Address Info (Table 4) is set idle and
the office parameter USE_ORIGINAL_
CGPN_FOR_BILLING is set to Y. With these
settings, the calling number field always
contains the original calling number regardless
of the setting of this office parameter and
whether or not the redirecting number is
present.
OFCVAR If on, the original calling number is
captured for the redirected call if the
redirecting and original called
number are not available in the call
set up signalling.
the calling number field of the mobile
originated call record in IN DP3-
triggered (Intelligent Network
Detection Point 3) redirection
scenarios.
orig_CgPN_in_DP3_MO_CDR
Operators who want the original calling
number to be captured only for DP3-triggered
redirection scenarios should set this office
parameter on and set the existing parameter
USE_OR IGINAL_CGPN_ FOR_BILLING
off.
OFCVAR If on (set to Y), the original calling
number is captured. If off (set to N),
the redirecting number is captured.
In all other call scenarios, the setting
of the SOC option GSM Generic
Address Info and the office parameter
USE_OR IGINAL_
CGPN_FOR_BILLING determine
whether the original calling number
or the redirecting number is captured.
Use the redirecting number for calling
line identification presentation
(CLIP).
USE_RDGN_FOR_CLIP OFCVAR In certain cases, especially for calls
with a number of legs, the calling
number might be lost. If this
parameter is on, the redirecting
number is used instead.
Determines whether or not billing
information is generated for handover
and if so, what handover information
is captured in the billing records.
HO_PERFORMED_PROCESSING
Note that the LIU_PROCESSING parameter
applies to a particular configuration of the
MSC. This is where the MSC uses Link
Interface Units (LIU7s) to terminate the A
interface signalling from the Base Station
Controller.
OFCVAR The LIU_PROCESSING parameter
determines whether intra-BSC
messaging is processed. If set to
PASS_THRU_LIU the BSC sends
the intra-BSC handover messaging to
the MSC. If set to
CONSUME_IN_LIU the BSC does
not send this messaging. It only sends
the MSC information about inter-
BSC handover
The BILLING parameter determines
whether or not billing information is
generated for handover. If the
parameter is set to BILLING_ON the
MSC generates billing information
and if set to BILLING_ OFF it does
not.
If LIU_PROCESSING is set to
PASS_THRU_LIU the MSC
generates billing information for
intra-BSC handover. If a handed-to
MSC also has this parameter set the
same way, it sends any intra-BSC
handover and inter-BSC messaging
to the anchor MSC which captures it
in the handover billing records.
The INTER_MSC_PROCESSING
parameter determines whether or not
the handed-to MSC sends
information about intra-MSC
handover to the anchor MSC. If set to
SEND_FROM_MSCB, the handed-
to MSC does send the information to
the anchor MSC and if set to
NO_SEND_FROM_ MSCB it does
not. If set to NO_ SEND_FROM_
MSCB, the billing records generated
on the anchor MSC capture
information about the initial inter-
MSC handover, but no information
on any subsequent intra-MSC
handovers on the handed-to MSC.
Note: if MAP Phase 1 is used on the
E interface between two MSCs, the
generation of this handover data is
controlled by NOTE_
INTERNAL_HANDOVER_
SUPPORTED in Table OFCENG.
Location and channel information
modules capturing handover
information.
GSM_SAVE_ALL_LOC_CH OFCVAR If set to yes all of the location updates
are captured in separate modules. If
set to no, only the initial location and,
if applicable, final location are
captured into separate modules.
The amount of inter-MSC and intra-
MSC information captured is also
dependent on the setting of the
HO_PERFORMED_ PROCESSING
office parameter listed above.
Incoming gateway call attempt or
generated on the handed-to MSC after
an inter-MSC handover.
This is in addition to the handover
records on the anchor MSC.
GEN_HO_IMT_TRK_BILLING OFCVAR If set to yes, the incoming trunk
record is generated on the handed-to
MSC. The record is not generated if
the office parameters is set to no.
Capturing of location information in a
UMTS network during call setup or
relocation.
LOC_RPT_CNTRL_FOR_SAI OFCVAR This parameter determines the
contents of the Location Reporting
Control (LRC) message which the
MSC sends to the RNC to request
location information in the form of
the Service Area Identifier (SAI).
If set to direct, the MSC does not
send the LRC during initial call
setup, but during relocation it sends
an LRC with the request type set to
direct after the Relocation Complete
message.
If set to chg_of_service_area, the
MSC sends the LRC with the request
type change of service area after
the initial UE message and during
relocation, it sends the LRC after the
Relocation Request Ack message.
Generation of billing LCS billing
information for emergency calls
LCS_BILLING_IN_EMER_CALLS OFCVAR If set to yes, the LCS record is
generated for emergency calls.
Generation of Release 4 or Release 99
LCS information
LCS_RELEASE LCSDATA If set to R4, Release 4 LCS
information is generated. If set to
R99, Release 99 LCS information is
generated.
Wireless Priority Service information
captured in an SS information module
ENABLE_WPS_CALL_INDICATOR_IN_C
DR
OFCVAR If set to yes, the WPS billing
information is generated for WPS
calls originated on the MSC. The
WPS FOC SOC must also be
switched on.
Location of subscriber provided
during an emergency call in North
America using the Time Difference of
Arrival Intelligent Network
Application Part feature (E911 TDOA
INAP).
IN_DP3_E911_CALL OFCVAR If set to yes, the MSC queries the
Service Control Point for routing
information to the emergency call
centre.
Enhanced Multi-Level Precedence
and Pre-emption service (eMLPP)
The eMLPP service is switched on
using the SOC option eMLPP SOC.
In Table 4 refer to GSM eMLPP on
page 58.
EMLPP_DEFAULT_PRECEDENCE OFCVAR Sets the default precedence level of
the network. The default value is 4.
PUBLIC_EMERGENCY_CALL_PRIORITY OFCVAR Sets the priority of all mobile-
originated Public Emergency calls.
The default value is 2.
HIGH_PRIORITY_CALL OFCVAR Sets the priority for Emergency Type
1 and Type 2 calls. A call with
priority greater than or equal to this
office parm cannot be pre-empted.
The default value is 0.
MLPP_SERVICE_DOMAIN OFCVAR Sets the default MLPP Service
Domain value in the outgoing ISUP
IAM. The default value is 000000.
MLPP_PBX_FULL_SUPPORT OFCVAR Sets PBX support. When set to Y,
this office parameter indicates that all
the PBXs in the network support the
MPP service. The default value is
N.
GHLRSSOP A user registers for eMLPP service
through this table. It also contains the
maximum priority and default
priority assigned to a subscriber.
SERVCNFG Provides information about pre-
emption capability (through Pre-
emption Capability Indicator or PCI
field) and Call Setup Class when a
call of a certain priority is being
established. This table is datafilled
for all priority levels (A,B,0 to 4).
MSC-HLR based Ring Back Tone
(RBT) service.
The RBT service is switched on using
the SOC option MSC-HLR RBT
service. In Table 4 refer to MSC-
HLR based Ring Back Tone on
page 58.
MSCHLR_Ring_Back_Tone_Option OFCVAR This office parameter contains four
fields which determine how the
service operates:
IP_No_Reply_Timer defines the
maximum establishing time for the
connection between the MSC/GMSC
and the External Intelligent
Peripheral (IP).
External_IP_Address contains the
address of the IP.
PLAY_CF_FTN_RBT determines
whether or not RBT is supported
during call forwarding.
RBT_Indicator_In_SRI determines
whether or not the GMSC sends the
RBT indicator to the HLR in the SRI
message. The HLR can still return the
RBT SS code even if the GMSC does
not send the indicator.
NOTE The two office parameters in this table are completely independent of each other.
B3.8.2 Software Optionality Control (SOC)
Determines whether the called partys
IMSI is captured in the Mobile
Number Portability (MNP)
information module.
MNP_CDPN_IMSI_IN_MO_ICG_CDR OFCVAR If set to Yes, the called party IMSI is
captured in the MNP information
module appended to a mobile
originated or incoming gateway
record if the MSC has sent an MNP
query to the MNP database. If set to
No, the called party IMSI is not
captured in the MNP module.
Combination In Table OFCVAR Result
SMS_BILLING SMS_IN_BILLING SMS Billing Records CAMEL SMS module
N
o
r
m
a
l
S
M
S
-
C
a
l
l
s
Y Y Yes N-A
Y N Yes N-A
N Y No N-A
N N No N-A
C
A
M
E
L

P
h
a
s
e

3
S
M
S
-
C
S
I

C
a
l
l
sY Y Yes Yes
Y N No No
N Y Yes Yes
N N No No
Table 3 Effect of SMS_BILLING and SMS_IN_BILLING
Information SOC Option Function
MSRN (Mobile Subscriber Routing
Number) is captured in the location and
channel information module appended to
the mobile originated call attempt record.
CAMEL_DP12_MSRN_BILL This SOC controls the information captured
when a mobile subscriber calls another
subscriber who subscribes to a CAMEL Phase 2
terminating IN service (triggered at detection
point DP12). If the SOC is switched on, the
MSRN is captured as described in the
information column.
CAMEL Phase 3 UMTS MSC CAMEL P3
Dependent on SOC options CAMEL
P2 DP2 & DP12 and CS-1R DP3
If switched on, the SOC allows the generation of
information for CAMEL Phase 3 services.
Table 4 SOC options controlling the generation of billing information
Generic address information module
appended to the mobile originated and
terminated record, all trunk records and the
roaming record
GSM Generic Address Info If this option is on, it overrides the settings of
the GSM_MSISDN_IN_IC_TRK_RECORD
and USE_ORIGINAL_CGPN_FOR_BILLING
office parameters described in Table 2.
If on, the SOC option appends the generic
address information module to all of the call
records listed here. It also ensures that the
redirecting number is captured in the calling
number field of the call records produced for the
forwarded call leg(s).
Wireless Priority Service (WPS)
information is captured in Supplementary
Service information modules.
WPS FOC SOC If this option is on, the MSC can support WPS
calls to allow priority access to the network to
US security officials.
Equal Access GSM WT EQUAL ACCESS This SOC option switches on/off the Equal
Access capabilities which allow users to select
Inter-Exchange Carriers (IXCs) for making long
distance calls.
Equal Access billing information is
captured in an Equal Access information
module appended to the Mobile Originated
Call Attempt record generated for the
Equal Access call.
GSM WT EA BILLING SOC This SOC option switches on/off the production
of billing information for the Equal Access
service.
China CAMEL Phase 2 China CAMEL Phase 2 SOC This SOC option switches on/off CAMEL Phase
2 services in the Chinese market, including the
production of billing information.
H.324 multimedia telephony services UMTS MSC 64K UDI 3G H324M This SOC option switches on/off the provision
of H.3234 multimedia services.
Location Services (LCS) LCS MO LOC Request
LCS MT Loc Request
LCS NI Loc Request
These SOC options switch on/off the LCS
capabilities of the MSC:
LCS MO LOC Request switches on/off mobile
originated location request capabilities
LCS MT Loc Request switches on/off mobile
terminated location request capabilities
LCS NI Loc Request switches on/off network
induced location request capabilities
The Location and Channel information
module is appended to the Mobile
Terminated Call Forwarding Attempt
record for the originally called party during
call forwarding on network determined
user busy (CF NDUB).
GSM CF NDUB Bill Rec This SOC option switches on/off the appending
of the Location and Channel information
module to the Mobile Terminated Call attempt
record during CF NDUB.
Determines the number formats for MNP
(mobile number portability) calls subject to
call forwarding. The forwarding MSC
strips the MNP routing code (MNP RC)
from the original called number (OCDN)
and redirecting number (REDN)
parameters of the ISUP IAM message sent
to the FTN (Forwarded To Number)
network.
GSM MNP RC STRIPPING This SOC option switches on/off the stripping of
the RC from the OCDN/REDN parameters of
the ISUP IAM message sent to FTN (Forwarded
To Number) network by the forwarding MSC.
If the SOC is on, the Calling Number fields in
the billing records for the forwarded call leg do
not contain the RC.
B3.8.3 Office Alarms for Billing
The operator can set the CHKBIL office alarm to provide a warning when billing systems memory
- provided by CRSPOOLs - is running low. The office parameter CRSPOOL_ALARM_IN_APPL
in table OFCVAR turns the CHKBIL alarm on/off.
Major and critical thresholds for CRSPOOLs are datafilled in the office parameters
CRS_ALARM_MAJOR_THRESHOLD and CRS_ALARM_CRITICAL_ THRESHOLD
respectively in table OFCENG. If CHKBIL is on, it raises a major or critical alarm when one or
more CRSPOOLs reach the major or critical thresholds defined in table OFCENG. The alarm
CHKBIL is cleared when usage of all the CRSPOOLs goes below the threshold.
The timestamp fields in mobile related call
records can contain a timezone offset value.
Multiple Time Zone Billing This SOC option switches on/off the production
of mobile related call records which capture
information about the different timezones in
which the MSC and handset are located.
The tariff system is set to produce
information for the Advice of Charge for
Multiple Rate Plan capabilities of the tariff
system.
AOC Multiple Rate Plan This SOC option switches on/off Aoc for MRP
in the tariff system.
If the SOC is on, the full AoC MRP capabilities
are available. If the SOC is set to idle, none of
the capabilities are available except for the new
table TARAOC2.
Enhanced Multi-Level Precedence and Pre-
emption service (eMLPP)
GSM eMLPP This SOC option switches on/off the eMLPP
service. If the SOC is on, the eMLPP
capabilities are controlled by table datafill (in
Table 2, see the entry Enhanced Multi-Level
Precedence and Pre-emption service (eMLPP)
on page 55).
MSC-HLR based Ring Back Tone MSC-HLR RBT service This SOC option switches on/off the ring back
tone service. If the SOC is on, the operation of
the service is controlled by table datafill (in
Table 2, see the entry MSC-HLR based Ring
Back Tone (RBT) service. on page 55).
Handling of an invalid IMEI/IMEISV GSM Invalid IMEISV This SOC option determines how the MSC
handles an invalid International Mobile
Subscriber Identity (IMSI) or IMEI Software
Version (IMEISV). If the SOC option is on, the
MSC stores the invalid IMEI/IMEISV and
continues with the current process. If the SOC is
idle, the MSC discards the invalid information
and handles the call dependent on the current
scenario, e.g. ciphering or providing identity
information.
B4 Structured Records and Modules
This section describes the structured records and the modules produced by the MSC to capture
billing information. Section B4.1 describes the contents of the structured records and Section B4.2
describes the contents of the billing modules. Section B4.3 describes market-specific modules.
B4.1 Structured Record Contents
The information for each structured record is given in a table which contains the name of the field,
a key indicating whether or not the field is mandatory and a reference to a detailed description
section. The key field has the following meaning:
M This field is mandatory and always present. Any exceptions to this rule are explicitly
described.
C This field is only available under certain conditions. If available the field is present.
The conditions under which the field is available are individually described.
X This field is not supported. In the context of this specification, not supported means
that while the field will be present in the billing or accounting record produced it will
only be populated with a default value.
This section contains information on the following records:
Type of Record Record
Rel
a
a. This column shows the product releases in which each record was added to the billing capabilities.
Structure
Code
Call Type
Code
Call/service
related records
Section B4.1.1, Mobile Originated Call Attempt on page 60 02 0002 001
Section B4.1.2, Mobile Terminated Call Attempt on page 61 02 0003 002
Section B4.1.3, Roaming Call Attempt on page 62 03 0018 014
Section B4.1.4, Incoming Gateway Call Attempt on page 63 03 0013 011
Section B4.1.5, Outgoing Gateway Call Attempt on page 64 03 0014 012
Section B4.1.6, Transit Call Attempt on page 65 03 0017 012
Section B4.1.7, Short Message Service, Mobile Originated on page 66 05 0004 005
Section B4.1.8, Short Message Service, Mobile Terminated on page 67 05 0005 006
Section B4.1.9, Incoming Intra-PLMN Trunk Record on page 68 03 0015 011
Section B4.1.10, Outgoing Intra-PLMN Trunk Record on page 69 03 0016 012
Section B4.1.11, Common Equipment Usage Record on page 70 04 0019 015
Section B4.1.12, Supplementary Service Action Record on page 71 09 0006 004
Section B4.1.13, Location Services (LCS) Record on page 73 15 0021 017
Section B4.1.14, Acknowledgement Record on page 74 GSMR02 0020 016
Section B4.1.15, Location Update Record on page 75 17 0001 003
Switch records Section B4.1.16, Time Change Record on page 76 02 0009 008
Section B4.1.17, Switch Restart Record on page 76 02 0010 009
Billing file
structure records
Section B4.1.18, Billing Block Header Record on page 77 02 0011 010
Section B4.1.19, Billing File Transfer In Record on page 77 02 0007 007
Section B4.1.20, Billing File Transfer Out Record on page 78 02 0008 007
B4.1.1 Mobile Originated Call Attempt
The MSC shall generate a mobile originated call attempt record for each outgoing call attempt made
by the mobile station. These MOC records shall be produced in the originating MSC.
In a call forwarding scenario where party A calls party B who forwards the call to party C, the MSC
uses this record to capture the details for the forwarded call leg from party B to party C. In this case
the record is called the Mobile Originated Call Forward Attempt record. The Call Forward Indicator
is set to 1C and the appended Supplementary Service (SS) Information Module (B4.2.4 on page 83)
captures details of the call forwarding SS.
Data Field Reference Size (characters)
Record Header M B5.2.157 18
Study Indicator M B5.2.189 2
Call forward Indicator C B5.2.16 2
Calling Party C B5.2.27 30
Calling Number C B5.2.26 30
Called Number C B5.2.22 40
Calling Equipment C B5.2.25 22
Additional Information M B5.2.3 4
Channel Allocation Time C B5.2.32 16
Answer Time C B5.2.6 16
Disconnect Time C B5.2.54 16
Release Time C B5.2.164 16
Off Air Call Setup X B5.2.125 2
Half Rate in Use C B5.2.71 2
Cause for Termination M B5.2.30 4
Call Reference M B5.2.18 8
MS Classmark C B5.2.112 16
Classmark Time Stamp C B5.2.37 16
Dialled Digits C B5.2.53 34
Outgoing Trunk Group C B5.2.135 6
Outgoing Trunk Member C B5.2.136 6
Outgoing Route Group C B5.2.80 4
Trunk Seizure (Outgoing) C B5.2.82 16
Calling Subscriber Category C B5.2.28 4
Call Indicator C B5.2.17 8
Call Duration M B5.2.15 14
Diagnostic C B5.2.52 6
MSC Number M B5.2.115 28
Record Number M B5.2.158 12
Total Size 398
Table 5 Mobile originated call attempt structured record
Structure 0002 Call Type 001 Codes
B4.1.2 Mobile Terminated Call Attempt
The MSC shall generate a mobile terminated call attempt record for each incoming call attempt
made for a mobile station. These MTC records shall be produced in the terminating MSC.
In a call forwarding scenario where party A calls party B who forwards the call to party C, the MSC
uses this record to capture the details for the original call leg from party A to party B. In this case
the record is called the Mobile Terminated Call Forward Attempt record. The Call Forward
Indicator is set to 1C and the appended Supplementary Service (SS) Information Module (B4.2.4 on
page 83) captures details of the call forwarding SS.
Field Reference Size (characters)
Call forward Indicator C B5.2.16 2
Called Party M B5.2.23 30
Called Equipment C B5.2.20 22
Additional Information M B5.2.3 4
Channel Allocation Time C B5.2.32 16
Release Time C B5.2.164 16
Off Air Call Setup X B5.2.125 2
Half Rate in Use C B5.2.71 2
Classmark Time Stamp C B5.2.37 16
Incoming Trunk Group C B5.2.83 6
Incoming Trunk Member C B5.2.84 6
Incoming Route Group C B5.2.80 4
Trunk Seizure (Incoming) C B5.2.82 16
Called Subscriber Category C B5.2.24 4
Total Size 364
Table 6 Mobile terminated call attempt structured record
B4.1.3 Roaming Call Attempt
For a mobile terminated call, the gateway MSC (GMSC) may generate a roaming record. As part of
terminating call handling, the GMSC queries the HLR for routing information to complete the call
to the called party. If the call is routed out of the GMSC, it creates a roaming record.
NOTE On the MSC provisioning through datafill determines whether or not this record
is produced. Please see Section B3.8 on page 49.
Roaming Number M B5.2.169 30
Outgoing Trunk Group M B5.2.135 6
Outgoing Trunk Member M B5.2.136 6
Trunk Seizure (Incoming) C B5.2.82 16
Trunk Seizure (Outgoing) C B5.2.82 16
Trunk Release (Outgoing) C B5.2.81 16
Logical Network C B5.2.105 4
Metering Zone C B5.2.107 4
Total Size 334
Table 7 Roaming call attempt structured record
B4.1.4 Incoming Gateway Call Attempt
The MSC shall allow the generation of an incoming gateway record for each incoming call attempt
received by a gateway MSC from another network. These records, produced in the gateway MSC,
may be used to settle accounts with other networks. The generation of gateway records shall not be
influenced by the production of MTC records i.e. even if the gateway MSC and terminating MSC
are collocated a gateway record shall still be produced.
NOTE On the MSC provisioning through datafill determines the trunks for which this
record will be produced. If required the production of this record may be
disabled. Please see Section B3.8 on page 49.
Called Number M B5.2.22 40
Incoming Trunk Group M B5.2.83 6
Incoming Trunk Member M B5.2.84 6
Trunk Seizure (Incoming) M B5.2.82 16
Trunk Release (Incoming) C B5.2.81 16
Incoming Metering Class C B5.2.79 4
Total Size 254
Table 8 Incoming gateway call attempt structured record
B4.1.5 Outgoing Gateway Call Attempt
The MSC shall allow the generation of an outgoing gateway record for each outgoing call attempt
from a gateway MSC to another network. These records, produced in the gateway MSC may be
used to settle accounts with other networks. The generation of gateway records shall not be
influenced by the production of MOC records i.e. even if the gateway MSC and originating MSC
are co-located a gateway record shall still be produced.
Trunk Seizure (Outgoing) M B5.2.82 16
Outgoing Metering Class C B5.2.79 4
Total Size 254
Table 9 Outgoing gateway call attempt structured record
B4.1.6 Transit Call Attempt
The MSC shall allow the generation of a transit record for each outgoing call from a MSC. The
MSC allows the production of transit records at any type of MSC i.e. an originating, terminating or
transit MSC.
Release Time (Outgoing) C B5.2.81 16
Total Size 254
Table 10 Transit call attempt structured record
B4.1.7 Short Message Service, Mobile Originated
The MSC shall allow the generation of an SMS mobile originated record for each mobile originated
short message sent by a mobile subscriber. The record can be generated for the mobile originated
SMS supplementary service and also for CAMEL (UMTS intelligent networking) SMS.
NOTE On the MSC provisioning allows the enabling and disabling of this record. If
required the production of this record may be disabled. Please see Section B3.8
on page 49.
Calling Party M B5.2.27 30
Calling Number M B5.2.26 30
Calling Equipment C B5.2.25 22
Service Centre M B5.2.179 28
SMS Timestamp M B5.2.186 16
Delivery Timestamp C B5.2.49 16
Call Reference C B5.2.18 8
Cause for Termination C B5.2.30 4
Message Reference M B5.2.106 6
MS Classmark M B5.2.112 16
SMS Result C B5.2.183 6
SMS Message Type M B5.2.181 2
SMS Validity Period C B5.2.187 18
Total Size 302
Table 11 SMS mobile originated record
B4.1.8 Short Message Service, Mobile Terminated
The MSC shall allow the generation of an SMS mobile terminated record for each mobile
terminated short message sent to a mobile subscriber.
NOTE On the MSC provisioning allows the enabling and disabling of this record. If
required the production of this record may be disabled. Please see Section B3.8
on page 49.
Calling Number M B5.2.26 30
Called Equipment C B5.2.20 22
Service Centre M B5.2.179 28
SMS Timestamp M B5.2.186 16
Delivery Timestamp C B5.2.49 16
Cause for Termination C B5.2.30 4
SMS Result X B5.2.183 6
Total Size 276
Table 12 SMS mobile terminated record
B4.1.9 Incoming Intra-PLMN Trunk Record
The MSC shall allow the generation of an incoming intra-PLMN trunk record for each incoming
trunk call attempt received by a MSC from another operator within the same network. These
records, produced in the MSC, may be used to settle accounts with other operators within a
network. The generation of incoming intra-PLMN trunk records shall not be influenced by the
production of MTC records i.e. even if the MSC is also the terminating MSC an incoming intra-
PLMN trunk shall still be produced.
Field Reference Size
Trunk Seizure (Incoming) M B5.2.82 16
Trunk Release (Incoming) C B5.2.81 16
Incoming Metering Class C B5.2.79 4
Total Size 254
Table 13 Incoming intra-PLMN trunk structured record
B4.1.10 Outgoing Intra-PLMN Trunk Record
The MSC shall allow the generation of an outgoing intra-PLMN trunk record for each outgoing
trunk call attempt made by a MSC to another operator within the same network. These records,
produced in the MSC, may be used to settle accounts with other operators within the same network.
The generation of outgoing intra-PLMN trunk records shall not be influenced by the production of
MOC records i.e. even if the MSC is also the originating MSC an outgoing intra-PLMN record shall
still be produced.
Total Size 254
Table 14 Outgoing intra-PLMN trunk structured record
B4.1.11 Common Equipment Usage Record
Conference circuits can be provided on a 3GPP Release 99 or earlier MSC, or on a 3GPP Release 4
Media Gateway (MGW) in a Bearer Independent Core Network (BICN). The MSC or MGW
generates a Common Equipment Usage Record each time a three-port conference-circuit or a six-
port conference-circuit used in the multi-party service is released. The record captures the identity
of the mobile subscriber using the circuit and the total duration of the usage of the circuit. The
Seizure time captures the time at which the conference circuit is seized and the Release time
captures the time at which the conference circuit is released. More than one common equipment
usage record may be generated for the duration of a single basic call. The Equipment Identity field
shows whether the circuit was provided by an MSC or MGW and the MSC/MGW field captures the
number of the MSC or MGW.
NOTE 1 On the MSC provisioning through datafill determines whether or not this record
is produced. Please see Section B3.8 on page 49.
NOTE 2 If the conference circuits are provided on the MSC, the Equipment Identity field
identifies this with the value 00001C and the MSC/MGW Number field contains
the E.164 number of the MSC. If the conference circuits are provided on a
conference-enabled MGW, the Equipment Identity field shows this with the
value 00002C and the MSC/MGW Number field contains the number of the
MGW.
Equipment Identity C B5.2.58 6
Equipment Type M B5.2.59 6
Served Party M B5.2.27 30
Served Number M B5.2.26 30
MSC/MGW Number M B5.2.116 28
Date and Time (Seizure) M B5.2.46 16
Date and Time (Release) M B5.2.46 16
Total Size 186
Table 15 Common equipment usage structured record
B4.1.12 Supplementary Service Action Record
The MSC shall generate a Supplementary Service (SS) action record to capture information about a
call independent supplementary service (CISS) action invoked by a mobile subscriber. A subscriber
uses CISS actions to change SS details, for example to provide a forwarding number for use in a
call forwarding service. The SS action record captures information about the subscriber and the
service details being changed or updated. The hot billing indicator field shows whether or not the
subscriber is provisioned with hot billing.
The SS action record may have basic service information appended to it in the form of either a
bearer service information module or a teleservices information module. This depends on the
information signalled by the mobile handset during the CISS operation. If the MSC receives bearer
or teleservice information from the handset, this implies that the CISS operation applies to the
signalled service, and not to both types of service. In this case, the MSC captures the service
information in a bearer or teleservice information module appended to the SS action record. If the
handset does not signal any basic service information, this implies that the operation applies to all
teleservices and all bearer services (e.g. to all basic services). In this case, the MSC does not append
an information module to the record.
The MSC also uses the record to capture information about Unstructured Supplementary Service
Data (USSD) services.
Served Party M B5.2.27 30
Served Number C B5.2.26 30
Served Equipment C B5.2.25 22
Call Reference C B5.2.18 8
Supplementary Service Code C B5.2.192 4
Supplementary Service Action C B5.2.191 2
Date and Time M B5.2.46 16
Supplementary Service Parameters C B5.2.193 32
Result Indicator C B5.2.167 4
Location Area Code C B5.2.104 12
Cell-SAC Id C B5.2.31 6
Access Network M B5.2.2 2
Hot Billing Indicator M B5.2.73 2
Total Size 246
Table 16 Supplementary service action structured record
NOTE On the MSC, provisioning allows the enabling and disabling of this record (Please see
Section B3.8 on page 49). If required the production of this record may be disabled. If
record production is enabled, further provisioning in table GCISSCDR defines the particular
services and CISS actions for which records are generated.
An entry of means that the setting can be changed to Y to produce a record for the SS/SS
action and N to turn record generation off. An entry of means that the setting cannot be
changed as there is no action defined in the GSM/UMTS standards.
Service Activate/Register Deactivate/Erase Interrogate Invoke
Calling Line Identification Presentation (CLIP)
Calling Line Identification Restriction (CLIR)
Connected Line Identification Presentation (COLP)
Connected Line Identification Restriction (COLR)
Call Forwarding Unconditional (CFU)
Call Forwarding Busy (CFB)
Call Forwarding on MS Not Reachable (CFNRc)
Call Forwarding on No Reply (CFNRy)
Call Waiting (CW)
Barring of All Outgoing Calls (BAOC)
Barring of All Outgoing International Calls (BOIC)
BOIC except to Home-PLMN Country (BOIC_EXHC)
Barring of All Incoming Calls (BAIC)
Barring of Incoming Calls when roaming outside of HPLMN Country (BIC_ROAM)
Unstructured Supplementary Service Data (USSD)
Table 17 Table GCISSCDR
B4.1.13 Location Services (LCS) Record
The MSC shall generate a record to capture details for location services. LCS information is used to
provide information about the subscribers location to the emergency services. Operators can also
use the information to provide new value added services (VASs) and for operations and
maintenance functions. The record captures details for Mobile Originated Location Request (MO-
LR), Mobile Terminated Location Request (MT-LR) and Network Initiated Location Request (NI-
LR) services.
Field MO-LR MT-LR NI-LR Reference Size (characters)
Record Header M M M B5.2.157 18
Study Indicator M M M B5.2.189 2
LCS Record Type M M M B5.2.100 2
Served Party M M C B5.2.178 16
LCS Client Type X M C B5.2.96 4
LCS Client Id C C C B5.2.95 32
LCS Initiation Time M M M B5.2.98 16
LCS Termination Time M M M B5.2.102 16
Geographical Location of Target UE 1 C M M B5.2.65 42
Geographical Location of Target UE 2 C C C B5.2.66 42
Age of Location X C C B5.2.5 6
Requested Quality of Service (QoS) C C C B5.2.165 12
LCS Result C C C B5.2.101 4
MSC Number M M M B5.2.115 28
Served MSISDN C C C B5.2.177 30
Requesting MLC C M C B5.2.166 26
Privacy Notification X C C B5.2.152 2
Privacy Override X C C B5.2.153 2
Positioning Data C C C B5.2.144 28
LCS Diagnostic C C C B5.2.97 2
System Type C C C B5.2.194 2
Served IMEI X X C B5.2.175 22
Emergency Service Routing Digits (ESRD-Digits) X X C B5.2.56 16
Emergency Service Routing Key (ESRK-Key) X X C B5.2.57 12
LCS Priority Level X X C B5.2.99 4
Record Number M M M B5.2.158 12
Total Size 506
Table 18 Location Services (LCS) Record
B4.1.14 Acknowledgement Record
This record captures details about high priority group calls made in the GSM Railways (GSM-R)
network. These may be details for a high priority voice group call service (VGCS) call or a voice
broadcast service (VBS) call. After call release, the mobile stations involved in the group call make
a second acknowledgement (or confirmation) call to the integrated acknowledgement centre (IAC)
on the MSC. The IAC extracts the call information from user-to-user (UUS1) signalling and
captures the information in the acknowledgement record. If the hot billing stream is provisioned,
the record is directed to it. Operators use the record to analyse the high priority group call.
Record Time M B5.2.159 16
Priority Call Tag M B5.2.149 2
Group Call Reference M B5.2.70 10
Functional Number M B5.2.64 16
Priority Level M B5.2.150 4
Priority Call Cause M B5.2.147 4
Priority Call Duration M B5.2.148 10
Priority Release Time M B5.2.151 12
Hot Billing Indicator M B5.2.73 2
Total Size 206
Table 19 Acknowledgement Record
B4.1.15 Location Update Record
This record captures the location of a mobile subscriber as part of the CAMEL mobility
management service. For this service, the operator provisions the subscriber with Mobility
Management CAMEL subscription information (M-CSI). When the subscriber performs a location
update, or a mobile attachment / detachment, the MSC informs the Service Control Point (SCP) of
the event. This record is only generated for successful applications of the CAMEL mobility
management service: it is not a general purpose mobility management record.
NOTE The Location Update record does not capture the old and new location
information (fields Old MSC-Id to New Cell - SAC Id) for the MM events
mobile initiated detach and network initiated detach.
Additionally this record does not contain MS classmark information for the MM
event network initiated detach.
Served IMSI M B5.2.176 30
Served MSISDN C B5.2.177 30
Recording Entity M B5.2.160 28
Old MSC-Id C B5.2.131 28
Old LAC C B5.2.130 12
Old AN C B5.2.128 2
Old Cell - SAC Id C B5.2.129 6
New MSC-Id C B5.2.121 28
New LAC C B5.2.120 12
New AN C B5.2.118 2
New Cell - SAC Id C B5.2.119 6
Update Time M B5.2.206 16
Update Result C B5.2.205 4
MM Event C B5.2.110 4
Total Size 256
Table 20 Location Update Record
B4.1.16 Time Change Record
When there is a time change in the switch a time change record shall be produced. The record can
be used by the downstream processor for billing time adjustment. The time stamps in a given call
and event record are all consistent with the switch time when the call is disconnected. For example
if a call is set up at 1100hrs and a switch time change is performed at 1105hrs changing the time to
1005hrs. The call is then completed 10 minutes later at the new time of 1015hrs. The resulting call
and event records would show a start time of 1000hrs and an end time of 1015hrs. The time that is
stored as the start time is recorded as a relative value to the last restart of the switch and changing
the hardware clock does not affect those relative times.
B4.1.17 Switch Restart Record
When there is a warm or cold restart on the switch a switch restart record shall be produced.
Auxiliary Record Header M B5.2.7 24
Date and Time (Old) M B5.2.46 16
Date and Time (New) M B5.2.46 16
Total Size 86
Table 21 Time change structured record
Data Field Reference Size
Switch Restart Type M B5.2.195 2
Total Size 72
Table 22 Switch restart structured record
B4.1.18 Billing Block Header Record
On the MSC billing records are packed into 2 Kbyte blocks called data blocks before being written
into the physical device. The first record in each of these data blocks shall be a billing block header
record. This record contains the recording entity, a timestamp and the block number.
B4.1.19 Billing File Transfer In Record
A billing file transfer in record shall indicate the beginning of a MSC billing file. The billing file
transfer in record shall be present in the first data block of all MSC billing files. Contained within
this record is a file sequence number. This number identifies a particular MSC billing file.
Information about the MSC release is captured in the Release Id field in the Record Header. The
Release Id field replaces the Generic Identity field.
The population of the record number field in this record is optional. The office parameter
ENABLE_FILE_TRANSFER_RECORD_NUM in the table OFCVAR determines whether or not
the record number field is populated. It is recommended that this parameter is set to Y to populate
the record number field. However, some customers may use an intermediate device between the
MSC and the downstream processor which generates its own record number, or disregards the
record number in the file transfer record. In this case, these customers can set the office parameter
to N to switch off the population of the record number field on the MSC.
Block Number M B5.2.13 6
Total Size 64
Table 23 Billing block header structured record
File Transfer Type M B5.2.62 4
File Sequence Number M B5.2.61 4
Total Size 78
Table 24 Billing file transfer in structured record
B4.1.20 Billing File Transfer Out Record
A billing file transfer out record shall indicate the end of a MSC billing file. The billing file transfer
out record shall be present in the final data block of all MSC billing files except in the event of file
write failure (Section B2.1).
Information about the MSC release is captured in the Release Id field in the Record Header. The
Release Id field replaces the Generic Identity field.
The population of the record number field in this record is optional. The office parameter
ENABLE_FILE_TRANSFER_RECORD_NUM in the table OFCVAR determines whether or not
the record number field is populated. It is recommended that this parameter is set to Y to populate
the record number field. However, some customers may use an intermediate device between the
MSC and the downstream processor which generates its own record number, or disregards the
record number in the file transfer record. In this case, these customers can set the office parameter
to N to switch off the population of the record number field on the MSC.
File Transfer Type M B5.2.62 4
File Sequence Number M B5.2.61 4
Record Count M B5.2.156 10
Block Count M B5.2.12 6
Total Size 94
Table 25 Billing file transfer out structured record
B4.2 Module Contents
A module is an information structure which can be appended to the MSC Structured record. Each
module contains a set of data fields. The length of each data field is defined in terms of BCD or Hex
characters. The module is identified by a module code which appears as the first field in the module.
A complete list of all the modules supported by the MSC and a summary of the records to which
they may be appended is given in Table 26. The content and purpose of each of these modules are
described in the following sections.
Customer and market-specific billing modules are defined in Section B4.3 on page 110.
Call Detail Records and Structure Codes
M
o
b
.

O
r
i
g
.
a
a. In a call forwarding scenario, there is a Mobile Terminated Call Forwarding Attempt record for the termination
of the original call leg and a Mobile Originated Call Forwarding Attempt record for the origination of the for-
warded leg (as well as the other call records). These records have the call forwarding indicator field set to true to
show that they are forwarding records. The list of modules shown in this table is not guaranteed for these forward-
ing records.
M
o
b
.

T
e
r
m
.
a
R
o
a
m
i
n
g
I
/
C

G
a
t
e
O
/
G

G
a
t
e
T
r
a
n
s
i
t
S
M
S

M
O
S
M
S

M
T
I
/
C

i
n
t
r
a
O
/
G

I
n
t
r
a
C
E
U
S
S

A
c
t
i
o
n
L
C
S
A
c
k
Information Module
Attach
b
b. This column specifies how many times the module can be appended to a call record: 0-1 indicates that the mod-
ule is not appended, or that it is appended once; 0-n indicates that the module is either not appended, or can be
appended many times.
Rel
c
c. This column shows the product releases in which each module was added to the billing system.
Code Ref. 02 03 18 13 14 17 04 05 15 16 19 06 21 20
End of Module List 1 02 00 B4.2.1 on page 80 Y Y Y Y Y Y Y Y Y Y Y Y Y
Bearer Service 0-n 03 02 B4.2.2 on page 80 Y Y Y Y
Location and Channel 0-n 02 03 B4.2.3 on page 81 Y Y Y Y
Supplementary Services 0-n 02 05 B4.2.4 on page 83 Y Y
Y
d
d. The SS module is appended to trunk records when a dropback service is used or where the MSC forms a tem-
porary connection to a resource e.g. to play specialised tones during the provision of a service.
Y
d
Y
Y
e
e. The SS module is appended to the SMS MO record for call barring and to the SMS MO and SMS MT records
for hot billing.
Y
e
Y
d
Y
d
Teleservices 0-n 02 06 B4.2.5 on page 91 Y Y Y Y Y
AoC Parameter 0-n 03 07 B4.2.6 on page 92 Y Y
Tariff Class 0-n 03 08 B4.2.7 on page 93 Y Y
Data Service 0-1 04 09 B4.2.8 on page 93 Y Y Y Y Y Y Y
Other Agent 0-n 04 10 B4.2.9 on page 95 Y
Location Only 0-n 05 04 B4.2.10 on page 95 Y Y Y
Equal Access 0-n 05 12 B4.2.11 on page 96 Y Y Y Y Y Y Y Y
Partial 0-1 05 13 B4.2.12 on page 97 Y Y Y Y Y Y Y Y Y
Trunk usage 0-1 06 16 B4.2.13 on page 97 Y Y Y Y Y
IN Information 0-n 07 18 B4.2.14 on page 98 Y Y Y Y Y Y Y
IN Charging 0-n 07 19 B4.2.15 on page 101 Y Y Y Y
Generic Address 0-1 07 20 B4.2.16 on page 102 Y Y Y Y Y Y Y
Network Call Reference 0-1 10 22 B4.2.17 on page 103 Y Y
CAMEL Charging 0-n 11 23 B4.2.18 on page 104 Y Y Y
Mobile Number Portability 0-n 15 25 B4.2.19 on page 105 Y Y Y
GSM Assisting SSP 0-n 16 26 B4.2.20 on page 106 Y Y
CAMEL SMS 0-1 16 27 B4.2.21 on page 107 Y
Patching
f
f. The patching module is used by Nortel patch designers to provide additional capabilities to customers. Once the
patched information has been sourced into a standard MSC product release, the module is released and made
available for new patch development. As such this is a special module whose use will vary according to the
patches developed for different customers.
0-n 16 28 B4.2.22 on page 108 Y Y Y Y Y Y Y
Bearer Independent Core Network 0-n 18 29 B4.2.23 on page 109 Y Y Y Y Y Y
Table 26 Information modules
B4.2.1 End of Module List Module
This module shall indicate the end of a list of appended modules. There will be a maximum of one
of these modules in any record.
B4.2.2 Bearer Service Information Module
This module shall be used to record Bearer service information. This module is appended if the
Bearer capability information indicates a request for a circuit duplex asynchronous or a circuit
duplex synchronous data call (3.1kHz, Audio or UDI), an Alternate speech and circuit duplex
asynchronous (or circuit duplex synchronous) data call, or a Speech followed by circuit duplex
asynchronous (or circuit duplex synchronous) data call. When data resources are utilized at a MSC,
both bearer and data service modules (B4.2.8) shall be appended to those records that support both
modules. Together, the information contained may be used to derive the full bearer service
employed in the call. There may be zero or more of these modules in records that support it.
This module may be appended to the following MSC structured records:
Supplementary service (SS) action
If the module is appended to the SS action record, this means that the details captured in the record
apply to the bearer service indicated in the module, rather than to all bearer services.
Module Code M B5.2.111 4
Total Size 4
Table 27 End of module list module
Bearer Service M B5.2.11 4
Total Size 24
Table 28 Bearer service information module
00 Module Code
02 Module Code
B4.2.3 Location and Channel Information Module
This module shall be used to record the location and channel information about a call. The MSC
shall provide the option to capture a module for each new identifiable location in a call or only the
first and last locations. Further, with regards to the first option the MSC shall provide the option to
suppress the generation of this module for each intra-BSS handover that is performed during the
call. The trunk group and trunk member fields capture the local BSS trunk identity when the mobile
station is local to the MSC. In the event of an inter-MSC handover it shall be the inter-MSC trunk
information that will be captured in these fields. The Location area code and the Cell-SAC (Service
Area Code) Id fields unambiguously capture the location of the mobile station at the beginning and
end of the call. The Channel type field derives its value from the Connection Element, Radio
Channel Requirements, User Rate and Information transfer capability in the Bearer capability
information element.
NOTE 1 When an inter-MSC handover is performed the MSC Number captured in this
field will be that of the handed-to MSC.
NOTE 2 When there is more than one Location and Channel Information module in a
record it will be the original location that is recorded last.
(Continued)
Roaming Number M B5.2.169 30
MSC Number (Note) M B5.2.115 28
Location Area Code M B5.2.104 12
Cell-SAC Id M B5.2.31 6
Channel Type M B5.2.34 6
Channel Description M B5.2.33 10
RNC ID M B5.2.168 6
Total Size 132
Table 29 Location and channel information module
03 Module Code
NOTE 3 When there is more than one Location and Channel Information module in a
record, the location area code field in each module may contain different settings
for the Mobile Network Code (MNC). This is because the MSC supports
multiple combinations of MNC and Mobile Country Code (MCC) to identify
valid equipment in the network. However, the HLR supports multiple MNCs but
not multiple MCCs. This means that support is limited to multiple MNCs for all
practical purposes.
NOTE 4 The Incoming trunk group and the incoming trunk group member fields shall
capture the local BSS trunk identity if the mobile station is local to the MSC
however if the handover is to a different MSC then it will be the inter MSC trunk
information that is captured in these fields.
NOTE 5 The location area code field contains either a 2-digit or a 3-digit Mobile Network
Code (MNC). The World Trade wireless networks (all markets except North
America) use a 2-digit MNC. The North American wireless markets will need a
3-digit MNC (by July 1998, all North American networks must be able to
support 3-digit MNCs to comply to PCS specifications). The display of either 2
or 3 digits in the location area code field is provisioned using the office
parameter MNC in the table OFCVAR.
NOTE 6 The channel type field may capture information relating to the type of speech
coder used on the speech path.
NOTE 7 Only the following fields will be populated in the Mobile Terminated Call
Forward Attempt record generated in the NDUB (network determined user busy)
call forwarding scenario.
- Location Area Code
- Cell-SAC ID
- Date and Time
- Access Network
All other fields in the module will be defaulted.
NOTE 8 If the forwarding mobile (party B where party A calls party B who forwards to
party C) performs one or more handovers prior to call forwarding, the Location
Area Code and Cell-SAC ID will be populated with the current location of the
forwarding mobile at the time that forwarding occurs. If one or more handovers
occur after the forwarding has taken place, mobile B's new location(s) will not be
reflected in the Mobile Terminated Call Forwarding Attempt record for the
forwarded call leg.
B4.2.4 Supplementary Services Information Module
This module shall be used to capture supplementary service information relating to a particular call.
For example if call barring is activated this module shall be included to indicate this. The
Supplementary Service Code field captures the type of Supplementary service involved. The
Supplementary Service Action field indicates the invocation of the supplementary service. The
Supplementary Service Parameters field captures any parameters that may be associated with a
particular supplementary service, e.g. the call forwarding number. The result indicator field shall
capture an indication of the success of the supplementary service operation. There may be zero or
more of these modules in records that support it.
NOTE The supplementary services information module is only appended to the short
message service, mobile originated record for the barring of outgoing calls
service and the hot billing service. The module is only appended to the short
message service, mobile terminated record for the hot billing service.
The module may also be appended to the following trunk records:
Incoming gateway
Outgoing gateway
The module is appended to these trunk records when the MSC has optimised the call path after
connecting separate calls together to connect two parties. For example, in a call forwarding scenario
where A calls B who forwards to C, the MSC may have released the connections to B to optimise
the connection between A and C. The services for which information is captured are:
Voicemail call dropback
Call re-origination
Network optimisation for trombone connections on ANSI ISUP trunks
ETSI/ANSI PRI release link trunk (RLT) for connections to an off-board IN intelligent
peripheral
05 Module Code
Though the mechanisms that support these services are very different, they share the same common
characteristics. Firstly, the original called party or device signals new call information which may
include an indication that the MSC should attempt to optimise the connection. The MSC releases
the connections to the original called party or device and connects the original calling party with the
new called party.
The following tables provide some examples of how the SS information module fields may be
populated by some of the supported supplementary services. They are not reference tables and do
not cover all possible values which may be captured by the SS information module. The tables do
not include the following fields which, in most cases, contain similar information for all services:
Module code which is 005C
SS Action which is 5C (invoke)
Date and time which captures when the service was invoked
However, these fields are discussed if there are exceptions to these settings.
The information is contained in the following tables:
Table 31 Number identification services
Table 32 Call forwarding services
Table 33 Explicit call transfer service
Table 34 Call completion services
Table 35 Community of interest services
Table 36 Other features and services
Table 37 Enhanced Multi-Level Precedence and Pre-emption service (eMLPP)
Table 38 MSC-HLR based ring back tone service
SS Code M B5.2.192 4
SS Action M B5.2.191 2
SS Parameters C B5.2.193 32
Result Indicator M B5.2.167 4
Total Size 62
Table 30 Supplementary service information module
NOTE If a call is set up over a number of network boundaries, some call information
may be dropped. If the calling number is not available, no information will be
sent to a subscriber of the CLIP service. The office parameter USE_RDGN_
FOR_CLIP in table OFCVAR allows operators to use the redirecting number for
CLIP if the calling number is not available. In this case, the SS parameters field
contains the redirecting number and not the calling number.
Supplementary Services Information Module
Service SS Code SS Parameters (example) Result
Indic
Description
Calling Line
Identification Presentation
(CLIP)
011C FFFFFFFFFFFFFFFFFFFF43664209200C 001C CLI successfully displayed by called party.
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 005C Insufficient information to display CLI.
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 026C CLI not displayed due to calling partys CLI Restriction
FFFFFFFFFFFFFFFFFFFF43664209200C 027C Called party has CLIP provisioned with the override
category and so overrides CLIR to display the CLI.
Calling Line
Identification Restriction
012C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 001C Calling party successfully restricts the display of the CLI
by the called party who is provisioned with CLIP.
Connected Line
Identification Presentation
(COLP)
013C FFFFFFFFFFFFFFFFFFFF43664209200C 001C Connected number successfully displayed.
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 005C Insufficient information to display the connected number.
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 028C Connected number not displayed due to called partys
subscription to the display restriction service COLR
FFFFFFFFFFFFFFFFFFFF43664209200C 029C Calling party has COLP provisioned with the override
category. It overrides CLIR to show the connected
number.
Connected Line
Identification Restriction
(COLR)
014C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 001C Called partys COLR service prevents the display of the
connected number.
Proprietary Calling Name
Delivery (CNAM).
CNAM is a proprietary
implementation of the
3GPP Calling Name
Presentation (CNAP)
This is a mobile terminated service which allows the called party to display the name of the calling party (contained in an
incoming ISUP IAM message or resulting from a TCAP query to a line information database). The SS information module
is attached to the mobile terminated call attempt record. The result indicator shows whether the CNAM was delivered to the
called party, but the CNAM itself is not captured.
01FC FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 001C Successful delivery of CNAM to MS.
057C Unavailable indication sent to MS.
058C Private indication sent to MS.
Table 31 Number identification services
Indic
Description
Call Forwarding All
Conditional
028C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 037C This indicates that the type of call forwarding is not
known. The forwarded-to number is not captured
and the result indicator shows an error. It may result,
for example, from the maximum number of call
forwarding legs being exceeded.
Call Forwarding
Unconditional (CFU)
a
a. If MAP phase 1 signalling is used between the gateway MSC and the HLR, there is insufficient information to
distinguish between call forwarding unconditional (CFU) and call forwarding not reachable (with not regis-
tered). In both cases, the ss-code in the supplementary services information module is populated with 025C, call
forwarding in gateway (unknown).
MAP phase 2 signalling can distinguish between these types of call forwarding and the ss-code is populated with
either 021C for CFU, or 02BC for call forwarding not reachable (with not registered).
021C FFFFFFFFFFFFFFFFFFFF43664209200C
or
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
001C
or
037C
The type of call forwarding is indicated by the SS
code. For successful call forwarding, the forwarded-
to number is captured in the SS parameters field and
the result indicator of 001C shows success. For
unsuccessful forwarding, the SS Parameters field
contains the default value and the result indicator of
037C indicates a failure condition.
Call Forwarding in Gateway
(Unknown)
025C
Call Forwarding Busy (CFB) 029C
Call Forwarding on No
Reply (CFNRy)
02AC
Call Forwarding on MS Not
Reachable (CFNRc)
a
02BC
Table 32 Call forwarding services
Indic
Description
Explicit Call
Transfer
031C FFFFFFFFFFFFFFFFF61411002133146C
The number defaults to all Fs if the directory
number (of party B or party C) is not
provided in the call setup signalling.
001C A subscriber (MS A) with two calls - one in the held state to party B
and the other in the active or alerting state to party C - can invoke the
ECT feature to join/transfer the two calls. The subscriber (MS A)
invoking the ECT feature is disconnected from the newly formed
transferred call between party B and party C. Even though MS A is
removed from the call (between party B an party C) billing
information is maintained for MS A throughout the duration of the
call between party B and party C. The mobile originated/terminated
call records produced for MS A each have an appended SS
information module capturing ECT information. In the call record
for the call between A and B, the SS parameters field contains the
directory number of party C. In the record for the call between A and
C, the SS parameters field contains the directory number of party B.
Table 33 Explicit call transfer service
Indic
Description
Call Hold (CH) 042C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 021C Call held.
001C Call retrieved.
Proprietary Voice
Mail Call Drop
Back
044C FFFFFFFFFFFFFFFFFFFF43664209200C 001C Successful drop back from the voicemail system (VMS). The
SS parameters field contains the mailbox identifier supplied by
the VMS.
ETSI ISUP Call Re-
origination
045C FFFFFFFFFFFFFFFFFFFF0215780220C 001C The re-origination service allows the MSC to set up a second
call after the failure of a previous mobile originated call. During
the set up of the original call, the terminating switch releases the
call by sending an ETSI ISUP release message containing
redirection information and a redirection number. Using this
information, the originating MSC sets up a new call using the
information received in the ISUP release message.
On the originating MSC, the terminating record for the first call
is an outgoing trunk record (an outgoing intra-PLMN or an
outgoing gateway record). The originating record for the second
call is an incoming trunk record. Both of these records have an
appended SS information module which contains information
about the call reorigination service. The SS Parameters field
captures the redirection number.
ETSI ISUP Call Re-
origination Based
on Cause
046C FFFFFFFFFFFFFFFFFFFF0215780222C 001C In this form of call re-origination, the original call (mobile or
trunk originated) is released by an ETSI ISUP release message
from the terminating switch. Based upon the cause value in the
release message, the originating MSC sets up a new call to the
original called party. The cause value determines a new entry
point into the number translations system. The call records on
the originating MSC contain details of the call re-origination.
The terminating record for the first call is an outgoing trunk
record and the originating record for the second call is an
incoming trunk record. Both of these records have an appended
SS information module containing details of the reorigination
service.
Proprietary Release
Link Trunk
049C FFFFFFFFFFFFFFFFF61411002133006C 001C RLT on ETSI/ANSI PRI trunks is used to release connections to
an intelligent peripheral (IP) after the application of an off-
board IN service. The MSC routes a call to an IP over the PRI
trunks. The IP signals information for a new call and an RLT
indicator. When MSC signals information indicating that the
new call is progressing, the IP sends an RLT indicator which
applies to the original call. The MSC releases the trunks to the
IP and bridges the call connections. The SS parameter field
contains the charge number taken from the FACILITY message
sent by the IP. The IN service information is captured in an IN
Information module.
049C FFFFFFFFFFFFFFFFF61411002133006C 001C The MSC supports RLT on ANSI ISUP trunks to remove
unnecessary connections from the call path. When the MSC sets
up a call, it includes a call reference value in the network
specific facility (NSF) parameter in the initial address message
(IAM). If it receives another IAM with an NSF parameter
which has the same call reference value, e.g. as a result of call
forwarding, it uses RLT to bridge the calls together and release
unnecessary call connections. The SS parameters field contains
the calling party number received in the IAM.
Table 34 Call completion services
Indic
Description
Closed User
Group (CUG)
061C FFFFFFFFFFFFFFFFFFFFFF043004566C
INIC of 0430
Interlock code of 04566
001C Successful capture of CUG details. Format of SS parameters
field:
Padding with leading Fs
ISDN Network Identification Code (INIC) - four characters.
Interlock Code in the range 00000 - 65535).
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 005C Insufficient information
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 009C Destination not part of CUG
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 036C Not a member of the CUG
Account Code
(ACC)
068C FFFFFFFFFFFFFFFFFFFFFFFFFFFF123C 001C The account code service displays the billing details of calls made
to specific accounts so that the mobile subscriber can differentiate
between this information and other items on the telephone bill.
The dialled account code digits are stored in the SS parameter
field. The result indicator field shows whether the service is
successful (001C) or a failure (056C).
056C
Proprietary
Customer
Information
069C Chars 1-4 CUSTGRP
Char 5 - Sign
Chars 6-8 NCOS
Char 9 - Sign
Chars 10-31 - Fs
Char 32 - Sign
001C
Table 35 Community of interest services
Service SS Code SS Parameters Result
Indic
Description
Anonymous Call
Rejection
0F7C FFFFFFFFFFFFFFFFF61411002133006C 001C The anonymous call rejection (ACRJ) service allows subscribers
to reject anonymous calls from calling parties who deliberately
withhold their calling line identification. These calls (identified
in ISUP signalling by the presentation indicator in the calling
party number parameter being set to restricted) are routed to
treatment and/or taken down. To capture service details the
gateway MSC appends an SS information module to the
appropriate originating call record (the incoming gateway call
attempt record, the incoming intra-PLMN trunk record or the
mobile originated call attempt record).
Optimal Routing
(Late Call
Forwarding)
0FBC FFFFFFFFFFFFFFFFFFFF12146323003C 001C This service optimises the call path created for calls involving
late call forwarding. Late call forwarded calls are connected
through to the VMSC serving the original called party before
being connected to the forwarded-to party.
Without optimal routing the VMSC remains unnecessarily
connected in the call path. With optimal routing, the call drops
back to the gateway switch in the original called partys home
network and the forwarded leg is established from there. SS
information modules containing the SS code of 0FBC are
appended to billing records in the home network for the
optimised forwarded leg.
Extension Service 0F9C FFFFFFFFFFFFFFFFF61411002133006C 001C The extension service allows a subscriber to have a number of
terminal devices alerted on receipt of a call. The service uses a
set of directory numbers (DNs) provisioned against a special
MSISDN called a pilot DN. When a call is made to the pilot DN,
the MSC sets up calls to the associated DNs (which may be in
the mobile or fixed network). Billing information for the call to
the pilot DN is captured in a mobile terminated call attempt
record. Information for calls from the pilot DN to each
associated DN is captured in separate mobile originated call
attempt records. A supplementary services information record is
appended to each record. The SS parameters field captures the
pilot DN.
Malicious Call
Trace
0FAC FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 001C MCT is a proprietary Nortel service which allows a mobile
subscriber to obtain information about a malicious caller. After
receiving a malicious call, the subscriber dials an access code to
obtain information about the last call he/she received.
Information about the last caller is output to logs on the MSC,
and the subscriber is presented with tones and announcements
describing how to find out more about the call. To capture
information about the MCT service, a supplementary service
information module is attached to a mobile originated call
attempt record. This successful result indicates that full
information (at least the calling partys address) was available in
the call trace
005C This result indicates that the captured information is incomplete.
Hot Billing 254C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 001C
Indic
Description
Enhanced Multi-
Level Precedence
and Pre-emption
0A1C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4C
The priority levels which may be captured
are:
4 Priority Level 4
3 Priority Level 3
2 Priority Level 2
1 Priority Level 1
0 Priority Level 0
B Priority Level B
A Priority Level A
021C This service attaches a priority level to a call and allows calls of
a higher priority to be dealt with ahead of lower priority ones
(pre-emption). During call setup an initial priority level is
assigned to the call. For example, the calling party A subscribes
to the eMLPP service and the priority is determined by the
calling party. The SS information module appended to the
mobile originated call record for A contains the priority
information. The result indicator value of 021C indicates that
the priority is user assigned. The SS parameters field contains
the initial priority. If, for example, party C now calls party A
using a higher level priority than the initial call, A can put B on
hold or terminate the call to B and take the call from C. The SS
module appended to the mobile originated record for party C
captures the eMLPP information, including the priority level.
The MSC can capture eMLPP information for users who do not
subscribe to the service. In this case the MSC assigns a priority
level and this is the value captured in the SS Parameters field.
The SS Action field is set to FC for a non-subscriber (as
opposed to 5C for a service subscriber).
The MSC can also capture eMLPP information for calls which
are not answered. In this case, the Call Duration field in the
associated Mobile Originated or Mobile Terminated record is set
to zero (indicated by the default value).
Indic
Description
Enhanced Multi-
Level Precedence
and Pre-emption -
Resource Pre-
emption
0A1C FFFFFFFFFFFFFFFFFFFFFFFFFFFFF24C
The priority levels use the same encoding as
shown in the called party pre-emption
example.
In this example of resource pre-emption:
pre-empting call has priority 2
pre-empted call has priority 4.
022C In this case a call is established with an associated priority level.
While this call is active, another call is initiated with a higher
priority level than the active call. If there are no free network
resources for the higher priority call, the MSC will invoke
resource pre-emption. This releases the currently active call and
marks the appropriate freed circuits for use by the higher
priority call. The MSC then sets up the higher priority call using
the freed resources. The call record for the pre-empted call has
an SS information module appended to it. The SS parameters
field in the module shows the pre-empted and pre-empting
priority levels. Character 20 (2 in the example) shows the
priority of the pre-empting call. Character 21 (4 in the example)
shows the priority of the pre-empted call. The result indicator of
022C shows that the priority level for the pre-empting call was
taken from the value sent in the call setup signalling. A result
indicator of 021C shows that the pre-empting call was
established by a mobile eMLPP service subscriber.
Indic
Description
MSC-HLR Ring
Back Tone Service
0FFC The Date and Time field in the SS
information module contains the time at
which the GMSC sends the IAM to the IP
e.g. 050523152313000C.
The SS Parameters field contains the time at
which the GMSC sends the REL message to
the IP to close the connection. An example
of the completed field is:
FFFFFFFFFFFFFFF0505233152312740C
If an error occurs, the SS Parameters field
contains the default value and the result
indicator contains the value 059C.
001C This supplementary service (SS) allows a called subscriber to
play back a personalised ring tone to the calling party. When the
Gateway MSC (GMSC) receives the incoming call setup
message ((a Radio Layer 3 Setup message or an ISUP Initial
Address Message (IAM)), it sends a MAP Send Routing
Information (SRI) message to the HLR requesting information
about the called party. The HLR finds out the called partys
location and sends an SRI Acknowledgement containing the
Mobile Subscriber Roaming Number (MSRN) and the
subscribers SS data. The GMSC routes the call to the
terminating party by sending an IAM to the Visited MSC
(VMSC). The called Mobile Station sends an Alerting message
to the VMSC, which then sends and Address Complete (ACM)
message the GMSC. The GMSC sends the backward call setup
signalling to the calling party and sends an IAM to the
Intelligent Peripheral (IP). The IP sends an ACM followed by an
Answer Message (ANM) to the GMSC. The IP starts playing the
personalised tone to the calling party. When the called party
answers the call, the GMSC completes the call connection and
releases the connection to the IP by sending Release (REL)
message. The IP confirms the confirms the release by sending a
Release Complete (RLC) message.
If an error occurs, result indicator contains the value 059C and
the SS Parameters field contains the default value.
Table 38 MSC-HLR based ring back tone service
Indic
Description
B4.2.5 Teleservices Information Module
This module shall be used to capture any teleservice information related to a call. The Teleservice
information is derived from the Bearer Capability information and Higher layer compatibility
information (if present) obtained during call setup. Each time the Teleservice is modified during the
course of a call a Teleservice Information module shall be appended to those records that support it.
There may be zero or more of these modules in the records that support it.
The data contained in the teleservice data field of the module is defined in accordance with 3GPP
TS 29.002. The teleservices information module may be appended to multiple MSC structured
records. However, not all of the defined values are valid for all of the structured records. For
example the TS for emergency calls is only applicable to mobile originated calls. This module may
be appended to the following MSC structured records:
Supplementary service (SS) action
If the module is appended to the SS action record this means that the details captured in the record
apply to the teleservice indicated in the module rather than to all teleservices. Unsupported
teleservice codes are reflected as All Teleservices in this module.
NOTE When data resources are utilized at a MSC both Bearer and data service modules
shall be appended to those records that support both modules. Together, the
information contained may be used to derive the full bearer service employed in
the call.
Teleservice M B5.2.197 4
Total Size 24
Table 39 Teleservices information module
06 Module Code
B4.2.6 AoC Parameter Information Module
This module shall be used to capture the charge advice parameters sent to the mobile station at call
setup. The Supplementary Service Code field captures the type of the AoC supplementary service
involved, namely Information. The E-parameter fields capture the Charge advice information
elements derived based upon the tariff system, class and switching pattern. The AoC Parm reason
field captures the reason for the appending of a new AoC module. There may be zero or one of
these modules in the records that support it. It is captured at the beginning of a call and is not
modified if the tariff changes due to either a tariff switch over or a call spanning multiple tariff
bands.
This module also captures information for the CAMEL (GSM/UMTS intelligent networking) AoC
service, which is specified in GSM/UMTS standards as an alternative mechanism to the AoC
supplementary service. In this service, the service control function (SCF) sends the E-parameters to
the MSC/SSP in a SendChargingInformation message. The MSC/SSP then forwards the charging
parameters to the mobile station.
NOTE 1 When the AoC Parameter Information module is appended to a mobile
originating or mobile terminating record the date and time field shall contain the
time at which the AoC parameters were sent to the mobile station.
NOTE 2 In the AoC parameter information module the AoC Parm Reason may contain
one of four values. The value 000C initial indicates that the module contains
the AoC parameters that were initially sent to the mobile station. The value
001C, subsequent indicates that the parameters in the module were sent to the
mobile station as a result of a change in the tariff band that occurred during the
call. The values 002C and 003C provide equivalent information for the CAMEL
AoC service: 002C IN initial and 003C IN subsequent.
SS-Code M B5.2.192 4
Date and Time (NOTE 1) M B5.2.46 16
E-Parameter (1) M B5.2.55 6
AoC Parm Reason (NOTE 2) M B5.2.4 4
Total Size 70
Table 40 AoC parameter information module
07 Module Code
B4.2.7 Tariff Class Information Module
This module shall be used to capture information needed for the Advice of Charge feature. This
module may be appended to the following MSC structured records:
B4.2.8 Data Service Information Module
This module shall be used to capture information about the interworking function resource used
during a data call. When data resources are utilized at a MSC both Bearer (B4.2.2) and data service
modules shall be appended to those records that support both modules. Together, the information
contained may be used to derive the full bearer service employed in the call. There may be zero or
one of these modules in the records that support it.
Incoming gateway
Outgoing gateway
Charge Zone M B5.2.36 6
Subscriber Service M B5.2.190 6
Tariff Class M B5.2.196 6
Total Size 22
Table 41 Tariff class information module
08 Module Code
09 Module Code
NOTE 1 The Data Service information module can be appended to records generated for
data calls subject to call forwarding. In the case where party A calls party B who
forwards to party C, the forwarding records are a Mobile Terminated Call
Forwarding Attempt record for the call from A to B and a Mobile Originated
Call Forwarding Attempt record for the forwarded leg from B to C. In these
records, the appended module contains information in the Data Rate, Connection
Element, Information Transfer Capability and Rate Adaptation fields. The other
fields are defaulted.
NOTE 2 The Data Service information module can be appended to trunk records at points
of network interconnection to capture information about the use of 64kbits/s data
services. In this case, the appended module contains information in the following
fields: Data Rate (if information is available in the call setup signalling),
Information Transfer Capability (Unrestricted Digital Information) and the Rate
Adaption (either no adaptation or H.223/H.245 adaptation). The Connection
Element field contains the value 0C, but this has no meaning in the context of
this type of service.
IWF Trunk Group (MS Side) M B5.2.88 6
IWF Trunk Member (MS Side) M B5.2.89 6
IWF Trunk Group (Network Side) M B5.2.88 6
IWF Trunk Member (Network Side) M B5.2.89 6
Data Volume X B5.2.45 6
Data Rate M B5.2.44 4
Connection Element M B5.2.38 2
Information Transfer Capability M B5.2.85 2
Data Compression M B5.2.43 4
Number of Fax Pages C B5.2.122 4
IWF Diagnostic Code C B5.2.94 4
IWF Activation Timestamp C B5.2.93 16
Rate Adaptation M B5.2.155 2
Total Size 72
Table 42 Data service information module
B4.2.9 Other Agent Information
This module shall be used to capture information about the geographical location of the terminating
mobile subscriber. The terminating location field captures the cartographical coordinates of the
called mobile subscriber at the time of call setup.
This module may be appended to the Mobile originated call attempt MSC structured record.

NOTE This module will only be appended to the mobile originated call attempt record if
the terminating location is returned in the ISUP NTP parameter to the originating
MSC. Currently this parameter is only defined in the ANSI ISUP standard.
B4.2.10 Location Only Information Module
This module shall be used to record the location information about a short message service
interaction. The Location area code and the Cell-SAC (Service Area Code) Id fields unambiguously
capture the location of the mobile station. The MSC shall provide the option to capture a module for
each new identifiable location in a call or only the first and last locations. Further; with regards to
the first option the MSC shall provide the option to suppress the generation of this module for each
intra-BSS handover that is performed during the call.
Location Services (LCS)
NOTE 1 When an inter-MSC handover is performed the MSC Number captured in this
field will be that of the handed-to MSC.
(continued)
Terminating Location M B5.2.198 16
Total Size 20
Table 43 Other agent information module
MSC Number (Note) M B5.2.115 28
Location Area Code M B5.2.104 12
Cell-SAC Id M B5.2.31 6
Total Size 52
Table 44 Location only information module
10 Module Code
04 Module Code
NOTE 2 The location area code field contains either a 2-digit or a 3-digit Mobile Network
Code (MNC). The World Trade wireless networks (all markets except North
America) use a 2-digit MNC. The North American wireless markets will need a
3-digit MNC (by July 1998, all North American networks must be able to
support 3-digit MNCs to comply to PCS specifications). The display of either 2
or 3 digits in the location area code field is provisioned using the office
parameter MNC in the table OFCVAR.
NOTE 3 This module is appended to a successful LCS billing record termination and for
every handover in order to record the location information. Where paging is not
done because of subscription, the module is not appended because of privacy
authorization failure.
B4.2.11 Equal Access Information Module
This module is used to capture information relating to the long distance carrier used for a call. Some
indication of the relationship between the calling subscriber and the long distance carrier e.g. pre-
subscribed, as well the manner in which the connection was established, e.g. via an operator, is also
captured in this module. There may be zero or one module appended to records that support it.
IC/INC Prefix C B5.2.87 10
Type of Carrier Identification Code C B5.2.200 2
Carrier Connect Timestamp C B5.2.29 16
IC/INC Call Event Status C B5.2.86 4
Total Size 36
Table 45 Equal access information module structure
12 Module Code
B4.2.12 Partial Information Module
This module shall be used to indicate that a call record is a partial record. It is appended to each
Partial record generated. This module may be appended to the following MSC structured records:
B4.2.13 Trunk Usage Information Module
This module is used in two situations:
to indicate that an incoming or outgoing trunk record is a result of inter-MSC handover.
to indicate that an outgoing trunk record is a result of call monitoring.
It shall be appended to only those trunk records that are appropriate, i.e. those trunk records
generated due to either to an inter-MSC handover or call monitoring.
Partial Record Sequence Number M B5.2.140 6
Partial Record Event Code M B5.2.137 4
Partial Record Reason M B5.2.138 4
Partial Record Reference Number M B5.2.139 8
Total Size 26
Table 46 Partial information module
13 Module Code
16 Module Code
B4.2.14 IN Information Module
This module shall be used to capture information about calls which use services provided by an
Intelligent Network (IN) connected to the PLMN. The MSC/SSP contains standard IN switching
logic in the service switching point (SSP) which is an additional capability located on the switch.
This means that it can interrupt normal call processing as necessary to interact with the service logic
in the IN Service Control Point (SCP) and with intelligent peripherals (IPs) which provide facilities
such as tones and announcements. This is called on-board IN service provision as the switch is an
SSP which interacts with the IN using either 3GPP CAMEL (Customised Applications of Mobile-
network Enhanced Logic) signalling or ITU-T INAP (IN Application Part) signalling. In contrast,
the MSC (without an SSP) uses a proprietary mechanism to route a call to/from the IN via an
external SSP. This is called off-board IN service provision because the IN signalling occurs off the
switch. The IN information module captures information for off-board and on-board IN services.
The module is only appended for IN SMS services using INAP CS1-R. The CAMEL
SMS information module (B4.2.21 on page 107) captures information for CAMEL
mobile originated SMS.
Location update record
Trunk Usage Reason M B5.2.199 4
Total Size 8
Table 47 Trunk usage information module
18 Module Code
NOTE 1 The IN timestamp fields and the operation indication field in the IN information
module capture information for on-board IN services involving the MSC/SSP.
The operation indication field indicates the type of IN operation, and may be:
SCP call translation, SCP call diversion, IP interaction, call extension or tone
generation for the geozone service
1
. Call extension is used to indicate that a
record was created as part of the mechanism for providing a terminating IN
service. For example, a terminating party may subscribe to IN call forwarding, in
which case the MSC/SSP sets up a second call leg to the forwarded-to party. In
this case, the Mobile Originated Call Forwarding Attempt record for the new call
leg has an appended IN information module which indicates call extension. For
an interaction with an IP, the field timestamp1 captures the time at which the IP
answered the call, and timestamp2 captures the time at which the IP was
released. For the geozone service
1.
, the timestamp fields capture the duration of
the tone and the operation indication field indicates tone generation. In addition,
the number captured in the Destination Routing Address (DRA) field depends
upon the IN service: for SCP call diversion or translation, DRA contains the new
called number returned by the SCP; for an IP interaction, DRA contains the
address of the IP.
NOTE 2 An IN service may involve more than one interaction with an IP or with the SCP.
A separate IN information module is created for each interaction. A call record
therefore may have a number of IN information modules appended.
(continued)
Detection Point C B5.2.51 4
Service Key C B5.2.180 12
Destination Routing Address C B5.2.50 32
SCP (Service Control Point) Address C B5.2.173 22
Off-Board IN Service Identifier C B5.2.126 4
Off-Board IN Service Indicator C B5.2.127 4
Charge Number C B5.2.35 24
IN Time Stamp1 C B5.2.77 16
IN Time Stamp2 C B5.2.78 16
Operation Indication C B5.2.133 2
CSI (CAMEL Subscription Information) C B5.2.42 2
IN Protocol C B5.2.76 2
Local Reference Number C B5.2.103 12
SCF ID / ETC Parm1 C B5.2.172 34
Correlation ID / ETC Parm2 C B5.2.40 34
Total Size 224
Table 48 IN information module
1.
Geozone tones are supported only on the stand-alone GSM/UMTS MSC configuration. The Nortel GSM/
UMTS MSC call server does not support Geozone tones in the BICN packet network configuration. Geozone
tones are not supported for the BICN portion of a hybrid GSM/UMTS MSC/MSC call server.
NOTE 3 If the original SCP is overloaded and the network supports service provision by a
standby SCP, the SCP address field contains the standby SCPs address.
NOTE 4 An IN information module may contain an Operation Indication field containing
the value 3 (call extension) and a detection point field containing the value 0
(none). This indicates that the module was generated as a result of an IN service,
but not as a direct result of DP triggering. The reason for this is that, as well as
the standard basic call state machines (BCSMs), the MSC/SSP uses an internal
mechanism called virtual agents to connect IN calls. For example in a
terminating IN call forwarding scenario, the MSC/SSP which forwards the call
uses two virtual agents, one for the termination of the original call leg and the
other for the origination of the forwarded call leg. As a result of call records
being generated both for the IN service and as a result of the use of virtual
agents, it is possible for a subscriber to be billed more than once for the call.
However, an IN information module containing the call extension information
indicates that the associated call record can be ignored for billing purposes.
NOTE 5 For terminating off-board IN services there is no IN trigger to cause the IN
information module to be appended to the terminating record. In this scenario,
the MSC receives an IN terminating index in the SRI Ack message from the
HLR and uses it to form a connection to the off-board IN network. The
originating record - a mobile originated call attempt record or an incoming
gateway record - has an IN information module appended to it. Because there is
no terminating IN trigger the outgoing record does not have an appended IN
information module and so contains no information about the offboard IN
service.
After the application of the off-board service, the service node may invoke the
Dual Port Release Link Trunk (RLT) service to release the trunks to the MSC. In
this way, the call path does not 'trombone' through the service network and waste
resources. In this case, both the originating record and the terminating record - an
outgoing trunk record or a mobile terminated call attempt record - have IN
information modules appended to capture the RLT service details.
NOTE 6 The customised ring back tone service allows a customised tone, music clip etc.
to be played to the calling party while the call is being connected to the called
party. The customised tone is provided as a terminating IN service. It generates
two IN information modules. The first module contains information obtained
from the CAMEL Connect message from the SCP. The second contains
information about the connection to the Intelligent Peripheral/Intelligent Voice
Recognition device used to play the tone, announcement, clip etc. to the
calling party. In this module the Destination Routing Address field contains the
address for routing the call to the IP/IVR: it is obtained from the Generic
Address field of the Connect message that the SCP sends to the GMSC. The
operation indication field contains the value 6C to indicate the ringback tone
service.
B4.2.15 IN Charging Information Module (CS-1R INAP Services)
The IN charging information module is used by the MSC/SSP to capture service-related billing
information for a mobile originated on-board IN service. The Service Control Point (SCP) sends the
billing information to the MSC/SSP in one or more INAP FurnishCharging Information (FCI)
messages. These messages contain either explicit billing parameters, or freeform parameters. The
length of the FCI explicit parameters and the freeform parameter is defined in ETS 300 374-1, but
the content is specific to the network operator.
As shown in Table 49, the IN charging information module contains three freeform FCI billing
items. This means that it can store up to three billing items from an FCI message(s). Any further
billing messages are stored in additional charging modules. In processing the information in the FCI
message(s), the MSC/SSP extracts the billing parameters one-by-one, and converts any explicit
parameters into freeform equivalents. This produces a format where the length of each billing item
is fixed to the length of the freeform parameter. The downstream processor is responsible for
processing this information.
FCI Freeform 1 M B5.2.60 46
Total Size 142
Table 49 IN charging information module
19 Module Code
B4.2.16 Generic Address Information Module
This module shall be used to record billing information for incoming trunks on a MSC acting as a
point of interconnect (POI) with other networks. The POI switch screens incoming calls on
specified trunk connections to ensure that the calling party is permitted to use the network facilities.
The module is populated by ITU-T ISUP, ATUP and I-ISUP trunks at the POI. The ITU-T ISUP
agent populates the original calling number field. The ATUP agent populates the pre-translated
called number field. The I-ISUP agent populates both fields. The module can also be used to
provide the additional call information (original calling number and pre-translated called party
number) for basic calls and for call forwarding scenarios.
Users can datafill the MSC to append this module to incoming trunk call detail records (CDRs) for
all supported trunk agents. Its function in this case is to capture the pre-translated called party
number. This is because when the gateway MSC gets routing information (the MSRN) from the
HLR, it replaces the original called number (the MSISDN) in the incoming trunk CDR with the
routing number. By appending this module, there is a record of the MSISDN. The module in this
case does not capture the original calling number and so this field contains the default value. Using
the Generic Address Info SOC (software optionality control) option, users can extend the use of the
module to be appended to the mobile originated and terminated record, the roaming record and the
outgoing trunk records. In this case, the module captures additional call information for basic calls
and for call forwarding.
The module may be appended to the following MSC structured records:
NOTE The boolean office parameter GSM_MSISDN_IN_IC_TRK_RECORD
determines whether or not the generic address module is appended to incoming
trunk records. However if the SOC option GSM Generic Address Info is
switched on, it overrides the setting of this office parameter and the generic
address information module is appended to call records.
Pre-translated Called Party Number M B5.2.146 40
Original Calling Number M B5.2.134 40
Post-translated Called Party Number M B5.2.145 40
Total Size 124
Table 50 Generic address information module
20 Module Code
B4.2.17 Network Call Reference Information Module
The network call reference information module captures the network call reference number
(NCRN) assigned to the call and the address of the MSC used to setup the call. The MSC captures
this information in a number of different call scenarios:
for a mobile terminated basic call where the Mobile Application Part (MAP)
SendRoutingInformation (SRI) message is at version 3 or higher.
mobile originated and terminated CAMEL (GSM/UMTS intelligent networking
services) calls
optimally routed calls
For a mobile terminated call, the gateway MSC generates the NCRN and sends it to the HLR in a
MAP v3 SRI message.
For a mobile originated CAMEL call, the visited MSC generates the network call reference number
and sends it to the gsmSCF (Service Control Function) in the CAMEL InitialDP message. For a
mobile terminated call CAMEL call, the GMSC queries the HLR for CAMEL service information
and for routing information using MAP SRI messages. The GMSC generates the NCRN and sends
it to the HLR in the SRI. When the HLR queries the terminating VMSC for routing information, it
sends the NCRN in the ProvideRoamingNumber message.
For call forwarding, either the VMSC or GMSC generates this number depending on where the call
is forwarded. In early call forwarding, the GMSC forwards the call and so generates the network
call reference number. In late call forwarding, the call is connected to the VMSC of the called party
before being forwarded, and in this case the VMSC generates the network call reference number. A
call may be connected through a number of nodes as the result of an IN service and each of them
may generate billing information. The network operator/service provider can use the information in
the network call reference information module appended to each billing record to correlate the
records at the downstream processor.
This module is also used to capture information for the optimal routing of late forwarded calls. In
late call forwarding the call is connected to the VMSC serving the called party before the
forwarding condition is encountered. If the call is optimally routed, the call falls back to the GMSC
in the home network of the called party and the forwarded leg is routed from there (rather than from
the VMSC as would happen if the forwarded leg were connected normally). This optimises the call
path by removing the unnecessary connection to the VMSC. During call setup, the GMSC assigns a
network call reference number for the call. The network call reference number and the GMSCs
address are signalled via the HLR to the VMSC. The VMSC uses the network call reference
number and the GMSCs address to hand the call back to the GMSC if the call forwarding condition
is encountered. The network call reference number and the GMSCs address are captured in
network call reference information modules appended to billing records on the GMSC and the
VMSC. Once again, the network call reference information module is used to correlate the billing
records generated on the GMSC and the VMSC.
For CAMEL services, the network call reference number is signalled in the MAP Subscriber
Request Information (SRI) message and the Provide Roaming Number (PRN) message. For
Optimal Routing the number is signalled in the Resume Call Handling (RCH) message. These
services do not rely on any ISUP parameters to signal the network call reference number.
22 Module Code
NOTE The network call reference number captured in this information module is
completely unrelated to the record number captured in the billing record to
which it may be appended.
B4.2.18 CAMEL Charging Information Module
The CAMEL Charging Information Module is used by the MSC/SSP to capture the charging
information generated during a CAMEL Phase 2 or Phase 3 service. CAMEL supports the
signalling of free format charging information from the service control function (gsmSCF) to the
MSC/SSP. The gsmSCF sends the charging information to the MSC/SSP in one or more
FurnishChargingInformation (FCI) messages. CAMEL also supports the signalling of charging
information for CAMEL Phase 3 mobile originated short message services (MO SMS). In this case,
the gsmSCF sends the charging information to the MSC/SSP in one or more FurnishCharging
InformationSMS messages.
For CAMEL Phase 2 and 3 services, there may be up to two CAMEL Charging Information
modules, one for leg 1 (calling party) and one for leg 2 (called party). In CAMEL Phase 2, any new
information received in FCI messages overwrites the charging information already received. In
CAMEL Phase 3 the new charging information may overwrite the existing data or be appended to
it.
Short Message Service, Mobile Originated
Network call reference number M B5.2.117 18
MSC address M B5.2.113 28
Total Size 50
Table 51 Network call reference information module
23 Module Code
NOTE The CAMEL Phase 2 charging information service produces a maximum of 40
octets (80 characters) of charging data. For this reason, only the free format data
1 and 2 fields contain charging data for a CAMEL Phase 2 service. The CAMEL
Phase 3 service can generate up to 160 octets (320 characters) of data and so all
eight fields may be completed. For both Phase 2 and 3, any fields which do not
contain charging data contain default values.
B4.2.19 Mobile Number Portability Information Module
Mobile number portability (MNP) allows subscribers to change operators without changing their
directory numbers (MSISDNs). To do this, ranges of numbers in the dial plan are defined as being
portable numbers. During call setup, if the MSC recognises a number in the portable range, it
queries the Number Portability Database (NPDB) for information about the number. If the number
has been ported, the NPDB returns a routing number which the MSC uses to route the call to the
new network. If the number has not been ported, the NPDB instructs the MSC to continue normal
call processing. The MSC captures the results of the MNP service in the MNP information module.
Free Format Data 1 M B5.2.63 42
Local Reference Number M B5.2.103 12
Party to Charge M B5.2.141 4
CSI (CAMEL Subscription Information) M B5.2.42 2
Total Size 358
Table 52 CAMEL charging information module
Routing Number M B5.2.170 26
Query Method M B5.2.154 2
Ported Status M B5.2.143 2
Called IMSI Number M B5.2.21 26
Total Size 60
Table 53 Mobile Number Portability information module
25 Module Code
B4.2.20 GSM Assisting SSP (ASSP) Information Module
The GSM ASSP information module is used by the MSC/SSP to capture billing information related
to the use of an intelligent peripheral (IP) device during a CAMEL Phase 2 intelligent network (IN)
service. In the network, some MSC/SSPs may be provisioned with connections to IPs. They can
provide connections to their IPs to other MSC/SSPs. In CAMEL terminology, they act as assisting
MSC/SSPs by providing connections for initiating MSC/SSPs.
An example of how this operates is that an initiating MSC/SSP initiates a CAMEL dialogue with
the SCP using the CAMEL InitialDP message. The SCP tells it to connect to an IP using the
EstablishTemporaryConnection message. To set up the connection to the IP, the initiating SSP sends
the assisting SSP an ISUP initial address message (IAM). The assisting SSP requests instructions
from the SCP using the CAMEL AssistRequestInstructions message. The SCP sends appropriate
instructions in a ConnectToResource message. The assisting SSP sends an ISUP IAM to the IP
which responds with an ISUP answer message. The assisting SSP then sends an ISUP answer
message to the initiating SSP to form a connection between the initiating SSP and the IP. After this,
further CAMEL and ISUP messages exchanged between the initiating and assisting SSPs and the
SCP determine how the IP is used for the call. The assisting SSP captures details about the use of
the IP in the GSM ASSP information module. If the SCP sends the assisting SSP several
ConnectToResource messages, the assisting SSP will append multiple GSM ASSP information
modules to the incoming trunk record.
SCP Address C B5.2.173 22
SCF ID C B5.2.171 22
Correlation ID C B5.2.39 24
IP SSP Capability C B5.2.92 10
IN Protocol C B5.2.76 2
IP Routing Address C B5.2.91 24
Total Size 140
Table 54 GSM ASSP information module
26 Module Code
B4.2.21 CAMEL Short Message Service (SMS) Information Module
The CAMEL SMS Information Module is used by the MSC/SSP to capture information about
mobile originated CAMEL SMS calls. In CAMEL Phase 3 there are a number of capabilities and
messages targetted specifically at providing intelligent network services for SMS. The module may
be appended to the SMS mobile originated structured record.
NOTE 1 On the MSC provisioning allows the enabling and disabling of this module. If
required the production of this module may be disabled. Please see Section B3.8
on page 49.
NOTE 2 If the original SCP is overloaded and the network supports service provision by a
standby SCP, the SCP address field contains the standby SCPs address.
SCP Address M B5.2.173 22
Service Key M B5.2.180 12
IN Protocol M B5.2.76 2
Default SMS Handling Indicator (DSH Indicator) M B5.2.48 2
Default SMS Handling Applied (DSH Applied) M B5.2.47 2
Operation History C B5.2.132 26
SMS Start Time C B5.2.184 16
SMS Stop Time C B5.2.185 16
IN Call Reference Number C B5.2.74 18
Modified Service Centre (Service Centre) C B5.2.179 28
Modified Destination Subscriber Number (Called Party) C B5.2.23 30
Modified Calling Number (Calling Number) C B5.2.26 30
SMS Release Cause Value C B5.2.182 4
IN Dialogue Result M B5.2.75 2
Total Size 214
Table 55 CAMEL SMS information module
27 Module Code
B4.2.22 Patching Information Module
The Patching Information Module allows new capabilities to be added to the MSC. Nortel patch
designers use the module to patch information as demanded by customers. Once a patch is sourced
to become part of a standard, supported software load for an MSC product release, the information
module is freed up for use in other patching. The module is solely for the use of Nortel patch
developers, though customers could see the module at their downstream processors if they request
patched updates.
NOTE The field names and their contents are only indicative and may change
depending on the patch requirements. For details of how a particular patch uses
this module please refer to the administrative information for the patch.
Unused Number 1 C B5.2.201 40
Unused Number 2 C B5.2.202 40
Unused Timestamp 1 C B5.2.203 16
Unused Timestamp 2 C B5.2.204 16
Patch Identity C B5.2.142 12
Total Size 128
Table 56 Patching information module
28 Module Code
B4.2.23 Bearer Independent Core Network Information Module
The Bearer Independent Core Network (BICN) information module captures billing information for
operators of 3GPP Release 4 BICNs. In this network, the MSC call server provides call control and
Media Gateways provide bearer connections for the call. The core network infrastructure of voice
circuits is replaced with a packet-based Internet Protocol (IP) or Asynchronous Transfer Mode
(ATM) network.
In handover scenarios there may be several BICN modules appended to the call records to show the
subscribers different locations.
Media Gateway (MGW) Number C B5.2.108 14
MGW Seizure Time C B5.2.109 16
Backbone Media Type C B5.2.8 2
Access Media Type C B5.2.1 2
Total Size 38
Table 57 Bearer Independent Core Network information module
29 Module Code
B4.3 Market-Specific Modules
This section contains the market-specific modules supported by the MSC. These modules will only
be seen by the customers for whom they were implemented or for the markets in which they are
required. The market-specific modules are shown in table Table 58. For quick reference, the table
also shows the records to which each module may be appended.
B4.3.1 Originator-Terminator Information Module
This module is used to capture detailed addressing information concerning the originating and
terminating parties involved in a PCS-1900 call. There may be zero, one or multiple modules
appended to records that support it.
Mobile originated call attempt record
Mobile terminated call attempt record
Call Detail Records and Structure Codes
M
o
b
.

O
r
i
g
.
M
o
b
.

T
e
r
m
.
R
o
a
m
i
n
g
I
/
C

G
a
t
e
O
/
G

G
a
t
e
T
r
a
n
s
i
t
S
M
S

M
O
S
M
S

M
T
I
/
C

i
n
t
r
a
O
/
G

I
n
t
r
a
C
E
U
S
S

A
c
t
i
o
n
Information Module
Attach
a
a. This column specifies how many times the module can be appended to a call record: 0-1 indicates that the
module can be appended once; 0-n indicates that the module can be appended many times.
Rel
b
b. This column shows the product releases in which each module was added to the billing system.
Code Ref. 02 03 18 13 14 17 04 05 15 16 19 06
End of Module List 1 02 00 B4.2.1 on page 80 Y Y Y Y Y Y Y Y Y Y Y Y
PCS 1900 Market-Specific Information Modules
Originator-Terminator 0-n 05 11 B4.3.1 on page 110 Y Y Y Y Y
Toll Free 0-n 06 14 B4.3.2 on page 111 Y Y Y
Local Number Portability (LNP) 0-n 08 21 B4.3.3 on page 111 Y Y Y
Singapore Specific Information Modules
Singapore Specific 0-1 06 17 B4.3.4 on page 112 Y Y Y Y Y Y Y Y
German and Austrian Carrier Specific Information Module
Carrier Selection Charging 0-1 11 24 B4.3.5 on page 113 Y Y Y Y Y
Table 58 Information modules
Charge Number/ANI C B5.3.3 40
Originating Line Information/II Parameter C B5.3.10 4
Originating NPA/NXX C B5.3.11 8
Automatic Number Identification Indicator C B5.3.1 2
Terminating Numbering Plan Area C B5.3.18 4
Generic Address Parameter C B5.3.4 30
Total Size 92
Table 59 Originator-terminator information module structure
11 Module Code
B4.3.2 Toll Free Information Module
This module is used to capture information relating to the Toll Free Database query involved in
PCS-1900 originating calls. Information regarding PCS-1900 terminating calls is not supported.
Note that per TR-533 specifications, the MSC shall not generate any record if the Toll Free
Database does not respond within the specified time-out period. There may be zero or one of these
modules in records that support it.
B4.3.3 Local Number Portability (LNP) Information Module
This module shall be used to record billing information for calls using the PCS-1900 LNP service.
LNP allows subscribers to retain their directory numbers when changing service provider, service
mix or location (location portability is not supported in the phase 1 service). These retained
numbers are called ported numbers. The addressing used to support the LNP service is the location
routing number (LRN). This is a number in the North American NPA-NXX format which uniquely
identifies the network to which a subscriber has moved. The information used to support the LNP
service is stored in a local LNP database and also in datafill on the MSC. PET7 signalling may carry
LNP service information as it contains fields for both the ported number and the LRN. The call
scenario determines which sources of information are used.
The LNP information module when captured is used to support the correct distance calculation for
billing calls to/from a carrier when the originator or terminator is not native to a switch. It is also
used to bill for queries made to the LNP database.
Toll Free Call Type Code M B5.3.19 4
Called Party Off-Hook Indicator M B5.3.2 2
Service Feature Code M B5.3.15 4
SCP Determined Terminating Number M B5.3.14 20
Overseas Indicator M B5.3.12 4
LATA M B5.3.6 4
IN/INC Routing Indicator C B5.3.5 2
Total Size 44
Table 60 Toll free information module
14 Module Code
21 Module Code
Whenever the MSC queries the LNP database it captures information in the LNP information
module. This happens regardless of the response from the database or whether the resulting call is
answered.
B4.3.4 Singapore Specific Information Module
This module is used to capture Singapore specific information. This module is only supported for
the MSCs which have the value of singapore in the MARKET_OF_OFFICE field in table
OFCENG.
Not all fields are captured each time this module code is present. This module may be appended to
the following MSC structured records (whether or not it is captured in a particular call is dependent
on particular scenarios):
The fields calling party category and city wide centrex capture information from the Singapore (ST)
ISUP signalling. This signalling is used to provide centrex services such as abbreviated dialling.
Party Identifier M B5.3.13 4
Location Routing Number M B5.3.8 12
Service Provider Identity X B5.3.16 10
Location X B5.3.7 16
Supporting Information M B5.3.17 8
Total Size 54
Table 61 Local number portability information module
Field Reference Size
XCLI Indicator C B5.4.7 4
National/International Indicator C B5.4.4 4
Other Subscriber CUSTGRP C B5.4.5 6
Other Subscriber NCOS C B5.4.6 6
Calling Party Category C B5.4.1 4
City Wide Centrex C B5.4.2 6
Total Size 34
Table 62 Singapore specific information module
17 Module Code
B4.3.5 Carrier Selection Charging Information Module
The carrier selection information module captures information about the carrier identification code
(CIC) of the carrier selected to handle the call.
Austrian Market
In the Austrian market, the CIC is signalled in the ITU-T ISUP Initial Address Message in either the
TNS parameter (transit network selection) or the CDPN parameter (called party number).
German Market
In the German market, the CIC is signalled in the ITU-T ISUP Initial Address Message in either the
TNS parameter (transit network selection) or the CSP (carrier selection parameter). At a gateway
point of interconnect (POI) switch the call may be screened to make sure that the caller can use the
network facilities. The CIC in the IAM is compared with the default CIC stored on the switch in
table OFCENG. If they match the call is screened based on the calling / redirecting party number
and access is allowed or denied based upon the outcome of the screening.
To screen the call (whitelist or blacklist screening) the MSC compares the calling / redirecting
number with entries in table DNSCRN.
The call may then be screened according to the subscriber group (also called subscriber class) of the
calling party. The screening of the subscriber group affects the routing of the call by determining
different entry points into the translations system for different groups of subscribers. The subscriber
group options are determined by the table option CUSTINFO in tables DNSCRN and PETSERVS.
CUSTINFO can be set to REG, UNREG, PRESEL, UNPAID or BLOCK. It is the setting of the
CUSTINFO option in these tables which determines the entry point into translations. The
subscriber group information is captured in the subscriber customer group field shown in Table 63.
Austrian and German Markets
For both market variants, the module may be appended to the following MSC structured records:
Selected Carrier Identification Code (CIC) M B5.5.3 4
Default CIC M B5.5.1 4
Subscriber Customer Group M B5.5.4 6
Total Size 18
Table 63 Carrier selection charging information module
24 Module Code
B5 Data Field Descriptions
B5.1 Overview
Data fields are the basic elements of the MSC records. This section describes the data fields
referenced from the record and module descriptions in Section B4. The description of the field
encoding depends on the type of field:
If the field is an atomic field, its contents are shown in a reference table which lists the
meaning of each BCD/hex character in the field. These tables also contain some
example values which show how the field may be populated. These values are
representative but are not a full listing of all values. An atomic data field contains signed
packed BCD or Hex characters and a sign character (Hex C). The characteristics of the
data fields are listed in Table 64. Unless otherwise indicated all characteristics apply.
NOTE 1 All unlisted values that can be associated with a particular character should be
considered as reserved for future use.
NOTE 2 The digits that are stored in a BCD or Hex character string are right justified with
unused characters filled with Hex-Fs.
Some of the fields use generic field types for their definition. For example the IN
timestamp fields use the date and time atomic field encoding. In these cases, the field
descriptions contain a reference to the atomic field used for their encoding.
Some fields are compound fields. For example the Record Header data field is formed
from three atomic data fields: the Hexadecimal ID, the Structure code, and the Call type
code. In these cases, the descriptions refer to the atomic field encoding for each field in
the compound field.
Sign Character:
The least significant character position of a data element is a sign character. Under normal conditions this
character shall be set to Hex-C. In the event that some of the character positions of the data field contain
data known or suspected to be missing or in error, or unavailable then this character shall be set to Hex-D.
Maximum Length:
The maximum length of an atomic data field is 32 BCD or Hex characters (including the sign character) for
all fields except the SCF ID / ETC Parm1 and Correlation ID / ETC Parm2 fields which are 34 characters
long. Additionally, the Free Format Data field and the fields Geographical Location of UE 1 to
Geographical Location of UE 4 are 42 characters long and the FCI Freeformat Data Parameter field is 46
characters long.
Flag Procedure:
The Hex-F character is used for each character that should be present in the data field but is known or
suspected to be in error. When the Hex-F character is used in this manner then the sign character (as stated
above) shall be a Hex-D. Further the Hexadecimal Identifier field of this record shall be set to Hex-AB.
Encoding:
The lower nibble (bit 4-1) of a byte (bit 8-1) encoding digit 2(n-1)+1 and the upper nibble (bit 8-5) of a
byte encoding digit 2n where n is the byte number of the BCD string (starting 1)
Table 64 Characteristics of GSM/UMTS billing atomic data fields
B5.2 Data Fields
This section describes the data fields in the billing records and modules described in Sections B4.1
on page 59 and B4.2 on page 79. For information on data fields in market-specific modules, refer to
Sections B5.3 on page 244 (PCS market), B5.4 on page 254 (Singapore market) and B5.5 on
page 257 (German and Austrian markets).
Table 65 lists all of the data fields, provides references to the field descriptions and lists the records
and/or modules which contain the fields. Use the key below for the abbreviations used in the table.
The Size column in the table lists the size of each field in BCD characters. The Type column
indicates whether the field is an atomic field or a compound field. If the Type field indicates that a
field is a compound field, the Field Name column shows the fields component fields in italic text.
Throughout Section B5.2, wherever you see the key symbol ( ), you can click on it to jump back
to this key. When you click on the return symbol, you return to the field table you were looking at.
Key to Table 65
Records
Call Detail Records Ro Roaming Call Attempt
Ack Acknowledgement Record (GSM-R) SSA Supplementary Service Action Record
CEU Common Equipment Usage SMSMO Short Message Service, Mobile Originated
ICG Incoming Gateway Call Attempt SMSMT Short Message Service, Mobile Terminated
ICIP Incoming Intra-PLMN Trunk Record Tr Transit
LCS Location Service (LCS) Record Switch/Billing File Records
LU Location Update Record BBHR Billing Block Header Record
MO Mobile Originated Call Attempt BFTIR Billing File Transfer In Record
MT Mobile Terminated Call Attempt BFTOR Billing File Transfer Out Record
OGG Outgoing Gateway Call Attempt SRR Switch Restart Record
OGIP Outgoing Intra-PLMN Trunk Record TCR Time Change Record
Information Modules
AoC Advice of Charge GA Generic Address OA Other Agent
BICN Bearer Independent Core Network GASSP GSM Assisting SSP PaI Patching
BS Bearer Service IN IN PI Partial Information
CC CAMEL Charging INC IN Charging SS Supplementary Service
CSMS CAMEL SMS LaC Location and Channel TC Tariff Class (AoC)
DS Data Services LO Location Only TS Teleservice
EA Equal Access MNP Mobile Number Portability TU Trunk Usage
EoM End of Module List NCR Network Call Reference
Field Name Size Type Ref. Call Records Switch / File Records Module
Access Media Type 2 Atomic B5.2.1 BICN
Access Network 2 Atomic B5.2.2 SSA LaC, LO
Additional Information 4 Atomic B5.2.3 MO, MT
Advice of Charge Parameter Reason 4 Atomic B5.2.4 AoC
Age of Location Information 6 Atomic B5.2.5 LCS
Answer Time
(of type Date and Time)
16 Atomic B5.2.6 MO, MT, Ro, ICG, OGG, Tr,
ICIP, OGIP
GASSP
Table 65 Data fields in billing records and modules
Return
Auxiliary Record Header
Sensor Type (4)
Sensor Identity (8)
Recording Office Type (4)
Recording Office Identity (8)
24 Compound B5.2.7 TCR, SRR, BBHR,
BFTIR, BFTOR
Backbone Media Type 2 Atomic B5.2.8 BICN
BCD or Full Hex String --- Atomic B5.2.9 Generic atomic field used by other data fields
BCD or Hex String (N) --- Atomic B5.2.10 Generic atomic field used by other data fields
Bearer Service 4 Atomic B5.2.11 BS
Block Count (BCD/Hex String 6) 6 Atomic B5.2.12 BFTOR
Block Number (BCD/Hex String 6) 6 Atomic B5.2.13 BBHR
Boolean Type 2 Atomic B5.2.14 Generic atomic field used by other data fields
Call Duration 14 Atomic B5.2.15 MO, MT, Ro, ICG, OGG, Tr,
ICIP, OGIP, CEU
Call Forward Indicator (Boolean Type) 2 Atomic B5.2.16 MO, MT
Call Indicator 8 Atomic B5.2.17 MO, MT, Ro
Call Reference (BCD/Hex String 8) 8 Atomic B5.2.18 All records
Call Type Code 4 Atomic B5.2.19 See Record Header field
Called Equipment (or Served Equipment) 22 Atomic B5.2.20 MT, SMSMT
Called IMSI Number (BCD/Hex String 26) 26 Atomic B5.2.21 MNP
Called Number (or Served Number)
Number Type (2)
Numbering Plan Identifier (6)
BCD/Hex String (32)
40 Compound B5.2.22 MO, MT, Ro, ICG, OGG, Tr,
SMSMO, SMSMT, ICIP,
OGIP, Ack
Called Party (or Served Party)
Number Type (2)
BCD/Hex String (22)
30 Compound B5.2.23 MT, Ro, SMSMT CSMS
Called Subscriber Category 4 Atomic B5.2.24 MT
Calling Equipment (or Served Equipment) 22 Atomic B5.2.25 MO, SMSMO, SSA
Calling Number (or Served Number)
Number Type (2)
BCD/Hex String (22)
SMSMO, SMSMT, ICIP,
OGIP, CEU, SSA, Ack
Calling Party (or Served Party)
Number Type (2)
BCD/Hex String (22)
30 Compound B5.2.27 MO, SMSMO, CEU, SSA
Calling Subscriber Category 4 Atomic B5.2.28 MO
Carrier Connect Timestamp
16 Atomic B5.2.29 EA
Cause for Termination 4 Atomic B5.2.30 MO, MT, Ro, ICG, OGG, Tr,
SMSMO, SMSMT, ICIP,
OGIP
Cell-SAC Id 6 Atomic B5.2.31 SSA LaC, LO
Channel Allocation Time
16 Atomic B5.2.32 MO, MT
Channel Description 10 Atomic B5.2.33 LaC
Channel Type 6 Atomic B5.2.34 LaC
Charge Number
Number Type (2)
BCD/Hex String (22)
24 Compound B5.2.35 IN
Charge Zone 6 Atomic B5.2.36 TC
Classmark Time Stamp
16 Atomic B5.2.37 MO, MT
Connection Element 2 Atomic B5.2.38 DS
Correlation Id BCD/Hex String (24) 24 Atomic B5.2.39 GASSP
Correlation ID / ETC Parm2 34 Atomic B5.2.40 IN
Counter BCD/Hex String (10) 10 Atomic B5.2.41 See IP Routing
Address field.
CSI (CAMEL Subscription Information) 2 Atomic B5.2.42 IN
Data Compression 4 Atomic B5.2.43 DS
Data Rate 4 Atomic B5.2.44 DS
Data Volume 6 Atomic B5.2.45 DS
Date and Time 16 Atomic B5.2.46 CEU (seizure), CEU
(release), SSA
TCR (old), TCR (new),
SRR, BBHR, BFTIR,
BFTOR
BS, LaC, SS, TS,
AoC
Default SMS Handling Applied (DSH
applied)
2 Atomic B5.2.47 CSMS
Default SMS Handling Indicator (DSH
Indicator)
Delivery Timestamp
16 Atomic B5.2.49 SMSMO, SMSMT
Destination Routing Address
BCD/Hex String (32)
32 Atomic B5.2.50 IN
Detection Point 4 Atomic B5.2.51 IN
Diagnostic 6 Atomic B5.2.52 MO, MT, Ro, ICG, OGG, Tr,
ICIP, OGIP
Dialled Digits
Number Type (2)
BCD/Hex String (32)
34 Compound B5.2.53 MO
Disconnect Time (of type Date and Time) 16 Atomic B5.2.54 MO, MT GASSP
E Parameter 6 Atomic B5.2.55 AoC (seven fields for
E parameters 1 to 7)
Emergency Service Routing Digits (ESRD)
BCD/Hex String (16)
16 Atomic B5.2.56 LCS
Emergency Service Routing Key (ESRK) 12 Atomic B5.2.57 LCS
Equipment Identity 6 Atomic B5.2.58 CEU
Equipment Type 6 Atomic B5.2.59 CEU
FCI Freeform Parameter 46 Atomic B5.2.60 INC (contains 3
parameter fields).
File Sequence Number
BCD/Hex String (4)
4 Atomic B5.2.61 BFTIR, BFTOR
File Transfer Type 4 Atomic B5.2.62 BFTIR, BFTOR
Freeformat Data 42 Atomic B5.2.63 CC
Functional Number 16 Atomic B5.2.64 Ack
Geographical Location of UE 1 42 Atomic B5.2.65 LCS
Group Call Reference 10 Atomic B5.2.70 Ack
Half Rate in Use (Boolean Type) 2 Atomic B5.2.71 MO, MT
Hexadecimal Id 2 Atomic B5.2.72 See Record Header field
Hot Billing Indicator 2 Atomic B5.2.73 SSA, Ack
IN Call Reference Number
BCD/Full Hex String (18)
IN Dialogue Result 2 Atomic B5.2.75 CSMS
IN Protocol 2 Atomic B5.2.76 CSMS, GASSP, IN
IN Time Stamp1 (of type Date and Time) 16 Atomic B5.2.77 IN
IN Time Stamp2 (of type Date and Time) 16 Atomic B5.2.78 IN
Incoming/Outgoing Metering Class
Incoming
Outgoing
4 Atomic B5.2.79
ICG, ICIP,
OGG, Tr, OGIP
Incoming/Outgoing Route Group
Incoming
Outgoing
4 Atomic B5.2.80
MT, Ro, ICG, OGG, Tr, ICIP,
OGIP
MO, Ro, ICG, OGG, Tr, ICIP,
OGIP
Incoming/Outgoing Trunk Release Time
Incoming
Outgoing
16 Atomic B5.2.81
ICG, ICIP,
Ro, OGG, Tr, OGIP
Incoming/Outgoing Trunk Seizure Time
Incoming
Outgoing
16 Atomic B5.2.82
MT, Ro, ICG, ICIP,
MO, Ro, OGG, Tr, OGIP
Incoming Trunk Group
BCD/Hex String (6)
6 Atomic B5.2.83 MT, Ro, ICG, OGG, Tr, ICIP,
OGIP
LaC
Incoming Trunk Member
BCD/Hex String (6)
6 Atomic B5.2.84 MT, Ro, ICG, OGG, Tr, ICIP,
OGIP
LaC
Information Transfer Capability 2 Atomic B5.2.85 DS
Inter-Exchange/International Carrier (IC/
INC) Call Event Status
4 Atomic B5.2.86 EA
Inter-Exchange/International Carrier (IC/
INC) Prefix
10 Atomic B5.2.87 EA
Interworking Function Trunk Group 6 Atomic B5.2.88 DS (mobile side), DS
(network side)
Interworking Function Trunk Member 6 Atomic B5.2.89 DS (mobile side), DS
(network side)
IP Address Identity BCD/Hex String (8) 8 Atomic B5.2.90 See IP Routing
Address field.
IP Routing Address
IP Address Identity (8)
MSC Id (6)
Counter (10)
24 Compound B5.2.91 GASSP
IP SSP Capability 10 Atomic B5.2.92 GASSP
IWF Activation Timestamp
16 Atomic B5.2.93 DS
IWF Diagnostic Code 4 Atomic B5.2.94 DS
LCS Client Identity
LCS Client Type 4 Atomic B5.2.96 LCS
LCS Diagnostic 2 Atomic B5.2.97 LCS
LCS Initiation Time
LCS Priority Level 4 Atomic B5.2.99 LCS
LCS Record Type 2 Atomic B5.2.100 LCS
LCS Result 4 Atomic B5.2.101 LCS
LCS Termination Time
Local Reference Number 12 Atomic B5.2.103 CC, IN
Location Area Code 12 Atomic B5.2.104 SSA LaC, LO
Logical Network 4 Atomic B5.2.105 Ro, ICG, OGG, Tr, ICIP,
OGIP
Message Reference BCD/Hex String (6) 6 Atomic B5.2.106 SMSMO
Metering Zone 4 Atomic B5.2.107 Ro, ICG, OGG, Tr, ICIP,
OGIP
MGW (Media Gateway) Number 14 Atomic B5.2.108 BICN
MGW Seizure Time
16 Atomic B5.2.109 BICN
MM Event 4 Atomic B5.2.110 LU
Module Code 4 Atomic B5.2.111 All modules
MS Classmark 16 Atomic B5.2.112 MO, MT, SMSMO, SMSMT,
SSA
MSC Address
BCD/Hex String (22)
28 Compound B5.2.113 NCR
MSC Id BCD/Hex String (6) 6 Atomic B5.2.114 See IP Routing
Address field.
MSC Number
BCD/Hex String (22)
SMSMO, SMSMT, ICIP,
OGIP, SSA, LCS, Ack
LaC, LO
MSC/MGW Number
BCD/Hex String (22)
28 Compound B5.2.116 CEU
Network Call Reference Number
18 Atomic B5.2.117 NCR
New AN 2 Atomic B5.2.118 LU
New Cell-SAC Id 6 Atomic B5.2.119 LU
New LAC 12 Atomic B5.2.120 LU
New MSC Id
BCD/Hex String (22)
28 Compound B5.2.121 LU
Number of Fax Pages BCD/Hex String (4) 4 Atomic B5.2.122 DS
Number Type 2 Atomic B5.2.123 Generic field type used to identify types of numbers.
Numbering Plan Identifier 6 Atomic B5.2.124 Field used in number type fields.
Off Air Call Setup Boolean Type 2 Atomic B5.2.125 MO, MT
Off-Board IN Service Identifier 4 Atomic B5.2.126 IN
Off-Board IN Service Indicator 4 Atomic B5.2.127 IN
Old AN 2 Atomic B5.2.128 LU
Old Cell-SAC Id 6 Atomic B5.2.129 LU
Old LAC 12 Atomic B5.2.130 LU
Old MSC Id
BCD/Hex String (22)
Operation History 26 Atomic B5.2.132 CSMS
Operation Indication 2 Atomic B5.2.133 IN
Original Calling Number
Number Type (2)
BCD/Hex String (32)
40 Compound B5.2.134 GA
Outgoing Trunk Group
BCD/Hex String (6)
6 Atomic B5.2.135 MO, Ro, ICG, OGG, Tr, ICIP,
OGIP
Outgoing Trunk Member
BCD/Hex String (6)
6 Atomic B5.2.136 MO, Ro, ICG, OGG, Tr, ICIP,
OGIP
Partial Record Event Code 4 Atomic B5.2.137 PI
Partial Record Reason 4 Atomic B5.2.138 PI
Partial Record Reference Number
BCD/Hex String (8)
8 Atomic B5.2.139 PI
Partial Record Sequence Number
BCD/Hex String (6)
6 Atomic B5.2.140 PI
Party to Charge 4 Atomic B5.2.141 CC
Patch Identity 12 Atomic B5.2.142 Pa
Ported Status 2 Atomic B5.2.143 MNP
Positioning Data 28 Atomic B5.2.144 LCS
Post-Translated Called Party Number
Number Type (2)
BCD/Hex String (32)
Pre-Translated Called Party Number
Number Type (2)
BCD/Hex String (32)
Priority Call Cause 4 Atomic B5.2.147 Ack
Priority Call Duration 10 Atomic B5.2.148 Ack
Priority Call Tag 2 Atomic B5.2.149 Ack
Priority Level 4 Atomic B5.2.150 Ack
Priority Release Time 12 Atomic B5.2.151 Ack
Privacy Notification 2 Atomic B5.2.152 LCS
Privacy Override 2 Atomic B5.2.153 LCS
Query Method 2 Atomic B5.2.154 MNP
Rate Adaptation 2 Atomic B5.2.155 DS
Record Count BCD/Hex String (10) 10 Atomic B5.2.156 BFTOR
Record Header
Hexadecimal Identity (2)
Release Id (6)
Structure Code (6)
Call Type Code (4)
18 Compound B5.2.157 All call records All switch/file records
Record Number 12 Atomic B5.2.158 All Call Detail Records. TCR, SRR, BFTIR,
BFTOR
Record Time (of type Date and Time) 16 Atomic B5.2.159 Ack
Recording Entity
BCD/Hex String (22)
Recording Office Identity 8 Atomic B5.2.161 All switch/file records
Recording Office Type / Sensor Type 4 Atomic B5.2.162 All switch/file records
Release Id 6 Atomic B5.2.163 See Record Header field
Release Time (of type Date and Time) 16 Atomic B5.2.164 MO, MT
Requested QoS 12 Atomic B5.2.165 LCS
Requesting Mobile Location Centre (MLC)
BCD/Hex String (20)
26 Compound B5.2.166 LCS
Result Indicator 4 Atomic B5.2.167 SSA SS
RNC ID
BCD/Hex String (6)
6 Atomic B5.2.168 LaC
Roaming Number
Number Type (2)
BCD/Hex String (22)
30 Compound B5.2.169 Ro LaC
Routing Number BCD/Hex String (26) 26 Atomic B5.2.170 MNP
SCF ID BCD/Hex String (22) 22 Atomic B5.2.171 GASSP
SCF ID / ETC Parm1 34 Atomic B5.2.172 IN
SCP Address BCD/Hex String (22) 22 Atomic B5.2.173 CSMS, GASSP, IN
Sensor Identity 8 Atomic B5.2.174 All switch/file records
Served IMEI 22 Atomic B5.2.175 LCS
Served IMSI
Number Type (2)
BCD/Hex String (22)
Served MSISDN
Number Type (2)
BCD/Hex String (22)
30 Compound B5.2.177 LCS, LU
Served Party BCD/Hex String (16) 16 Atomic B5.2.178 LCS
Service Centre
BCD/Hex String (22)
28 Compound B5.2.179 SMSMO, SMSMT CSMS
Service Key 12 Atomic B5.2.180 CSMS, IN
SMS Message Type 2 Atomic B5.2.181 SMSMO
SMS Release Cause Value 4 Atomic B5.2.182 CSMS
SMS Result (of type Diagnostic) 6 Atomic B5.2.183 SMSMO, SMSMT
SMS Start Time (of type Date and Time) 16 Atomic B5.2.184 CSMS
SMS Stop Time (of type Date and Time) 16 Atomic B5.2.185 CSMS
SMS Timestamp (of type Date and Time) 16 Atomic B5.2.186 SMSMO, SMSMT
SMS Validity Period 18 Atomic B5.2.187 SMSMO
Structure Code 6 Atomic B5.2.188 See Record Header field
Study Indicator 2 Atomic B5.2.189 All Call Detail Records
Subscriber Service 6 Atomic B5.2.190 TC
B5.2.1 Access Media Type
This field captures the type of connection between the Media Gateway (MGW) and the Base
Station System (BSS) in case of a GSM network and between the MGW and the Radio Network
Controller (RNC) in the case of a UMTS network. The access media type for the GSM network is
Time Division Multiplexing (TDM) circuits. For the UMTS network the access media type can be
ATM Adaptation Layer 2/Asynchronous Transfer Mode (AAL2/ATM). For the bearer
corresponding to BICC calls the access media type could be TDM/ATM/Internet Protocol (IP). The
access media type is captured from the RAB assignment response message during call
establishment. The field encoding is shown in Table 66.
Supplementary Service Action 2 Atomic B5.2.191 SSA SS
Supplementary Service Code 4 Atomic B5.2.192 SSA SS, AoC
Supplementary Service Parameter
BCD/Hex String (32)
32 Atomic B5.2.193 SSA SS
Switch Restart Type 2 Atomic B5.2.195 SRR
System Type 2 Atomic B5.2.194 LCS
Tariff Class 6 Atomic B5.2.196 TC
Teleservice 4 Atomic B5.2.197 TS
Terminating Location 16 Atomic B5.2.198 OA
Trunk Usage Reason 4 Atomic B5.2.199 TU
Type of Carrier Identification Code (CIC) 2 Atomic B5.2.200 EA
Unused Number 1
Number Type (2)
BCD/Hex String (32)
40 Compound B5.2.201 PaI
Unused Number 2
Number Type (2)
BCD/Hex String (32)
40 Compound B5.2.202 PaI
Unused Timestamp 1
16 Atomic B5.2.203 PaI
Unused Timestamp 2
16 Atomic B5.2.204 PaI
Update Result 4 Atomic B5.2.205 LU
Update Time (of type Date and Time) 16 Atomic B5.2.206 LU
Field Used In:
Module: BICN.
Character(s) Description Values
1 Access Media Type 0 - IP
1 - AAL2
2 - TDM
2 Sign Character C
Default: FC
Example:
Access Media Type (IP): 0C
Table 66 Access media Type atomic data field
B5.2.2 Access Network
This field differentiates between a GSM (2G) or UMTS (3G) radio access interface and services.
For GSM services the location information available to the MSC is generally in the form of the
Global Cell Identifier (GCI). Both routing information and services location information are in GCI
format. In UMTS, location information is available to the MSC in the form of a Service Area
Identifier (SAI) or GRNCId (Global RNCId). Routing uses the GRNCId format while services use
the SAI. The field encoding is shown in Table 67.
The access network field is used with the cell-sac id field (B5.2.31 on page 144) which provides
information about the cell identity or service area code being used to access the network. If the cell-
sac id field is defaulted, the value of the access network field has no meaning.
NOTE If the access network information is not available, the field defaults to value 0C.
B5.2.3 Additional Information
This field identifies the type of call being made. The main use of the field is to record type I and
type II emergency calls. The identity of the mobile station making the emergency call is provided in
the mobile originated attempt call record: either its MSISDN is contained in the calling number
field or its IMSI is contained in the calling party field. The MSISDN or IMSI may be mapped from
the mobile stations TMSI. Additionally, emergency call records are directed to the hot billing
stream if it is in use, otherwise they are directed to the normal billing stream. The field encoding is
shown in Table 68.
Field Used In:
Records: SSA. Modules: LaC, LO.
Character Description Values
1 Access Network 0 - GSM
1 - UMTS
2 Sign Character C
Default: 0C.
Example:
Access Network (GSM Network): 0C
Table 67 Access network atomic data field
Field Used In:
Records: MO, MT.
1-2 Unused FF
3 Type of call 1 - Type I emergency call
2 - Type II emergency call
F - Non-emergency call
4 Sign Character C
Default: FFFC
Example:
Type 1 emergency call - FF1C
Table 68 Additional information atomic data field
B5.2.4 Advice of Charge Parameter Reason
This field indicates whether the Advice of Charge (AoC) parameters are the initial set sent by the
MSC to the mobile station, or an updated set sent, e.g. when the tariff band changes during a call.
The field also shows whether the AoC supplementary service (SS), or the CAMEL (GSM/UMTS
intelligent networking) AoC service was used. The field encoding is shown in Table 69.
B5.2.5 Age of Location Information
This field captures the age of the location information provided as the result of a location service
(LCS). It indicates when the location estimate was last updated and is measured in minutes. If the
information is current, the field contains its default value. The field has an upper value of 65535
with a wrap around to zero after reaching this limit. The encoding of the field is shown in Table 70.
B5.2.6 Answer Time
This field shows the time at which the call was answered or at which charging commences. For
Mobile Terminated calls the Answer time is defined as the time at which the CONNECT message is
received from the called party. For the Mobile Originated Record, Incoming Trunk Records
(Gateway/Intra-PLMN) and Outgoing Trunk records (Gateway/Intra-PLMN/Transit), the Answer
time is the time at which the Answer
1
message is received at the MSC.
Field Used In:
Module: AoC.
1 Reserved 0
2-3 Reason 00 -Initial
01 - Subsequent
02 - IN Initial
03 - IN Subsequent
4 Sign Character C
Default: 000C
Example:
AoC Parameter Reason - 000C
Table 69 Advice of charge parameter reason atomic data field
Field Used In:
Record: LCS.
1-5 Location Estimate 00000 - 65535
6 Sign Character C
Default: FFFFFC
Example:
Age of Location: 00012C
Table 70 Age of location information atomic data field
This field also captures the time at which the assisting SSP (an MSC/SSP) forms a connection to its
intelligent peripheral (IP) during a CAMEL Phase 2 service. To form the connection, the assisting
SSP sends the IP an ISUP initial address message (IAM). The IP responds with an ISUP answer
message. The Assisting SSP sends an ISUP answer message to the initiating SSP which is going to
use the facilities of the IP. The assisting SSP then sends a CAMEL PlayAnnouncement or
PromptAndCollectUserInformation message to the IP. The IP acknowledges this by sending the
assisting SSP a CAMEL AssistRequestInstructions message. This confirms that there is a TCAP
connection between the IP and assisting SSP to carry the CAMEL signalling. The assisting SSP
captures the answer time when both the ISUP and TCAP connections are established. The
connections are not formed in a strict order, so the assisting SSP captures the timestamp when the
last of the two connections is formed.
The Answer Time field is encoded using the 16 character date and time field atomic field as
described in Section B5.2.46 on page 153.
B5.2.7 Auxiliary Record Header
This field captures additional information required in the non call related billing and accounting
records. It consists of four fields as shown in Table 71.
B5.2.8 Backbone Media Type
This field captures the Backbone Media Type which represents the edge to edge connection
between the call servers. The backbone media type can be of the form IP or AAL2 and is captured
from the H.248 Add Reply message for BICC calls and the RAB assignment response for mobile
calls. The field encoding is shown in Table 72.
1.
For billing purposes, we use the generic term Answer message as an indication that the call is answered. The
actual message received by the MSC when a call is answered is dependent on the terminating agent signalling
type, for example ANM for ISUP, Connect for mobile, etc.
Field Used In:
Records: MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP. Module: GASSP.
Field Used In:
Switch/Billing File Records: TCR, SRR, BBHR, BFTIR, BFTOR.
Field Type Number of Characters Detailed Reference
Sensor Type 4 B5.2.162
Sensor Identity 8 B5.2.174
Recording Office Type 4 B5.2.162
Recording Office Identity 8 B5.2.161
Table 71 Auxiliary record header data field
B5.2.9 BCD or Full Hex String
This is a generic atomic field type used by other fields to capture a string of BCD or hex characters.
It differs from the BCD/Hex String (N) field as it allows Hex F to be a valid value. It can contain up
to 31 BCD/hex characters followed by the sign character. The field encoding is shown in Table 73.
NOTE As Hex Fs are valid data values, there is no default value. Any applications
which analyse the data in this field must bear this in mind.
B5.2.10 BCD or Hex String(N)
This is a generic atomic field type used by other fields to capture a string of BCD or hex characters.
It can contain up to 31 BCD/hex characters followed by the sign character. The field encoding is
shown in Table 74.
Field Used In:
Module: BICN.
1 Backbone Media Type 0 - IP
1 - AAL2
2 Sign Character C
Default: FC
Example:
Backbone Media Type (AAL2): 1C
Table 72 Backbone Media Type atomic data field
Generic field type used by other fields.
1 - (N-1) BCD or Hex Characters {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F}
N Sign Character C
Default: Not applicable. When captured only valid values shall be recorded.
Example:
BCD or Full Hex String(6): 12345C
Table 73 BCD or full hex string atomic data field
1 - (N-1) BCD or Hex Characters {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E}
N Sign Character C
Default: FFF...FC
Example:
BCD or Hex String(6): 12345C
Table 74 BCD or hex string atomic data field
B5.2.11 Bearer Service
This field together with the Data rate field defines the Bearer service. The information is obtained
from the Bearer Capability Information element contained in the access signalling. The field
encoding is shown in Table 75.
NOTE Bearer Service Group codes and Compound Bearer Service Group codes are
defined in accordance with 3GPP TS 29.002. The bearer service rate is indicated
in a separate field, the Data Rate atomic data field (B5.2.44 on page 152).
B5.2.12 Block Count
This field is defined as a value in the range 00001 to 99999 with wrap around from 99999 to 00001.
It is encoded as a six character BCD/hex string as defined in Section B5.2.10 on page 127.
B5.2.13 Block Number
This field is defined as value in the range 00001 to 99999 with wrap around from 99999 to 00001. It
is encoded as a six character BCD/hex string as defined in Section B5.2.10 on page 127.
Field Used In:
Module: BS.
1-2 Spare 00 - Spare
3 Bearer Service Group 0 - All Bearer Services
2 - Circuit Data Asynchronous (CDA)
3 - Circuit Data Synchronous (CDS)
4 - Pad Access CA
5 - Data PDS
6 - Alternate Speech-Data CDA
7 - Alternate Speech-Data CDS
8 - Speech Followed by Data CDA
9 - Speech Followed by Data CDS
Compound Bearer Service Group
a
a. Compound Bearer Service Groups are only applicable to call independent supplementary service
operations (i.e. they are not used in InsertSubscriberData or in DeleteSubscriberData messages).
A - All Data Circuit Asynchronous
B - All Data Circuit Synchronous
C - All Asynchronous Services
D - All Synchronous Services
4 Sign Character C
Example:
Bearer Service (Circuit Data Asynchronous): 002C
Table 75 Bearer service atomic data field
Field Used In:
Record: BFTOR.
Field Used In:
Record: BBHR.
B5.2.14 Boolean Type
This is a generic field type used by other fields to indicate the boolean conditions true or false. The
field encoding is shown in Table 76.
B5.2.15 Call Duration
In all but the Common equipment usage record the call Duration is the chargeable duration of a call
in seconds. For successful calls this is the chargeable (or accountable duration) from answer to
release (or disconnect) of the traffic channel (or relevant resource). Unanswered calls will have a
call duration of zero. In the Common equipment usage record the call duration captures the total
duration of usage of a particular piece of equipment e.g. a conference circuit. The field encoding is
shown in Table 77.
NOTE 1 The call duration is calculated by the billing system. However, operators can use
the raw data in the billing records, such as the connect, answer and disconnect
times, to derive their own call duration.
(continued)
1 Condition 1 - Stated Condition is True
0 - Stated Condition is False
2 Sign Character C
Default: 0C
Example:
Boolean Type (Half Rate in Use): 1C
Table 76 Boolean type atomic data field
Field Used In:
Records: MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP, CEU.
1 Note 2 Granularity 0 - Seconds
1 - Tenths of a Second
2 Note 3 Rounding Indicator 0 - Rounded Up
1 - Rounded Down
2 - Rounded to the Nearest Integer
3 Sign Character C
4 - 11 Call Duration {00000000 - 09994239}
12 - 13 Spare 00
14 Sign Character C
Default: FFFFFFFFFFFFFC
Example:
Call Duration rounded up in seconds (120Seconds): 00C0000012000C
Table 77 Call duration atomic data field
NOTE 2 The granularity of the call duration is set by the office parameter GSM_
CALL_DURATION_GRANULARITY. If the granularity is set to tenths of a
second this is indicated by character 1 having the value 1. In this case character
11 contains the tenths of a second value.
NOTE 3 If the call duration is set to have a granularity of seconds, character 2 captures
the rounding method used to determine the call duration. The office parameter
GSM_CALL_DURATION_ROUNDING determines the rounding method used.
Rounded up is the recommended method. In this case, characters 4 to 11 capture
the call duration in seconds.
If the call duration granularity is set to be in tenths of seconds, the setting of
character 2 has no meaning. That is no rounding is applied and the call duration
is measured down to tenths of a second.
NOTE 4 If a call terminates to a recorded announcement, the MSC does not capture the
answer time stamp and the call duration is set to 0 (zero). This prevents
subscribers from being billed for these announcements.
NOTE 5 In invalid long call duration records, the Call Duration field is set to zero
(00C0000000000C). The handling of these invalid long duration records is
determined by the setting of the office parameter GSM_LONG_
CALL_TEARDOWN (B3.8.1 on page 49).
NOTE 6 In a call where the Explicit Call Transfer service is invoked, the Call Duration
may differ between the mobile originated and terminated call records (MOCs
and MTCs). The Call Duration in the MOCs captures the time portion before the
call was transferred, while the Call Duration in the MTCs captures the entire call
duration. For example consider a scenario where mobile A calls mobile B, puts B
on hold, then calls mobile C and invokes ECT. At this time mobile A drops out
of the call while mobile B and C continue talking. Assuming no roaming or call
forwarding occurs, four records are generated: two MOCs (A-B, A-C) and two
MTCs (A-B, A-C). Consider some example times:
- A calls B and B answers at 10 o'clock;
- A puts B on hold then calls C and C answers at 10:02;
- A invokes ECT and drops out of the call at 10:03;
- B and C continue and finish talking at 10:09
The Call Duration in the MOCs is 3 minutes for A-B and 1 minute for A-C.
The Call Duration in the MTCs is 9 minutes for A-B and 7 minutes for A-C.
The purpose of this calculation schema is to provide the customer with a view of
the call portion before the call is transferred (MOCs) as well as for the entire
billing period (MTCs), so that the customer can use the information flexibly. As
a consequence of this difference in Call Duration, the partial billing behaviour
may be affected. Please see the NOTE on page 63 in Section B3.4.4 for more
information on partial billing for ECT.
B5.2.16 Call Forward Indicator
This field is a simple boolean indicator which indicates whether or not a call is forwarded. It is
encoded as a boolean type atomic field as described in Section B5.2.14 on page 129.
The records generated during call forwarding are best described using the terminology A calls
mobile station B (MS B) who forwards to C. When the Call Forward Indicator is set in a Mobile
Originated Call Forwarding Attempt record the information contained pertains to the forwarded
part of the call for the leg from MS B to C. Specifically the Supplementary Services information
module appended to the structured record will contain the call forwarding information.
Where the call forwarding takes place at a terminating entity a Mobile Terminated Call Forwarding
Attempt record is produced with the Call Forward Indicator set for the leg from A to MS B. Again a
Supplementary Services information module appended to the structured record will contain the call
forwarding information.
B5.2.17 Call Indicator
This field shall capture a charge indication. This charge indication shall be derived by called digit
analysis and from the charge information received in the backward direction. If called digit analysis
reveals, No indication then the Charge indicator received in the backward direction shall be used
to populate the Call indicator field. If called digit analysis reveals, Called Party Charge then this
value shall be used in the Call Indicator field in all cases except when the Charge indicator received
in the backward direction indicates No Charge. In this case the value for No Charge shall be
used to populate the Call Indicator field. The same principle shall also apply when called digit
analysis reveals, Calling Party Charge i.e. the result of the called digit analysis shall be used in all
circumstances except when the Charge indicator received in the backward direction indicates No
Charge. Finally, if called digit analysis reveals, No Charge then regardless of the charge
indication received in the backward direction the value, No Charge shall populate the Call
Indicator field. For avoidance of doubt if a spare Charge indicator value is received in the backward
direction or if no charge indications are possible through the provisioned signalling system then it
shall be the result of called digit analysis that will be used to populate the Call Indicator field. The
Call indicator consists of a single field as shown in Table 78.
Field Used In:
Records: MO, MT.
NOTE 1 The last Charge indicator value received in the backward messaging shall be
used in the above algorithm.
NOTE 2 The Call Indicator field in a Mobile terminated call attempt shall always be set to
the default value, No indication unless the Call record type indication function
is active. Please see B3.6.2 for information on this optional functionality.
NOTE 3 In invalid long call duration records, the Call Indicator field is set to the value
no charge (000001C). The handling of these invalid long duration records is
determined by the setting of the office parameter GSM_LONG_
CALL_TEARDOWN (B3.8.1 on page 49).
B5.2.18 Call Reference
This field contains a non-unique integer value allocated locally at an MSC. This number shall not
have any global significance. One possible use of this number may be in the correlation of related
records at the same MSC i.e. the roaming, MOC etc. call records of a particular call shall have the
same call reference value. However because the number is non-unique only through the use of the
Call reference in combination with a date and timestamp could a more rigid guarantee of correlation
be ensured. This field is defined as a value in the range 000000 to 0262143 with wrap around from
0262143 to 000000. It is encoded as an eight character BCD/hex string as defined in Section
B5.2.10 on page 127.
B5.2.19 Call Type Code
This field captures information about the type of call and it also identifies the type of billing record
being generated. This field is included in other fields in a call record (for example it is one of the
fields in the Record Header field shown in Section B5.2.157). The field encoding is shown in Table
79.
Field Used In:
Records: MO, MT, Ro.
1-6 Reserved 000000
7 Call Indicator 0 - No Indication
1 - No Charge
2 - Charge
3 - Called Party Charge
4 - Calling Party Charge
8 Sign Character C
Default: 0000000C
Example:
Call Indicator (No Charge): 0000001C
Table 78 Call indicator atomic data field
Field Used In:
Records: All Call Detail Records.
B5.2.20 Called Equipment (or Served Equipment)
This field contains the international mobile equipment identity (IMEI) or IMEI Software Version
(IMEISV) of the called partys mobile equipment. The structure of the IMEI and IMEISV are
defined in 3GPP TS 23.003. In a call forwarding scenario, the Mobile Terminated Call Forwarding
Attempt and Mobile Originated Call Forward Attempt records have the call forward indicator field
set to TRUE. These records contain a value for the called equipment if the MSC attempts to connect
to the originally called party before encountering the forwarding condition. The field encoding is
shown in Table 80.

Field Used In:
Records: All Call Detail Records. All Switch/Billing File Records.
1-3 Call Type Code 001 - Mobile Originated Call
002 - Mobile Terminated Call
003 - Location Update Call
004 - Supplementary Service Action
005 - SMS Mobile Originated Call
006 - SMS Mobile Terminated Call
007 - File Transfer Record
008 - Time Change Record
009 - Switch Restart Record
010 - Block Header Record
011 - Incoming Trunk Call
012 - Outgoing Trunk Call
014 - Roaming Call
015 - Common Equipment
016 - Acknowledgement Call
017 - Location Service (LCS)
4 Sign Character C
Example:
Call Type Code (Mobile Originated Call): 001C
Table 79 Call type code atomic data field
Field Used In:
Records: MT, SMSMT.
1-5 Unused FFFFF
6-19 IMEI {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F}
20-21 Software Version Number (SVN) {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F}
22 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFC
Examples:
Valid IMEI without SVN: FFFFF12345678901234FFC
Invalid IMEISV with invalid characters: FFFFF1234567890ABCD56C
Invalid short IMEI/IMEISV: FFFFF1234567890FFFFFFC
Invalid IMEISV whose length exceeds 16 digits, or IMEI whose length exceeds 15 digits: FFFFFFFFFFFFFFFFFFFFFC
Table 80 Called equipment (or served equipment) atomic data field
B5.2.21 Called IMSI Number
This field contains the called partys IMSI as returned to the MSC by the Mobile Number
Portability Signalling Relay Function (MNP-SRF, the MNP portability database). During a call
involving MNP, the MSC sends the MNP-SRF a MAP SendRoutingInfo (SRI) message to find the
numbers ported status (ported, not ported, ported in). The MNP-SRF sends this information to the
MSC in the SRI Ack message. The MSC uses the information in this message to populate this field.
It is encoded as a 26 character BCD/hex field as defined in Section B5.2.10 on page 127.
If the subscriber has ported out of the network, i.e. moved to another service provider, the Called
Party IMSI field contains the default value. If the number is ported in, or has not been ported, this
field captures the IMSI.
B5.2.22 Called Number (or Served Number)
The called number is the translated number that the MSC uses for routing a call. It consists of three
fields as shown in Table 81.
Sometimes a feature or a service replaces the original dialled number with a new called number;
sometimes a feature or a service requires the MSC to invoke translations more than once before
routing a call. For example, when the Gateway MSC (GMSC) interrogates the HLR for routing
information (Send Routing Information (SRI)) to terminate to a mobile subscriber, the GMSC will
replace the original dialled MSISDN with the Mobile Subscriber Roaming Number (MSRN) or call
forwarding address (CFA) that it receives in the SRI response. In general, the called number field
reflects the last translated number, which is used by the MSC for routing. However, this is not
always the case. For example, in certain mobile to mobile calls, the MSC receives call setup
information from the calling party, interrogates the HLR for routing information to the called party
and routes the call to the MSC currently serving the called party. For these calls, the Mobile
Originated Record and the Roaming Record will contain the translated MSISDN in the Called
Number field rather than the MSRN which is used for routing.
When inter-MSC handovers occur, the translated routing number will be placed in the called
number field, and the number type is set to None.
The following sections provide more details on the information captured in the called number field
in different billing records.
Field Used In:
Module: MNP.
Field Used In:
Records: MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, Ack.
Number Type 2 B5.2.123
Numbering Plan Identifier 6 B5.2.124
BCD or Hex String (32) 32 B5.2.10
Table 81 Called (or served) number data field
B5.2.22.1 Mobile Originated Record
In the mobile originated record, the Called Number field reflects the number resulting from
universal translations (that is the number derived after the dialled digits received from the mobile
station have been through translations). The Nature of Address (NOA) in the Numbering Plan
Identifier (NPI) part of this field is derived from translations (see B5.2.22.6) and the Number Type
usually reflects a value of None. However, if the dialled digits are for a mobile subscriber (an
MSISDN) and the GMSC serving the originating mobile interrogates the HLR for routing
information to the called mobile (using the SRI message), the NOA and NPI are retrieved from
datafill in table GSMDEFS. The Number Type in this case reflects MSISDN. If table GSMDEFS
is not datafilled, the NOA and NPI values are derived from the default entry in the table. If a feature
or a service changes the called number, the Number Type for the new called number may not reflect
MSISDN. For example, if the HLR returns a forwarding number to a destination in the PSTN/
ISDN, the new called number captured will not be an MSISDN.
B5.2.22.2 Mobile Terminated Record
In the standard mobile terminated record, the Called Number field reflects the MSISDN of the
terminating mobile subscriber. The Number Type is MSISDN; the NPI is ISDN number; and the
NOA is International number. In cases of various types of redirection, it is possible that the Called
Number is derived from customer translations in which case the NPI and NOA would be based on
values received in signalling and customer datafill.
B5.2.22.3 Roaming Record
In a roaming record, the Called Number field reflects the MSISDN of the terminating mobile
subscriber after it has been translated by the GMSC. The Number Type is MSISDN; the NPI and
NOA are retrieved from datafill in table GSMDEFS. The MSRN used to route the call to the
terminating party is captured in the roaming number field of the record.
B5.2.22.4 Incoming (Gateway/Intra-PLMN) Trunk and Outgoing (Gateway/Intra-
PLMN/Transit) Trunk Record
In the incoming trunk and outgoing trunk record types, the Called Number field reflects the called
party number resulting from universal translations. This is the number employed by the GMSC for
routing. The NOA Indicator in the Numbering Plan Identifier part of this field is derived from
translations (see B5.2.22.6). The Number Type usually reflects a value of None. The only other
value the called number can have is the number type of MSRN (as opposed to MSISDN) if the
GMSC interrogates the HLR for routing information (using the SRI message).
In the case of Inter-MSC Handover, the Called Number field in the outgoing trunk record generated
on the anchor MSC and in the incoming trunk record generated on MSC-B, reflects the translated
Handover Number and the number type field reflects a value of None.
B5.2.22.5 Short Message Service Mobile Terminated Record
In the short message service mobile terminated record, the Called Number field reflects the
MSISDN of the subscriber receiving the short message. The format of the Called Number, in this
case, is in international format. The NOA reflects international number, the NPI reflects ISDN
Number, and the Number Type reflects MSISDN.
B5.2.22.6 Determination of the Nature of Address (NOA)
In signalling, an NOA value can be associated with the called number, but translations can modify
this NOA value. Please refer to sections B5.2.22.1 to B5.2.22.5 for information on the source of the
number in the called number field. The billing record reflects the NOA value after translations. On
the MSC the following translation selectors (in the order listed) can alter the NOA of the translated
number:
The CDN selector
The call profile selector with the international (INTL) option
The CLASS selector (see note)
For example, the NOA of the called number field in a mobile originated call attempt record can
indicate an international, national, or network-specific number if the translation of the called
number encounters the CDN option:
NOTE If datafilled, the CLASS selector may be set to one of the values
INTERNATIONAL_CLASS, INTL_OP_ASSISTED_CLASS,
INTERCONTINENTAL_CLASS, CONTINENTAL_CLASS, or LOCAL_
CLASS. Networks are strongly encouraged to use the CDN selector rather than
the CLASS selector as the means for defining the NOA of a translated number.
For more information on these translations selectors, refer to the Translations Guide [22] and the
ANSI ISUP translations enhancements [23].
B5.2.22.7 Short Message Service - Mobile Originated Record (SMS-MO)
In the SMS-MO record, the Called Number field reflects the MSISDN of the mobile intended as the
recipient of the SM by the originating mobile. The format of the Number Type reflects MSISDN.
This information is useful if the called number is changed by SCP in the connectSMS operation.
The changed number is captured as the modified destination subscriber number in the appended
CAMEL SMS information module.
CDN Option Nature of Address Indicator (Section B5.2.124)
INTL 1 - International Number
NATL 2 - National Significant Number
LOCAL 3 - Network Specific Number
B5.2.23 Called Party (or Served Party)
This field contains the international mobile subscriber identity (IMSI) of the terminating mobile
subscriber. In the CAMEL SMS information module, this field contains the MSISDN of the
destination subscriber. This field is captured when the original message destination address sent by
the MSC/SSP in the InitialDP SMS message is altered in the Connect SMS message returned by the
gsmSCF. It consists of three fields as shown in Table 82.
NOTE In this data field the Number Type is set to indicate that the BCD or Hex String
contains an IMSI value. The Numbering Plan Identifier is set to the default value
given in the detailed reference section.
B5.2.24 Called Subscriber Category
This field defines the priority status of the called mobile subscriber. This value is obtained from the
Home Location Register. The field encoding is shown in Table 83.
Field Used In:
Records: MT, Ro, SMSMT. Module: CSMS.
Table 82 Called (or served) party data field
Field Used In:
Record: MT.
1-3 Category 000 - Unknown
001 - French
002 - English
003 - German
004 - Russian
005 - Spanish
006 - Spare language 1
009 - Reserved
010 - Ordinary
011 - Priority
012 - Data (voiceband)
013 - Test
015 - Payphone
016 - Fixed access
017 - 223 Categories 17 to 223
224 National Use 1/Category 224
225 - Category 225
(continued)
Table 83 Called subscriber category atomic data field
B5.2.25 Calling Equipment (or Served Equipment)
This field contains the international mobile equipment identity (IMEI) or IMEI Software Version
(IMEISV) of the calling partys mobile equipment. The structure of the IMEI and IMEISV are
defined in 3GPP TS 23.003. In a call forwarding scenario, the Mobile Originated and Terminated
Call Attempt records have the call forward indicator set to TRUE and do not contain a value for
calling equipment. The Supplementary Service Action record contains a default value for this field.
The field encoding is shown in Table 84.
226 National Use 2/National Security Emergency Preparedness (NSEP)
227 - Category 227
229 - Category 229
231 - Category 231
233 - Category 233
235 - Category 235
237 - Category 237
239 - Category 239
240 - Ordinary no charge
241 - Category 241
243 - Category 243
244 - Priority no charge
245 - Category 245
247 - Category 247
249 - Category 249
251 - Category 251
252 National Use 15
253 - Category 253
255 - Reserved
4 Sign Character C
Default: FFFC
Example:
Called Subscriber Category (Ordinary): 010C
Table 83 Called subscriber category atomic data field
NOTE The MSC captures the IMEI when it is available. This availability depends upon
the nature of the mobile station in question. For GSM phase 1 mobiles the value
is available when the MSC implicitly performs an IMEI identity request. For
phase 2 mobiles the value may be available at all times since an identity request
may be performed via the ciphering mode setting message exchange. When the
IMEI is obtained via this mechanism then the MSC shall include it.
B5.2.26 Calling Number (or Served Number)
In the mobile originated record, the Calling Number field reflects the MSISDN of the originating
mobile. In the Common Equipment Usage Record, the Served Number field contains the MSISDN
of the mobile subscriber requesting a multi-party service. In the Short Message Service Mobile
Originated (SMS-MO) record, the Calling Number field reflects the MSISDN of the subscriber
sending the short message. In all of these records, the Number Type field always reflects
MSISDN. In all other call records defined for the MSC, the Calling Number contains the number
of the calling party, if available through signalling. This number may or may not be an MSISDN
value. For example, for incoming ISUP trunks, the Calling Number is taken from the Calling Party
Number parameter in the Initial Address Message (IAM). In this case, the Number Type will reflect
a value of None. The Calling Number field consists of three fields as shown in Table 85.
NOTE 1 The Calling Number field may contain a default value in the Mobile Terminated
Record, the Roaming Record, and the Incoming Trunk and Outgoing Trunk
records. This is because the calling number is an optional parameter in signalling
messages, e.g. in the incoming ISUP Initial Address Message (IAM), and so may
not be provided.
(continued)
Field Used In:
Records: MO, SMSMO, SSA.
1-5 Unused FFFFF
6-19 IMEI {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F}
22 Sign Character C
Examples:
Table 84 Calling equipment (or served equipment) atomic data field
Field Used In:
Records: MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, CEU, SSA, Ack.
Table 85 Calling (or served) number data field
NOTE 2 In call redirection scenarios, the Calling Number captured in the originating and
terminating records for the redirecting leg of the call (the Mobile Originated Call
Forwarding Attempt record and the mobile terminating or outgoing trunk record)
is usually populated with the redirecting number, if available. In the case where
redirection has occurred, but the redirecting number is not available in the
incoming message and the redirection count is one, the MSC can capture the
original called number in the Calling Number field of the following records:
Mobile Terminated Call Attempt, Roaming Call attempt, Incoming Gateway
Call Attempt, Outgoing Gateway Call Attempt, Transit Call Attempt, Incoming
Intra-PLMM Trunk Record and the Outgoing Intra-PLMN Trunk Record.
Operators can also use an office parameter to have the original calling number
captured in the Calling Number field when the redirecting number and the
original called number are missing from the call setup signalling during call
redirection. If the office parameter USE_OCGN_IN_CDR_IF_NO_RDGN_
OCN is on, the original calling number is captured in the Calling Number field
of the Incoming Gateway Call Attempt record or the Incoming Intra-PLMN
Trunk record.
In some administrations, the calling party is billed for the forwarded leg. In this
case the office parameter USE_ORIGINAL_CGPN_FOR_BILLING in table
OFCVAR can be used to specify that the calling number and not the redirecting
number is captured in the billing records. Note that if the office parameter is
switched on and the calling number is not contained in the signalled information,
the calling number field in the billing record is not populated.
Software Optionality Control (SOC) on the MSC determines which optional
software modules the operator uses. If the GSM Generic Address Info SOC is
on, it overrides the setting of the USE_ORIGINAL_CGPN_FOR_BILLING
office parameter. In this case, the calling number field captures the redirecting
number in call redirection scenarios regardless of the setting of the office
parameter.
For information on the office parameters and SOCs in this note, and the ways in
which they might interact with each other to sections B3.8.1 and B3.8.2.
NOTE 3 The calling number captured for I-ISUP (Australian interconnect ISUP)
connections and in Australian networks may contain a leading 0 (zero) before the
national significant number (0+NSN format).
NOTE 4 Some administrations require that directory numbers (DNs) are in national
format, even for call forwarding/redirection. To achieve this, the datafill in table
GSMVAR on the MSC specifies the digit substitution to convert MSISDNs to
national format numbers. The datafill affects the format of the calling number
captured in the billing records generated on a serving MSC, which sets up a
mobile originated call, and a redirecting MSC which sets up the forwarded leg of
a call. The datafill can be done separately for roaming and non-roaming
subscribers. For non-roaming subscribers, datafill in REPLACE_MS_CC_
DIGITS in table GSMVAR allows the country code (CC) digits to be replaced by
national prefix digits. For roaming subscribers, datafill in REPLACE_INTL_
(continued)
ROAM_CLID in table GSMVAR may be used to replace the entire calling
number with replacement digits, if the CC digits of the mobile originator do not
match the local CC digits.
For example, in a call forwarding scenario in which (1) party A calls party B and
is forwarded to party C, (2) REPLACE_MS_CC_DIGITS is enabled and (3) the
mobile country codes (MCC) of party A and party B match the CC digits in
REPLACE_MS_CC_DIGITS, then the following will result:
- The Mobile Originated Call Attempt record for party A will show the
MSISDN of A as the calling number in international format*, and the
(translated) MSISDN of B as the called number.
- The Mobile Terminated Call Forwarding Attempt record** for the original
call to party B will show the MSISDN of A as the calling number in national
format*, and the MSISDN of B as the called number in international
(untranslated) format.
- The Mobile Originated Call Forwarding Attempt record** for party B for the
call leg to party C will show the MSISDN of B as the redirecting and calling
number in international format, and the translated address for C as the called
number (assuming that C represents a PSTN destination).
- The outgoing trunk record for the terminating party C will show the
MSISDN of B as the redirecting and calling number in national format, and
the translated address for C as the called number.
* International format implies that the MCC is included in the digit
string and the NOA indicator is international. National format
implies that the MCC digits are not included in the digit string
(possibly replaced with National Prefix digits) and the NOA indicator
is national
** In the Mobile Originated and Mobile Terminated Call Forwarding
Attempt records, the Call Forward Indicator will be set.
NOTE 5 The MSC has another mechanism for specifying the format of the calling
number, redirecting number and original called number. This is to support the
different formats required in some administrations in different circumstances, for
example, that internationally formatted numbers are sent to voice mail systems
or that national format numbers must be signalled to some PSTNs. To achieve
this, the table OFCVAR specifies the format of the Calling Number for mobile
terminations and the table PETSIG specifies the format of the number to be used
over specified trunk groups. OFCVAR and PETSIG both contain the office
parameter PREFERRED_NOA. This has three subfields CALLING_NUMBER,
REDIRECTING_NUMBER and ORIG_CALLED_NUMBER which determine
the format of the number. The settings of these fields determine the format of the
respective number:
(continued)
- NONE (unspecified)
- INTL (international),
- NATL (national),
- NATWNP (national, with no prefix)
- UNKNOWN
- CDN (the format is the same as that of the called number).
Note that the datafill in these tables overrides the datafill described in NOTE 4.
If both sets of datafill are used on a MSC, the datafill described in this note take
priority. Also, the datafill described in NOTE 4 is only used on serving MSCs
and redirecting MSCs. Other MSCs in the call path may use the datafill
described in this note to alter the format of the numbers.
(continued)
NOTE 6 For CAMEL SMS calls, provisioned using SMS-CSI (CAMEL subscription
information), the SCP (Service Control Point) may change the calling number. In
this case, the SMS-MO record captures the original calling number. The
appended CAMEL SMS information module captures the modified calling
number. The SMS-MT (SMS Mobile Terminated) record also contains a calling
number field. The number that it contains reflects the calling number conveyed
to the service centre in the mobile originated forward short message (MO-FSM).
NOTE 7 The Calling Number is not available in the SMS Mobile Originated Barring of
All Outgoing Calls service (SMS MO BAOC). Therefore the Calling Number
field in the SMS MO record for SMS MO BAOC contains a default value.
NOTE 8 In North America a subscribers location may be provided by a Service Control
Point (SCP) for an emergency call using Intelligent Network Application Part
(INAP) signalling. In this case, this field contains the Emergency Service
Routing Key (ESRK) used to route the emergency call.
B5.2.27 Calling Party (or Served Party)
This field contains the international mobile subscriber identity (IMSI) of the originating mobile
subscriber. In the Common Equipment Usage record, the field contains the IMSI of the mobile
subscriber requesting a multi-party connection. It consists of three fields as shown in Table 86.
NOTE 1 In this data field the Number Type is set to indicate that the BCD or Hex String
contains an IMSI value. The Numbering Plan Identifier is set to the default value
given in the detailed reference section.
Field Used In:
Records: MO, SMSMO, CEU, SSA.
Numbering Plan Indicator 6 B5.2.124
Table 86 Calling (or served) party data field
B5.2.28 Calling Subscriber Category
This field defines the priority status of the calling mobile subscriber. This value is obtained from the
Home Location Register. The encoding of this field is exactly the same as that defined for the
Called Subscriber Category in Section B5.2.24 on page 137.
B5.2.29 Carrier Connect Timestamp
This field contains the time at which it is determined by the MSC that the carrier connection is
established. It is encoded as a 16 character date and time atomic field as described in Section
B5.2.46 on page 153.
The Carrier Connect Time Stamp is typically applicable for outgoing trunk records for trunks
connected to IC/INC directly or through an AT (Access Tandem). The absence of a Carrier Connect
Time Stamp in an Incoming Trunk Record may or may not imply that the call was successfully
connected to a carrier. The absence of a Carrier Time Stamp in a Mobile Origination Record or in an
Outgoing Trunk Record does imply that the call was not connected to a carrier.
B5.2.30 Cause for Termination
This field contains a reason for the release of a connection. The value of the cause for termination is
determined by the releasing agent. Examples showing the capturing of the cause for termination are
given in Section B3.7 on page 46. The reason captured in this field is a general one, and if more
detailed release information is available, it is captured in the Diagnostic field. The cause for
termination consists of a single field as shown in Table 87.
Field Used In:
Record: MO.
Field Used In:
Module: EA.
NOTE In the mobile originated and mobile terminated SMS call detail records this field
shall only be populated with a non default value when there is an abnormal call
termination.
B5.2.31 Cell-SAC Id
This field identifies the location of a mobile subscriber. The information is captured during a
normal voice/data call, handover, short message service sending and receipt, and for call
independent supplementary services (CISS) interactions. The field encoding is shown in Table 88.
NOTE 1 This field and the Access Network (AN) field (B5.2.2 on page 124) together
contain information about the type of network access. If the AN field indicates
GSM access, the Cell-SAC Id field contains the cell identity of the subscriber. If
the AN field indicates UMTS access, the Cell-SAC Id field contains the Service
Area Code of the subscriber.
NOTE 2 The GSM (2G) handover procedure contains location information and so this
field captures the cell identity provided during the procedure.
(continued)
Field Used In:
Records: MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP.
1 Reserved 0
2-3 Cause for Termination 00 - Normal Release
01 - Partial Record
02 - Partial Record Call Re-establishment
03 - Unsuccessful Call Attempt
04 - Stable Call Abnormal Termination
4 Sign Character C
Default: 000C
Example:
Cause for Termination (Call terminated due to generation of a partial call record): 001C
Table 87 Cause for termination atomic data field
Field Used In:
Record: SSA. Modules: LaC, LO.
1-5 Cell Identity/Service Area Code (Integer value) {00000....99999}
6 Sign Character C
Default: FFFFFC
Example:
Cell-SAC Id: 00124C
Table 88 Cell-SAC Id atomic data field
NOTE 3 In a UMTS network the MSC requests the reporting of location information
using the Location Reporting Control (LRC) RANAP procedure. In response,
the RNC reports the location information in a Location Report Procedure. The
MSC can send the LRC during initial call setup and during the relocation
procedure. The office parameter LOC_RPT_CNTRL_FOR_SAI determines the
location information requested in the LRC. For more information, see the office
parameter descriptions (B3.8.1 on page 49).
If the MSC does not request location information using the LRC procedure
during relocation, the Cell-SAC id field defaults to FFFFFC as the relocation
messaging/signalling does not contain location information. If this field is
defaulted, the value in the access network field (B5.2.2 on page 124) has no
meaning.
B5.2.32 Channel Allocation Time
This field contains the seizure time of the traffic channel. For both Mobile Originated and Mobile
Terminated calls, the seizure time is the time at which the traffic channel is allocated i.e. the time at
which the ASSIGN command is sent to the Mobile station. It is encoded as a 16 character date and
time atomic field as described in Section B5.2.46 on page 153.
In certain call scenarios such as unconditional call forwarding, where a channel is not allocated, the
field defaults to F ... FC. The time at which the call is answered, if applicable for the call, is always
captured separately in the answer time field (Section B5.2.6 on page 125).
B5.2.33 Channel Description
NOTE This 10 character atomic data field shall always be set to its default value. This
default value is FFFFFFFFFC.
B5.2.34 Channel Type
This field identifies the characteristics of the radio channel used for a call. The field encoding is
shown in Table 89.
Field Used In:
Records: MO, MT.
Field Used In:
Module: LaC.
NOTE 1 For UMTS voice calls the channel type value will always be 11100C. This
implies the use of the Adaptive Multi-Rate (AMR) encoder/decoder (codec).
This codec can change the bit rate used for speech encoding during a call.
NOTE 2 The values in the Speech Encoding Algorithm sub-field are captured from
information defined in 3GPP TS 48.008 [16]. Please refer to the permitted
speech version identifier in the channel type field description in TS 48.008.
Field Used In:
Module: LaC.
1 Speech or Data Indicator 0 - Spare (Not Used)
1 - Speech
2 - Data
3 - GSM Signalling
4 - Speech plus Cellular Text Modem (CTM)
Option
2 Character 1 = any Channel Rate and Type 0 - Spare
1 - Full Rate Traffic Channel (TCH Channel Bm)
2 - Half Rate Traffic Channel (TCH Channel Lm)
3 - Full/Half Rate Channel, Full Rate Preferred, Change Allowed
4 - Full/Half Rate Channel, Half Rate Preferred, Change Allowed
5 - Full/Half Rate Channel, Full Rate Preferred, No Change Allowed
6 - Full/Half Rate Channel, No Half Rate Preferred, No Change Allowed
or
2 Character 1 = 1 or 4 Channel Rate and Type 7 - Full/Half Rate, Change Allowed
8 - Full/Half Rate, No Change Allowed
Option
3-4 Character 1 = 1 or 4 Speech Encoding Algorithm
# = hex. See NOTE 2
00 - Spare
10 - GSM Full Rate Speech Version 1 (3GPP speech version value #01)
11 - GSM Half Rate Speech Version 1 (3GPP speech version value #05)
or
3-4 Character 1 = 3 Speech Encoding Algorithm 00 - Spare
or
3 Character 1= 2 Transparency Indicator 0 - Transparent
1 - Non Transparent
Option
4 Character 3 = 0
(transparent)
Data Rate 0 - Spare
1 - 9.6 KBit/s
2 - 4.8 KBit/s
3 - 2.4 KBit/s
4 - 1.2 KBit/s
5 - 600 Bits/s
6 - 1200/75 Bits/s (N->MS/MS->N)
7 - 14.4 Kbit/s
8 - 64 Kbits/s
or
4 Character 3 = 1
(non transparent)
Data Rate 0 - Spare
1 - 12 KBit/s
2 - 6 KBit/s
3 - 14.5 kbit/s
5 Reserved 0
6 Sign Character C
Default: FFFFFC
Example:
Channel Type (Data, Full Rate,Transparent,2.4 KBit/s): 23030C
Channel Type (Data, Full Rate, Non Transparent, 12 KBit/s): 23110C (NIRR not in use)
Channel Type (Data, Full Rate, Non Transparent, 6 KBit/s): 23120C (NIRR in use)
Table 89 Channel type atomic data field
B5.2.35 Charge Number
This field contains the number, for example an MSISDN, returned by an intelligent peripheral (IP)
to the MSC. During the provision of an off-board intelligent network (IN) service, the IP sends the
billing information to the MSC in an ETSI/ANSI PRI Facility message which contains a billing
number parameter. For a CS1-R INAP mobile originated SMS service, the charging information is
captured from the InitialDP message used to originate the IN service. For CAMEL MO SMS
(mobile originated short message service) the field contains the default value. It consists of two
B5.2.36 Charge Zone
This field contains the charge zone used to derive the Advice of Charge (AoC) parameters sent to
the mobile handset to allow it to calculate a real-time estimate of the call charges. The charging
zone is derived from the origination and destination zones of the calling and called parties. It is
defined as a value in the range 00000 to 00255 with wrap around from 00255 to 00000. The field
B5.2.37 Classmark Time Stamp
This field captures the time at which the mobile station classmark parameters are assigned. It is
encoded as a 16 character date and time atomic field as described in Section B5.2.46 on page 153.
Field Used In:
Module: IN.
Table 90 Charge number data field
Field Used In:
Module: TC.
1-5 Charge Zone {00000....00255}
6 Sign Character C
Default: FFFFFC
Example:
Charge Zone:00102C
Table 91 Charge zone atomic data field
Field Used In:
Records: MO, MT.
B5.2.38 Connection Element
This field contains the type of the connection employed in a data call. If the value is Transparent
then the Radio link protocol has not been employed on air interface. If the value is Non
Transparent then the Radio link protocol has been employed on the air interface. The field
NOTE When the Data Service information module is appended to incoming and
outgoing trunk records, the default value for the connection element field is 0C.
B5.2.39 Correlation ID
This field captures the correlation ID used to correlate the CAMEL phase 2 operations between the
initiating SSP, the assisting SSP and the Service Control Point (SCP). The correlation id is used in
the call scenario where the SCP requests the use of an intelligent peripheral (IP) in a CAMEL call.
In this case, the initiating SSP (an MSC/SSP) does not have its own IP and so requests the use of an
initiating SSPs facilities. The SCP sends the initiating SSP (another MSC/SSP) a CAMEL
EstablishTemporaryConnection message with the optional correlation ID parameter. To set up the
connection, the initiating SSP sends the assisting SSP an ISUP initial address message (IAM) which
contains the correlation ID. When the assisting SSP requests instructions from the SCP about which
IP facilities to use, it includes the correlation ID in the CAMEL AssistRequestInstructions (ARI)
message. After sending the ARI, the assisting MSC captures the correlation id for the billing record.
The SCP uses the correlation id to correlate the operations of initiating and assisting SSP during the
service. The field is encoded as a 24 character BCD/hex atomic data field as described in Section
B5.2.10 on page 127.
Field Used In:
Module: DS.
1 Connection Element 0 - Transparent
1 - Non Transparent
2 Sign Character C
Example:
Connection Element (Transparent): 0C
Table 92 Connection element atomic data field
Field Used In:
Module: GASSP.
B5.2.40 Correlation ID / ETC Parm2
This field captures part of the addressing information used to form a connection to an intelligent
peripheral (IP) for a CAMEL service. The Service Control Point (SCP) sends an Establish
TemporaryConnection message which contains the addressing information for the IP. Part of the
addressing information is the correlation ID. The MSC, acting as an initiating SSP, uses the
addressing information to form a connection to an assisting SSP which has the IP connected to it.
B5.2.41 Counter
This field is part of the IP (intelligent peripheral) Routing Address field described in Section
B5.2.91 on page 184, along with the IP Address Identity and MSC ID. The IP and the assisting SSP
have two connections between them: an ISUP connection and a TCAP connection which carries
CAMEL information. The IP uses the IP routing address to associate these two links. It also uses the
address to distinguish between the different connections that it has with the assisting SSP. The
initial value of the counter is zero and it is incremented by one each time the assisting SSP receives
a Connect To Resource (CTR) message from the SCP. If the counter reaches the maximum value of
099999999, it is reset to zero when the next CTR message is received. The field is encoded as 10
character BCD/hex string as defined in Section B5.2.10 on page 127.
Field Used In:
Module: IN.
1 Spare 0
2 Format Indicator 0 - Explicit
1 - Embedded
3-33 Correlation ID {0,1,2,3,4,5,6,7,8,9,0,A,B,C,D,E,F}
34 Sign Character C
Default: FF0000000000000000000000000000000C
Example:
Correlation ID / ETC Parm 2: 000000000000000000000000000001115C
Table 93 Correlation ID / ETC Parm 2 atomic data field
Field Used In:
Module: GASSP.
B5.2.42 CSI (CAMEL Subscription Information)
This field captures the CSI used for a call. The field encoding is shown in Table 94.
NOTE The value unknown indicates that the CSI information is not present.
The CSI values have the following meanings:
Originating CAMEL Subscription Information (O-CSI) identifies the subscriber as
having originating CAMEL services.
Dialled Service CAMEL Subscription Information (D-CSI) identifies the subscriber as
having originating dialled services.
Network CAMEL Subscription Information (N-CSI) identifies services offered on a per-
network basis by the serving PLMN operator for all subscribers.
Terminating CAMEL Subscription Information (T-CSI) identifies the subscriber as
having terminating CAMEL services in the GMSC.
VMSC Terminating CAMEL Subscription Information (VT-CSI) identifies the
subscriber as having CAMEL services in the VMSC
Mobile Originated Short Message Service CAMEL Subscription Information (MO-
SMS-CSI) identifies the subscriber as having originating CAMEL SMS services.
Mobile Terminated Short Message Service CAMEL Subscription Information (MO-
SMS-CSI) identifies the subscriber as having terminating CAMEL SMS services.
CSI is not supported in CS1-R. Hence for CS1-R at mobile origination and termination the CSI
field is set to the default value and the IN Protocol field (B5.2.76 on page 177) is set to CS1-R (1C).
Field Used In:
Module: IN.
1 CAMEL Subscription Information (CSI) 0 - Originating CAMEL Subscription Information (O-CSI)
1 - Dialled CAMEL Subscription Information (D-CSI)
2 - Network CAMEL Subscription Information (N-CSI)
3 - Terminating CAMEL Subscription Information (T-CSI)
4 - VMSC Terminating CAMEL Subscription Information (VT-CSI)
5 - Mobile Originated SMS CAMEL Subscription Information (MO-SMS-CSI)
6 - Mobile Terminated SMS CAMEL Subscription Information (MT-SMS-CSI)
7 - Mobility CAMEL Subscription Information (M-CSI)
2 Sign Character C
Default: FC
Example:
CSI (Network CAMEL Subscription Information): 2C
Table 94 CSI atomic data field
B5.2.43 Data Compression
This field captures information about the request, type and direction of data compression (if any)
negotiated between the IWF and the MS. The field encoding is shown in Table 95.

Field Used In:
Module: DS.
1 Data Compression Requested to IWF 0 - No
1 - Yes
Option
2 Character 1 = 0 Data Compression Type Negotiated by IWF 0 - Data Compression Not Used
or
2 Character 1 = 1 Data Compression Type Negotiated by IWF 0 - Data Compression Not Used
1 - V.42bis Data Compression Used
Option
3 Character 2 = 0 Data Compression Direction 0 - Data Compression Not Used
or
3 Character 2 = 1 Data Compression Direction 1 - Data Compression used in MS to IWF direction only
2 - Data Compression used in IWF to MS direction only
3 - Data Compression used in both directions
4 Sign Character C
Default: 000C
Examples:
Data Compression (not requested to IWF): 000C
Data Compression (requested to IWF, but not used): 100C
Data Compression (requested to IWF and V.42bis used in the MS to IWF direction only): 111C
Data Compression (requested to IWF and V.42bis used in the IWF to MS direction only): 112C
Data Compression (requested to IWF and V.42bis used in both directions): 113C
Table 95 Data Compression atomic data field
B5.2.44 Data Rate
This field captures information about the data rate used for a data service. The field encoding is
shown in Table 96.
NOTE 1 A data rate of Any shall be used to refer to all the bearer services of the
corresponding group. When the data rate is set to Any the connection element
in the data information module is not applicable and shall be set to zero.
NOTE 2 It should be noted that from a billing perspective the values 300/300 Bits/s (data
rate data field) and 600 Bits/s (channel type data field) are analogous. The
difference is due to the fact that the values in the channel type field are derived
from the radio layer 3 assignment request message and the values in the data rate
field are derived from the radio layer 3 setup message.
NOTE 3 The data rate field and the rate adaptation field (B5.2.155 on page 217) together
distinguish between the H.324 64K multimedia service and the 64K clear
channel service. For H.324, the data rate field indicates 64K (015C) and the rate
adaptation field indicates H.223 and H.245 (4C). For the 64K clear channel
service, the data rate indicates 64K (015C) and the rate adaptation field indicates
no rate adaptation (0C).
Field Used In:
Module: DS.
1 Spare 0
2-3 Data Rate 00 - Any
01 - 300/300 Bits/s
02 - 1200/1200 Bits/s
03 - 1200/75 Bits/s
04 - 2400/2400 Bits/s
05 - 4800/4800 Bits/s
06 - 9600/9600 Bits/s
07 - 14.4/14.4 Kbits/s
08 - 19.2/19.2 Kbits/s
09 - 28.8/28.8 Kbits/s
10 - 38.4/38.4 Kbits/s
11 - 43.2/43.2 Kbits/s
12 - 48.0/48.0 Kbits/s
13 - 56/56 Kbits/s
14 - 57.6/57.6 Kbits/s
15 - 64.0/64.0 Kbits/s
4 Sign Character C
Example:
Data Rate (1200/75 Bits/s): 003C
Table 96 Data rate atomic data field
B5.2.45 Data Volume
This field is associated with packet data services. The field encoding is shown in Table 97.
NOTE This 6 character atomic data field shall always be set to its default value. This
default value is 00000C.
B5.2.46 Date and Time
This is a generic field type specifying the date and time format. Other fields, for example, the
Answer Time field use this atomic field encoding. The field encoding is shown in Table 98.
NOTE 1 Characters 1 and 2 use the following interpretation for the year:
50 - 99 indicate the years 1950 - 1999
00 - 49 indicate the years 2000 - 2049
(continued)
Field Used In:
Module: DS.
1-5 Data Volume {00000....99999}
6 Sign Character C
Default: 00000C
Example:
Data Volume: 00000C
Table 97 Data Volume atomic data field
Field Used In:
Records: CEU, SSA. Switch/Billing File Records: TCR, SRR, BBHR, BFTIR, BFTOR.
Modules: BS, LaC, SS, TS, AoC.
1-2 - See NOTE 1 Year 00 to 99 {00....99}
3-4 Month 01 to 12 {01....12}
5-6 Day 01 to 31 {01....31}
7-8 Hour 00 to 23 {00....23}
9-10 Minute 00 to 59 {00....59}
11-12 Second 00 to 59 {00....59}
13 Tenths of Seconds {0....9}
14-15 - See NOTE 2 Hour Offset to MSC 00 - no offset
01 to 34 - time zone offset from +30 minutes to +26 hours
81 to B4 - time zone offset from -30 minutes to -26 hours
16 Sign Character C
Default: FFFFFFFFFFFFFFFC
Example:
Date and Time: 930304122053400C
Table 98 Date and time atomic data field
NOTE 2 The Date and Time field is 16 characters in length. If the SOC option Multiple
Time Zone Billing is not switched on, characters 14, 15 and 16 shall be set to
00C respectively. The offset to the Universal time as defined in 3GPP TS 32.205
(and indicated in the struck through text) is not supported by the MSC. All time
stamp fields are stored with zero hours time difference.
If the SOC option is on, characters 14 and 15 are used to indicate the timezone
offset between the MSC and the handset as shown in Tables 99 and 100.
Records
a
a. Mobile Originated Call Attempt (MO)
Mobile Terminated Call Attempt (MT)
Short Message Service Mobile Originated Record (SMS MO)
Short Message Service Mobile Terminated Record (SMS MT)
Supplementary Service Action Record (SSA)
Field MO MT SMS MO SMS MT SSA
Answer Time (B5.2.6 on page 125) Y Y
Channel Allocation Time (B5.2.32 on page 145) Y Y
Classmark Time Stamp (B5.2.37 on page 147) Y Y
Date and Time Y
Delivery Timestamp (B5.2.49 on page 157) Y Y
Disconnect Time (B5.2.54 on page 167) Y Y
Incoming/Outgoing Trunk Seizure Time (B5.2.82 on page 180) Y Y
Release Time (B5.2.164 on page 221) Y Y
SMS Time Stamp (Section B5.2.186) Y Y
Table 99 Timestamp fields in call records which may capture timezone offset values
Information Modules
a
a. Bearer Service (BS
Location and Channel (L&C)
Supplementary Service (SS)
Teleservice (TS)
Advice of Charge (AoC)
Data Service
Equal Access
Intelligent Network (IN)
Camel Short Message Service (CSMS)
Patching (Pa)
Field BS L&C SS TS AoC DS EA IN CSMS Pa
Date and Time Y Y Y Y Y
IWF Activation Timestamp (B5.2.93 on page 185) Y
Carrier Connect Timestamp (B5.2.29 on page 143) Y
IN Timestamp 1 (B5.2.77 on page 178) Y
IN Timestamp 2 (B5.2.78 on page 178) Y
SMS Start Time (B5.2.184 on page 231) Y
SMS Stop Time (B5.2.185 on page 231) Y
Unused Timestamp 1 (B5.2.203 on page 242) Y
Unused Timestamp 2 (B5.2.204 on page 242) Y
Table 100 Timestamp fields in modules which may capture timezone offset values when
appended to call records
The timezone offset is captured in 30 minute intervals, so an offset of 2
represents an offset of 1 hour, that is 2 x 30 minutes. Table 101 shows the values
which represent the different timezone offsets.
Hex Value Offset Hex Value Offset Hex Value Offset Hex Value Offset
00 No Offset 01 +30m 02 +1hour 03 +1hr 30min
04 +2hr 05 +2hr 30min 06 +3hr 07 +3hr 30min
08 +4hr 09 +4hr 30min 0A +5hr 0B +5hr 30min
0C +6hr 0D +6hr 30min 0E +7hr 0F +7hr 30min
10 +8hr 11 +8hr 30min 12 +9hr 13 +9hr 30min
14 +10hr 15 +10hr 30min 16 +11hr 17 +11hr 30min
20 +16hr 21 +16hr 30min 22 +17hr 23 +17hr 30min
24 +18hr 25 +18hr 30min 26 +19hr 27 +19hr 30min
30 +24hr 31 +24hr 30min 32 +25hr 33 +25hr 30min
34 +26hr 35 ~ 80 NOT USED 81 -30m 82 -1hour
83 -1hr 30min 84 -2hr 85 -2hr 30min 86 -3hr
87 -3hr 30min 88 -4hr 89 -4hr 30min 8A -5hr
8B -5hr 30min 8C -6hr 8D -6hr 30min 8E -7hr
8F -7hr 30min 90 -8hr 91 -8hr 30min 92 -9hr
93 -9hr 30min 94 -10hr 95 -10hr 30min 96 -11hr
97 -11hr 30min 98 -12hr 99 -12hr 30min 9A -13hr
9B -13hr 30min 9C -14hr 9D -14hr 30min 9E -15hr
9F -15hr 30min A0 -16hr A1 -16hr 30min A2 -17hr
A3 -17hr 30min A4 -18hr A5 -18hr 30min A6 -19hr
A7 -19hr 30min A8 -20hr A9 -20hr 30min AA -21hr
AB -21hr 30min AC -22hr AD -22hr 30min AE -23hr
AF -23hr 30min B0 -24hr B1 -24hr 30min B2 -25hr
B3 -25hr 30min B4 -26hr B5 ~ FF NOT USED
Table 101 Timezone offset values
B5.2.47 Default SMS Handling Applied (DSH Applied)
This field indicates whether or not default SMS handling was applied during a CAMEL SMS call.
Certain error scenarios require the application of default SMS handling (DSH), for example the
expiry of timer Tssf. The field encoding is shown in Table 102.
B5.2.48 Default SMS Handling Indicator (DSH Indicator)
This field indicates whether a CAMEL SMS call should be released or continued as requested in the
case of an error in the dialogue between the MSC/SSP and the gsmSCF (service control function).
The MSC/SSP captures the information in this field from the SMS-CSI data received from the VLR
(downloaded earlier to the VLR from HLR). The field encoding is shown in Table 103.
Field Used In:
Module: CSMS.
1 Condition 0 - No
1 - Yes
2 Sign Character C
Default: FC
Example:
Default SMS Handling applied: 1C
Table 102 Default SMS handling applied (DSH applied) atomic data field
Field Used In:
Module: CSMS.
1 Condition 0 - Continue Call
1 - Release Call
2 Sign Character C
Default: FC
Example:
Default SMS Handling Indicator (Continue Call): 0C
Table 103 Default SMS handling indicator (DSH indicator) atomic data field
B5.2.49 Delivery Timestamp
This field captures the time at which a short message is either successfully delivered to the service
centre (mobile originated SMS) or is successfully delivered to the mobile station (mobile
terminated SMS). In the former case this time stamp is marked by the receipt of the FORWARD
SHORT MESSAGE ACK at MSC. In the latter case this time stamp is marked by the receipt CP-
DATA(RP-ACK) at the MSC. In both cases, the timestamp marks when the MSC sends the
message: it does not mark receipt by the end user or confirmation of receipt by the SMS service
centre. The timestamp field is encoded using the 16 character date and time atomic field as
described in Section B5.2.46 on page 153.
B5.2.50 Destination Routing Address
This field captures routing information related to intelligent network (IN) services. For a mobile
originated call on an MSC/SSP (on-board IN service) the destination routing address contains either
the address of an intelligent peripheral (IP), or the new called party number returned by the IN
Service Control Point (SCP) in a CAP (UMTS standard) or INAP (UMTS proprietary IN) Connect
message. For off-board IN services, (where the MSC is remote from the IN service switching point
(SSP)) the destination routing address contains the IN Index.
The IN Index is a translation key which is used by the MSC to route the call to the SSP and it is
right justified in the destination routing address. The IN Index is taken from the subscription
information in the VLR for mobile originated calls, and from the SendRoutingInformation message
returned by the HLR for mobile terminated calls. The destination routing address field is encoded as
a 32 character BCD/hex string as defined in Section B5.2.10 on page 127.
For the GSM-R functional addressing service, the Connect message sent by the SCP contains the
MSISDN associated with the called partys functional address. The MSC/SSP captures this
information in the destination routing address field.
Field Used In:
Module: SMSMO, SMSMT.
Field Used In:
Module: IN.
B5.2.51 Detection Point
This field contains the trigger that activated an on-board or off-board intelligent network (IN)
service, or connection to an IN intelligent peripheral (IP). The field encoding is shown in Table 104.
NOTE 1 Characters 2 and 3 may also record the detection point DP2-T (DP2 on a trunk)
as value 02.
NOTE 2 The value 000C indicates that the trunks between the intelligent peripheral (IP)
and MSC were released by the dual port release link trunk feature. Information
on the IN service applied is contained in the charge number and the off-board IN
service identifier and indicator fields in the IN information module.
Field Used In:
Module: IN.
1 Spare 0
2-3 IN Detection Indicator 00 - None
01 - Origination Attempt Authorized
02 - Info Collected (DP2)
03 - Info Analysed (DP3)
04 - Route Select Failure
05 - O_Called_Party_Busy
06 - O_No_Answer
07 - O_Answer
08 - O_Mid_Call
09 - O_Disconnect
10 - O_Abandon
11 - Unused_11
12 - Termination Attempt Authorized (DP12)
13 - T_Busy
14 - T_No_Answer
15 - T_Answer
16 - T_Mid_Call
17 - T_Disconnect
18 - T_Abandon
19 - SCP-directed termination to IP
20 - 33 Spare
34 - Off-board Originating
35 - Off-board Terminating
4 Sign character C
Default: 000C
Examples:
Mobile originated on-board call: 002C
Table 104 Detection point atomic data field
B5.2.52 Diagnostic
This field contains a detailed technical reason for the release of the connection. The value captured
in the Diagnostic field is determined by the releasing agent. Examples showing the capturing of the
diagnostic information are given in Section B3.7 on page 46. The field encoding is shown in Table
105.
NOTE 1 The intelligent population of the Diagnostic field is partially supported by the
MSC. In the call scenarios in which this field is not supported, the field shall be
present and the default value shall be captured.
NOTE 2 The SMS Result field, which also uses the Diagnostic atomic field type, is
populated with either radio layer 3 or MAP error codes for failure cases in SMS
calls.
Table 106 refers to other tables which show the values captured for each agency.
Field Used In:
Records: MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP.
1-2 Protocol 00 - 3GPP TS 24.008
3GPP TS 44.068 and GSM TS 44.069
01 - 3GPP TS 29.002
02 - ITU-T Q.767
03 - Network Specific Cause
04 - Manufacturer Specific Cause
05 - Unknown
3-5 Error Code See Table 106
6 Sign Character C
Default: FFFFFC
Examples:
02016C: ITU-T ISUP - Normal Release
05003C: MF - NO Circuit Available
04016C: ANSI ISUP - Normal Release
03004C: ATUP, MTUP or Blue Book TUP - National Network Congestion
00017C: MS - User Busy
Table 105 Diagnostic atomic data field
NOTE 3 Diagnostic error codes for PRI and QSIG protocols and for the R1 and R2 trunk
agents are not supported for the Diagnostic field. If a PRI/QSIG or R1/R2 agent
initiates call release, the Diagnostic field contains the default value FFFFFC.
B5.2.52.1 Signalling Agents with Error Codes used for Diagnostic
The following tables contain the error code values for the signalling types ITU-T ISUP and the I-
ISUP variant, ANSI ISUP and radio layer 3 and Broadcast call control/Group call control (BCC/
GCC). These signalling agencies do not require mapping.
Values Mapping
Requirement
a
a. No = no mapping is required. The signalling cause value is captured directly into the billing record.
Tables 107 through 109 have the values of these error codes.
Yes = mapping is required. The reason for termination is mapped to a three character numeric value
that is placed in the diagnostic field. Tables 111 through 115 have the required mapping values.
Error Code (3 Characters) Signalling Agent
00 3GPP TS 24.008 No Radio layer 3 cause value as specified in Table 109 Radio layer 3
GSM TSs 44.068 and 44.069 No Group call control and broadcast call control cause
values as specified in Table 110
GCC and BCC
01 3GPP TS 29.002 No
Not Supported
b
b. MAP error codes are currently not supported in the diagnostic field for call release. However, MAP
and radio layer 3 causes for Short Message Service failures are captured into the SMS Result field. For
information on these error codes, refer to 3GPP TS 24.008 and 29.002.
MAP
02 CCITT Q.767 No ISUP Cause value as specified in Table 107 ITU-T ISUP
03 Network Specific Cause
(See the following tables for
mappings)
Yes 000 - 050 (Table 111) ATUP
Yes 000 - 050 (Table 112) Blue Book TUP
Yes 000 - 050 (Table 113) Italian TUP (ITTUP)
Yes 000 - 050 (Table 114) MTUP
Yes All other values reserved -
04 Nortel Specific Cause No ISUP Cause value as specified in Table 108 ANSI ISUP
05 Unknown No 000 - Cause for termination Unknown MF
Yes 001-050 (Table 115) MF
Table 106 Error code value settings

NOTE Portuguese ISUP also uses the nationally defined cause value 14 Query on
Release for Mobile Number Portability.
Cause Value Error code
Unallocated number 1
No route to specified transit network 2
No route to destination 3
Send special information tone 4
Misdialled trunk prefix 5
Pre-emption 8
Pre-emption-circuit reserved for reuse 9
Normal clearing 16
User busy 17
No user responding 18
No answer from user 19
Absent Subscriber 20
Call rejected 21
Number changed 22
Destination out of order 27
Address incomplete 28
Facility rejected 29
Normal, unspecified 31
No circuit available 34
Network out of order 38
Temporary failure 41
Switching equipment congestion 42
Request channel not available 44
precedence call blocked 46
Resource unavailable, unspecified 47
Requested facility not subscribed 50
Incoming calls barred within CUG 55
BC not authorized 57
BC presently not available 58
Serv/opt not available, unspecified 63
BC not implemented 65
Requested facility not implemented 69
Only restricted digital information 70
Service/option not implemented unspecified 79
User not member of CUG 87
Incompatible destination 88
Invalid transit network selection 91
Invalid message, unspecified 95
Message Type not implemented 97
Parameter not implemented 99
Recovery on timer expiry 102
Parameter not implemented, passed on 103
Protocol error, unspecified 111
Interworking, unspecified 127
Table 107 ITU-T ISUP cause values
a
a. Shaded entries indicate values which correspond to a
Cause for Termination (CFT) value of Normal Release.
Cause Value Decimal Value
Unallocated Number 1
No Route to Transit Network 2
No Route to Destination 3
Send Special information Tone 4
Misdialled Trunk Prefix 5
Pre-emption-Circuit Reserved for Reuse 9
Normal clearing 16
User busy 17
No User Responding 18
No Answer From User (User Alerted) 19
Subscriber Absent 20
Call Rejected 21
Number Changed 22
Redirect to New Destination 23
Unknown Business Route 24
Exchange Routing Error 25
Misrouted Call to Ported Number 26
Destination Out of Service 27
Address Incomplete 28
Facility Rejected 29
Apply Locally 30
Normal, Unspecified 31
No Circuit Available 34
Network Out of Order 38
Temporary Failure 41
Switching Equipment Congestion 42
User information Discarded 43
Requested Channel not Available 44
Pre-emption 45
Precedence Call Blocked 46
Resource Unavailable, Unspecified 47
Requested Facility Not Subscribed 50
Call Type Incompatible with Service Request 51
Outgoing Calls Barred
52
a
a. The ANSI ISUP specification T1.113 uses cause value 53 for Outgoing Calls Barred Within
CUG.
Call Blocked due to Group Restrictions 54
Incoming Calls Barred Within CUG 55
Bearer Capability Not Authorized 57
Bearer Capability Presently Not Available 58
Inconsistency in Designated Outgoing Access Information and Subscriber Class 62
Service or Option Not Available Unspecified 63
Bearer Capability Not Implemented 65
Channel Type Not Implemented 66
Facility Not Implemented 69
Only Restricted Digital Information 70
Service or Option Not implemented 79
Invalid Reference Value 81
User Not Member of CUG 87
Incompatible Destination 88
Non-existent CUG 90
Invalid TNS 91
Invalid Message, Unspecified 95
Mandatory Information Element is Missing 96
Message Type Not implemented 97
Parameter Not implemented 99
Invalid Parameter Contents 100
Recovery on Timer Expiration 102
Parameter Not Implemented, Passed on 103
Message with Unrecognized Parameter, Discarded 110
Protocol Error, Unspecified 111
Interworking, Unspecified 127
Table 108 ANSI ISUP cause values
b

c
b. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of
Normal Release.
c. Values in italic show Nortel proprietary cause values defined in ITU Q.850 as being for
DSS1 signalling.

Cause Value Error Code
NIL 0
Unallocated number 1
No route to destination 3
Channel unacceptable 6
Operator determined barring 8
Normal call clearing 16
User busy 17
No user responding 18
User alerting, no answer 19
Call rejected 21
Number changed 22
Pre-emption 25
Non selected user clearing 26
Destination out of order 27
Invalid number format (incomplete number) 28
Facility rejected 29
Response to status enquiry 30
Normal, unspecified 31
No circuit available 34
Network out of order 38
Temporary failure 41
Switching equipment congestion 42
Access info discarded 43
Requested circuit/channel not available 44
Resource unavailable, unspecified 47
Quality of service unavailable 49
Requested facility not subscribed 50
Incoming calls barred within the CUG 55
Bearer capability not authorized 57
Bearer capability not presently available 58
Service or option not available, unspecified 63
Bearer service not implemented 65
ACM equal to or greater than ACM max 68
Requested facility not implemented 69
Only restricted digital information bearer capability is available 70
Service or option not implemented, unspecified 79
Invalid transaction identifier value 81
User not member of CUG 87
Incompatible destination 88
Invalid transit network selection 91
Semantically incorrect message 95
Invalid mandatory information 96
Message type non-existent or not implemented 97
Message type not compatible with protocol state 98
Information element non-existent or not implemented 99
Conditional IE error 100
Message not compatible with protocol state 101
Recovery on timer expiry 102
Interworking, unspecified 127
Table 109 3GPP TS 24.008 radio layer 3 cause values
a
a. Shaded entries indicate values which correspond to a Cause
for Termination (CFT) value of Normal Release.
B5.2.52.2 Signalling Agents and Required Mappings
This section contains the mappings required for the following signalling agencies:
Table 111, ATUP cause values and error codes
Table 112, Blue Book TUP cause values and error codes
Table 113, Italian TUP (ITTUP) cause values and error codes
Table 114, MTUP cause values and error codes
Table 115, MF cause values and error codes.
Cause Value Error Code
NIL 0
Illegal MS 3
IMEI not accepted 5
Illegal ME 6
Service not authorized 8
Application not supported on the protocol 9
RR connection aborted 10
Normal cause 16
Network failure 17
Busy 20
Congestion 22
Response to Get Status 30
Service option not supported 32
Requested service option not subscribed 33
Service option temporarily out of order 34
Call cannot be identified 38
Retry upon entry into a new cell 48-63
Invalid transaction identifier value 81
Semantically incorrect message 95
Invalid mandatory information 96
Message type non-existent or not implemented 97
Message type not compatible with the protocol state 98
Information Element non-existent or not implemented 99
Information Element not compatible with the protocol state 100
Table 110 GSM TSs 44.068 and 44.069 GCC and BCC cause values
a
a. Shaded entries indicate values which correspond to a Cause for
Termination (CFT) value of Normal Release.
ATUP Cause Values Error Code
Address Incomplete (ADI) 000
Call Failure (CFL) 001
Circuit Group Congestion (CGC) 002
Line Out of Service (LOS) 003
National Network Congestion (NNC) 004
Switching or Circuit Congestion (SCC) 005
Switching Equipment Congestion (SEC) 006
Send Special Info Tone (SST) 007
Unallocated Number (UNN) 008
Subscriber Busy (SSB) 009
Clear Forward (CLF) 015
Clear Backward (CBK) 016
Force Release (FRL) 017
Table 111 ATUP cause values and error codes
a
a. Shaded entries indicate values which correspond to a Cause for Termination
(CFT) value of Normal Release.
Blue Book TUP Cause Values Error Code
Subscriber Busy (SSB) 009
Access Barred (ACB) 012
Digital Path Not Provided (DPN) 013
Extended Unsuccessful Message (EUM) 014
Table 112 Blue Book TUP cause values and error codes
a
Italian TUP Cause Values Error Code
International Congestion Signal (INC) 002
Special Info Transmission Tone (SIT) 007
Number Not In Use (NNU) 008
Engaged User Signal (EUS) 009
Call Note Allowed (CNA) 012
Clearance Signal (CLS) 015
End Of Conversation (EOC) 016
Clearance Request Message (CRQ) 030
Checked Not Ready (CNR) 031
Table 113 Italian TUP (ITTUP) cause values and error codes
a
B5.2.53 Dialled Digits
This field contains the digits received from the mobile station on mobile originated call setup. This
is the called number before the digits are sent through universal translations. Dialled digits may
contain the characters * and #. If a subscriber uses dialled digits to invoke a supplementary
service, abbreviated dialling or dedicated routing, the dialled digits field contains the digits received
from the mobile station. Dialled digits consists of two fields as shown in Table 116.
MTUP Cause values Error code
Switching or Circuit Congestion (SCC) 005
Subscriber Local Busy (SLB) 010
Subscriber Toll Busy (STB) 011
Access Barred Signal (ACB) 012
Digital Path Not Provided (DPN) 013
Extended Unsuccessful Message (EUM) 014
Force Release (FRL) 017
Table 114 MTUP cause values and error codes
a
MF Cause values Error code
Normal Clearing 001
Forced Release or Abnormal Clearing 002
No Circuit Available 003
Incompatible Agents 004
Data Call Denied 005
Datafill Trouble 006
Start Wink Failure 007
First Equal Access Wink Failure 008
Second Equal Access Wink Failure 009
Acknowledgement Wink Failure 010
First Stage Outpulsing Trouble 011
Second Stage Outpulsing Trouble 012
No Answer from User 013
Subscriber Busy 014
Subscriber Out of Order 015
Congestion 016
Unassigned Number 017
Table 115 MF cause values and error codes
a
NOTE 1 The dialled digit of * is stored as the BCD character A and the dialled digit of
# is stored as the BCD character B.
NOTE 2 The dialled digits field can contain the cell of origin depending on the datafill in
the MSC translation tables. The cell of origin is included if the COO option of
the DMOD selector in the xxCODE tables is present in the datafill.
NOTE 3 If the length of the dialled digits is greater than 30 digits, the digits after the 30th
digit are truncated in the billing record.
NOTE 4 For the GSM-R functional addressing service, the dialled digits field contains the
functional number (FN) dialled by the calling party.
B5.2.54 Disconnect Time
This field contains the time at which the connection is released. For call origination or termination,
the field captures the time at which the MSC receives or sends the disconnect message.
This field also captures the time at which the connection between an assisting SSP (an MSC/SSP)
and an intelligent peripheral (IP) is released during a CAMEL Phase 2 call. There are several ways
in which the connection can be released. In one, the IP sends the final specialised resource report to
the Assisting SSP in a TCAP end message to end the TCAP connection used to carry CAMEL
signalling. The Assisting SSP captures the disconnect time at this point. It then sends an ISUP
release message to the IP and a specialised resource report to the SCP. The IP responds with an
ISUP release complete message to confirm that it has released the ISUP connection. The SCP
instructs the Initiating SSP to release the ISUP connection to the Assisting SSP.
The disconnect time field is encoded as a 16 character date and time atomic field as described in
Section B5.2.46 on page 153.
B5.2.55 E Parameter
The E parameter field contains the value of one of the E parameters sent by the MSC to the mobile
station to support the Advice of Charge (AoC) supplementary service. There are seven E parameters
which specify constants and multipliers which the mobile station uses to calculate call charges. The
AoC information module contains seven E parameter fields to hold these values. Each E parameter
consists of a single field as shown in Table 117.
Field Used In:
Record: MO.
BCD or Hex String (32) Notes 32 B5.2.10
Table 116 Dialled digits data field
Field Used In:
Records: MO, MT. Module: GASSP.
B5.2.56 Emergency Service Routing Digits (ESRD)
This field captures the Emergency Service Routing Digits for an LCS service. It is a 15-digit string
that uniquely identifies a base station, or cell site that may be used to route emergency calls through
the network. It is encoded as a 16 character BCD/hex atomic data field as shown in Section B5.2.10
on page 127.
B5.2.57 Emergency Service Routing Key (ESRK)
This field captures the Emergency Services Routing Key during an LCS service. It is a 10-digit
string that uniquely identifies an outgoing Emergency Services Call encoded in E.164 format.The
Field Used In:
Module: AoC.
1 Spare 0
2-5 E-Parameter {0000....8191}
6 Sign Character C
Default: FFFFFC
Example:
E-Parameter: 04567C
Table 117 E parameter atomic data field
Field Used In:
Record: LCS.
Field Used In:
Record: LCS.
Characters Description Detailed reference
1 Spare 0
2-11 ESRK {0,1,2,3,4,5,6,7,8,9}
12 Sign Character C
Default: FFFFFFFFFFFC
Example:
ESRK-Key: 0F123457232C
Table 118 ESRK-Key atomic data field
B5.2.58 Equipment Identity
This field contains an identifier which distinguishes between equipment provided on an MSC or on
a Media Gateway (MGW) e.g. between MSC or MGW conference circuits. The field encoding is
shown in Table 119.
B5.2.59 Equipment Type
This field contains the type of the common equipment employed e.g. conference circuit for multi-
party service. The field encoding is shown in Table 120.
B5.2.60 FCI Freeform Parameter
This field contains service-related information provided by the IN SCP (intelligent network Service
Control Point) to the MSC/SSP during the provision of a mobile-originated on-board IN service.
The information is provided in INAP FurnishChargingInformation message(s). The field encoding
is shown in Table 121.
Field Used In:
Record: CEU.
1-5 Equipment Identity 00001 - MSC
00002 - Media Gateway
6 Sign Character C
Example:
Equipment Identity: 00002C (equipment provided on an MGW)
Table 119 Equipment identity atomic data field
Field Used In:
Record: CEU.
1-3 Spare 000
4 Equipment Type 0 - Conference Circuit
Option
5 Character 4 = 0 Type of conference circuit 1 - 3-Port Conference Circuit
2 - 6-Port Conference Circuit
6 Sign Character C
Example:
Equipment Type: 00001C (3-port multi-party service)
Table 120 Equipment type atomic data field
NOTE 1 A data descriptor of FFFF is used for any explicit billing item taken from the FCI
(FurnishChargingInformation) message and converted to a freeform equivalent.
This is because the process of converting an explicit billing item involves right
justifying it and its sub-parameters and padding with Hex F characters.
NOTE 2 A freeform billing item received in an FCI message is passed straight into an FCI
freeform parameter field. The value of the data descriptor is the same as that
provided in the FCI message.
NOTE 3 The sequence number shows the order in which the billing items were received.
NOTE 4 The IN Charging Information module contains three FCI freeform parameter
fields. Any fields which do not contain actual billing data are filled with the
default value of FF ... FC.
B5.2.61 File Sequence Number
This field is defined as a binary coded decimal value in the range 000 to 999. It is encoded as a 4
character BCD/hex atomic data field as shown in Section B5.2.10 on page 127.
B5.2.62 File Transfer Type
This field captures information about the type of transfer for the billing file. The billing file contains
a number of records. The file transfer type field is found in the records which mark the start and end
of the billing file. The field encoding is shown in Table 122.
Field Used In:
Module: INC.
1-4 Data Descriptor 0000 ... FFFF
5-44 Freeform billing data All 0s to all Fs
45 Sequence number {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E}
46 Sign Character C
Default: FFF...FC.
Example: 1256778899DDCCBBAA662219543BB477CC22397899AA3C
Table 121 FCI freeform parameter atomic data field
Field Used In:
Switch/Billing File Records: BFTIR, BFTOR.
B5.2.63 Free Format Data
This field contains the service-related charging information sent by the gsmSCF (GSM service
control function) to the MSC/SSP during a CAMEL intelligent network service. The information is
provided in the CAMEL Application Part (CAP) FurnishCharging Information (FCI) message(s).
For CAMEL Phase 2 there can be up to 40 bytes of charging information supplied in one or more
FCI messages. The MSC/SSP captures this information in two separate free format data fields each
of which can capture 20 octets (40 characters) of data bounded by a leading F and a trailing C.
For CAMEL Phase 3 services, the SCP may supply up to 160 octets of charging information in one
or more FCI messages. The MSC/SSP captures the information in eight separate free format data
fields. New charging information may overwrite or be appended to the original information
depending on instructions sent by the SCP. The first field, free format 1, contains the first set of
charging information. If the MSC/SSP receives new charging information with instructions to
append the new data, it adds the new data straight after the previously recorded data.
The encoding of a single free format data field is shown in Table 123.
The CAMEL charging information module (B4.2.18 on page 104) captures eight free format data
fields, free format data 1 to free format data 8. For CAMEL Phase 2 services, only the first two
fields contain charging data, while for a CAMEL Phase 3 service all eight fields may contain
charging data. In both cases, a field containing the default value indicates that it contains no
charging data. Table 124 shows the default and an example for the eight free format data fields
captured in the CAMEL charging information module.
Field Used In:
Switch/Billing File Records: BFTIR, BFTOR.
1-3 File Transfer Type 000 - Incoming Transfer
001 - Outgoing Transfer
002 - Outgoing Emergency Transfer
4 Sign Character C
Example:
File Transfer Type (Outgoing Transfer): 001C
Table 122 File transfer type atomic data field
Field Used In:
Module: CC.
1 Padding F
2-41 Free format data Each of the 40 characters can be one of 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F
42 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Example: F1234567895839567891269870789121947789123C
Table 123 CAMEL free format data atomic data field
B5.2.64 Functional Number
This field contains the functional number of the mobile station making an acknowledgement call to
the integrated acknowledgement centre (IAC). It consists of a single field as shown in Table 125.
B5.2.65 Geographical Location of UE 1
This field captures the location of the user equipment (mobile station etc.) provided by a location
service (LCS). The Geographical Location of User Equipment (UE) is obtained from the Mobile
Originated Location Request (MO-LR) message or Provide Subscriber Location (PSL) message.
For a MO-LR and a Mobile Terminated Location Request (MT-LR) service, the MSC obtains the
information from the Perform Location Response, or the Location Reporting message, or the last
computed location from the VLR. The MSC captures the Geographical Location Information of the
UE in the five fields Geographical Location of UE 1 to 5 (B5.2.65 to B5.2.69). The maximum size
of the location information is 91 bytes. Please refer to 3GPP Specification (23.032) for more details.
This field captures the first 20 bytes (bytes 0 to 19) of the location information. Its encoding is
shown in Table 120.
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Example: F1234567895839567891269870789121947789123C
F4579361234560916234569025234567893601196C
Table 124 Default and Example Values for Eight Free Format Data Fields
Field Used In:
Record: Ack.
1-15 Functional number 000000000000000 - 999999999999999
16 Sign Character C
Default: FFFFFFFFFFFFFFFC.
Example:
Functional number: 003026178911101C
Table 125 Functional number atomic data field
NOTE For more information on the information in this field, see the Location service
data types ASN.1 definition in 3GPP TS 29.002. This section of the Mobile
Application Part (MAP) specification provides full details of operations such as
ProvideSubscriberLocation-Res which return location information. See also
3GPP TS 23.032 which specifies the methods used for specifying geographical
location.
service (LCS). It captures the 20th to 39th byte (numbering from byte 0) of the geographical area
description of the UE and is populated when the size of the location data is greater than 20 bytes.
When the location information received is less than 20 bytes, this field contains default values. For
more information, please see B5.2.65. The field encoding is shown in Table 127.
description of the UE and is populated when the size of the location data is greater than 40 bytes. If
the location information received is less than 40 bytes, this field contains default values. For more
information, please see B5.2.65. The field encoding is shown in Table 128.
Field Used In:
Record: LCS.
1 Spare F
2-41 Location Estimate - bytes 0 to 19 {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E, F}
42 Sign Character C
Example:
Geographical Location of UE: F5500023556771FA432134FFF0110001F00000F78C
Table 126 Geographical location of UE 1 atomic data field
Field Used In:
Record: LCS.
1 Spare F
42 Sign Character C
Example:
Geographical Location of UE: FFFFFFFFFFFFFFFFFFF8983001244882166300F62C
service (LCS). It captures the 80th to 91st byte (numbering from byte 0) of the geographical area
Field Used In:
Record: LCS.
1 Spare F
42 Sign Character C
Example:
Geographical Location of UE: FFFFFFFFFFFFFFFFFFFFFFFFF0113221231332231C
Field Used In:
Record: LCS.
1 Spare F
42 Sign Character C
Example:
Geographical Location of UE: FFE7F283FF7824BC53AF85674230113221231332231
B5.2.70 Group Call Reference
This field contains the group call reference number of a high priority group call. It is captured in the
acknowledgement record generated by the integrated acknowledgement centre (IAC). It consists of
a single field as shown in Table 131.
B5.2.71 Half Rate in Use
This field is a simple boolean indicator which indicates whether or not a Half rate channel was used.
It is encoded as a boolean type atomic data field as described in Section B5.2.14 on page 129.
Field Used In:
Record: LCS.
1 Spare F
24 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFFFC
Example:
Geographical Location of UE: FFFFFFF0113221231332231C
Field Used In:
Record: Ack.
1 Unused 0
2-9 Group call reference number 00000000 - 99999999
10 Sign Character C
Default: 0FFFFFFFFC.
Example:
Group reference: 000000011C
Table 131 Group call reference atomic data field
Field Used In:
Records: MO, MT.
B5.2.72 Hexadecimal Identity
This field specifies whether the structured record is of good or bad quality. It is one of the fields in
the Record Header compound field described in B5.2.157 on page 218. The field encoding is shown
in Table 132.
NOTE A Hexadecimal identity of AB means that the record formatter has found a value
somewhere in the record that is unexpected. It is the customers choice of
whether or not to discard this record however there may be some valid
information contained. For avoidance of doubt a value of AB is not set if a call
fails for some call processing reason.
B5.2.73 Hot Billing Indicator
This field is used in the Supplementary Service Action record and the GSM-R Acknowledgement
record and shows whether or not the subscriber is provisioned with hot billing. The field encoding
Field Used In:
1 Constant A
2 Record Quality A - Good Record
B - Data Errors Encountered
Example:
Hexadecimal Identity (Good Record): AA
Table 132 Hexadecimal identity atomic data field
Field Used In:
Records: SSA, Ack.
1 Hot billing I 0 - Normal record
1 - Hot billing record
2 Sign C
Default: 0C.
Example:
Hot billing record: 1C
Table 133 Hot billing indicator atomic data field
B5.2.74 IN Call Reference Number
This field contains the IN call reference number which is used to identify uniquely a CAMEL Phase
3 mobile originated short message (MO-SMS). The field is encoded as an eighteen character BCD
or full hex string as defined in Section B5.2.9 on page 127.
NOTE For a CAMEL mobile originated short message, a failure to build an
initialDPSMS message results in a default value of FFFFFFFFFFFFFFFFFC
being captured for the IN Call Reference.
B5.2.75 IN Dialogue Result
This field indicates the success or failure of the dialogue between the MSC/SSP and the gsmSCF
(service control function) for a CAMEL Phase 3 service. The field encoding is shown in Table 134.
The IN dialogue result is captured as a failure as follows:
Tsms timer expiry
Inability to send message
Receiving abort/reject/error from SCP
Sending abort to SCP
All other scenarios are treated as successful.
B5.2.76 IN Protocol
This field identifies the intelligent networking (IN) protocol used between the MSC and the SCP
(Service Control Point) to provide services during a call. The MSC supports a proprietary IN
protocol based on CS1-R INAP which was developed by the ITU for fixed line applications. It also
supports the standard wireless CAMEL (Customised Applications for Mobile enhanced Logic)
services defined by ETSI/3GPP. The field encoding is shown in Table 135.
Field Used In:
Module: CSMS.
Field Used In:
Module: CSMS.
1 Condition 0 - Failure
1 - Success
2 Sign Character C
Default: FC
Example:
IN Dialogue Result (Success): 1C
Table 134 IN dialogue result atomic data field
B5.2.77 IN Time Stamp1
This field contains the answer time of an intelligent peripheral (IP) used during an on-board IN
(intelligent network) service involving a MSC/SSP. Together with IN timestamp2 (B5.2.78) this
field measures the duration of the IP connection. It is encoded as a 16 character date and time
atomic data field as described in Section B5.2.46 on page 153.
B5.2.78 IN Time Stamp2
This field contains the time at which an intelligent peripheral (IP) is released from a call. IPs may be
used for on-board IN (intelligent network) services involving a MSC/SSP. Together with IN
timestamp1 (B5.2.77) this field measures the duration of the IP connection. It is encoded as a 16
character date and time atomic data field as described in Section B5.2.46 on page 153.
Field Used In:
Modules: CSMS, GASSP, IN.
1 IN Protocol 0 - CS1-R
1 - CAP (CAMEL Application Part) Phase 1
2 - CAP Phase 2
3 - CAP Phase 3
4 - C AP Phase 4
5 - CAP Phase 5
6 - Unknown Protocol
All other values spare
2 Sign Character C
Default: FC
Example:
IN Protocol (CAP Phase 3): 3C
Table 135 IN Protocol atomic data field
Field Used In:
Module: IN.
Field Used In:
Module: IN.
B5.2.79 Incoming/Outgoing Metering Class
This field indicates metering values such as payphone, ordinary and test call. If chargeable, this
information is used to identify the billing rate of the call. This field is a single field as shown in
Table 136.
B5.2.80 Incoming/Outgoing Route Group
This field captures the details of the route group on which the call entered/left the MSC. The traffic
entering/leaving an operators network can be carried by different carriers to a given call
destination. The operator may group the trunks forming these incoming/outgoing connections into
route groups. Route groups are directional, that is a route group defines either incoming or outgoing
trunk connections. This means that a bi-directional trunk may be associated with two route groups:
one for the incoming connection and one for the outgoing connection. If the operator has defined
route groups, the route group number indicates which carrier the trunk group is associated with and
hence which carrier should be compensated for the use of their network. The field encoding is
shown in Table 137.
Field Used In:
Records: ICG, ICIP, OGG, Tr, OGIP.
1 Spare 0
2-3 Metering Class 00 - Unknown
01 - Ordinary
02 - Test
03 - Payphone
4 Sign Character C
Default: 000C
Example:
Incoming Metering Class (Test): 002C
Table 136 Incoming/outgoing metering class atomic data field
Field Used In:
1-3 Route Group {000....127}
4 Sign Character C
Default: FFFC
Example:
Incoming Route Group (Route Group 014): 014C
Table 137 Incoming/outgoing route group atomic data field
B5.2.81 Incoming/Outgoing Trunk Release Time
This field captures the release time of the incoming/outgoing trunk. It is encoded as a 16 character
date and time atomic data field as described in Section B5.2.46 on page 153.
B5.2.82 Incoming/Outgoing Trunk Seizure Time
This field captures the allocation time of the incoming/outgoing trunk. It is encoded as a 16
character date and time atomic data field as described in Section B5.2.46 on page 153.
NOTE In certain call scenarios, incoming or outgoing trunk seizure fields may contain
the time of a mobile channel allocation rather than a trunk seizure time:
The outgoing trunk seizure field in mobile originated call record contains the
time of a mobile channels allocation if the outgoing connection is to a mobile
station (MS). Similarly, the incoming trunk seizure time in a mobile terminated
call record may contain the channel allocation time of the incoming mobile
connection. In these cases the other fields normally associated with trunk
connections - trunk group, trunk member and route group - are not populated.
The incoming trunk seizure fields in a roaming call record may also contain
mobile channel allocation times if the incoming connection is to an MS.
In scenarios where a call consists of two or more legs, such as call forwarding,
the incoming/outgoing trunk seizure times in the MO, MT and/or roaming
records reflect the trunk seizure time of the associated party for the leg that the
record is generated on. If the associated party is a mobile and the mobile is
physically part of the call, then the trunk seizure time reflects the channel
allocation time of the mobile. Similarly, if the associated party is a trunk agent,
then the trunk seizure time reflects the seizure time of the trunk. For example,
take the call forwarding scenario, where MS(A) calls MS(B) who is forwarded to
ISUP(C). The outgoing trunk seizure time field in the MO record for MS(A)
contains the channel allocation time of MS(B). The incoming trunk seizure time
field in the MT Call Forwarding record for MS(B) contains the channel
allocation time of MS(A). Similarly, on the forwarding leg, MS(B) forwards to
ISUP(C), the outgoing trunk seizure time field in the MO Call Forwarding
record for MS(B) contains the outgoing trunk seizure time for ISUP(C). If party
C were a mobile, the incoming trunk seizure time field in the MT record for
MS(C) would contain the channel allocation for MS(B). In certain call
forwarding scenarios, such as CFU (call forwarding unconditional), CFNRC
(call forwarding, subscriber not reachable), CFB NDUB (call forwarding
because the network determines that the user is busy), MS(B)'s channel
allocation is not available. In these cases, the incoming/outgoing trunk seizure
time field in the MT or MO records respectively, is populated with the default
value.
Field Used In:
Records: Ro, ICG, OGG, Tr, ICIP, OGIP.
Field Used In:
B5.2.83 Incoming Trunk Group
This field describes the trunk group on which the call entered the MSC. It is defined as a value in
the range 00000 to 08191 with wrap around from 08191 to 00000. It is encoded as a 6 character
BCD/hex field as described in Section B5.2.10 on page 127.
In the location and channel information module, this field captures the local BSS trunk identity
when the mobile station is local to the MSC. That is, it captures details of the access trunks used to
form the connection from the BSS to the MSC. In the event of an inter-MSC handover this field
contains details of BSS trunks or inter-machine trunks depending on datafill.
In the structured billing records which contain this field (as opposed to the location and channel
information module), it captures details of the network trunks used to connect the call. If the
incoming trunk group is a BSS connection, the field contains the default value.
B5.2.84 Incoming Trunk Member
This field describes the trunk member on which the call arrived at the MSC. It is defined as a value
in the range 00000 to 09999 with wrap around from 09999 to 00000. It is encoded as a 6 character
BCD/hex field as described in Section B5.2.10 on page 127.
In the location and channel information module, this field captures the local BSS trunk identity
when the mobile station is local to the MSC. That is, it captures details of the access trunks used to
form the connection from the BSS to the MSC. In the event of an inter-MSC handover this field
contains details of BSS trunks or inter-machine trunks depending on datafill.
In the structured billing records which contain this field (as opposed to the location and channel
information module), it captures details of the network trunks used to connect the call. If the
incoming trunk member is a BSS connection, the field contains the default value.
B5.2.85 Information Transfer Capability
This field contains an indication of the nature of trunking facilities used in a data call (i.e. 3.1kHz,
fax, or UDI). These facilities may have different tariffs and hence this field may be used as a
distinguishing mechanism. The field encoding is shown in Table 138.
Field Used In:
Records: MT, Ro, ICG, OGG, Tr, ICIP, OGIP. Module: LaC.
Field Used In:
Records: MT, Ro, ICG, OGG, Tr, ICIP, OGIP. Module: LaC.
B5.2.86 Inter-Exchange/International Carrier (IC/INC) Call Event Status
This field contains an indication of the last event relating to the Inter-exchange/International carrier
signalling that occurred prior to call disconnection. IC/INC Call Event Status is applicable for
outgoing trunk records for trunks connected to an IC/INC directly or through an AT (Access
Tandem). For the incoming records a default value of FFFC is captured. It consists of a single field
as shown in Table 139.
NOTE 1 The existing events are applicable only for the PETMF trunk.
NOTE 2 In a non Feature group B or Feature group D signalling network the Inter-
exchange/International carrier field shall only be populated with the default
value in those defined records which include it.
Field Used In:
Module: DS.
1 Information Transfer Capability 0 - 3.1 kHz. Audio
1 - Fax Group 3
2 - Unrestricted Digital Information
2 Sign Character C
Example:
Information Transfer Capability (3.1kHz, Audio): 0C
Table 138 Information transfer capability atomic data field
Field Used In:
Module: EA.
1 Spare 0
2-3 Call event status 01 - First wink received at the originating MSC from the inter-exchange or international carrier.
03 - Second start dial wink received at the originating MSC from the inter-exchange or international carrier.
04 - Timer expiry at the originating MSC while waiting for an acknowledgment wink from the terminating office.
05 - Operator service or CAMA signalling off hook indication received at the originating MSC from the inter-
exchange or international carrier.
or
Off hook indication received at the originating MSC while waiting for a second start dial wink on a call that used
international carrier signalling.
07 - Acknowledgment wink received at the originating MSC.
10 - Answer received.
11 - Timer expiry at the originating MSC while waiting for a second start dial wink on a call that used international
carrier signalling.
12 - Timer expiry at the originating MSC while waiting for off hook indication in response to an Operator service
request or CAMA signalling.
13 - Off hook indication received at the originating MSC while waiting for a second start dial wink on a call that used
international carrier signalling.
FF - Call was abandoned or disconnected at the originating MSC prior to the receipt a connect wink from the
terminating office.
4 Sign Character C
Default: FFFC
Example:
IC/INC Call event status: 001C
Table 139 IC/INC call event status atomic data field
B5.2.87 Inter-Exchange/International Carrier (IC/INC) Prefix
This field contains the identity of the Inter-exchange/International carrier used and an indication of
the operator involvement in the call. It is specifically related to a call in an equal access
environment. It consists of a single field as shown in Table 140.
B5.2.88 Interworking Function Trunk Group
This field contains information about the interworking function (IWF) trunk group used to connect
the MSC and the IWF to support a GSM/UMTS data service. The data circuit requires two
connections between the MSC and the IWF, one on the mobile side of the call and one on the
network side. The data services information module captures this information in two IWF trunk
group fields. The field is defined as a value in the range 00000 to 08191 with wrap around from
08191 to 00000. The IWF trunk group consists of a single field as shown in Table 141.
B5.2.89 Interworking Function Trunk Member
This field contains information about the interworking function trunk member used to connect the
MSC and the IWF to support a GSM/UMTS data service. The field encoding is shown in Table 142.
Field Used In:
Module: EA.
1-8 Carrier Identity 00000000 ... 00099999
9 Operator 0 - Operator involved
1 - Direct dialled (No operator involved)
2 - Cannot determine if operator involved
10 Sign Character C
Default: FFFFFFFFFC
Example:
IC/INC Prefix: 000000021C
IC/INC Prefix (PETMF): 000003332C
Table 140 IC/INC prefix atomic data field
Field Used In:
Module: DS.
1-5 IWF Trunk Group {00000....08191}
6 Sign Character C
Default: FFFFFC
Example:
Interworking Function Trunk Group (Trunk 4/MS Side): 00004C
Table 141 Interworking function trunk group atomic data field

B5.2.90 IP Address Identity
B5.2.91. It identifies the IP which is connected to the assisting SSP. It is encoded as an eight
B5.2.91 IP Routing Address
This field captures the IP routing address which the assisting SSP (an MSC/SSP) uses to connect to
an intelligent peripheral (IP) during a CAMEL Phase 2 intelligent network (IN) service. The IP
provides services such as tones and announcements or digit collection. The assisting SSP provides
the services of its IPs to MSC/SSPs which do not have their own. These MSC/SSPs are called
initiating SSPs.
The SCP, which runs CAMEL services, sends the assisting SSP instructions on the facilities to
provide for a call using the CAMEL ConnectToResource (CTR) operation. The assisting SSP
composes an IP routing address to use on the ISUP connection to the IP. The address is composed of
three parts as shown in Table 143. The Assisting SSP gets the IP address identity from the CTR
message or from datafill, the MSCID from datafill and sets the counter itself. It captures the IP
routing address for the billing record. It then uses ISUP signalling to form the connection to the IP
using the IP routing address. It also uses ISUP signalling to form a connection between the IP and
the initiating SSP which requires the IP facilities. The IP routing address field consists of three
Field Used In:
Module: DS.
1-5 IWF Trunk Member {00000....09999}
6 Sign Character C
Default: FFFFFC
Example:
Interworking Function Trunk Member (Member 12/Network Side): 00012C
Table 142 Interworking function trunk member atomic data field
Field Used In:
Module: GASSP.
Field Used In:
Module: GASSP.
IP Address Identity 8 B5.2.90
MSC ID 6 B5.2.114
Counter 10 B5.2.41
Table 143 IP routing address
B5.2.92 IP SSP Capability
This field captures the IP SSP capability which describes what is required of an intelligent
peripheral during a CAMEL Phase 2 service. In this case, an initiating SSP (an MSC/SSP) requests
the use of an IP from an assisting SSP (another MSC/SSP). The assisting SSP requests instructions
about the IP from the SCP (Service Control Point) by sending it a CAMEL AssistRequest
Instructions message. The SCP sends the requirements in a ConnectToResource message. After
sending the ARI message to the SCP, the assisting SSP captures the IP SSP capability for the billing
record. The field is encoded as shown in Table 144.
B5.2.93 IWF Activation Timestamp
This field captures the time at which the IWF circuit was activated for a data call. For data calls, the
time of activation is not necessarily identical to the time of answer (the additional delay is usually
caused by modem synchronisation). The timestamp is encoded as a 16 character date and time
Field Used In:
Module: GASSP.
1 Spare F
2 IPRoutingAddress 0 - IPRoutingAddress Not Supported
1 - IPRoutingAddress Supported
3 Voice Back 0 - Voice Back Not Supported
1 - Voice Back Supported
4 Voice Information Via Speech Recognition 0 - Voice Information Not Supported, Via Speech Recognition
1 - Voice Information Supported, Via Speech Recognition
5 Voice Information Via Voice Recognition 0 - Voice Information Not Supported, Via Voice Recognition
1 - Voice Information Supported, Via Voice Recognition
6 Voice Announcement From Text 0 - Generation of Voice Announcements From Text Not Supported
1 - Generation of Voice Announcements From Text Supported
7-8 Reserved 00
9 End of Standard Part 0 - End of Standard Part
1 - This Value Is Reserved In Cap V.2
10 Sign Character C
Default: FFFFFFFFFC
Example:
IP SSP Capability: F00000000C
Table 144 IP SSP capability atomic data field
Field Used In:
Module: DS.
B5.2.94 IWF Diagnostic Code
This field contains a diagnostic code in the range 000 - 999 returned to the MSC by the
interworking function (IWF) during the use of a GSM/UMTS data service. The field encoding is
shown in Table 145.
B5.2.95 LCS Client Identity
This field captures the identifier of the LCS (location service) client. In the LCS model a client is
connected to a Gateway Mobile Location Centre (GMLC). The LCS client may request location
information from the GMLC, or be sent information from the GMLC as a result of a mobile
originated LCS request. The MSC obtains the LCS client id from the MOLR (mobile originated
location request) message or PSL (Provide Subscriber Location) message. The field encoding is
shown in Table 146.
Field Used In:
Module: DS.
1 -3 IWF Diagnostic Code 000 - Failed to Enable Channel
001 - Failed to Disable Channel
002 - Out of Memory
003 - Modem DSP Failure
004 - Modem Training Failure
005 - V42bis Decoder Error
006 - Invalid MIP Version
007 - Bearer Channel Resources Not Available
008 - Failed to Activate Call
009 - Invalid CIC Specified in MIP Message
010 - Failed to Register with Local Name Server
011 - Bearer Channel Failed to Register with Call Server
012 - Failed to Register with UDP
013 - Invalid Setup Request Parameter
014 - Static FMOs Not Allocated
015 - Data Compression Buffers Not Allocated
016 - Failed to Allocate Dynamic FMOs
4 Sign Character C
Default: FFFC
Example:
IWF fault code (002 - Out of Memory): 002C
Table 145 IWF diagnostic code atomic data field
Field Used In:
Record: LCS.
BCD or Full Hex String (26) 26 B5.2.9
Table 146 LCS client identity data field
B5.2.96 LCS Client Type
This field identifies the type of LCS client for the LCS service. There are a number of PLMN
operator services which can be used. Broadcast clients may send mobile stations information
related to their location, e.g. weather or travel information. Operations and Maintenance (O&M)
clients, which may reside in the home network (o-andM-Hpln) or in the visited network (o-andM-
VPLMN) may request location information for operation systems functions. Anonymous clients
may request information from a number of mobile stations e.g. for traffic engineering. CAMEL IN
(GSM/UMTS intelligent network) clients may use location information to provide IN services
(targetMSsubscribedService). The MSC obtains the LCS Client Type from the Provide Subscriber
Location (PSL) MT-LR message. The LCS client type field encoding is shown in Table 147.
B5.2.97 LCS Diagnostic
This field provides more detailed information about the cause for failure for an LCS service which
fails or is only partially successful. The information in the field comes from the Perform Location
Request message. The field encoding is shown in Table 148.
Field Used In:
Record: LCS.
1 Spare F
2-3 Value added Service 10
PLMN Operator Service 21 - Broadcast Service
22 - Operations and Measurements (O&M) in the home network (o-andM-Hpln)
23 - O&M in the visited network (o-andM-VPLMN)
24 - Anonymous Location
25 - targetMSsubscribedService
Emergency Service 30
Lawful Intercept 40
4 Sign Character C
Default: FFFC
Example:
LCS Client Type (Broadcast service): F21C
Table 147 LCS client type atomic data field
B5.2.98 LCS Initiation Time
This fields captures the time at which location information was requested. It is captured when the
MSC sends the RNC a location reporting control message (3GPP Release 99 LCS), or a Location
Related Data Request message (3GPP Release 4 LCS). It is also captured for 2G GSM LCS when
the MSC sends the Perform Location Request message to the SMLC. For multiple location request
the initiation time could be the same for each record. The LCS Initiation Time field is encoded as a
16 character date and time atomic data field as described in Section B5.2.46 on page 153.
B5.2.99 LCS Priority Level
This field captures the priority for a Location Service (LCS). The information in the field comes
from the Provide Subscriber Location message. The field encoding is shown in Table 149.
Field Used In:
Record: LCS.
Character Description Value
1 Congestion 0
Insufficient_Resource 1
Insufficient_measurement_data 2
Inconsistent_measurement_data 3
Location_procedure_not_comleted 4
Location_procedure_not_supported_by_TargetMS 5
QOS_NotAttainable 6
Position_method_not_available_in_network 7
Postion_methodZ_not_available_in_LocationArea 8
Default: FC
Example:
Insufficient_Resource: 1C
Table 148 LCS Diagnostic atomic data field
Field Used In:
Record: LCS.
Field Used In:
Record: LCS.
1 Padding Character F
2 Spare 0
3 Priority Level 0=Normal Priority
1=Higher Priority
4 Sign Character C
Default: FFFC
Example:
Notify Location Allowed: F01C
Table 149 LCS Priority Level atomic data field
B5.2.100 LCS Record Type
This field identifies the type of Location Service (LCS) requested by the user or by an LCS client.
For mobile Originated Location Requests (MO-LRs), the user may request location information and
also permit that location information to be transmitted to third parties. For Mobile Terminated
Location Requests (MT - LRs), LCS clients can use the location information to provide services,
perform operations and maintenance tasks, etc. The LCS record type obtained is based on the type
of LCS request. The field encoding is shown in Table 150.
B5.2.101 LCS Result
This field captures the result of the LCS request. The MSC captures the result from the Perform
Location Response (PLR) message for 2G LCS. For 3G LCS, the MSC captures the result from the
Location Report (3GPP Release 99) or from the Location Related Data Response message or the
Location Related Data Failure message (3GPP Release 4). The field encoding is shown in Table
151.
Field Used In:
Record: LCS.
1 MO-LR: Basic Self Location 1
MO-LR: Autonomous Self Location 2
MO-LR: Transfer to 3rd party 3
MT-LR 4
NI-LR (Emergency) 5
2 Sign Character C
Default: FC
Example:
LCS Record Type (Autonomous self location): 2C
Table 150 LCS record type atomic data field
B5.2.102 LCS Termination Time
This field captures the time at which location information was provided for a location service
(LCS). The time is captured when the MSC receives the location information from the Serving
Mobile Location Centre (SMLC). For UMTS LCS this happens when the MSC receives the
RANAP Location Report message (3GPP Release 99) or the Location Related Data (LRD)
Response / LRD failure message (3GPP Release 4) from the SMLC ((which is part of the Radio
Network Controller (RNC)). For GSM services, this happens when the SMLC ((which can be in the
core network or in the base station system (BSS)) returns the BSSMAP-LE Provide Location
Response message to the MSC. The LCS timestamp field is encoded as a 16 character date and time
Field Used In:
Record: LCS.
1 Spare 0
2-3 Success 00
LCS Cause Unspecified 01
System Failure 02
Protocol Error 03
Data Missing 04
Unexpected Data Value 05
Position Method Failure 06
Target MS Unreachable 07
Location Request Aborted 08
Facility Not Supported 09
Inter BSC Handover Ongoing 10
Intra BSC Handover Complete 11
Congestion 12
Unauthorized LCS Client 13
Unauthorized Requesting Network 14
Subscription Violation 15
SOC Idle 16
4 Sign Character C
Default: Not applicable, either the success or failure cause will be recorded.
Example:
LCS Result (Illegal Subscriber): 006C
LCS Result (Success): 000C
Table 151 LCS result atomic data field
Field Used In:
Record: LCS.
B5.2.103 Local Reference Number
This field captures the local reference number which is used to correlate the billing information
generated for CAMEL/IN services. The reference number is assigned to the call by the CCF (call
control function) on the MSC/SSP. It may be used for correlation between SSP billing and SCP
billing. For a particular detection point, the same local reference number is captured in the IN
information and the CAMEL charging information modules and this allows them to be correlated.
B5.2.104 Location Area Code
This field captures the mobile network code (MNC), mobile country code (MCC) and location area
code (LAC) of the MSC serving a mobile subscriber. The information is captured during a normal
voice/data call, handover, short message service sending and receipt, and for call independent
supplementary services (CISS) interactions. The location area code consists of a single field and
may be encoded as shown in Table 153 (2-digit MNCs) and Table 154 (3-digit MNCs).
(continued)
Field Used In:
Modules: CC, IN.
1 Spare 0
2-11 Local Reference Number 0000000001 ... 9999999999
12 Sign Character C
Default: 00000000000C
Example: 00000000023C
Table 152 Local reference number atomic data field
Field Used In:
Record: SSA. Modules: LaC, LO.
1 Spare 0
2-4 Mobile Country Code {000....999}
5-6 Mobile Network Code {00....99}
7-11 Location Area Code {00000....99999}
12 Sign Character C
Default: 00000000000C
Example:
Location Area Code: 00011300234C
Table 153 Location area code atomic data field - 2-digit MNCs
12 Sign Character C
Default: 00000000000C
Example:
Table 154 Location area code atomic data field - 3-digit MNCs
NOTE By default, the MSC checks Mobile Network Codes (MNCs), but this facility
may be disabled during an upgrade, for example when upgrading a network to
use 3-digit MNCs. During this time, if a mobile station using 2-digit MNCs
makes a call and the MSC is setup to use 3-digit MNCs, the location area code
field displays Hex F for the third MNC digit.
B5.2.105 Logical Network
This field captures a geographical origin or destination for a call. This origin or destination area is
operator defined. The MSC allows the service provider to divide the world or their service area into
a maximum of 16 areas called logical Networks. Out of these 16 allowed logical networks two are
reserved to denote an unknown logical network,0 and the home PLMN,1.In outgoing trunk calls
the logical network value is provided by dialled digit analysis. For incoming trunk calls the logical
network is assumed to be 0 i.e. unknown. For more information on logical networks, refer to Part C,
Tariff Administration on page 319. The field encoding is shown in Table 155.
B5.2.106 Message Reference
This field captures the number provided by the mobile station for each short message submitted to
the service centre. It is defined as a binary coded decimal value in the range 00000 to 00255. It is
encoded as a 6 character BCD/hex encoding described in Section B5.2.10 on page 127.
B5.2.107 Metering Zone
This field defines a separate charging zone of a logical network (B5.2.105). For example if Europe
is defined as a logical network then the United Kingdom may be defined as a metering zone within
this logical network. The MSC allows up to 64 metering zones per logical network. On both
incoming and outgoing trunk calls the metering zone is determined by the analysis of the called
number. At the originating and terminating MSC the metering zone of the calling and called user
respectively is determined from the location area code and cell identity/service area code obtained
during paging. For more information on metering zones, refer to Part C, Tariff Administration on
page 319. The field encoding is shown in Table 156.
Field Used In:
1 Spare 0
2-3 Logical Network {00....15}
4 Sign Character C
Default: FFFC
Example:
Logical Network: 012C
Table 155 Logical network atomic data field
Field Used In:
Record: SMSMO.
NOTE For the outgoing trunk, roaming and transit records the logical network and
metering zone captured shall be the logical network and metering zone
associated with the translation of the called number i.e. the destination. For
incoming trunk records the logical network and metering zone shall be set to
Unknown. In these records the only conclusive evidence captured about the
origin of the call is in the route group field.
B5.2.108 MGW (Media Gateway) Number
This field captures the internet protocol (IP) address of the MGWs serving the bearer path for
Bearer Independent Call Network (BICN) calls. The MGW number is captured upon receipt of the
RAB assignment response during call establishment. Each MGW connected to the MSC is
provisioned in the table GWINV. Each MGW has an entry in the IPADDR field which defines its
MGW Number. The field encoding is shown in Table 157.
B5.2.109 MGW Seizure Time
This field captures the time at which the MGW is seized in a BICN call. It is obtained from the
RAB assignment response message during call establishment. The MGW Seizure Time field is
encoded using the 16 character date and time field atomic field as described in Section B5.2.46 on
page 153.
Field Used In:
1 Spare 0
2-3 Metering Zone {00....63}
4 Sign Character C
Default: FFFC
Example:
Metering Zone: 012C
Table 156 Metering zone atomic data field
Field Used In:
Modules: BICN.
1 Spare 0
2-13 BCD or Hex String (11) {0,1,2,3,4,5,6,7,8,9}
14 Sign Character C
Default: FFFFFFFFFFFFFC
Example:
MGW Number: 0047104088034C
Table 157 MGW Number atomic data field
Field Used In:
Module: BICN.
B5.2.110 MM (Mobility Management) Event
This field is used to capture the result of an MM event that the MSC reports to the Service Control
Point (SCP) as part of the CAMEL Phase 3 mobility management service. The field encoding is
shown in Table 158.
B5.2.111 Module Code
This field contains a code value which identifies the information module containing the field. The
Field Used In:
Record: LU.
1 Spare 0
2 MM Result 0 - Failed to send Note MM Event message
1 - Note MM Event message sent
3 MM Event 0 - Location Update on the Same VLR
1 - Location Update on a different VLR
2 - Attach of IMSI
3 - Detach of IMSI by the MS
4 - Detach of IMSI by the Network
F - Unknown
4 Sign Character C
Default: 00FC
Example:
MM Event (Message sent, Attach of IMSI): 012C
Table 158 MM Event atomic data field
NOTE The patching information module provides information for additional billing
capabilities patched into the MSC for particular customers. The module is only
used by Nortel patch designers. When the patch is sourced in a normal MSC
product release, the patch is freed up for use by other patch designers.
The market-specific module codes are listed in the following sections:
B5.3.9 on page 249 (PCS market module codes)
B5.4.3 on page 255 (Singapore market code)
B5.5.2 on page 258 (German and Austrian market module code).
Field Used In:
Modules: All modules.
Character Description Values (Billing)
1-3 Module Code 000 - End of Module List
001- Unused
002 - Bearer Services Information
003 - Location and Channel Information
004 - Location Only Information
005 - Supplementary Services Information
006 - Teleservices Information
007 - AoC Information
008 - Tariff Class Information
009 - Data Information
010 - Other Agent Information
012 - Equal Access Information
013 - Partial Information
016 - Trunk Usage Information
018 - IN Information
019 - IN Charging Information
020 - Generic Address Information
022 - Network Call Reference Information
023 - CAMEL Charging Information
025 - Mobile Number Portability Information
026 - GSM Assisting SSP Information
027 - CAMEL Short message Service (SMS) Information
028 - Patching Information
029 - Bearer Independent Core Network
4 Sign Character C
Default: Not applicable
Example:
Module Code (Bearer Services Information): 002C
Table 159 Module code atomic data field
B5.2.112 MS Classmark
This field contains the mobile station classmark employed by the served MS on call setup. The
Phase 2 Revision level is now supported in this field. The field encoding is shown in Table 160.
Field Used In:
Records: MO, MT, SMSMO, SMSMT, SSA.
1 Classmark 1 Classmark 1
2 Classmark 2
2 Revision Level 0 Reserved For Phase 1
1 Used By Phase 2 MSs
2 Used By Mobile Stations Supporting R99 or Later Versions
3 Encryption Algorithm 0 Algorithm A5/1 Available
F Algorithm A5/1 Not Available
4 RF Power Capability 0 Class 1
1 Class 2
2 Class 3
3 Class 4
4 Class 5
7 - Class is irrelevant
Option
5 15 Character 1 = 1 - FFFFFFFFFFF
Or
5 Character 1 = 2 Short Message Capability 0 Short Message Capability Not Present
1 - Short Message Capability Present
6 Frequency Capability 0 Extension Band Not Supported
1 Extension Band Supported
7 PS Capability 0 PS Capability Not Present
1 PS Capability Present
8 Encryption Algorithm 5/2 0 Algorithm 5/2 Not Available
1 Algorithm 5/2 Available
9 Encryption Algorithm 5/3 0 - Algorithm 5/3 Not Available
1 - Algorithm 5/3 Available
10 Classmark 3 Indicator 0 Classmark3 Not Present
1 Classmark3 Present
11 Screening Indicator 0 Phase 1 MS
1 Phase 2 MS
2 UNDEFINED1_MS
3 UNDEFINED2_MS
12 VGCS 0 VGCS Capability Not Present
1 VGCS Capability Present
13 VBS 0 VBS Capability Not Present
1 VBS Capability Present
(continued)
Table 160 MS Classmark atomic data field
NOTE The MS Classmark field captures the value #F in character 3 if the mobile
handset signals the value 1 (A5/1 algorithm not available) in the A5/1 field of the
MS Classmark 1 or 2 information element. See 3GPP TS 24.008 [5].
B5.2.113 MSC Address
This field is used to capture information generated either by a CAMEL (GSM/UMTS intelligent
network) service or during the optimal routing of a late forwarded call. For a CAMEL service, this
field contains the address of the MSC/SSP initiating the service. For an optimally routed call, this
field contains the address of the gateway MSC (GMSC). The GMSC sets up the original call to the
called party and, if optimisation is successful, it also sets up the forwarded call leg. The MSC
Address consists of two fields as shown in Table 161.
B5.2.114 MSC ID
B5.2.91 on page 184. It provides the identifier of the assisting SSP to which the IP is connected. It
is encoded as a six character BCD/hex string as defined in Section B5.2.10 on page 127.
Option
14 Character 10 = 0 - F
Or
14 Character 10 = 1 Encryption Algorithm 1 Algorithm 5/4 Available
15 - F - Spare
16 Sign Character C
Default: FFF0FFFFFFFFFFFC
Example:
MS Classmark (Classmark 2, Class 5, Short Message Capability Present): 2004100FFF000FFC
Field Used In:
Module: NCR.
Table 161 MSC address data field
Field Used In:
Module: GASSP.
Table 160 MS Classmark atomic data field
B5.2.115 MSC Number
This field captures the E.164 number of the MSC producing the record. It consists of two fields as
shown in Table 162. The office parameter GSMMSC_Number in table OFCVAR sets the MSC
Number.
B5.2.116 MSC/MGW Number
This field captures the number of the MSC or the Media Gateway (MGW) which provides the
conference circuit for a multi-party conference call. It consists of two fields as shown in Table 163.
In 3GPP Release 99 networks, or in earlier networks, the MSC provides conference circuits. In this
case, the field identifies the MSC which provided the conference circuit for a call.
In 3GPP Release 4 networks (where the MGW provides the bearer plane connections) a conference-
enabled MGW can provide conference circuits for a call. In this case, the MSC/MGW Number
contains the MGW Number. The NPI field contains the default value FFFFFC. The BCD or Hex
String field contains the 12-character MGW number, padded with leading Fs and followed by the
end of field delimiter C. Each MGW has an entry in the GWINV table where the IPADDR field
defines its MGW Number.
Field Used In:
Records: MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, SSA, Ack.
Modules: LaC, LO.
Table 162 MSC Number data field
Field Used In:
Record: CEU.
Table 163 MSC/MGW Number data field
B5.2.117 Network Call Reference Number
This field contains the network call reference number generated for a CAMEL (GSM/UMTS
intelligent network) service or for the optimal routing of a late forwarded call. Its function is to
allow the downstream processor to correlate the billing information which may be generated by
these services. For a CAMEL service, the gsmSCF (the CAMEL service control function) may also
generate billing information and this too can be correlated with the records generated by the MSC/
SSP. Note that any capabilities of the gsmSCF are outside the scope of this specification. The
network call reference number is generated by the MSC/SSP initiating the CAMEL service. It is
signalled to the gsmSCF, and depending on the call scenario, to other MSC/SSPs. This field has no
relationship to the local call reference number described in Section B5.2.18.
For an optimally routed call, the GMSC which routes the call to the originally called party sends a
network call reference number to the HLR. The HLR sends this information to the VMSC of the
called party. When the VMSC encounters the forwarding condition, it includes the network call
reference number in the message (the MAP ResumeCallHandling message) that it sends to the
GMSC to attempt to optimise the forwarded leg.
For a mobile originated short message, the network call reference number in the network call
reference information module and the MSC Number in the SMS-MO record are used to correlate
the billing information generated for the service.
The field is encoded as an 18 character BCD or full hex atomic data field as described in Section
B5.2.9 on page 127.
B5.2.118 New AN (Access Network)
This field identifies the type of network involved in the provision of the CAMEL Phase 3 mobility
management service. The field encoding is shown in Table 173.
NOTE If the New AN information is not available, the field defaults to value 0C.
Field Used In:
Module: NCR.
Field Used In:
Record: LU.
1 - UMTS
2 Sign Character C
Default: 0C.
Example:
Access Network (UMTS Network): 1C
Table 164 New AN atomic data field
B5.2.119 New Cell-SAC Id
This field identifies the location of a mobile subscriber and is captured during the provision of the
CAMEL Phase 3 mobility management service. The field encoding is shown in Table 174.
B5.2.120 New LAC (Location Area Code)
This field captures the Mobile Network Code (MNC), the Mobile Country Code (MCC) and the
Location Area Code (LAC) of the MSC providing location information to the Service Control Point
(SCP) as part of the CAMEL Phase 3 mobility management service. The new LAC consists of a
single field and may be encoded as shown in Table 175 (2-digit MNCs) and Table 176 (3-digit
MNCs).
Field Used In:
Record: LU.
6 Sign Character C
Default: FFFFFC
Example:
Cell-SAC Id: 00124C
Table 165 New Cell-SAC id atomic data field
Field Used In:
Record: LU.
1 Spare 0
12 Sign Character C
Default: 00000000000C
Example:
Table 166 New LAC atomic data field - 2-digit MNCs
12 Sign Character C
Default: 00000000000C
Example:
Table 167 New LAC atomic data field - 3-digit MNCs
B5.2.121 New MSC Id
This field captures the E.164 number of the MSC which is providing the CAMEL Phase 3 mobility
management service to a subscriber. It consists of two fields as shown in Table 177.
B5.2.122 Number of Fax Pages
This field captures the number of pages transmitted during a call using the facsimile data service.
The information is returned to the MSC by the interworking function (IWF) supporting the service.
The field either contains a page count in the range 000 to 999 for a fax call, or the default value for
a non-fax call. It is encoded as an 4 character BCD/hex atomic data field as shown in Section
B5.2.10 on page 127.
B5.2.123 Number Type
This field identifies the type of number in fields which contains addressing information such as the
called/calling party number, dialled digits among others. It is a generic field type and is used in a
number of billing fields containing addresses. The field encoding is shown in Table 169.
NOTE A Number type of None, MSISDN, or MSRN implies that there shall be
Numbering plan identifier information associated with the number.
Field Used In:
Record: LU.
Table 168 New MSC id data field
Field Used In:
Module: DS.
1 Number Type 0 - None
1 - IMSI
2 - MSISDN
3 - MSRN
4 - IMEI
5 - TMSI
6 - Dialled Digits
7 - Charge Number/ANI
8 - Generic Address Parameter
9 - Normalised
2 Sign Character C
Default: 0C
Example:
Number Type (IMEI): 4C
Table 169 Number type atomic data field
B5.2.124 Numbering Plan Identifier
This field contains information about the type of number contained in an address or number field,
for example the called and calling number fields. The field encoding is shown in Table 170.
NOTE 1 There are two default values for the numbering plan identifier (NPI). If the
number is part of a dial or numbering plan, for example an MSISDN or an
MSRN, the NPI value defaults to 01000C. For numbers which are not defined as
part of a numbering plan, for example an IMSI, the NPI defaults to FFFFFC to
show that it is not applicable.
NOTE 2 The extension indicator field is set to 1 - no extension for off-board IN
services.
B5.2.125 Off Air Call Setup
This field is a simple boolean indicator which indicates whether or not an Off Air Call Setup was
used. It is encoded as a boolean type atomic field as described in Section B5.2.14 on page 129.
NOTE The intelligent population of this field is not supported by the MSC. In the
records in which this field is present the default value will be inserted.
1 Spare 0
2 Extension Indicator 0 - Extension
1 - No Extension
3 (See Note) Nature of Address Indicator 0 - Unknown
1 - International Number
2 - National Significant Number
3 - Network Specific Number
4 - Dedicated PAD Access
4-5 (See Note) Numbering Plan Indicator 00 - Unknown
01 - ISDN (E.164) Number
02 - Spare
03 - Data Numbering Plan
04 - Telex NUmbering Plan
05 - National Use
06 - National Use
07 - Spare
08 - National Numbering Plan
09 - Private Numbering Plan
6 (See Note) Sign Character C
Default: 01000C (See Notes)
FFFFFC
Example:
Numbering Plan Identifier (Extension, Unknown, National Use): 00005C (See Note)
Table 170 Numbering plan identifier atomic data field
Field Used In:
Records: MO, MT.
B5.2.126 Off-Board IN Service Identifier
This field identifies the IN (intelligent network) service applied by the IN service node. In off-board
IN services, the service node makes a call to all numbers stored against the IN service until one of
the numbers accepts the call. For each call attempted, the service node sends an ETSI/ANSI PRI
setup message to the MSC containing the off-board IN service identifier and the charge number.
The MSC captures the service identifier returned by the service node in the off-board IN service
identifier field. The identifier consists of a single field as shown in Table 171.
NOTE The MSC captures the off-board IN service identifiers but does not decide their
meaning. The meaning of individual identifiers is left to the service provider and
the network operator.
B5.2.127 Off-Board IN Service Indicator
This field indicates the type of IN service applied by the IN service node. In off-board IN services,
when the call is answered, the service node sends a Facility Request (FAR) message to the MSC to
request the dual port RLT feature. The FAR message contains the off-board IN service indicator and
the charge number. The MSC captures the service indicator in the FAR message in the off-board IN
service Indicator field. The indicator consists of a single field as shown in Table 172.
NOTE 1 The off-board IN service indicator is right justified in the field and padded with
leading zeros.
NOTE 2 The MSC captures the off-board IN service indicators but does not decide their
meaning. The meaning of individual indicators is left to the service provider and
the network operator.
Field Used In:
Module: IN.
1 Unused 0
2-3 Off-Board IN Service Identifier 00-04 Unused
05-15 Off-board IN service identifier
4 Sign C
Default: FFFC
Example:
IN Service Identifier: 014C
Table 171 Off-board IN service identifier atomic data field
Field Used In:
Module: IN.
1-3 Off-Board IN Service Indicator 000 - 255
4 Sign C
Default: FFFC
Example:
IN Service Indicator: 001C
Table 172 Off-board IN service indicator atomic data field
B5.2.128 Old AN (Access Network)
This field identifies the type of network involved in the provision of the CAMEL Phase 3 mobility
management service. The field encoding is shown in Table 173.
NOTE If the Old AN information is not available, the field defaults to value 0C.
B5.2.129 Old Cell-SAC Id
This field identifies the location of a mobile subscriber and is captured during the provision of the
CAMEL Phase 3 mobility management service. The field encoding is shown in Table 174.
B5.2.130 Old LAC (Location Area Code)
This field captures the Mobile Network Code (MNC), Mobile Country Code (MCC) and Location
Area Code (LAC) of the MSC providing location information to the Service Control Point (SCP) as
part of the CAMEL Phase 3 mobility management service. The old LAC consists of a single field
and may be encoded as shown in Table 175 (2-digit MNCs) and Table 176 (3-digit MNCs).
Field Used In:
Record: LU.
1 - UMTS
2 Sign Character C
Default: 0C
Example:
Access Network (UMTS Network): 1C
Table 173 Old AN atomic data field
Field Used In:
Record: LU.
6 Sign Character C
Default: FFFFFC
Example:
Cell-SAC Id: 00124C
Table 174 Old Cell-SAC id atomic data field
B5.2.131 Old MSC Id
This field captures the E.164 number of the MSC which is providing the CAMEL Phase 3 mobility
management service to a subscriber. It consists of two fields as shown in Table 177.
B5.2.132 Operation History
This field captures the details of the operations exchanged between the MSC/SSP and the gsmSCF
during the provision of a CAMEL Short Message Service (SMS). Each non-default value captured
in the field represents one successful message exchange. For most of the SSF errors to an operation
(error/reject/abort), only the SSF Error operation is captured in the operation history. The sequence
in which the messages are captured in the field is from left to right, that is, the indication of the first
message exchanged is in the left-most non-default character. The field can capture up to 25 message
indications. If more than 25 are received, the first 25 are captured and the other indications are not
captured in the field. The field encoding is shown in Table 178.
Field Used In:
Record: LU.
1 Spare 0
12 Sign Character C
Default: 00000000000C
Example:
Table 175 Old LAC atomic data field - 2-digit MNCs
12 Sign Character C
Default: 00000000000C
Example:
Table 176 Old LAC atomic data field - 3-digit MNCs
Field Used In:
Record: LU.
Table 177 Old MSC id data field
B5.2.133 Operation Indication
This field contains information about the intelligent network (IN) services or facilities used during
an on-board IN call on the MSC/SSP. It may indicate one of the SCP-directed services call
translation or call diversion, or a connection to an intelligent peripheral (IP). It is also used in some
records created for terminating IN services to indicate that they were created as part of the internal
mechanism for providing the service. The field encoding is shown in Table 179.
(continued)
Field Used In:
Module: CSMS.
1 - 25
Each character in the field can take
one of the indicated values
Operation History 1 - Unsupported Operation
2 - InitialDP SMS
3 - SCP Empty End
4 - SSF Empty End
5 - SCP Error (Error/reject/abort)
6 - SSF Error (Error/reject/abort)
7 - EventReportSMS
8 - ConnectSMS
9 - ContinueSMS
A - Release SMS
B - FCI (Furnish Charging Information) SMS
C - RequestReportSMS
D - ResetTimerSMS
26 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFFFFFC
Example:
Operation History: FFFFFFFFFFFFFFFFFFF2BBC87C
Each value in the field represents a different operation. The left most non-default value (1 in the example) indicates the first
successful message exchanged. The maximum number of operations recorded is 25.
Table 178 Operation history atomic data field
Field Used In:
Module: IN.
1 Operation Indication 0 - SCP call translation (see NOTE 1)
1 - SCP call diversion (see NOTE 2)
2 - IP interaction
3 - Call extension (see NOTE 3)
4 - Tone generation (see NOTE 4)
5 - Internal IP interaction
6 - Ring Back IP interaction
All other values spare
2 Sign Character C
Default: 0C
Example:
Operation Indication (SCP call diversion): 1C
Table 179 Operation indication atomic data field
NOTE 1 If the SCP sends the MSC/SSP a Connect message containing a new Destination
Routing Address (DRA), but no redirectionInformation, this is called SCP Call
Translation. The MSC/SSP attempts to terminate the call towards the address
indicated in the DRA.
NOTE 2 If the SCP sends the MSC/SSP a Connect message containing a new Destination
Routing Address (DRA) and a redirectionInformation parameter indicating call
diversion, this is called SCP Call Diversion. SCP Call Diversion can be applied
for an originating or terminating call.
NOTE 3 This is a terminating IN service triggered at DP12. As a result of a terminating
service, e.g. IN call forwarding, the call may be extended to a new party. The
MSC/SSP creates a mobile originated call forwarding attempt record for the new
leg. It has an appended IN information module in which the operation indication
field indicates call extension and the detection point field indicates none. All of
the other fields in the module contain default values. This shows that the call
record was not generated at an IN detection point and therefore that it is not a
billable event. Operators can use the module for information about the
application of the service, but can ignore it for billing purposes.
NOTE 4 The tone generation value is only captured for the proprietary CS-1R INAP
geozone tone service
2
.
B5.2.134 Original Calling Number
This field captures information signalled on incoming trunks on an MSC acting as a point of
interconnect to another network. The field is populated only if both the calling party number and
redirecting number are signalled in the IAM (initial address message). In this case, the calling party
number is captured in this field. The field can also capture information more widely for basic calls
and during call forwarding. For forwarded calls, this field captures the number of the original
calling party while the calling number field (B5.2.26 on page 139) captures the number of the
redirecting party. It consists of three fields as shown in Table 180.
NOTE The original calling number captured for I-ISUP (Australian interconnect ISUP)
connections may contain a leading 0 (zero) before the national significant
number (0+NSN format).
2.
Geozone tones are supported only on the stand-alone GSM/UMTS MSC configuration. The Nortel GSM/
UMTS MSC call server does not support Geozone tones in the BICN packet network configuration. Geozone
tones are not supported for the BICN portion of a hybrid GSM/UMTS MSC/MSC call server.
Field Used In:
Module: GA.
Table 180 Original calling number data field
B5.2.135 Outgoing Trunk Group
This field describes the trunk group on which the call left the MSC. It is defined as a value in the
range 00000 to 08191 with wrap around from 08191 to 00000. It is encoded as a six character BCD/
hex string as defined in Section B5.2.10 on page 127. In the structured billing records which contain
this field it captures details of the network trunks used to connect the call. If the outgoing trunk
group is a BSS connection, the field contains the default value.
B5.2.136 Outgoing Trunk Member
This field describes the trunk member on which the call left the MSC. It is defined as a value in the
range 00000 to 09999 with wrap around from 09999 to 00000. It is encoded as a six character BCD/
hex string as defined in Section B5.2.10 on page 127. In the structured billing records which contain
this field it captures details of the network trunks used to connect the call. If the outgoing trunk
member is a BSS connection, the field contains the default value.
B5.2.137 Partial Record Event Code
This field captures a simple indication of the type of partial record i.e. whether the record is the
first, a subsequent, or the last record in the set generated in association with a particular call. For
avoidance of doubt, if the first partial record is also the last then the indication employed shall be,
last. The field encoding is shown in Table 181.
Field Used In:
Records: MO, Ro, ICG, OGG, Tr, ICIP, OGIP.
Field Used In:
Records: MO, Ro, ICG, OGG, Tr, ICIP, OGIP.
Field Used In:
Module: PI.
1 Spare 0
2-3 Event Code 01 - First
02 - Subsequent
03 - Last
4 Sign Character C
Default: FFFC
Example:
Partial record event code: 001C
Table 181 Partial record event code atomic data field
B5.2.138 Partial Record Reason
This field describes the reason for the partial record generation, for example 000C indicates a long
duration call and 002C indicates a location change. The field encoding is shown in Table 182.
B5.2.139 Partial Record Reference Number
This field captures an integer that may be used to identify the set of partial records associated with a
particular call. It is defined as a value in the range 0000001 to 9994239 with wrap around from
9994239 to 0000001. It is encoded as an eight character BCD/hex string as defined in Section
B5.2.10 on page 127.
B5.2.140 Partial Record Sequence Number
This field captures an integer value that may be used to order the partial records generated
associated with a particular call. It is defined as a value in the range 00001 to 65535. It is encoded as
a six character BCD/hex string as defined in Section B5.2.10 on page 127.
Field Used In:
Module: PI.
1 Spare 0
2-3 Reason 00 - Long duration
01 - Service change
02 - Location change
03 - Classmark change
04 - AoC parameter change
05 - Radio channel change
06 - CDR size
07 - Call release
08 - Call re-establishment
4 Sign Character C
Default: FFFC
Example:
Partial record reason (Long duration): 000C
Table 182 Partial record reason atomic data field
Field Used In:
Module: PI.
Field Used In:
Module: PI.
B5.2.141 Party To Charge
This field contains an indicator that specifies which party should be charged for the CAMEL (GSM/
UMTS intelligent networking) service. The field encoding is shown in Table 183.
NOTE The party to charge is always set to 01C (calling party) for CAMEL mobile
originated SMS.
B5.2.142 Patch Identity
This field captures the identity of the patch. It is encoded as a 12 character BCD/hex atomic data
field as shown in Section B5.2.10 on page 127.
B5.2.143 Ported Status
This field captures the status of a number which is in the portable number range defined for the
mobile number portability service. The number may have been ported to another network or may
not be ported and remain with the original service provider. The field encoding is shown in Table
184.
Field Used In:
Module: CC.
1 Padding F
2-3 Party to Charge 01 - Leg 1 (calling party)
02 - Leg 2 (called party)
4 Sign Character C
Default: F01C.
Example: F02C - leg 2 (called party) to be charged
Table 183 Party to charge atomic data field
Field Used In:
Module: Pa.
Field Used In:
Module: MNP.
1 Query Method Type 0 Unknown
1 Ported Number
2 Non-ported Number
2 Sign Character C
Default: 0C.
Example: 1C - Ported number
Table 184 Ported status atomic data field
B5.2.144 Positioning Data
This field captures information about the positioning method used or attempted during a Location
Service (LCS) to provide the subscribers location. The positioning method is used to get an
estimate of the subscribers geographical location. The Positioning Data is obtained from Location
Report message for 3G LCS and from the Perform Location Response message for 2G LCS. For
more information, refer to 3GPP TS 25.305 [8] for UTRAN positioning methods and to 3GPP TS
43.059 [13] for GERAN positioning methods. The field encoding is shown in Table 185 and
information about the positioning values and methods is provided in Table 186.
Field Used In:
Module: LCS.
Character Description Values: see Table 186
1-2 1st Positioning method 00 - 12
3 1st Usage 0 - 5
4-5 2nd Positioning method 00 - 12
6 2nd Usage 0 - 5
7-8 3rd Positioning method 00 - 12
9 3rd Usage 0 - 5
10-11 4th Positioning method 00 - 12
12 4th Usage 0 - 5
15 5th Usage 0 - 5
18 6th Usage 0 - 5
21 7th Usage 0 - 5
24 8th Usage 0 - 5
27 9th Usage 0 - 5
28 Sign Character C
Default: FFFFFFFFFFF FFFFFFFFFFFFFFFFC
Example:
Attempted Unsuccessfully: result used to generate location, TOA: 011FFFFFFFFFFFFFFFFFFFFFFFFC
Table 185 Positioning Method atomic data field
B5.2.145 Post-Translated Called Party Number
This field captures the called party number generated by the MSCs translation system as shown in
Table 187. As a result of translations, the originally dialled subscriber number, the Mobile
Subscriber ISDN number (MSISDN), may be re-formatted. For example an MSISDN in
international format can be re-formatted to national format by having the international digits
removed. The post-translated MSISDN is captured in this field.
Description Values
Usage 0 - Attempted Unsuccessfully due to failure or Interruption
1 - Attempted Successfully: result not used to generate location
2 - Attempted Successfully: result used to verify but not generate location
3 - Attempted Successfully: result used to generate location
4 - Attempted Successfully: actual method used by the MS cant be determined
5 - Nil positioning Usage
Positioning method 00 - Timing Advance
01 - Reserved 1
02 - Reserved 2
03 - Mobile Assisted Enhanced Observed Time Difference (EOTD)
04 - Mobile Based EOTD
05 - Mobile Assisted Global Positioning System (GPS)
06 - Mobile Based GPS
07 - Conventional GPS
08 - Time-Difference-Of-Arrival (U-TDOA)
09 - UTRAN Observed Time Difference Of Arrival (OTDOA)
10 - UTRAN Idle Period Downlink (IPDL)
11 - UTRAN Round Trip Time (RTT)
12 - UTRAN Cell Identity (CellID)
Table 186 Values for Positioning Method and Usage
Field Used In:
Module: GA.
Table 187 Post-translated called party number data field
B5.2.146 Pre-Translated Called Party Number
This field captures the pre-translated called party number as shown in Table 188. The number
generated by the translation process on the MSC is captured in the called number field (see
B5.2.22). For call-redirection/forwarding scenarios (both UMTS and intelligent networking), the
pre-translated called number for each leg of the call is captured in this field.
B5.2.147 Priority Call Cause
This field contains the reason for the release of the connection to the high priority call as reported
by the mobile station making an acknowledgement call to the integrated acknowledgement centre
(IAC). It consists of a single field as shown in Table 189.
Field Used In:
Module: GA.
Table 188 Pre-translated called party number data field
Field Used In:
Record: Ack.
1-3 Priority call cause 000 - No error
001 - Mobile was powered off when receiving (power fail)
002 - Call was interrupted due to radio link error
004 - Spare
008 - Spare
016 - Call was left on a user command
032 - Spare
064 - Spare
128 - Spare
4 Sign Character C
Default: 000C.
Example:
Priority call cause (no error): 000C
Table 189 Priority call cause atomic data field
B5.2.148 Priority Call Duration
This field contains the duration of a high priority call measured in tenths of a second as shown in
Table 190. The field is encoded as a binary coded decimal (BCD) value. The mobile station sends
the call duration information when it makes the acknowledgement call to the integrated
acknowledgement centre (IAC). The user-to-user information element (UUS1) in the SETUP
message contains the call duration information in the Tdur field.
B5.2.149 Priority Call Tag
This field specifies whether the mobile station making an acknowledgement call to the integrated
acknowledgement centre (IAC) was the initiator or a receiver of the original high priority group
call. It consists of a single field as shown in Table 191.
B5.2.150 Priority Level
This field contains the priority level of a high priority group call. The field is captured in the
acknowledgement record generated by the integrated acknowledgement centre (IAC). It consists of
a single field as shown in Table 192.
Field Used In:
Record: Ack.
1 Unused 0
2-9 Call duration in tenths of a second 00000000 - 16777215
10 Sign Character C
Default: 000000000C.
Example:
Priority call duration: 001200600C
Table 190 Priority call duration atomic data field
Field Used In:
Record: Ack.
1 Initiator/receiver of original group call 0 - Spare
1 - Spare
2 - Receiver
3 - Initiator
2 Sign Character C
Example:
Priority call tag (Initiator): 3C
Table 191 Priority call tag atomic data field
B5.2.151 Priority Release Time
This field contains the time difference, measured in tenths of a second, between the end of the high
priority call and the acknowledgement call made to the integrated acknowledgement centre (IAC).
It consists of a single field as shown in Table 193. The field is encoded as a binary coded decimal
(BCD) value. The user-to-user information element (UUS1) in the SETUP message contains the
call release information in the Trel field.
B5.2.152 Privacy Notification
This field provides information about the privacy of the mobile subscriber for a Location Service
(LCS). This information is defined on a per-subscriber basis and is part of the information in the
external client list in the Provide Subscriber Location (PSL) message. The field encoding is shown
in Table 194.
Field Used In:
Record: Ack.
1 Unused 0
2-3 Priority Level 07 - Priority Level A (highest)
06 - Priority Level B
05 - Priority Level 0
4 Sign Character C
Default: 000C.
Example:
Priority level 0: 005C
Table 192 Priority level atomic data field
Field Used In:
Record: Ack.
1 Unused 0
2-11 Time between call release and the acknowledgement call
in tenths of a second
0000000000 - 4294967295
12 Sign Character C
Default: 00000000000C.
Example:
Priority release time: 00214755300C
Table 193 Priority release time atomic data field
B5.2.153 Privacy Override
This field contains an indicator which shows whether or not a subscribers privacy setting was
overridden to get its location during a Location Service (LCS). The field contains a boolean
indicator showing whether or not the privacy override indicator (POI) was received in the Provide
Subscriber Location (PSL) message. A subscribers privacy may be overridden during an
emergency call and for lawful intercept. The field encoding is shown in Table 195.
B5.2.154 Query Method
This field identifies the method used to obtain a routing number for the mobile number portability
service. The field encoding is shown in Table 196.
Field Used In:
Record: LCS.
1 Notify Location Allowed 0
Notify and Verify Location Allowed If No Response 1
Notify and Verify Location Not Allowed If No Response 2
Location Not Allowed 3
2 Sign Character C
Default: FC
Example:
Notify Location Allowed: 0C
Table 194 Privacy Notification atomic data field
Field Used In:
Record: LCS.
1 Condition 0 - Privacy Not Override
1 - Privacy Override
2 Sign Character C
Default: FC
Example:
Privacy Override: 1C
Table 195 Privacy Override atomic data field
Field Used In:
Module: MNP.
1 Query Method Type 0 Unknown
1 IN Solution
2 SRF Solution
2 Sign Character C
Default: 0C.
Example:
1C - IN solution
Table 196 Query method atomic data field
B5.2.155 Rate Adaptation
This field captures information about the rate adaptation used for a data service. The field reflects
the value of Rate Adaptation and Other Rate Adaptation in the Bearer Capability information
element defined in 3GPP TS 24.008. This field provides information to the operator to distinguish
H.324M calls from other data calls.The field encoding is shown in Table 197.
NOTE The data rate field (B5.2.44 on page 152) and the rate adaptation field together
distinguish between the H.324 64K multimedia service and the 64K clear
channel service. For H.324, the data rate field indicates 64K (015C) and the rate
adaptation field indicates H.223 and H.245 (4C). For the 64K clear channel
service, the data rate indicates 64K (015C) and the rate adaptation field indicates
no rate adaptation (0C).
B5.2.156 Record Count
This field is defined as a value in the range 000000001 to 000065535. It is encoded as a 10
Field Used In:
Module: DS.
1 Data Rate 0 - No rate adaptation
1 - V.110
2 - X.31
3 - V.120
4 - H.223 and H.245
5 - PHS Internet Access Forum Standard (PIAFS)
2 Sign Character C
Example:
Rate Adaptation (V.110): 1C
Table 197 Rate adaptation atomic data field
Field Used In:
Switch/Billing File Record: BFTOR.
B5.2.157 Record Header
This field is the first piece of information included in the structured record. It consists of four fields
as shown in Table 198.
The release id field identifies the product / software release on the MSC generating the call record.
The Structure Code is a unique number that is assigned to each type of record. This value defines
the set of data fields that is to follow the Record Header. The Call Type Code indicates the type of
call, whether it be mobile originated, mobile terminated, incoming trunk, outgoing trunk, etc. Each
Structure Code is associated with a Call Type Code. As shown in Table 199, a Call Type Code may
be associated with more than one Structure Code.
Field Used In:
Hexadecimal ID 2 B5.2.72
Release Id 6 B5.2.163
Structure Code 6 B5.2.188
Call Type Code 4 B5.2.19
Table 198 Record header data field
Structure Code Call Type Code
Values Description Values Description
0001 Location Update 003 Location Update Call
0002 Mobile Originated 001 Mobile Originated Call
0003 Mobile Terminated 002 Mobile Terminated Call
0004 SMS Mobile Originated 005 SMS Mobile Originated Call
0005 SMS Mobile Terminated 006 SMS Mobile Terminated Call
0006 Supplementary Service Action 004 Supplementary Service Action
0007 Transfer In 007 File Transfer Record
0008 Transfer Out
0009 Time Change 008 Time Change Record
0010 Switch Restart 009 Switch Restart Record
0011 Block Header 010 Block Header Record
0013 Incoming Gateway 011 Incoming Trunk Call
0014 Outgoing Gateway 012 Outgoing Trunk Call
0015 Incoming Intra-PLMN Trunk 011 Incoming Trunk Call
0016 Outgoing Intra-PLMN Trunk 012 Outgoing Trunk Call
0017 Transit
0018 Roaming 014 Roaming Call
0019 Common Equipment Usage 015 Common Equipment
0020 Acknowledgement 016 Acknowledgement
0021 Location Services (LCS) 017 Location Services (LCS)
Table 199 Mapping of structure codes to call type codes
B5.2.158 Record Number
This field defines a contiguous integer value for each record that may be used for auditing purposes.
It is defined as a value in the range 00000000001 to 04,294,967,295 with wrap around from
04,294,967,295 to 00000000001. The field encoding is shown in Table 200.
B5.2.159 Record Time
This field contains the time of capture of an acknowledgement call record which is generated by the
integrated acknowledgement centre (IAC) to provide details of a high priority group call. It is
encoded as a 16 character date and time atomic data field as shown in Section B5.2.46 on page 153.
B5.2.160 Recording Entity
This field captures the E.164 number of the VLR which sends location information to the Service
Control Point (SCP) as part of the CAMEL Phase 3 mobility management service. It consists of two
B5.2.161 Recording Office Identity
The recording office identity field is part of the auxiliary header field in the switch records and the
billing file structuring records. It provides information about the MSC generating the record.This
value is taken from the OFFICE_ID_ON_AMA_TAPE value in table OFCENG. The field encoding
Field Used In:
Records: All Call Detail Records. Switch/Billing File Records: TCR, SRR, BFTIR, BFTOR.
1-11 Record Number {00000000001....04,294,967,295}
12 Sign Character C
Example:
Record Number: 00000000254C
Table 200 Record number atomic data field
Field Used In:
Record: Ack.
Field Used In:
Record: LU.
Table 201 Recording entity data field
B5.2.162 Recording Office Type / Sensor Type
The recording office type and sensor type fields are part of the auxiliary header field which is in the
switch records and the billing file structuring records. They identify the MSC as the type of network
node generating the billing record. They consist of a single field as shown in Table 203.
B5.2.163 Release Id
This field captures information relating to the software release that is in operation. This information
may be required by the downstream processor for differentiation purposes. It is updated in each
software release and is part of the Record Header field described in Section B5.2.157 on page 218.
Field Used In:
Records: All Switch/Billing File Records.
1 Spare 0
2-7 Office Identity {000000....999999}
8 Sign Character C
Example:
Recording Office Identity: 0123456C
Table 202 Recording office identity atomic data field
Field Used In:
1-3 Recording Office Type / Sensor Type 001 - MSC
4 Sign Character C
Example:
Recording Office Type / Sensor Type: 001C
Table 203 Recording office type atomic data field
Field Used In:
1 Unused 0
2-3 GSM/UMTS Release {00....99}
4-5 Version 00
6 Sign Character C
The Release Id shall be set to the following in the GSM/UMTS releases indicated:
MSC release 19: 01900C
Table 204 Release id atomic data field
B5.2.164 Release Time
This field contains the release time of the facilities used on a call. For both Mobile originated and
Mobile terminated calls this includes the traffic channel when one is used. In trunk records, the field
captures the release time of the trunking facilities. It is encoded as a 16 character date and time
atomic data field as shown in Section B5.2.46 on page 153.
B5.2.165 Requested QoS
This field captures the Quality of Service (QoS) requested for a location service (LCS). The field
captures the requested horizontal accuracy for the location of the subscriber. The MSC captures the
Requested QoS from the Mobile Originated Location Request (MOLR) message or Provide
Subscriber Location (PSL) message. The field encoding is shown in Table 205.
NOTE The values for horizontal and vertical uncertainty are specified in 3GPP TS
23.032. Section 6.2 in this specification defines a flexible and accurate method
for determining uncertainty and also provides some example values.
B5.2.166 Requesting Mobile Location Centre (MLC)
This field provides the address of the requesting Gateway Mobile Location Centre requesting the
location of the mobile subscriber as part of a Location Service (LCS). The Provide Subscriber
Location (PSL) message provides this information. The field consists of two fields as shown in
Table 206.
Field Used In:
Records: MO, MT.
Field Used In:
Record: LCS.
1 Spare F
2 Vertical Coordinates Request 1
3 Response Time Category 0 - Delay Tolerant
1 - Low Delay
4-6 Horizontal Uncertainty 000 ... 127
7 Horizontal Accuracy 1 - Horizontal Accuracy (Most Significant Bit)
8-10 Vertical Uncertainty 000 ... 127
11 Vertical Accuracy 1 - Vertical Accuracy (Most Significant Bit)
12 Sign Character C
Example:
Requested QoS: F1112311221C
Table 205 Requested QoS atomic data field
B5.2.167 Result Indicator
This field provides information about the outcome of invoking a supplementary service. The field
Field Used In:
Record: LCS.
Table 206 Requesting MLC atomic data field
Field Used In:
Record: SSA. Module: SS.
1 Spare 0
2-3 Result Indicator
General 00 - Unknown/No Value
01 - Successful Outcome
02 - Service Not Provided By Network
04 - Wrong Procedure Used
05 - Insufficient Information
06 - Conflict with Other Supplementary Services
09 - Destination Not part of CUG
10 - Subscriber Busy
11 - No Answer
12 - Timer Expired
13 - Network Congestion
14 - Network Resources Not Available
15 - Call Cleared for Abnormal Reasons
16 - Wrong Password
17 - Use of Password Not Allowed
Supplementary Service 18 - Not a Subscribed-to Supplementary Service
21 - SS Invoked by Subscriber
22 - SS Invoked by Network
25 - Supplementary Service Control Procedure Not Correct
Number Identification 26 - Calling Number Identity Restriction
27 - Calling Line Identity Presentation Overridden
28 - Connected Number Identity Restriction
29 - Connected Number Identity Restriction Overridden
Forwarded to Number 31 - Invalid Directory Number
32 - Violates Subscription Options
36 - Not Member of CUG
37 - Call Already Forwarded the Maximum Number of Times
Transferred to 40 - Is Busy
Account code service 56 - Account code validation failure
Calling Name Delivery (CNAM) service 57 - Unavailable
58 - Private
MSC-HLR based Ring Back Tone 59 - Ring Back Tone Failure
4 Sign Character C
Example:
Result Indicator (No Answer): 011C
Table 207 Result indicator atomic data field
B5.2.168 RNC ID
This field captures the identity of the Radio Network Controller (RNC) in a 3GPP Release 4
network where the MSC call server is separated from the bearer plane controlled by the media
gateway. The controlling RNC uses the RNC ID (identity) to route received uplink messages
towards the serving RNC. The RNC ID is obtained from the InitialUE message. It is encoded as a 6
character BCD/Hex atomic data field as described in Section B5.2.10 on page 127.
NOTE Because the RNC is part of the UMTS radio access, the Access Network field
(B5.2.2 on page 124) and the RNC Id together provide the full billing
information. To indicate UMTS access, the Access Network field contains the
value 1C and the RNC Id field captures the identity of the RNC. For GSM
access, the Access Network field contains the value 0C and the RNC Id field
contains the default value FFFFFC. If the RNC Id is not available, the field also
contains the default value.
B5.2.169 Roaming Number
This field contains the mobile subscriber roaming number (MSRN) of the called mobile subscriber.
It consists of three fields as shown in Table 208.
B5.2.170 Routing Number
This field contains information for the mobile number portability (MNP) service which allows
subscribers to move to new network operators without changing their directory numbers
(MSISDNs). For ETSI MNP, if the subscriber has moved to another network (ported out) this field
captures the routing number to the new network and the MSISDN of the subscriber. If the
subscriber has not moved, the field contains the subscribers MSISDN. For Signalling Relay
Function (SRF) based MNP, if the subscriber has moved to another network, this field captures the
routing number and the MSISDN of the subscriber. If the subscriber has not moved or is ported-in
to a network, the field contains the default value. It is encoded as a 26 character BCD/hex atomic
data field as described in Section B5.2.10 on page 127.
Field Used In:
Module: LaC
Field Used In:
Record: Ro. Module: LaC.
Table 208 Roaming number data field
Field Used In:
Module: MNP.
B5.2.171 SCF ID
This field captures the SCF id (Service Control Function Identity) of the SCP (Service Control
Point) to be used in a CAMEL Phase 2 intelligent network service. In a CAMEL Phase 2 network
an assisting SSP (an MSC/SSP) can provide connections to its intelligent peripherals (IPs) to
initiating SSPs. The assisting SSP uses the SCF ID to identify the SCP which it needs to contact for
instructions on the IP facilities to supply to the initiating SSP. To set up the connection to the IP, the
initiating SSP sends an ISUP initial address message (IAM) to the assisting SSP. This message
includes the SCF ID. The assisting SSP maps the SCF ID to an SCP address. It then obtains
instructions on the IP facilities to supply for the call, by sending the identified SCP a CAMEL
AssistRequestInstructions (ARI) message. The assisting SSP captures the SCF ID for the billing
record after sending the ARI to the SCP. The field is encoded as a 22 character BCD/hex atomic
data field as described in Section B5.2.10 on page 127.
B5.2.172 SCF ID / ETC Parm1
This field captures part of the addressing information used to form a connection to an intelligent
peripheral (IP) for a CAMEL service. The Service Control Point (SCP) sends an Establish
TemporaryConnection message which contains the addressing information for the IP. Part of the
addressing information is the SCF ID. The MSC, acting as an initiating SSP, uses the addressing
information to form a connection to an assisting SSP which has the IP connected to it. The field
Field Used In:
Record: SSA. Module: GASSP.
Field Used In:
Module: IN.
1 Spare 0
2 Format Indicator 0 - Explicit
1 - Embedded
3-33 SCF ID {0,1,2,3,4,5,6,7,8,9,0,A,B,C,D,E,F}
34 Sign Character C
Default: FF0000000000000000000000000000000C
Example:
SCF ID / ETC Parm 1: 000000000000000000000000000099673C
Table 209 SCF ID / ETC Parm 1 atomic data field
B5.2.173 SCP Address
This field captures the address of an Intelligent Network (IN) Service Control Point (SCP) for an
on-board IN service. It is encoded as a 22 character BCD/hex atomic data field as described in
Section B5.2.10 on page 127.
For proprietary IN services, the SCP address is provided by datafill on the MSC/SSP which
provides addresses for each of the IN Detection Points (DPs) at which IN services can be triggered:
At DP2 (the information collected DP) for a mobile originated call, the SCP address is
provided by office parameter GSM_IN_SCP_ADDRESS in table OFCVAR
At DP2 on incoming ANSI or ITU-T ISUP trunks, the SCP address is provided by the
INDP2 option in table MSCCLLI for the trunk group
At DP3 (the information analysed DP) for a mobile originated, trunk originated or
forwarded call, the SCP address is provided by office parameter GSM_DP3_SCP_
ADDRESS in table OFCVAR
At DP12 (the authorised termination DP) for a mobile terminated call, the SCP address
is provided by office parameter GSM_DP12_SCP_ADDRESS in table OFCVAR.
The SCP address defaults to FF ... FC for off-board IN services.
For CAMEL, the SCP address is provided in following ways:
At DP2 with O-CSI, the SCP address is taken from the O-CSI parameter received in the
Complete Call message.
At DP12 with T-CSI, the SCP address is taken from the T-CSI parameter received in the
SRI Ack message.
At DP3 with D-CSI, the SCP address is taken from the D-CSI parameter received in the
Complete Call message.
At DP3 with N-CSI, the SCP address is provided by the datafill against MS selector in
the table MSCINAP using the index arrived at in universal translations.
For the CAMEL Phase 3 mobility management service, the SCP address is taken from
the M-CSI parameter stored in the VLR.
For CAMEL SMS services, the SCP address is taken from the SMS-CSI data received in the
Complete Call message from the VLR. The SMS-CSI is stored in the HLR and is downloaded to the
VLR along with other subscriber data.
If the original SCP is overloaded and the network supports service provision by a standby SCP, the
SCP address field contains the standby SCPs address.
Field Used In:
Modules: CSMS, GASSP, IN.
B5.2.174 Sensor Identity
The sensor identity field is part of the auxiliary header field which is in the switch records and the
billing file structuring records. It provides information about the MSC generating the record. Its
value is taken from the OFFICE_ID_ON_AMA_TAPE value in table OFCENG. The field encoding
NOTE The Sensor identity can be used to distinguish between different billing files
from different MSCs.
B5.2.175 Served IMEI
This field captures the International Mobile Equipment Identity (IMEI) or IMEI Software Version
(IMEISV) of the party associated with the location request. The format of the IMEI/IMEISV is
specified in 3GPP TS 23.002. This field is captured when the location service (LCS) is initiated.

Field Used In:
1 Record 0 - Original Record
1 - Rewritten Record
2-7 Office Identity {000000....999999}
8 Sign Character C
Example:
Sensor Identity: 0001234C
Table 210 Sensor identity atomic data field
Field Used In:
Records: LCS.
1-5 Unused FFFFF
6-19 IMEI {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F}
22 Sign Character C
Examples:
Table 211 Served IMEI atomic data field
B5.2.176 Served IMSI
This field captures the IMSI of the served party for the CAMEL Phase 3 mobility service. It
identifies the subscriber for whom the location information is being provided. It consists of three
B5.2.177 Served MSISDN
This field captures the MSISDN of the served party for the CAMEL Phase 3 mobility service. It
identifies the subscriber for whom the location information is being provided. For Location
Services (LCS) this field identifies the subscriber for whom the service is being provided if it is
supplied by the User Equipment (UE). For LCS, the served MSISDN is supplied by the Provide
Subscriber Location message. The served MSISDN field consists of three fields as shown in Table
213.
B5.2.178 Served Party
This field captures the identity of the served party for Location Services (LCS). It captures the
international mobile subscriber identity (IMSI) of the mobile subscriber from which location
information was requested to provide the location service. The MSC obtains the Identity of Target
UE from the LCS MOLR message or the Provide Subscriber Location (PSL) message. The field is
encoded as a sixteen character BCD/hex string as defined in Section B5.2.10 on page 127.
Field Used In:
Record: LU.
Table 212 Served IMSI data field
Field Used In:
Record: LU.
Table 213 Served MSISDN data field
Field Used In:
Record: LCS.
B5.2.179 Service Centre
This field captures the address of the service centre involved in an interaction. For a CAMEL
mobile originated service, this field is captured in the CAMEL SMS information module when the
original service centre address sent by the MSC/SSP in the InitialDP SMS message is altered in the
Connect SMS message returned by the gsmSCF. It consists of two fields as shown in Table 214.
B5.2.180 Service Key
This field captures the service key which is used by an IN SCP (intelligent network Service Control
Point) to invoke the correct service logic program to provide an IN service. It also captures the
service key for the GSM-R functional addressing service. The field encoding is shown in Table 215.
NOTE The service key is defined in accordance with 3GPP TS 29.002.
The service key is captured for on-board IN services and is provided by datafill on the MSC/SSP.
The datafill provides the service keys for each of the detection points (DPs) at which a service can
be triggered. For CAMEL services:
In Originating Services, the Service Key is provided from the O-CSI or D-CSI
parameter in Complete Call Message.
In Terminating Services, the Service Key is provided from the T-CSI parameter received
in SRI ACK message.
In N-CSI, the Service Key is provided by the parameter SERVICEKEY in Table
MSCINAP.
For CAMEL SMS services, the service key, like the SCP address is obtained from the
SMS-CSI in the Complete Call message from the VLR.
For the CAMEL Phase 3 mobility management service, the Service Key is taken from
the M-CSI parameter stored in the VLR. (continued)
Field Used In:
Records: SMSMO, SMSMT. Module: CSMS.
Table 214 Service centre data field
Field Used In:
Modules: CSMS, IN.
1 Spare 0
2-11 Service Key {0000000000 - 2147483647}
12 Sign Character C
Default: 00000000000C.
Example:
Service Key (Mobile Originated On-Board IN call): 01555884995C
Table 215 Service key atomic data field
For proprietary CS-1R INAP services:
In CS1-R, the Service Key is provided by the parameter SERVICEKEY in Table
MSCINAP.
AT DP-T, Index Value in MSCINAP is used as index in table MSCCLLI for the retrieval
of Service Key.
If the service key is not in the datafill or subscription information described above, the MSC can be
provisioned with other datafill to provide it:
At DP2 (the information collected DP) for a mobile originated call, the service key is
provided by office parameter GSM_IN_SVC_KEY in table OFCVAR.
At DP2 for a call origination on ANSI or ITU-T ISUP trunks, the service key is provided
by the INDP2 option in table MSCCLLI for the trunk group.
At DP3 (the information analysed DP) for a mobile originated, trunk originated, or
forwarded call, the service key is provided by office parameter GSM_DP3_IN_SVC_
KEY.
At DP12 (the authorised termination DP) for a mobile terminated call, the service key is
provided by office parameter GSM_DP12_IN_SVC_KEY in table OFCVAR.
The service key defaults to FFFFFFFFFFFC for an off-board IN service.
B5.2.181 SMS Message Type
This field contains an indication of the type of SMS message. The field encoding is shown in Table
216.
A CAMEL Service may be invoked for the following Mobile Originated short message types:
Short Message Submission (PDU type = SMS-SUBMIT): short message transfer
protocol data unit containing user data (the short message), being sent from an MS to a
Service Center (SC).
Short Message Command (PDU type = SMS-COMMAND): short message transfer
protocol data unit, which enables an MS to invoke an operation at the SC.
Field Used In:
Record: SMSMO.
1 SMS Type 0 - SMS SUBMIT
1 - SMS COMMAND
2 Sign Character C
Default: FC
Example: 1C
Table 216 SMS message type atomic data field
B5.2.182 SMS Release Cause Value
This field contains an indication of the reason for the release of a CAMEL SMS call by the MSC/
SSP. This field is captured in the following cases:
the SMS call is released as a result default SMS handling (DSH) being applied to the
releaseCall operation
the successful processing of a releaseSMS operation
The SMS cause values are specified in 3GPP TS 24.011. The field encoding is shown in Table 217.
Field Used In:
Module: CSMS.
1 Spare 0
2-3 Unassigned (Unallocated) Number 01
Operator Determined Barring 02
Call Barred 03
Short Message Transfer Rejected 04
Destination Out Of Service 05
Unidentified Subscriber 06
Facility Rejected 07
Unknown Subscriber 08
Reserved 09
Network Out Of Order 10
Temporary Failure 11
Congestion 12
Resources Unavailable, Unspecified 13
Requested Facility Not Subscribed 14
Requested Facility Not Implemented 15
Invalid Short Message Transfer Reference Value 16
Semantically Incorrect Message 17
Mandatory Information Element Missing 18
Message Type Non-existent or Not Implemented 19
Message Not Compatible With Short Message Protocol State 20
Information Element Non Existent or Not Implemented 21
Protocol Error Unspecified 22
Interworking Unspecified 23
4 Sign Character C
Default: FFFC
Example:
SMS Release Cause Value: (Short Message Transfer Rejected) F05C
Table 217 SMS release cause value atomic data field
B5.2.183 SMS Result
This field contains the result of the attempt to deliver a Short Message if the attempted delivery is
unsuccessful. Any value captured into this field is a detailed indication of cause of failure. The
values can be found in 3GPP specifications 24.008 or 29.002. The SMS result is encoded using the
6 character diagnostic atomic data field structure as shown in Section B5.2.52 on page 159.
However, the service may fail before there is an attempt to deliver the message and in these cases
the SMS Result field does not capture the diagnostic information. For the SMS-MT service (Short
Message Service - Mobile Terminated), the MSC receives a MAP_MT_FSM from the service
centre or SMS-Gateway MSC. It then pages the mobile station and sends the message to it. If the
service fails before there is an attempt to deliver the message, e.g. if the paging times out, the SMS
result field does not capture the diagnostic information. For the SMS - MO (SMS Mobile
Originated) service, the MSC sends a MAP_MO_FSM message to service centre or the SMS-
IWMSC (SMS interworking MSC). If there is a failure before this happens the SMS result field
does not capture the diagnostic information.
B5.2.184 SMS Start Time
This field captures the time at which the MSC/SSP sends the InitialDP SMS message to the Service
Control Point (SCP) to initiate a CAMEL SMS call. It is encoded as a 16 character date and time
field atomic field as described in Section B5.2.46 on page 153.
B5.2.185 SMS Stop Time
This field indicates the time at which the dialogue between the MSC/SSP and Service Control Point
(SCP) is terminated. This field, along with the IN dialogue start time field, allows the operator to
calculate the duration of the dialogue between the MSC/SSP and SCP. The field is encoded as a 16
character date and time field atomic field as described in Section B5.2.46 on page 153.
Field Used In:
Records: SMSMO, SMSMT.
Field Used In:
Module: CSMS.
Field Used In:
Module: CSMS.
B5.2.186 SMS Timestamp
This field shall capture the time at which a short message is either sent by the MSC to the service
centre (mobile originated SMS), or is sent to the mobile station (mobile terminated SMS). In the
former case this time stamp is marked by the generation of a FORWARD SHORT MESSAGE by
the MSC. In the latter case it is marked by the generation of a CP DATA (RP-DATA) message by
the MSC. It is encoded as a 16 character date and time atomic data field as described in Section
B5.2.46 on page 153.
B5.2.187 SMS Validity Period
This field indicates the length of the validity period or the absolute time of the validity period
termination. SMS Validity Period is only used for SMS-SUBMIT and it is not present if SMS-
COMMAND is used (see section B5.2.181 on page 229). The field is encoded as shown in Table
218.
B5.2.188 Structure Code
This field identifies the type of billing record and also indicates whether or not the record has any
modules appended to it. It is one of the fields in the Record Header compound field described in
Section B5.2.157 on page 218. The field encoding is shown in Table 219.
Field Used In:
Records: SMSMO, SMSMT.
Field Used In:
Record: SMSMO.
1 Spare 0
2 - 3 SMS Validity Period Format 01 - TP-Validity-Period-Not-Present
02 - TP-Validity-Enhanced-Format
03 - TP-Validity-Relative-Format
04 - TP-Validity-Absolute-Format
4-17 SMS Validity Period {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F}
18 Sign Character C
Default: 0FFFFFFFFFFFFFFFFC
Example: 002FFFFFFFFFFFF13C
Table 218 SMS validity period atomic data field
B5.2.189 Study Indicator
This field indicates the nature of the record. A normal record is one generated during a real call
scenario by the call processing software. A study generated record is one generated by a testing
utility i.e. without making an actual phone call. The field encoding is shown in Table 220.
Field Used In:
1 Module Indicator 0 - Record Contains No Modules
1 - Record Contains Modules
2-5 Structure Code 0001 - Location Update
0002 - Mobile Originated
0003 - Mobile Terminated
0004 - SMS Mobile Originated
0005 - SMS Mobile Terminated
0006 - Supplementary Service Action
0007 - Transfer In
0008 - Transfer Out
0009 - Time Change
0010 - Switch Restart
0011 - Block Header
0013 - Incoming Gateway
0014 - Outgoing Gateway
0015 - Incoming Intra-PLMN Trunk
0016 - Outgoing Intra-PLMN Trunk
0017 - Transit
0018 - Roaming
0019 - Common Equipment Usage
0020 - Acknowledgement of High Priority Call
0021 - Location Services (LCS)
6 Sign Character C
Example:
Structure Code (No Modules, Outgoing Gateway): 00014C
Table 219 Structure code atomic data field
Field Used In:
Records: All Call Detail Records.
1 Study Indicator 0 - Normal Record
1 - Study Generated Record
2 Sign Character C
Default: 0C
Example:
Study Indicator (Normal Record): 0C
Table 220 Study indicator atomic data field
B5.2.190 Subscriber Service
This field captures details of the service provided to the subscriber. The field encoding is shown in
Table 221.

Field Used In:
Module: TC.
1-5 Subscriber Service 00000 - Mobile Terminated Telephony
00001 - Mobile Originated Telephony
00002 - Mobile Terminated Fax Group 3
00003 - Mobile Originated Fax Group 3
00004 - Mobile Terminated Alternate Speech/Fax.
00005 - Mobile Originated Alternate Speech/Fax.
00006 - Mobile Terminated CDA 3.1kHz
00007 - Mobile Originated CDA 3.1kHz
00008 - Mobile Terminated CDA UDI (Trans.)
00009 - Mobile Originated CDA UDI (Trans.)
00010 - Mobile Terminated CDA UDI (Non. Trans.)
00011 - Mobile Originated CDA UDI (Non. Trans.)
00012 - Mobile Terminated CDS 3.1kHz
00013 - Mobile Originated CDS 3.1kHz
00014 - Mobile Terminated CDS UDI
00015 - Mobile Originated CDS UDI
00016 - Mobile Terminated Alternate speech/data CDA
00017 - Mobile Originated Alternate speech/data CDA
00018 - Mobile Terminated Alternate speech/data CDS
00019 - Mobile Originated Alternate speech/data CDS
00020 - Mobile Terminated speech followed by data CDA
00021 - Mobile Originated speech followed by data CDA
00022 - Mobile Terminated speech followed by data CDS
00023 - Mobile Originated speech followed by data CDS
6 Sign Character C
Example:
Subscriber Service (Mobile Terminated Telephony): 00000C
Table 221 Subscriber service atomic data field
B5.2.191 Supplementary Service Action
This field captures the call independent supplementary service (CISS) action or call related SS
action performed by the subscriber. The field encoding is shown in Table 222.
B5.2.192 Supplementary Service Code
This field captures a code which shows the supplementary service invoked by the subscriber. The
Field Used In:
1 Supplementary Service Action 0 - Registration (CISS)
1 - Erasure (CISS)
2 - Activation (CISS)
3 - Deactivation (CISS)
4 - Interrogation (CISS)
5 - Invoke (CRSS, CISS for USSD calls)
6 - Password Registration
F - None
2 Sign Character C
Default: FC.
Example:
Supplementary Service Action (Invoke): 5C
Table 222 Supplementary service action data field
Field Used In:
Record: SSA. Modules: SS, AoC.
1 Spare 0
2 SS Group 1 - Number Identification Services
2 - Forwarding Services
3 - Explicit Call Transfer
4 - Call Completion Services
5 - Multiparty Services
6 -Community of Interest Services
7 - Charging Services
8 - Additional Information Transfer Services
9 - Call Restriction Services
A - GSM Railways Services
B - National Specific Services
F - Other Features and Services
Option
3 Character 2 = 1 SS Type 1 - Calling Number Identity Presentation
2 - Calling Number Identity Restriction
3 - Connected Line Identity Presentation
4 - Connected Line Identity Restriction
F - Proprietary Calling Name Delivery (CNAM)
a
(continued)
Table 223 Supplementary service code atomic data field
NOTE The Supplementary service code used for Hot Billing does not conform with
the general coding rules of the other supplementary services. The value used to
define this service is 254C.
or
3 Character 2 = 2 SS Type 0 - All Forwarding SS
1 - Call Forwarding Unconditional
5 - Call Forwarding in Gateway (Unknown)
8 - Call Forwarding All Conditional
9 - Call Forwarding Subscriber Busy
A - Call Forwarding No Reply
B - Call Forwarding Not Reachable
or
3 Character 2 = 3 SS Type 1 - Explicit Call Transfer
or
3 Character 2 = 4 SS Type 1 - Call Waiting
2 - Call Hold
4 - Proprietary Voice Mail Call Dropback
5 - Call Reorigination
6 - Call Reorigination By Cause
9 - Proprietary Release Link Trunk Service
or
3 Character 2 = 5 SS Type 1 - Multiparty Services
or
3 Character 2 = 6 SS Type 1 - Closed user Groups (CUG) Service
8 - Account Code Service
9 - Proprietary Customer Information
or
3 Character 2 = 7 SS Type 1 - Advice of Charge Information
2 - Advice of Charge Charging
or
3 Character 2 = 8 SS Type 1 - Unstructured Supplementary Service Data (USSD)
or
3 Character 2 = 9 SS Type 0 - All Barring SS
1 - Barring of Outgoing Calls (CRSS)
2 - Barring of All Outgoing Calls (CISS)
3 - Barring of All Outgoing International Calls (CISS)
4 - Barring of All Outgoing International Calls Except to the Home PLMN (CISS)
9 - Barring of Incoming Calls (CRSS)
A - Barring of All Incoming Calls (CISS)
B - Barring of All Incoming Calls When Roaming Outside the Home PLMN (CISS)
C - Incoming Operator Determined Barring (CRSS)
D - Outgoing Operator Determined Barring (CRSS)
or
3 Character 2 = A SS Type 1 - Enhanced Multi-Level Precedence and Pre-emption Service/Wireless Priority Service
or
3 Character 2 = B SS Type 0 - Directory Assistance Service Call
or
3 Character 2 = F SS Type 7 - Anonymous Call Rejection
9 - Extension Service
A - Malicious Call Trace (MCT)
B - Optimal Routing (of Late Call Forwarding)
F - MSC-HLR based Ring Back Tone Service
or
1-3 254 - Hot billing service (see note)
4 Sign Character C
Default: 000C
Example:
Supplementary Service Code (Advice of Charge Information): 071C
a. CNAM is a proprietary implementation of the 3GPP Calling Name Presentation (CNAP).
Table 223 Supplementary service code atomic data field
B5.2.193 Supplementary Service Parameters
This field captures any parameters that may be associated with a particular supplementary service
e.g. the call forwarding number. For additional examples of uses for the Supplementary Service
Parameters field, please refer to Section B4.2.4, Supplementary Services Information Module on
page 83. If there is no additional information associated with the supplementary service then the
field shall be populated with a default value. It is encoded as a 32 character BCD/hex string as
defined in Section B5.2.10 on page 127.
B5.2.194 System Type
This field indicates the type of wireless system on which a Location Service (LCS) was initiated.
B5.2.195 Switch Restart Type
This field identifies the type of switch restart. The field encoding is shown in Table 225.
Field Used In:
Field Used In:
Record: LCS.
1 System Type 1 - UTRAN
0 - GERAN
2 Sign Character C
Default: FC
Example:
UTRAN: 1C
Table 224 System Type atomic data field
Field Used In:
Switch/Billing File Record: SRR.
1 Switch Restart Type 0 - Warm Restart
1 - Cold Restart
2 Sign Character C
Example:
Switch Restart Type (Warm Restart): 0C
Table 225 Switch restart type atomic data field
B5.2.196 Tariff Class
This field contains the tariff class used to derive the charging (E) parameters sent to the mobile
station to support the Advice of Charge (AoC) service. For more information on the derivation of
the tariff class, refer to Part C, Tariff Administration on page 319. The tariff class consists of a
single field as shown in Table 226.
B5.2.197 Teleservice
This field captures details of the teleservice used by the subscriber for the call. The field encoding is
shown in Table 227.
Field Used In:
Module: TC.
1-5 Tariff Class 00000....01023
6 Sign Character C
Default: FFFFFC
Example:
Tariff Class: 00104C
Table 226 Tariff class atomic data field
NOTE Teleservice codes are defined in accordance with 3GPP TS 29.002.
Field Used In:
Module: TS.
1 Spare 0
2 TS Group 0 - All Teleservices
1 - Basic
2 - Short Message Service
6 - Facsimile
7 - Data Teleservices
8 - Teleservices Except SMS
9 - Voice Group Call Services
D - Proprietary service group
Option
3 Character 2 = 0 TS Type 0 - All Teleservice Codes
or
3 Character 2 = 1 TS Type 0 - All Speech Transmission Services
1 - Telephony
2 - Emergency Calls
or
3 Character 2 = 2 TS Type 0 - All Short Message Services
1 - Short Message MT-PP
2 - Short Message MO-PP
or
3 Character 2 = 6 TS Type 0 - All Facsimile Short Transmission Services
1 - Facsimile Group 3 and Alter Speech
2 - Automatic Facsimile Group 3
3 - Facsimile Group 4
or
3 Character 2 = 7 TS Type
0 - All Data Teleservices
a
a. The teleservice groups All data teleservices and All teleservices except SMS are compound tele-
services. Compound teleservice group codes are applicable to call independent supplementary service
operations (i.e. they are not used in InsertSubscriberData or in DeleteSubscriberData operations).
or
3 Character 2 = 8 TS Type
0 - All Teleservices Except SMS
a.

or
3 Character 2 = 9 TS Type 0 - All Voice Group Call Services
1 - Voice Group Call Service
2 - Voice Broadcast Service
or
3 Character 2 = D TS Type 0 - Auxiliary Speech
1 - Auxiliary Telephony
4 Sign Character C
Example:
Teleservice (Basic Telephony): 011C
Teleservice (Auxiliary Telephony): 0D1C
Table 227 Teleservice atomic data field
B5.2.198 Terminating Location
This field captures details of the location of the terminating party on the call. The field encoding is
shown in Table 228.
B5.2.199 Trunk Usage Reason
This field indicates that an incoming / outgoing trunk is being used as the result of an inter-MSC
handover or call monitoring. The field encoding is shown in Table 229.
B5.2.200 Type of Carrier Identification Code (CIC)
This field contains an indication of whether or not the calling subscriber is pre-subscribed to the
Inter-exchange/International carrier used in the call. It is specifically related to a call in an equal
access environment. The type of CIC is applicable only to origination records and always has a
default value of FC for Termination Records. It consists of a single field as shown in Table 230.
Field Used In:
Module: OA.
1-2 Latitude in Degrees {00....90}
3-4 Latitude in Minutes {00....59}
5-6 Latitude in Seconds {00....59}
7 Latitude Direction 1 - North
2 - South
8-10 Longitude in Degrees {000....180}
11-12 Longitude in Minutes {00....59}
13-14 Longitude in Seconds {00....59}
15 Longitude Direction 3 - East
4 - West
16 Sign Character C
Example:
Terminating Location: 213432101123454C
Table 228 Terminating location atomic data field
Field Used In:
Module: TU.
1-3 Trunk Usage Reason 000 - Handover
001 - Call Monitoring
4 Sign Character C
Example:
Trunk usage reason - 000C
Table 229 Trunk usage reason atomic data field
B5.2.201 Unused Number 1
This field contains a generic number which is used in the patching information module. Nortel
patch designers can use the field to hold the numbering information required to meet customer
requirements for the patched capabilities. The field encoding is shown in Table 231.
B5.2.202 Unused Number 2
This field contains a generic number which is used in the patching information module. Nortel
patch designers can use the field to hold the numbering information required to meet customer
requirements for the patched capabilities. The field encoding is shown in Table 232.
Field Used In:
Module: EA.
1 Type of CIC 0 - None
1 - Exchange Access Operator Services Signalling - 10xxx, 101xxx or 950xxxx not dialled.
2 - Exchange Access Operator Services Signalling - 10xxx, 101xxx dialled.
3 - 950xxxx dialled.
4 - Pre-subscribed CIC selected and not input by Calling party.
5 - Pre-subscribed CIC selected and input by Calling party.
6 - Pre-subscribed CIC selected but no indication of input by Calling party.
7 - Non Pre-subscribed CIC selected as input by Calling party.
2 Sign Character C
Default: FC
Example:
Type of Carrier Identification Code: 6C
Table 230 Type of carrier identification code atomic data field
Field Used In:
Module: PaI.
Table 231 Unused Number 1 data field
Field Used In:
Module: PaI.
Table 232 Unused Number 2 data field
B5.2.203 Unused Timestamp 1
This field contains a timestamp which is used in the patching information module. Nortel patch
designers can use the field to hold the timestamp information required to meet customer
requirements for the patched capabilities. The field is encoded using the 16 character date and time
B5.2.204 Unused Timestamp 2
This field contains a timestamp which is used in the patching information module. Nortel patch
designers can use the field to hold the timestamp information required to meet customer
requirements for the patched capabilities. The field is encoded using the 16 character date and time
B5.2.205 Update Result
This field captures the result of a mobility management service failure. The field encoding is shown
in Table 233.
NOTE This field always contains the default value of FFFC. If the MSC successfully
reports the mobility management service to the Service Control Point (SCP), the
field defaults as there is no error condition to report. The CAMEL service which
reports the mobility management event to the SCP occurs after the mobility
event itself, e.g. after the location update. However, if the mobility management
service fails the CAMEL service is not triggered and so the Location Update
record (B4.1.15 on page 75) is not generated.
Field Used In:
Module: PaI.
Field Used In:
Module: PaI.
B5.2.206 Update Time
This field contains the time at which the CAMEL Phase 3 mobility management service was
performed. The field is encoded using the 16 character date and time field atomic field as described
in Section B5.2.46 on page 153.
Field Used In:
Record: LU.
1-3 User Error 000 - Unauthorized Requesting Network
001 - Unauthorized Privacy Class
002 - Unauthorized Call Unrelated External Client
003 - Unauthorized Call Related External Client
004 - Privacy Override Not Applicable
005 - Congestion
006 - Insufficient Resources
007 - Insufficient Measurement Data
008 - Inconsistent Measurement Data
009 - Location Procedure Not Completed
010 - QoS Not Attainable
011 - Position Method Not Available In Network
012 - Position Method Not Available In Location Area
013- Unknown or Unreachable LCS Client
Provider Error 100 - Duplicated Invoke Id
101 - Not Supported Service
102 - Mistyped Parameter
103 - Resource Limitation
104 - Initiating Release
105 - Unexpected Response From The Peer
106 - Service Completion Failure
107 - No Response From The Peer
108 - Invalid Response Received
4 Sign Character C
Default: FFFC
Example:
Update Result (Insufficient resources - User) - 006C
Table 233 Update result atomic data field
Field Used In:
Record: LU.
B5.3 PCS 1900 Fields
These fields are only generated by the PCS modules described in Section B4.3. Table 234 lists the
PCS fields, provides references to the field descriptions and lists the information modules
containing the fields.
Key to PCS market-specific information modules
LNP Local Number Portability O-T Originator-Terminator
TF Toll Free

B5.3.1 Automatic Number Identification Indicator
This field indicates the amount of Automatic number identification (ANI) information that is
available, as is specifically related to a call in an equal access environment. A full set of ANI
information would imply the availability of both the Originating line information and the actual
Charge number. These values may not necessarily be the same. It consists of a single field as shown
in Table 235.
Data Field Size Type Ref. PCS 1900 Modules
Automatic Number Identification indicator 2 Atomic B5.3.1 O-T
Called Party Off-Hook Indicator 2 Atomic B5.3.2 TF
Charge Number/Automatic Number Identification (ANI)
Number Type (2)
BCD/Hex String (32)
40 Compound B5.3.3 O-T
Generic Address Parameter 30 Atomic B5.3.4 O-T
Inter-exchange/International Carrier (IC/INC) Routing Indicator 2 Atomic B5.3.5 TF
LATA BCD/Hex String (4) 4 Atomic B5.3.6 TF
Location 16 Atomic B5.3.7 LNP
Location Routing Number (LRN) 12 Atomic B5.3.8 LNP
Module Code 4 Atomic B5.3.9 O-T, TF, LNP
Originating Line Information/II Parameter 4 Atomic B5.3.10 O-T
Originating Numbering Plan Area (and Area Code) 8 Atomic B5.3.11 O-T
Overseas Indicator 4 Atomic B5.3.12 TF
Party Identifier 4 Atomic B5.3.13 LNP
SCP Determined Terminated Number BCD/Hex String (20) 20 Atomic B5.3.14 TF
Service Feature Code 4 Atomic B5.3.15 TF
Service Provider Identity 10 Atomic B5.3.16 LNP
Supporting Information 8 Atomic B5.3.17 LNP
Terminating Numbering Plan Area 4 Atomic B5.3.18 O-T
Toll Free Call Type Code 4 Atomic B5.3.19 TF
Table 234 PCS 1900 market-specific data fields
NOTE In a non Signalling system Number 7 network the Automatic number
identification indicator shall only be populated with a non default value in those
defined records which include it that are generated at the originating MSC. It is
not possible to determine in a subsequent MSC if the Calling line digits provided
(if provided) constitute both the Originating line information and the actual
Charge number.
B5.3.2 Called Party Off-Hook Indicator
This field defines the called partys off-hook status after a toll free database query. Note that for SS7
signalling, this indicates that the ANM was received (if the MSC is terminating the call) or that the
ANM was sent (if the MSC is acting as an AT). This is specifically related to a toll free call. It
NOTE The MSC shall capture the IMEI when it is available. This availability depends
upon the nature of the mobile station in question. For GSM phase 1 mobiles the
value shall only be available when the MSC implicitly performs an IMEI identity
request. For phase 2 mobiles the value may be available at all times since an
identity request may be performed via the ciphering mode setting message
exchange. When the IMEI is obtained via this mechanism then the MSC shall
include it.
Field Used In:
Information Module: Originator-Terminator.
1 ANI Indicator 0 - No ANI or Calling number provided
1 - ANI provided, no Calling number
2 - Calling number provided, No ANI
3 - Both Calling number and ANI provided
2 Sign Character C
Default: FC
Example:
Automatic number identification indicator - 2C
Table 235 Automatic number identification indicator atomic data field
Field Used In:
Information Module: Toll Free.
1 Called Party Off-Hook Indicator 0 - terminating party has gone off-hook
1 - terminating party off-hook not detected
2 - an answer attempt (operator or collect call)
3 - simulated called party off-hook detected
9 - unknown
2 Sign C
Default: 1C
Example:
Called Party Off-Hook Indicator: 0C
Table 236 Called party off-hook indicator atomic data field
B5.3.3 Charge Number/Automatic Number Identification (ANI)
This field contains the actual billing or charge number related to a call and is obtained from the
optional Charge Number (CN) parameter in the optional part of the PET7 Initial Address Message
(IAM). It consists of three fields as shown in Table 237.
NOTE 1 For mobile terminated calls, this field is only populated in the mobile terminated
record if the charge number is provided in the incoming PET7 IAM message.
NOTE 2 In a call forward scenario to an outbound roamer, the charge number in the
roaming record is populated with the dialled digits.
NOTE 3 For all other call scenarios, or when the optional charge number parameter is not
passed in the PET7 IAM, this field is set to the default value in both the mobile
originated and mobile terminated records.
B5.3.4 Generic Address Parameter
This field is used to capture the dialled digits as are specifically related to a call in an equal access
environment. The number shall be captured as a nationally formatted number i.e. inter-exchange
carrier prefix digits shall not be included. It consists of a single field as shown in Table 238.
Field Used In:
Table 237 Charge number/ANI data field
NOTE 1 In a non Signalling system Number 7 (more specifically a non ANSI7+ ISUP)
network the Generic Address parameter shall only be populated with a non
default value in those defined records which include it, that are generated at the
originating MSC.
NOTE 2 Character 4 indicates whether the BCD/hex string starting at character 12
contains an odd or even number of digits. Taking the example, character 4 = 1
and there are an odd number of address digits in the number 500239345.
B5.3.5 Inter-exchange/International Carrier (IC/INC) Routing Indicator
This field contains an indication of whether the call is routed directly or if the MSC is acting as an
Access Tandem (AT). This field shall only be captured if the Toll Free Call Type Code returned
from the toll free database is equal to call is routed to IXC, (141C). This is specifically related to a
toll free call. It consists of a single field as shown in Table 239.
Field Used In:
1-3 Type of Address 000 - Dialled digits
255 - Used in general default structure
4 (see NOTE 2) Odd/Even Indicator 0 - Even number of address digits
1 - Odd number of address digits
5 Number Type 8 - Generic address parameter
6 Extension Indicator 0 - Extension
1 - No Extension
7-8 Nature of Address Indicator 00 - Unknown
02 - National significant number
9-10 Numbering Plan Indicator 00 - Unknown
01 - ISDN/Telephone numbering plan
11 Presentation Restriction
Indicator
0 - Presentation Allowed
1 - Presentation Restricted (Default)
2 - Number Unavailable
3 - Used in general default structure
12-29 BCD or Hex String (18) {0,1,2,3,4,5,6,7,8,9}
30 Sign Character C
Default: 25508100003FFFFFFFFFFFFFFFFFFC
Example:
Generic Address Parameter: 00018002011500239345FFFFFFFFFC
Table 238 Generic address parameter atomic data field
Field Used In:
1 IC/INC Routing Indicator 0 - call routed directly
1 - call routed to AT
2 Sign C
Default: FC
Example:
IC/INC Routing Indicator: 1C
Table 239 IC/INC routing indicator atomic data field
B5.3.6 LATA
This field captures the originating LATA in a toll free call. This is specifically related to a toll free
call. It is defined as a value in the range 000 to 999 with wrap around from 999 to 000. It is encoded
as a 4 character BCD/hex string atomic data field as described in Section B5.2.10 on page 127.
B5.3.7 Location
This captures the location of a partys switch when that party (called or calling) uses the local
number portability (LNP) service. It consists of a single field as shown in Table 240.
NOTE The field is not currently used as the phase 1 definition of LNP is limited to a
user being able to retain his/her telephone number when changing service
provider or service mix. In the records in which this field is present the default
value FFFFFFFFFFFFFFFC will be inserted.
B5.3.8 Location Routing Number (LRN)
This field captures the routing address used to route a call to a party using the local number
portability (LNP) service. The LRN is defined in the North American numbering format NPA-NXX
XXXX and identifies the network to which the subscriber has moved. The LRN consists of a single
field as shown in Table 241.
Field Used In:
Field Used In:
Information Module: Local Number Portability.
Character Description Meaning
1-3 Location Type 001 - V & H coordinates
002 - 5 Digit U.S. Zip Code
003 - 9 Digit U.S. Zip Code
004 - Canadian Postal Code
005 - Longitude & Latitude
999 - Unknown
4-15 Location Digits {000000000000....999999999999}
16 Sign Character C
Default: FFFFFFFFFFFFFFFC
Example:
Location:.
Table 240 Location data atomic data field
B5.3.9 Module Code (PCS 1900 Market-Specific)
This field contains a code value which identifies the information module containing the field. It
B5.3.10 Originating Line Information/II Parameter
This field contains an indication of the type of subscriber originating the call. The codes used in this
parameter are the binary equivalents of the decimal codes used in the II digits of the ANI
(Automatic number identification) sequence for inband signalling systems. The information is
specifically related to a call in an equal access environment. It consists of a single field as shown in
Table 243.
(continued)
Field Used In:
1 Spare 0
2-11 Location Routing Number
(NPA-NXX XXXX)
{0000000000....9999999999}
12 Sign Character C
Example:
Location Routing Number: 02146841111C
Table 241 Location routing number atomic data field
Field Used In:
Information Modules: Originator-Terminator, Toll Free, Local Number Portability.
Character Description Values (Billing)
1-3 Module Code 011 - Originator-Terminator Information
014 - Toll Free Information
021 - Local Number Portability (LNP) Information
4 Sign Character C
Default: Not applicable
Example:
Module Code (Toll Free Information): 014C
Table 242 Module code atomic data field
Field Used In:
1-3 Type of Calling line See Note
4 Sign Character C
Default: FFFC
Example:
Originating line information: 010C
Table 243 Originating line information parameter atomic data field
NOTE 1 In a MF signalling network the Originating line information field shall only be
populated with the default value in those defined records which include it, that
are generated at the originating MSC.
NOTE 2 On mobile originations this field shall be populated with the value 62, Type 2
mobile subscriber. For mobile terminations this value shall be populated with
the value received over the network signalling (if available). For a complete list
of these values and their definitions the reader is referred to Bellcore TR-NWT-
000690.
B5.3.11 Originating Numbering Plan Area (and Area Code)
This field contains an indication of where the call was originated. For mobile originated calls this
shall be captured as the Numbering plan area code and the area code of the originating cell. For
mobile terminated calls the value captured shall be based upon the trunk group upon which the call
arrives at the MSC. This is, as is specifically related to a call in an equal access environment. It
B5.3.12 Overseas Indicator
This field contains the overseas indicator which is based on the routing number parameter in the
response message the toll free SCP sends to the MSC. It indicates whether the routing number is an
overseas number or not. It consists of a single field as shown in Table 245.
Field Used In:
1 Spare 0
2-4 BCD or Hex String (3) Numbering plan area code
5-7 BCD or Hex String (3) Area code of where call was originated
8 Sign Character C
Default: FFFFFFFC
Example:
Originating numbering plan area: 0214684C
Table 244 Originating numbering plan area atomic data field
B5.3.13 Party Identifier
This field identifies the party using the local number portability (LNP) service, i.e. the originating
or terminating party. It consists of a single field as shown in Table 246.
B5.3.14 SCP Determined Terminated Number
This field contains the routing number parameter in the RESPONSE message sent from the toll free
database to the MSC. This field is right justified with leading Fs. This is specifically related to a toll
free call. It is encoded as a 20 character BCD/hex string atomic data field as described in Section
B5.2.10 on page 127.
Field Used In:
1-3 Overseas indicator 000 - not an overseas call (NPA dialled)
001 - not an overseas call (NPA not dialled) determined by network
002 - Not an overseas call (non-NANP terminating number)
003 - 7 digit overseas number
008 - 12 digit or more overseas number
009 - operator special dialled code is in the called number field
4 Sign C
Default: FFFC
Example:
Overseas Indicator: 003C
Table 245 Overseas indicator atomic data field
Field Used In:
1-3 Party Identifier Type 001 = Originating Party data
002 = Terminating Party data
003 = Billing Party data
004 = Aggregate/Feature record DN data
999 = Unknown
4 Sign Character C
Default: FFFC
Example:
Party Identifier (Originating Party Data): 001C
Table 246 Party identifier atomic data field
Field Used In:
B5.3.15 Service Feature Code
This field contains the three digit service feature identification field from the billing indicators
parameter in the RESPONSE message sent from the toll free database to the MSC. This is
specifically related to a toll free call. It consists of a single field as shown in Table 247.
NOTE The MSC does not edit or screen this value. It simply copies the value received in
the toll free database RESPONSE message billing indicators parameter.
B5.3.16 Service Provider Identity
This field identifies the entity on a switch that provides a service to a subscriber. It consists of a
NOTE This field is not currently used. In the records in which this field is present the
default value FFFFFFFFFC will be inserted.
B5.3.17 Supporting Information
This field identifies the source of the Location Routing Number (LRN) which is used to route a call
for a subscriber using the Local Number Portability (LNP) service. The source of the LRN can be a
number database (for example on an Intelligent Network Service Control Point) or datafill on the
MSC. The field also contains information on the status of the LNP query performed. It consists of a
Field Used In:
1-3 Service Feature Code 000-999
4 Sign Character C
Default: FFFC
Example:
Service Feature Code: 001C
Table 247 Service feature code atomic data field
Field Used In:
1 Spare 0
2-9 Service Provider Identity {00000000 - 99999999}
10 Sign Character C
Default: FFFFFFFFFC.
Example:
Table 248 Service provider identity atomic data field
B5.3.18 Terminating Numbering Plan Area
This field contains the area code of the MSC serving a terminating mobile subscriber. In the mobile
terminated record and the roaming record the Terminating NPA field reflects the area code of the
Mobile Subscriber Roaming Number (MSRN) that is used by the network to route the call to the
terminating MSC serving the mobile subscriber. In a Mobile Originating Record the Terminating
NPA field reflects the area code of the Gateway MSC serving the terminating mobile (which is
derived from the translated MSISDN of the terminating mobile). The field defined as a value in the
range 000 to 999 with wrap around from 999 to 000. It consists of a single field as shown in Table
250.
Field Used In:
1 Location Routing Number
(LRN) Source Indicator
1 - Local Number Portability (LNP) Database
2 - Switch System Data
3 - Incoming Signalling
9 - Unknown
2-3 Query Status Indicator 01 = No query failure
02 = No response message received
03 = AIN CONTINUE or Authorize_Termination message received as response
04 = Protocol Error received in response message
05 = Error Detected in response data
06 = Query rejected
09 = No query performed
99 = Query unsuccessful, reason unknown
4 Reserved for Future Use 0
8 Sign Character C
Default: FFFFFFFC
Example:
Supporting Information (LNP database, with no query failure): 1010000C
Table 249 Supporting information atomic data field
Field Used In:
1-3 BCD or Hex String (3) Numbering plan area code
4 Sign Character C
Default: FFFC
Example:
Terminating numbering plan area: 214C
Table 250 Terminating numbering plan area atomic data field
B5.3.19 Toll Free Call Type Code
This field is based on the billing indicators parameter in the RESPONSE message from the toll free
database to the MSC. A call type code of 142 indicates the call is to be handled by the originating
LEC. It consists of a single field as shown in Table 251.
B5.4 Singapore Specific Fields
These fields are all captured only in the Singapore Specific Information Module described in
Section B4.3. They are only supported for MSCs which have the value of singapore in the
MARKET_OF_ OFFICE field in table OFCENG. The fields are shown in Table 252.
B5.4.1 Calling Party Category
This field contains the calling party category (CPC) of a subscriber. It is obtained from the
mandatory CPC parameter contained in a Singapore (ST) ISUP initial address message (IAM). The
Field Used In:
1-3 Toll Free Call Type Code 141 - Call is routed to IXC
142 - Call is routed to LEC
4 Sign Character C
Example:
Toll free call type code: 142C = call routed to LEC
Table 251 Toll free call type code atomic data field
Data Field Size Type Ref.
Calling Party Category 4 Atomic B5.4.1
City Wide Centrex 6 Atomic B5.4.2
Module Code 4 Atomic B5.4.3
National / International Indicator 4 Atomic B5.4.4
Other Subscriber CUSTGRP 6 Atomic B5.4.5
Other Subscriber NCOS 6 Atomic B5.4.6
XCLI Indicator 4 Atomic B5.4.7
Table 252 Singapore market-specific data fields
B5.4.2 City Wide Centrex
This field contains the city wide centrex (CWC) parameter which the MSC obtains from the
optional CWC parameter in a Singapore (ST) ISUP IAM (initial address message). The field
B5.4.3 Module Code
The MSC module code for the Singapore Specific Information Module is 017C.
1 Unused 0
2-3 Calling Party Category 00 - Calling Partys Category Unknown
01 - Operator, Language French
02 - Operator Language English
03 - Operator Language, German
04 - Operator Language, Russian
05 - Operator Language, Spanish
06 - 08 - Available to an administration for selecting a language by mutual agreement
09 - Reserved
0A - Ordinary Calling Subscriber
0B - Calling Subscriber with Priority
0C - Data Call (Voice Band Data)
0D - Test Call
0E - Spare (Non-voice Terminal)
0F - Payphone
10 - F9 Spare
FA - FE - Reserved for National Use
FF - Spare
4 Sign Character C
Default: 000C
Example:
Calling Partys Category (Ordinary): 00AC
Table 253 Calling party category atomic data field
1 Unused 0
2-3 User Defined Byte 8 00 - FE
4-5 User Defined Byte 9 00 - FE
6 Sign Character C
Default: 0FFFFC
Example:
City Wide Centrex:00102C
Table 254 City wide centrex atomic data field
B5.4.4 National / International Indicator
This field can be used to determine if a Goods and Sales Tax is applicable to a call. It is obtained
from the mandatory Forward Call Indicator parameter contained in a Singapore (ST) ISUP initial
address message (IAM).The field encoding is shown in Table 255.
B5.4.5 Other Subscriber CUSTGRP
This field provides other agents customer user group information, if available. It is only available
on mobile to mobile calls. The field encoding is shown in Table 256.
B5.4.6 Other Subscriber NCOS
This field provides the other agents class of service information, if available. It is only available on
mobile to mobile calls. The field encoding is shown in Table 257.
1 Spare 0
2-3 National/International Indicator 00 - National call
01 - International call
4 Sign Character C
Default: FFFC
Example:
National/International Indicator Code (International Call): 001C
Table 255 National / international indicator atomic data field
1-5 Customer Group 00000-04095
6 Sign Character C
Default: 00000C
Example:
CUSTGRP: 01234C
Table 256 Other subscriber CUSTGRP atomic data field
1-5 Network Class of Service 00000 - 000255
6 Sign Character C
Default: 00000C
Example:
NCOS: 00255C
Table 257 Other subscriber NCOS atomic data field
B5.4.7 XCLI Indicator
This field contains an indication of whether or not the calling subscriber has subscribed to the
Calling Line Identification restriction feature. It is obtained from the mandatory Calling Party
Number parameter contained in a Singapore (ST) ISUP initial address message (IAM). This field is
only captured in Mobile Terminated, Roaming, and Outgoing Trunk records. The field encoding is
shown in Table 258.
B5.5 German and Austrian Market-Specific Fields
These fields are captured only in the German and Austrian Carrier Specific Information Module
described in Section B4.3. The fields are shown in Table 259.
B5.5.1 Default Carrier Identification Code (CIC)
This field captures the default CIC which is datafilled on the MSC. This CIC is compared to the
selected CIC signalled in the initial address message (IAM). If the CICs are the same, the call is
subjected to screening to make sure that the calling party can use the network facilities of the
selected carrier. The CIC is defined and distributed by a regulatory authority and it may be specified
as a two-character or a three-character code as shown in Tables 260 to 263.
1 spare 0
2-3 XCLI Code 00 - Presentation allowed
01 - Presentation restricted
02 - Address not available
03 - Spare
4 Sign Character C
Default: FFFC
Example:
XCLI Indicator Code: 001C
Table 258 XCLI indicator atomic data field
Data Field Size Type Ref.
Default Carrier Identification Code (CIC) 4 Atomic B5.5.1
Module Code 4 Atomic B5.5.2
Selected Carrier Identification Code (CIC) 4 Atomic B5.5.3
Subscriber Customer Group 6 Atomic B5.5.4
Table 259 German and Austrian market-specific data fields
B5.5.1.1 German Market Default Carrier CICs

B5.5.1.2 Austrian Market Default Carrier CICs
NOTE CICs must not start or end with a zero (0). The first character of a 3-digit CIC
must be in the range of 6 to 9.
B5.5.2 Module Code
The module code for the Carrier Selection Charging Information Module is 024C.
1 Unused F
2-3 CIC 10 - 99
4 Sign Character C
Default: FFFC
Example:
Carrier Identification Code: F24C
Table 260 Default CIC - 2-digit German Market CIC
1-3 CIC
000 - 099
a
a. All 3-digit CICs must start with a leading 0.
4 Sign Character C
Default: FFFC
Example:
Carrier Identification Code: 035C
Table 261 Default CIC - 3-digit German Market CIC
1 Unused F
2-3 CIC 11 - 99
4 Sign Character C
Default: FFFC
Example:
Table 262 Default CIC - 2-digit Austrian market CIC
1-3 CIC 601 - 999
4 Sign Character C
Default: FFFC
Example:
Table 263 Default CIC - 3-digit Austrian market CIC
B5.5.3 Selected Carrier Identification Code (CIC)
This field captures the selected CIC which is contained in the initial address message signalled
during call setup. At the gateway MSC this CIC is compared to the default CIC stored in datafill on
the switch. If the CICs are the same, the call is subjected to screening to make sure that the calling
party can use the network facilities of the selected carrier. The CIC is defined and distributed by a
regulatory authority and may be specified as a two-character or a three-character code as shown in
Tables 264 to 267.
B5.5.3.1 German Market Selected CICs
B5.5.3.2 Austrian Market Selected CICs
NOTE CICs must not start or end with a zero (0). The first character of a 3-digit CIC
must be in the range of 6 to 9.
1 Unused F
2-3 CIC 10 - 99
4 Sign Character C
Default: FFFC
Example:
Table 264 Selected CIC - 2-digit CIC
1-3 CIC
000 - 099
a
a. All 3-digit CICs must start with a leading 0.
4 Sign Character C
Default: FFFC
Example:
Table 265 Selected CIC - 3-digit CIC
1 Unused F
2-3 CIC 11 - 99
4 Sign Character C
Default: FFFC
Example:
Table 266 Selected CIC - 2-digit Austrian market CIC
1-3 CIC 601 - 999
4 Sign Character C
Default: FFFC
Example:
Table 267 Selected CIC - 3-digit Austrian market CIC
B5.5.4 Subscriber Customer Group
This field captures the subscriber group (also called subscriber class) of the calling party. It is
captured by a MSC acting as a point of interconnect (POI) and is used to determine routing options
for the call. Subscriber group options are defined by the CUSTINFO table option in the tables
DNSCRN and PETSERVS. CUSTINFO may be set to REG, UNREG, PRESEL, UNPAID or
BLOCK. The information is captured in a single field as shown in Table 268.
NOTE This field (Subscriber Customer Group) is not used in the Austrian market since
carrier screening is not done. In the Austrian market the field has always the
default value 00000C.
1-4 Unused 0000
5 Subscriber Customer Group 1 - Registered
2 - Unregistered
3 - Preselected
4 - Blocked
5 - Unpaid
6 - Unspecified
6 Sign Character C
Default: 00000C
Example:
Subscriber Customer Group (Registered): 00001C
Table 268 Subscriber Customer Group
B6 Example Call Scenarios
Before looking at these examples bear the following in mind:
It is assumed that the generation of all billing record types is enabled. Some of the MSC
billing records may be enabled or disabled on a per trunk basis. Section B4.1 identifies
those records which may be enabled or disabled.
The types of trunk records generated by an MSC are dependent on datafill. The example
scenarios show the records which may be produced but they are not definitive.
The call scenarios in this section assume that the SOC option GSM Generic Address
Info is not switched on. However, if the SOC is on, the generic address information
module is appended to the mobile originated and terminated call records, the roaming
records and the incoming and outgoing trunk records shown in the call scenarios.
The MSC and VLR are implemented as one on the MSC platform.
If MAP Phase 3 is used during mobile terminated call setup the terminating record also
has a Network Call Reference module appended to it. This is not shown in the diagrams
as they make no assumptions about the version of MAP used in call establishment.
The following examples are included:
B6.1, Mobile to Land (Outgoing) Call on page 262
B6.2, Partial Billing in a Mobile to Land (Outgoing) Call on page 264
B6.3, Land to Mobile (Incoming) Call on page 265
B6.4, Mobile to Mobile Call Within the Same Network on page 266
B6.5, Calls Involving Roaming Mobile Subscribers on page 269
B6.6, Incoming Call to a PLMN Service Centre on page 271
B6.7, Call Forwarding on page 272
B6.8, Delivery and Origination of Short Messages on page 276
B6.9, Call Hold and Multi-party Services on page 277
B6.10, Explicit Call Transfer Service on page 279
B6.11, Redirection and Call Dropback Services on page 281
B6.12, Handover on page 285
B6.13, Local Number Portability on page 288
B6.14, Extension Services on page 290
B6.15, Intelligent Network (IN) Scenarios on page 291
This section contains a number of example scenarios illustrating the purpose and practical usage of
the various types of records defined in the previous sections. These examples are neither exhaustive
nor definitive. Fully reviewed and tested billing examples are on the sample billing CDROM: see
References and Sample Information on page viii.
B6.16, CAMEL Mobility Management Service on page 299
B6.17, Call Independent Supplementary Service Action on page 299
B6.18, Invoking the Billing Zone Query Service Using USSD on page 300
B6.19, Optimal Routing of a Late Forwarded Call on page 301
B6.20, Mobile Number Portability (MNP) on page 303
B6.21, Location Services (LCS) on page 306
B6.22, Enhanced Multi-level Precedence And Pre-emption Service (eMLPP)
Call on page 308
B6.23, GSM-R Call Scenarios on page 311
B6.24, Market-Specific Call Scenarios on page 314
B6.1 Mobile to Land (Outgoing) Call
Figure 10 depicts a mobile originated call to a fixed network subscriber. In this scenario, the mobile
handset signals the call requirements to the serving MSC, which generates a mobile originated call
(MOC) record for the mobile subscriber. The call is then routed to a gateway MSC (GMSC) based
on the ISDN/PSTN number. The serving MSC generates an outgoing intra-PLMN (OGIP) trunk
record and the gateway MSC generates an incoming intra-PLMN (ICIP) trunk record. The gateway
MSC also generates an outgoing gateway (OG) record which can be used for accounting purposes.
Figure 10 Mobile to land (outgoing) call
Gateway
MSC
MSC
HLR
ISDN/PSTN
HPLMN
Record
ICIP
OG
Record
Record
OGIP
MOC
Record
L&C
TS
EoM
Key
ICIP Incoming Intra-PLMN Trunk Record
MOC Mobile Originated Call Attempt Record
OG Outgoing Gateway
OGIP Outgoing Intra-PLMN Trunk Record
EoM End of Module List Module
L&C Location and Channel Information Module
TS Teleservice Information Module
If the mobile station is served directly by the gateway MSC, the scenario shown in Figure 10 is
simplified. In this case, the gateway MSC produces a MOC record and an OG record.
In the Release 4 Bearer Independent Control Network (BICN) the signalling and bearer planes are
separated and the bearer connections are established through media gateways. Figure 11 shows the
call scenario in Figure 10 but for a Release 4 BICN.
Figure 11 Mobile to land (outgoing) call in a Release 4 BICN
Gateway
MSC
MSC
HLR
HPLMN
Record
OG
ICIP
Record
Record
OGIP
MOC
Record
L&C
TS
EoM
Key
OG Outgoing Gateway
BICN Bearer Independent Core Network Information Module
MGW MGW MGW MGW
ISDN/PSTN
BICN
EoM
BICN
BICN
EoM
BICN
EoM
B6.2 Partial Billing in a Mobile to Land (Outgoing) Call
Figure 12 depicts the same call scenario shown Section B6.1 Figure 10, but with partial billing
records created because the call lasts for a long time. The call detail records in each case contain the
same information except in the timestamp fields. The timestamp fields capture the duration of the
record not the total duration of the call. The partial records contain the cause for termination (CFT)
value partial record except for the final set of records which contain the cause of the calls release.
In this scenario, the CFT in the partial records labelled (part 1) contains the cause partial record
and the CFT in the partial records labelled (final) contains the cause of the calls release. The
modules appended to the MOC record (part 1) are also appended to the partial MOC record (final).
The MOC record (final) may also have additional modules appended. For example if the subscriber
invokes a supplementary service (SS) in the second portion of the call, the MOC record (final) has
an appended SS information module.The partial information modules also contain record and
sequencing information.
Figure 12 Partial records in a mobile to land (outgoing) call - long duration call
Partial records may also be generated if a record exceeds the maximum size and if a call is re-
established after a radio failure. The content of the partial records depends on the conditions under
which they were created. For more information on partial billing, refer to Section B3.4 on page 40.
Gateway
MSC
MSC
HLR
ISDN/PSTN
HPLMN
Record
OGIP
MOC
Record
L&C
TS
EoM
Key
OG Outgoing Gateway
Part Partial Information Module
(part 1)
Part
MOC
Record
L&C
TS
EoM
(final)
Part
EoM
Part
(part 1)
Record
OGIP
EoM
Part
(final)
Record
ICIP
EoM
Part
(part 1)
Record
ICIP
EoM
Part
(final)
Record
OG
EoM
Part
(part 1)
Record
OG
EoM
Part
(final)
B6.3 Land to Mobile (Incoming) Call
Figure 13 illustrates an incoming call from the fixed network to the PLMN. The incoming call is
initially routed to a gateway MSC (GMSC). The GMSC creates an incoming gateway (IG) record
which can be used for accounting purposes. After querying the HLR, the GMSC creates a roaming
record and then routes the call to the MSC where the subscriber is currently registered. This results
in the generation of an outgoing intra-PLMN (OGIP) trunk record in the GMSC. In addition, the
terminating MSC will create a incoming intra-PLMN (ICIP) trunk record and a mobile terminating
call (MTC) record for the terminating mobile subscriber.
Figure 13 Land to mobile (incoming) call
If the mobile station is served directly by the GMSC, the scenario shown in Figure 13 is simplified.
In this case, the GMSC produces an IG record and a MTC record.
Figure 14 shows the same scenario as in Figure 13, but for a Release 4 Bearer Independent Core
Network (BICN).
Gateway
MSC
MSC
HLR
ISDN/PSTN
HPLMN
IG
Record
Record
OGIP
Record
ICIP
MTC
Record
SRI
Record
Roaming
TS
EoM
L&C
TS
EoM
Key
IG Incoming Gateway Record
MTC Mobile Terminated Call Attempt Record
Figure 14 Land to mobile (incoming) call in a Release 4 BICN
B6.4 Mobile to Mobile Call Within the Same Network
This section shows two mobile to mobile call scenarios: one where both mobile stations are located
at the same MSC and one where the terminating party is on a different MSC to the calling party. The
scenarios are shown for a Release 99 or earlier network (Figures 15 and 16) and for a Release 4
Bearer Independent Core Network (BICN) (Figures 17 and 18).
In Figure 15, both mobile stations are located at the same MSC. At the start of the call, the
originating mobile sends a call setup message to the MSC. The MSC creates a mobile originating
call (MOC) record and queries the HLR for routing information. The HLR queries the MSC to find
the called subscribers location and returns routing information to the MSC. The MSC sets up the
connection to the called party and creates a mobile terminated call (MTC) record. The outgoing
trunk seizure field in the MOC contains the time at which the channel to the terminating MS was
allocated. The incoming trunk seizure field in the MTC contains the time at which a mobile channel
was allocated to the calling party.
Visited
MSC
Gateway
MSC
Gateway
HLR
HPLMN
ICIP
Record
Record
OGIP
BICN
EoM
BICN
EoM
Record
Roaming
TS
EoM
IG
Record
EoM
BICN
MTC
Record
L&C
TS
EoM
BICN
MGW MGW
MGW MGW
ISDN/PSTN
Key
IG Incoming Gateway
MSC
Figure 15 Mobile to mobile call with both mobiles at the same MSC
Figure 16 illustrates a mobile originated call to another mobile subscriber who is currently roaming
at another MSC within his home PLMN (HPLMN). The incoming call initially enters the Gateway
MSC (GMSC) in the terminating mobile subscribers HPLMN. At this point, the GMSC creates a
mobile origination call (MOC) record. The GMSC queries the HLR to obtain routing information.
The GMSC routes the call to the terminating MSC where the mobile subscriber is currently located.
Also, the GMSC creates a roaming record and a outgoing intra-PLMN (OGIP) trunk record. The
roaming record will contain information such as IMSI of the terminating mobile subscriber. Upon
receiving the call, the terminating MSC creates an incoming intra-PLMN (ICIP) trunk record for
the incoming call and a mobile termination call (MTC) record for the terminating mobile
subscriber. If the call is routed through a transit MSC, then the transit MSC generates an incoming
intra-PLMN (ICIP) trunk record and an outgoing intra-PLMN (OGIP) trunk record.
MOC
Record
SRI
MSC
HLR
L&C
TS
EoM
MTC
Record
L&C
TS
EoM
Key
Figure 16 Mobile to mobile call with the subscribers on different MSCs
Figures 17 and 18 show the previous two scenarios for a Release 4 Bearer Independent Core
Network (BICN).
Figure 17 Mobile to mobile call with both mobiles at the same MSC in a Release 4 BICN
MSC MSC
HLR
HPLMN
Record
ICIP
OGIP
Record
OGIP
Record
Roaming
Record
ICIP
Record
MTC
Record
SRI
Gateway
MSC
MOC
Record
L&C
TS
EoM
TS
EoM
L&C
TS
EoM
Key
SRI
MSC
HLR
Key
MOC
Record
L&C
TS
EoM
BICN
MTC
Record
L&C
TS
EoM
BICN
MGW MGW
Figure 18 Mobile to mobile call with the subscribers on different MSCs in a Release 4
BICN
B6.5 Calls Involving Roaming Mobile Subscribers
This section contains call scenarios involving mobile subscribers who have roamed from their
HPLMN to a visited PLMN (VPLMN).
B6.5.1 Call Made by the Roaming Subscriber to Another Mobile Subscriber
In this scenario, the roaming mobile subscriber makes a call to a mobile subscriber in the network
which he/she is visiting. These calls result in the same records as for the mobile to mobile calls
shown in Figures 15 to 18. In these scenarios, the HPLMN is the called partys. The information
which shows that the calling party is roaming is captured in the MOC record. This record contains
the calling partys IMSI, part of which is the mobile network code (MNC) of the subscribers home
network. The roaming record shown in Figures 16 and 18 captures information for the called party
and results from the interrogation of the HLR.
MSC
Gateway
HLR
HPLMN
ICIP
Record
Record
OGIP
MOC
Record
L&C
TS
EoM
Key
MGW MGW
MGW MGW
BICN
EoM
BICN BICN
EoM
MSC
Roaming
Record
TS
EoM
MTC
Record
L&C
TS
EoM
BICN
SRI
B6.5.2 Incoming Call to a Roaming Subscriber
Figure 19 illustrates an incoming call from the fixed network to a mobile subscriber who is
currently roaming outside his home PLMN (HPLMN). The incoming call is initially routed to the
gateway MSC (GMSC) in the mobile subscribers HPLMN. At this point, the GMSC creates a
incoming gateway (IG) record which can be used for accounting purposes. The GMSC queries the
HLR to obtain routing information. The GMSC of the HPLMN routes the call to the visiting PLMN
(VPLMN), where the mobile subscriber is currently located. Also, the GMSC of the HPLMN
creates a outgoing gateway (OG) record and a roaming record. The roaming record will contain
information such as IMSI of the mobile subscriber. Upon receiving the call, the GMSC of the
VPLMN creates an IG record. In addition, it creates an OG intra-PLMN trunk record. The call is
routed by the VPLMN to the terminating MSC, which creates a IC intra-PLMN trunk record for the
incoming call and a mobile terminated call record for the terminating mobile subscriber.
Figure 19 Incoming call to a roaming subscriber
As a variation on the scenario shown in Figure 19, the calling party may be a mobile subscriber
whose HPLMN is the one that the roaming party is visiting. In this case, the VPLMN in Figure 19
routes the call to the roaming partys HPLMN: the originating MSC creates a mobile originated call
(MOC) record and the intermediate MSCs create incoming/outgoing trunk records. The records
created after this are the same as in Figure 19 as the roaming partys HPLMN provides information
on the mobiles location and the call is completed to it. The IMSI captured in the MTC record
shows that the called party is roaming because it contains a different mobile network code (MNC)
from that of the VPLMN.
Gateway
MSC
HLR
HPLMN
Gateway
MSC
MSC
VPLMN
Roaming
Record
MTC
Record
IG
Record
OG
Record
Record
OGIP
Record
ICIP
SRI
ISDN/PSTN
IG
Record
L&C
TS
EoM
TS
EoM
Key
IG Incoming Gateway
OG Outgoing Gateway Record
Figure 20 shows the scenario from Figure 19 but for a Release 4 Bearer Independent Core Network
(BICN).
Figure 20 Incoming call to a roaming subscriber in a Release 4 BICN
B6.6 Incoming Call to a PLMN Service Centre
Figure 21 illustrates a incoming call from a fixed network to a Service Centre. Services provided by
a Service Centre include voice mail, operator services, etc. The call is initially routed to a gateway
MSC (GMSC). The GMSC creates an incoming gateway (IG) record based on the point at which
the call entered the network and the destination of the call, and routes the call to the terminating
MSC. As a result of the outgoing call, a OG intra-PLMN trunk record is generated in the GMSC.
Similarly, an incoming intra-PLMN (ICIP) trunk record is generated in the terminating MSC. The
call is then connected to the service centre. Since no mobile subscriber is involved, the MSC does
not create a mobile terminated call record. Instead, the MSC generates a transit record describing
the destination of the call. Generation of the transit record assumes that the VMS trunk group is
defined as a transit route on the MSC.
Gateway
HLR
HPLMN
Record
OG
Key
IG Incoming Gateway
OG Outgoing Gateway
MGW MGW
MGW MGW
BICN
EoM
MSC
Roaming
Record
TS
EoM
SRI
ISDN/PSTN
IG
Record
BICN
EoM
VPLMN
MSC
MTC
Record
L&C
TS
EoM
BICN
MGW MGW
Gateway
MSC
IG
Record
BICN
EoM
Record
OGIP
BICN
EoM
ICIP
Record
BICN
EoM
Figure 21 Incoming call to a PLMN service centre
B6.7 Call Forwarding
This section describes an example call forwarding scenario and explains why some records for call
forwarding have an appended location information and channel information module while others do
not.
B6.7.1 Example Call Forwarding Scenario
Figure 22 illustrates a call forwarding scenario, showing it to consist of two legs. An incoming call
from the fixed network (leg 1) is initially routed to a gateway MSC (GMSC). After querying the
HLR and receiving a redirecting number from it, the GMSC forwards the call to the fixed network
(leg 2). For leg 1, the GMSC creates an incoming gateway (IG) record which can be used for
accounting purposes. After receiving the redirecting number, the GMSC terminates leg 1 and
creates a mobile terminating call (MTC) forwarding attempt record. This record is for the
terminating mobile subscriber who is registered with call forwarding. For the origination of leg 2,
the GMSC creates a mobile originating call (MOC) call forwarding attempt record. Because leg 2
terminates in the PSTN, the GMSC also creates an outgoing gateway (OG) record.
Gateway
MSC
MSC
ISDN/PSTN
HPLMN
Service
Center
IG
Record
OGIP
Record
ICIP
Record
Transit
Record
Key
IG Incoming Gateway
Some countries require that directory numbers presented to the network are in national format.
Operators can datafill the MSC (using office parameters REPLACE_MS_CC_DIGITS and
REPLACE_INTL_ROAM_CLID in table GSMVAR) to provide national format numbers,
including those presented in calls involving redirection. If this feature is active on the gateway MSC
in Figure 22, the following numbers are captured in national format: the number of the ISDN/PSTN
calling party which is captured in the calling number field of the MTC call forward record; the
redirecting number, which is the number of the called mobile station, is captured in the calling
number field of the OG record. The calling number field in the IG and MOC records contains a
number in international format.
Operators can also use other datafill in tables OFCVAR and PETSIG to set the format of the calling
number, the redirecting number and the original called number captured in MTC and outgoing trunk
records. These tables contain the office parameter PREFERRED_NOA which has fields for the
calling number, the redirecting number and the original called number. The keyword entries in these
fields define the format of the associated number. The numbering formats specified by this datafill
override that specified by the REPLACE_MS_CC_ DIGITS and REPLACE_INTL_ROAM_CLID
parameters in GSMVAR. Operators can use either method to set the format of the signalled
numbers.
Some administrations bill the calling party for the forwarded leg of the call. In this case, the office
parameter USE_ORIGINAL_CGPN_FOR_BILLING in table OFCVAR can be used to specify that
the calling number is captured for billing purposes rather than the redirecting number. However, the
setting of the office parameter may itself be overridden by the SOC option GSM Generic Address
Info. If this SOC option is on, the setting of the office parameter has no effect and the redirecting
number is captured for billing purposes. The generic address information module is appended to all
call records to capture the original calling number and the pre-translated called party number. The
calling number fields in the call records of the call forwarding leg contain the redirecting partys
number.
Figure 23 shows the call scenario from Figure 22 but for a Release 4 Bearer Independent Core
Network (BICN).
Figure 22 Call forwarding
Figure 23 Call forwarding in a Release 4 BICN
Gateway
MSC
MSC
HLR
ISDN/PSTN
HPLMN
IG
Record
MTC
Forwarding
Record
MOC
Forwarding
Record
OG
Record
SRI
TS
SS
EoM
TS
SS
EoM
Key
SS Supplementary Service Information Module
ISDN/PSTN
Key
MOC Mobile Originated Call Forward Attempt Record
MTC Mobile Terminated Call Forward Attempt Record
HLR
HPLMN
MGW MGW
Gateway
MSC
IG
Record
BICN
EoM
Record
OG
BICN
EoM
SRI
MTC
Forward
Record
TS
SS
EoM
MOC
Forward
Record
TS
SS
EoM
B6.7.2 Location Information and Call Forwarding Records
The presence or absence of location and channel information depends on the particular call
forwarding scenario. Assume the following terminology:
In a call forwarding scenario, mobile A calls mobile B who is forwarded to mobile C.
The billing records produced for that call are:
- Mobile Originated Call Attempt for A to B
- Mobile Terminated Call Forwarding Attempt for A to B
- Mobile Originated Call Forward Attempt for B to C
- Mobile Terminated Call Attempt for B to C
Where call forwarding is unconditional, there is no location and channel information available for
the forwarding mobile, i.e. mobile B. In call forwarding unconditional neither the MSRN nor the
location information is available for capture due to the message flow. This is because the decision to
forward the call is made at the HLR before any call messaging is sent to the VLR. Because of the
call scenario, no attempt made to find the mobile, the location information is unknown and an
MSRN (mobile station roaming number) is never allocated. As a result of this, a location and
channel information module is not appended to the billing record. This is a type of call forwarding
called early call forwarding which has this name because the call is forwarded before being
connected to the originally called party.
There are two different types of call forwarding on busy (CFB): Network Determined User Busy
(NDUB) and User Determined User Busy (UDUB). These are both examples of late call forwarding
where the call is connected to the VMSC of the called party before being forwarded. The location
and channel information captured for the call is dependent on which type of call busy condition
causes call forwarding.
In NDUB call forwarding, the network determines that the called party is busy. The actions of the
MSC depend on the setting of the SOC GSM CF NDUB Bill Rec (B3.8.2 on page 56). If this SOC
option is on, the MSC captures location information in a location and channel information module
appended to the mobile terminated call forward attempt record generated for the redirecting party.
The module captures the known location information in the following fields: MSC number, location
area code, cell-SAC (service area code) identity, date and time and access network. If the SOC
option is off, the location and channel information module is not appended to the call record.
When a call is forwarded UDUB:
- an MSRN is allocated
- a page request is sent to the VLR
- the VLR pages the mobile
- the mobile responds with a busy indication.
Since the mobile was actually found, the location information is known. In this case, which is the
same as call forwarding on No reply (CFNRy), the MSRN and the location information are known
and are populated in the location and channel module appended to the billing record.
The call forwarding condition call forward not reachable (CFNRc) can look like either call forward
unconditional or call forward NDUB depending on where the decision is made that the called party
is not reachable. If the mobile is Not Reachable-detached at the HLR the forwarding condition
looks like Call Forward Unconditional. If an attempt is made to find the mobile by the VLR, it looks
like NDUB in which case an MSRN is allocated, but the location information is not known.
B6.8 Delivery and Origination of Short Messages
B6.8.1 Delivery of a Mobile Terminated Short Message
Figure 24 illustrates a incoming call from the Short Message Service Centre to a mobile subscriber.
The SMS-SC interrogates the HLR to find the location of the subscriber to whom the message is to
be delivered. The incoming message is sent to a MSC. The MSC then sends the message to the
terminating mobile. This transaction results in the generation of a mobile terminated (MT) short
message service (SMS) record.
Figure 24 Delivery of short message to a mobile subscriber
B6.8.2 Origination of a Short Message
Figure 25 illustrates the origination of a short message by a mobile station. The mobile signals that
it wants to send a short message. The MSC routes the message to the service centre (SMS-SC)
which confirms receipt of the message. This transaction results in the creation of a mobile
originated (MO) SMS call record.
MSC
HPLMN
SMS-SC
HLR
MT
SMS
Record
LO
Key
MT SMS Mobile Terminated Short Message Service Record
LO Location Only Information Module
EoM
Figure 25 Origination of a short message
B6.9 Call Hold and Multi-party Services
Figure 26 illustrates a 3-party conference call between a fixed network and two mobile subscribers.
Mobile A initiates a call to the fixed network (PSTN). The mobile originated (MO) call enters the
serving MSC, which generates a mobile originated call (MOC) record for the mobile subscriber.
The call is then routed to a gateway MSC (GMSC), which shall create an incoming intra-PLMN
(ICIP) trunk record. It also produces an outgoing gateway (OG) record which can be used for
accounting purposes. In addition, an outgoing intra-PLMN (OGIP) trunk record is generated in the
serving MSC.
Mobile A then puts the PSTN agent on hold, this results in a call hold supplementary service
module to be appended to the MOC record for A to PSTN, and initiates a call to mobile C. Again,
the serving MSC generates a MOC record for mobile A for the A to C call. It queries the HLR for
information on Cs location and generates a roaming record and an outgoing intra-PLMN (OGIP)
trunk record. The call is then routed to the terminating MSC, which creates an incoming intra-
PLMN (ICIP) trunk record and also a mobile terminated call (MTC) record for the terminating
mobile.
Mobile A then initiates the multi-party service to bridge all three parties together into a conference
call. This transaction results in a multi-party supplementary service module to be appended to each
of mobile As records to indicate the invocation of the multi-party service. Subscriber As records
include the MOC record (A to PSTN) and the MOC record (A to C). In addition a common
equipment usage (CEU) record is generated to record usage of conference facilities, for example,
the conference bridge.
MSC
HPLMN
SMS-SC
MO
SMS
Record
LO
EoM
Key
MO SMS Mobile Originated Short Message Service Record
Figure 26 Call hold and multi-party services
Figure 27 shows the same scenario but for a Release 4 Bearer Independent Core Network (BICN).
Gateway
MSC
MSC
ISDN/PSTN
MSC
HPLMN
MOC
Record
(A to
A
C
PSTN)
MTC
Record
OGIP
Record
(A to
PSTN)
OG
Record
ICIP
Record
(A to
PSTN)
OGIP
Record
(A to C)
ICIP
Record
(A to C)
(A to C)
(A to
PSTN)
CEU
Record
MOC
Record
HLR
Roaming
Record
(A to C)
(A to C)
Key
CEU Common Equipment Usage Record
L&C
TS
EoM
SS
L&C
TS
EoM
SS
TS
TS
L&C
TS
EoM
EoM
EoM
Figure 27 Call hold and multi-party services in a Release 4 BICN
B6.10 Explicit Call Transfer Service
The explicit call transfer service allows a subscriber to put a party on hold to establish a call to
another party. The subscriber can then drop out of the call to leave the originally held party and the
new party connected together. Figure 28 shows an example scenario.
HLR
HPLMN
MSC
SRI
A
Gateway
MGW
C
MSC
MGW MGW
B
MGW MGW
MGW
MGW MGW
Final bearer path to
Intermediate bearer paths
conference-enabled gateway
ISDN/PSTN
MOC
Record
(A to
PSTN)
L&C
TS
EoM
SS
Key
OG Outgoing Gateway
ICIP
Record
BICN
EoM
(A to
PSTN)
OGIP
Record
BICN
EoM
(A to
PSTN)
OG
Record
BICN
EoM
(A to
PSTN)
MOC
Record
(A to C)
OGIP
Record
BICN
EoM
(A to C)
Roaming
Record
TS
EoM
(A to C)
BICN
L&C
TS
EoM
SS
BICN
CEU
Record
TS
EoM
MSC
MTC
Record
L&C
TS
EoM
BICN
(A to C)
ICIP
Record
EoM
BICN
(A to C)
Figure 28 Explicit Call Transfer Service
The call from party B arrives at the gateway MSC which captures the incoming call details in an
incoming gateway (IG) record. It then queries the HLR to find the location of party A and routes the
call using the returned information. It creates a roaming record and an outgoing intra-PLMN record
to capture the call details. The serving MSC receives the call setup information and connects the
call to party A. It creates an incoming intra-PLMN (ICIP) record and a mobile terminated call
(MTC) record to capture the call details.
Party A then puts party B on hold and sets up the call to party C. The MSC appends a
supplementary service (SS) information module to the MTC record to capture the call hold details
and creates a MOC record for the new call. It then queries the HLR for routing information and
routes the call to party C using the returned information. It captures details in a roaming record and
an outgoing intra-PLMN (OGIP) record. The MSC serving party C creates an ICIP record and an
MTC record to capture the call details. Party A then invokes the ECT service by sending a
FACILITY message to its serving MSC. The MSC removes the traffic connections to party A and
bridges the calls to connect party B and party C. It captures the ECT information in two SS
information modules which it appends to the MOC and MTC records associated with party A. The
SS Parameter fields in the SS information modules contain the directory numbers for parties B and
C. The SS information module appended to the MTC record for the call from B to A has the
directory number of party C in the SS Parameters field. The SS information module appended to the
MOC for the call from A to C has the directory number of party B in the SS Parameters field.
Gateway
MSC
MSC
ISDN/PSTN
MSC
HPLMN
MTC
Record
(PSTN
A
C
to A)
MTC
Record
ICIP
Record
(PSTN
to A)
IG
Record
OGIP
Record
(PSTN
to A)
OGIP
Record
(A to C)
(A to C)
(PSTN
to A)
MOC
Record
HLR
Roaming
Record
(A to C)
(A to C)
ICIP
B Roaming
Record
(PSTN
to A)
Key
L&C
TS
EoM
SS
SS
Record
(A to C)
L&C
TS
EoM
SS
L&C TS
EoM
TS
EoM
TS
EoM
The example scenario shows party A being called and then calling party C. However, each call
involving party A may be established as an incoming or outgoing call. This means that the call
records generated for party A may be two MOC or two MTC call records, or one MOC and one
MTC record. MS A is billed for any chargeable leg of the transferred call. So, for example, if party
A makes both calls before invoking ECT (A calls B, puts B on hold, then calls C and invokes ECT),
he/she is billed for both legs of the transferred call involving parties B and C.
The example scenario shows party B in the PSTN and party C in the HPLMN, but in theory there is
no restriction on the location of these parties. However the HPLMN operator may impose
subscription limitations to prohibit ECT with certain network operators.
The ECT service can also be triggered using USSD (Unstructured Supplementary Service Data). In
this case the user invokes the service by entering a USSD string on the mobile station and pressing
SEND. The MSC captures information about the USSD service invocation in a Supplementary
Service Action Record. In this record, the SS parameters field captures the USSD string, the SS
code field indicates USSD (081C) and the SS action field shows that the service was invoked (5C).
The other records generated for USSD-initiated ECT are the same as those in Figure 28.
B6.11 Redirection and Call Dropback Services
This section describes scenarios for the voicemail call dropback service, the call re-origination
service and the network optimisation service.
B6.11.1 Voice Mail Call Dropback
Figure 29 shows the billing records which may be generated as part of the voice mail call dropback
facility (VMCDB). This facility allows a call made to a voice mail system to be re-routed to a new
destination. The MSC connects the originating mobile station to the voice mail system and captures
information in a mobile originated call (MOC) record and a transit record. The voice mail system
then signals a new called number to the MSC and requests that the trunks between it and the MSC
are released. The MSC clears the connection to the voice mail system and captures the new call
details and trunk release request in an incoming intra-PLMN (ICIP) trunk record. The MSC creates
a connection to the new called party and creates a MTC record for the new call. The supplementary
service information module appended to the transit and IC intra-PLMN trunk records contains
details of the VMCDB service.
Figure 29 Voice mail call dropback
Figure 29 shows the records created if the originating and terminating parties are both mobile
stations connected at the same MSC. If the originating agent at the MSC is a trunk, an incoming
trunk record such as an incoming intra-PLMN (ICIP) trunk or incoming gateway (IG) record is
created rather than a MOC. If the MSC re-routes the call to the PSTN it creates an outgoing trunk
record. If the MSC re-routes the call to a mobile station served by another MSC, it creates a
roaming record and an outgoing trunk record such as an outgoing intra-PLMN trunk record.
Some countries require that directory numbers presented to the network are in national format. The
MSC may be datafilled (using the office parameters REPLACE_MS_CC_DIGITS and
REPLACE_INTL_ROAM_CLID in table GSMVAR) to provide national format numbers,
including those presented in calls involving redirection. If this feature is active on the MSC in
Figure 29, the following numbers are captured in national format: the number of MS A is captured
in the calling number field of the transit record (call to VMS); the redirecting number, which is the
number of the VMS, is captured in the calling number field of the MTC record (new call). The
calling number fields in the MOC and IC intra-PLMN records are in international format.
numbers.
MSC
VMS
MOC
Record A
B
MTC
Record
(new
call)
(call to
VMS)
Transit
Record
(call to
VMS)
ICIP
Record
(new
call)
Key
L&C
TS
EoM
SS
EoM
SS
EoM
L&C
TS
EoM
number.
B6.11.2 The Nortel ETSI ISUP Call Re-Origination Service
For this service, the MSC creates a connection to a called party over ISUP trunks. The called party,
acting as a dropback agent, returns an ISUP Release message containing redirection parameters.
The MSC releases the original connection and sets up a new call to the new called number.
This service generates billing records which are similar to those generated by the VMCDB service
shown in Figure 29. This figure illustrates the re-origination service if you substitute the exchange
serving the dropback agent for the VMS. For the first call, the MSC creates a MOC record, and
depending on the location of the original called party, either an Outgoing intra-PLMN or an
Outgoing Gateway record. For the second call, the MSC creates either an Incoming intra-PLMN or
an Incoming Gateway record. The terminating record depends on the location of the new called
party. In Figure 29 the new called party is MS B and so the record is a Mobile Terminated Call
record. If the new call is routed off the MSC, the terminating record is one of the outgoing trunk
records. The details of the re-origination service are captured in supplementary service information
modules appended to outgoing trunk record of call 1 and the incoming trunk record of call 2. The
service is identified by the SS code field in these modules.
As with VMCDB, the original calling number and redirecting number may be captured in national
format in the terminating records for the call if the MSC is setup to present directory numbers in
national format (using the office parameters REPLACE_MS_CC_DIGITS and
REPLACE_INTL_ROAM_ CLID in table GSMVAR). In this case, the calling number field of the
originating records remains in international format.
numbers.
number.
B6.11.3 The Network Optimisation of Trombone Connections
This service uses a release link trunk (RLT) mechanism to remove unnecessary connections from
the call path. On receiving call setup information from the PSTN or a mobile subscriber, the MSC
sets up the call to the called party using an ANSI ISUP initial address message (IAM). It includes a
call reference value in the network specific facility (NSF) parameter in this message and also stores
the value in a local database. The exchange serving the called party sets up a new call, for example
as a result of call forwarding. In the IAM which it uses to signal the new call information it includes
an NSF parameter with the same call reference value as in the original call setup information. In this
case, the new called party, for example a mobile subscriber or a voicemail system (VMS) is
connected to the MSC which set up the original call. When this MSC receives the IAM, it checks
the value of the call reference in the NSF parameter with those in its database. When it finds a
match, it initiates RLT to release the connections to the original called party. It bridges the call
connections to connect the calling party and the new called party.
This network service generates billing records which are similar to those of the VMCDB service
shown in Figure 29. This figure illustrates the RLT service if you substitute the exchange serving
the original called party for the VMS. The originating record for the first call is a MOC record for
MS A, but could be an IC gateway record or an IC intra-PLMN record depending on the call agent.
The outgoing record for the first call is either an OG gateway or an OG intra-PLMN record. For the
second call, the MSC creates an IC gateway or a IC intra-PLMN record. The terminating record is
an MTC record for MS B, but could be a transit record if the call is connected to a VMS. The
supplementary service information modules indicating the use of the service are appended to the
outgoing trunk record of the first call and the incoming trunk record of the second call.
B6.12 Handover
Figure 30 shows an inter-MSC handover followed by an intra-MSC handover. On receiving the call
setup signalling from the PSTN the gateway MSC creates an incoming gateway (IG) record. It then
interrogates the HLR for routing information to the called party. When the HLR returns the routing
information, the gateway MSC routes the call and creates an outgoing intra-PLMN (OGIP) trunk
record. The MSC creates an incoming intra-PLMN (ICIP) trunk record. It sets up the connection to
the called mobile station and creates a mobile terminated call (MTC) record. When the anchor MSC
hands the call over to the other MSC it creates an outgoing intra-PLMN trunk record to capture
information on the use of this trunking. The new serving MSC creates an incoming intra-PLMN
trunk record. During the intra-MSC handover, the new serving MSC captures the changed location
in a location and channel information module appended to the incoming intra-PLMN trunk record.
It also passes the information back to the anchor MSC which captures the information in a location
and channel information module appended to the MTC record. The MTC record contains three
location and channel information modules in this scenario: one for the original location of the called
party, one for the inter-MSC handover and one for the intra-MSC handover.
The example scenario shows the case where the MSCs have been datafilled to record all of the
locations resulting from handover, and to record details of the trunk connection between the anchor
MSC and the new MSC. The office parameter HO_PERFORMED_PROCESSING determines
whether or not the anchor MSC generates billing information for handover and also the amount of
information generated for intra-MSC and inter-MSC handover. The office parameter
GSM_SAVE_ALL_LOC_CH in table OFCVAR on the anchor MSC determines whether all
locations or just the first and last locations are recorded. The office parameter
GEN_HO_IMT_TRK_BILLING on the handed-to MSC determines whether or not it creates an
incoming trunk billing record when the subscriber moves to it, for the trunk connection between the
anchor MSC and the handed-to MSC.
Figure 30 Inter-MSC and Intra-MSC Handover
NOTE The MSC supports a software option which allows the provisioning of multiple
Mobile Country Codes (MCC) and Mobile Network Codes (MNC). The HLR
has a similar facility supporting multiple MNCs only. This allows a network
operator to lease spare capacity to/from other operators, or to consolidate the use
of equipment currently in separate networks. If this option is in use, the location
and channel information modules resulting from handover may contain different
MNCs.
Figure 31 shows a similar scenario but for a Release 4 Bearer Independent Core Network (BICN).
In this scenario there are two intra-MSC handovers following the initial inter-MSC handover: one
between Radio Network Controllers (RNCs) on the same media gateway and the second to an RNC
on a separate media gateway. The OGIP record on the anchor MSC captures the use of the inter-
machine trunk MGW ((MGW5 (IMT) in Figure 31)) in the BICN module appended to it. The ICIP
record on the handed-to MSC captures the use of MGW6 (IMT) in the BICN module appended to
it. The MTC record on the anchor MSC and the ICIP record on the handed-to MSC contain full
location and channel information in the appended L&C modules.
Gateway
MSC
ISDN/PSTN
MSC
A A - new MSCs area
ICIP
Record
IG
Record OGIP
Record
MSC
OGIP
Record
HPLMN
ICIP
Record
MTC
Record
L&C
TS
EoM
L&C
L&C
TU
EoM
L&C
EoM
Key
TU Trunk Usage Information Module
TU
HLR
Roaming
Record
TS
EoM
SRI
L&C
(anchor) (handed-to)
Figure 31 Inter-MSC and Intra-MSC Handover in an R4 BICN Network
In a UMTS network the Radio Network Controllers (RNCs) may be interconnected by the Iur
interface. In this case they can perform a type of handover in the radio network called Serving
Radio Network Subsystem (SRNS) relocation. In this case the call remains anchored at the serving
RNC but may be connected to one or more drift RNCs. However, there may still come a time when
the call path is better optimised through the core network. When this hard handover occurs, it can
result in inter-MSC and intra-MSC handovers in exactly the same way as before.
Gateway
HLR
HPLMN
ICIP
Record
Record
OGIP
Key
TU Trunk Usage Information Module
MGW1 MGW2
BICN
EoM
BICN
EoM
MSC
Roaming
Record
TS
EoM
SRI
ISDN/PSTN
IG
Record
BICN
EoM
RNC
RNC
RNC
RNC
MSC
MGW9 MGW7
Final bearer path
Intermediate bearer paths
Inter-MSC handover
MTC
Record
Intra-MSC handover
MGW8
ICIP
Record
OGIP
Record
Intra-MSC handover
L&C
EoM
TU
BICN
L&C
M GW 6
MGW5
L&C
EoM
L&C
TS
BICN
L&C
(handed-to)
L&C
L&C
(IMT)
(IM T)
MSC
MGW3 MGW4
TU
EoM
(anchor)
BICN
B6.13 Local Number Portability
The PCS-1900 local number portability service (LNP) allows users to retain their telephone
directory numbers (DNs) when changing between local service providers (this is the phase 1 service
focus which will be extended to allow users to change location). The service defines ranges of DNs
which are portable and subscribers with these DNs may keep them if they move to another service
provider. When a subscriber moves, the original network is called a donor, donating the DN to the
new network. The new network is called the recipient network.
Figure 32 shows a call to a subscriber who has moved from the PLMN to another service provider,
that is where the PLMN is the donor network. On receiving call setup information from the PSTN,
the gateway MSC creates an incoming gateway (IG) record. The MSC recognises the number as
one which is portable, but in the range allocated to its network, so it queries the HLR for routing
information to the called number. Because the user has transferred to another provider, the HLR
indicates that the subscriber is unknown. The MSC queries the LNP database which returns the
Location Routing Number (LRN) as routing information. The LNP information is captured in an
LNP module appended to the IC gateway record. The MSC routes the call to the new network and
creates an outgoing gateway (OG) record. This scenario occurs when the PSTN cannot make the
LNP database query and so routes the call to the PLMN based on the called number. The PLMN
then routes the call to the new network supporting the subscriber.
Figure 32 Local number portability with the MSC in the donor network
For a mobile originated call to a donated number, the scenario is similar to that shown in Figure 32.
In this case, a mobile originated call record captures details of the call setup (rather than an IC
gateway record) and the LNP module appended to it captures information from the LNP database
query.
Gateway
MSC
ISDN/PSTN
IG
Record
HPLMN
Local LNP
database
HLR
OG
Gateway
Record
Key
LNP Local Number Portability Information Module
LNP
EoM
ISDN/PSTN
Figure 33 shows a call to a subscriber who has moved to the PLMN, that is where the PLMN is the
recipient network. A call originates at the gateway MSC with a number that it recognises as being
portable and belonging to another network, so it queries the LNP database. The LNP database
returns an LRN to the MSC. The MSC captures the information in an LNP module appended to the
IC gateway record. The call is now completed like a mobile terminating call. The MSC queries the
HLR by sending an SRI message containing the LRN and the called number (the portable number).
The MSC routes the call based on the information returned by the HLR. In the example, the called
party is served by the gateway MSC which pages the called mobile and captures the terminating
information in a mobile terminating call (MTC) record.
Figure 33 Local number portability with the MSC in the recipient network
If the call originates at a mobile station rather than a trunk, a mobile originated call (MOC) record
captures the call setup information and the LNP module appended to it captures the information
from the LNP database. If the call is routed over trunks rather than directly to the called party, the
gateway MSC creates an outgoing trunk record e.g. an outgoing intra-PLMN (OGIP) trunk record.
The call scenario to a subscriber who has moved to the PLMN is greatly simplified if the LNP
database query is performed outside of the PLMN and ANSI ISUP signalling is used. In this case
the connecting network signals the LNP information in an ANSI ISUP Initial Address Message (the
LRN is in the called party number, the directory number is in the generic address parameter and the
forward call indicator shows that the database query has been performed). The MSC queries the
HLR for the location of the called party and captures the signalled LNP information in an LNP
module appended to the IC gateway record.
Gateway
MSC
ISDN/PSTN
IG
Record
HPLMN
Local LNP
database
HLR
MTC
Record
Key
LNP Local Number Portability Information Module
LNP
EoM
L&C
EoM
TS
B6.14 Extension Services
The extension service provides a subscriber with a single directory number (DN) called a pilot DN
which has a number of terminals associated with it, e.g. fixed line and wireless telephones. When
someone calls the pilot DN, the MSC calls the associated terminals in turn until one is answered, or
there are no more terminals to call. The MSC applies the ringing tone to the calling party and
originates calls to each of the terminals. If one of the terminals is answered, the MSC connects the
original calling party to it.
In Figure 34, the subscriber has three groups of terminals associated with the pilot DN: a mobile
station, a second group consisting of two telephones in the PSTN and finally a voice mail system.
On receiving call setup information from the PSTN, the gateway MSC creates an incoming gateway
(IG) record. The MSC interrogates the HLR and obtains a list of numbers associated with the pilot
DN. For this call leg, the MSC creates a mobile terminating call (MTC) record with a
supplementary service (SS) information module appended. The first number associated with the
pilot DN is for a mobile station. The MSC queries the HLR for its location and uses the returned
information to route the call to the MS. For this leg, the MSC creates a mobile originated call
(MOC) record with an SS information module appended, and an MTC record. When the call to the
mobile station times-out, the MSC creates two calls to both PSTN terminals because they are
grouped together for simultaneous alerting. The MSC creates two MOC records with appended SS
information modules and two outgoing gateway (OG) records. When these calls time out, the MSC
calls the voice mail system (VMS). When the VMS answers the call, the MSC connects the calling
party to it. For this call leg, the MSC creates another MOC with an appended SS information
module and a transit record.
For the call legs that it originates, the MSC creates a MOC record with an appended SS information
module that contains information about the extension service. It also creates an appropriate
terminating record which is either one of the outgoing trunk records, or an MTC record.
Figure 34 Extension services alerting to three groups of called numbers
B6.15 Intelligent Network (IN) Scenarios
Using intelligent network (IN) nodes and signalling, a network operator can develop a range of
services for their customers. The IN provides a framework for producing services rather than
defining a set of services itself. The billing information produced during the invocation of an IN
service depends entirely on how that service has been set up to operate. For this reason, it is only
possible to describe where IN billing information is produced in typical or example call scenarios.
Real IN services vary in complexity from those with limited interactions between the network
nodes, to those with multiple interactions between the nodes. The IN services may generate a lot
more billing information than is shown here depending on their complexity.
This section provides an overview of the networks in which the MSC/SSP may be used. It then
provides information about billing for a Mobile Originated (MO) service, a Mobile Terminated
(MT) service and for a Mobile Forwarded (MF) call. The final section describes an alternative
proprietary IN mechanism called Off-board IN which can be implemented on the MSC.
Gateway
MSC
ISDN/PSTN
MTC
Record
Transit
Record
HPLMN
VMS
MTC
Record
IG
Record
OG
Record
MOC
Record
MOC
Record
MOC
Record
MOC
Record
OG
Record
HLR call1
call 2
call3
Key
EoM
SS
EoM
SS
EoM
SS
EoM
SS
EoM
SS
B6.15.1 IN Nodes and Signalling
The IN introduces new nodes and signalling interfaces into the network. Figure 35 shows the nodes
and signalling interfaces in two types of IN network: the CAMEL network (Customised
Applications of Mobile-network Enhanced Logic) which provides IN services for GSM and UMTS
networks and the INAP based (Intelligent Network Application Part) IN network which provides
proprietary IN services for GSM and UMTS networks.
Figure 35 IN nodes and signalling interfaces
The CAMEL network provides IN services attuned to GSM/UMTS mobile requirements, such as
the ability to provide services to roaming subscribers. The service logic resides on the gsmSCF
(GSM Service Control Function). The MSC/SSP runs the gsmSSF (GSM Service Switching
Function). During a call, the gsmSSF and gsmSCF use the CAMEL Application Part (CAP)
signalling protocol to provide IN services to subscribers. The HLR stores CAMEL Subscription
Information (CSI) for individual subscribers and also for network services supplied to all users of
the network. The HLR uses the MAP interface to transfer the CSI to the MSC/SSP and to exchange
information with the gsmSCF. There are several types of CSI for different types of service, e.g. O-
CSI and T-CSI for originating and terminating services respectively, other call-related CSI and
SMS-CSI for short messages. An intelligent peripheral (IP) running the specialised resource
function (SRF) provides resources such as tones and announcements and digit collection as needed
for a service. The standards define several ways in which the IP may be connected to the network.
In one configuration an MSC/SSP (called the assisting SSP) may allow other MSC/SSPs (called the
initiating SSPs) to use its IP for services. The gsmSCF may also have a direct connection to the IP.
For basic call and call forwarding, the MSC/SSP splits a call into two interacting state machines:
the Originating Basic Call State Machine (O-BCSM) and the Terminating BCSM (T-BCSM). The
state machines contain a number of detection points (DPs) which relate to different points in call
(PICs) for mobile originated call setup and mobile terminated call setup. When the MSC/SSP
encounters a DP in a call that requires IN servicing, it suspends normal call processing and notifies
the gsmSCF that the point has been encountered. It then either waits for the gsmSCF to send
information to it, for example a new call destination, or continues normal call processing. CAMEL
services for mobile originated (MO) SMS use a similar model: the MO SMS state machine defines
a number of DPs and points in association (PIA) at which normal message processing can be
interrupted to provide IN services.
MSC/SSP
SCP
HLR
IP
MSC/SSP
gsmSCF
HLR
MAP
INAP PRI
INAP
MAP
CAP
INAP based IN network CAMEL network
MAP
IP
gsmSSF
gsmSRF
The 3GPP standards body (and ETSI previously) has developed the CAMEL standards in a number
of phases. The Phase 3 standard is complete and stable and 3GPP are currently working on Phase 4.
The Phase 1 and Phase 2 networks provide more limited capabilities than the Phase 3 network. The
Phase 1 network does not support connections to IPs, provides only subscriber triggered
originating, terminating and forwarding services and does not support charging information.
Compared to Phase 1, the Phase 2 network supports extended CSI, new DPs, connections to IPs and
charging information. For information on CAMEL Phase 1 and 2 capabilities, refer to the GSM
standards 03.78 and 09.78. For information on CAMEL Phase 3 (CSI, state machines, DPs,
CAMEL messages etc.) refer to the 3GPP standards 23.078 and 29.078.
The INAP-based network (Intelligent Network Application Part) provides IN functionality based on
the CS1-R standards (Q.121x). The service logic resides on the SCP (Service Control Point) which
is equivalent to the gsmSCF. The network can also support IPs (intelligent peripherals) for
additional capabilities such as voice prompts and data collection. The SCP controls the IP using
INAP signalling and the MSC/SSP uses PRI signalling (Primary Rate Interface) to establish
connections to the IP. The call modelling used to provide services is also similar to CAMEL, as it
uses DPs as the mechanism for interrupting normal call processing.
Some operators providing IN services in early GSM networks used the INAP standards. When the
earliest services were required, CAMEL may not have been defined and so operators had no choice
but to use INAP. Also CAMEL Phase 1 offered a very limited set of capabilities and so operators
may have chosen INAP to make use of its extended capabilities. These INAP-based networks
provide proprietary IN services as they are not based on the CAMEL standards.
B6.15.2 Mobile Originated IN Billing
Mobile originated services are provided on the O-BCSM, typically for the calling party. A service is
applied when an originating DP is encountered in the O-BCSM. In this case, call processing is
interrupted and service information obtained from the gsmSCF or SCP. The call is completed with
the new service information. For example for a VPN (virtual private network) service, the dialled
digits are converted to an MSISDN number. The billing information is captured in a number of IN
modules. These modules are appended to mobile originated call (MOC) record shown in Figure 36
where they are denoted by the term (IN Service).
Figure 36 Billing for a mobile originated IN service
MSC/SSP
MOC
Record
gsmSCF
OG
Intra-
PLMN
Record
Call routed through the
PLMN to the called party
(IN
service)
B6.15.2.1 CAMEL MO Billing
In a CAMEL network, the IN service details are captured in an appended IN Information module
(Section B4.2.14 on page 98). This contains information such as a service key to identify the IN
service, the address of the gsmSCF and the DP at which the service was triggered etc. It may also
contain information about a connection to an IP. There may be several of these modules appended
e.g. if there are several interactions with an IP. The MOC record also has an appended Call
Reference Information module (Section B4.2.17 on page 103). This contains the network call
reference number generated by the MSC/SSP to identify the call. In addition, the billing record(s)
may have an appended CAMEL Charging Information Module(s) containing information about the
charges to be levied for the service. For each DP, two charging modules may be appended, one for
the calling party and one for the called party. If the gsmSCF sends new charging information to the
MSC/SSP for either party, it may overwrite previous charging information, or be appended to it.
In a CAMEL Phase 2 network, the same modules can be used to capture service details. However if
the gsmSCF sends the MSC/SSP new charging information, it overwrites the previous information
in the CAMEL Charging Information Module. Also, if an assisting SSP provided the IP connections
for a service, the incoming trunk record generated on it may have an appended GSM Assisting SSP
information module(s) to capture details of the connection(s). The CAMEL Phase 1 network does
not support charging information or interactions with IPs.
B6.15.2.2 CS1-R MO Billing
In an INAP-based network, in addition to the IN Information module (Section B4.2.14 on page 98),
the MOC record may have an appended IN Charging Information module (Section B4.2.15 on
page 101). This module contains charging information sent to the MSC/SSP by the SCP. Additional
IN Information modules may be attached to account for interaction with the IP, in which case the
duration of the interaction is recorded in the module.
B6.15.3 Mobile Terminated IN Billing
Mobile terminated services on the T-BCSM, are typically provided for the called party and are
applied in the gateway MSC (GMSC). A service is applied when a terminating DP is encountered in
the T-BCSM. In this case, call processing is interrupted and service information obtained from the
gsmSCF or SCP. The call is then completed with the new service information. For example, for a
time-of-day routing service, the call may be completed to different destination addresses depending
on the time at which the call is made. The billing information is captured in a number of modules
appended to a number of call records. (IN Service) in Figure 37 indicates that IN modules are
appended to the call record.
Figure 37 Billing for a mobile terminated service
B6.15.3.1 CAMEL MT Billing
Information about the IN service is captured in billing records on the gateway MSC/SSP (GMSC)
and the visited MSC (VMSC) of the called party. The GMSC captures details of the terminating IN
service in a GSM IN Information module (Section B4.2.14 on page 98) appended to a Mobile
Terminated Call (MTC) record. There may be several IN information modules appended to the
record if there were interactions with an IP. The GMSC generates a network call reference number.
This number is captured in an GSM Call Reference Information module (Section B4.2.17 on
page 103), which is also appended to the MTC record. The network call reference number is
signalled to other network nodes including the VMSC during call setup.
As a result of applying terminating IN services, a GSM IN Information module is appended to the
corresponding MOC record. This module allows the terminator to be marked as the originator of the
second leg of the call if IN Call Diversion (IN Call Forwarding) has taken place.
The VMSC captures the number in a GSM Call Reference Information module appended to the
MTC record that it creates for the call. The network operator can use the call reference number
captured in separate billing records to correlate the records at the downstream processor. In
addition, the billing record(s) may have appended GSM CAMEL Charging Information Modules
containing information about the charges to be levied for the service.
The CAMEL Phase 2 network can capture CAMEL service information in the same modules.
Additionally, if the IP connections are provided by an assisting SSP, the incoming trunk record on it
may contain an appended GSM Assisting SSP information module(s) with details of the IP
connection(s). The CAMEL Phase 1 network does not support connections to IPs or charging
information and so this information is not captured for Phase 1 services.
HLR
Gateway
MSC/SSP
IC
Gateway
Record
gsmSCF
Incoming call
setup information
MTC
Record
(IN
service)
Visited
MSC/SSP
MTC
Record
(IN
service)
IC
Intra-
PLMN
Record
Roaming
Record

MOC
Record

(IN
Service)
B6.15.3.2 CS1-R MT Billing
In an INAP-based network, the information about the IN service is captured in billing records on
the gateway MSC/SSP (GMSC) of the called party. The GMSC captures details of the terminating
IN service in a GSM IN Information module (Section B4.2.14 on page 98) appended to a Mobile
Terminated Call (MTC) record. Additional GSM IN Information modules may be attached to the
MTC to account for interaction with the IP. In this case the duration of the IP interaction is recorded
in the module.
As a result of applying terminating IN services, a GSM IN Information module is appended to the
corresponding MOC record. This module allows the terminator to be marked as the originator of the
second leg of the call if IN Call Diversion (IN Call Forwarding) has taken place.
The GMSC may also capture charging information from the SCP in a GSM IN Charging
Information module (Section B4.2.15 on page 101) appended to the MTC record.
B6.15.4 Mobile Forwarding IN Billing
This section deals with the application of IN services to the forwarded leg, i.e. an originating IN
service is applied to the originating leg which is created as a result of the forwarding. Note that the
cause of the forwarding may be either IN or Supplementary Services (SS). There are two major
types of call forwarding: early and late call forwarding. In the early forwarding SS, the call is
forwarded at the GMSC without the call being connected to the original called party. In late call
forwarding, the call is connected the VMSC of the called party before being forwarded. Application
of the early or late forwarding SS causes IN services on the forwarded leg to be run at the GMSC or
VMSC respectively, that is the IN services are applied on the forwarding nodes.
Figure 38 shows an example IN call forwarding scenario which uses the term (IN Service) to
indicate that IN modules are appended to the billing record. In the example, the forwarding service
is applied as a mobile terminated service for the original called party. Forwarding information from
the gsmSCF causes a second call leg to be created towards the forwarded-to party. The GMSC then
connects the original call leg and the new call leg to leave the calling party and the forwarded-to
party connected.
Figure 38 Billing for IN call forwarding
B6.15.4.1 CAMEL MF Billing
Details of the original call are captured in a Mobile Terminated Call (MTC) record. The MTC
record has an appended GSM IN Information module (Section B4.2.14 on page 98) and a GSM Call
Reference module (Section B4.2.17 on page 103). Details of the forwarded leg are captured in a
Mobile Originated Call (MOC) record. It also has GSM IN Information and GSM Call Reference
Information modules appended. If the forwarded call leg involves interactions with an IP, there may
be several IN information modules appended containing details of the IP connections. The call
reference information module contains information such as the new network call reference number
generated by the GMSC for the forwarded leg. If the forwarded-to party is a mobile subscriber, its
VMSC generates an MTC record for it. This record also has an appended GSM Call Reference
Information module containing the call reference number for the forwarded leg. Any charging
information for the service is contained in GSM Charging Information modules appended to the
appropriate call records for the original call or for the forwarded call leg.
For IN services caused by late call forwarding (e.g. Call Forward Busy), the GSM IN Information
module and GSM Call Reference modules are appended to the MOC record on the VMSC.
The CAMEL Phase 2 network can capture service information in the same modules. Additionally, if
the IP connections are provided by an assisting SSP, the incoming trunk record on it may contain an
appended GSM Assisting SSP information module(s) with details of the IP connection(s). The
CAMEL Phase 1 network does not support connections to IPs or charging information and so none
of this information is captured for Phase 1 services.
HLR
Gateway
MSC/SSP
IC
Gateway
Record
OG
Intra-
PLMN
Record
Incoming call
setup information
MOC
Record
MTC
Record
Call routed to the forwarded-to party
(IN
service)
(IN
service)
gsmSCF
B6.15.4.2 CS1-R MF Billing
The INAP-based MF services are restricted by the fact that only DP3 may be triggered on the
forwarded leg. Billing information for the call forwarding scenario consists of a GSM IN
Information module (Section B4.2.14 on page 98) attached to the MOC record. However, it may
also include appended GSM IN Charging Information modules (Section B4.2.15 on page 101)
containing charging information sent by the gsmSCF.
Additional GSM IN Information modules may be attached to the MOC to account for interaction
with the IP. In this case the duration of such IP interaction is recorded in the module.
B6.15.5 Proprietary Off-Board IN Services
The MSC supports a proprietary mechanism called Off-board IN. Off-board IN functionality allows
the MSC to route a call that is recognised as needing IN servicing to an off-board IN platform like a
Service Node. Off-board IN is achieved by provisioning proprietary IN indices (originating or
terminating) in the HLR with a non-zero value. This is shown in Figure 39.
Figure 39 Off-board IN
The billing records generated for off-board IN services have GSM IN Information modules
appended to them. These modules contain information about the off-board IN indices used to
trigger the service and the details of the off-board IN service invoked during the call. Off-board
IN services do not result in the generation of the GSM IN Charging Information nor the GSM Call
Reference Information modules.
Since Off-Board IN functionality can be provided for both mobile originated or mobile terminated
calls, the GSM IN Information module may be attached to either the MOC or MTC records.
MSC
Off-board IN network
Nailed up connection
IN
HLR
MAP
ISUP
MSC
B6.16 CAMEL Mobility Management Service
This service provides a mechanism for the MSC/SSP to notify the Service Control Point (SCP) that
a mobility management has occurred, for example a location update or an IMSI attach/detach. After
the mobility management event has occurred, the MSC/SSP reports the outcome to the SCP if the
subscriber is provisioned with Mobility Management CAMEL subscription information (M-CSI).
Figure 40 shows an example scenario.
Figure 40 CAMEL mobility management service
The mobile station (MS) starts the location update procedure. After the MS is authenticated, the
HLR downloads the subscribers data to the MSC/SSP, including the M-CSI data. The MSC/SSP
and MS then set up the ciphering to be used over the radio interface. The MSC/SSP accepts the
location update request from the MS and the MS accepts its new temporary identifier (the
temporary mobile subscriber identity). The M-CSI triggers and the MSC/SSP reports the location
update information to the SCP in a MAP Note MM Event message. The SCP responds with a MAP
Note MM Event Result message. The MSC/SSP generates the Location Update record with details
of the location information and appends an IN information module with details of the IN service.
The MSC/SSP clears all of the connections with the MS which were used for the location update
procedure.
B6.17 Call Independent Supplementary Service Action
Figure 41 shows the billing information generated as a result of a mobile subscriber performing a
call independent supplementary service (CISS) operation. A subscriber performs a CISS operation
to change SS provisioning, for example to change the forwarded-to number for the call forwarding.
supplementary service (SS). The updating of SS information uses MAP (mobile application part)
operations. The MAP operations are carried in radio layer 3 messages over the access interface.
HLR
Visited MSC/SSP
(VMSC)
LU
Record
IN
EoM
SCP
Key
LU Location Update Record
IN Intelligent Network Information
Figure 41 CISS Action
The mobile station signals the CISS information in a radio layer 3 REGISTER message. The
Facility information element in the message contains the MAP operation RegisterSS and the
relevant SS parameters. For call forwarding, this information includes the type of call forwarding,
the basic services to which the forwarding service applies and the forwarded-to number. The MSC
copies the MAP operation into a TCAP TC-Begin primitive which it sends to the HLR. The HLR
returns the result of the CISS operation in a TCAP TC-End primitive. The MSC copies the MAP
operation into Facility information element carried in a radio layer 3 Release Complete message.
The successful result of the CISS operation is that the subscribers SS details are updated.
The MSC captures the details of the CISS operation in an SS action record. If the record does not
have any appended modules, the CISS operation applies to all of the subscribers basic services.
The record may have a bearer service information module or a teleservices information module
appended. In this case, the CISS operation captured in the SS action record applies to the bearer or
teleservice recorded in the module.
B6.18 Invoking the Billing Zone Query Service Using USSD
Figure 42 shows the billing information generated as a result of a mobile subscriber invoking the
Billing Zone Query service using USSD (Unstructured Supplementary Service Data). The service
subscriber enters a USSD string on the mobile station and then presses SEND to invoke the
service. Using information about the subscribers location, the MSC retrieves associated billing
zone information and sends it to the mobile station. The mobile station displays the information to
the subscriber as a text message. The billing zone information is defined by the operator and may
contain geographical information e.g. City Centre or information about a rate e.g. Premium Rate
or 10% Discount Zone.
Figure 42 Invoking the billing zone query service using USSD
MSC
SS
A
Action
Record
HLR
MSC
SS
A
Action
Record
HLR
To invoke the service, the mobile sends the USSD request in a REGISTER message. The Facility
information element in this message contains the USSD information. The MSC uses the mobile
stations location as determined by the Cell Identity and Location Area Code to retrieve the
associated billing zone information. It sends the information to the mobile station in a RELEASE
COMPLETE message. The billing zone information is in the Facility information element of this
message.
To capture details of the service, the MSC generates a Supplementary Service Action record. The
SS parameters field of this record contains the USSD string used to invoke the service, the SS code
field indicates USSD (081C) and the SS action field shows that the service was invoked (5C).
B6.19 Optimal Routing of a Late Forwarded Call
The optimal routing of a late forwarded call optimises the call path by removing unnecessary
connections from it. In a call in which late call forwarding is applied, the call is connected to the
VMSC serving the called party before the forwarding condition, e.g. busy, applies. Without optimal
routing, the connection to the VMSC of the called party remains in the call path. With optimal
routing, the connection to the VMSC is removed from the call path thus optimising the connection.
Figure 43 shows an example of late call forwarding to a busy mobile subscriber who subscribes to
the service call forwarding on busy. Other types of late call forwarding include forwarding on no
reply and forwarding on not reachable (Visitor Location Register (VLR) determined).
In the call scenario, the GMSC receives call setup information in step 1 which it captures in an
incoming (IC) gateway record. In step 2, the GMSC sends a SendRoutingInformation (SRI)
message to the HLR. This message is used to request routing information from the HLR and to
signal the GMSCs address and a call reference number to the HLR. The HLR sends a
ProvideRoamingNumber (PRN) message to the VMSC to request a roaming number (MSRN). The
PRN also contains the GMSCs address and the call reference number. The VMSC stores the
signalled information and returns an MSRN to the HLR in the PRN Ack. message. The HLR returns
the MSRN to the GMSC in an SRI Ack. message. Using the MSRN, the GMSC routes the call to
the called party. It creates a roaming record and an outgoing (OG) gateway record to capture call
details.
In step 3, the VMSC receives the call setup information which it captures in an incoming (IC) intra-
PLMN record. Because the called party is busy and subscribes to the forwarding on busy service,
the VMSC sets up the forwarded call leg. Because the VMSC supports optimal routing, it sends the
GMSC a MAP ResumeCallHandling (RCH) message at step 4 to attempt to return call handling to
the GMSC. The RCH message contains the call reference number and call forwarding information.
The GMSC sends an RCH Ack. to signal that it will take over call handling. It then sends an ISUP
Release message to release the original connection.
The VMSC captures the call details in a mobile terminated call (MTC) forwarding attempt record.
This has an appended call reference information module containing the GMSCs address and the
call reference number. It also has an appended supplementary service (SS) information module
which captures the forwarding on busy condition. This is shown as SS (CFB) in Figure 43. To
capture information for the call falling back to it, the GMSC also creates an MTC forwarding
attempt record. This record has an appended call reference information module containing the
GMSCs address and the call reference number. It also has an appended SS information module (SS
(OR)) which records the fact that the record was generated as a result of optimal routing.
The GMSC uses the forwarded-to number in the RCH message to route the forwarded call leg in
step 5. The GMSC captures details for the forwarded leg in a mobile originated call (MOC)
forwarding attempt record. This record has an appended call reference information module. It also
has an appended SS information module (SS (OR)) which shows that the forwarded leg was
originated from the GMSC as a result of optimal routing. Because, in this example scenario, the
GMSC routes the call to the PSTN/ISDN, it creates an OG gateway record. The terminating record
captured at this point is appropriate to the scenario. For example, if the forwarded-to party is a
mobile station resident at the GMSC, the final call record is an MTC record.
The information captured in the call reference information modules appended to the billing records
allows the operator to correlate the records at the downstream processor. The information in the SS
information modules shows which records were generated as a result of optimal routing.
Figure 43 Late call forwarding with forwarded leg originating in the home network
B6.20 Mobile Number Portability (MNP)
The MNP service allows subscribers to move to other operators or service providers without
changing their directory numbers (MSISDNs). The number portability database (NPDB) stores
information about the ranges of portable numbers. The MSC also contains information about
portable number ranges so that it can decide whether or not to query the NPDB. The network
architecture used for MNP is based on that used in intelligent networks (INs). The NPDB runs the
MNP service logic just like the IN SCP (Service Control Point) runs IN service logic. The MSC and
NPDB exchange information using the INAP protocol (intelligent network application part). Figure
44 shows an example MNP call scenario in which the MSC routes a call to a ported number.
VPLMN
HLR
MTC
Record
ISDN/PSTN
HPLMN
Gateway
MSC
(GMSC)
Visited
MSC
(VMSC)
IG
Record
OG
Record
Roaming
Record
OG
Record
MOC
Record
Busy
ICIP
Record
TS
EoM
Key
OG Outgoing Gateway
GCR GSM Call Reference Information Module
SS Supplementary Services Information Module
GCR
L&C
TS
SS (CFB)
EoM
MTC
Record
GCR
TS
SS (OR)
EoM
GCR
TS
SS (OR)
EoM
2
1
3
4
5
Mobile subscriber A makes a call to subscriber B. The MSC captures the call setup information a
mobile originated call (MOC) record. The MSC recognises the dialled number as being in the range
of portable numbers. It sends an INAP InitialDP message to the NPDB containing the MSISDN of
the called party. The NPDB recognises that the number has been ported. It sends the MSC an INAP
Connect message which contains a routing number. The MSC captures the ported number
information in the MNP information module appended to the MOC record.
Figure 44 Mobile number portability
The MSC uses the routing number to determine a route to party B. It sends an ISUP IAM (initial
address message) towards the HPLMN of party B. The IAM contains the routing number and the
MSISDN. The MSC captures the call information in an outgoing gateway record. In the HPLMN of
party B, the gateway MSC receives the IAM. It captures the call information in an incoming
gateway record. Because the IAM contains a routing number, the MSC knows that the subscriber
belongs to its network. It sets up the call in normal way, querying the HLR for routing information
and then routing the call to VMSC B. It captures the call information in a roaming record and
outgoing intra-PLMN trunk record. VMSC B sets up the call to party B. It captures the call
information in an incoming intra-PLMN record and a mobile terminated call attempt record.
This scenario shows an example of a subscriber having moved to another network. If the subscriber
had not moved, the NPDB would have returned an INAP continue message to the MSC to instruct it
to continue normal call processing. The MSC would have used the normal call processing to
connect the call to one of its subscribers.
HPLMN B
Gateway
MSC
(GMSC)
Key
OG Outgoing Gateway
MNP Mobile Number Portability
PLMN A
A
MSC
(VMSC)
NPDB
MOC
Record
L&C
TS
EoM
HLR
MNP
B
OG
Record
Visited
MSC
(VMSC)
MTC
Record
L&C
TS
EoM
OGIP
Record
IG
Record
Record
Roaming
ICIP
Record
MNP can also be applied during mobile terminated call setup. In this case, if the Gateway MSC
recognises the number as being in the portable range, it queries the NPDB for information. It then
sets up the call to one of its own subscribers if the number is not ported, or to the new operators
network if the number is ported. The GMSC creates an incoming trunk record and appends the
MNP information module to it to capture the call setup information.
In some cases a subscriber may have moved to another provider, but the GMSC may not recognise
the number as being in the portable range. In this case, the GMSC acts as if the called party is one of
its subscribers and interrogates the HLR as part of normal call setup. As there is no longer any
subscriber data in the HLR for the called party, the HLR returns an error in its response to the MSC.
If suitably provisioned, the GMSC can use the error message as a trigger to query the NPDB for the
porting information.
The MNP standards also define another method for obtaining a routing number. It uses a network
node called the MNP Signal Relay Function (SRF). As shown in Figure 45 this node sits between
the MSC, the NPDB and the HLR. During mobile call setup, the MSC sends the MAP
SendRoutingInformation (SRI) message to the MNP SRF at step 1 if it recognises that the called
number is in the portable number range. The MNP-SRF queries the NPDB for the ported status of
the called party. In the first case shown in steps 3a to 5a, the response from the NPDB tells the
MNP-SRF that the number is not ported. The MNP-SRF sends the call setup information to the
HLR which in turn sends routing information to the GMSC in the SRI Ack message. The GMSC
uses the routing information to complete call setup. In the second case shown by steps 3b to 5b, the
NPDB tells the MNP-SRF that the called number is ported. The MNP-SRF relays the SRI message
to the MNP-SRF in PLMN B which is the called partys new network. The MNP-SRF in PLMN B
sends the SRI Ack message to the GMSC in PLMN A. The GMSC uses the routing information to
complete call setup.
The MNP information is captured in an MNP module appended to the incoming trunk record of
GMSC A.
Figure 45 MNP using the MNP Signal Relay Function (SRF)
MSC
(GMSC)
NPDB HLR
MNP-SRF
MSC
(VMSC)
NPDB
HLR
MNP-SRF
PLMN A
PLMN B
1
2
3a
3b
4a
4b
5a
5b
B6.21 Location Services (LCS)
B6.21.1 3GPP Release 99 Messaging
Location Services (LCS) allow information about a subscribers location to be used in various
services. These range from providing the location to emergency services, value added services such
as weather reports or local traffic conditions, and operation and maintenance (O&M) services.
There are a number of new network nodes which calculate the location, co-ordinate requests for
location information and provide location information to LCS clients and mobile subscribers.
Figure 46 shows an example LCS scenario in which an LCS client requests location information.
Figure 46 Mobile Terminated Location Request (MT-LR) LCS
In the MT-LR scenario the LCS client issues a request for location information to the Gateway
Mobile Location Centre (GMLC). The GMLC authenticates the client and then, if it does not
already know the Visited MSC (VMSC) address, it requests routing information for LCS from the
HLR in a MAP Send Routing Information for LCS message. When it receives the routing
information, the GMLC requests location information from the VMSC in a MAP Provide
Subscriber Location message. The VMSC may then notify the mobile station/user equipment of the
location request in an LCS notification message. The VMSC then requests location information
from the Serving Mobile Location Centre (SMLC) in a RANAP Location Reporting Control
message. The SMLC is located in the Serving Radio Network Controller (SRNC). The SRNC/
SMLC uses this message to control and co-ordinate the measurement of the userss location. Once
the measurement has been made, the SMLC returns the location information to the VMSC in a
RANAP Location Report message. The VMSC captures the information in a Location Services
Record. The record has a Location Only information module appended to it which contains further
location information. The VMSC then sends the location information to the GMLC in a MAP
Provide Subscriber Location Response message. Finally, the GMLC sends the information to the
LCS client.
Key
LCS Location Services Record
VMSC
LCS
Record
LO
EoM
SRNC
SMLC
GMLC
LMU
LCS
Client
HLR
LCS services may also be originated by the mobile station using a Mobile Originated Location
Request (MO-LR). Once again, when the SMLC returns the location information to the VMSC in
the RANAP location response message, the VMSC captures the information in an LCS record. As
before, the VMSC sends the location information to an LCS client via a GMLC. The service may
also be provided to GSM subscribers. In this case the LCS record is generated when the MSC
receives location information in a BSSMAP-LE Perform Location Response message from the
SMLC.
The LCS record has a location only information module appended to it for successful LCS billing
record termination and for every handover in order to record the location information. However,
where paging is not done because of subscription, the module is not appended because of privacy
authorization failure.
B6.21.2 3GPP Release 4 Messaging
The 3GPP Release 4 standards define additional messaging for the location services. The MSC and
the RNC exchange new Location Related Data (LRD) messages to provide deciphering keys or
assistance data to the user equipment (UE) for the location service. Figure 47 shows an example of
a mobile originated location request.
Figure 47 Mobile Originated Location Request (MO-LR) LCS
In this scenario, the UE requests location data by sending the MSC an MO-LR Invoke message
inside a radio layer 3 Register message. The message indicates that the UE wants deciphering keys.
The MSC sends the SRNC an LRD Request message. The MSC captures the LCS Initiation Time at
this point. The SRNC sends the deciphering keys to the MSC in a LRD Response message. The
MSC captures the LCS Result. It then sends the deciphering keys to the to the UE in an MO-LR
Response message inside a radio layer 3 Facility message. The MSC captures the location
information in the Location Services record.
If the UE requests assistance data, there are a couple of extra steps. When the SRNC receives the
LRD Request from the MSC, it sends the assistance data to the UE. After the UE acknowledges
receipt of the information, the SRNC sends the LRD Response to the MSC. The response contains
no data to signal that the service was successful. The MSC sends the MO-LR response to the UE
and captures the LCS Record.
Key
LCS Location Services Record
VMSC
LCS
Record
LO
EoM
SRNC
The service can fail if the SRNC is not able to provide the deciphering keys or assistance data. In
this case, the SRNC sends a LRD Failure message to the MSC. The MSC captures the LCS result
and then sends an MO-LR Error message back to the UE.
B6.22 Enhanced Multi-level Precedence And Pre-emption Service
(eMLPP) Call
This section contains two eMLPP call scenarios:
B6.22.1, Called Party Pre-emption
B6.22.2, Resource Pre-emption on page 309
B6.22.1 Called Party Pre-emption
Figure 48 shows an example eMLPP call. In this scenario, party A calls party B and establishes an
active call. Party C then calls party A with a higher precedence call. This call pre-empts the existing
call and so party A puts party B on hold and takes the new call from party C.
Party A subscribes to the eMLPP service and signals a precedence (priority level) for the call during
call setup. The priority level is captured in a Supplementary Service information module appended
to the Mobile originated call (MOC) record. The MSC queries the HLR for routing information for
party B and routes the call using the information it receives. It generates a roaming record and an
outgoing intra-PLMN record. On the MSC serving party B, the call information is captured in an
incoming intra-PLMN record and a mobile terminated call (MTC) record.
Party C calls party A using a higher priority level than the one currently being used by party A. The
MSC serving party C captures the signalled call priority in an SS information module appended to
the MOC for party C. The MSC queries the HLR for routing information for party A and sets up the
call with the routing information it receives. It captures the call information in a roaming record and
an outgoing intra-PLMN record. On the MSC serving party A, the call information is captured in an
incoming intra-PLMN record and an MTC record. The MSC presents the call to party A as a call
waiting service and this is captured in an appended SS information module. On receiving the call
notification, party A puts party B on hold and takes the call from party C. Use of the call hold
service is captured in an SS information module appended to the MOC record for party A.
Figure 48 eMLPP Call
If the eMLPP subscriber does not subscribe to the call hold service, the original call is released if
the subscriber accepts the new call. Using the previous example, if party A does not subscribe to
call hold, the call to party B is released when party A accepts the call from party C. If the calling
party does not subscribe to the eMLPP service, the network may assign a default precedence. In this
case, the precedence information is captured in the SS information module along with an indication
that the network set the initial call priority (in Section B4.2.4 see the first example in Table 37 on
page 89).
B6.22.2 Resource Pre-emption
Figure 49 shows an example eMLPP call with resource pre-emption. In this scenario, there is an
active call at the MSC which is of a low priority (precedence). The mobile station attempts to make
a call but there are no free outgoing circuits for it. Because the call is of a higher priority than the
active call, the MSC pre-empts the active call. It releases the original call circuits and seizes them
for the new call. Having done this, it sets up the new call to the dialled destination.
MSC
HLR
MSC
MTC
Record
A
B
MOC
Record
Roaming
Record
OGIP
Record
ICIP
Record
C
MSC
MOC
Record
Roaming
Record
(A to B)
(A to B)
(A to B)
(A to B) (A to B)
(C to A)
(A to C)
OGIP
Record
(C to A)
ICIP
Record
(C to A)
MTC
Record
(C to A)
Key
SS (Hold)
EoM
SS (eMLPP)
EoM
SS (Wait)
L&C
TS
L&C
TS
EoM
L&C
TS
EoM
TS
EoM
TS
EoM
SS (eMLPP)
L&C
TS
Figure 49 Resource Pre-emption
During the setup phase of the original call, the MSC used the precedence (priority) information in
the initial address message (IAM) to set the priority level of the call. It then set up the call using the
normal call setup procedures. The MSC captured information about the call in an incoming intra-
PLMN record and outgoing intra-PLMN record.
The mobile station now signals its call setup requirements to the MSC, including a higher
precedence than the currently active call. The MSC queries the HLR for the location of the called
party and then attempts to route the call to the called party. However, it finds that there are no
outgoing circuits available for the new call and so uses the pre-emption procedure to release the
currently active call and to reserve the released circuits for the new mobile originated call. The
MSC then routes the call towards the called party.
The MSC captures details of the new call in a mobile originated call attempt record. It captures the
results of querying the HLR in a roaming record and the use of the trunk circuits in an outgoing
intra-PLMN record. To record the pre-emption details, the MSC appends a supplementary services
(SS) information module to the outgoing intra-PLMN record of the originally active call. This
record contains the precedence levels of the pre-empted call (the originally active call) and the pre-
empting call (the new mobile originated call). The result indicator indicates that the pre-empting
call was made by a mobile eMLPP subscriber. To record the eMLPP service details of the new call,
the MSC appends an SS information module to the mobile originated call attempt record of the new
call.
Depending on the call scenario, the SS information module may be appended to different records.
The rule in all cases however, is that the SS information module containing the details of the
resource pre-emption is appended to the call record of the pre-empted call. For example, the
scenario in Figure 50 shows an example of a mobile originated call being pre-empted by another
mobile originated call because of a lack of terrestrial radio resources. In this case, the pre-emption
details are captured in an SS information module appended to the mobile originated call attempt
record of party A. Once again, this module contains the precedence levels of both the pre-empted
and pre-empting call.
MSC
HLR
MOC
Record
Roaming
Record
OGIP
Record
ICIP
Record
active
Call
OGIP
Record
EoM
TS
EoM
L&C
TS
SS (eMLPP)
SS (eMLPP)
EoM
Key
Figure 50 Terrestrial Resource Pre-emption
B6.23 GSM-R Call Scenarios
This section contains some example call scenarios for GSM-R calls:
Section B6.23.1, Voice Group and Broadcast Calls
Section B6.23.2, Functional Addressing
B6.23.1 Voice Group and Broadcast Calls
The voice group call service (VGCS) and voice broadcast service (VBS) service are part of the
advanced speech call item (ASCI) services. This section contains two example scenarios to
illustrate these services. The term group call is used here to describe both services.
B6.23.1.1 Mobile Dispatcher Group Call
Figure 51 shows an example scenario where a mobile dispatcher makes a group call (either VBS or
VGCS) to a number of terminating service subscribers. The dispatcher dials an E.164 number
which the MSC translates to determine the service required and the group call area. The MSC then
uses group call setup signalling to establish the call to all of the base stations in the group call area.
It generates a mobile originated call (MOC) record to capture the call details. There are no
terminating records generated for service subscribers.
A mobile dispatcher does not have to signal any special service information to set up the call. The
teleservice information module appended to the MOC indicates the telephony service.
MSC
Roaming
Record
OG
Record
active
Call
OGIP
Record
MOC
Record
A
B
L&C
TS
SS (eMLPP)
EoM
MOC
Record
L&C
TS
SS (eMLPP)
EoM HLR
TS
EoM
Key
OG Outgoing Gateway
Figure 51 Mobile Dispatcher Group Call
B6.23.1.2 Service Subscriber Group Call
Figure 52 shows an example scenario in which a service subscriber makes a group call to a number
of terminating dispatchers. The service subscriber dials a group identifier (GID) and requests either
the VBS or VGCS teleservice. The MSC generates a mobile originated call (MOC) record to
capture the call information. It appends a Teleservice (TS) information module to the MOC to show
the requested service (091C for VGCS or 092C for VBS). The MSC uses the location of the service
subscriber (cell of origin) along with the dialled GID to derive a group call reference. It then sets up
the group call to each dispatcher in the group call area. The MSC generates a mobile terminated call
(MTC) record for each dispatcher.
Figure 52 Service Subscriber Group Call
Calls to terminating dispatchers may also be established over ISUP and PRI trunk connections as
well as the mobile access network shown in Figure 52. In this case the MSC captures the call
information for the dispatcher in an outgoing intra-PLMN trunk record or an outgoing gateway call
attempt record.
MSC
A
MOC
Record
Key
TS
EoM
L&C
MSC
A
MOC
Record
B
C
D
MTC
Record
MTC
Record
MTC
Record
(to B) (to C) (to D)
Key
TS
EoM
L&C
TS
EoM
L&C
TS
EoM
L&C
TS
EoM
L&C
B6.23.2 Functional Addressing
Figure 53 shows an example of a call using functional addressing. This GSM-R service allows a
user to be called using a functional numbers (FN) instead of an MSISDN. The functional address is
stored in the intelligent network (IN) Service Control Point (SCP).
In the example scenario, party A calls party B by dialling party Bs FN. Party A may also send its
own FN to the MSC so that this information can eventually be passed to party B. The MSC
generates a mobile originated call (MOC) record and captures the FN in the dialled digits field. The
MSC then sends the FN of party B to the SCP which returns the associated MSISDN. The MSC
appends an IN information module to the MOC record. The module contains the MSISDN returned
by the SCP. The MSC queries the HLR for routing information for party B using the MSISDN and
then routes the call based on the information that it receives. If party A signalled its FN, the MSC
includes it in the call setup information. The MSC generates a roaming record and an outgoing
intra-PLMN record.
The MSC serving party B sets up the call to party B and generates an incoming intra-PLMN record
and a mobile terminated call (MTC) record. The FN of party B is signalled in the backward call
setup messaging to party A.
Figure 53 Functional Addressing Call
MSC
HLR
MSC
MTC
Record
A
B MOC
Record
Roaming
Record
ICIP
Record
OGIP
Record
(A to B) SCP
Key
IN Intelligent Network Information Module
TS
EoM
IN
EoM
L&C
TS
L&C
EoM
TS
The decision about whether to display the MSISDN or the FN is up to each party. The presentation
of functional numbers is handled by User-to-User Information (UUI) Supplementary Service. The
calling party sends its FN to the called party using the UUI; the called party sends its FN to the
calling party also using the UUI service. The CLIP (calling line identification presentation and
CoLP (connected line presentation) services may be used to display MSISDNs instead of the FNs.
The user decides whether to use the UUI or CLIP/CoLP information to display the FN or the
MSISDN. If used, CLIP or CoLP information is captured in an SS information module appended to
the appropriate call record. If party A displays Bs MSISDN, the CoLP information is captured in
an SS information module appended to the MOC record. If B displays As MSISDN the CLIP
information is captured in an SS information module appended to the MTC record.
B6.24 Market-Specific Call Scenarios
B6.24.1 Chinese Market CAMEL Phase 2 Service Billing
In the Chinese market a number of services are provided using CAMEL Phase 2 intelligent
networking. In these services, the MSC/SSP interrupts normal call processing to interact with the
service logic running on the Service Control Point (SCP). Both the MSC/SSP and SCP generate call
detail records, so it is important that the downstream processor processes the appropriate records to
generate customer bills. In the Chinese market operators can set up their services so that the records
produced by the MSC/SSP are marked so that the downstream processor can process them
accordingly.
Figure 54 shows an example of CAMEL call forwarding. In this case, party A calls party B who
subscribes to a CAMEL call forwarding service. During the origination of the forwarding leg, the
CAMEL service is triggered and the SCP sends information to the MSC/SSP to complete the call to
the forwarded-to party.
When party A calls party B, the MSC/SSP creates a mobile originated call (MOC) record to capture
the call details. The MSC/SSP sends a SendRoutingInformation (SRI) message to the HLR to get
the service details for party B. The HLR returns service information for party B in an SRI Ack
message. This contains details of a terminating CAMEL service and an originating CAMEL service
plus a forwarded-to number to be used if call forwarding is encountered. The MSC/SSP creates a
mobile terminated call (MTC) record to capture the call details. Party Bs terminating CAMEL
service is triggered at detection point 12 (DP12) and so the MSC/SSP sends the SCP an InitialDP
message. The SCP responds by sending the MSC/SSP a Connect message with the new service
details. Within this message, the generic number parameter contains a Number Qualifier Indicator
(NQI) set to 80 hex and generic digits with the first two being 60 (number = 60+x).
Figure 54 CAMEL call forwarding in the Chinese market
In order to route the call to party B, the MSC/SSP sends the HLR another SRI message. The HLR
responds with an SRI Ack message which indicates that party B is busy and so party Bs call
forwarding service is triggered. The mobile originated CAMEL service is triggered at DP2 and the
MSC/SSP sends the SCP another InitialDP message to get the service details for the call forwarded
leg to party C. The InitialDP message contains the 60+x number as the calling party number, party
Cs number as the called party number and party Bs number as the originally called number. The
MSC/SSP creates a MOC for the call forwarded leg. The SCP responds with a Connect message in
which the generic number parameter contains an NQI of 80 hex and the generic digits contain party
As number. The message also contains a redirecting party id parameter which contains party Bs
number and a destination routing address parameter which contains party Cs number. The MSC/
SSP sends the HLR and SRI message to get routing information to complete the call to party C. The
HLR returns the information in an SRI Ack message. The MSC/SSP sets up the call to party C and
captures the call information in an MTC record.
In this call scenario, all of the parties are on the same MSC/SSP. If the MSC/SSP routes the call to
another MSC/SSP, or a PSTN node, it creates a roaming record and either an outgoing intra-PLMN
record or an outgoing gateway record. The numbering in these terminating records is the same as
that shown in the terminating records in Figure 54.
MSC/SSP
HLR
A C
MOC
Record
SCP
Key
IN Intelligent Network Information Module
NCR Network Call Reference
TS
IN
EoM
MTC
Record MOC
Record
TS IN
EoM
L&C
NCR
TS
EoM
NCR
L&C
SS
IN
MTC
Record
TS
EoM
L&C
B
Calling Number field contains
Party Bs number irrespective
Calling Number field contains Party As number
(the generic number from the SCP).
Calling Number field contains a 60+x number
(the generic number from the SCP).
of the setting of the USE_
ORIGINAL_CGPN_FOR
BILLING office parameter.
The Chinese market also supports the Calling Party/Called Party Pays Service. To trigger the
service, the calling party dials either 12597 or 12598 followed by the called party number. The
MSC/SSP triggers the service at detection point DP2 or DP3 and sends an InitialDP message to the
SCP. The SCP responds with a Connect message in which the generic number parameter contains
an NQI of 80 hex and the generic digits starting with 12597 or 12598. The Connect message also
contains the Destination Routing Address (DRA) parameter which contains party Bs number. The
MSC/SSP queries the HLR and routes the call according to the information it receives. The MSC/
SSP generates a MOC and MTC record for the call. In the MOC record, the calling number field
contains party As number and the called number field contains the dialled digits, that is 12597 or
12598 followed by the called party number. In the MTC record the calling number field contains the
number in the generic digits and the called number field contains the number from the DRA
parameter.
Part C:
Tariff Administration
APP 5.9 Standard Part C: Tariff Administration
C1 Introduction
C1.1 Overview
3GPP TS 32.205 specifies that network elements should support a tariff system to provide charging
information for the Advice of Charge (AoC) supplementary service. The tariff information is used
to determine a set of parameters which are sent to the mobile station. The mobile station uses the
parameters to perform a real-time calculation of the charges that will be levied for the call or to
provide an estimate of the charges. The MSC supports an on-line tariff system to support the AoC
service.
The following sections give an overview of the tariff system:
Section C1.2, Defining Service Areas Covered by the Tariff System describes how the
operator can define the geographical area to be covered by the tariff system.
Section C1.3, The Tariff System describes how the operator can specify the charge
bands to be applied each day to define the tariff switching pattern.
Section C1.4, Tariffing for the Advice of Charge (AoC) Service describes the tariffing
requirements for AoC. AoC uses the tariff switching pattern and additional tariffing
based on the service used and the call distance.
Section C1.5, Tariff Administration Change Control (TACC) describes how the tariff
system is controlled.
Section C2, Tariff System Functions provides more information on the components of the tariff
system. Section C3, Advice of Charge for Multiple Rate Plans describes how operators can set
different rate plans for their subscribers and then use the rate plan to provide appropriate AoC
parameters for the AoC services.
C1.2 Defining Service Areas Covered by the Tariff System
To define the service areas covered by the tariff system, the network operator can divide any given
geographical region into a number of separate areas. For example, the operator may divide the
entire world into separate areas to define a fully international tariffing system. Alternatively, the
operator may divide the region covered by its network into separate areas. The definition of these
areas is arbitrary, allowing the operator total flexibility in defining coverage.
On the MSC, the network operator defines separate areas in terms of logical networks (LNETs) and
metering zone (MZONEs). The operator then defines the interconnections across MZONE
boundaries using route groups (RGRPs). An example is shown in Figure 55.
Part C: Tariff Administration Standard APP 5.9
Figure 55 Logical Networks, Metering Zones and Route Groups
Figure 55 shows two LNETs, LNET 1 and 4, each divided into MZONEs. An operator can specify
up to 16 LNETs, with LNET value 1 reserved for the home network and LNET value 0 reserved for
unknown networks. Each LNET can be divided into up to 64 MZONEs, with values from 0 to 63.
Each MZONE may have up to 127 RGRPs defined in it. An RGRP lists the trunk groups which can
be used to form connections over the route. The RGRP is important in determining the call charges
as a call to a given destination can be setup over a number of alternative routes. For example, in the
United States, a caller making a long distance call to New York can select a long distance carrier to
connect the call. Regardless of the carrier selected the destination of the called party is the same.
However, the selection of a given carrier will affect the charges levied for the call. As an example,
Figure 55 shows three alternative connections between A and B: the direct route using RGRP 126,
or the indirect routes using RGRPs 1 and 14, or RGRPs 3 and 101.
C1.3 The Tariff System
The tariff system defines the tariff to be applied for each call. Within the tariff system it is possible
to define up to 32 different tariffing regimes to meet differing tariff requirements. The regimes are
identified by tariff indexes (TIDXs) numbered from 0 to 31. Each TIDX is determined by unique
combinations of LNET, MZONE and RGRP. This mapping is performed by table DESTZGRP as
shown in Figure 56. The table can hold up to 8K entries which map different combinations of
LNET, MZONE and RGRP to the TIDXs.
The reason for providing the capability to define a number of tariffing regimes is that the price an
operator pays for using another operators network depends on the charges levied by that operator.
For example, a US operator may connect a call at noon local time to a network in Taiwan where the
local time is nearer midnight. At midnight the Taiwanese operator may well be operating an off-
peak tariff and the US network should take account of that charge.
LNET 4 Home network
(LNET 1)
MZ 1
MZ 32
MZ 63
A
B
MZ - MZONE
Key
- Service Switching Point (SSP)
- Signal Transfer Point (STP)
- Route group
1
3
14
101
MZ 2
MZ 3
MZ
32
MZ
60
MZONE 3 MZONE 60 126
Figure 56 Mapping LNET, MZONE and RGRP to a Tariff Index (TIDX)
During call setup, the universal translations system determines the route to be used for the call
based upon analysis of the call setup information. The translations system uses the LNETs specified
in LNETNAME and the MZONEs defined by the operator. The trunk group used to establish the
call is mapped to an RGRP by table RTEGRP. Table DESTZGRP maps these inputs to a TIDX.
For GSM AoC, MSC table LAC (location area code) may also be used to provide information about
the location of the calling party, and, depending on the call scenario, of the terminating party. For
UMTS AoC the table LACSAC provides this information.
The tariff system itself is composed of three tables which define the charges to be applied at
different times of the day. This is called the tariff switching pattern. The system classifies days as
belonging to the day classes weekday, weekend and holiday. It then specifies the charges to be
applied on each of these types of day. For each TIDX, the operator must specify the charging bands
for the full 24 hour period of each day class. The tariff system tables which define the tariff
switching pattern are shown in Figure 57.
Figure 57 Tariff System Tables
LNETNUM LNET
LNETNAME
RGRP CONTYPE DIR TRKGRPS CDRREQ
RTEGRP
LNET MZONE RGRP TIDX
DESTZGRP
Universal
translations
The LNETs defined in table LNETNAME
are used in the universal translations tables.
TIDX is the index used to access
the relevant tariffing scheme defined
in the tariff system tables.
TIDX Date DayClass
tsDate
DayClass = holiday
TIDX Day DayClass
tsDay
DayClass = weekday
or weekend
TIDX SPeriod EPeriod DayClass ChrgBnd
tsTime
The table TSDAY defines each day of the week as being a weekday or a weekend. For each TIDX
the table lists all seven days of the week and assigns the day class value of either weekday or
weekend. The table TSDATE specifies special days in the year e.g. holidays. For each TIDX the
table lists the special dates and assigns them the day class of holiday. For tariffing purposes, the
tariffs specified for holidays take precedence over those specified for weekends or weekdays.
The table TSTIME defines the charge bands to be applied for each of the tariffing schemes
(TIDXs). The tariff system supports up to nine charge bands numbered 0 to 8. Table TSTIME has
entries which cover the full 24 hour period of the three day classes weekday, weekend and holiday.
For each day class in each TIDX, the operator specifies the start and end of each charging period
and charge band to be applied in that period. Where a single charge applies for a given class of day,
the table contains a single entry. For example, if the tariffing scheme TIDX 0 has a single weekend
charge, the table has one entry with the start period 00:00, the end period 23:59, the day class
weekend and the relevant charge. Where there are a number of different charges levied at different
times of a particular day class, the table contains an entry for each charge period. For example the
tariffing scheme TIDX 0 may have three charging period on weekdays defining a peak rate during
office hours and two cheaper periods outside of office hours. In this case there are three entries
specifying the start and end of each charging period and charge band to be used in each period.
The use of the tariff system by AoC is described in Section C1.4. Controlling the tariff system is
described in Section C1.5.
C1.4 Tariffing for the Advice of Charge (AoC) Service
The AoC service specifies that the network elements are capable of sending charge advice
information (CAI) elements to the mobile station. The mobile station uses the CAI elements (also
called E parameters) to calculate the charges for a call. The CAI elements are defined in 3GPP TS
22.024 and comprise a set of numeric constants, multipliers and rates which can be combined to
calculate call charges.
Tariffing for AoC is determined by two dependencies:
A time and date dependency specifying the tariffs which apply at different times of the
day. This information is provided by the tariff switching pattern defined by the tariff
system tables described in Section C1.3.
A service and distance dependency which determines the charges to be levied according
to the telecommunication service used and the distance over which the call is connected.
This information, called the tariff class, is provided by additional AoC tariff tables.
The analysis of information required to determine the CAI elements sent to the mobile station is
shown in Figure 58. The derivation of a charging zone applies only to mobile originated calls, based
on the general tariffing principal that the calling party pays for a call. If call forwarding is
encountered, or the route group is not specified in table RTEGRP, the charging zone defaults to 0.
Also, if the trunk group is not datafilled in RTEGRP, RGRP defaults to 127.
Figure 58 Tariff analysis for AoC
Table 269 summarises the analysis performed for a mobile originated and a mobile terminated call.
Figure 59 shows the MSC tables involved in providing the tariff switching pattern and the tariff
class information which determine the CAI elements sent to the mobile station.
Analysis Level and function
Type of call
Mobile Originated Call Mobile Terminated Call
1
Charging origin Based on cell of origination Dont care (0)
Charging destination
Based on a combination of dialled digit
analysis and selected outgoing trunk group.
Based on cell of paging response
2 Service type Mobile originated telephony call (0) Mobile terminated telephony call (1)
3 Tariff switching pattern Based on time of day, day class, selected route etc.
4 CAI element E3 Based on MCC/MNC of calling mobile Based on MCC/MNC of called mobile
Table 269 Information analysed at each level
Charging
origin
Charging
destination
Level 1
Analysis
Service
Tariff
class
Tariff
switching
pattern
CAI
elements
CAI elements (E parameters)
Level 2
Analysis
Level 3
Analysis
Level 4
Analysis
type
E3 CAI
element
sent to mobile station
Charging
zone
Defined in Section C1.3
Figure 59 Deriving Charging Parameters for the AoC Service
TARID TARCLAID CHRGBAND
LAC KEY MZONE
1 1 0
. . .
. . .
ZONEID ORIGID DESTID
Table LAC/LACSAC
Table CHRGZONE
Table TARDETA
TARCLAID SUBSERV ZONEID
Translation System
LAC KEY MZONE
1 5
2
. . .
. . .
If the called party is on a different
Table LAC for GSM: Originating MS location area code (LAC) & Cell-ID Terminating MS LAC & Cell-ID Dialled digits (MSISDN)
Table LAC/LACSAC
Table TARCLASS
Tariff Switch. Pattern
DESTID LNET MZONE
Table DESTZGRP
LNET, MZONE
HOMENET 02 01
1 0 2
CHRGBAND
0
5
5
2 MOT
Mobile originated/
RGRP
02
RGRP TRKGRP
1 trkgrp1
. . .
. . .
Table RTEGRP
Direction = outgoing
DIR
og
outgoing trunk
CAIELEMS TARID
Table TARAOCA
45 1 2 4 0 0 3
45
Using the LNET and MZONE from
translations and RGRP from table RTEGRP,
the tables of the tariff system define the tariff
switching pattern or charge band. See
Section C1.3.
MSC to the calling party
If the called party is on the same
MSC as the calling party
.
terminated
telephony service
(MOT/MTT)
Table LACSAC for UMTS: Originating MS LAC and service area code (SAC) Terminating MS LAC and SAC
C1.5 Tariff Administration Change Control (TACC)
The TACC system allows a craftsperson to control and update the entire tariff system. At any one
time, there is one active tariff system on the MSC. However, a craftsperson can develop an inactive
tariff system with changes reflecting new charging requirements. Using TACC, the craftsperson can
check the inactive system to remove any inconsistencies and schedule when it should become active
to replace the current tariff system.
The tables managed using TACC are TSDATE, TSDAY and TSTIME. In addition, the AoC tables
with a time component are also managed using TACC. These tables are TARDET and TARAOC.
There are in fact two versions of each of these tables: an active table e.g. TSDATEA and an inactive
table e.g. TSDATEI. Using MSC table control functions, the craftsperson can change the
information in the inactive tables to reflect new tariffing requirements. Then using TACC the
craftsperson can check the inactive tariff system defined by these tables and schedule when it
should become active.
Tariff administration is described in more detail in Section C2.3.
C2 Tariff System Functions
C2.1 Tariff Switching Pattern Functions
C2.1.1 Charging Calendar
The MSC allows the definition of a charging calendar for a particular year. The calendar shall
contain a set of day definitions (Monday, Tuesday etc.) each of which allocates a day class
(Weekend or Weekday) to a particular day of the week. The calendar shall also contain a set of date
definitions (Holiday only) for which tariffing may be different. The date definitions shall take
precedence over the day definitions e.g. if the date definition shows the day to be a holiday it is not
relevant that the day may also be a weekend.
C2.1.2 Day Class
The MSC allows the definition of a day class to be used in the charging calendar. A day class shall
be used to group together days on which the same tariff switch pattern is applied. The MSC shall
allow the definition of three day classes: weekday, weekend and holiday.
C2.1.3 Tariff Switch Pattern
The MSC shall allow the definition of a tariff switching pattern for a 24 hour period i.e. one
calendar day. This pattern is applied to all the days belonging to a particular day class. On the MSC
it is necessary to define a minimum of three tariff periods i.e. 00:00-23:59 for each allowed day
class. The granularity may be refined greatly (if required) by defining a number of tariff periods
over a 24 hour period for each day class. Associated with each tariff period is a particular charge
band. The MSC shall support 9 charge bands.
C2.2 Advice of Charge Tariff Functions
C2.2.1 AoC Service (or Subscriber Service)
Seventy network service descriptions are supported by the MSC for the purpose of AoC. These are
defined as Basic service and Charge indicator pairs. The Basic services supported are: mobile
originated and mobile terminated telephony, mobile originated and mobile terminated automatic fax
group 3, mobile originated and mobile terminated alternate speech/fax, mobile originated and
mobile terminated circuit duplex asynchronous (CDA) 3.1kHz, mobile originated and mobile
terminated circuit duplex synchronous (CDS) 3.1kHz, mobile originated and mobile terminated
unrestricted digital information (CDA/Transparent and Non transparent), and mobile originated and
mobile terminated unrestricted digital information (CDS/Transparent and Non transparent). The
Charge indicator values are: No indication, No charge, Charge, Called party charge, and Calling
party charge. The MSC does not support the definition of any other AoC service descriptions and
further, the AoC service is not supported on the MSC for any other possible service descriptions.
NOTE The mobile terminating AoC service offers the subscribing mobile an indication
of the cost of receiving a call i.e. cost of the air time. In some networks this air
time is chargeable to the terminating mobile subscriber. In networks where this
air time is free a cost zero indication shall be signalled to MS. This
functionality is supported by the MSC for both non-roaming and roaming mobile
subscribers.
C2.2.2 Charging Destination
The MSC allows the definition of a logical destination for distance sensitive charging purposes. A
charging destination shall be defined in terms of a destination logical network and destination
metering zone (B5.2.105 and B5.2.107 respectively). In the event that the switch destination of the
call differs from the originating MSC then the outgoing route group (B5.2.80) shall also be used in
determining the charging destination value. Based upon these three criteria it is possible to define a
maximum of 128 possible charging destinations relative to a particular MSC. The first 64 values are
reserved for charging destinations local to a particular MSC and the remaining values may be used
to define charging destinations in other switches. A simple string name may be associated with each
defined charging destination.
C2.2.3 Charging Origin
The MSC allows the definition of a logical origin for distance sensitive charging purposes. A
charging origin shall be defined in terms of an originating metering zone (B5.2.107). The
originating logical network (B5.2.105) shall always be assumed to be the home network. A simple
string name may be associated with each defined charging origin.
C2.2.4 Charging Zone
The MSC allows the definition of a distance class for charging purposes. A charging zone shall be
defined in terms of a charging origin and a charging destination. The MSC allows the definition of
64 possible charging origins and 128 possible charging destinations however the MSC shall only
allow the definition of a maximum of 256 charging zones. This means that more than one charging
origin and charging destination pair may correspond to the same charging zone. A simple string
name may be associated with each defined charging zone.
C2.2.5 Tariff (AoC)
The MSC allows the definition of a tariff. An AoC tariff consists of the set of so called e-
parameters defined in 3GPP TS 22.024. The MSC shall support the assigning of values to the e1,
e2, e3, e4, e5, e6, and e7 parameters in the tariff. The e5 and e6 parameters however shall always be
set to zero because the MSC does not support the packet switching services to which these
parameters relate. Furthermore the e3 parameter shall always be set to 100 for non roaming mobile
subscribers. The required tariff is selected based upon the tariff class and the charge band. The
charge band is obtained from the tariff switch pattern. Although the MSC will allow the definition
of 1024 possible tariff classes and 9 possible charge bands the MSC shall limit the number of
definable tariff values to 2048.
C2.2.6 Tariff Class
The MSC shall allow the definition of a tariff class. The tariff class defines a set of service and
distance dependencies for which the same tariff switch patterns apply. On the MSC the tariff class
shall be defined in terms of the AoC service (Section C2.2.1) and the charging zone. Although the
MSC will allow the definition of 70 possible AoC service descriptions and 256 possible charge
zones the MSC shall limit the number of definable tariff classes to 1024. This means that more than
one AoC service description and charging zone pair may correspond to the same Tariff class. For a
non roaming mobile terminated service the tariff class is independent of distance and therefore the
Tariff class shall only be derived from the AoC service description. For an instance of a mobile
terminated service to a roaming subscriber the MSC shall allow through provisioning the option of
Tariff class selection based upon the Tariff switch pattern in operation at the roaming subscribers
Home PLMN at the time of the call. This ensures that the roaming subscriber is correctly informed
of the charges being incurred for the resources utilized on the roaming leg of the call. For avoidance
of doubt the default operation of this function for a roaming subscriber is Tariff class selection
based upon the Tariff switch pattern in operation at the Visited PLMN at the time of the call.
C2.3 Tariff Administration
C2.3.1 Administration and Control
On the MSC tariff administration is achieved via table control functions at the human machine
interface. The on line definition of two tariff systems is supported by the MSC. One of these tariff
systems will be the active tariff system and the other will be the inactive tariff system. Access to the
active tariff system data shall be read only. The inactive tariff system may be in one of three states:
available, checked or standby. Editing of inactive tariff system data shall only be allowed when the
tariff system is in the available state.
The application of a taSubmitChangeOver subcommand shall update the active tariff system with
the new (formerly the inactive tariff system in standby state) tariff system and replaces the standby
tariff system with the old tariff system. This permits a rollback to the old tariff system should it be
necessary
Once a changeover is scheduled details of both the change-over time and the change that will take
place may be obtained at the human machine interface. A scheduled changeover may be cancelled
at any time by application of the taCancelChangeOver or taUnfreeze subcommands.
No changes are permitted to the currently active tariff system. The MSC provides a
taCopyTariffSystem subcommand which may be employed to copy the entire contents of the active
tariff system into the inactive tariff system. The new system may then be modified as required.
C2.3.2 Tariff System
On the MSC the tariff system is defined in terms of a consistent set of tariff and tariff classes. The
tariff classes in turn shall have switch over patterns associated with them. A rigid set of control
mechanisms are provided to control the modification of these tariff entities in order to guarantee
that the system remains consistent after modification.
The MSC shall allow there to be one and only one active tariff system at any one time. The current
state of a tariff system may be obtained by the examination of captive office datafill. A simplified
state transition diagram is illustrated in Figure 60. The entities within a tariff system may not be
modified whilst in the active state. (modification of a tariff system is only possible whilst in the
available state). The MSC shall allow the preparation of a second tariff system (inactive) whilst
another tariff system is active.
Figure 60 Tariff system state transition diagram
The MSC provides functionality to check a completed tariff system for data consistency.
Application of a taCheck subcommand at the human machine interface shall invoke a set of
standard checks that ensure that the tariff system is both complete and consistent. When this
subcommand returns a successful result the tariff system shall transition into the checked state. In
this state the tariff system cannot be modified. To modify a tariff system in the checked state
requires an application of the taUnfreeze subcommand. This subcommand shall transition the tariff
system back into the available state.
Once complete, a tariff system may be activated by means of the taSubmitChangeOver
subcommand. Two types of change over are supported by the MSC: immediate change over and
scheduled change over. With an immediate change over the tariff system becomes active (replacing
the old tariff system) immediately. With a scheduled change over a date and time included in the
subcommand indicates the point in time when this tariff system shall become active. This date and
time must be greater than or equal to the current time. If the date and time equals the current time
then a prompt shall be issued to determine if an immediate change over is intended. A scheduled
change over command transitions the tariff system into the standby state. Before the application of a
taSubmitChangeOver command is allowed an appropriate check for privileged access authority
must be satisfied.
Available
Checked
Standby
Active
taCheck
taSubmitChangeOver
(scheduled)
taSubmitChangeOver
(time-out)
taSubmitChangeOver
(immediate)
taUnfreeze
taUnfreeze
taUnfreeze
taRollBackChangeOver
taCancelChangeOver
While in the standby state a tariff system may be transitioned back into the checked state or back
into the available state by application of the taCancelChangeOver subcommand or the taUnfreeze
subcommand respectively. Both subcommands shall deactivate the scheduled tariff system
changeover however only the latter subcommand will allow the re-editing of the tariff system data.
On activation, a change over shall take place between the currently active tariff system and the new
tariff system specified in the taSubmitChangeOver subcommand. The new tariff system shall
become active and the old tariff system shall be placed in the standby state. The application of the
taRollBackChangeOver subcommand shall cause the reactivation of the old tariff system. This
backup shall be available until new tariff system (inactive) development begins at the MSC.
C3 Advice of Charge for Multiple Rate Plans
C3.1 Introduction
This service uses new rate plan information as an additional key into the existing tariff system to
derive the charging information sent to the user in the Advice of Charge (AoC) service. It uses
many of the existing tariff system tables and tariffing principles described in Section C1 on
page 319.
In the multiple rate plan scheme, each subscriber is assigned a rate plan. The rate plan is defined by
Customer Group (CUSTGRP) and Network Class of Service (NCOS) settings. Together CUSTGRP
and NCOS form a COS key which defines a subscribers rate plan. If a subscriber changes to a
different rate plan, the operator changes the COS key to the one defining the new plan. CUSTGRP
and NCOS are proprietary Nortel service settings.
The tariff identifier (TARID) derived from the existing tariff system and the COS (rate plan)
settings feed into a new table called TARAOC2. Using the TARID and COS values, the new table
provides the Charging Advice Information (CAI) elements to be sent to the mobile handset to
provide the charging information. The multiple rate plans can be used for both AoCI (AoC
information which provides an estimate of call charges to the user) and AoCC (AoC charging for
real-time charging of the subscriber).
If COS information is not present for a given AoC subscriber this means that the rate plan
information is not available. In this case the original single rate plan applies for both Mobile
Originated and Mobile Terminated calls and the CAI elements are obtained from the existing tariff
table TARAOCA as shown in Figure 59 on page 324.
C3.2 Setting Up AoC with Multiple Rate Plans
C3.2.1 Software Optionality Control (SOC)
The use of this service is controlled by the SOC option AOC Multiple Rate Plan. If this is set to idle
none of the multiple rate capabilities are available except for the new table TARAOC2. When the
SOC option is set to ON, the full multiple rate plan capabilities are available.
C3.2.2 Provisioning in the HLR and MSC
The desired Rate Plan must be represented by a COS value in the HLR consisting of both a
CUSTGRP and a NCOS value.
The COS Index (CUSTGRP/NCOS values from Table GSMCUST and GSMNCOS)
used to specify the AOC Multiple Rate Plan must have the XLT option data filled.
Additionally, to allow the plus key dialling, the COS_PLUS_KEY_REG office
parameter in table GHLRDFLT needs to be set to Y.
In Table GHLRSSOP, the subscriber must be provisioned with valid CUSTGRP/NCOS
values.
On the MSC translations information and the information in the tariff system must be correctly set:
The tables LAC and LACSAC along with Universal Translations must be data filled to
properly represent the tariff information of the network.
AoC tariff tables must be data filled with the accurate tariff information. These tables are
table DESTZGRP, CHARGZONE, TSTIMEA, TSDAYA, TSDATE, TARCLASS, and
TARDETA.
Valid TARID/CUSTGRP/NCOS values must be present in Table TARAOC2. If the
fields, TARID/CUSTGRP/NCOS, do not have a valid index or are not data filled, the
MSC does not attempt to provide AoC Multiple Rate Plan for that particular subscriber.
For a subscriber using AoCC, the call is taken down because, as the charging
information is unreliable, the subscriber cannot be charged using it. For a subscriber
using AoCI, the call continues but without the CAI sent which means the subscriber
does not get the charging estimate.
Table TARAOC2, provides the CAI elements of the tariff system. Table TARAOC2
overrides the existing active table TARAOCA and the inactive table TARAOCI. This is
implemented so that the craftsperson can modify CAI Elements in table TARAOC2
without Change Control Management. Because Change Control Management is not
applicable for table TARAOC2, the craftsperson is responsible for ensuring the integrity
of any datafill. However, Change Control Management still ensures the consistency of
all other Tariff Administration tables.
C3.3 AoC and MRP Data Tables
C3.3.1 AoC and MRP Tables for Intra-PLMN Calls
Figure 61 AoC with MRPs for Intra-PLMN Calls
Table LAC/LACSAC
Table LAC/LACSAC
LAC KEY
MZONE
. . . . . . . . .
301 8 . . . . . . . . . 1
UXLA
Originating MS Location Area Code (LAC) and Cell ID
If the called party is on the same MSC as the
calling party
If the called party is on a different MSC than the
calling party or if the called party is a land line.
Dialled Digits (MSISDN)
CONN
DIR CDRREQ TRKGRPS KEY
107 GATEWAY OG
Y
ANSIISUP
MZONE
RGRP DESTID DESTNAME LNET
1 43 107
77
DEST77
Universal Translations
LNET MZONE
DESTID ZONEID
ZONENAME ORIGID
1
5
11
AOCZONE
Table RTEGRP
Table DESTZGRP
1 77 43
ATUPLOOP
Table CHRGZONE
AOCSERV TARCLSID TIDX
ZONEID
11
2
11 0
43 2 43
0
Table TARCLASS
CHRGBND
TARID
11
7
117
43 5 435
Table TARDETA
TARCLSID
CHRGIND AOCSERV
CALLTYPE
MO_TPHY
CHARGE
2
Table SERVTYPE
TSTIME_KEY
0 1500 1529 WEEKEND 7
0 1400 1429 WEEKDAY
5
Table TSTIMEA
CHRGBAND
CUSTGRP
435
TARID
NCOS E1PARM E2PARM E4PARM
E5PARM E6PARM E7PARM
TARNAME
117
10
10
1
1
MSORIG1
MSORIG2
600
600
10
10
0
0
0
0
0
0
600
600
MS
VLR Translations
Table TARAOC2
for CUSTGRP and
NCOS
Note: For MT call, the default
ORIGID of 0 is used.
Note: From this point, the first row
represents a scenario in which the called party
is on a different MSC to the calling party. The
second row represents a scenario in which
the called party is on the same MSC as the
calling party.
Table LAC for GSM: Originating MS location area code (LAC) & Cell-ID
Table LACSAC for UMTS: Originating MS LAC and service area code (SAC)
LAC KEY
MZONE
. . . . . . . . .
301 7 . . . . . . . . . 5
Terminating MS LAC & Cell-ID
Terminating MS LAC and SAC
C3.3.2 AoC and MRP For Roaming Subscribers
Figure 62 AoC and MRP for Inter-PLMN Calls
C3.4 Examples of AoC and Multiple Rate Plans (MRPs)
This section provides examples of how AoC is used with MRPs for intra-PLMN and inter-PLMN
calls using the table datafill described in Section C3.3 on page 335.
C3.4.1 Intra-PLMN AoC MRPs
For a mobile originated call:
1. Subscriber A is datafilled with AoC and with COSINFO (CUSTGRP/NCOS) for
example 7/20 in the HLR.
2. The AoC subscription and COSINFO are sent to MSC (VLR) in the MAP Insert
Subscriber Data (ISD) message during the Location Update procedure.
3. Subscriber A originates a call.
4. MSC A enters the AoC translations (UXLA) and derives a Tariff ID, for example 123,
from the relevant tables datafill.
CUSTGRP
435
TARID
NCOS E1PARM E2PARM E4PARM
TARNAME
117
10
10
1
1
MSORIG1
MSORIG2
600
600
10
10
0
0
0
0
0
0
600
600
MS
Table TARAOC2
MNC
505
MCC
CHRGBAND E2PARM E3PARM E4PARM
02 5 10 100 0 0 0 600
Table PLMNSUPA
E1PARM
600
From Subscriber IMSI
From table TSTIMEA.
Please refer to the previous
figure.
See Figure 61 for these three inputs to TARAOC2
505 02 7 10 100 0 0 0 600
600
For Inter-PLMN call, E3 is retrieved from
PLMNSUPA.
Other E Parameters are retrieved from:
1) MO call, TARAOC2
2) MT call, PLMNSUPA
5. Table TARAOC2 is checked for an entry against Tariff ID 123 and COS information of
7/20.
6. If an entry is found in TARAOC2, the corresponding CAI elements are sent to
Subscriber A.
If there is no entry in table TARAOC2 a log is generated to report the corrupt datafill.
The call is taken down for an AOCC subscriber or continues without the charging
information for an AOCI subscriber.
The process for a mobile terminated call is very similar, except that in step 3. the subscriber
terminates a call.
C3.4.2 Support of AoC with MRPs for Inter-PLMN Roaming
Inter-PLMN roaming is supported for AoC calls but multiple rate plans are typically not shared
between operators. Because COS is a Nortel proprietary functionality, it is expected that the Home
PLMN does not send COS information to a Visited PLMN MSC/VLR for roaming subscribers.
Therefore, when no COS value is received for a AOC subscriber, it is assumed that s/he is an
inbound roamer and the original AoC single rate plan applies for both Mobile Originated (MO) and
Mobile Terminated (MT) calls.
Where two operators have an explicit roaming agreement for AoC Multiple rate plans, and both use
Nortel MSC and HLR with mutually agreed datafill and COS values for Multiple Rate plans for
roamers, then a COS value may be sent to the VPLMNs MSC/VLR. When a COS value is present
for an AoC call, AoC Multiple Rate Plans apply, i.e., the inbound roamer is treated like a local
subscriber for mobile originated calls. For mobile terminated calls the single rate plan applies in
line with the AoC specifications.
C3.4.2.1 Mobile Originating Call with Inter-PLMN Roaming
For outgoing calls, the Local PLMN (LPLMN) determines the tariff in Home PLMN (HPLMN)
units. The LPLMN, be it the HPLMN or the Visited PLMN (VPLMN), always sets the values of the
CAI elements E1, E2, E4, E5, E6, and E7 in terms of units of the LPLMN and according to its own
tariff structure. Element E3 then converts LPLMN units into HPLMN units. So the values of E1,
E2, E4, E5, E6, E7 are retrieved from table TARAOC2 while E3 is retrieved from table
PLMNSUPA. See Figure 61 and Figure 62. For this example:
1. Subscriber A is datafilled with AOC and COSINFO(CUSTGRP/NCOS) value, being 7/
20 for example, in HLR of HPLMN (for example, MCC 505, MNC 02).
2. AOC and COSINFO are sent to VLR in VPLMN in ISD during Location Update.
3. Subscriber A originates call.
4. MSC A enters AOC XLA and derives a Tariff ID, being 123 for example, from the
relevant tables datafill.
5. Table PLMNSUPA is checked for an entry against MCC/MNC(505/02) to retrieve E3. If
no entry is found in table PLMNSUPA, a log is generated to report the corrupt datafill,
and the call is taken down if AOCC or continues if AOCI.
6. Table TARAOC2 is checked for an entry against Tariff ID 123 and COS information of
7/20 to retrieve E1, E2, E4, E5, E6 and E7.
7. If an entry is found in TARACO2, the corresponding CAI elements are sent to
Subscriber A. Otherwise, if no entry is found in table TARAOC2, log is generated to
report the corrupt datafill, and the call is taken down if AOCC or continues if AOCI.
C3.4.2.2 Mobile Terminating call with Inter-PLMN Roaming
According to 3GPP Specification 22.024, for incoming calls to roamers involving AoC, the
HPLMN determines the tariff (charge to be levied), and the tariff is not dependent on the time of the
call, or the type of service being used. This tariff is communicated by the HPLMN to each of the
other PLMNs with which it has a roaming agreement. This means that the LPLMN must provide
CAI values to all of the PLMNs with which it has a roaming agreement.
However, in order to provide a mechanism that allows a more accurate determination of charge the
earlier Nortel feature AD7365 enhanced the charging capabilities to allow the charge band to be
used (in addition to the HPLMNs information) in the charge calculation. The charge band itself is
dependent on the following:
Time/Day/Date the call is made (from the perspective of the HPLMN)
Tariff Class of the call, which is based on the Service and Distance factors involved in
the call.
The CAI values are retrieved from PLMNSUPA as shown in Figure 62. In this scenario the
COSINFO is not used and only single rate plan is applied. In this case:
1. Subscriber A is datafill with AOC in HLR of HPLMN(MCC 505, MNC 02).
2. AOC is sent to VLR of VPLMN in ISD during Location Update.
3. Call is terminated to Subscriber A.
4. MSC A enters AOC XLA and derive a Charge Band of 1.
5. Table PLMNSUPA is checked for an entry against MCC/MNC(505/02) and Charge
Band 1 to retrieve all the CAI values.
6. If an entry is found in PLMNSUPA, the corresponding CAI elements are sent to
Subscriber A.
7. If no entry is found in table PLMNSUPA, a log is generated to report the corrupt datafill,
and the call is taken down if AOCC or continues if AOCI.
Part D:
Frequently Asked Questions
APP 5.9 Standard Part D: Frequently Asked Questions
D1 Enabling and Shutting Down the Hot Billing Stream
The hot billing stream, just like other billing streams, is defined and enabled by tables CRSFMT
and CRSMAP. The CRSFMT table defines the billing streams. A valid billing stream has the format
GSMFMT as shown in Table 270. In this example, the hot billing stream is defined as GHOT and
the normal billing stream by GCDR. The table also contains an entry for the AMA stream which is
not a valid billing stream.
As described in Section B2.1 on page 31, billing records are written to the billing file in 2K blocks.
In the MSC, billing records for each stream are first written into a buffer, and then the data in the
buffer is written out to disk. In table CRSFMT the TIMERDMP and TIMERVAL fields control how
frequently data in the buffer for a stream, is written out to disk. The recommended settings for the
hot billing stream (GHOT) are 'Y' and 2, respectively. These settings mean that billing data in the
buffer is written out to disk every 2 seconds even if the buffer is not full. This guarantees that billing
data is available in the active hot billing file every 2 seconds. The recommended settings for the
normal billing stream (GCDR) are 'N' and 0. This means that billing data is not written out to disk
until the buffer is full.
The hot billing stream is enabled by the table CRSMAP. The HOT tuple in table CRSMAP is pre-
defined with the STREAM field set to a default value of AMA. To turn on the hot billing stream in
CRSMAP, datafill the STREAM field for the HOT tuple with the name of the hot billing stream
previously defined in CRSFMT. In this example the stream is called GHOT. If the hot billing stream
is no longer required, it can be disabled by changing the HOT tuple in CRSMAP from GHOT to
AMA. Table 271 shows the before and after view of this tuple in CRSMAP.
KEY FORMAT DATADUMP CDRSRCH ALARMS TIMERDMP TIMERVAL
AMA BCFMT N NIL_FM N N 0
GCDR GSMFMT N NIL_FM Y N 0
GHOT GSMFMT N NIL_FM Y Y 2
Table 270 Examples definition of billing stream formats in CRSFMT
Datafill to enable the normal and hot billing streams
KEY STREAM
GSM GCDR
HOT GHOT
Datafill to disable the hot billing stream
KEY STREAM
GSM GCDR
HOT AMA
Table 271 Example datafill of billing streams in CRSMAP
Part D: Frequently Asked Questions Standard APP 5.9
The effect of this change is to redirect the hot billing stream to the AMA stream defined in table
CRSFMT. This is not a valid billing stream and so it is not recognised by the GSM/UMTS billing
applications. All GSM/UMTS billing records are then directed to the normal GSM/UMTS billing
stream which in the examples shown here is called GCDR.
The information disclosed herein is proprietary to Nortel or others, and is not
to be used or disclosed to unauthorised persons without the written consent
of Nortel. The recipient of this document shall respect the security status of
the information.
This document and the information contained herein is provided as is with
no warranty of any kind, expressed or implied.This includes, but is not limited
to, the implied warranties of merchantability or fitness for any particular
purpose. The entire risk as to quality and performance of such information is
with the user. Should the information prove defective, the user assumes the
cost of all necessary servicing, repair, or correction. In no event is Nortel
liable for any damages, direct, indirect, or consequential.
Nortel may, but is not obliged to, update the information, or arrange for the
information to be updated, and make the updates available to users from time
to time.
The master copy of this document is stored in electronic format, and any hard
copies or soft copies used for distribution are uncontrolled. For information
on how to obtain the latest version refer to the Product Planning (Switching)
Document Control Process Ref. NQAPR103 .
2005 - 2006 Nortel
GSM/UMTS MSC Billing and Account-
ing Specification
MSCS19
Document Number: Q272-1
Document Status: APP 5.9
Classification: Standard
Activity: 19412375
Date: 17th July 2006

aDMSCBILL 5 9 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

aDMSCBILL 5 9 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Q272-1

UMTS Network Signalling Systems

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