Q272-1 UMTS Network Signalling Systems GSM/UMTS MSC Billing and Accounting Specification SIM Specification (Approved) NSS18 APP 4.9 30th March 2005
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Q272-1UMTS Network Signalling SystemsGSM/UMTS MSC Billing and Accounting Specification
SIM Specification (Approved)NSS18 APP 4.9 30th March 2005
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 .
2004 - 2005 Nortel
UMTS Network Signalling SystemsGSM/UMTS MSC Billing and Accounting SpecificationNSS18SIM Specification (Approved)
Document Number: Q272-1Document Status: APP 4.9Classification: StandardActivity: 12557317Date: 30th March 2005
GSM/UMTS MSC Billing and Accounting SpecificationSIGN OFFIssue: APP 4.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 SpecificationAPP 4.9 Standard NSS1830th March 2005 (Approved) Page: v
Revision Information
Revision Issue Date Act ID Description of ChangesDRA 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 February 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.
APP 4.7 (Draft) March 2005 12557317 Specification draft updated.
GSM/UMTS MSC Billing and Accounting Specification Q272-1NSS18 Standard APP 4.9Page: vi (Approved) 30th March 2005
APP 4.8 (Draft) March 2005 12557317 Specification updated after a review meeting.
Revision Issue Date Act ID Description of Changes
Q272-1 GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 Standard NSS1830th March 2005 (Approved) Page: vii
About this Specification
Release Information
As NSS17 was a limited release, some customers may upgrade to NSS18 directly from NSS16. For this reason, sections A2.1 on page 7 to A2.3 on page 26 contain descriptions of the changes made in the NSS18 and NSS17 releases. In the remaining sections, only changes made in NSS18 are highlighted using underlined text (see ‘Documentation Conventions’ on page viii).
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 ETSI technical specification 3GPP TS 32.205 are used in the Nortel implementation. However, the MSC does not support all of the features of 3GPP TS 32.205. The purpose of this specification is to describe (for the features supported) the Nortel implementation and interpretation of the functionality described in technical specification 3GPP TS 32.205. In other words, this specification does not specify compliance to 3GPP TS 32.205, though as far as possible it uses the terms of 3GPP TS 32.205. 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 SuperNode Data Manager (SDM) hardware platform or on the Core and Billing Manager (CBM) hardware platform. The SBA on the CBM/SDM provides a robust, fault-tolerant server which supports the full range of Nortel’s billing capabilities and provides a choice of file transfer protocols.
GSM/UMTS MSC Billing and Accounting Specification Q272-1NSS18 Standard APP 4.9Page: viii (Approved) 30th March 2005
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
NCL Order code Name Description MNCL
Order code Medium
GBSN0180 GOSSGBSN0180 GSM18 Sample Billing SBA North America GBSNM180 CDROM GBSW0180 GOSSGBSW0180 GSM18 Sample Billing SBA World Trade GBSWM180 CDROM
Q272-1 GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 Standard NSS1830th March 2005 (Approved) Page: ix
Standards
[1] 3GPP TS 23.032, version 4.1.1: Universal Geographical Area Description (GAD)
[2] 3GPP TS 23.078 version 4.9.0: Customised Applications for Mobile networkEnhanced Logic (CAMEL) Phase 3 - Stage 2
[3] 3GPP TS 23.107, version 4.6.0: QoS Concept and Architecture
[4] 3GPP TS 23.207, version 5.9.0: End-to-End QoS Concept and Architecture (Release 5).
[5] 3GPP TS 23.305, version 4.5.0: Stage 2 functional specification of User Equipment (UE) positioning in UTRAN
[6] 3GPP TS 24.008, version 4.11.0: Mobile radio interface layer 3 specification; Core Network Protocols - Stage 3
[7] 3GPP TS 24.011, version 4.1.1: Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface
[8] 3GPP TS 24.080, version 4.3.0: Mobile radio interface layer 3 Supplementary services specification Formats and coding.
[9] 3GPP TS 29.002, version 4.12.0: Mobile Application Part (MAP) specification
[10] 3GPP TS 29.078 version 4.8.0: CAMEL Phase 3; CAMEL Application Part (CAP) specification
[11] 3GPP TS 32.200, version 4.4.0: Charging management; Charging principles
[12] 3GPP TS 32.205, version 4.4.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
Nortel Documentation
[14] 411-4231-301: GSM/UMTS VCN Billing Application OA&M Manual.
[15] 411-2231-451, Volumes 1 and 2: DMS-MSC/Call Server Customer Data Schema
[16] 411-2231-455: GSM MSC / UMTS CCN CS Office Parameters Reference Manual
Transfer interfaces
[17] DMS-MSC FTAM Billing Transfer Specification
Tape Formats
[18] AD4779: S/DMS DAT Tape Format Description
GSM/UMTS MSC Billing and Accounting Specification Q272-1NSS18 Standard APP 4.9Page: x (Approved) 30th March 2005
Translations
[19] NTP 411-3001-2202: Translations Guide Volume 2 of 2
[20] AD9239: World Trade versus North American ANSI ISUP
Abbreviations
3GPP 3rd Generation Partnership ProjectAAL2 ATM Adaptation Layer type 2AC Apply ChargingACM Address Complete MessageACR Apply Charging ReportAIN Advanced Intelligent NetworkAMA Automatic Message AccountingAMR Adaptive Multi-RateAN Access NumberANI Automatic Number IdentificationANM The ISUP Answer messageANN Answer No Charge messageANSI American National Standards InstituteAoC Advice of ChargeASSP Assisting Service Switching PointAT Access TandemATM Asynchronous Transfer ModeATUP Australian Telephone User Part BACCS Billing, Administration and Customer Care SystemBAF Bellcore Automatic Message Accounting FormatBCD Binary Coded DecimalBICN Bearer Independent Core Network (Release 4 network architecture)BSC Base Station ControllerBSS Base Station Subsystem BTS Base Transceiver StationBTUP British Telecom User PartCAI Charge Advice InformationCAMA Centralized Automatic Message AccountingCAMEL Customised Applications of Mobile-network Enhanced Logic
Q272-1 GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 Standard NSS1830th March 2005 (Approved) Page: xi
CBM Core Billing ManagerCC Circuit CoreCCS7 Common Channel Signalling System No. 7CDA Circuit-Switched Duplex Asynchronous (data)CDN Called Party NumberCDR Call Detail RecordCDS Circuit-Switched Duplex Synchronous (data)CFT Cause For TerminationCFU Call Forwarding UnconditionalCIC Carrier Identification Code (used in ANSI ISUP for PCS 1900 networks and also in
ITU-T ISUP) CISS Call Independent Supplementary ServiceCLI Calling Line Identity/IdentifierCLIP Calling Line Identity PresentationCLIR Calling Line Identity RestrictionCNAM Calling NameCOLP Connected Line Identification PresentationCOLR Connected Line Identification RestrictionCPC Calling Party CategoryCR Change RequestCRSS Call Related Supplementary Service CS Circuit-SwitchedCSD Circuit-Switched DataCSI CAMEL Subscription InformationCTM-TTY Cellular Text Modem Text Telephony CTU CTM capable transcoder unitsCUG Closed User GroupCWC City Wide Centrex (used in Singapore)DAT Digital Audio TapeDIRP Device Independent Recording PackageDMS Digital Multiplex SystemDN Directory NumberDP Detection PointDRM Distributed Recording ManagerDSH Default SMS HandlingDSP Down Stream Processor
GSM/UMTS MSC Billing and Accounting Specification Q272-1NSS18 Standard APP 4.9Page: xii (Approved) 30th March 2005
EA Equal AccessECT Explicit Call TransferEDP Event Detection PointEDP-R Event Detection Point RequestEDP-N Event Detection Point NotificationEFD Event Forwarding DiscriminatorEIR Equipment Identity RegisterEIU Ethernet Interface UniteMLPP Enhanced Multi-Level Precedence and Pre-emption (for GSM-R) EOTD Enhanced Observed Time DifferenceESRD Emergency Service Routing DigitsESRK Emergency Service Routing KeyETC EstablishTemporaryConnectionETSI European Telecommunications Standards InstituteFA Functional address(ing) (for GSM-R)FAR The ISUP Facility Request MessageFCI The INAP Furnish Charging Information MessageFOC Full Operating Capability FPE Feature Processing EnvironmentFSN File Sequence NumberFTAM File Transfer, Access and ManagementFTP File Transfer ProtocolGAD Geographical Area DescriptionGCI Global Cell IdentifierGMLC Gateway Mobile Location CentreGMSC Gateway MSCGPS Global Positioning SystemGRNCid Global Radio Network Controller IdentifierGSM-R GSM for RailwaysgsmSCF GSM Service Control FunctionHex HexadecimalHLR Home Location RegisterHPLMN Home PLMNIAM ISUP Initial Address MessageIBN Integrated Business NetworkIBN MF IBN Multi-Frequency (a trunk type)
Q272-1 GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 Standard NSS1830th March 2005 (Approved) Page: xiii
IBN7 IBN CCS7 (a trunk type)IC Inter-Exchange CarrierIMEI International Mobile Equipment IdentityIMSI International Mobile Subscriber IdentityIN Intelligent NetworkINAP IN Application PartINC International Carrier INIC ISDN Network Identifier CodeIOC Input-Output ControllerIP Intelligent Peripheral (in Intelligent Networking)
Internet Protocol (in packet networking)IPDL Idle Period DownlinkISDN Integrated Services Digital NetworkISO International Organisation for StandardizationISUP ISDN User PartI-ISUP Australian Interconnect ISUP ITU International Telecommunication UnionITU-T ITU - Telecommunication Standardisation SectorIVR Intelligent Voice RecognitionIWF Inter-Working FunctionIXC Inter-Exchange CarrierLAC Location Area CodeLAN Local Area NetworkLATA Local Access and Transit AreaLCS Location ServicesLEC Local Exchange CarrierLIU7 Link Interface Unit for CCS7 connectivityLNP Local Number Portability (a service used in PCS-1900 networks)LPP Link Peripheral ProcessorLRD Location Related DataLRN Location Routing NumberMAP Mobile Application PartMCC Mobile Country CodeMGW Media GatewayMLC Mobile Location CentreMMI Man Machine Interface
GSM/UMTS MSC Billing and Accounting Specification Q272-1NSS18 Standard APP 4.9Page: xiv (Approved) 30th March 2005
MNC Mobile Network CodeMNP Mobile Number PortabilityMOC Mobile Originated CallMO-LR/MOLRMobile Originated Location RequestMRP Multiple Rate PlanMSC Mobile Services Switching CentreMSC/SSP MSC Service Switching PointMSISDN Mobile Station International ISDN NumberMSRN Mobile Station Roaming NumberMTC Mobile Terminated CallMT-LR/MTLRMobile Terminated Location RequestMTUP Mobile Telephone User Part (used to be CTUP - Chinese Telephone User Part)NANP North American Numbering PlanNCOS Network Class of ServiceNDUB Network Determined User BusyNE Network ElementNEF Network Element FunctionNI-LR/NILR Network Initiated Location RequestNIRR Negotiation of Intermediate Rate RequestedNOA Nature of AddressNPA Numbering Plan AreaNPDB Number Portability DatabaseNPI Numbering Plan IndicatorNQI Number Qualifier IndicatorNSEP National Security Emergency Preparedness NSS Network Sub System NTP The ANSI ISUP Network Transport Parameter (carried in IAM and ACM)OACSU Off Air Call Set UpOMC Operations and Maintenance CentreOR Optimal RoutingOS Operations SystemOSF Operations System FunctionOTDOA Observed Time Difference Of ArrivalPAD Packet Assembly/DisassemblyPCS Personal Communications SystemPET PCS-1900 Equal-Access Trunk
Q272-1 GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 Standard NSS1830th March 2005 (Approved) Page: xv
PET MF PET Multi-Frequency TrunkPET7 PET CCS7 (ISUP) TrunkPLMN Public Land Mobile NetworkPRI Primary Rate InterfacePRN The MAP ProvideRoamingNumber messagePSAP Public Safety Answering PointPSL Provide Subscriber LocationPSPDN Packet switched public data networkPSTN Public Switched Telephone NetworkRLT Release Link TrunkRNC Radio Network ControllerRTT Round Trip TimeSAC Service Area CodeSAI Service Area IdentifierSBA Supernode Billing ApplicationSBS Supernode Billing ServerSCF Service Control Function (IN)SCP Service Control Point (IN)SDM Supernode Data ManagerSLR Subscriber Location RequestSMB Supernode Multi-computing BaseSMLC Serving Mobile Location CentreSMS Short Message ServiceSMS-SC SMS Service CentreSOC Software Optionality ControlSRI The MAP Send Routing Information messageSS Supplementary ServiceSSA Supplementary Service ActionSSF Service Switching Function (IN)SSP Service Switching Point (IN)TACC Tariff Administration Change ControlTCAP Transaction Capabilities Application PartTDOA Time-Difference-Of-ArrivalTDP Trigger Detection PointTMN Telecommunications Management NetworkTMSI Temporary Mobile Subscriber Identity
GSM/UMTS MSC Billing and Accounting Specification Q272-1NSS18 Standard APP 4.9Page: xvi (Approved) 30th March 2005
TON Type of NumberTS Technical SpecificationTUP Telephone User PartUDI Unrestricted Digital Information UE User EquipmentUMTS Universal Mobile Telephony SystemUSSD Unstructured Supplementary Service DataUTC Coordinated Universal TimeUXLA Universal TranslationsVAS Value Added ServiceVBS Voice Broadcast Service (for GSM-R)VGCS Voice Group Call Service (for GSM-R)VLR Visitor Location RegisterVMCDB Voice mail call dropbackVMSC Visited MSCVoATM Voice over Asynchronous Transfer ModeVoIP Voice over Internet ProtocolVPLMN Visited PLMNWPS Wireless Priority ServiceXCLI See CLI
Q272-1 Standard GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 NSS1830th March 2005 (Approved) Page: xvii
Table of Contents
About this Specification................................................................................................................... viiRelease Information ......................................................................................................................... viiScope................................................................................................................................................ viiStructure.......................................................................................................................................... viiiDocumentation Conventions........................................................................................................... viiiReferences and Sample Information............................................................................................... viiiAbbreviations......................................................................................................................................x
Part AIntroduction
A1 Overview of MSC and Billing Requirements...............................................................................3A1.1 Introduction to the GSM/UMTS MSC .............................................................................3A1.2 Requirements in GSM/UMTS Standards .........................................................................4A1.3 MSC’s Support of Requirements ......................................................................................5A1.4 MSC Configuration...........................................................................................................5
A2 Billing and Accounting Features ..................................................................................................7A2.1 Billing Feature Development............................................................................................7
A2.1.1 NSS18 Feature Development................................................................................7A2.1.2 NSS17 Feature Development..............................................................................12A2.1.3 NSS18 Market-Specific Features........................................................................17A2.1.4 NSS17 Market-Specific Features........................................................................18A2.1.5 NSS18 Change Request (CR) Updates ...............................................................19A2.1.6 NSS17 Change Request (CR) Updates ...............................................................21
A2.2 Other Changes.................................................................................................................22A2.2.1 Other Changes Made in this Release ..................................................................22A2.2.2 Other Changes Made in NSS17 ..........................................................................24
A2.3 List of Changed Pages ....................................................................................................26A2.3.1 Changed Pages in NSS18 ...................................................................................26A2.3.2 Changed Pages in NSS17 ...................................................................................30
A2.4 Feature Information ........................................................................................................33A2.4.1 UMTS and GSM Features ..................................................................................33A2.4.2 GSM Railways (GSM-R) Features .....................................................................39
GSM/UMTS MSC Billing and Accounting Specification Standard Q272-1NSS18 APP 4.9Page: xviii (Approved) 30th March 2005
Part BBilling Records and Formats
B1 Introduction.................................................................................................................................43B1.1 Overview of Billing Requirements .................................................................................43B1.2 MSC Billing System .......................................................................................................44
B1.2.1 Overview.............................................................................................................44B1.2.2 Storage Capacity of the Billing Platforms ..........................................................47
B2 Billing Files and CDRs ...............................................................................................................49B2.1 Production of the Billing File .........................................................................................49B2.2 Format of the Billing File on Disk..................................................................................50
B2.2.1 File Format..........................................................................................................50B2.2.2 Production of Auxiliary Records ........................................................................52
B2.3 Digital Audio Tape (DAT) Formats for the SDM ..........................................................52B2.4 Sample Billing Information ............................................................................................52B2.5 File Naming Conventions ...............................................................................................53
B2.5.1 Conventions used by the SBA Management Function .......................................53B2.5.2 Conventions used by the DRM Management Function......................................53
B2.6 The MSC CDR Structure ................................................................................................54
B3 Production of Call Detail Records ..............................................................................................57B3.1 General............................................................................................................................57B3.2 Use of Supplementary Services ......................................................................................58
B3.2.1 CISS Actions.......................................................................................................58B3.2.2 Call Related SS Actions......................................................................................58B3.2.3 Use of Call Forwarding.......................................................................................58B3.2.4 Use of the Call Hold Service ..............................................................................59B3.2.5 Use of the Multiparty Service .............................................................................59
B3.3 Inter MSC Handover.......................................................................................................60B3.4 Generation of Partial Records.........................................................................................60
B3.4.1 Overview.............................................................................................................60B3.4.2 General Information on Partial Records .............................................................61B3.4.3 Partial Record Production - Exceeding of Record Size Limitation ....................62B3.4.4 Partial Record Production - Expiry of the Partial Record Timer........................62B3.4.5 Partial Record Production - Call Re-establishment ............................................63
B3.5 Hot Billing ......................................................................................................................64B3.6 Proprietary Billing Services............................................................................................66
B3.6.1 Distance Based Billing........................................................................................66B3.6.2 Call Record Type Indication...............................................................................66
B3.7 Call Release Cause Reporting.........................................................................................66B3.8 Controlling the Information that the MSC Generates.....................................................69
B3.8.1 Office Parameters and Table Datafill .................................................................69B3.8.2 Software Optionality Control (SOC) ..................................................................74B3.8.3 Office Alarms for Billing....................................................................................76
Q272-1 Standard GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 NSS1830th March 2005 (Approved) Page: xix
B4 Structured Records and Modules ................................................................................................77B4.1 Structured Record Contents ............................................................................................77
B4.1.1 Mobile Originated Call Attempt .........................................................................78B4.1.2 Mobile Terminated Call Attempt .......................................................................79B4.1.3 Roaming Call Attempt .......................................................................................80B4.1.4 Incoming Gateway Call Attempt .......................................................................81B4.1.5 Outgoing Gateway Call Attempt .......................................................................82B4.1.6 Transit Call Attempt ..........................................................................................83B4.1.7 Short Message Service, Mobile Originated .......................................................84B4.1.8 Short Message Service, Mobile Terminated ......................................................85B4.1.9 Incoming Intra-PLMN Trunk Record ................................................................86B4.1.10 Outgoing Intra-PLMN Trunk Record ................................................................87B4.1.11 Common Equipment Usage Record ..................................................................88B4.1.12 Supplementary Service Action Record ..............................................................89B4.1.13 Location Services (LCS) Record .......................................................................91B4.1.14 Acknowledgement Record .................................................................................92B4.1.15 Location Update Record ....................................................................................93B4.1.16 Time Change Record .........................................................................................94B4.1.17 Switch Restart Record .......................................................................................94B4.1.18 Billing Block Header Record .............................................................................95B4.1.19 Billing File Transfer In Record ..........................................................................95B4.1.20 Billing File Transfer Out Record .......................................................................96
B4.2 Module Contents.............................................................................................................97B4.2.1 End of Module List Module................................................................................98B4.2.2 Bearer Service Information Module ..................................................................98B4.2.3 Location and Channel Information Module .......................................................99B4.2.4 Supplementary Services Information Module .................................................101B4.2.5 Teleservices Information Module ....................................................................108B4.2.6 AoC Parameter Information Module ...............................................................109B4.2.7 Tariff Class Information Module ......................................................................110B4.2.8 Data Service Information Module ...................................................................110B4.2.9 Other Agent Information ..................................................................................112B4.2.10 Location Only Information Module..................................................................112B4.2.11 Equal Access Information Module ..................................................................113B4.2.12 Partial Information Module ..............................................................................114B4.2.13 Trunk Usage Information Module ....................................................................114B4.2.14 IN Information Module ....................................................................................115B4.2.15 IN Charging Information Module (CS-1R INAP Services) .............................118B4.2.16 Generic Address Information Module .............................................................119B4.2.17 Network Call Reference Information Module .................................................120B4.2.18 CAMEL Charging Information Module ..........................................................121B4.2.19 Mobile Number Portability Information Module .............................................122B4.2.20 GSM Assisting SSP (ASSP) Information Module ...........................................123B4.2.21 CAMEL Short Message Service (SMS) Information Module..........................124B4.2.22 Patching Information Module ..........................................................................125B4.2.23 Bearer Independent Core Network Information Module .................................126
GSM/UMTS MSC Billing and Accounting Specification Standard Q272-1NSS18 APP 4.9Page: xx (Approved) 30th March 2005
B4.3 Market Specific Modules..............................................................................................127B4.3.1 Originator-Terminator Information Module ....................................................127B4.3.2 Toll Free Information Module .........................................................................128B4.3.3 Local Number Portability (LNP) Information Module ....................................128B4.3.4 Singapore Specific Information Module...........................................................129B4.3.5 Carrier Selection Charging Information Module .............................................130
B5 Data Field Descriptions ............................................................................................................131B5.1 Overview.......................................................................................................................131B5.2 Data Fields ....................................................................................................................132
B5.2.1 Access Media Type ...........................................................................................139B5.2.2 Access Network ................................................................................................140B5.2.3 Additional Information .....................................................................................140B5.2.4 Advice of Charge Parameter Reason ................................................................141B5.2.5 Age of Location Information ............................................................................141B5.2.6 Answer Time.....................................................................................................141B5.2.7 Auxiliary Record Header ..................................................................................142B5.2.8 Backbone Media Type ......................................................................................142B5.2.9 BCD or Full Hex String ....................................................................................143B5.2.10 BCD or Hex String(N) ......................................................................................143B5.2.11 Bearer Service...................................................................................................144B5.2.12 Block Count ......................................................................................................144B5.2.13 Block Number...................................................................................................144B5.2.14 Boolean Type....................................................................................................145B5.2.15 Call Duration.....................................................................................................145B5.2.16 Call Forward Indicator......................................................................................146B5.2.17 Call Indicator ....................................................................................................147B5.2.18 Call Reference...................................................................................................148B5.2.19 Call Type Code .................................................................................................148B5.2.20 Called Equipment (or Served Equipment)........................................................149B5.2.21 Called Number (or Served Number).................................................................149
B5.2.21.1 Mobile Originated Record .....................................................................150B5.2.21.2 Mobile Terminated Record ....................................................................150B5.2.21.3 Roaming Record ....................................................................................150B5.2.21.4 Incoming (Gateway/Intra-PLMN) Trunk and Outgoing (Gateway/Intra-
PLMN/Transit) Trunk Record ...............................................................150B5.2.21.5 Short Message Service – Mobile Terminated Record ...........................151B5.2.21.6 Determination of the Nature of Address (NOA)....................................151B5.2.21.7 Short Message Service - Mobile Originated Record (SMS-MO) ..........151
B5.2.22 Called Party (or Served Party) ..........................................................................152B5.2.23 Called Subscriber Category ..............................................................................152B5.2.24 Calling Equipment (or Served Equipment) ......................................................153B5.2.25 Calling Number (or Served Number) ...............................................................154B5.2.26 Calling Party (or Served Party).........................................................................157B5.2.27 Calling Subscriber Category.............................................................................157B5.2.28 Carrier Connect Timestamp..............................................................................157
Q272-1 Standard GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 NSS1830th March 2005 (Approved) Page: xxi
B5.2.29 Cause for Termination ......................................................................................158B5.2.30 Cell-SAC Id ......................................................................................................158B5.2.31 Channel Allocation Time..................................................................................159B5.2.32 Channel Description .........................................................................................159B5.2.33 Channel Type....................................................................................................159B5.2.34 Charge Number.................................................................................................161B5.2.35 Charge Zone......................................................................................................161B5.2.36 Classmark Time Stamp.....................................................................................161B5.2.37 Connection Element..........................................................................................162B5.2.38 Correlation ID ...................................................................................................162B5.2.39 Correlation ID / ETC Parm2.............................................................................163B5.2.40 Counter..............................................................................................................163B5.2.41 CSI (CAMEL Subscription Information) .........................................................164B5.2.42 Data Compression.............................................................................................165B5.2.43 Data Rate...........................................................................................................166B5.2.44 Data Volume .....................................................................................................167B5.2.45 Date and Time...................................................................................................167B5.2.46 Default SMS Handling Applied (DSH Applied) ..............................................170B5.2.47 Default SMS Handling Indicator (DSH Indicator) ...........................................170B5.2.48 Delivery Timestamp .........................................................................................171B5.2.49 Destination Routing Address ............................................................................171B5.2.50 Detection Point .................................................................................................172B5.2.51 Diagnostic .........................................................................................................173
B5.2.51.1 Signalling Agents with Error Codes used for Diagnostic ......................174B5.2.51.2 Signalling Agents and Required Mappings ...........................................178
B5.2.52 Dialled Digits ....................................................................................................180B5.2.53 Disconnect Time ...............................................................................................181B5.2.54 E Parameter.......................................................................................................181B5.2.55 Emergency Service Routing Digits (ESRD).....................................................182B5.2.56 Emergency Service Routing Key (ESRK)........................................................182B5.2.57 Equipment Identity ...........................................................................................183B5.2.58 Equipment Type................................................................................................183B5.2.59 FCI Freeform Parameter ...................................................................................183B5.2.60 File Sequence Number......................................................................................184B5.2.61 File Transfer Type ............................................................................................184B5.2.62 Free Format Data ..............................................................................................185B5.2.63 Functional Number ...........................................................................................186B5.2.64 Geographical Location of UE 1 ........................................................................186B5.2.65 Geographical Location of UE 2 ........................................................................187B5.2.66 Geographical Location of UE 3 ........................................................................187B5.2.67 Geographical Location of UE 4 ........................................................................188B5.2.68 Geographical Location of UE 5 ........................................................................188B5.2.69 Group Call Reference .......................................................................................189B5.2.70 Half Rate in Use................................................................................................189B5.2.71 Hexadecimal Identity ........................................................................................190B5.2.72 Hot Billing Indicator .........................................................................................190
GSM/UMTS MSC Billing and Accounting Specification Standard Q272-1NSS18 APP 4.9Page: xxii (Approved) 30th March 2005
B5.2.73 IN Call Reference Number ...............................................................................191B5.2.74 IN Dialogue Result ...........................................................................................191B5.2.75 IN Protocol........................................................................................................191B5.2.76 IN Time Stamp1................................................................................................192B5.2.77 IN Time Stamp2................................................................................................192B5.2.78 Incoming/Outgoing Metering Class..................................................................193B5.2.79 Incoming/Outgoing Route Group .....................................................................193B5.2.80 Incoming/Outgoing Trunk Release Time .........................................................194B5.2.81 Incoming/Outgoing Trunk Seizure Time..........................................................194B5.2.82 Incoming Trunk Group .....................................................................................195B5.2.83 Incoming Trunk Member..................................................................................195B5.2.84 Information Transfer Capability .......................................................................195B5.2.85 Inter-Exchange/International Carrier (IC/INC) Call Event Status ...................196B5.2.86 Inter-Exchange/International Carrier (IC/INC) Prefix .....................................197B5.2.87 Interworking Function Trunk Group ................................................................197B5.2.88 Interworking Function Trunk Member .............................................................197B5.2.89 IP Address Identity ...........................................................................................198B5.2.90 IP Routing Address ...........................................................................................198B5.2.91 IP SSP Capability..............................................................................................199B5.2.92 IWF Activation Timestamp ..............................................................................199B5.2.93 IWF Diagnostic Code .......................................................................................200B5.2.94 LCS Client Identity ...........................................................................................200B5.2.95 LCS Client Type ...............................................................................................201B5.2.96 LCS Diagnostic.................................................................................................201B5.2.97 LCS Initiation Time ..........................................................................................202B5.2.98 LCS Priority Level............................................................................................202B5.2.99 LCS Record Type..............................................................................................203B5.2.100 LCS Result ........................................................................................................203B5.2.101 LCS Termination Time.....................................................................................204B5.2.102 Local Reference Number ..................................................................................205B5.2.103 Location Area Code ..........................................................................................205B5.2.104 Logical Network ...............................................................................................206B5.2.105 Message Reference ...........................................................................................206B5.2.106 Metering Zone...................................................................................................206B5.2.107 MGW (Media Gateway) Number .....................................................................207B5.2.108 MGW Seizure Time ..........................................................................................207B5.2.109 MM (Mobility Management) Event .................................................................208B5.2.110 Module Code.....................................................................................................208B5.2.111 MS Classmark...................................................................................................209B5.2.112 MSC Address ....................................................................................................211B5.2.113 MSC ID.............................................................................................................211B5.2.114 MSC Number ....................................................................................................212B5.2.115 MSC/MGW Number.........................................................................................212B5.2.116 Network Call Reference Number .....................................................................213B5.2.117 New AN (Access Network) ..............................................................................213B5.2.118 New Cell-SAC Id..............................................................................................214
Q272-1 Standard GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 NSS1830th March 2005 (Approved) Page: xxiii
B5.2.119 New LAC (Location Area Code)......................................................................214B5.2.120 New MSC Id .....................................................................................................215B5.2.121 Number of Fax Pages........................................................................................215B5.2.122 Number Type ....................................................................................................215B5.2.123 Numbering Plan Identifier ................................................................................216B5.2.124 Off Air Call Setup.............................................................................................216B5.2.125 Off-Board IN Service Identifier........................................................................217B5.2.126 Off-Board IN Service Indicator ........................................................................217B5.2.127 Old AN (Access Network)................................................................................218B5.2.128 Old Cell-SAC Id ...............................................................................................218B5.2.129 Old LAC (Location Area Code) .......................................................................218B5.2.130 Old MSC Id.......................................................................................................219B5.2.131 Operation History .............................................................................................219B5.2.132 Operation Indication .........................................................................................220B5.2.133 Original Calling Number ..................................................................................221B5.2.134 Outgoing Trunk Group .....................................................................................222B5.2.135 Outgoing Trunk Member ..................................................................................222B5.2.136 Partial Record Event Code................................................................................222B5.2.137 Partial Record Reason.......................................................................................223B5.2.138 Partial Record Reference Number ....................................................................223B5.2.139 Partial Record Sequence Number .....................................................................223B5.2.140 Party To Charge ................................................................................................224B5.2.141 Patch Identity ....................................................................................................224B5.2.142 Ported Status .....................................................................................................224B5.2.143 Positioning Data................................................................................................225B5.2.144 Pre-Translated Called Party Number ................................................................226B5.2.145 Priority Call Cause............................................................................................226B5.2.146 Priority Call Duration .......................................................................................227B5.2.147 Priority Call Tag ...............................................................................................227B5.2.148 Priority Level ....................................................................................................228B5.2.149 Priority Release Time .......................................................................................228B5.2.150 Privacy Notification..........................................................................................229B5.2.151 Privacy Override ...............................................................................................229B5.2.152 Query Method ...................................................................................................230B5.2.153 Rate Adaptation ................................................................................................230B5.2.154 Record Count ....................................................................................................231B5.2.155 Record Header ..................................................................................................231B5.2.156 Record Number.................................................................................................232B5.2.157 Record Time .....................................................................................................232B5.2.158 Recording Entity ...............................................................................................233B5.2.159 Recording Office Identity .................................................................................233B5.2.160 Recording Office Type / Sensor Type ..............................................................233B5.2.161 Release Id..........................................................................................................234B5.2.162 Release Time.....................................................................................................234B5.2.163 Requested QoS..................................................................................................234B5.2.164 Requesting Mobile Location Centre (MLC).....................................................235
GSM/UMTS MSC Billing and Accounting Specification Standard Q272-1NSS18 APP 4.9Page: xxiv (Approved) 30th March 2005
B5.2.165 Result Indicator.................................................................................................235B5.2.166 RNC ID .............................................................................................................237B5.2.167 Roaming Number..............................................................................................237B5.2.168 Routing Number ...............................................................................................237B5.2.169 SCF ID ..............................................................................................................238B5.2.170 SCF ID / ETC Parm1 ........................................................................................238B5.2.171 SCP Address .....................................................................................................239B5.2.172 Sensor Identity ..................................................................................................240B5.2.173 Served IMEI......................................................................................................240B5.2.174 Served IMSI ......................................................................................................240B5.2.175 Served MSISDN ...............................................................................................241B5.2.176 Served Party ......................................................................................................241B5.2.177 Service Centre...................................................................................................241B5.2.178 Service Key.......................................................................................................242B5.2.179 SMS Message Type ..........................................................................................243B5.2.180 SMS Release Cause Value................................................................................244B5.2.181 SMS Result .......................................................................................................245B5.2.182 SMS Start Time ................................................................................................245B5.2.183 SMS Stop Time.................................................................................................245B5.2.184 SMS Timestamp ...............................................................................................246B5.2.185 SMS Validity Period.........................................................................................246B5.2.186 Structure Code ..................................................................................................246B5.2.187 Study Indicator..................................................................................................247B5.2.188 Subscriber Service ............................................................................................248B5.2.189 Supplementary Service Action .........................................................................249B5.2.190 Supplementary Service Code............................................................................249B5.2.191 Supplementary Service Parameters ..................................................................251B5.2.192 System Type......................................................................................................251B5.2.193 Switch Restart Type..........................................................................................251B5.2.194 Tariff Class .......................................................................................................252B5.2.195 Teleservice ........................................................................................................252B5.2.196 Terminating Location .......................................................................................254B5.2.197 Trunk Usage Reason .........................................................................................254B5.2.198 Type of Carrier Identification Code (CIC) .......................................................254B5.2.199 Unused Number 1 .............................................................................................255B5.2.200 Unused Number 2 .............................................................................................255B5.2.201 Unused Timestamp 1 ........................................................................................256B5.2.202 Unused Timestamp 2 ........................................................................................256B5.2.203 Update Result....................................................................................................256B5.2.204 Update Time .....................................................................................................257
Q272-1 Standard GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 NSS1830th March 2005 (Approved) Page: xxv
B5.3 PCS 1900 Fields............................................................................................................258B5.3.1 Automatic Number Identification Indicator .....................................................258B5.3.2 Called Party Off-Hook Indicator ......................................................................259B5.3.3 Charge Number/Automatic Number Identification (ANI) ...............................260B5.3.4 Generic Address Parameter ..............................................................................260B5.3.5 Inter-exchange/International Carrier (IC/INC) Routing Indicator....................261B5.3.6 LATA................................................................................................................262B5.3.7 Location ............................................................................................................262B5.3.8 Location Routing Number (LRN).....................................................................262B5.3.9 Module Code (PCS 1900 Market-Specific)......................................................263B5.3.10 Originating Line Information/II Parameter.......................................................263B5.3.11 Originating Numbering Plan Area (and Area Code) ........................................264B5.3.12 Overseas Indicator ............................................................................................264B5.3.13 Party Identifier ..................................................................................................265B5.3.14 SCP Determined Terminated Number ..............................................................265B5.3.15 Service Feature Code ........................................................................................266B5.3.16 Service Provider Identity ..................................................................................266B5.3.17 Supporting Information.....................................................................................266B5.3.18 Terminating Numbering Plan Area...................................................................267B5.3.19 Toll Free Call Type Code .................................................................................268
B5.4 Singapore Specific Fields .............................................................................................268B5.4.1 Calling Party Category......................................................................................268B5.4.2 City Wide Centrex ............................................................................................269B5.4.3 Module Code.....................................................................................................269B5.4.4 National / International Indicator......................................................................270B5.4.5 Other Subscriber CUSTGRP ............................................................................270B5.4.6 Other Subscriber NCOS....................................................................................270B5.4.7 XCLI Indicator..................................................................................................271
B5.5 German and Austrian Market-Specific Fields ..............................................................271B5.5.1 Default Carrier Identification Code (CIC)........................................................271
B5.5.1.1 German Market Default Carrier CICs ...................................................272B5.5.1.2 Austrian Market Default Carrier CICs ..................................................272
B5.5.2 Module Code.....................................................................................................272B5.5.3 Selected Carrier Identification Code (CIC) ......................................................273
B5.5.3.1 German Market Selected CICs ..............................................................273B5.5.3.2 Austrian Market Selected CICs..............................................................273
B5.5.4 Subscriber Customer Group..............................................................................274
B6 Example Call Scenarios ............................................................................................................275B6.1 Mobile to Land (Outgoing) Call ...................................................................................276B6.2 Partial Billing in a Mobile to Land (Outgoing) Call.....................................................277B6.3 Land to Mobile (Incoming) Call ...................................................................................278B6.4 Mobile to Mobile Call Within the Same Network........................................................278B6.5 Calls Involving Roaming Mobile Subscribers..............................................................280
B6.5.1 Call Made by the Roaming Subscriber to Another Mobile Subscriber ............280B6.5.2 Incoming Call to a Roaming Subscriber...........................................................281
GSM/UMTS MSC Billing and Accounting Specification Standard Q272-1NSS18 APP 4.9Page: xxvi (Approved) 30th March 2005
B6.6 Incoming Call to a PLMN Service Center....................................................................282B6.7 Call Forwarding ............................................................................................................283
B6.7.1 Example Call Forwarding Scenario ..................................................................283B6.7.2 Location Information and Call Forwarding Records ........................................284
B6.8 Delivery and Origination of Short Messages................................................................285B6.8.1 Delivery of a Mobile Terminated Short Message.............................................285B6.8.2 Origination of a Short Message ........................................................................286
B6.9 Call Hold and Multi-party Services ..............................................................................287B6.10 Explicit Call Transfer Service.......................................................................................288B6.11 Redirection and Call Dropback Services ......................................................................290
B6.11.1 Voice Mail Call Dropback................................................................................290B6.11.2 The Nortel ETSI ISUP Call Re-Origination Service ........................................292B6.11.3 The Network Optimisation of Trombone Connections ....................................293
B6.12 Handover.......................................................................................................................294B6.13 Local Number Portability .............................................................................................296B6.14 Extension Services ........................................................................................................298B6.15 Intelligent Network (IN) Scenarios...............................................................................299
B6.15.1 IN Nodes and Signalling...................................................................................300B6.15.2 Mobile Originated IN Billing ...........................................................................301
B6.15.2.1 CAMEL MO Billing ..............................................................................302B6.15.2.2 CS1-R MO Billing .................................................................................302
B6.15.3 Mobile Terminated IN Billing ..........................................................................302B6.15.3.1 CAMEL MT Billing...............................................................................303B6.15.3.2 CS1-R MT Billing..................................................................................304
B6.15.4 Mobile Forwarding IN Billing ..........................................................................304B6.15.4.1 CAMEL MF Billing...............................................................................305B6.15.4.2 CS1-R MF Billing..................................................................................306
B6.15.5 Proprietary Off-Board IN Services ...................................................................306B6.16 CAMEL Mobility Management Service.......................................................................307B6.17 Call Independent Supplementary Service Action .........................................................307B6.18 Invoking the Billing Zone Query Service Using USSD ...............................................308B6.19 Optimal Routing of a Late Forwarded Call ..................................................................309B6.20 Mobile Number Portability (MNP)...............................................................................311B6.21 Location Services (LCS)...............................................................................................314
B6.21.1 3GPP Release 99 Messaging ............................................................................314B6.21.2 3GPP Release 4 Messaging ..............................................................................315
B6.22 GSM-R Call Scenarios..................................................................................................316B6.22.1 Enhanced Multi-level Precedence And Pre-emption Service (eMLPP) Call ...316
B6.22.1.1 Called Party Pre-emption .......................................................................316B6.22.1.2 Resource Pre-emption ............................................................................318
B6.22.2 Voice Group and Broadcast Calls.....................................................................319B6.22.2.1 Mobile Dispatcher Group Call ...............................................................319B6.22.2.2 Service Subscriber Group Call...............................................................320
B6.22.3 Functional Addressing ......................................................................................321B6.23 Market-Specific Call Scenarios ....................................................................................322
B6.23.1 Chinese Market CAMEL Phase 2 Service Billing............................................322
Q272-1 Standard GSM/UMTS MSC Billing and Accounting SpecificationAPP 4.9 NSS1830th March 2005 (Approved) Page: xxvii
Part CTariff Administration
C1 Introduction...............................................................................................................................327C1.1 Overview.......................................................................................................................327C1.2 Defining Service Areas Covered by the Tariff System ................................................327C1.3 The Tariff System .........................................................................................................328C1.4 Tariffing for the Advice of Charge (AoC) Service.......................................................330C1.5 Tariff Administration Change Control (TACC) ...........................................................333
C2 Tariff System Functions............................................................................................................335C2.1 Tariff Switching Pattern Functions...............................................................................335
C2.1.1 Charging Calendar ............................................................................................335C2.1.2 Day Class ..........................................................................................................335C2.1.3 Tariff Switch Pattern.........................................................................................335
C2.2 Advice of Charge Tariff Functions ...............................................................................336C2.2.1 AoC Service (or Subscriber Service)................................................................336C2.2.2 Charging Destination ........................................................................................336C2.2.3 Charging Origin ................................................................................................336C2.2.4 Charging Zone ..................................................................................................337C2.2.5 Tariff (AoC) ......................................................................................................337C2.2.6 Tariff Class .......................................................................................................337
C2.3 Tariff Administration....................................................................................................338C2.3.1 Administration and Control ..............................................................................338C2.3.2 Tariff System ....................................................................................................338
C3 Advice of Charge for Multiple Rate Plans................................................................................341C3.1 Introduction...................................................................................................................341C3.2 Setting Up AoC with Multiple Rate Plans....................................................................341
C3.2.1 Software Optionality Control (SOC) ................................................................341C3.2.2 Provisioning in the HLR and MSC...................................................................342
C3.3 AoC and MRP Data Tables ..........................................................................................343C3.3.1 AoC and MRP Tables for Intra-PLMN Calls ...................................................343C3.3.2 AoC and MRP For Roaming Subscribers.........................................................344
C3.4 Examples of AoC and Multiple Rate Plans (MRPs).....................................................344C3.4.1 Intra-PLMN AoC MRPs...................................................................................344C3.4.2 Support of AoC with MRPs for Inter-PLMN Roaming....................................345
C3.4.2.1 Mobile Originating Call with Inter-PLMN Roaming ............................345C3.4.2.2 Mobile Terminating call with Inter-PLMN Roaming ............................346
Part DFrequently Asked Questions
D1 Enabling and Shutting Down the Hot Billing Stream...............................................................349
GSM/UMTS MSC Billing and Accounting Specification Standard Q272-1NSS18 APP 4.9Page: xxviii (Approved) 30th March 2005
NSS18 Billing and Accounting
Part A:Introduction
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (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 and A1.3 give an overview of billing, tariff and accounting functions defined in the GSM/UMTS standards and the MSC’s 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
The GSM/UMTS MSC is based on Nortel's Global System for Mobile Communications (GSM) Digital Mobile System (DMS) platform. This platform 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 the 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
BSCBTS
BTS
BSCBTS
BTS
Node B
MSC
GSM radio
GSM or UMTScore network
RNCNode B
Access to 2nd Generation (2G) GSM services
Access to GSM Railways services using GSM (2G) radio access
Access to 3rd Generation (3G) UMTS services
access
GSM radio access
UMTS radio access
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 4 (Approved) 30th March 2005
In the 3GPP Release 4 network architecture, the MSC server handles call processing and signalling and the Media Gateway provides the bearer connections for the call. This is summarised in Figure 2.
Figure 2 3GPP Release 4 Network
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.
Throughout this document, the term MSC is used for both the MSC and the MSC server.
A1.2 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.
Node B
GSM or UMTScore network
RNCNode B
GSM radio access
UMTS radio access
MSC Server
MediaGateway
BSCBTS
BTS
MediaGateway
3rd Generation (3G) access
MSC Server2nd Generation (2G) access
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 5
3GPP TS 32.200 specifies the requirements for billing and accounting procedures 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 MSC’s 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) either on the Core and Billing Manager (CBM) platform or the SuperNode Data Manager (SDM) 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 ISO standard protocol File Transfer, Access and Management (FTAM) interface and the file transfer protocol (FTP) interface.
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.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 6 (Approved) 30th March 2005
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 7
A2 Billing and Accounting Features
This section gives a brief description of the NSS18 developments which have an impact on the billing functions of the MSC.
A2.1 Billing Feature Development
NSS17 was a limited customer release and so some NSS18 customers may be upgrading from an NSS16 MSC. This section contains details of the NSS18 and NSS17 features which change billing information.
A2.1.1 NSS18 Feature Development
A00004084 Location Based Services Enhancements
This feature provides enhanced support for the 3GPP Release 99 and Release 4 Location Service (LCS). It extends the capabilities for mobile originated and terminated location services (MO-LR and MT-LR) and now supports network initiated location services (NI-LR).
To capture billing information there are new fields in the Location Services (LCS) record (B4.1.13 on page 91). The office parameters LCS_BILLING_IN_EMER_ CALLS and LCS_RELEASE (B3.8.1 on page 69) control LCS. The former determines whether or not the LCS record is generated for emergency calls. The latter determines whether Release 4 or Release 99 LCS information is generated.
Impact This feature impacts all customers who implement Location Services (LCS).
A00004142 MSC Support of BICN UMTS
This feature provides support for the 3GPP Release 4 network in which the MSC call server which provides call control is physically separated from the Media Gateway which provides bearer connections. In order to capture billing information the Location and Channel information module (B4.2.3 on page 99) contains the new RNC Id (Radio Network Controller Id) field (B5.2.166 on page 237).
Impact This feature impacts all customers.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 8 (Approved) 30th March 2005
A00004147 MC09 Billing Enhancement
This feature allows operators to capture information about the use of 64 kbits/s channels at points of network interconnection. In networks which use ITU-T ISUP or ETSI PRI, the call setup messages carry sufficient information to distinguish between different services carried in 64kbits/s channels. To capture the billing information, trunk records can now have a Data Service information module (B4.2.8 on page 110) appended to them. For a mobile originated service, the module is appended to an outgoing trunk record. For a mobile terminated service, the module is appended to an incoming trunk record. The term trunk records means any of the following records: the roaming record the incoming/outgoing gateway and the incoming/outgoing intra-PLMN records.
Impact This feature impacts customers who implement multimedia data services.
A00004164 Advice of Charge Multiple Rate Plans Enhancements
This feature provides operators with the ability to define multiple rate plans (MRPs) for their subscribers and to use them with the Advice of Charge (AoC) service. The MRPs work with both AoCC (AoC charging where the subscriber is charged in real-time) and with AoCI (AoC information where the mobile handset is sent charging data from which it calculates an estimate of the call charges).
In order to provide the service, the operator must define a rate plan. This is done using two Nortel proprietary parameters Customer Group (CUSTGRP) and Network Class of Service (NCOS). Combinations of these two parameters define the different rate plans which the operator then assigns to subscribers individually. The rate plan information provides extra keys into the tariff system and are used with the tariff information to derive the appropriate charging information to send to the mobile handset. There is a new tariff system table called TARAOC2 which can use the new rate plan keys to derive the Charging Advice Information (CAI) elements which are sent to the handset. The new capabilities are described in C3.4 on page 344.
Impact This feature impacts customers who want to provide MRPs and use them with AoC.
A00004169 Call Forward Records Enhancement for Loc
This feature captures the location and channel information for a subscriber who forwards a call when he/she is found to be network determined user busy (NDUB) but not in an active state. In this case, party A calls party B who is NDUB and inactive and who as a result forwards the call to party C. The Mobile Terminated Call Forwarding Attempt record generated for party B (for the call from A to B) has a Location and Channel information module appended to it which provides information about party B’s location. This feature does not alter any records, modules or fields. This feature is controlled by the existing SOC GSM CF NDUB Bill Rec (B3.8.2 on page 74).
Impact This feature impacts customers who implement call forwarding on NDUB.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 9
A00004188 CAMEL enhancement
This feature provides a mechanism for the MSC to be able to interact with a standby Service Control Point (SCP) when the initial SCP is overloaded. In this way, CAMEL services can still be provided by the standby SCP rather than the service failing. To do this the Signalling Transfer Point (STP) between the MSC and initial SCP detects that the SCP is overloaded and redirects the call to the standby SCP. It then sends the response form. All further service requests to the SCP will be handled by the standby. The feature provides the SCP overload capability for all CAMEL, INAP and proprietary triggers except for the SS-CSI and M-CSI triggers.
The MSC looks at the address of the first message that it receives from the SCP. If the address is different, this indicates that the message has been sent by a standby SCP. In this case, the MSC overwrites the SCP address (B5.2.171 on page 239) in the IN information module (B4.2.14 on page 115) or CAMEL SMS information module (B4.2.21 on page 124) depending on the CAMEL service.
Impact This feature impacts customers who support CAMEL services.
A00004372 R4 MSC: CONF Service Alignment with MGW
This feature provides the support for conference services in a 3GPP Release 4 network. In this network, the MSC call server provides call control and the media gateways provide bearer connections. Conference-enabled media gateways provide conference circuits.
Billing information for the use of the conference facilities is captured in the Common Equipment Record (B4.1.11 on page 88). The Equipment Identity field (B5.2.57 on page 183) indicates whether the conference circuits were provided by an MSC or a conference-capable media gateway. The MSC/MGW Number field (B5.2.115 on page 212) identifies the MSC or media gateway providing the conference circuits. The MSC number is defined by the GSMMSC_Number office parameter in table OFCVAR and the MGW number is defined by the IPADDR field in the table GWINV (both described in B3.8.1 on page 69). An example call scenario shows the billing records which may be generated for a Release 4 conference call (B6.9 on page 287).
Impact This feature impacts all customers.
A00004373 R4 MSC: HO Service Alignment with MGW
This feature defines handover capabilities for the 3GPP Release 4 Bearer Independent Call Network (BICN). For billing purposes, this feature uses the capabilities of features A00004142 and A00004513 which respectively define extensions to the Location and Channel information module (B4.2.3 on page 99) and the new BICN information module (B4.2.23 on page 126).
Impact This feature impacts customers who provide services on a 3GPP Release 4 BICN.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 10 (Approved) 30th March 2005
A00004513 R4 Billing related enhancements
This feature defines the new Bearer Independent Core Network (BICN) information module (B4.2.23 on page 126) to capture billing information for calls using the 3GPP Release 4 BICN network architecture. In handover scenarios additional BICN information modules are appended to the appropriate call records.
Impact This feature impacts customers who operate a 3GPP Release 4 BICN.
A00004613 Advice of Charge for R2 and TUP
This feature allows operators to provide the Advice of Charge (AoC) service over R2 and Telephony User Part (TUP) trunks. Users are presented with an estimation of their call charges in real time using AoC. The billing information is captured in AoC Parameter information module(s) (B4.2.6 on page 109) appended to mobile originated or mobile terminated call attempt records (B4.1.1 on page 78 and B4.1.2 on page 79).
The feature does not change any billing records, fields or modules. It ensures that the destination id is calculated correctly for the service.
Impact This feature impacts customers who provide AoC over R2 and TUP trunks.
A00004614 Ringback Support for DP12 CAMEL P2 Connect Solution
This feature allows operators to provide customised ring tones to their subscribers, e.g. music clips. The service is a mobile terminated service which applies the ring tone heard by the calling party.
It is provided as a mobile terminating CAMEL Phase 2 service. During the set up of a call to called party, the CAMEL mobile terminated detection point DP12 is triggered. The Gateway MSC sends an InitialDP message to the SCP. The SCP sends a CAMEL Connect message in response which contains the Destination Routing Address (DRA) and Generic Number. The DRA gives the address of the called party so that the call can be completed to him/her. The Generic Address is the address of the Intelligent Peripheral / Intelligent Voice Response (IP/IVR) which plays the customised ring “tone” to the calling party while the called party is paged and connected. The service works in Release 99 networks and in the Release 4 Bearer Independent Core Networks (BICNs).
The billing information for the service is captured in two IN information modules (B4.2.14 on page 115) appended to the mobile terminated call attempt record (B4.1.2 on page 79) generated for the called party. One module contains the information obtained from the SCP in the Connect message. In this module the DRA field (B5.2.49 on page 171) contains the called party address. The other module contains information about the interaction with the IP/IVR. This module includes the new value of 6C in the operation indication field (B5.2.132 on page 220) for the new service and the DRA field contains the address of the IP/IVR.
Impact This feature impacts customers who provide the CAMEL Phase 2 customised ring back tone services to their customers.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 11
A00006555 MSC Subscriber Category Enhancement
This feature enhances the MSC to support subscription routing services based on the Subscriber Category/Calling Party Category (CPC). The CPC is set up in the Home Location Register (HLR) and transferred to the Visitor Location Register (VLR) in the MSC by means of the Category parameter in the Insert Subscriber Data (ISD) message. The CPC parameter is then used in the Universal Translations (UXLA) system for subscription based routing.This feature provides enhancements to the Calling Party Category (CPC) to support subscription based routing services such as a hot-line and Private Numbering Plan (PNP). The CPC is contained in the Category field of the MAP Insert Subscriber Data message sent from the HLR to the MSC. The feature also defines how the CPC is used in translations, in interworking scenarios and how it is passed to the SCP in originating and terminating intelligent networking (IN) scenarios. This is because some values are both subscriber categories and values reserved for national use. The new CPC values are captured in the Calling Subscriber Category field (Section B5.2.27 on page 157) in the Mobile Originated Call Attempt Record (Section B4.1.1 on page 78) and in the Called Subscriber Category field (Section B5.2.23 on page 152) in the Mobile Terminated Call Attempt Record (Section B4.1.2 on page 79). Impact This feature impacts customers who support subscription based routing.
A00007441 MC09 Billing Module Captured on CF leg for CSD Calls
This feature allows operators to capture the details of data services during call forwarding. In a call forwarding scenario, party A calls party B who forwards to party C. The billing for party B is captured in a Mobile Terminated Call Forwarding Attempt record (for the call from A to B) and in a Mobile Originated Call Forwarding Attempt record for the forwarded call leg to party C. These records now have a Data Service information module (B4.2.8 on page 110) appended to them to capture the service details. In this way the operator has all of the relevant charging information for the call.
Impact This feature impacts customers who provide circuit-switched data services.
A00007479 Calling party address (MSISDN) in MO CDR
This feature sets the Calling Number field (B5.2.25 on page 154) in the Mobile Originated Call Attempt record (B4.1.1 on page 78) to capture the MSISDN of the original calling party during call redirection. In this scenario, party A calls party B and the call is redirected to party C. The call triggers Intelligent Networking detection point 3 (IN DP3). The Service Control Point (SCP) returns the redirection information so that the call to party B is redirected to party C. The MSISDN of party A is captured in the Calling Number field of the Mobile Originated call record. The MSISDN of party B is captured in the Called Number field (B5.2.21 on page 149). The address of party C is captured in the Destination Routing Address field (B5.2.49 on page 171) in the appended IN information module (B4.2.14 on page 115).
(continued)
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 12 (Approved) 30th March 2005
The feature is controlled by the new office parameter orig_CgPN_in_DP3_MO_ CDR in table OFCVAR (B3.8.1 on page 69). If the parameter is set to yes (Y), the call information is captured as described here. If set to no (N), the redirecting number is captured in the Calling Number field. In all other call scenarios the settings of the existing office parameter USE_ ORIGINAL _CGPN_FOR_BILLING and SOC option GSM Generic Address Info determine whether the original calling number or redirecting number is captured in the Calling Number field. If operators want the original calling number captured for DP3-triggered calls only, they should set orig_CgPN_in_DP3_MO_CDR to Y and USE_ORIGINAL _CGPN_FOR_ BILLING to N.
Impact This feature impacts customers who use IN DP3 triggered redirection services.
A2.1.2 NSS17 Feature Development
Major Development in NSS17 - Record Header Changed in all Billing Records
The new release id field is captured in the record header of all billing records. It shows the product release of the MSC generating the records. The new field replaces the generic id field which was captured in the billing file structure records. For more information see ‘A00001605 Circuit Billing Header Release Field Enhancement’ on page 15.
Impact This change affects all customers.
A00000570 Wireless Priority Service (WPS) -Full Operating Capability (FOC)
To meet a United States (US) regulatory requirement, WPS gives priority access to network resources to US security and other authorised officials. The service is based on a subset of the GSM supplementary service eMLPP (enhanced Multi-Level Precedence and Priority).
The MSC generates a Mobile Originated Call Attempt record (B4.1.1 on page 78) with an appended Supplementary Service (SS) Information module (B4.2.4 on page 101) to capture the WPS information. The SS Code field (B5.2.190 on page 249) captures the service code using the same code as for eMLPP (0A1C). However, unlike for eMLPP, the SS parameters field does not contain any information about the priority level for the call.
The Software Optionality Control (SOC) option ‘WPS FOC SOC’ (B3.8.2 on page 74) must be on, and the office parameter ENABLE_WPS_CALL_ INDICATOR_IN_CDR (B3.8.1 on page 69) in table OFCVAR must be set to Y for the WPS billing information to be generated.
Impact This feature impacts all US customers.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 13
A00000993 World Trade Equal Access
This feature provides users with the ability to select the inter-exchange carriers that they want to use for long distance calls. The MSC generates a Mobile Originated Call Attempt record (B4.1.1 on page 78) with an appended Equal Access information module (B4.2.11 on page 113) to capture the call information. The IC/INC Prefix field (B5.2.86 on page 197) can now capture carrier identification codes (CICs) up to 8 characters in length. CICs associated with specific carriers can be from 3 to 5 digits in length. The 3-digit CICs are in the 0XY format where this does not conflict with any of the area codes in the existing dial plan. The 5-digit CICs are assigned to IP long distance service carriers.
The Equal Access capabilities are controlled by the SOC ‘GSM WT EQUAL ACCESS’ and the billing capabilities by the SOC ‘GSM WT EA BILLING SOC’ (B3.8.2 on page 74). Impact This feature impacts customers who implement Equal Access.
A00001042 LRD Messages for 3G Networks
This feature provides support for the 3GPP release 4 LCS (location services) location related data (LRD) procedure and associated messages. It also differentiates between two Mobile Originated Location Request (MO-LR) types (MO-LR Autonomous Self Location for Deciphering Keys and MO-LR Autonomous Self Location for Assistance Data). The LCS request type is captured in the LCS Record Type field (B5.2.99 on page 203) in the LCS record (B4.1.13 on page 91). The LCS Initiation Time (B5.2.97 on page 202) and LCS Result (B5.2.100 on page 203) fields are unchanged but are captured at different times in the 3G LCS scenario. The MSC captures the LCS Initiation Time when it sends the LRD Request message to the RNC. The MSC captures the LCS Result when the RNC responds with a success or failure message in response to the LRD request. A call scenario (B6.21.2 on page 315) provides an example of the service. The existing SOC ‘LCS MO LOC Request’ (B3.8.2 on page 74) must be turned on for the feature to work. Impact This feature impacts customers who provide 3GPP release 4 LCS.
A00001053 H324M 64K UDI productization on DMS-MSC
This feature implements the 3G-H.324 Unrestricted Digital Information (UDI) Circuit Switched (CS) Multimedia Telephony service to provide multimedia telephone capabilities. These allow end-users with H.324M capable handsets to communicate via video and voice at the same time. For billing purposes, the information is captured using existing values in the Data Rate field (B5.2.43 on page 166) and the Rate Adaptation field (B5.2.153 on page 230) in the Data Services information module (B4.2.8 on page 110).
The H324M 64K UDI capabilities are controlled by the SOC ‘UMTS MSC 64K UDI 3G H324M’ (B3.8.2 on page 74). Impact This feature impacts customers who implement H.324 services.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 14 (Approved) 30th March 2005
A00001121 Location Based Services: R99 Compliance
This feature enhances the release 99 location service (LCS) messages to make them fully compliant with the standards. The messages are Provide Subscriber Location (PSL), PSL Ack, Subscriber Location Request (SLR), Mobile Originated Location Request (MOLR) and MOLR Ack. The MSC captures LCS billing information in the LCS record (B4.1.13 on page 91). This record contains five fields which provide information on the geographical location of the user equipment: Geographical Location of Target UE 1 (B5.2.64 on page 186) to Geographical Location of Target UE 5 (B5.2.68 on page 188). The existing SOC options for LCS (B3.8.2 on page 74) must be turned on for the feature to work. Impact This feature impacts customers who provide release 99 compliant LCS.
A00001132 MSC/VLR Support for CAMEL P3 M-CSI
This feature provides support for the CAMEL Phase 3 mobility management procedures. These procedures, when triggered on the MSC/SSP, cause it to provide information to the SCP (Service Control Point) about non-call related mobility events: location updates, mobile attachments and mobile detachments. The subscriber’s Mobility CAMEL Subscription Information (M-CSI) is stored in the HLR and transferred to the VLR in the MAP InsertSubscriberData operation. When the MSC/SSP (actually the VLR in the MSC/SSP) detects one of the mobility events for the mobile subscriber, it sends the SCP a MAP Note MM Event message to report the event. The MSC/SSP captures the mobility information in the new Location Update record (B4.1.15 on page 93). The CSI field (B5.2.41 on page 164) in the IN information module (B4.2.14 on page 115) is extended to capture M-CSI. A call scenario (B6.16 on page 307) provides an example of the service. The existing SOC option UMTS MSC CAMEL P3 (B3.8.2 on page 74) must be on and the new office parameter MCSI_BILLING (B3.8.1 on page 69) in table OFCVAR must be set to Y for the record to be generated. Impact This feature impacts customers who support CAMEL Phase 3 mobility
services.
A00001134 ETC Error Handling and Billing
This feature enhances the support of error handling for and the billing of the CAMEL Phase 2 and Phase 3 establish temporary connection (ETC) operation. This operation is used to connect an intelligent peripheral (IP) into a call to play announcements or to collect information. The ETC message may contain addressing information in two formats: the AssistingSSPIPRoutingAddress address parameter may contain the scfID and the correlationID parameters as embedded parameters; or the scfID and correlationID parameters may be sent as separate parameters. Only ISUP 97, which the MSC/SSP may use to form the connection to the IP, can support the scfID and correlationID as separate parameters. If the SCP sends the MSC/SSP an ETC message with all of the address information as separate parameters, the MSC/SSP checks to see what connection it has to the IP. If it is does not have an ISUP 97 connection, the MSC/SSP returns an error message to the SCP and does not attempt to connect to the IP.
(continued)
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 15
The MSC/SSP in this case is acting as an initiating SSP as it is initiating the connection to the assisting SSP. It captures billing information for the IP connection in an IN information module (B4.2.14 on page 115) appended to the appropriate call record. The module contains two new fields, SCF ID / ETC Parm1 (B5.2.170 on page 238) and Correlation ID / ETC Parm2 (B5.2.39 on page 163) to capture the addressing information from the ETC operation. The MSC/SSP captures this information regardless of whether the scfID and correlationID are embedded or separate parameters. The assisting SSP, which provides its IP for the call, already captures the IP address information in the GSM assisting SSP information module (B4.2.20 on page 123). Impact This feature impacts customers who provide IP connections using
assisting SSPs.
A00001143 CF NDUB Enh for Loc (Call Forwarding on Network Determined User Busy Enhancement for Location)
This feature enhances the billing for the service call forwarding on network determined user busy (CF NDUB). In this case, party A calls party B, but the call is forwarded to party C because the network determines that party B is busy. To capture information about the location of party B, the MSC adds a Location and Channel information module (B4.2.3 on page 99) to the Mobile Terminated Call Forwarding Attempt record (B4.1.1 on page 78) for party B (for the call from A to B). The MSC may cover a large geographical area and so knowing the location of party B allows him/her to be charged appropriately for the call forwarded leg. The feature does not change any billing records or formats. The CF NDUB billing capabilities are controlled by the SOC ‘GSM CF NDUB Bill Rec’ (B3.8.2 on page 74). Impact This feature impacts customers who implement the call forwarding on
network determined user busy service.
A00001605 Circuit Billing Header Release Field Enhancement
This feature captures information about the MSC product release in all call records and not just the billing file structure records. The feature creates the new Release Id field (B5.2.161 on page 234) which is part of the Record Header field (B5.2.155 on page 231). This field is captured in all call records (B4.1.1 on page 78 to B4.1.20 on page 96). The generic identity field has been deleted and so is no longer captured in the billing file structure records Billing File Transfer In and Billing File Transfer Out (B4.1.19 on page 95 and B4.1.20 on page 96). Impact This feature impacts all customers.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 16 (Approved) 30th March 2005
A00001613 MNP: Stripping of RC in ISUP IAM message
This feature determines the format of the original called number (OCDN) and the redirecting number (REDN) in calls which involve mobile number portability (MNP) and early call forwarding (unconditional call forwarding or forwarding because the subscriber is not reachable). During the application of an MNP service, a routing code (DXXX) can be prepended to the called number to show that it has been ported. After the application of the early call forwarding service, the gateway MSC sets up the call to the forward-to network. To meet ITU standards, this feature ensures that the OCDN and REDN in the IAM (initial address message) do not contain the MNP routing code. This means that the billing records generated in the forwarded-to network do not contain the routing code. The feature is controlled by the SOC option 'GSM MNP RC STRIPPING' (B3.8.2 on page 74). There is no change to the existing billing format due to the implementation of this feature. In the existing billing record format for call forwarding scenarios, the redirecting number is captured in the calling address field when the office parameter USE_ORIGINAL_CGPN_FOR_BILLING in OFCVAR table is set to 'N'. When the GSM MNP RC STRIPPING SOC is set to 'ON', the routing code is stripped from the calling address field of the Mobile Originated Call Forwarding Attempt record and the outgoing trunk billing record of the call forwarding leg (where party A calls B who forwards to C, the forwarded leg is the one from B to C). The current billing record format does not capture the original called number for a call forwarding scenario. Impact This feature impacts customers who support MNP.
A00001891 Explicit Call Transfer Enhancements
This feature enhances the information captured during explicit call transfer (ECT) to allow the call records to be correlated. During ECT, party A calls, or is called by, parties B and C. A drops out of the call but leaves parties B and C connected. Party A has a call record for the calls to parties B and C. The call record is a Mobile Originated Call Attempt record (B4.1.1 on page 78) if A calls the other party, or a Mobile Terminated Call Attempt record (B4.1.2 on page 79) if the other party calls party A. Each of these records has a Supplementary Service information module (B4.2.4 on page 101) appended. Table 35 on page 104 gives an example of how the SS information module may be completed for the ECT service. The SS Parameter field (B5.2.191 on page 251) contains the directory number of B and C. For the call between parties A and B, the SS Parameters field contains the directory number of party C. For the call between A and C, the SS Parameters field contains the directory number of party B. The SS Parameter field is now 32 characters long. The ECT call scenario (B6.10 on page 288) describes how the directory numbers are captured. Impact This feature impacts customers who support ECT. Additionally, it
impacts all customers who collect information about supplementary services in the Supplementary Service Action Record (B4.1.12 on page 89) or the Supplementary Service Information Module (B4.2.4 on page 101) because of the change in length of the SS parameters field.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 17
A19013161 MSC Support: Multiple Time Zone Billing
This feature enhances the MSC to capture information about the differences between the timezone at the MSC and the handset. An MSC may cover a large geographical area covering several timezones. If this is the case, table datafill on the MSC can be used to specify the timezones in different location area codes (LACs) within its coverage (using tables TZONEGTA, TZONELAC, TZLAC3G and TZDEFLOC). The MSC captures the difference between its timezone and the handset’s using an offset value in the Date and Time field (B5.2.45 on page 167). This is a general purpose field whose format and contents are used by a number of other fields to provide time and timestamp information. The timestamps in the following records can use the timezone offset: Mobile Originated Call Attempt, Mobile Terminated Call Attempt, Short Message Service Mobile Originated (SMS-MO), SMS Mobile Terminated (SMS-MT) and the Call Independent Supplementary Service (CISS) record. Additionally, the timestamps in all of the modules which can be appended to these records may also capture the timezone offset. All of this information is summarised in Section B5.2.45. The multiple time zone billing capabilities are controlled by the SOC ‘Multiple Time Zone Billing’ (B3.8.2 on page 74). Impact This feature impacts customers who want to capture timezone differences
in their call records.
A2.1.3 NSS18 Market-Specific Features
A00004167 MSC Support for TDOA 911 Positioning using INAP
This feature allows the location of the calling party to be provided during E911 emergency calls. When the subscriber dials 911, the call triggers INAP (Intelligent Network Application Part) detection point 3 (DP3). The MSC sends an InitialDP message to the Service Control Point (SCP). The SCP sends the Emergency Service Routing Key (ESRK) to the MSC in an INAP Connect message. The MSC uses the ESRK to route the emergency call to a Public Safety Answering Point (PSAP). The SCP then obtains the subscriber’s location as a Time Difference Observed Arrival and reports it to the emergency centre when requested.
The ESRK is captured in the Calling Number field (B5.2.25 on page 154) and the emergency number 911 is captured in the Dialled Digits field (B5.2.52 on page 180). The capability is controlled by office parameter IN_DP3_E911_CALL (B3.8.1 on page 69).
Impact This feature impacts customers in North America who provide location information during E911 emergency calls.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 18 (Approved) 30th March 2005
A00007490 Israeli Directory Assistance Service
This feature allows a subscriber to call the directory assistance service to ask an operator for information on a directory number. The caller calls the directory assistance service number and requests a number from the operator. The operator finds the number and connects the caller to a recorded message service which plays the number. In order to capture the billing information the outgoing trunk record on the caller’s Visited MSC (VMSC) has an appended Supplementary Service information module (B4.2.4 on page 101). This module captures the new value 0B0C in the SS code field (B5.2.190 on page 249) to indicate the national specific directory assistance service.
Impact This feature impacts customers in the Israeli market who provide the directory assistance service.
A2.1.4 NSS17 Market-Specific Features
A00001007 China CAMEL P2 Enhancements for NQI=80H
This feature enhances the way that CAMEL Phase 2 calls are billed in the Chinese market. Operators can bill CAMEL subscribers using call detail records generated by the Service Control Point (SCP) or the MSC/SSP. The SCP and the MSC/SSP both produce billing records but the MSC/SSP’s records are marked to show that they are not required for billing purposes. Additionally, to support the “Calling & Called Party Pays service 12597/12598”, the correct digits must be captured in the call records. This feature extends the billing capabilities to CAMEL mobile originated and mobile forwarded calls to add to the mobile terminated billing capabilities which are already defined. For this feature the SCP sends the MSC/SSP a CAMEL Connect message during mobile originated or mobile forwarded call setup. This message contains the generic number parameter with the number qualifier identifier field set to 80 hex and the generic number digits in one of a number of defined formats. When this happens, the MSC/SSP captures the generic number digits in the calling number field of the appropriate call records. Some example scenarios (B6.23.1 on page 322) provide examples of which numbering information is captured which call records. The feature does not change any billing records or formats. The China CAMEL Phase 2 capabilities are controlled by the SOC ‘China CAMEL Phase 2 SOC’ (B3.8.2 on page 74). Impact This feature impacts customers in the Chinese market.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 19
A00001142 China CAMEL P2 AC/ACR Billing Enhancement
This feature provides support for a Chinese market capability which prevents a CAMEL pre-paid subscriber from being charged for certain calls. In some cases, for example where the call cannot be completed, the call is connected to an intelligent peripheral which plays an announcement to the caller. In this case, the backward call setup signalling from the IP indicates that the calling party should not be charged for the call. The IP may send the indication in one of the following messages: Answer No-Charge (ANN) message, Address Complete Message (ACM) or the Answer Message (ANM). The MSC/SSP sends the Service Control Point (SCP) a CAMEL ApplyChargingReport message which indicates that the calling party should not be charged (in response to the original ApplyCharging instruction from the SCP). The MSC/SSP captures the billing information by setting the Call Indicator field (B5.2.17 on page 147) to indicate ‘no charge’ in the mobile originated call attempt record (B4.1.1 on page 78). The feature does not change any billing records or formats. The China AC/ACR billing capabilities are controlled by the SOC ‘China CAMEL Phase 2 SOC’ (B3.8.2 on page 74). Impact This feature impacts customers in the Chinese market.
A2.1.5 NSS18 Change Request (CR) Updates
Q00609584 CallReferenceNumber needs to be presented in V3 SRI without restriction
This CR allows the MSC to capture a Network Call Reference Number (NCRN) for a mobile terminated basic call if the Mobile Application Part (MAP) SendRouting Information (SRI) message is at version 3 or higher. In this scenario, the Gateway MSC (GMSC) queries the Home Location Register (HLR) for service and routing information to set up a call by sending it an SRI message. If this message is at MAP version 3 or higher, it can contain a NCRN. The MSC captures the NCRN in a Network Call Reference information module (B4.2.17 on page 120). With the introduction of this CR, the MSC can capture the NCRN for mobile terminated basic calls as well as for mobile originated and terminated CAMEL calls and for optimally routed calls.
Impact This change impacts all customers who use MAP v3 or later.
Q00722754-01GSM13: XAC PTML ISB MSC: Call duration of MT and IC Gateway CDRs are different
This CR introduces the new office parameters GSM_CALL_DURATION_ ROUNDING and GSM_CALL_DURATION_GRANULARITY (Table 4 in B3.8.1 on page 69). These office parameters determine how the value of the call duration is rounded. The Call Duration field is now 14 characters long (B5.2.15 on page 145) with extra fields to show the rounding method used as well as the call duration.
(continued)
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 20 (Approved) 30th March 2005
The following records are now all longer because of the new encoding of the Call Duration field: Mobile Originated Call Attempt (B4.1.1 on page 78), Mobile Terminated Call Attempt (B4.1.2 on page 79), Roaming (B4.1.3 on page 80), Incoming and Outgoing Gateway (B4.1.4 on page 81 and B4.1.5 on page 82), Transit (B4.1.6 on page 83), the Incoming and Outgoing Intra-PLMN (B4.1.9 on page 86 and B4.1.10 on page 87) and Common Equipment Usage (B4.1.11 on page 88).
Impact This change impacts all customers.
Q00808848-03UMTS:XMSC15DK: Field 'CH TYPE' is not filled correctly in UMTS video call
This CR defines the new value 8 for the fourth character of the Channel Type field (B5.2.33 on page 159). The new value indicates a 64Kbits/s data service.
Impact This change impacts all customers who support 64Kbits/s data services.
Q00887668 AWS:UMTS:V3:MSC: MM Call does not support Classmark 7 for UMTS mobiles
This CR defines the new value 7 for the RF power capability subfield of the MS classmark field (B5.2.111 on page 209). The new value indicates that the class is irrelevant.
Impact This change impacts all customers.
Q01006934 Enhancement in patching module
The Patching information module (B4.2.22 on page 125) contains the new Patch Identity field (B5.2.141 on page 224).
Impact This change impacts Nortel staff who write billing patches.
Q01067308 GSM18: FG08:LCS Billing: To allow LCS billing to go to hot billing stream
This CR allows the Location Services (LCS) record to be generated in the hot billing stream (B3.5 on page 64).
Impact This change impacts all customers who deploy LCS.
Q01093144 18REG:BILLING:SVE - Documentation - LNP MC not appended on every LNP query
This CR alters the capturing of information for Local Number Portability (LNP) services. Whenever the MSC triggers a query to the LNP database it creates an LNP information module (B4.3.3 on page 128) to capture the LNP data. This happens regardless of the response from the LNP database, or whether the resulting call is answered. CR Q01093144 is a documentation CR related to CR Q01054004. Neither CR has an impact on the format or content of the information module.
Impact This change impacts all customers who deploy LNP services.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 21
Q01094882 GSM:MSC:GSM15:SMS MT messages and records can not be billed
The SMS (Short Message Service) Result field (B5.2.181 on page 245) captures diagnostic information which provides information about the failure to deliver a short message. However, depending on when the failure occurs during delivery, the field may not capture diagnostic information about the failure condition.
Impact This change affects customers providing SMS.
A2.1.6 NSS17 Change Request (CR) Updates
Q00427302-01NSS:MSC:GSM13: Questions regarding wrong 'MS Classmark' values in GCDR
This CR increases the MS classmark field (B5.2.111 on page 209) to 16 characters to capture additional classmark values.
Impact This change impacts all customers.
Q00547509 GSM:GSM13:MSC: Module Code 18 not appended to PREPAID MT billing records
This CR explains why an IN information module (B4.2.14 on page 115) is not appended to the terminating call record in some off-board IN call scenarios.
Impact This change impacts customers who implement off-board IN.
Q00645209-01NSS:GSM15:MSC:LCS GCDR field LCS CLIENT Ext ID
This CR corrects the encoding of the LCS Client Identity field (B5.2.94 on page 200).
Impact This change impacts customers who implement LCS.
Q00687676 GSM17FG02: Modification to MM EVENT field in STRUC CODE= 10001C
This CR corrects the encoding of the MM Event field (B5.2.109 on page 208).
Impact This change impacts customers who implement the CAMEL mobility management service.
Q00703335 MSC: No MNP info in CDR for home subs
This CR adds to the description of the Routing Number field (B5.2.168 on page 237) to differentiate between ETSI Mobile Number Portability (MNP) and Signalling Relay Function (SRF) based MNP.
Impact This change provides a clarification to customers who implement MNP.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 22 (Approved) 30th March 2005
Q00712339 GSM17 FG02: AN, OLD LAC and SAC fields not captured correctly
This CR describes how the Location Update record (B4.1.15 on page 93) is completed for mobile and network initiated detach. The Access Network (B5.2.2 on page 140), New AN (B5.2.117 on page 213) and Old AN fields (B5.2.127 on page 218) can all capture a default value.
Impact This change provides a clarification to customers who implement the CAMEL mobility management service.
A2.2 Other Changes
A2.2.1 Other Changes Made in this Release
This section describes changes in the specification which are not directly related to the NSS18 GSM/UMTS product release.
Call Forwarding Record Naming Updated
In a call forwarding scenario where party A calls party B who calls party C, the two records which capture the call forwarding information are the Mobile Terminated Call Forwarding Attempt record for the call from A to B and the Mobile Originated Call Forwarding Attempt record for the forwarded call leg from B to C. These records are based on the Mobile Terminated Call Attempt (B4.1.2 on page 79) and the Mobile Originated Call Attempt (B4.1.1 on page 78) records. In both records the call forward indicator is set to true and they each have Supplementary Service information modules (B4.2.4 on page 101) appended which contain the forwarding information.
Impact This change is editorial and has no technical impact.
Called and Calling Subscriber Category Fields
The headings for these field descriptions (B5.2.23 on page 152 and B5.2.27 on page 157) have been updated to remove any ambiguity about their use.
Impact This change is editorial and has no technical impact.
Channel Type Field Values for UMTS Calls
In a UMTS call record a setting of 11100C in the Channel Type field (B5.2.33 on page 159) in the Location and Channel Information module (B4.2.3 on page 99) indicates the use of the Adaptive Multi-Rate (AMR) coder/decoder (codec).
Impact This clarification provides information to all customers who implement the AMR codec in UMTS networks.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 23
Cell SAC Id field values during relocation and handover
Table 4 in B3.8.1 on page 69 describes how the office parameter LOC_RPT_ CNTRL_FOR_SAI in table OFCVAR determines the capturing of the Service Area Code (SAC) in the Cell-SAC id field (B5.2.30 on page 158).
Impact This change impacts all customers who generate billing logs.
Core and Billing Manager
The Core and Billing Manager is a new hardware platform which runs the Supernode Billing Application (SBA). The SBA creates billing records and transfers them to the downstream processor. The information described in B1.2 on page 44 and in B2 starting from page 49.
Impact This change impacts all customers.
GSM_BILLING_REPORT and GSM_HOTBILLING_REPORT Office Parameters
Table 4 in B3.8.1 on page 69 describes how the office parameters GSM_BILLING_ REPORT and GSM_HOTBILLING_REPORT control the production of GCDR 600 and GHOT 600 logs.
Impact This change impacts all customers who generate billing logs.
Hot Billing Office Parameters
In an editorial change, the office parameters GSM_EMERGENCY_HOT and MARK_ROAMER_HOT (B3.5 on page 64) have also been added to the office parameter descriptions in section B3.8.1 on page 69, Table 4.
Impact This change provides clarifications for customers who provide hot billing.
IMEI Fields Capture Digits
The fields which can capture the IMEI contain a clarification that a valid IMEI contains only digits. This has been added to the Called Equipment field (B5.2.20 on page 149), the Calling Equipment field (B5.2.24 on page 153) and the Served IMEI field (B5.2.173 on page 240).
Impact This change provides a clarifications customers.
Location Service (LCS) information
The Geographical Location of UE (B5.2.64 on page 186) field and Requested QoS field (B5.2.163 on page 234) contain notes listing the standards messages/parameters which provide the information contained in the billing fields.
Impact This change provides clarifications for customers who provide location services.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 24 (Approved) 30th March 2005
Served Party field
The Served Party field (B5.2.176 on page 241) replaces the Identity of Target UE field in the LCS record (B4.1.13 on page 91).
Impact This change affects customers providing Location Services (LCS).
Supplementary Service Action Field
The value 5C in this field (B5.2.189 on page 249) now has an entry for the CISS (Call Independent Supplementary Service) operation for USSD (Unstructured Supplementary Service Data).
Impact This change provides clarifications for customers who USSD services.
A2.2.2 Other Changes Made in NSS17
This section describes changes in the specification which are not directly related to the NSS17 GSM product release.
Called and Calling Equipment Field Descriptions Updated
The descriptions of how the IMEI is captured in the Called Equipment field (B5.2.20 on page 149) and Calling Equipment field (B5.2.24 on page 153) during call forwarding have been amended.
Impact This change provides information to customers about call forwarding.
Carrier Selection Charging Information Module Description Updated
The information module can be appended to the Roaming Call Attempt record as shown in the market specific module information (B4.3 on page 127, Table 59) and in the list of records in the module’s description (B4.3.5 on page 130).
Impact This change provides information to German and Austrian customers.
Channel Type Field Value Clarified
The Channel Type field (B5.2.33 on page 159) always has the value 11100C for UMTS voice calls.
Impact This change provides information to all customers.
Generic Address Parameter Updated
The example of the Generic Address Parameter field (B5.3.4 on page 260) has been corrected.
Impact This change impacts PCS 1900 customers who capture originator-terminator information.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 25
IN Information Module Description Updated The notes providing information about the IN information module (B4.2.14 on page 115) have been extended. The new information provides clarification and does not describe new billing capabilities.
Impact The change provides information to all customers.
Module InformationThe tables at the front of the module and market-specific module sections (B4.2 on page 97 and B4.3 on page 127) have an extra column specifying how many times each module can be appended to each call record. This information provides clarification and does not describe new billing capabilities.
Impact The change provides information to all customers.
Module / Record Field Size Information The record and module information tables in sections B4.1 to B4.3 show the sizes of all the fields that they contain and also the total size of the record or module. Information about the size and type (atomic or compound) of each field is in the tables at the beginning of sections B5.2 on page 132, B5.3 on page 258, B5.4 on page 268 and B5.5 on page 271. Each field description contains information about the records and/or modules that the field is in.
Impact The changes provide information to all customers.
Network call Reference Information Module Description UpdatedThe description of the module (B4.2.17 on page 120) has been updated to make it clear that the network call reference number is for CAMEL and optimal routing services only and that it is transferred between network nodes in MAP signalling. No ISUP signalling is used.
Impact The changes provide information to all customers.
Record Count Maximum CorrectedThe record count field (B5.2.154 on page 231) has a maximum value of 000065535.
Impact The change impacts all customers.
Sample Billing InformationSection B2.3 on page 52 provides information on the availability of sample billing information.
Impact The change provides information to all customers.
Short Message Service (SMS) Record UpdatesThe Calling Equipment field in the SMS Mobile Originated Record (B4.1.7 on page 84) and the Called Equipment in the SMS Mobile Terminated record (B4.1.8 on page 85) are both conditional (C) fields and not unsupported (X) fields.
Impact The change impacts all customers who implement SMS.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 26 (Approved) 30th March 2005
Supplementary Service Action (SSA) Record UpdatesThe Served Equipment and Call Reference fields in the SSA record (B4.1.12 on page 89) are both conditional (C) fields and not unsupported (X) fields.
Impact The change impacts all customers who implement call independent supplementary services (CISS) and/or Unstructured Supplementary Service Data (USSD) services.
A2.3 List of Changed Pages
A2.3.1 Changed Pages in NSS18
Table 1 lists the pages in the specification which contain new or altered information for NSS18. The changes have an impact on the down stream processor.
Page Section New/Changed Information58 B3.2.3 The call forwarding description uses the terminology Mobile Originated and Mobile
Terminated Call Forwarding Attempt for the forwarding records. 64 B3.5 The LCS record can be generated in the hot billing stream. 69 B3.8.1 This section contains information on new/changed office parameters GSM_
BILLING_REPORT, GSM_HOTBILLING_REPORT, GSM_EMERGENCY_HOT, MARK_ROAMER_HOT, GSMMSC_NUMBER, IPADDR field, GSM_CALL_ DURATION_GRANULARITY, GSM_CALL_DURATION_ROUNDING, orig_CgPN_in_DP3_MO_CDR, LOC_RPT_CNTRL_FOR_SAI, LCS_BILLING_ IN_EMER_CALLS, LCS_RELEASE and IN_DP3_E911_CALL.
74 B3.8.2 This section contains information on the new Software Optionality Control (SOC) option AOC Multiple Rate Plan.
78 B4.1.1 The Mobile Originated Call Attempt record can contain new values in the Calling Subscriber Category field. The Calling Number field can contain the original calling number during Intelligent Network (IN) triggered call redirection. The Mobile Originated Call Attempt record is called the Mobile Originated Call Forwarding Attempt record when it captures call forwarding information.The record is six characters longer because of the change in length of the Call Duration field.
79 B4.1.2 The Mobile Terminated Call Attempt record can contain new values in the Called Subscriber Category field. The Mobile Terminated Call Attempt record is called the Mobile Terminated Call Forwarding Attempt record when it captures call forwarding information.The record is six characters longer because of the change in length of the Call Duration field.
Table 1 Changed Pages in this Release
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 27
80 - 83
B4.1.3- B4.1.6
The Roaming, Incoming and Outgoing Gateway and Transit records are six characters longer because of the change in length of the Call Duration field.
86- 87
B4.1.9- B4.1.10
The Incoming and Outgoing Intra-PLMN records are six characters longer because of the change in length of the Call Duration field.
88 B4.1.11 The Common Equipment record can capture information for conference circuits provided on a Media Gateway as well as on an MSC. The record is six characters longer because of the change in length of the Call Duration field.
91 B4.1.13 The Location Services (LCS) Record contains new fields and increases to 500 characters in length.
97 B4.2 The module summary table shows the records to which the Data Services and Bearer Independent Core Network information modules may be appended. The footnotes on call forwarding uses the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
99 B4.2.3 The Location and Channel information module contains the new RNC ID field. The notes below the module table use the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
101 B4.2.4 The SS information module can now capture an SS code for national-specific directory assistance service calls.
110 B4.2.8 The Data Services information module can be appended to incoming and outgoing trunk records and the roaming record. It can also be appended to the Mobile Originated Call Forwarding Attempt and Mobile Terminated Call Forwarding Attempt records generated in call forwarding. The notes below the module table use the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
115 B4.2.14 The IN information module can contain the address of a standby SCP if the original one is overloaded. It can also contain the new value of 6C in the operation indication field for the customised ring back tone service. The notes below the module table use the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
120 B4.2.17 The Network Call Reference information module is generated for mobile terminated basic calls if the MSC uses MAP version 3 or higher.
124 B4.2.21 The CAMEL SMS information module can contain the address of a standby SCP if the original one is overloaded.
125 B4.2.22 The Patching information module contains the new Patching Identity field. 126 B4.2.23 The Bearer Independent Core Network information module captures billing
information in 3GPP Release 4 BICNs. 128 B4.3.3 The LNP information module is appended to call records after the MSC queries the
LNP database. 139 B5.2.1 The new Access Media Type field is in the new BICN information module.
Page Section New/Changed Information
Table 1 Changed Pages in this Release
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 28 (Approved) 30th March 2005
142 B5.2.8 The new Backbone Media Type field is in the new BICN information module. 145 B5.2.15 The encoding of the Call Duration Field has changed and it is now 14 characters
long. 146 B5.2.16 The description of the Call Forward Indicator field uses the terminology Mobile
Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
149 B5.2.20 The Called Equipment field has a clarification that a valid IMEI contains digits only. The notes in the field use the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
152 B5.2.23 The alteration of the section heading to Called Subscriber Category removes confusion about the field contents.
153 B5.2.24 The Calling Equipment field has a clarification that a valid IMEI contains digits only. The notes in the field use the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
154 B5.2.25 The notes in the Calling Number field use the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
157 B5.2.26 The Calling Party field may contain the Emergency Service Routing Key for a North American E911 call.
157 B5.2.27 The Calling Subscriber Category field can capture new values. 159 B5.2.33 The Channel Type field value of 11100C in UMTS call records indicates the use of
the AMR codec.162 B5.2.37 The default value for the Connection Element field is 0C if the Data Service
information module is appended to trunk records and the roaming record. 182 B5.2.55 The Emergency Service Routing Digits field is captured in the LCS record. 182 B5.2.56 The Emergency Service Routing Key field is captured in the LCS record. 183 B5.2.57 The Equipment Type field indicates whether conference circuits are provided on an
MSC or on a Media Gateway. 186 B5.2.64 A note in the Geographical Location of UE field refers to the 3GPP standards which
define its contents.---- --------- The Identity of Target UE field is now called the Served Party field. 194 B5.2.81 The note in the Incoming/Outgoing Trunk Seizure Time field uses the terminology
Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
201 B5.2.96 The LCS Diagnostic field is captured in the LCS record. 202 B5.2.98 The LCS Priority Level field is captured in the LCS record. 203 B5.2.99 The LCS Record Type field can capture new LCS information. 207 B5.2.107 The new MGW Number field is in the new BICN information module. 207 B5.2.108 The new MGW Seizure Time field is in the new BICN information module. 208 B5.2.110 The Module Code field can capture the new code for the BICN information module. 212 B5.2.115 The new MSC/MGW field is captured in the Common Equipment Usage record.
Page Section New/Changed Information
Table 1 Changed Pages in this Release
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 29
220 B5.2.132 The Operation Indication field can capture the new value 6C for the CAMEL phase 2 customised ring back tone service. A note in the field uses the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
224 B5.2.141 The Patching Identity field captures the patch identity. 225 B5.2.143 The Positioning Data field is captured in the LCS record. 229 B5.2.150 The Privacy Notification field is captured in the LCS record. 229 B5.2.151 The Privacy Override field is captured in the LCS record. 234 B5.2.163 A note in the Requested QoS field refers to the 3GPP standards which define its
contents.235 B5.2.164 The Requesting MLC field is captured in the LCS record. 237 B5.2.166 The RNC ID field is captured in the Location and Channel information module. 239 B5.2.171 The SCP address field can contain the address of a standby SCP if the original one is
overloaded. 240 B5.2.173 The new Served IMEI field is captured in the LCS record. 241 B5.2.175 The Served MSISDN field is captured in the LCS record 241 B5.2.176 The new Served Party Field is captured in the LCS record.
This field was called Identity of Target UE before this update. 245 B5.2.181 The SMS Result field contains a clarification about when error information is
captured. 249 B5.2.189 The value 5C in the Supplementary Service Action field has been updated for
USSD. 249 B5.2.190 The Supplementary Service Code field can contain the value 0B4C for national-
specific directory assistance calls. 251 B5.2.192 The System Type field is captured in the LCS record. 283 B6.7 The description of the call forwarding scenarios uses the terminology Mobile
Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
309 B6.19 The description of the optimal routing of forwarding calls uses the terminology Mobile Originated and Mobile Terminated Call Forwarding Attempt for the forwarding records.
341 C3 The tariff system now support multiple rate plans using rate plans based on a subscriber’s Customer Group (CUSTGRP) and Network Class of Service (NCOS).
Page Section New/Changed Information
Table 1 Changed Pages in this Release
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 30 (Approved) 30th March 2005
A2.3.2 Changed Pages in NSS17
Table 2 lists the pages in the specification which contain new or altered information for NSS17. The changes have an impact on the down stream processor.
Page Section New/Changed Information69 B3.8.1 This section describes the new office parameters for the Location Update record -
MCSI_BILLING - and the Wireless Priority Service (WPS) - ENABLE_WPS_ CALL_INDICATOR_IN_CDR.
74 B3.8.2 The section describes the new SOC options for Call Forwarding on Network Determined User Busy (CF NDUB), CAMEL Phase 3 Mobility Management, China CAMEL Phase 2, Equal Access, H.324 multimedia services, LCS, Mobile Number Portability (MNP), multiple timezone billing and WPS.
78 - 96
B4.1.1 - B4.1.20
All call records contain the modified Record Header field. The timestamps in the Mobile Originated, Mobile Terminated, SMS MO, SMS MT, and SS action records can contain a timezone offset value.
84 B4.1.7 The Calling Equipment field is conditional (C) in the SMS MO record. 85 B4.1.8 The Called Equipment field is conditional (C) in the SMS MT record. 89 B4.1.12 The SS Parameters field in the SS Action Record is now 32 characters long.
The Served Equipment and Call Reference fields are (C). 91 B4.1.13 The LCS record now contains five fields to provide the geographical location
information: Geographical Location of UE 1 to Geographical Location of UE 5. 93 B4.1.15 The new Location Update record captures details for the CAMEL mobility
management service. A note below the record information table describes how the record is completed for mobile and network initiated detach.
97 B4.2 The module table has a new column showing how many times each module can be appended to call records. The timestamps in the Bearer Service, Location and Channel, SS, Teleservice, AoC, Data Service, Equal Access, IN, CAMEL SMS and Patching modules can contain a timezone offset value.
101 B4.2.4 The SS information module table and the examples in Table 33 on page 103 to Table 39 on page 107 have been changed to show the SS Parameters field as 32 characters long.
115 B4.2.14 The IN information module can be appended to the new location update record. It also contains two new fields: SCF ID / ETC Parm1. New notes provide more information about how the module is used, especially for off-board IN.
120 B4.2.17 The Network Call Reference information module captures information from MAP signalling (no ISUP signalling is used). This is a clarification.
127 B4.3 The Carrier Selection Charging information module can be appended to the Roaming Call Attempt Record.
Table 2 Changed Pages in the NSS17 Release
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 31
130 B4.3.5 The Carrier Selection Charging Information Module can be appended to the Roaming Call Attempt Record.
131 B5.1 This section contains information on the lengths of the Geographical Location of UE 1 to Geographical Location of UE 4 fields and the Correlation Id / ETC Parm 1 and the SCF ID / ETC Parm 2 fields.
140 B5.2.2 The Access Network field now defaults to 0C. 141 B5.2.6 The Answer Time field can contain a timezone offset value. 148 B5.2.19 The Call Type Code field now includes the new location update record.149 B5.2.20 The Called Equipment field contains a modified description of the capturing of the
IMEI during call forwarding. 153 B5.2.24 The Calling Equipment field contains a modified description of the capturing of the
IMEI during call forwarding. 157 B5.2.28 The Carrier Connect Timestamp field can contain a timezone offset value.159 B5.2.31 The Channel Allocation Time field can contain a timezone offset value. 159 B5.2.33 The Channel Type field always has the value 11100C for UMTS voice calls. 161 B5.2.36 The Classmark Time Stamp field can contain a timezone offset value. 163 B5.2.39 The new Correlation ID / ETC Parm2 field contains part of the addressing
information for the intelligent peripheral (IP) to be used for a CAMEL service. 164 B5.2.41 The CSI field can now capture a value for M-CSI information. 166 B5.2.43 The Data Rate field has a note explaining how the H.324 multimedia service and the
64K clear channel service are differentiated. 167 B5.2.45 The Date and Time field can contain a timezone offset value.171 B5.2.48 The Delivery Timestamp field can contain a timezone offset value.181 B5.2.53 The Disconnect Time field can contain a timezone offset value. ----- --------- The Generic Identity field is no longer used in billing records. 186 B5.2.64 The field Geographical Location of UE 1 replaces Geographical Location of UE. 187 B5.2.65 The new field Geographical Location of UE 2 captures location information. 187 B5.2.66 The new field Geographical Location of UE 3 captures location information. 188 B5.2.67 The new field Geographical Location of UE 4 captures location information. 188 B5.2.68 The new field Geographical Location of UE 5 captures location information. 192 B5.2.76 The IN Timestamp1 field can contain a timezone offset value.192 B5.2.77 The IN Timestamp2 field can contain a timezone offset value.194 B5.2.81 The Incoming/Outgoing Trunk Seizure Time field can contain a timezone offset
value. 197 B5.2.86 The IC/INC Prefix field is now 10 characters long to capture the carrier
identification codes (CICs) for the Chinese market. 200 B5.2.93 The IWF Activation Timestamp field can contain a timezone offset value.200 B5.2.94 The LCS Client Identity field has been updated. 202 B5.2.97 The LCS Initiation Time field may be captured for 3G LCS as well as 2G. 203 B5.2.99 The LCS Record Type field captures new values for LCS. 203 B5.2.100 The LCS Result field may be captured for 3G LCS as well as 2G.
Page Section New/Changed Information
Table 2 Changed Pages in the NSS17 Release
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 32 (Approved) 30th March 2005
208 B5.2.109 The new MM Event field captures the mobility management event reported during a CAMEL Phase 3 mobility management service. Field coded amended.
209 B5.2.111 The MS Classmark field is now 16 characters long to capture additional information. 213 B5.2.117 The new field New AN identifies the type of network involved in the provision of
the CAMEL Phase 3 mobility management service. The field defaults to 0C.214 B5.2.118 The new field New Cell - SAC Id identifies the location of the subscriber involved in
the provision of the CAMEL Phase 3 mobility management service. 214 B5.2.119 The new field New LAC captures the location area code of the MSC which sends
location information to the SCP as part of the CAMEL Phase 3 mobility management service.
215 B5.2.120 The new field New MSC Id captures the E.164 number of the MSC which sends location information to the SCP as part of the CAMEL Phase 3 mobility management service.
218 B5.2.127 The new field Old AN identifies the type of network involved in the provision of the CAMEL Phase 3 mobility management service. The field defaults to 0C.
218 B5.2.128 The new field Old Cell - SAC Id identifies the location of the subscriber involved in the provision of the CAMEL Phase 3 mobility management service.
218 B5.2.129 The new field Old LAC captures the location area code of the MSC which sends location information to the SCP as part of the CAMEL Phase 3 mobility management service.
219 B5.2.130 The new field Old MSC Id captures the E.164 number of the MSC which sends location information to the SCP as part of the CAMEL Phase 3 mobility management service.
230 B5.2.153 The Rate Adaptation field has a note explaining how the H.324 multimedia service and the 64K clear channel service are differentiated.
231 B5.2.154 The Record Count maximum value is 000065535. 231 B5.2.155 The Record Header field contains the new Release Id field. Additionally, a table
shows the correspondence of the structure code and the call type code for the location update record.
233 B5.2.158 The new Recording Entity field captures the E.164 number of the VLR which sends location information to the SCP as part of the CAMEL Phase 3 mobility management service.
234 B5.2.161 The new Release Id field contains information about the MSC release. It replaces the Generic Identity field which is deleted from the billing system.
234 B5.2.162 The Release Time field can contain a timezone offset value.237 B5.2.168 The Routing Number field contains information about ETSI and SRF MNP. 238 B5.2.170 The new SCF ID / ETC Parm1 field contains part of the addressing information for
the intelligent peripheral (IP) to be used for a CAMEL service. 241 B5.2.175 The new Served MSISDN field captures the identity of the party for whom a
CAMEL Phase 3 mobility management service is being provided.
Page Section New/Changed Information
Table 2 Changed Pages in the NSS17 Release
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 33
A2.4 Feature Information
A2.4.1 UMTS and GSM Features
Release 18 (NSS18)
A00004084 Location Based Services Enhancements A00004142 MSC Support of BICN UMTSA00004147 MC09 Billing EnhancementA00004164 Advice of Charge Multiple Rate Plans Enhancements A00004167 MSC Support for TDOA 911 Positioning using INAPA00004169 Call Forward Records Enhancement for LocA00004188 CAMEL enhancementA00004372 R4 MSC: CONF Service Alignment with MGWA00004373 R4 MSC: HO Service Alignment with MGW A00004513 R4 Billing related enhancements A00004613 Advice of Charge for R2 and TUPA00004614 Ringback Support for DP12 CAMEL P2 Connect Solution A00006555 MSC Subscriber Category Enhancement A00007441 MC09 Billing Module Captured on CF leg for CSD Calls
(continued)
240 B5.2.174 The new Served IMSI field captures the identity of the party for whom a CAMEL Phase 3 mobility management service is being provided.
245 B5.2.182 The SMS Start Stamp field can contain a timezone offset value. 245 B5.2.183 The SMS Stop Stamp field can contain a timezone offset value. 246 B5.2.184 The SMS Time Stamp field can contain a timezone offset value. 246 B5.2.186 The Structure Code field now includes the new Location Update record. 249 B5.2.190 SS Code for eMLPP (0A1C) also codes for WPS.251 B5.2.191 The SS Parameters field is now 32 characters long. 256 B5.2.201 The Unused Timestamp 1 field can contain a timezone offset value.256 B5.2.202 The Unused Timestamp 2 field can contain a timezone offset value.256 B5.2.203 The new Update Result field contains the result of the provision of a CAMEL Phase
3 mobility management service. 257 B5.2.204 The new Update Time field contains the time at which a CAMEL Phase 3 mobility
management service was performed. 260 B5.3.4 The Generic Address Parameter field example has been corrected. 307 B6.16 Call scenario added for the CAMEL mobility management service. 315 B6.21.2 Call scenario added for location services based on location related data procedures.322 B6.23.1 Call scenario added for billing of CAMEL calls in the Chinese market.
Page Section New/Changed Information
Table 2 Changed Pages in the NSS17 Release
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 34 (Approved) 30th March 2005
Release 18 features continued A00007479 Calling party address (MSISDN) in MO CDRA00007490 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 differentQ00808848-03 UMTS:XMSC15DK: Field 'CH TYPE' is not filled correctly in UMTS video callQ00887668 AWS:UMTS:V3:MSC: MM Call does not support Classmark 7 for UMTS mobilesQ01006934 Enhancement in patching module Q01067308 GSM18: FG08:LCS Billing: To allow LCS billing to go to hot billing streamQ01093144 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 AccessA00001007 China CAMEL P2 Enhancements for NQI=80HA00001042 LRD Messages for 3G NetworksA00001053 H324M 64K UDI productization on DMS-MSCA00001121 Location Based Services: R99 ComplianceA00001132 MSC/VLR Support for CAMEL P3 M-CSIA00001134 ETC Error Handling and Billing A00001143 CF NDUB Enh for LocA00001605 Circuit Billing Header Release Field EnhancementA00001613 MNP: Stripping of RC in ISUP IAM messageA00001891 Explicit Call Transfer EnhancementsA19013161 MSC Support: Multiple Time Zone BillingQ00427302-01NSS:MSC:GSM13: Questions regarding wrong 'MS Classmark' values in GCDRQ00547509 GSM:GSM13:MSC: Module Code 18 not appended to PREPAID MT billing
recordsQ00645209-01NSS:GSM15:MSC:LCS GCDR field LCS CLIENT Ext IDQ00687676 GSM17FG02: Modification to MM EVENT field in STRUC CODE= 10001CQ00703335 MSC: No MNP info in CDR for home subsQ00712339 GSM17 FG02: AN, OLD LAC and SAC fields not captured correctly
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 35
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 andAbandon EDP-R
A19012008 Support of Mobile Number Portability based on Query on Release for Portugal ISUPA19012022 Camel Phase 2 Billing EnhancementA19012197 CAMEL P3 SMS-CSI Umbrella Document
A19011809 CAMEL P3 FCI SMSA19011818 CAMEL Phase 3 SOC/Billing Framework
A19012198 CDR Optionality for Unanswered callsA19012200 Reorigination triggered by Release CauseA19012258 CAMEL Phase 3: ContinueWithArgumentA19012279 CAMEL Ph2 Assisting SSP and CTRA19012295 CTM-TTY Circuit PoolingA19012546 Incoming Trunk Record Enhancement for CAMELA89007097 Billing Buffer OverflowA89007099 Sourcing:cmcc Call Forward Billing RequirementQ00390220 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
Release 15 (GSM15/UMTS02)
A60011214 Mobile Number Portability (MNP) EnhancementA60011241 GSM/UMTS Supplementary Services Location DiscriminationA60011396 UMBRELLA FN for A60011396 and A60011397
A60011396-InitialDP (Initial Detection Point) enhancement to includenaCarrierInformation.
A60011397-CAP2 Establish Temporary Connection (ETC) and Connect Support for NA Info
A60011410 CAP 2: IN support for Equal Access (EA) BillingA60011426 LoCation Services (LCS) functionality descriptionA60011497 USSD Billing
Release 14 (GSM14/UMTS01)
A60010347 CAMEL PHASE 2: Call Re-OriginationA60010354 CAMEL Phase 2: Send Charging Information (SCI)A60010376 CAMEL Internal SRF supportA60010390 SRF Implementation for GSM 03.66 and 3G TS 23.066 based MNPA60010812 IT2: UMTS Billing Enhancements
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 36 (Approved) 30th March 2005
Release 13 (GSM13)
A60009171 Support of ETSI Mobile Number Portability (MNP)A60009178 Partial Billing EnhancementsA60009179 Enhancements to Incoming Trunk Call Detailed RecordA60009197 Austrian Carrier Selection Phase 2A60009304 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 RoutingGR2638 Anonymous Call RejectionGR2647 GSM11 Israeli ISUPGR2659 GSM11 CAMEL Ph2 Furnish ChargingGR2671 File Transfer Sequence Number OptionalityGR2798 GSM11 DMS-MSC Address Enhancements GR2803 NOA Address Format CustomizingGR2897 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) callsGR3105 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 GSM10GR2542 Roaming Record and Common Equipment Usage Record Optionality
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 37
Release 9 (GSM09)
GR1278 IN Integrated DMS-MSC/SSPGR1293 Explicit Call Transfer (ECT)GR1301 GSM Support for 30 Digit Translation (UXLA)GR1306 MSC Support for 14400bps Data RateGR1335 Multiple Network/Country Codes per MSCGR1346 Network Optimisations for Call ForwardingGR2082 Generic Billing Enhancements GR2107 Italian TUP for DMS-MSCGR2121 ATUP-POI Phase 3 Enhancements on the DMS-MSCGR2154 CISS BillingGR2155 AoC Tariff Band ChangeGR2329 Indirect Access Screening and NOA routing (for Germany)
Release 8 (GSM08)
AD8029 Call Re-EstablishmentAD9035 Calling Name Delivery (CNAM)AD9036 Irish Blue Book TUP on the DMSAD9095 Redirection Features EvolutionAD9284 GSM IN Integrated MSC/SSP Product DescriptionAD9291 Malicious Call TraceAD9320 Extension Services Simultaneous AlertingAD9363 Mobile Access HuntingAD9365 GSM/PCS 1900 Special TranslationAD9388 V.42-bis Data CompressionAD9403 ETSI ISUP Market EnhancementsAD9415 PCS 1900 GSM Local Number PortabilityGR1002 National Number Format of OCN/RDN for CFGR1330 RLT Support for ANSI PRI
Release 7 (GSM07)
AD7988 Account CodeAD7995 ETSI Release Link TrunkAD8001 GSM07 Integrated MSC/SSP Product DescriptionAD8005 Mobile Identification for Emergency CallsAD8006 RLT Implementation for GSMAD8021 GSM Support of 3 Digit Mobile Network CodeAD8028 Multiple VocodersAD8030 ATUP Enhancements for Interworking to the DMS-MSCAD8966 Billing for Off-Board IN Services
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 38 (Approved) 30th March 2005
Release 6(GSM.06)
AD7337 DMS-MSC Voice Mail Call DropbackAD7613 PCS-1900 800 Database QueryAD7614 Phase 2 PRN Support for GSM Data ServicesAD7695 SS7 Compliance & CleanupAD7744 ‘*’ and ‘#’ Translation for GSMAD7809 MSC COLP/COLR Supplementary ServicesAD7839 Functional Support for Phase 2 Bearer CapabilityAD7895 Handover Billing EnhancementsAD7903 Billing Enhancements for Diagnostic and Cause for TerminationAD7904 Addition of Cell of Origin as a Suffix to MS Dialled DigitsAD7916 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 barringAD7170 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 EnhancementsAD6334 DMS-MSC Multi-Party ServiceAD6340 GSM Data Services FPE DevelopmentAD6341 BC/LLC/HLC enhancements for GSM data servicesAD6458 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-ISUPAD6876 Billing Enhancements For MFAE1525 Services Support for BTUP on DMS-MSC
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part A: Introduction30th March 2005 (Approved) Page: 39
Release 3 (GSM.03)
AD4776 Line Identification Supplementary ServicesAD5729 MM support for EIR InterfaceAD5765 BC Modifications and Assignment Request in the MSCAD5768 Provide enhancements to GSM-MSC billing platform and billing capture pointsAD6083 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 SwitchingCentre (DMS-MSC)
Release 01 (GSMR01)
GR2880 eMLPP Enhancements for Mobile SubscribersGR2898 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.
NSS18 Billing and Accounting Q272-1Part A: Introduction Standard APP 4.9Page: 40 (Approved) 30th March 2005
NSS18 Billing and Accounting
Part B:Billing Records and Formats
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 43
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 MSC’s billing capabilities:
• Section B2, ‘Billing Files and CDRs’ on page 49 describes the format of the billing file and the CDRs it contains
• Section B3, ‘Production of Call Detail Records’ on page 57 describes the production of CDRs for different calls
• Section B4, ‘Structured Records and Modules’ on page 77 describes the call records and modules which may be captured in CDRs
• Section B5, ‘Data Field Descriptions’ on page 131 describes the data fields in the CDRs
• Section B6, ‘Example Call Scenarios’ on page 275 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, Administrationand Customer Care
System
Public LandMobile Network
Call DetailRecords
Mediation Device
Telecommunications ManagementNetwork (TMN)
File Transfer InterfaceMSC
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 44 (Approved) 30th March 2005
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 one of two hardware platforms: the new Core and Billing Manager (CBM) or the existing Supernode Data Manager (SDM). These hardware platforms are co-located with the MSC and physically connected to it with high speed data links. In effect they are MSC peripherals. The hardware platforms provide the disk storage for the billing files, backup facilities and the file transfer interfaces to the downstream processor.
The SBA with the CBM is shown in Figure 4. The CBM is connected to the MSC via a high-speed 100MBits/s ethernet connection. The SBA with the SDM platform is shown in Figure 5. The SDM is an off-board peripheral device connected to the DMS bus using DS-512 fibre optic links.
1. There are a number of different terms used for the BACCS. These include billing centre and administration centre (ADC).
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 45
Figure 4 MSC with the SBA/CBM billing architecture
The CBM is co-located with the MSC.The connection is via a 100Mbits/s
DownstreamProcessor (DSP)
CoreMSC
Files of billing data transferred to a downstream processor.
CDR FormattingFormat data into CDRs
Call ProcessingCapture of callevent data
KeyStorage of billing files:
Backup DVDs sent to a downstream processor.
Primary streamSecondary stream
CBM
Backup
Disks
DMS Bus
FTP
SBA Buffer/Comms System
Write data tophysical devices
Transfer of billing files:Primary streamSecondary stream
Recovery
SecondaryStream
PrimaryStream
DVDbackup
FTP
FTAM
SBA
Recovery
EthernetLAN FTAM
ethernet LAN.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 46 (Approved) 30th March 2005
Figure 5 MSC with the SBA/SDM billing architecture
In normal operation, the billing information produced by the CDR formatting function is buffered in the SBA buffer and then written to CBM/SDM disks using the primary stream. If the SBA is unable to accept billing records, they are written to backup disk storage configured on the MSC. When the SBA is available again, the system enters recovery mode and the backed up records are transferred to the CBM/SDM disks in the secondary stream. For information on the production of the billing file refer to Section B2.1. For more information on the capabilities of the SBA, the CBM and the SDM, refer to the Billing Application OA&M Manual [14].
DownstreamProcessor (DSP)
CoreMSC
Files of billing data transferred to a downstream processor.
DAT
CDR FormattingFormat data into CDRs
Call ProcessingCapture of callevent data
KeyStorage of billing files:
Digital Audio Tape
Backup tapes sent to a downstream processor.
Primary streamSecondary stream
SDM
Backup
Disks
DMS Bus
FTP
SBA Buffer/Comms System
Write data tophysical devices
Transfer of billing files:Primary streamSecondary stream
Recovery
SecondaryStream
PrimaryStream
Tapebackup
FTP
FTAM
SBA
Recovery
EthernetLAN FTAM
The SDM is co-located with the MSC.The connection is via a DS-512 fibre optic links.
(DAT)
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 47
The SBA may be connected through a file transfer interface to a downstream processor (DSP). Asshown in Figure 3, this processor is either the BACCS or a mediation device. The SBA on the CBM/SDM provides the file transfer protocol (FTP) and the File Transfer, Access and Management(FTAM) file transfer interfaces. Using FTP a craftsperson can set up a schedule on the SBA to sendbilling records to the DSP either after the files are closed with the Outbound FTP feature, or whilethe file is open for real time transfer via Open File FTP. Alternatively the DSP can use the FTP con-nection to pull records from the SBA. Using the FTAM interface, the DSP pulls records from theSBA: the SBA responds to commands initiated by the DSP. The FTAM interface operates over anEthernet network with ISO 8802-3 at the Data Link Layer. For more information, please refer to theGSM Supernode Billing Application Interface Guide.
Some operators do not use the file transfer interface. Instead, they use the backup DVDs (CBM only) or Digital Audio Tape (DAT on the SDM only) for file transfer. To do this they send the DVDs or tapes 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. For information on the tape formats supported by the SDM, please refer to Section B2.3 on page 52.
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 secondary streams 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 secondary streams just like the normal billing stream.
B1.2.2 Storage Capacity of the Billing Platforms
The CBM and the SDM store records to hard disk:
• the CBM has one active 72 Gigabyte disk with three mirror disks
• the SDM contains dual 9 Gigabyte disk drives.
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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 48 (Approved) 30th March 2005
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 49
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 format of the billing file on tape (SDM only)
• Section B2.4 describes the billing example CDROM.
• Section B2.5 describes the naming convention used for billing files
• Section B2.6 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 6. Production of hot billing records is described in sections B3.5 on page 64 and D1 on page 349.
Figure 6 Production of the billing file in the normal billing stream
CDR Formatting Core
Active primary and secondary billing files containing CDRs packed into 2Kbyte
Callinformation
SBA Buffer/Comms System
Formatter
Buffers
CDR CDR CDR
CDR CDR CDR
data blocks
Formatted CDRs writtento buffers in the SBA buffer/
CDRs sent in the normal stream(e.g. GCDR) to disk in primaryand secondary streamsCDRs written to backup storage
if communication with the SBAfails
Backup
Recovery
Comms system.
SBA
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 50 (Approved) 30th March 2005
The MSC call processing facility establishes call connections. When a call is disconnected the CDR formatting function formats the call information to produce CDRs and packs them into a buffer. When the buffer is full, when the 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 stream to the disks. This is the normal mode of operation: one billing file is active and it is updated with records in the primary stream.
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 secondary stream.
When recovery starts, the currently active billing file (in the primary stream) will receive a record which is obviously out of sequence. When this happens the SBA closes the file and opens a new active file (an out of sequence record is one of the rotation criteria which causes the SBA to close one file and open another). The new active file receives all of the records generated since recovery. At the same time, the secondary billing file may still be receiving the backed up records in the secondary stream. Because of this, there may be two active files open during recovery, one receiving information from the primary stream and the other from the secondary stream. The net effect of this form of SBA operation is that every billing file contains records which are in sequence and the files together 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 57.
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 7.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 51
Figure 7 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.
... ... ... ... ... ... ... ...
BlockDescriptor
Word
RecordDescriptor
Word
BlockHeaderRecord
RecordDescriptor
Word
FileTransfer In
RecordIgnored area
BlockDescriptor
Word
RecordDescriptor
Word
BlockHeaderRecord
RecordDescriptor
WordCDR
BlockDescriptor
Word
RecordDescriptor
Word
BlockHeaderRecord
RecordDescriptor
WordCDR
RecordDescriptor
Word
File Trans.Out
Record
Structured RecordRecord Header
Data Fields
Module: OneData Fields
Module Segment
Module: TwoData Fields
Block 1
Block 2
Block n
Billing File Blocks
Ignored area............
...... Ignoredarea
Module: NData Fields
2 Kbytes
A record descriptor word ...... and associated CDR
Key
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 52 (Approved) 30th March 2005
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 secondary streams. 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 Digital Audio Tape (DAT) Formats for the SDM
The tape backup capability allows a craftsperson to copy billing data from the SDM disk to DAT. The tape formats and their use are shown in Table 3.
The STD format is the default tape format for the SDM tape drive. The FPTAPE and STDSWAP formats are being supported to enable existing customers to interface to the SDM with minimal impact to their environment. For more information on the tape formats, please refer to the GSM SuperNode Billing Application OA&M Guide. For information about how failure (exceptional) conditions affect the way billing information is stored, please refer to the end of Section B2.1 which describes the exception and recovery procedures.
B2.4 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.
Tape Format Description
STD Standard IBM tape formatSTDSWAP Standard IBM tape format - byte swappeda
a. As an example of byte swapping, VOL1 would be stored as OV1L (V and O swapped, followed by L and 1 swapped).
FPTAPE Nortel proprietary
Table 3 Tape Formats Supported by the SDM
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 53
B2.5 File Naming Conventions
B2.5.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.
B2.5.2 Conventions used by the DRM Management Function
The SBA can be configured to produce billing files which use the DRM (Distributed Recording Manager) file naming conventions. In the DRM convention, the first character indicates of the type of the file (active, unprocessed, processed, removed). The second character indicates whether or not the file has been backed up. Characters 3 to 12 indicate the date and time at which the file was generated. The two digits used for the year imply the following:
50 - 99 indicate the years 1950 - 1999 00 - 49 indicate the years 2000 - 2049
Characters 13 and 14 carry a sequence number allocated to prevent duplicate filenames. The remaining characters indicate the type of application generating the file. The extension used to indicate a standard billing file or a hot billing file may be chosen via provisioning. A typical selection for a standard billing file may be GCDR and a typical selection for a hot billing file may be GHOT.
Character1
Character 2-Character 7
Character 8-Character 11
Character 12 -Character 13
Character 14 -Character N
File Type Date Time Sequence Number Application Name
A - Active YY - Year HH - Hour XX - Integer value Filename e.g. GCDRU - Unprocessed MM - Month MM - Minute
P - Processed DD - Day
Example: Filename: A971031102204GCDR (Active file, 31st October 1997, 10:22am, 04, standard billing file)
Character1
Character 2
Character 3 -Character 8
Character 9 -Character 12
Character 13 -Character 14
Character 15 -Character N
File Type Back-up State Date Time Sequence Number Application Name
A - Active N - Not Backed Up YY - Year HH - Hour XX - Integer value Filename e.g. GCDR, GHOTU - Unprocessed B - Backed Up MM - Month MM - Minute
P - Processed DD - Day
Example: Filename: AN971031102204GCDR (Active file, not backed up, 31st October 1997, 10:22am, 04, standard billing file)
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 54 (Approved) 30th March 2005
The file type provides information on the status of the file. An (A)ctive file is one which is open and having CDRs written to it as calls are processed. An (U)nprocessed file is closed and no longer collecting records but as yet it has not been processed by the DSP. A (P)rocessed file is closed and has been processed by the DSP. The operator can use the file type and the backup status to manage the storage of the billing files, for example removing backed up files with file type P from the disk to free up space for new billing files.
B2.6 The MSC CDR Structure
The structure of a MSC billing record is shown in Figure 8. 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 8 The MSC call and event record structure (informative)
Record Header
Module One
Module Two
End of Module List
Structured Record
Detailed Record
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 55
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.
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 60).
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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 56 (Approved) 30th March 2005
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 57
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
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 58 (Approved) 30th March 2005
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 89. 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 275.
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’.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 59
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 283.
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’
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 60 (Approved) 30th March 2005
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 287.
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 subscriber’s 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 61
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 can’t 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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 62 (Approved) 30th March 2005
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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 63
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.
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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 64 (Approved) 30th March 2005
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 subscriber’s 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 65
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).
NOTE Hot billing is supported on the SBA billing platform, but only using the FTAM connection. This is because FTAM allows access to the current active file and the retrieval of the records in near real time.
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:
• Mobile originated call attempt
• Mobile terminated call attempt
• Short message service, mobile originated
• Short message service, mobile terminated
• Common equipment usage
• Supplementary Service Action Record
• Location Services (LCS) Record
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 66 (Approved) 30th March 2005
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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 67
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 106, ‘ITU-T ISUP cause values’ on page 175Table 107, ‘ANSI ISUP cause values’ on page 176Table 109, ‘GSM TSs 04.68 and 04.69 GCC and BCC cause values’ on page 178Table 110, ‘ATUP cause values and error codes’ on page 179Table 111, ‘Blue Book TUP cause values and error codes’ on page 179Table 112, ‘Italian TUP (ITTUP) cause values and error codes’ on page 179Table 113, ‘MTUP cause values and error codes’ on page 180Table 114, ‘MF cause values and error codes’ on page 180
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 108, ‘3GPP TS 24.008 radio layer 3 cause values’ on page 177). For full information see Section B5.2.51, ‘Diagnostic’ on page 173.
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 9.
Figure 9 Example call release values in mobile to mobile calls
MSC
A
roaming
Mobile B sends release with CFT valueRadio layer 3
mobiletermination withCFT=03 and
mobile originationwith CFT=03 and
diagnostic=00019diagnostic=00019
User alerting, no answer
MSC
A
roaming mobile
termination withCFT=03 and
mobile originationwith CFT=03 and
diagnostic=00017diagnostic=00017
User busy
release
Radio layer 3release
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 68 (Approved) 30th March 2005
The cause for termination and diagnostic values are propagated from the releasing agent’s 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 10 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 10 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 network5. 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 10 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 trunkATUP releases call
PSTN ATUP releases
call
ANSI ISUP Cause Value 017
incoming trunkbilling record with ANSI ISUPCFT=03 and
Radio layer 3 receives release from ANSI ISUP
billing record with CFT=03 and ATUP
of 03009
incoming trunkbilling record with CFT=03and ATUP diagnostic value
diagnostic value
of 04017diagnostic valueof 04017
with ANSI ISUPCFT=03 and
mobile termination
diagnostic value
1
2 3
3
6
6
4of 03009
MSC B5
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 69
ls
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 MSC’s 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 GCDR600 logs on/off.
Generation of GHOT 600 logs for hot billing
GSM_HOTBILLING_REPORT OFCVAR Switches the generation of GHOT600 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 calon/off. If on, call records for emergency calls are directed to the hot billingstream.
Table 4 Office parameters controlling the generation of billing information
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 70 (Approved) 30th March 2005
rs
r.
r n f
s.
is -
ff
r
,
Generation of hot billing records for inbound roaming subscribers.
MARK_ROAMER_HOT OFCVAR Switches the generation of hot billing records for inbound roameon/off. If on, billing records for inbound roamers are directed to the hot billing stream.
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 entryin the table and the IPADDR for each MGW sets its MGW Numbe
Call durationThese 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_ROUNDING 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 fotenths of seconds, the call duratiois rounded up to the nearest tenth oa 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 secondThe rounding parameter has threesettings: rounded up, rounded down or rounded to the nearest integer. The default setting is rounded up.
Short Message Service, Mobile OriginatedShort Message Service, Mobile TerminatedIN information module appended to the Short Message Service, Mobile Originated
SMS_BILLINGSee Table 5 for more information.
OFCVAR Switches SMS record generation on/off. If on, the IN information module appended to the SMS MO recordfor IN SMS services based on CS1R INAP, not the UMTS CAMELstandard.
CAMEL SMS information module appended to the Short Message Service, Mobile Originated record
SMS_IN_BILLINGSee Table 5 for more information
OFCVAR Switches module generation on/ofor 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 fosubscribers provisioned with CAMEL M-CSI who trigger the CAMEL mobility management service. If set to Y, the record is producedbut if set to N, the record is not produced. The UMTS MSC CAMEL P3 SOC must also be switched on.
Record Type/Billing Information Office Parameter/Table Data Table Function
Table 4 Office parameters controlling the generation of billing information
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 71
f.
re
f.
f.
g
D /
d
g
e
e er
ls
Supplementary Service Action GSM_CISS_BILLING OFCVAR Switches record generation on/ofIf it is on, table GCISSCDR determines which CISS records aproduced.
Common Equipment Usage ENABLE_CEU_RECORD OFCVAR Switches record generation on/of
Mobile originated and terminatedIncoming gateway call attemptIncoming intra-PLMN trunk recordOutgoing gateway call attemptOutgoing intra-PLMN trunk recordRoaming 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/of
Incoming gateway call attemptIncoming intra-PLMN trunk recordOutgoing gateway call attemptOutgoing intra-PLMN trunk recordTransit
CONN, DIR, TRKGRPS and CDRREQ fields
RTEGRP These fields determine the trunksand trunk groups for which billinrecords are generated.
Partial billing information: the partial information module is appended to billing records
GSM_PB_REC_GEN_ENABLEDGSM_PB_INTERVALGSM_CDR_MAX_SIZE
OFCVAROFCENGOCFVAR
GSM_PB_REC_GEN_ENABLEswitches partial billing records onoff. If it is on, the frequency at whichpartial information is generated another 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 6 for information on how this may be overridden by the GSM Generic Address Info SOC option.
OFCVAR Switches on/off the generation ofthe 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 6 for information on how this may be overridden by the GSM Generic Address Info SOC option.
OFCVAR If on, the original calling numbernot the redirecting number is captured for billing purposes.
Original calling number is captured in 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 callinnumber 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 officparameter USE_OR IGINAL_ CGPN_FOR_BILLING determinwhether the original calling numbor 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 calwith a number of legs, the callingnumber might be lost. If this parameter is on, the redirecting number is used instead.
Record Type/Billing Information Office Parameter/Table Data Table Function
Table 4 Office parameters controlling the generation of billing information
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 72 (Approved) 30th March 2005
.
er
es
t
o s
to e g s
G
et
d
g
s, ta
.
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 OFCVAR The LIU_PROCESSING parameter determines whether intra-BSC messaging is processedIf set to PASS_THRU_LIU the BSC sends the intra-BSC handovmessaging to the MSC. If set to CONSUME_IN_LIU the BSC donot send this messaging. It only sends the MSC information abouinter-BSC handover
The BILLING parameter determines whether or not billinginformation is generated for handover. If the parameter is set tBILLING_ON the MSC generatebilling 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-MSC also has this parameter set thsame way, it sends any intra-BSChandover and inter-BSC messaginto the anchor MSC which captureit in the handover billing records.
The INTER_MSC_PROCESSINparameter determines whether or not the handed-to MSC sends information about intra-MSC handover to the anchor MSC. If sto SEND_FROM_MSCB, the handed-to MSC does send the information to the anchor MSC anif set to NO_SEND_FROM_ MSCB it does not. If set to NO_ SEND_FROM_ MSCB, the billinbilling records generated on the anchor MSC capture informationabout the initial inter-MSC handover, but no information on any subsequent intra-BSC hand overs on the handed-to MSC. Note: if MAP Phase 1 is used on the E interface between two MSCthe generation of this handover dais controlled by NOTE_ INTERNAL_HANDOVER_ SUPPORTED in Table OFCENG
Record Type/Billing Information Office Parameter/Table Data Table Function
Table 4 Office parameters controlling the generation of billing information
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 73
s e
-
is
g e t f
s to
t
l
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 ialso dependent on the setting of thHO_PERFORMED_ PROCESSING office parameter listed above.
Incoming gateway call attempt or Incoming intra-PLMN trunk record 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 handedto MSC. The record is not generated if the office parameters 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 ReportinControl (LRC) message which thMSC sends to the RNC to requeslocation information in the form othe Service Area Identifier (SAI).If set to direct, the MSC does notsend the LRC during initial call setup, but during relocation it sendan LRC with the request type set direct after the Relocation Complete message. If set to chg_of_service_area, theMSC sends the LRC with the request type “change of service area” after the initial UE messageand during relocation, it sends theLRC after the Relocation RequesAck 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 toR99, Release 99 LCS informationis generated.
Wireless Priority Service information captured in an SS information module
ENABLE_WPS_CALL_INDICATOR_IN_CDR
OFCVAR If set to yes, the WPS billing information is generated for WPScalls originated on the MSC. TheWPS 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 theService Control Point for routinginformation to the emergency calcentre.
Record Type/Billing Information Office Parameter/Table Data Table Function
Table 4 Office parameters controlling the generation of billing information
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 74 (Approved) 30th March 2005
NOTE The two office parameters in this table are completely independent of each other.
B3.8.2 Software Optionality Control (SOC)
Combination In Table OFCVAR Result
SMS_BILLING SMS_IN_BILLING SMS Billing Records CAMEL SMS module
Nor
mal
SMS-
Cal
ls
Y Y Yes N-A
Y N Yes N-A
N Y No N-A
N N No N-A
CA
MEL
Pha
se 3
SMS-
CSI
Cal
ls Y Y Yes Yes
Y N No No
N Y Yes Yes
N N No No
Table 5 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 P3Dependent 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.
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 4. 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.
Table 6 SOC options controlling the generation of billing information
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 75
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 RequestLCS MT Loc RequestLCS 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.
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.
Information SOC Option Function
Table 6 SOC options controlling the generation of billing information
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 76 (Approved) 30th March 2005
B3.8.3 Office Alarms for Billing
The operator can set the CHKBIL office alarm to provide a warning when billing system’s 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 77
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 Rela
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 78 02 0002 001Section B4.1.2, ‘Mobile Terminated Call Attempt’ on page 79 02 0003 002Section B4.1.3, ‘Roaming Call Attempt’ on page 80 03 0018 014Section B4.1.4, ‘Incoming Gateway Call Attempt’ on page 81 03 0013 011Section B4.1.5, ‘Outgoing Gateway Call Attempt’ on page 82 03 0014 012Section B4.1.6, ‘Transit Call Attempt’ on page 83 03 0017 012Section B4.1.7, ‘Short Message Service, Mobile Originated’ on page 84 05 0004 005Section B4.1.8, ‘Short Message Service, Mobile Terminated’ on page 85 05 0005 006Section B4.1.9, ‘Incoming Intra-PLMN Trunk Record’ on page 86 03 0015 011Section B4.1.10, ‘Outgoing Intra-PLMN Trunk Record’ on page 87 03 0016 012Section B4.1.11, ‘Common Equipment Usage Record’ on page 88 04 0019 015Section B4.1.12, ‘Supplementary Service Action Record’ on page 89 09 0006 004Section B4.1.13, ‘Location Services (LCS) Record’ on page 91 15 0021 017Section B4.1.14, ‘Acknowledgement Record’ on page 92 GSMR02 0020 016Section B4.1.15, ‘Location Update Record’ on page 93 17 0001 003
Switch records Section B4.1.16, ‘Time Change Record’ on page 94 02 0009 008Section B4.1.17, ‘Switch Restart Record’ on page 94 02 0010 009
Billing file structure records
Section B4.1.18, ‘Billing Block Header Record’ on page 95 02 0011 010Section B4.1.19, ‘Billing File Transfer In Record’ on page 95 02 0007 007Section B4.1.20, ‘Billing File Transfer Out Record’ on page 96 02 0008 007
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 78 (Approved) 30th March 2005
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 101) captures details of the call forwarding SS.
Data Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Call forward Indicator C B5.2.16 2
Calling Party C B5.2.26 30
Calling Number C B5.2.25 30
Called Number C B5.2.21 40
Calling Equipment C B5.2.24 22
Additional Information M B5.2.3 4
Channel Allocation Time C B5.2.31 16
Answer Time C B5.2.6 16
Disconnect Time C B5.2.53 16
Release Time C B5.2.162 16
Off Air Call Setup X B5.2.124 2
Half Rate in Use C B5.2.70 2
Cause for Termination M B5.2.29 4
Call Reference M B5.2.18 8
MS Classmark C B5.2.111 16
Classmark Time Stamp C B5.2.36 16
Dialled Digits C B5.2.52 34
Outgoing Trunk Group C B5.2.134 6
Outgoing Trunk Member C B5.2.135 6
Outgoing Route Group C B5.2.79 4
Trunk Seizure (Outgoing) C B5.2.81 16
Calling Subscriber Category C B5.2.27 4
Call Indicator C B5.2.17 8
Call Duration M B5.2.15 14
Diagnostic C B5.2.51 6
MSC Number M B5.2.114 28
Record Number M B5.2.156 12
Total Size 398
Table 7 Mobile originated call attempt structured record
Structure 0002 Call Type 001Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 79
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 101) captures details of the call forwarding SS.
Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Call forward Indicator C B5.2.16 2
Called Party M B5.2.22 30
Calling Number C B5.2.25 30
Called Number C B5.2.21 40
Called Equipment C B5.2.20 22
Additional Information M B5.2.3 4
Channel Allocation Time C B5.2.31 16
Answer Time C B5.2.6 16
Disconnect Time C B5.2.53 16
Release Time C B5.2.162 16
Off Air Call Setup X B5.2.124 2
Half Rate in Use C B5.2.70 2
Cause for Termination M B5.2.29 4
Call Reference M B5.2.18 8
MS Classmark C B5.2.111 16
Classmark Time Stamp C B5.2.36 16
Incoming Trunk Group C B5.2.82 6
Incoming Trunk Member C B5.2.83 6
Incoming Route Group C B5.2.79 4
Trunk Seizure (Incoming) C B5.2.81 16
Called Subscriber Category C B5.2.23 4
Call Indicator C B5.2.17 8
Call Duration M B5.2.15 14
Diagnostic C B5.2.51 6
MSC Number M B5.2.114 28
Record Number M B5.2.156 12
Total Size 364
Table 8 Mobile terminated call attempt structured record
Structure 0003 Call Type 002Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 80 (Approved) 30th March 2005
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 69.
Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Called Party M B5.2.22 30
Called Number C B5.2.21 40
Calling Number C B5.2.25 30
Roaming Number M B5.2.167 30
MSC Number M B5.2.114 28
Incoming Trunk Group C B5.2.82 6
Incoming Trunk Member C B5.2.83 6
Incoming Route Group C B5.2.79 4
Outgoing Trunk Group M B5.2.134 6
Outgoing Trunk Member M B5.2.135 6
Outgoing Route Group C B5.2.79 4
Trunk Seizure (Incoming) C B5.2.81 16
Trunk Seizure (Outgoing) C B5.2.81 16
Answer Time C B5.2.6 16
Trunk Release (Outgoing) C B5.2.80 16
Call Duration M B5.2.15 14
Logical Network C B5.2.104 4
Metering Zone C B5.2.106 4
Cause for Termination M B5.2.29 4
Diagnostic C B5.2.51 6
Call Reference M B5.2.18 8
Call Indicator C B5.2.17 8
Record Number M B5.2.156 12
Total Size 334
Table 9 Roaming call attempt structured record
Structure 0018 Call Type 014Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 81
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 69.
Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Calling Number C B5.2.25 30
Called Number M B5.2.21 40
MSC Number M B5.2.114 28
Incoming Trunk Group M B5.2.82 6
Incoming Trunk Member M B5.2.83 6
Incoming Route Group C B5.2.79 4
Outgoing Trunk Group C B5.2.134 6
Outgoing Trunk Member C B5.2.135 6
Outgoing Route Group C B5.2.79 4
Trunk Seizure (Incoming) M B5.2.81 16
Answer Time C B5.2.6 16
Trunk Release (Incoming) C B5.2.80 16
Call Duration M B5.2.15 14
Cause for Termination M B5.2.29 4
Diagnostic C B5.2.51 6
Logical Network C B5.2.104 4
Metering Zone C B5.2.106 4
Incoming Metering Class C B5.2.78 4
Call Reference M B5.2.18 8
Record Number M B5.2.156 12
Total Size 254
Table 10 Incoming gateway call attempt structured record
Structure 0013 Call Type 011Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 82 (Approved) 30th March 2005
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.
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 69.
Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Calling Number C B5.2.25 30
Called Number M B5.2.21 40
MSC Number M B5.2.114 28
Incoming Trunk Group C B5.2.82 6
Incoming Trunk Member C B5.2.83 6
Incoming Route Group C B5.2.79 4
Outgoing Trunk Group M B5.2.134 6
Outgoing Trunk Member M B5.2.135 6
Outgoing Route Group C B5.2.79 4
Trunk Seizure (Outgoing) M B5.2.81 16
Answer Time C B5.2.6 16
Trunk Release (Outgoing) C B5.2.80 16
Call Duration M B5.2.15 14
Cause for Termination M B5.2.29 4
Diagnostic C B5.2.51 6
Logical Network C B5.2.104 4
Metering Zone C B5.2.106 4
Outgoing Metering Class C B5.2.78 4
Call Reference M B5.2.18 8
Record Number M B5.2.156 12
Total Size 254
Table 11 Outgoing gateway call attempt structured record
Structure 0014 Call Type 012Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 83
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.
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 69.
Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Calling Number C B5.2.25 30
Called Number M B5.2.21 40
MSC Number M B5.2.114 28
Incoming Trunk Group C B5.2.82 6
Incoming Trunk Member C B5.2.83 6
Incoming Route Group C B5.2.79 4
Outgoing Trunk Group M B5.2.134 6
Outgoing Trunk Member M B5.2.135 6
Outgoing Route Group C B5.2.79 4
Trunk Seizure (Outgoing) M B5.2.81 16
Answer Time C B5.2.6 16
Release Time (Outgoing) C B5.2.80 16
Call Duration M B5.2.15 14
Cause for Termination M B5.2.29 4
Diagnostic C B5.2.51 6
Logical Network C B5.2.104 4
Metering Zone C B5.2.106 4
Outgoing Metering Class C B5.2.78 4
Call Reference M B5.2.18 8
Record Number M B5.2.156 12
Total Size 254
Table 12 Transit call attempt structured record
Structure 0017 Call Type 012Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 84 (Approved) 30th March 2005
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 69.
Data Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Calling Party M B5.2.26 30
Calling Number M B5.2.25 30
Called Number M B5.2.21 40
Calling Equipment C B5.2.24 22
MSC Number M B5.2.114 28
Service Centre M B5.2.177 28
SMS Timestamp M B5.2.184 16
Delivery Timestamp C B5.2.48 16
Call Reference C B5.2.18 8
Cause for Termination C B5.2.29 4
Message Reference M B5.2.105 6
MS Classmark M B5.2.111 16
SMS Result C B5.2.181 6
SMS Message Type M B5.2.179 2
SMS Validity Period C B5.2.185 18
Record Number M B5.2.156 12
Total Size 302
Table 13 SMS mobile originated record
Structure 0004 Call Type 005Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 85
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 69.
Data Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Called Party M B5.2.22 30
Calling Number M B5.2.25 30
Called Number M B5.2.21 40
Called Equipment C B5.2.20 22
MSC Number M B5.2.114 28
Service Centre M B5.2.177 28
SMS Timestamp M B5.2.184 16
Delivery Timestamp C B5.2.48 16
Call Reference M B5.2.18 8
Cause for Termination C B5.2.29 4
MS Classmark M B5.2.111 16
SMS Result X B5.2.181 6
Record Number M B5.2.156 12
Total Size 276
Table 14 SMS mobile terminated record
Structure 0005 Call Type 006Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 86 (Approved) 30th March 2005
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.
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 69.
Field Reference Size
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Calling Number C B5.2.25 30
Called Number M B5.2.21 40
MSC Number M B5.2.114 28
Incoming Trunk Group M B5.2.82 6
Incoming Trunk Member M B5.2.83 6
Incoming Route Group C B5.2.79 4
Outgoing Trunk Group C B5.2.134 6
Outgoing Trunk Member C B5.2.135 6
Outgoing Route Group C B5.2.79 4
Trunk Seizure (Incoming) M B5.2.81 16
Answer Time C B5.2.6 16
Trunk Release (Incoming) C B5.2.80 16
Call Duration M B5.2.15 14
Cause for Termination M B5.2.29 4
Diagnostic C B5.2.51 6
Logical Network C B5.2.104 4
Metering Zone C B5.2.106 4
Incoming Metering Class C B5.2.78 4
Call Reference M B5.2.18 8
Record Number M B5.2.156 12
Total Size 254
Table 15 Incoming intra-PLMN trunk structured record
Structure 0015 Call Type 011Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 87
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.
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 69.
Field Reference Size (characters)
Record Header M B5.2.155 18
Study Indicator M B5.2.187 2
Calling Number C B5.2.25 30
Called Number M B5.2.21 40
MSC Number M B5.2.114 28
Incoming Trunk Group C B5.2.82 6
Incoming Trunk Member C B5.2.83 6
Incoming Route Group C B5.2.79 4
Outgoing Trunk Group M B5.2.134 6
Outgoing Trunk Member M B5.2.135 6
Outgoing Route Group C B5.2.79 4
Trunk Seizure (Outgoing) M B5.2.81 16
Answer Time C B5.2.6 16
Trunk Release (Outgoing) C B5.2.80 16
Call Duration M B5.2.15 14
Cause for Termination M B5.2.29 4
Diagnostic C B5.2.51 6
Logical Network C B5.2.104 4
Metering Zone C B5.2.106 4
Outgoing Metering Class C B5.2.78 4
Call Reference M B5.2.18 8
Record Number M B5.2.156 12
Total Size 254
Table 16 Outgoing intra-PLMN trunk structured record
Structure 0016 Call Type 012Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 88 (Approved) 30th March 2005
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 69.
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.
Field Reference Size (characters)Record Header M B5.2.155 18Study Indicator M B5.2.187 2Equipment Identity C B5.2.57 6 Equipment Type M B5.2.58 6Served Party M B5.2.26 30Served Number M B5.2.25 30MSC/MGW Number M B5.2.115 28 Date and Time (Seizure) M B5.2.45 16Date and Time (Release) M B5.2.45 16Call Duration M B5.2.15 14Call Reference M B5.2.18 8Record Number M B5.2.156 12Total Size 186
Table 17 Common equipment usage structured record
Structure 0019 Call Type 015Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 89
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.
Data Field Reference Size (characters)Record Header M B5.2.155 18Study Indicator M B5.2.187 2Served Party M B5.2.26 30Served Number C B5.2.25 30Served Equipment C B5.2.24 22Call Reference C B5.2.18 8Supplementary Service Code C B5.2.190 4Supplementary Service Action C B5.2.189 2Date and Time M B5.2.45 16Supplementary Service Parameters C B5.2.191 32Result Indicator C B5.2.165 4MSC Number M B5.2.114 28Location Area Code C B5.2.103 12Cell-SAC Id C B5.2.30 6Access Network M B5.2.2 2MS Classmark M B5.2.111 16Hot Billing Indicator M B5.2.72 2Record Number M B5.2.156 12Total Size 246
Table 18 Supplementary service action structured record
Structure 0006 Call Type 004Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 90 (Approved) 30th March 2005
NOTE On the MSC, provisioning allows the enabling and disabling of this record (Please seeSection B3.8 on page 69). If required the production of this record may be disabled. Ifrecord production is enabled, further provisioning in table GCISSCDR defines the particularservices 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/SSaction and N to turn record generation off. An entry of means that the setting cannot bechanged as there is no action defined in the GSM/UMTS standards.
Service Activate/Register Deactivate/Erase Interrogate InvokeCalling 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 19 Table GCISSCDR
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 91
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 subscriber’s 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.155 18
Study Indicator M M M B5.2.187 2
LCS Record Type M M M B5.2.99 2
Served Party M M C B5.2.176 16
LCS Client Type X M C B5.2.95 4
LCS Client Id C C C B5.2.94 32
LCS Initiation Time M M M B5.2.97 16
LCS Termination Time M M M B5.2.101 16
Geographical Location of Target UE 1 C M M B5.2.64 42
Geographical Location of Target UE 2 C C C B5.2.65 42
Geographical Location of Target UE 3 C C C B5.2.66 42
Geographical Location of Target UE 4 C C C B5.2.67 42
Geographical Location of Target UE 5 C C C B5.2.68 24
Age of Location X C C B5.2.5 6
Requested Quality of Service (QoS) C C C B5.2.163 12
LCS Result C C C B5.2.100 4
MSC Number M M M B5.2.114 28
Served MSISDN C C C B5.2.175 30
Requesting MLC C M C B5.2.164 26
Privacy Notification X C C B5.2.150 2
Privacy Override X C C B5.2.151 2
Positioning Data C C C B5.2.143 28
LCS Diagnostic C C C B5.2.96 2
System Type C C C B5.2.192 2
Served IMEI X X C B5.2.173 16
Emergency Service Routing Digits (ESRD-Digits) X X C B5.2.55 16
Emergency Service Routing Key (ESRK-Key) X X C B5.2.56 12
LCS Priority Level X X C B5.2.98 4
Record Number M M M B5.2.156 12
Total Size 500
Table 20 Location Services (LCS) Record
Structure 0021 Call Type 017Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 92 (Approved) 30th March 2005
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.
Data Field Reference Size (characters)Record Header M B5.2.155 18Study Indicator M B5.2.187 2Calling Number C B5.2.25 30Called Number C B5.2.21 40MSC Number M B5.2.114 28Record Time M B5.2.157 16Priority Call Tag M B5.2.147 2Group Call Reference M B5.2.69 10Functional Number M B5.2.63 16Priority Level M B5.2.148 4Priority Call Cause M B5.2.145 4Priority Call Duration M B5.2.146 10Priority Release Time M B5.2.149 12Hot Billing Indicator M B5.2.72 2Record Number M B5.2.156 12Total Size 206
Table 21 Acknowledgement Record
Structure 0020 Call Type 016Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 93
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.
Data Field Reference Size (characters)Record Header M B5.2.155 18Study Indicator M B5.2.187 2Served IMSI M B5.2.174 30Served MSISDN C B5.2.175 30Recording Entity M B5.2.158 28Old MSC-Id C B5.2.130 28Old LAC C B5.2.129 12Old AN C B5.2.127 2Old Cell - SAC Id C B5.2.128 6New MSC-Id C B5.2.120 28New LAC C B5.2.119 12New AN C B5.2.117 2New Cell - SAC Id C B5.2.118 6MS Classmark C B5.2.111 16Update Time M B5.2.204 16Update Result C B5.2.203 4MM Event C B5.2.109 4Record Number M B5.2.156 12Total Size 256
Table 22 Location Update Record
Structure 0001 Call Type 003Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 94 (Approved) 30th March 2005
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.
Data Field Reference Size (characters)Record Header M B5.2.155 18Auxiliary Record Header M B5.2.7 24Date and Time (Old) M B5.2.45 16Date and Time (New) M B5.2.45 16Record Number M B5.2.156 12Total Size 86
Table 23 Time change structured record
Data Field Reference Size
Record Header M B5.2.155 18
Auxiliary Record Header M B5.2.7 24
Switch Restart Type M B5.2.193 2
Date and Time M B5.2.45 16
Record Number M B5.2.156 12
Total Size 72
Table 24 Switch restart structured record
Structure 0009 Call Type 008Codes
Structure 0010 Call Type 009Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 95
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.
Data Field Reference Size (characters)
Record Header M B5.2.155 18
Auxiliary Record Header M B5.2.7 24
Date and Time M B5.2.45 16
Block Number M B5.2.13 6
Total Size 64
Table 25 Billing block header structured record
Data Field Reference Size (characters)
Record Header M B5.2.155 18
Auxiliary Record Header M B5.2.7 24
Date and Time M B5.2.45 16
File Transfer Type M B5.2.61 4
File Sequence Number M B5.2.60 4
Record Number M B5.2.156 12
Total Size 78
Table 26 Billing file transfer in structured record
Structure 0011 Call Type 010Codes
Structure 0007 Call Type 007Codes
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 96 (Approved) 30th March 2005
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.
Data Field Reference Size (characters)
Record Header M B5.2.155 18
Auxiliary Record Header M B5.2.7 24
Date and Time M B5.2.45 16
File Transfer Type M B5.2.61 4
File Sequence Number M B5.2.60 4
Record Count M B5.2.154 10
Block Count M B5.2.12 6
Record Number M B5.2.156 12
Total Size 94
Table 27 Billing file transfer out structured record
Structure 0008 Call Type 007Codes
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 97
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 28. The content and purpose of each of these modules are described in the following sections.
Customer and market specific modules are defined in Section B4.3 on page 127.
Call Detail Records and Structure Codes
Mob
. Orig
.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.
Mob
. Ter
m.a
Roa
min
g
I/C G
ate
O/G
Gat
e
Tran
sit
SMS
MO
SMS
MT
I/C in
tra
O/G
Intra
CEU
SS A
ctio
n
LCS
Ack
Information Module Attachb
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.
Relc
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 20End of Module List 1 02 00 B4.2.1 on page 98 Y Y Y Y Y Y Y Y Y Y Y Y YBearer Service 0-n 03 02 B4.2.2 on page 98 Y Y Y YLocation and Channel 0-n 02 03 B4.2.3 on page 99 Y Y Y YSupplementary Services 0-n 02 05 B4.2.4 on page 101 Y Y Y d
d. The SS module is appended to trunk records when a dropback service is used.
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 108 Y Y Y Y YAoC Parameter 0-n 03 07 B4.2.6 on page 109 Y YTariff Class 0-n 03 08 B4.2.7 on page 110 Y YData Service 0-1 04 09 B4.2.8 on page 110 Y Y Y Y Y Y Y Other Agent 0-n 04 10 B4.2.9 on page 112 YLocation Only 0-n 05 04 B4.2.10 on page 112 Y Y YEqual Access 0-n 05 12 B4.2.11 on page 113 Y Y Y Y Y Y Y YPartial 0-1 05 13 B4.2.12 on page 114 Y Y Y Y Y Y Y Y YTrunk usage 0-1 06 16 B4.2.13 on page 114 Y Y Y Y YIN Information 0-n 07 18 B4.2.14 on page 115 Y Y Y Y Y Y YIN Charging 0-n 07 19 B4.2.15 on page 118 Y Y Y YGeneric Address 0-1 07 20 B4.2.16 on page 119 Y Y Y Y Y Y Y Network Call Reference 0-1 10 22 B4.2.17 on page 120 Y YCAMEL Charging 0-n 11 23 B4.2.18 on page 121 Y Y YMobile Number Portability 0-n 15 25 B4.2.19 on page 122 Y Y YGSM Assisting SSP 0-n 16 26 B4.2.20 on page 123 Y YCAMEL SMS 0-1 16 27 B4.2.21 on page 124 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 125 Y Y Y Y Y Y YBearer Independent Core Network 0-n 18 29 B4.2.23 on page 126 Y Y Y Y Y Y
Table 28 Information modules
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 98 (Approved) 30th March 2005
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:
• Mobile originated call attempt • Mobile terminated call attempt • Roaming call attempt• 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.
Field Reference Size (characters)
Module Code M B5.2.110 4
Total Size 4
Table 29 End of module list module
Field Reference Size (characters)
Module Code M B5.2.110 4
Bearer Service M B5.2.11 4
Date and Time M B5.2.45 16
Total Size 24
Table 30 Bearer service information module
00Module Code
02Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 99
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt • Incoming gateway call attempt • Incoming intra-PLMN trunk
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)
Field Reference Size (characters)Module Code M B5.2.110 4Roaming Number M B5.2.167 30MSC Number (Note) M B5.2.114 28Incoming Trunk Group M B5.2.82 6Incoming Trunk Member M B5.2.83 6Location Area Code M B5.2.103 12Cell-SAC Id M B5.2.30 6Channel Type M B5.2.33 6Channel Description M B5.2.32 10Date and Time M B5.2.45 16Access Network M B5.2.2 2RNC ID M B5.2.166 6 Total Size 132
Table 31 Location and channel information module
03Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 100 (Approved) 30th March 2005
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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 101
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt • Short message service, mobile originated • Short message service, mobile terminated
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:
• Outgoing intra-PLMN trunk • Incoming intra-PLMN trunk • Incoming gateway • Outgoing gateway • Transit call attempt
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
05Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 102 (Approved) 30th March 2005
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 contain similar information for all services:
Module code which is 005CSS Action which is 5C (invoke)Date and time which captures when the service was invoked
The information is contained in the following tables:
Table 33, ‘Number identification services’ on page 103Table 34, ‘Call forwarding services’ on page 104Table 35, ‘Explicit call transfer service’ on page 104Table 36, ‘Call completion services’ on page 105 Table 37, ‘Community of interest services’ on page 106Table 38, ‘Proprietary services’ on page 106Table 39, ‘GSM railways services’ on page 107
Field Reference Size (characters)
Module Code M B5.2.110 4
SS Code M B5.2.190 4
SS Action M B5.2.189 2
Date and Time M B5.2.45 16
SS Parameters C B5.2.191 32
Result Indicator M B5.2.165 4
Total Size 62
Table 32 Supplementary service information module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 103
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 party’s 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 party’s 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 party’s COLR service prevents the display of the connected number.
Calling Name Delivery (CNAM)
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 33 Number identification services
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 104 (Approved) 30th March 2005
Supplementary Services Information Module
Service SS Code SS Parameters (example) Result 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 FFFFFFFFFFFFFFFFFFFF43664209200CorFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
001Cor037C
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 34 Call forwarding services
Supplementary Services Information Module
Service SS Code SS Parameters (example) Result 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 35 Explicit call transfer service
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 105
Supplementary Services Information Module
Service SS Code SS Parameters (example) Result 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 bythe 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. Duringthe set up of the original call, the terminating switch releases thecall 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 callis an outgoing trunk record (an outgoing intra-PLMN or an outgoing gateway record). The originating record for the secondcall is an incoming trunk record. Both of these records have anappended 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 therelease 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 appendedSS 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 toan 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 messagesent 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 setsup 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 releaseunnecessary call connections. The SS parameters field containsthe calling party number received in the IAM.
Table 36 Call completion services
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 106 (Approved) 30th March 2005
Supplementary Services Information Module
Service SS Code SS Parameters (example) Result Indic
Description
Closed User Group (CUG)
061C FFFFFFFFFFFFFFFFFFFFFF043004566CINIC of 0430Interlock code of 04566
001C Successful capture of CUG details. Format of SS parameters field: Padding with leading FsISDN 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 CUSTGRPChar 5 - SignChars 6-8 NCOSChar 9 - SignChars 10-31 - FsChar 32 - Sign
001C
Table 37 Community of interest services
Supplementary Services Information Module
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 party’s 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.
Table 38 Proprietary services
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 107
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 party’s address) was available in the call trace
005C This result indicates that the captured information is incomplete.
Hot Billing 254C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC 001C
Supplementary Services Information Module
Service SS Code SS Parameters Result Indic
Description
Enhanced Multi-Level Precedence and Pre-emption
0A1C FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4C The priority levels which may be captured are: 4 Priority Level 43 Priority Level 32 Priority Level 21 Priority Level 10 Priority Level 0B Priority Level BA Priority Level A
021C This service is used in GSM-R (railways) networks. 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. Note that the priority level for a call may also be assigned by the network if the calling party is not an eMLPP subscriber. In this case, no SS information module is created.
Table 39 GSM railways services
Supplementary Services Information Module
Service SS Code SS Parameters Result Indic
Description
Table 38 Proprietary services
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 108 (Approved) 30th March 2005
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:
• Mobile originated call attempt • Mobile terminated call attempt • Roaming call attempt • Common equipment usage• 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.
Enhanced Multi-Level Precedence and Pre-emption - Resource Pre-emption
0A1C FFFFFFFFFFFFFFFFFFFFFFFFFFFFF24CThe 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.
Supplementary Services Information Module
Service SS Code SS Parameters Result Indic
Description
Table 39 GSM railways services
06Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 109
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.
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt
Field Reference Size (characters)
Module Code M B5.2.110 4
Teleservice M B5.2.195 4
Date and Time M B5.2.45 16
Total Size 24
Table 40 Teleservices information module
Field Reference Size (characters)Module Code M B5.2.110 4SS-Code M B5.2.190 4Date and Time (NOTE 1) M B5.2.45 16E-Parameter (1) M B5.2.54 6E-Parameter (2) M B5.2.54 6E-Parameter (3) M B5.2.54 6E-Parameter (4) M B5.2.54 6E-Parameter (5) M B5.2.54 6E-Parameter (6) M B5.2.54 6E-Parameter (7) M B5.2.54 6AoC Parm Reason (NOTE 2) M B5.2.4 4Total Size 70
Table 41 AoC parameter information module
07Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 110 (Approved) 30th March 2005
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’.
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:
• Mobile originated call attempt • Mobile terminated call attempt
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt • Roaming call attempt • Outgoing intra-PLMN trunk • Incoming intra-PLMN trunk • Incoming gateway • Outgoing gateway
Field Reference Size (characters)
Module Code M B5.2.110 4
Charge Zone M B5.2.35 6
Subscriber Service M B5.2.188 6
Tariff Class M B5.2.194 6
Total Size 22
Table 42 Tariff class information module
08Module Code
09Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 111
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.
Field Reference Size (characters)Module Code M B5.2.110 4IWF Trunk Group (MS Side) M B5.2.87 6IWF Trunk Member (MS Side) M B5.2.88 6IWF Trunk Group (Network Side) M B5.2.87 6IWF Trunk Member (Network Side) M B5.2.88 6Data Volume X B5.2.44 6Data Rate M B5.2.43 4Connection Element M B5.2.37 2Information Transfer Capability M B5.2.84 2Data Compression M B5.2.42 4Number of Fax Pages C B5.2.121 4IWF Diagnostic Code C B5.2.93 4IWF Activation Timestamp C B5.2.92 16Rate Adaptation M B5.2.153 2Total Size 72
Table 43 Data service information module
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 112 (Approved) 30th March 2005
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.
This module may be appended to the following MSC structured records:
• Short message service, mobile originated • Short message service, mobile terminated• 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)
Field Reference Size (characters)Module Code M B5.2.110 4Terminating Location M B5.2.196 16Total Size 20
Table 44 Other agent information module
Field Reference Size (characters)Module Code M B5.2.110 4MSC Number (Note) M B5.2.114 28Location Area Code M B5.2.103 12Cell-SAC Id M B5.2.30 6Access Network M B5.2.2 2Total Size 52
Table 45 Location only information module
10Module Code
04Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 113
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Incoming gateway call attempt • Outgoing gateway call attempt • Transit call attempt• Incoming intra-PLMN trunk• Outgoing intra-PLMN trunk
Field Reference Size (characters)
Module Code M B5.2.110 4
IC/INC Prefix C B5.2.86 10
Type of Carrier Identification Code C B5.2.198 2
Carrier Connect Timestamp C B5.2.28 16
IC/INC Call Event Status C B5.2.85 4
Total Size 36
Table 46 Equal access information module structure
12Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 114 (Approved) 30th March 2005
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:
• 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
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.
This module may be appended to the following MSC structured records:
• Incoming gateway call attempt • Outgoing gateway call attempt • Transit call attempt• Incoming intra-PLMN trunk• Outgoing intra-PLMN trunk
Field Reference Size (characters)Module Code M B5.2.110 4Partial Record Sequence Number M B5.2.139 6Partial Record Event Code M B5.2.136 4Partial Record Reason M B5.2.137 4Partial Record Reference Number M B5.2.138 8Total Size 26
Table 47 Partial information module
13Module Code
16Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 115
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt • Incoming gateway call attempt • Incoming intra-PLMN trunk• Outgoing gateway call attempt• Outgoing intra-PLMN trunk• Short message service, mobile originated
The module is only appended for IN SMS services using INAP CS1-R. The CAMEL SMS information module (B4.2.21 on page 124) captures information for CAMEL mobile originated SMS.
• Location update record
Field Reference Size (characters)Module Code M B5.2.110 4Trunk Usage Reason M B5.2.197 4Total Size 8
Table 48 Trunk usage information module
18Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 116 (Approved) 30th March 2005
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. 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, 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.
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 SCP’s address.
(continued)
Field Reference Size (characters)Module Code M B5.2.110 4Detection Point C B5.2.50 4Service Key C B5.2.178 12Destination Routing Address C B5.2.49 32SCP (Service Control Point) Address C B5.2.171 22Off-Board IN Service Identifier C B5.2.125 4Off-Board IN Service Indicator C B5.2.126 4Charge Number C B5.2.34 24IN Time Stamp1 C B5.2.76 16IN Time Stamp2 C B5.2.77 16Operation Indication C B5.2.132 2CSI (CAMEL Subscription Information) C B5.2.41 2IN Protocol C B5.2.75 2Local Reference Number C B5.2.102 12SCF ID / ETC Parm1 C B5.2.170 34Correlation ID / ETC Parm2 C B5.2.39 34Total Size 224
Table 49 IN information module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 117
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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 118 (Approved) 30th March 2005
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt• Incoming gateway call attempt• Incoming intra-PLMN trunk
As shown in Table 50, 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.
Field Reference Size (characters)Module Code M B5.2.110 4FCI Freeform 1 M B5.2.59 46FCI Freeform 2 M B5.2.59 46FCI Freeform 3 M B5.2.59 46Total Size 142
Table 50 IN charging information module
19Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 119
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:
• Mobile originated call attempt• Mobile terminated call attempt• Roaming call attempt• Incoming intra-PLMN trunk• Outgoing intra-PLMN trunk• Incoming gateway call attempt• Outgoing gateway call attempt
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.
Field Reference Size (characters)Module Code M B5.2.110 4Pre-translated Called Party Number M B5.2.144 40Original Calling Number M B5.2.133 40Total Size 84
Table 51 Generic address information module
20Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 120 (Approved) 30th March 2005
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 GMSC’s address are signalled via the HLR to the VMSC. The VMSC uses the network call reference number and the GMSC’s address to hand the call back to the GMSC if the call forwarding condition is encountered. The network call reference number and the GMSC’s 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.
22Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 121
The module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt
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.
The module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt • Short Message Service, Mobile Originated
Field Reference Size (characters)Module Code M B5.2.110 4Network call reference number M B5.2.116 18MSC address M B5.2.112 28Total Size 50
Table 52 Network call reference information module
23Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 122 (Approved) 30th March 2005
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.
The module may be appended to the following MSC structured records:
• Mobile originated call attempt • Incoming gateway call attempt • Incoming intra-PLMN trunk
Field Reference Size (characters)Module Code M B5.2.110 4Free Format Data 1 M B5.2.62 42Free Format Data 2 M B5.2.62 42Free Format Data 3 M B5.2.62 42Free Format Data 4 M B5.2.62 42Free Format Data 5 M B5.2.62 42Free Format Data 6 M B5.2.62 42Free Format Data 7 M B5.2.62 42Free Format Data 8 M B5.2.62 42Local Reference Number M B5.2.102 12Party to Charge M B5.2.140 4CSI (CAMEL Subscription Information) M B5.2.41 2Total Size 358
Table 53 CAMEL charging information module
Field Reference Size (characters)Module Code M B5.2.110 4Routing Number M B5.2.168 26Query Method M B5.2.152 2Ported Status M B5.2.142 2Total Size 34
Table 54 Mobile Number Portability information module
25Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 123
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.
The module may be appended to the following MSC structured records:
• Incoming gateway call attempt • Incoming intra-PLMN trunk
Field Reference Size (characters)Module Code M B5.2.110 4SCP Address C B5.2.171 22SCF ID C B5.2.169 22Correlation ID C B5.2.38 24IP SSP Capability C B5.2.91 10IN Protocol C B5.2.75 2IP Routing Address C B5.2.90 24Answer Time C B5.2.6 16Disconnect Time C B5.2.53 16Total Size 140
Table 55 GSM ASSP information module
26Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 124 (Approved) 30th March 2005
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 69.
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 SCP’s address.
Field Reference Size (characters)Module Code M B5.2.110 4SCP Address M B5.2.171 22Service Key M B5.2.178 12IN Protocol M B5.2.75 2Default SMS Handling Indicator (DSH Indicator) M B5.2.47 2Default SMS Handling Applied (DSH Applied) M B5.2.46 2Operation History C B5.2.131 26SMS Start Time C B5.2.182 16SMS Stop Time C B5.2.183 16IN Call Reference Number C B5.2.73 18Modified Service Centre (Service Centre) C B5.2.177 28Modified Destination Subscriber Number (Called Party) C B5.2.22 30Modified Calling Number (Calling Number) C B5.2.25 30SMS Release Cause Value C B5.2.180 4IN Dialogue Result M B5.2.74 2Total Size 214
Table 56 CAMEL SMS information module
27Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 125
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.
The module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt • Roaming call attempt• Incoming gateway call attempt • Incoming intra-PLMN trunk • Outgoing gateway call attempt • Outgoing intra-PLMN trunk
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.
Field Reference Size (characters)Module Code M B5.2.110 4Unused Number 1 C B5.2.199 40Unused Number 2 C B5.2.200 40Unused Timestamp 1 C B5.2.201 16Unused Timestamp 2 C B5.2.202 16Patch Identity C B5.2.141 12 Total Size 128
Table 57 Patching information module
28Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 126 (Approved) 30th March 2005
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.
The module may be appended to the following MSC structured records:
• Mobile originated call attempt • Mobile terminated call attempt • Incoming gateway call attempt • Incoming intra-PLMN trunk • Outgoing gateway call attempt • Outgoing intra-PLMN trunk
In handover scenarios there may be several BICN modules appended to the call records to show the subscriber’s different locations.
Field Reference Size (characters)Module Code M B5.2.110 4 Media Gateway (MGW) Number C B5.2.107 14 MGW Seizure Time C B5.2.108 16 Backbone Media Type C B5.2.8 2 Access Media Type C B5.2.1 2 Total Size 38
Table 58 Bearer Independent Core Network information module
29Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 127
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 59. 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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt record• Mobile terminated call attempt record
Call Detail Records and Structure Codes
Mob
. Orig
.
Mob
. Ter
m.
Roa
min
g
I/C G
ate
O/G
Gat
e
Tran
sit
SMS
MO
SMS
MT
I/C in
tra
O/G
Intra
CEU
SS A
ctio
n
Information Module Attacha
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.
Relb
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 98 Y Y Y Y Y Y Y Y Y Y Y YPCS 1900 Market-Specific Information Modules Originator-Terminator 0-n 05 11 B4.3.1 on page 127 Y Y Y Y YToll Free 0-n 06 14 B4.3.2 on page 128 Y Y YLocal Number Portability (LNP) 0-n 08 21 B4.3.3 on page 128 Y Y YSingapore Specific Information Modules Singapore Specific 0-1 06 17 B4.3.4 on page 129 Y Y Y Y Y Y Y YGerman and Austrian Carrier Specific Information Module Carrier Selection Charging 0-1 11 24 B4.3.5 on page 130 Y Y Y Y Y
Table 59 Information modules
Field Reference Size (characters)Module Code M B5.3.9 4Charge Number/ANI C B5.3.3 40Originating Line Information/II Parameter C B5.3.10 4Originating NPA/NXX C B5.3.11 8Automatic Number Identification Indicator C B5.3.1 2Terminating Numbering Plan Area C B5.3.18 4Generic Address Parameter C B5.3.4 30Total Size 92
Table 60 Originator-terminator information module structure
11Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 128 (Approved) 30th March 2005
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.
This module may be appended to the following MSC structured records:
• Mobile originated call attempt • Incoming gateway call attempt • Incoming intra-PLMN trunk
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.
Field Reference Size (characters)Module Code M B5.3.9 4Toll Free Call Type Code M B5.3.19 4Called Party Off-Hook Indicator M B5.3.2 2Service Feature Code M B5.3.15 4SCP Determined Terminating Number M B5.3.14 20Overseas Indicator M B5.3.12 4LATA M B5.3.6 4IN/INC Routing Indicator C B5.3.5 2Total Size 44
Table 61 Toll free information module
14Module Code
21Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 129
The module may be appended to the following MSC structured records: • Mobile originated call attempt • Incoming gateway call attempt • Incoming intra-PLMN trunk
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):
• 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
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.
Field Reference Size (characters)Module Code M B5.3.9 4Party Identifier M B5.3.13 4Location Routing Number M B5.3.8 12Service Provider Identity X B5.3.16 10Location X B5.3.7 16Supporting Information M B5.3.17 8Total Size 54
Table 62 Local number portability information module
Field Reference SizeModule Code M B5.4.3 4XCLI Indicator C B5.4.7 4National/International Indicator C B5.4.4 4Other Subscriber CUSTGRP C B5.4.5 6Other Subscriber NCOS C B5.4.6 6Calling Party Category C B5.4.1 4City Wide Centrex C B5.4.2 6Total Size 34
Table 63 Singapore specific information module
17Module Code
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 130 (Approved) 30th March 2005
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 MarketIn 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 MarketIn 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 64.
Austrian and German Markets For both market variants, the module may be appended to the following MSC structured records:
• Roaming call attempt • Incoming gateway call attempt • Outgoing gateway call attempt • Incoming intra-PLMN trunk record • Outgoing intra-PLMN trunk record
Field Reference Size (characters)Module Code M B5.5.2 4Selected Carrier Identification Code (CIC) M B5.5.3 4Default CIC M B5.5.1 4Subscriber Customer Group M B5.5.4 6Total Size 18
Table 64 Carrier selection charging information module
24Module Code
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 131
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 65. 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 65 Characteristics of GSM/UMTS billing atomic data fields
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 132 (Approved) 30th March 2005
RCACEIC d ICLCLUMMOOInABIBSCCCSDEAEo
AcAcAdAdAgAn(of
n
B5.2 Data Fields
This section describes the data fields in the billing records and modules described in Sections B4.1 on page 77 and B4.2 on page 97. For information on data fields in market-specific modules, refer to Sections B5.3 on page 258 (PCS market), B5.4 on page 268 (Singapore market) and B5.5 on page 271 (German and Austrian markets).
Table 66 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 field’s 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 66ecords all Detail Records Ro Roaming Call Attemptck Acknowledgement Record (GSM-R) SSA Supplementary Service Action Record
U Common Equipment Usage SMSMO Short Message Service, Mobile OriginatedG Incoming Gateway Call Attempt SMSMT Short Message Service, Mobile TerminateIP Incoming Intra-PLMN Trunk Record Tr TransitS‘ Location Service (LCS) Record Switch/Billing File Records
Location Update Record BBHR Billing Block Header RecordO Mobile Originated Call Attempt BFTIR Billing File Transfer In RecordT Mobile Terminated Call Attempt BFTOR Billing File Transfer Out RecordGG Outgoing Gateway Call Attempt SRR Switch Restart RecordGIP Outgoing Intra-PLMN Trunk Record TCR Time Change Recordformation ModulesoC Advice of Charge GA Generic Address OA Other AgentCN Bearer Independent Core Network GASSP GSM Assisting SSP PaI Patching
Bearer Service IN IN PI Partial InformationCAMEL Charging INC IN Charging SS Supplementary Service
MS CAMEL SMS LaC Location and Channel TC Tariff Class (AoC)S Data Services LO Location Only TS Teleservice
Equal Access MNP Mobile Number Portability TU Trunk UsageM End of Module List NCR Network Call Reference
Field Name Size Type Ref. Call Records Switch / File Records Modulecess Media Type 2 Atomic B5.2.1 BICN cess Network 2 Atomic B5.2.2 SSA LaC, LOditional Information 4 Atomic B5.2.3 MO, MTvice of Charge Parameter Reason 4 Atomic B5.2.4 AoCe of Location Information 6 Atomic B5.2.5 LCSswer Time type Date and Time)
16 Atomic B5.2.6 MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP
GASSP
Table 66 Data fields in billing records and modules
Retur
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 133
AuSeSeReReBaBCBCBeBlBlBoCa
CaCaCaCaCa(BCaNuNuBCCaNuNuBCCaCaBCCaNuNuBCCaNuNuBCCaCa(ofCa
CeCh(ofChCh
xiliary Record Headernsor Type (4)nsor Identity (8)cording Office Type (4)cording Office Identity (8)
24 Compound B5.2.7 TCR, SRR, BBHR, BFTIR, BFTOR
ckbone Media Type 2 Atomic B5.2.8 BICN D or Full Hex String --- Atomic B5.2.9 Generic atomic field used by other data fieldsD or Hex String (N) --- Atomic B5.2.10 Generic atomic field used by other data fieldsarer Service 4 Atomic B5.2.11 BSock Count (BCD/Hex String 6) 6 Atomic B5.2.12 BFTORock Number (BCD/Hex String 6) 6 Atomic B5.2.13 BBHRolean Type 2 Atomic B5.2.14 Generic atomic field used by other data fieldsll Duration 14 Atomic B5.2.15 MO, MT, Ro, ICG, OGG, Tr,
ICIP, OGIP, CEUll Forward Indicator (Boolean Type) 2 Atomic B5.2.16 MO, MTll Indicator 8 Atomic B5.2.17 MO, MT, Roll Reference (BCD/Hex String 8) 8 Atomic B5.2.18 All recordsll Type Code 4 Atomic B5.2.19 See Record Header fieldlled Equipment (or Served Equipment)CD/Hex String 22)
22 Atomic B5.2.20 MT, SMSMT
lled Number (or Served Number)mber Type (2)mbering Plan Identifier (6)D/Hex String (32)
40 Compound B5.2.21 MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, Ack
lled Party (or Served Party)mber Type (2)mbering Plan Identifier (6)D/Hex String (22)
30 Compound B5.2.22 MT, Ro, SMSMT CSMS
lled Subscriber Category 4 Atomic B5.2.23 MTlling Equipment (or Served Equipment)D/Hex String (22)
22 Atomic B5.2.24 MO, SMSMO, SSA
lling Number (or Served Number)mber Type (2)mbering Plan Identifier (6)D/Hex String (22)
30 Compound B5.2.25 MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, CEU, SSA, Ack
lling Party (or Served Party)mber Type (2)mbering Plan Identifier (6)D/Hex String (22)
30 Compound B5.2.26 MO, SMSMO, CEU, SSA
lling Subscriber Category 4 Atomic B5.2.27 MOrrier Connect Timestamp type Date and Time)
16 Atomic B5.2.28 EA
use for Termination 4 Atomic B5.2.29 MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP
ll-SAC Id 6 Atomic B5.2.30 SSA LaC, LOannel Allocation Time type Date and Time)
16 Atomic B5.2.31 MO, MT
annel Description 10 Atomic B5.2.32 LaCannel Type 6 Atomic B5.2.33 LaC
Field Name Size Type Ref. Call Records Switch / File Records Module
Table 66 Data fields in billing records and modules
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 134 (Approved) 30th March 2005
ChNuBCChCl(ofCoCoCoCo
CSDaDaDaDa S,
DeapDeIndDe(ofDeBCDeDi
DiNuBCDiE ds for
to 7)EmBCEmEqEqFC
). FilBCFilFrFuGeGeGe
arge Numbermber Type (2)D/Hex String (22)
24 Compound B5.2.34 IN
arge Zone 6 Atomic B5.2.35 TCassmark Time Stamp type Date and Time)
16 Atomic B5.2.36 MO, MT
nnection Element 2 Atomic B5.2.37 DSrrelation Id BCD/Hex String (24) 24 Atomic B5.2.38 GASSP rrelation ID / ETC Parm2 34 Atomic B5.2.39 INunter BCD/Hex String (10) 10 Atomic B5.2.40 See IP Routing
Address field. I (CAMEL Subscription Information) 2 Atomic B5.2.41 INta Compression 4 Atomic B5.2.42 DSta Rate 4 Atomic B5.2.43 DSta Volume 6 Atomic B5.2.44 DSte and Time 16 Atomic B5.2.45 CEU (seizure), CEU
(release), SSATCR (old), TCR (new), SRR, BBHR, BFTIR, BFTOR
BS, LaC, SS, TAoC
fault SMS Handling Applied (DSH plied)
2 Atomic B5.2.46 CSMS
fault SMS Handling Indicator (DSH icator)
2 Atomic B5.2.47 CSMS
livery Timestamp type Date and Time)
16 Atomic B5.2.48 SMSMO, SMSMT
stination Routing AddressD/Hex String (32)
32 Atomic B5.2.49 IN
tection Point 4 Atomic B5.2.50 INagnostic 6 Atomic B5.2.51 MO, MT, Ro, ICG, OGG, Tr,
ICIP, OGIPalled Digitsmber Type (2)D/Hex String (32)
34 Compound B5.2.52 MO
sconnect Time (of type Date and Time) 16 Atomic B5.2.53 MO, MT GASSP Parameter 6 Atomic B5.2.54 AoC (seven fiel
E parameters 1 ergency Service Routing Digits (ESRD) D/Hex String (16)
16 Atomic B5.2.55 LCS
ergency Service Routing Key (ESRK) 12 Atomic B5.2.56 LCS uipment Identity 6 Atomic B5.2.57 CEUuipment Type 6 Atomic B5.2.58 CEUI Freeform Parameter 46 Atomic B5.2.59 INC (contains 3
parameter fieldse Sequence Number D/Hex String (4)
4 Atomic B5.2.60 BFTIR, BFTOR
e Transfer Type 4 Atomic B5.2.61 BFTIR, BFTOReeformat Data 42 Atomic B5.2.62 CC nctional Number 16 Atomic B5.2.63 Ackographical Location of UE 1 42 Atomic B5.2.64 LCSographical Location of UE 2 42 Atomic B5.2.65 LCSographical Location of UE 3 42 Atomic B5.2.66 LCS
Field Name Size Type Ref. Call Records Switch / File Records Module
Table 66 Data fields in billing records and modules
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 135
GeGeGrHaHeHoINBCININ , INININIncIncOuIncInc
Ou
Inc(of
IncOuInc(of
IncOuIncBCIncBCInfIntINIntINInt ), DS
Int ), DS
IP
IPIPMSCoIPIW(ofIW
ographical Location of UE 4 42 Atomic B5.2.67 LCSographical Location of UE 5 24 Atomic B5.2.68 LCSoup Call Reference 10 Atomic B5.2.69 Acklf Rate in Use (Boolean Type) 2 Atomic B5.2.70 MO, MTxadecimal Id 2 Atomic B5.2.71 See Record Header fieldt Billing Indicator 2 Atomic B5.2.72 SSA, Ack Call Reference Number D/Full Hex String (18)
18 Atomic B5.2.73 CSMS
Dialogue Result 2 Atomic B5.2.74 CSMS Protocol 2 Atomic B5.2.75 CSMS, GASSP Time Stamp1 (of type Date and Time) 16 Atomic B5.2.76 IN Time Stamp2 (of type Date and Time) 16 Atomic B5.2.77 INoming/Outgoing Metering Class omingtgoing
4 Atomic B5.2.78ICG, ICIP, OGG, Tr, OGIP
oming/Outgoing Route Groupoming
tgoing
4 Atomic B5.2.79MT, Ro, ICG, OGG, Tr, ICIP, OGIPMO, Ro, ICG, OGG, Tr, ICIP, OGIP
oming/Outgoing Trunk Release Time type Date and Time)
omingtgoing
16 Atomic B5.2.80
ICG, ICIP, Ro, OGG, Tr, OGIP
oming/Outgoing Trunk Seizure Time type Date and Time)
oming tgoing
16 Atomic B5.2.81
MT, Ro, ICG, ICIP, MO, Ro, OGG, Tr, OGIP
oming Trunk Group D/Hex String (6)
6 Atomic B5.2.82 MT, Ro, ICG, OGG, Tr, ICIP, OGIP
LaC
oming Trunk MemberD/Hex String (6)
6 Atomic B5.2.83 MT, Ro, ICG, OGG, Tr, ICIP, OGIP
LaC
ormation Transfer Capability 2 Atomic B5.2.84 DSer-Exchange/International Carrier (IC/C) Call Event Status
4 Atomic B5.2.85 EA
er-Exchange/International Carrier (IC/C) Prefix
10 Atomic B5.2.86 EA
erworking Function Trunk Group 6 Atomic B5.2.87 DS (mobile side(network side)
erworking Function Trunk Member 6 Atomic B5.2.88 DS (mobile side(network side)
Address Identity BCD/Hex String (8) 8 Atomic B5.2.89 See IP Routing Address field.
Routing Address Address Identity (8)C Id (6)unter (10)
24 Compound B5.2.90 GASSP
SSP Capability 10 Atomic B5.2.91 GASSP F Activation Timestamp type Date and Time)
16 Atomic B5.2.92 DS
F Diagnostic Code 4 Atomic B5.2.93 DS
Field Name Size Type Ref. Call Records Switch / File Records Module
Table 66 Data fields in billing records and modules
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 136 (Approved) 30th March 2005
LCNuBCLCLCLC(ofLCLCLCLC(ofLoLoLo
MM
MM(ofMMM
MNuBCM
MNuBCMNuBCNeBCNeNeNeNeNuBCNuNuNuOfOf
S Client Identitymbering Plan Identifier (6)D/Full Hex String (26)
32 Atomic B5.2.94 LCS
S Client Type 4 Atomic B5.2.95 LCSS Diagnostic 2 Atomic B5.2.96 LCS S Initiation Time type Date and Time)
16 Atomic B5.2.97 LCS
S Priority Level 4 Atomic B5.2.98 LCS S Record Type 2 Atomic B5.2.99 LCSS Result 4 Atomic B5.2.100 LCSS Termination Time type Date and Time)
16 Atomic B5.2.101 LCS
cal Reference Number 12 Atomic B5.2.102 CC, INcation Area Code 12 Atomic B5.2.103 SSA LaC, LOgical Network 4 Atomic B5.2.104 Ro, ICG, OGG, Tr, ICIP,
OGIPessage Reference BCD/Hex String (6) 6 Atomic B5.2.105 SMSMOetering Zone 4 Atomic B5.2.106 Ro, ICG, OGG, Tr, ICIP,
OGIPGW (Media Gateway) Number 14 Atomic B5.2.107 BICN GW Seizure Time type Date and Time)
16 Atomic B5.2.108 BICN
M Event 4 Atomic B5.2.109 LU odule Code 4 Atomic B5.2.110 All modulesS Classmark 16 Atomic B5.2.111 MO, MT, SMSMO, SMSMT,
SSASC Addressmbering Plan Identifier (6)D/Hex String (22)
28 Compound B5.2.112 NCR
SC Id BCD/Hex String (6) 6 Atomic B5.2.113 See IP Routing Address field.
SC Numbermbering Plan Identifier (6)D/Hex String (22)
28 Compound B5.2.114 MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, SSA, LCS, Ack
LaC, LO
SC/MGW Numbermbering Plan Identifier (6)D/Hex String (22)
28 Compound B5.2.115 CEU
twork Call Reference NumberD/Full Hex String (18)
18 Atomic B5.2.116 NCR
w AN 2 Atomic B5.2.117 LU w Cell-SAC Id 6 Atomic B5.2.118 LU w LAC 12 Atomic B5.2.119 LU w MSC Id mbering Plan Identifier (6)D/Hex String (22)
28 Compound B5.2.120 LU
mber of Fax Pages BCD/Hex String (4) 4 Atomic B5.2.121 DSmber Type 2 Atomic B5.2.122 Generic field type used to identify types of numbers. mbering Plan Identifier 6 Atomic B5.2.123 Field used in number type fields. f Air Call Setup Boolean Type 2 Atomic B5.2.124 MO, MTf-Board IN Service Identifier 4 Atomic B5.2.125 IN
Field Name Size Type Ref. Call Records Switch / File Records Module
Table 66 Data fields in billing records and modules
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 137
OfOlOlOlOlNuBCOpOpOrNuNuBCOuBCOuBCPaPaPaBCPaBCPaPaPoPoPrNuNuBCPrPrPrPrPrPrPrQuRaReReHeReStrCaRe
Re
f-Board IN Service Indicator 4 Atomic B5.2.126 INd AN 2 Atomic B5.2.127 LU d Cell-SAC Id 6 Atomic B5.2.128 LU d LAC 12 Atomic B5.2.129 LU d MSC Id mbering Plan Identifier (6)D/Hex String (22)
28 Compound B5.2.130 LU
eration History 26 Atomic B5.2.131 CSMS eration Indication 2 Atomic B5.2.132 INiginal Calling Numbermber Type (2)mbering Plan Identifier (6)D/Hex String (32)
40 Compound B5.2.133 GA
tgoing Trunk Group D/Hex String (6)
6 Atomic B5.2.134 MO, Ro, ICG, OGG, Tr, ICIP, OGIP
tgoing Trunk MemberD/Hex String (6)
6 Atomic B5.2.135 MO, Ro, ICG, OGG, Tr, ICIP, OGIP
rtial Record Event Code 4 Atomic B5.2.136 PIrtial Record Reason 4 Atomic B5.2.137 PIrtial Record Reference NumberD/Hex String (8)
8 Atomic B5.2.138 PI
rtial Record Sequence NumberD/Hex String (6)
6 Atomic B5.2.139 PI
rty to Charge 4 Atomic B5.2.140 CC tch Identity 12 Atomic B5.2.141 Pa rted Status 2 Atomic B5.2.142 MNPsitioning Data 28 Atomic B5.2.143 LCS e-Translated Called Party Numbermber Type (2)mbering Plan Identifier (6)D/Hex String (32)
40 Compound B5.2.144 GA
iority Call Cause 4 Atomic B5.2.145 Ackiority Call Duration 10 Atomic B5.2.146 Ackiority Call Tag 2 Atomic B5.2.147 Ackiority Level 4 Atomic B5.2.148 Ackiority Release Time 12 Atomic B5.2.149 Ackivacy Notification 2 Atomic B5.2.150 LCS ivacy Override 2 Atomic B5.2.151 LCS ery Method 2 Atomic B5.2.152 MNPte Adaptation 2 Atomic B5.2.153 DScord Count BCD/Hex String (10) 10 Atomic B5.2.154 BFTORcord Headerxadecimal Identity (2)lease Id (6)ucture Code (6)ll Type Code (4)
18 Compound B5.2.155 All call records All switch/file records
cord Number 12 Atomic B5.2.156 All Call Detail Records. TCR, SRR, BFTIR, BFTOR
cord Time (of type Date and Time) 16 Atomic B5.2.157 Ack
Field Name Size Type Ref. Call Records Switch / File Records Module
Table 66 Data fields in billing records and modules
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 138 (Approved) 30th March 2005
ReNuBCReReReReReReNuBCReRNBCRoNuNuBCRoSCSCSC , INSeSeSeNuNuBCSeNuNuBCSeSeNuBCSeSMSMSMSMSMSMSMStrStuSuSuSu
cording Entity mbering Plan Identifier (6)D/Hex String (22)
28 Compound B5.2.158 LU
cording Office Identity 8 Atomic B5.2.159 All switch/file recordscording Office Type / Sensor Type 4 Atomic B5.2.160 All switch/file recordslease Id 6 Atomic B5.2.161 See Record Header field lease Time (of type Date and Time) 16 Atomic B5.2.162 MO, MTquested QoS 12 Atomic B5.2.163 LCSquesting Mobile Location Centre (MLC)mbering Plan Identifier (6)D/Hex String (20)
26 Compound B5.2.164 LCS
sult Indicator 4 Atomic B5.2.165 SSA SSC IDD/Hex String (6)
6 Atomic B5.2.166 LaC
aming Numbermber Type (2)mbering Plan Identifier (6)D/Hex String (22)
30 Compound B5.2.167 Ro LaC
uting Number BCD/Hex String (26) 26 Atomic B5.2.168 MNP F ID BCD/Hex String (22) 22 Atomic B5.2.169 GASSP F ID / ETC Parm1 34 Atomic B5.2.170 INP Address BCD/Hex String (22) 22 Atomic B5.2.171 CSMS, GASSPnsor Identity 8 Atomic B5.2.172 All switch/file recordsrved IMEI BCD/Hex String (16) 16 Atomic B5.2.173 LCS rved IMSI mber Type (2)mbering Plan Identifier (6)D/Hex String (22)
30 Compound B5.2.174 LU
rved MSISDN mber Type (2)mbering Plan Identifier (6)D/Hex String (22)
30 Compound B5.2.175 LCS, LU
rved Party BCD/Hex String (16) 16 Atomic B5.2.176 LCSrvice Centrembering Plan Identifier (6)D/Hex String (22)
28 Compound B5.2.177 SMSMO, SMSMT CSMS
rvice Key 12 Atomic B5.2.178 CSMS, INS Message Type 2 Atomic B5.2.179 SMSMOS Release Cause Value 4 Atomic B5.2.180 CSMS S Result (of type Diagnostic) 6 Atomic B5.2.181 SMSMO, SMSMTS Start Time (of type Date and Time) 16 Atomic B5.2.182 CSMS S Stop Time (of type Date and Time) 16 Atomic B5.2.183 CSMS S Timestamp (of type Date and Time) 16 Atomic B5.2.184 SMSMO, SMSMTS Validity Period 18 Atomic B5.2.185 SMSMO
ucture Code 6 Atomic B5.2.186 See Record Header fielddy Indicator 2 Atomic B5.2.187 All Call Detail Records
bscriber Service 6 Atomic B5.2.188 TCpplementary Service Action 2 Atomic B5.2.189 SSA SSpplementary Service Code 4 Atomic B5.2.190 SSA SS, AoC
Field Name Size Type Ref. Call Records Switch / File Records Module
Table 66 Data fields in billing records and modules
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 139
SuBCSwSyTaTeTeTrTyUnNuNuBCUnNuNuBCUn(ofUn(ofUpUp
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 67.
pplementary Service ParameterD/Hex String (32)
32 Atomic B5.2.191 SSA SS
itch Restart Type 2 Atomic B5.2.193 SRRstem Type 2 Atomic B5.2.192 LCS riff Class 6 Atomic B5.2.194 TCleservice 4 Atomic B5.2.195 TSrminating Location 16 Atomic B5.2.196 OAunk Usage Reason 4 Atomic B5.2.197 TUpe of Carrier Identification Code (CIC) 2 Atomic B5.2.198 EAused Number 1 mber Type (2)mbering Plan Identifier (6)D/Hex String (32)
40 Compound B5.2.199 PaI
used Number 2 mber Type (2)mbering Plan Identifier (6)D/Hex String (32)
40 Compound B5.2.200 PaI
used Timestamp 1 type Date and Time)
16 Atomic B5.2.201 PaI
used Timestamp 2 type Date and Time)
16 Atomic B5.2.202 PaI
date Result 4 Atomic B5.2.203 LU date Time (of type Date and Time) 16 Atomic B5.2.204 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 67 Access media Type atomic data field
Field Name Size Type Ref. Call Records Switch / File Records Module
Table 66 Data fields in billing records and modules
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 140 (Approved) 30th March 2005
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 68.
The access network field is used with the cell-sac id field (B5.2.30 on page 158) 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 station’s 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 69.
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 68 Access network atomic data field
Field Used In: Records: MO, MT.
Character Description Values 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 69 Additional information atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 141
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 70.
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 71.
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 Answer1 message is received at the MSC.
Field Used In: Module: AoC.
Character Description Values1 Reserved 02-3 Reason 00 -Initial
01 - Subsequent 02 - IN Initial 03 - IN Subsequent
4 Sign Character CDefault: 000CExample:AoC Parameter Reason - 000C
Table 70 Advice of charge parameter reason atomic data field
Field Used In: Record: LCS.
Character(s) Description Values1-5 Location Estimate 00000 - 655356 Sign Character CDefault: FFFFFCExample:Age of Location: 00012C
Table 71 Age of location information atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 142 (Approved) 30th March 2005
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.45 on page 167.
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 72.
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 73.
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 ReferenceSensor Type 4 B5.2.160Sensor Identity 8 B5.2.172Recording Office Type 4 B5.2.160Recording Office Identity 8 B5.2.159
Table 72 Auxiliary record header data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 143
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 74.
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 75.
Field Used In: Module: BICN.
Character(s) Description Values1 Backbone Media Type 0 - IP
1 - AAL22 Sign Character CDefault: FCExample:Backbone Media Type (AAL2): 1C
Table 73 Backbone Media Type atomic data field
Generic field type used by other fields. Character Description Values
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 CDefault: Not applicable. When captured only valid values shall be recorded.Example:BCD or Full Hex String(6): 12345C
Table 74 BCD or full hex string atomic data field
Generic field type used by other fields. Character Description Values
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 CDefault: FFF...FCExample:BCD or Hex String(6): 12345C
Table 75 BCD or hex string atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 144 (Approved) 30th March 2005
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 76.
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.43 on page 166).
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 143.
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 143.
Field Used In: Module: BS.
Character Description Values1-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 CA5 - Data PDS6 - Alternate Speech-Data CDA 7 - Alternate Speech-Data CDS8 - Speech Followed by Data CDA 9 - Speech Followed by Data CDS
Compound Bearer Service Groupa
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 AsynchronousB - All Data Circuit SynchronousC - All Asynchronous ServicesD - All Synchronous Services
4 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Bearer Service (Circuit Data Asynchronous): 002C
Table 76 Bearer service atomic data field
Field Used In: Record: BFTOR.
Field Used In: Record: BBHR.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 145
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 77.
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 78.
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)
Generic field type used by other fields. Character Description Values
1 Condition 1 - Stated Condition is True0 - Stated Condition is False
2 Sign Character CDefault: 0CExample:Boolean Type (Half Rate in Use): 1C
Table 77 Boolean type atomic data field
Field Used In: Records: MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP, CEU.
Character Description Values1 Note 2 Granularity 0 - Seconds
1 - Tenths of a Second 2 Note 3 Rounding Indicator 0 - Rounded Up
1 - Rounded Down2 - Rounded to the Nearest Integer
3 Sign Character C4 - 11 Call Duration {00000000 - 09994239}12 - 13 Spare 0014 Sign Character CDefault: FFFFFFFFFFFFFCExample:Call Duration rounded up in seconds (120Seconds): 00C0000012000C
Table 78 Call duration atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 146 (Approved) 30th March 2005
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.
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 145.
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.
Field Used In: Records: MO, MT.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 147
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 79.
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.
Field Used In: Records: MO, MT, Ro.
Character Description Values1-6 Reserved 0000007 Call Indicator 0 - No Indication
1 - No Charge2 - Charge3 - Called Party Charge4 - Calling Party Charge
8 Sign Character CDefault: 0000000CExample:Call Indicator (No Charge): 0000001C
Table 79 Call indicator atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 148 (Approved) 30th March 2005
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 143.
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.155). The field encoding is shown in Table 80.
Field Used In: Records: All Call Detail Records.
Field Used In: Records: All Call Detail Records. All Switch/Billing File Records.
Character Description Values1-3 Call Type Code 001 - Mobile Originated Call
002 - Mobile Terminated Call003 - Location Update Call 004 - Supplementary Service Action 005 - SMS Mobile Originated Call 006 - SMS Mobile Terminated Call 007 - File Transfer Record008 - Time Change Record009 - Switch Restart Record010 - Block Header Record011 - Incoming Trunk Call012 - Outgoing Trunk Call 014 - Roaming Call 015 - Common Equipment 016 - Acknowledgement Call 017 - Location Service (LCS)
4 Sign Character C Default: Not applicable. When captured only valid values shall be recorded.Example:Call Type Code (Mobile Originated Call): 001C
Table 80 Call type code atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 149
B5.2.20 Called Equipment (or Served Equipment)
This field contains the international mobile equipment identity (IMEI) of the called party’s mobile equipment. The structure of the IMEI is defined in 3GPP TS 23.003. The field is encoded as a 22 character BCD/hex string as defined in Section B5.2.10 on page 143. A valid IMEI is composed of digits and any used characters in the field are populated with Hex Fs. 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.
B5.2.21 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: Records: MT, SMSMT.
Field Used In: Records: MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, Ack.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (32) 32 B5.2.10
Table 81 Called (or served) number data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 150 (Approved) 30th March 2005
B5.2.21.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.21.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.21.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.21.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.21.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.21.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”.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 151
B5.2.21.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.21.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.21.1 to B5.2.21.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 selectorThe call profile selector with the international (INTL) optionThe 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 and the ANSI ISUP translations enhancements .
B5.2.21.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.123)INTL 1 - International NumberNATL 2 - National Significant NumberLOCAL 3 - Network Specific Number
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 152 (Approved) 30th March 2005
B5.2.22 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.23 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.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 82 Called (or served) party data field
Field Used In: Record: MT.
Character Description Values1-3 Category 000 - Unknown
001 - French 002 - English 003 - German 004 - Russian 005 - Spanish 006 - Spare language 1 007 - Spare language 2 008 - Spare language 3 009 - Reserved 010 - Ordinary011 - Priority 012 - Data (voiceband) 013 - Test015 - Payphone 016 - Fixed access 017 - 223 Categories 17 to 223 224 National Use 1/Category 224225 - Category 225(continued)
Table 83 Called subscriber category atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 153
B5.2.24 Calling Equipment (or Served Equipment)
This field contains the international mobile equipment identity (IMEI) of the calling party’s mobile equipment. The structure of the IMEI is defined in 3GPP TS 23.003. The field is encoded as a 22 character BCD/hex string as defined in Section B5.2.10 on page 143. A valid IMEI is composed of digits and any used characters in the field are populated with Hex Fs. 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.
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.
226 National Use 2/National Security Emergency Preparedness (NSEP) 227 - Category 227 228 National Use 3/Category 228 229 - Category 229 230 National Use 4/Category 230 231 - Category 231 232 National Use 5/Category 232 233 - Category 233 234 National Use 6/Category 234 235 - Category 235 236 National Use 7/Category 236 237 - Category 237 238 National Use 8/Category 238 239 - Category 239 240 - Ordinary no charge 241 - Category 241 242 National Use 10/Category 242 243 - Category 243 244 - Priority no charge 245 - Category 245 246 National Use 12/Category 246 247 - Category 247 248 National Use 13/Category 248 249 - Category 249 250 National Use 14/Category 250 251 - Category 251 252 National Use 15253 - Category 253 254 National Use 16/Category 254 255 - Reserved
4 Sign Character CDefault: FFFCExample:Called Subscriber Category (Ordinary): 010C
Field Used In: Records: MO, SMSMO, SSA.
Table 83 Called subscriber category atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 154 (Approved) 30th March 2005
B5.2.25 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 84.
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.
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 redirection number, if available. However, 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.
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).
(continued)
Field Used In: Records: MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP, CEU, SSA, Ack.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 84 Calling (or served) number data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 155
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_ 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 originalcall to party B will show the MSISDN of A as the calling number in nationalformat*, and the MSISDN of B as the called number in international(untranslated) format.
- The Mobile Originated Call Forwarding Attempt record** for party B for thecall leg to party C will show the MSISDN of B as the redirecting and callingnumber in international format, and the translated address for C as the callednumber (assuming that C represents a PSTN destination).
- The outgoing trunk record for the terminating party C will show theMSISDN of B as the redirecting and calling number in national format, andthe 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 formatimplies that the MCC digits are not included in the digit string(possibly replaced with National Prefix digits) and the NOA indicatoris national
** In the Mobile Originated and Mobile Terminated Call ForwardingAttempt records, the Call Forward Indicator will be set.
(continued)
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 156 (Approved) 30th March 2005
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:
- 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.
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 subscriber’s 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 157
B5.2.26 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 85.
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.
B5.2.27 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.23 on page 152.
B5.2.28 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.45 on page 167.
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.
Field Used In: Records: MO, SMSMO, CEU, SSA.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Indicator 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 85 Calling (or served) party data field
Field Used In: Record: MO.
Field Used In: Module: EA.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 158 (Approved) 30th March 2005
B5.2.29 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 66. 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 86.
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.30 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 87.
NOTE 1 This field and the Access Network (AN) field (B5.2.2 on page 140) 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. (continued)
Field Used In: Records: MO, MT, Ro, ICG, OGG, Tr, SMSMO, SMSMT, ICIP, OGIP.
Field Type Number of Characters Detailed Reference1 Reserved 02-3 Cause for Termination 00 - Normal Release
01 - Partial Record02 - Partial Record Call Re-establishment03 - Unsuccessful Call Attempt04 - Stable Call Abnormal Termination
4 Sign Character CDefault: 000CExample:Cause for Termination (Call terminated due to generation of a partial call record): 001C
Table 86 Cause for termination atomic data field
Field Used In: Record: SSA. Modules: LaC, LO.
Character Description Values1-5 Cell Identity/Service Area Code (Integer value) {00000....99999}6 Sign Character CDefault: FFFFFCExample:Cell-SAC Id: 00124C
Table 87 Cell-SAC Id atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 159
NOTE 2 The GSM (2G) handover procedure contains location information and so this field captures the cell identity provided during the procedure.
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 69).
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 140) has no meaning.
B5.2.31 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.45 on page 167.
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 141).
B5.2.32 Channel Description
NOTE This 10 character atomic data field shall always be set to its default value. This default value is FFFFFFFFFC.
B5.2.33 Channel Type
This field identifies the characteristics of the radio channel used for a call. The field encoding is shown in Table 88.
Field Used In: Records: MO, MT.
Field Used In: Module: LaC.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 160 (Approved) 30th March 2005
NOTE 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.
Field Used In: Module: LaC.
Character Description Values1 Speech or Data Indicator 0 - Spare (Not Used)
1 - Speech2 - Data3 - GSM Signalling4 - Speech plus Cellular Text Modem (CTM)
Option2 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 AllowedOption
3-4 Character 1 = 1 or 4 Speech Encoding Algorithm 00 - Spare 10 - GSM Full Rate Speech Version 111 - GSM Half Rate Speech Version 1 12 - GSM Full Rate Speech Version 2 13 - GSM Half Rate Speech Version 2 14 - GSM Full Rate Speech Version 3 15 - GSM Half Rate Speech Version 3
or3-4 Character 1 = 3 Speech Encoding Algorithm 00 - Spare or3 Character 1= 2 Transparency Indicator 0 - Transparent
1 - Non Transparent
Option4 Character 3 = 0
(transparent)Data Rate 0 - Spare
1 - 9.6 KBit/s2 - 4.8 KBit/s3 - 2.4 KBit/s4 - 1.2 KBit/s5 - 600 Bits/s6 - 1200/75 Bits/s (N->MS/MS->N)7 - 14.4 Kbit/s 8 - 64 Kbits/s
or4 Character 3 = 1
(non transparent)Data Rate 0 - Spare
1 - 12 KBit/s2 - 6 KBit/s3 - 14.5 kbit/s
5 Reserved 06 Sign Character CDefault: FFFFFCExample:Channel Type (Data, Full Rate,Transparent,2.4 KBit/s): 23030CChannel 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 88 Channel type atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 161
B5.2.34 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 fields as shown in Table 89.
B5.2.35 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 encoding is shown in Table 90.
B5.2.36 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.45 on page 167.
Field Used In: Module: IN.
Field Type Number of Characters Detailed Reference Number Type 2 B5.2.122 BCD or Hex String (22) 22 B5.2.10
Table 89 Charge number data field
Field Used In: Module: TC.
Character Description Values1-5 Charge Zone {00000....00255} 6 Sign Character CDefault: FFFFFCExample:Charge Zone:00102C
Table 90 Charge zone atomic data field
Field Used In: Records: MO, MT.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 162 (Approved) 30th March 2005
B5.2.37 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 encoding is shown in Table 91.
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.38 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 SSP’s 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 143.
Field Used In: Module: DS.
Character Description Values1 Connection Element 0 - Transparent
1 - Non Transparent 2 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Connection Element (Transparent): 0C
Table 91 Connection element atomic data field
Field Used In: Module: GASSP.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 163
B5.2.39 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. The field encoding is shown in Table 92.
B5.2.40 Counter
This field is part of the IP (intelligent peripheral) Routing Address field described in Section B5.2.90 on page 198, 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 143.
Field Used In: Module: IN.
Character Description Values1 Spare 02 Format Indicator 0 - Explicit
1 - Embedded3-33 Correlation ID {0,1,2,3,4,5,6,7,8,9,0,A,B,C,D,E,F}34 Sign Character CDefault: FF0000000000000000000000000000000CExample:Correlation ID / ETC Parm 2: 000000000000000000000000000001115C
Table 92 Correlation ID / ETC Parm 2 atomic data field
Field Used In: Module: GASSP.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 164 (Approved) 30th March 2005
B5.2.41 CSI (CAMEL Subscription Information)
This field captures the CSI used for a call. The field encoding is shown in Table 93.
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.75 on page 191) is set to CS1-R (1C).
Field Used In: Module: IN.
Character Description Values1 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 CDefault: FCExample:CSI (Network CAMEL Subscription Information): 2C
Table 93 CSI atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 165
B5.2.42 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 94.
Field Used In: Module: DS.
Character Description Values 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 or2 Character 1 = 1 Data Compression Type Negotiated by IWF 0 - Data Compression Not Used
1 - V.42bis Data Compression Used
Option3 Character 2 = 0 Data Compression Direction 0 - Data Compression Not Used or3 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 CDefault: 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 94 Data Compression atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 166 (Approved) 30th March 2005
B5.2.43 Data Rate
This field captures information about the data rate used for a data service. The field encoding is shown in Table 95.
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.153 on page 230) 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.
Character Description Values1 Spare 02-3 Data Rate 00 - Any
01 - 300/300 Bits/s02 - 1200/1200 Bits/s03 - 1200/75 Bits/s04 - 2400/2400 Bits/s05 - 4800/4800 Bits/s06 - 9600/9600 Bits/s07 - 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 CDefault: Not applicable. When captured only valid values shall be recorded.Example:Data Rate (1200/75 Bits/s): 003C
Table 95 Data rate atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 167
B5.2.44 Data Volume
This field is associated with packet data services. The field encoding is shown in Table 96.
NOTE This 6 character atomic data field shall always be set to its default value. This default value is 00000C.
B5.2.45 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 97.
NOTE 1 Characters 1 and 2 use the following interpretation for the year: 50 - 99 indicate the years 1950 - 199900 - 49 indicate the years 2000 - 2049
(continued)
Field Used In: Module: DS.
Character Description Values 1-5 Data Volume {00000....99999} 6 Sign Character C Default: 00000CExample: Data Volume: 00000C
Table 96 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.
Character Description Values1-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 CDefault: FFFFFFFFFFFFFFFCExample:Date and Time: 930304122053400C
Table 97 Date and time atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 168 (Approved) 30th March 2005
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 switched on, characters 14 and 15 are used to indicate the timezone offset between the MSC and the handset as shown in Tables 98 and 99.
Recordsa
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 141) Y Y
Channel Allocation Time (B5.2.31 on page 159) Y Y
Classmark Time Stamp (B5.2.36 on page 161) Y Y
Date and Time Y
Delivery Timestamp (B5.2.48 on page 171) Y Y
Disconnect Time (B5.2.53 on page 181) Y Y
Incoming/Outgoing Trunk Seizure Time (B5.2.81 on page 194) Y Y
Release Time (B5.2.162 on page 234) Y Y
SMS Time Stamp (Section B5.2.184) Y Y
Table 98 Timestamp fields in call records which may capture timezone offset values
Information Modulesa
a. Bearer Service (BSLocation and Channel (L&C) Supplementary Service (SS)Teleservice (TS)Advice of Charge (AoC)Data ServiceEqual AccessIntelligent 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.92 on page 199) Y
Carrier Connect Timestamp (B5.2.28 on page 157) Y
IN Timestamp 1 (B5.2.76 on page 192) Y
IN Timestamp 2 (B5.2.77 on page 192) Y
SMS Start Time (B5.2.182 on page 245) Y
SMS Stop Time (B5.2.183 on page 245) Y
Unused Timestamp 1 (B5.2.201 on page 256) Y
Unused Timestamp 2 (B5.2.202 on page 256) Y
Table 99 Timestamp fields in modules which may capture timezone offset values when appended to call records
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 169
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 100 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
18 +12hr 19 +12hr 30min 1A +13hr 1B +13hr 30min
1C +14hr 1D +14hr 30min 1E +15hr 1F +15hr 30min
20 +16hr 21 +16hr 30min 22 +17hr 23 +17hr 30min
24 +18hr 25 +18hr 30min 26 +19hr 27 +19hr 30min
28 +20hr 29 +20hr 30min 2A +21hr 2B +21hr 30min
2C +22hr 2D +22hr 30min 2E +23hr 2F +23hr 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 100 Timezone offset values
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 170 (Approved) 30th March 2005
B5.2.46 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 101.
B5.2.47 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 102.
Field Used In: Module: CSMS.
Character(s) Description Values1 Condition 0 - No
1 - Yes2 Sign Character CDefault: FCExample:Default SMS Handling applied: 1C
Table 101 Default SMS handling applied (DSH applied) atomic data field
Field Used In: Module: CSMS.
Character(s) Description Values1 Condition 0 - Continue Call
1 - Release Call 2 Sign Character CDefault: FCExample:Default SMS Handling Indicator (Continue Call): 0C
Table 102 Default SMS handling indicator (DSH indicator) atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 171
B5.2.48 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.45 on page 167.
B5.2.49 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 143.
For the GSM-R functional addressing service, the Connect message sent by the SCP contains the MSISDN associated with the called party’s 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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 172 (Approved) 30th March 2005
B5.2.50 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 103.
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.
Character Description Values 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: 000CExamples:Mobile originated on-board call: 002C
Table 103 Detection point atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 173
B5.2.51 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 66. The field encoding is shown in Table 104.
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 105 refers to other tables which show the values captured for each agency.
Field Used In: Records: MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP.
Character Description Values1-2 Protocol 00 - 3GPP TS 24.008
GSM TS 04.68 and GSM TS 04.6901 - 3GPP TS 29.002 02 - ITU-T Q.76703 - Network Specific Cause04 - Manufacturer Specific Cause05 - Unknown
3-5 Error Code See Table 1056 Sign Character CDefault: FFFFFCExamples:02016C: ITU-T ISUP - Normal Release05003C: MF - NO Circuit Available04016C: ANSI ISUP - Normal Release03004C: ATUP, MTUP or Blue Book TUP - National Network Congestion00017C: MS - User Busy
Table 104 Diagnostic atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 174 (Approved) 30th March 2005
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.51.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 Requirementa
a. No = no mapping is required. The signalling cause value is captured directly into the billing record. Table 106 through Table 108 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. Table 110 through Table 114 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 108 Radio layer 3GSM TSs 04.68 and 04.69 No Group call control and broadcast call control cause
values as specified in Table 109GCC and BCC
01 3GPP TS 29.002 No Not Supportedb
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 106 ITU-T ISUP03 Network Specific Cause
(See the following tables for mappings)
Yes 000 - 050 (Table 110) ATUPYes 000 - 050 (Table 111) Blue Book TUP Yes 000 - 050 (Table 112) Italian TUP (ITTUP) Yes 000 - 050 (Table 113) MTUPYes All other values reserved -
04 Nortel Specific Cause No ISUP Cause value as specified in Table 107 ANSI ISUP05 Unknown No 000 - Cause for termination Unknown MF
Yes 001-050 (Table 114) MF
Table 105 Error code value settings
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 175
NOTE Portuguese ISUP also uses the nationally defined cause value 14 “Query on Release” for Mobile Number Portability.
Cause Value Error codeUnallocated number 1No route to specified transit network 2No route to destination 3Send special information tone 4Misdialled trunk prefix 5Pre-emption 8Pre-emption-circuit reserved for reuse 9 Normal clearing 16User busy 17No user responding 18No answer from user 19Absent Subscriber 20Call rejected 21Number changed 22Destination out of order 27Address incomplete 28Facility rejected 29Normal, unspecified 31No circuit available 34Network out of order 38Temporary failure 41Switching equipment congestion 42Request channel not available 44precedence call blocked 46Resource unavailable, unspecified 47Requested facility not subscribed 50Incoming calls barred within CUG 55BC not authorized 57BC presently not available 58Serv/opt not available, unspecified 63BC not implemented 65Requested facility not implemented 69Only restricted digital information 70Service/option not implemented unspecified 79User not member of CUG 87Incompatible destination 88Invalid transit network selection 91Invalid message, unspecified 95Message Type not implemented 97Parameter not implemented 99Recovery on timer expiry 102Parameter not implemented, passed on 103Protocol error, unspecified 111Interworking, unspecified 127
Table 106 ITU-T ISUP cause valuesaa. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 176 (Approved) 30th March 2005
Cause Value Decimal ValueUnallocated Number 1No Route to Transit Network 2No Route to Destination 3Send Special information Tone 4Misdialled Trunk Prefix 5Normal clearing 16User busy 17No User Responding 18No Answer From User (User Alerted) 19Call Rejected 21Number Changed 22Translations Failure 25Call Returns 26Destination Out of Service 27Address Incomplete 28Facility Rejected 29Apply Locally 30Normal, Unspecified 31No Circuit Available 34Network Out of Order 38Temporary Failure 41Switching Equipment Congestion 42User information Discarded 43Requested Channel not Available 44Pre-emption 45No pre-emption Circuit Available 46Resource Unavailable, Unspecified 47Outgoing Calls Barred 52Incompatible Agents 53Bearer Capability Not Authorized 57Bearer Capability Presently Not Available 58Service or Option Not Available Unspecified 63Bearer Capability Not Implemented 65Channel Type Not Implemented 66Facility Not Implemented 69Only Restricted Digital Information 70Service or Option Not implemented 79Invalid Reference Value 81Incompatible Destination 88Invalid TNS 91Invalid Message, Unspecified 95Message Type Not implemented 97Parameter Not implemented 99 Invalid Parameter Contents 100Recovery on Timer Expiration 102Parameter Not Implemented, Passed on 103Protocol Error, Unspecified 111Interworking, Unspecified 127
Table 107 ANSI ISUP cause valuesa
a. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 177
Cause Value Error CodeNIL 0Unallocated number 1No route to destination 3Channel unacceptable 6Operator determined barring 8Normal call clearing 16User busy 17No user responding 18User alerting, no answer 19Call rejected 21Number changed 22Pre-emption 25 Non selected user clearing 26Destination out of order 27Invalid number format (incomplete number) 28Facility rejected 29Response to status enquiry 30Normal, unspecified 31No circuit available 34Network out of order 38Temporary failure 41Switching equipment congestion 42Access info discarded 43Requested circuit/channel not available 44Resource unavailable, unspecified 47Quality of service unavailable 49Requested facility not subscribed 50Incoming calls barred within the CUG 55Bearer capability not authorized 57Bearer capability not presently available 58Service or option not available, unspecified 63Bearer service not implemented 65ACM equal to or greater than ACM max 68Requested facility not implemented 69Only restricted digital information bearer capability is available 70Service or option not implemented, unspecified 79Invalid transaction identifier value 81User not member of CUG 87Incompatible destination 88Invalid transit network selection 91Semantically incorrect message 95Invalid mandatory information 96Message type non-existent or not implemented 97Message type not compatible with protocol state 98Information element non-existent or not implemented 99Conditional IE error 100Message not compatible with protocol state 101Recovery on timer expiry 102Protocol error, unspecified 111Interworking, unspecified 127
Table 108 3GPP TS 24.008 radio layer 3 cause valuesa
a. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 178 (Approved) 30th March 2005
B5.2.51.2 Signalling Agents and Required Mappings
This section contains the mappings required for the following signalling agencies:
• Table 110, ‘ATUP cause values and error codes’
• Table 111, ‘Blue Book TUP cause values and error codes’
• Table 112, ‘Italian TUP (ITTUP) cause values and error codes’
• Table 113, ‘MTUP cause values and error codes’
• Table 114, ‘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 Protocol error, unspecified 112
Table 109 GSM TSs 04.68 and 04.69 GCC and BCC cause valuesa
a. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 179
ATUP Cause Values Error CodeAddress Incomplete (ADI) 000Call Failure (CFL) 001Circuit Group Congestion (CGC) 002Line Out of Service (LOS) 003National Network Congestion (NNC) 004Switching or Circuit Congestion (SCC) 005Switching Equipment Congestion (SEC) 006Send Special Info Tone (SST) 007Unallocated Number (UNN) 008Subscriber Busy (SSB) 009Clear Forward (CLF) 015Clear Backward (CBK) 016Force Release (FRL) 017
Table 110 ATUP cause values and error codesa
a. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
Blue Book TUP Cause Values Error CodeAddress Incomplete (ADI) 000Call Failure (CFL) 001Circuit Group Congestion (CGC) 002Line Out of Service (LOS) 003National Network Congestion (NNC) 004Switching Equipment Congestion (SEC) 006Send Special Info Tone (SST) 007Unallocated Number (UNN) 008Subscriber Busy (SSB) 009Access Barred (ACB) 012Digital Path Not Provided (DPN) 013Extended Unsuccessful Message (EUM) 014Clear Forward (CLF) 015Clear Backward (CBK) 016
Table 111 Blue Book TUP cause values and error codesa
a. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
Italian TUP Cause Values Error Code Address Incomplete (ADI) 000 Call Failure (CFL) 001 International Congestion Signal (INC) 002 Line Out of Service (LOS) 003 National Network Congestion (NNC) 004 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 112 Italian TUP (ITTUP) cause values and error codesaa. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 180 (Approved) 30th March 2005
B5.2.52 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 115.
MTUP Cause values Error codeAddress Incomplete (ADI) 000Call Failure (CFL) 001Circuit Group Congestion (CGC) 002Line Out of Service (LOS) 003National Network Congestion (NNC) 004Switching or Circuit Congestion (SCC) 005Switching Equipment Congestion (SEC) 006Send Special Info Tone (SST) 007Unallocated Number (UNN) 008Subscriber Local Busy (SLB) 010Subscriber Toll Busy (STB) 011Access Barred Signal (ACB) 012Digital Path Not Provided (DPN) 013Extended Unsuccessful Message (EUM) 014Clear Forward (CLF) 015Clear Backward (CBK) 016Force Release (FRL) 017
Table 113 MTUP cause values and error codesa
a. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
MF Cause values Error codeNormal Clearing 001Forced Release or Abnormal Clearing 002No Circuit Available 003Incompatible Agents 004Data Call Denied 005Datafill Trouble 006Start Wink Failure 007First Equal Access Wink Failure 008Second Equal Access Wink Failure 009Acknowledgement Wink Failure 010First Stage Outpulsing Trouble 011Second Stage Outpulsing Trouble 012No Answer from User 013Subscriber Busy 014Subscriber Out of Order 015Congestion 016Unassigned Number 017
Table 114 MF cause values and error codesa
a. Shaded entries indicate values which correspond to a Cause for Termination (CFT) value of Normal Release.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 181
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.53 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.45 on page 167.
B5.2.54 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 116.
Field Used In: Record: MO.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122BCD or Hex String (32) Notes 32 B5.2.10
Table 115 Dialled digits data field
Field Used In: Records: MO, MT. Module: GASSP.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 182 (Approved) 30th March 2005
B5.2.55 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 143.
B5.2.56 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 encoding is shown in Table 117.
Field Used In: Module: AoC.
Character Description Values1 Spare 02-5 E-Parameter {0000....8191}6 Sign Character CDefault: FFFFFCExample:E-Parameter: 04567C
Table 116 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 117 ESRK-Key atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 183
B5.2.57 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 118.
B5.2.58 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 119.
B5.2.59 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 120.
Field Used In: Record: CEU.
Character Description Values1-5 Equipment Identity 00001 - MSC
00002 - Media Gateway 6 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Equipment Identity: 00002C (equipment provided on an MGW)
Table 118 Equipment identity atomic data field
Field Used In: Record: CEU.
Character Description Values 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 CDefault: Not applicable. When captured only valid values shall be recorded.Example:Equipment Type: 00001C (3-port multi-party service)
Table 119 Equipment type atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 184 (Approved) 30th March 2005
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.60 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 143.
B5.2.61 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 121.
Field Used In: Module: INC.
Character Description Values 1-4 Data Descriptor 0000 ... FFFF5-44 Freeform billing data All 0s to all Fs45 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 120 FCI freeform parameter atomic data field
Field Used In: Switch/Billing File Records: BFTIR, BFTOR.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 185
B5.2.62 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 122.
The CAMEL charging information module (B4.2.18 on page 121) 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 123 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.
Character Description Values1-3 File Transfer Type 000 - Incoming Transfer
001 - Outgoing Transfer002 - Outgoing Emergency Transfer
4 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:File Transfer Type (Outgoing Transfer): 001C
Table 121 File transfer type atomic data field
Field Used In: Module: CC.
Character Description Values 1 Padding F2-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,F42 Sign Character CDefault: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCExample: F1234567895839567891269870789121947789123C
Table 122 CAMEL free format data atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 186 (Approved) 30th March 2005
B5.2.63 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 124.
B5.2.64 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.64 to B5.2.68). 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.
Default: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Example: F1234567895839567891269870789121947789123CF4579361234560916234569025234567893601196CFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Table 123 Default and Example Values for Eight Free Format Data Fields
Field Used In: Record: Ack.
Character Description Values1-15 Functional number 000000000000000 - 99999999999999916 Sign Character CDefault: FFFFFFFFFFFFFFFC.Example:Functional number: 003026178911101C
Table 124 Functional number atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 187
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.
B5.2.65 Geographical Location of UE 2
This field captures the location of the user equipment (mobile station etc.) provided by a 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.64. The field encoding is shown in Table 126.
B5.2.66 Geographical Location of UE 3
This field captures the location of the user equipment (mobile station etc.) provided by a location service (LCS). It captures the 40th to 59th 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 40 bytes. If the location information received is less than 40 bytes, this field contains default values. For more information, please see B5.2.64. The field encoding is shown in Table 127.
Field Used In: Record: LCS.
Character(s) Description Values
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
Default: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Example:Geographical Location of UE: F5500023556771FA432134FFF0110001F00000F78C
Table 125 Geographical location of UE 1 atomic data field
Field Used In: Record: LCS.
Character(s) Description Values
1 Spare F
2-41 Location Estimate - bytes 20 to 39 {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E, F}
42 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Example:Geographical Location of UE: FFFFFFFFFFFFFFFFFFF8983001244882166300F62C
Table 126 Geographical location of UE 2 atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 188 (Approved) 30th March 2005
B5.2.67 Geographical Location of UE 4
This field captures the location of the user equipment (mobile station etc.) provided by a location service (LCS). It captures the 60th to 79th 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 60 bytes. If the location information received is less than 60 bytes, this field contains default values. For more information, please see B5.2.64. The field encoding is shown in Table 128.
B5.2.68 Geographical Location of UE 5
This field captures the location of the user equipment (mobile station etc.) provided by a location service (LCS). It captures the 80th to 91st 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 80 bytes. If the location information received is less than 80 bytes, this field contains default values. For more information, please see B5.2.64. The field encoding is shown in Table 129.
Field Used In: Record: LCS.
Character(s) Description Values
1 Spare F
2-41 Location Estimate - bytes 40 to 59 {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E, F}
42 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Example:Geographical Location of UE: FFFFFFFFFFFFFFFFFFFFFFFFF0113221231332231C
Table 127 Geographical location of UE 3 atomic data field
Field Used In: Record: LCS.
Character(s) Description Values
1 Spare F
2-41 Location Estimate - bytes 60 to 79 {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E, F}
42 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC
Example:Geographical Location of UE: FFE7F283FF7824BC53AF85674230113221231332231
Table 128 Geographical location of UE 4 atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 189
B5.2.69 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 130.
B5.2.70 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 145.
Field Used In: Record: LCS.
Character(s) Description Values
1 Spare F
2-23 Location Estimate - bytes 80 to 91 {0,1,2,3,4,5,6,7,8,9,A,B,C,D,E, F}
24 Sign Character C
Default: FFFFFFFFFFFFFFFFFFFFFFFC
Example:Geographical Location of UE: FFFFFFF0113221231332231C
Table 129 Geographical location of UE 5 atomic data field
Field Used In: Record: Ack.
Character Description Values1 Unused 02-9 Group call reference number 00000000 - 9999999910 Sign Character CDefault: 0FFFFFFFFC.Example:Group reference: 000000011C
Table 130 Group call reference atomic data field
Field Used In: Records: MO, MT.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 190 (Approved) 30th March 2005
B5.2.71 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.155 on page 231. The field encoding is shown in Table 131.
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 customer’s 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.72 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 is shown in Table 132.
Field Used In: Records: All Call Detail Records. All Switch/Billing File Records.
Character Description Values1 Constant A2 Record Quality A - Good Record
B - Data Errors Encountered Default: Not applicable. When captured only valid values shall be recorded. Example:Hexadecimal Identity (Good Record): AA
Table 131 Hexadecimal identity atomic data field
Field Used In: Records: SSA, Ack.
Character Description Values 1 Hot billing I 0 - Normal record
1 - Hot billing record 2 Sign C Default: 0C. Example:Hot billing record: 1C
Table 132 Hot billing indicator atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 191
B5.2.73 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 143.
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.74 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 133.
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.75 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 134.
Field Used In: Module: CSMS.
Field Used In: Module: CSMS.
Character(s) Description Values1 Condition 0 - Failure
1 - Success 2 Sign Character CDefault: FCExample:IN Dialogue Result (Success): 1C
Table 133 IN dialogue result atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 192 (Approved) 30th March 2005
B5.2.76 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.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.45 on page 167.
B5.2.77 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.76) 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.45 on page 167.
Field Used In: Modules: CSMS, GASSP, IN.
Character Description Values1 IN Protocol 0 - CS1-R
1 - CAP (CAMEL Application Part) Phase 12 - CAP Phase 23 - CAP Phase 34 - C AP Phase 45 - CAP Phase 56 - Unknown ProtocolAll other values spare
2 Sign Character CDefault: FCExample:IN Protocol (CAP Phase 3): 3C
Table 134 IN Protocol atomic data field
Field Used In: Module: IN.
Field Used In: Module: IN.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 193
B5.2.78 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 135.
B5.2.79 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 operator’s 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 136.
Field Used In: Records: ICG, ICIP, OGG, Tr, OGIP.
Character Description Values1 Spare 02-3 Metering Class 00 - Unknown
01 - Ordinary02 - Test03 - Payphone
4 Sign Character CDefault: 000CExample: Incoming Metering Class (Test): 002C
Table 135 Incoming/outgoing metering class atomic data field
Field Used In: Records: MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP.
Character Description Values1-3 Route Group {000....127}4 Sign Character CDefault: FFFCExample:Incoming Route Group (Route Group 014): 014C
Table 136 Incoming/outgoing route group atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 194 (Approved) 30th March 2005
B5.2.80 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.45 on page 167.
B5.2.81 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.45 on page 167.
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 channel’s 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: Records: MO, MT, Ro, ICG, OGG, Tr, ICIP, OGIP.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 195
B5.2.82 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 143.
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.83 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 143.
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.84 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 137.
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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 196 (Approved) 30th March 2005
B5.2.85 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 138.
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.
Character Description Values1 Information Transfer Capability 0 - 3.1 kHz. Audio
1 - Fax Group 32 - Unrestricted Digital Information
2 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Information Transfer Capability (3.1kHz, Audio): 0C
Table 137 Information transfer capability atomic data field
Field Used In: Module: EA.
Character Description Values1 Spare 02-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.orOff 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 CDefault: FFFCExample:IC/INC Call event status: 001C
Table 138 IC/INC call event status atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 197
B5.2.86 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 139.
B5.2.87 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 140.
B5.2.88 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 141.
Field Used In: Module: EA.
Character Description Values1-8 Carrier Identity 00000000 ... 000999999 Operator 0 - Operator involved
1 - Direct dialled (No operator involved) 2 - Cannot determine if operator involved
10 Sign Character CDefault: FFFFFFFFFCExample: IC/INC Prefix: 000000021CIC/INC Prefix (PETMF): 000003332C
Table 139 IC/INC prefix atomic data field
Field Used In: Module: DS.
Character Description Values1-5 IWF Trunk Group {00000....08191}6 Sign Character CDefault: FFFFFCExample:Interworking Function Trunk Group (Trunk 4/MS Side): 00004C
Table 140 Interworking function trunk group atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 198 (Approved) 30th March 2005
B5.2.89 IP Address Identity
This field is part of the IP (intelligent peripheral) Routing Address field described in Section B5.2.90. It identifies the IP which is connected to the assisting SSP. It is encoded as an eight character BCD/hex string as defined in Section B5.2.10 on page 143.
B5.2.90 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 142. 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 fields as shown in Table 142.
Field Used In: Module: DS.
Character Description Values1-5 IWF Trunk Member {00000....09999}6 Sign Character CDefault: FFFFFCExample:Interworking Function Trunk Member (Member 12/Network Side): 00012C
Table 141 Interworking function trunk member atomic data field
Field Used In: Module: GASSP.
Field Used In: Module: GASSP.
Field Type Number of Characters Detailed ReferenceIP Address Identity 8 B5.2.89MSC ID 6 B5.2.113Counter 10 B5.2.40
Table 142 IP routing address
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 199
B5.2.91 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 143.
B5.2.92 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 atomic data field as described in Section B5.2.45 on page 167.
Field Used In: Module: GASSP.
Character Description Values1 Spare F2 IPRoutingAddress 0 - IPRoutingAddress Not Supported
1 - IPRoutingAddress Supported3 Voice Back 0 - Voice Back Not Supported
1 - Voice Back Supported4 Voice Information Via Speech Recognition 0 - Voice Information Not Supported, Via Speech Recognition
1 - Voice Information Supported, Via Speech Recognition5 Voice Information Via Voice Recognition 0 - Voice Information Not Supported, Via Voice Recognition
1 - Voice Information Supported, Via Voice Recognition6 Voice Announcement From Text 0 - Generation of Voice Announcements From Text Not Supported
1 - Generation of Voice Announcements From Text Supported7-8 Reserved 009 End of Standard Part 0 - End of Standard Part
1 - This Value Is Reserved In Cap V.210 Sign Character CDefault: FFFFFFFFFCExample:IP SSP Capability: F00000000C
Table 143 IP SSP capability atomic data field
Field Used In: Module: DS.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 200 (Approved) 30th March 2005
B5.2.93 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 144.
B5.2.94 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 145.
Field Used In: Module: DS.
Character Description Values 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 144 IWF diagnostic code atomic data field
Field Used In: Record: LCS.
Field Type Number of Characters Detailed ReferenceNumbering Plan Identifier 6 B5.2.123BCD or Full Hex String (26) 26 B5.2.9
Table 145 LCS client identity data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 201
B5.2.95 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 146.
B5.2.96 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 147.
Field Used In: Record: LCS.
Character Description Values
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 146 LCS client type atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 202 (Approved) 30th March 2005
B5.2.97 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.45 on page 167.
B5.2.98 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 148.
Field Used In: Record: LCS.
Character Description Value1 Congestion 0
Insufficient_Resource 1Insufficient_measurement_data 2Inconsistent_measurement_data 3Location_procedure_not_comleted 4Location_procedure_not_supported_by_TargetMS 5QOS_NotAttainable 6Position_method_not_available_in_network 7Postion_methodZ_not_available_in_LocationArea 8
Default: FCExample:Insufficient_Resource: 1C
Table 147 LCS Diagnostic atomic data field
Field Used In: Record: LCS.
Field Used In: Record: LCS.
Character Description Values1 Padding Character F2 Spare 03 Priority Level 0=Normal Priority
1=Higher Priority4 Sign Character CDefault: FFFCExample:Notify Location Allowed: F01C
Table 148 LCS Priority Level atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 203
B5.2.99 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 149.
B5.2.100 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 150.
Field Used In: Record: LCS.
Character Description Values
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 149 LCS record type atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 204 (Approved) 30th March 2005
B5.2.101 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 atomic data field as described in Section B5.2.45 on page 167.
Field Used In: Record: LCS.
Character(s) Description Values1 Spare 02-3 Success 00
LCS Cause Unspecified 01System Failure 02Protocol Error 03Data Missing 04Unexpected Data Value 05Position Method Failure 06Target MS Unreachable 07Location Request Aborted 08Facility Not Supported 09Inter BSC Handover Ongoing 10Intra BSC Handover Complete 11Congestion 12Unauthorized LCS Client 13Unauthorized Requesting Network 14Subscription Violation 15SOC Idle 16
4 Sign Character CDefault: Not applicable, either the success or failure cause will be recorded. Example:LCS Result (Illegal Subscriber): 006CLCS Result (Success): 000C
Table 150 LCS result atomic data field
Field Used In: Record: LCS.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 205
B5.2.102 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. The field encoding is shown in Table 151.
B5.2.103 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 152 (2-digit MNCs) and Table 153 (3-digit MNCs).
(continued)
Field Used In: Modules: CC, IN.
Character Description Values1 Spare 02-11 Local Reference Number 0000000001 ... 999999999912 Sign Character CDefault: 00000000000C Example: 00000000023C
Table 151 Local reference number atomic data field
Field Used In: Record: SSA. Modules: LaC, LO.
Character Description Values1 Spare 02-4 Mobile Country Code {000....999}5-6 Mobile Network Code {00....99}7-11 Location Area Code {00000....99999}12 Sign Character CDefault: 00000000000CExample:Location Area Code: 00011300234C
Table 152 Location area code atomic data field - 2-digit MNCsCharacter Description Values
1-3 Mobile Country Code {000....999} 4-6 Mobile Network Code {000....999} 7-11 Location Area Code {00000....99999} 12 Sign Character C Default: 00000000000C Example: Location Area Code: 11378600234C
Table 153 Location area code atomic data field - 3-digit MNCs
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 206 (Approved) 30th March 2005
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.104 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 327. The field encoding is shown in Table 154.
B5.2.105 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 143.
B5.2.106 Metering Zone
This field defines a separate charging zone of a logical network (B5.2.104). 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 327. The field encoding is shown in Table 155.
Field Used In: Records: Ro, ICG, OGG, Tr, ICIP, OGIP.
Character Description Values1 Spare 02-3 Logical Network {00....15}4 Sign Character CDefault: FFFCExample:Logical Network: 012C
Table 154 Logical network atomic data field
Field Used In: Record: SMSMO.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 207
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.107 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 156.
B5.2.108 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.45 on page 167.
Field Used In: Records: Ro, ICG, OGG, Tr, ICIP, OGIP.
Character Description Values1 Spare 02-3 Metering Zone {00....63}4 Sign Character CDefault: FFFCExample:Metering Zone: 012C
Table 155 Metering zone atomic data field
Field Used In: Modules: BICN.
Character(s) Description Values
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 156 MGW Number atomic data field
Field Used In: Module: BICN.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 208 (Approved) 30th March 2005
B5.2.109 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 157.
B5.2.110 Module Code
This field contains a code value which identifies the information module containing the field. The field encoding is shown in Table 158.
Field Used In: Record: LU.
Character Description Values1 Spare 02 MM Result 0 - Failed to send Note MM Event message
1 - Note MM Event message sent3 MM Event 0 - Location Update on the Same VLR
1 - Location Update on a different VLR2 - Attach of IMSI3 - Detach of IMSI by the MS4 - Detach of IMSI by the NetworkF - Unknown
4 Sign Character CDefault: 00FCExample:MM Event (Message sent, Attach of IMSI): 012C
Table 157 MM Event atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 209
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 263 (PCS market module codes)
• B5.4.3 on page 269 (Singapore market code)
• B5.5.2 on page 272 (German and Austrian market module code).
B5.2.111 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 159.
Field Used In: Modules: All modules.
Character Description Values (Billing)1-3 Module Code 000 - End of Module List
001- Unused 002 - Bearer Services Information003 - Location and Channel Information004 - Location Only Information005 - Supplementary Services Information006 - Teleservices Information007 - AoC Information008 - Tariff Class Information009 - Data Information010 - Other Agent Information012 - 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 Information026 - GSM Assisting SSP Information 027 - CAMEL Short message Service (SMS) Information 028 - Patching Information029 - Bearer Independent Core Network
4 Sign Character CDefault: Not applicableExample:Module Code (Bearer Services Information): 002C
Table 158 Module code atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 210 (Approved) 30th March 2005
Field Used In: Records: MO, MT, SMSMO, SMSMT, SSA.
Character Description Values
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
1 – 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 159 MS Classmark atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 211
B5.2.112 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 160.
B5.2.113 MSC ID
This field is part of the IP (intelligent peripheral) Routing Address field described in Section B5.2.90 on page 198. 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 143.
Option
14 Character 10 = 0 - F
Or
14 Character 10 = 1 Encryption Algorithm 1 – Algorithm 5/4 Available
2 – Algorithm 5/5 Available
3 – Algorithm 5/6 Available
4 – Algorithm 5/7 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.
Field Type Number of Characters Detailed Reference Numbering Plan Indicator 6 B5.2.123 BCD or Hex String (22) 22 B5.2.10
Table 160 MSC address data field
Field Used In: Module: GASSP.
Table 159 MS Classmark atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 212 (Approved) 30th March 2005
B5.2.114 MSC Number
This field captures the E.164 number of the MSC producing the record. It consists of two fields as shown in Table 161. The office parameter GSMMSC_Number in table OFCVAR sets the MSC Number.
B5.2.115 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 162.
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.
Field Type Number of Characters Detailed ReferenceNumbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 161 MSC Number data field
Field Used In: Record: CEU.
Field Type Number of Characters Detailed ReferenceNumbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 162 MSC/MGW Number data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 213
B5.2.116 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 143.
B5.2.117 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 172.
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.
Character Description Values 1 Access Network 0 - GSM
1 - UMTS 2 Sign Character C Default: 0C. Example: Access Network (UMTS Network): 1C
Table 163 New AN atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 214 (Approved) 30th March 2005
B5.2.118 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 173.
B5.2.119 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 174 (2-digit MNCs) and Table 175 (3-digit MNCs).
Field Used In: Record: LU.
Character Description Values1-5 Cell Identity/Service Area Code (Integer value) {00000....99999}6 Sign Character CDefault: FFFFFCExample:Cell-SAC Id: 00124C
Table 164 New Cell-SAC id atomic data field
Field Used In: Record: LU.
Character Description Values1 Spare 02-4 Mobile Country Code {000....999}5-6 Mobile Network Code {00....99}7-11 Location Area Code {00000....99999}12 Sign Character CDefault: 00000000000CExample:Location Area Code: 00011300234C
Table 165 New LAC atomic data field - 2-digit MNCs Character Description Values
1-3 Mobile Country Code {000....999} 4-6 Mobile Network Code {000....999} 7-11 Location Area Code {00000....99999} 12 Sign Character C Default: 00000000000C Example: Location Area Code: 11378600234C
Table 166 New LAC atomic data field - 3-digit MNCs
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 215
B5.2.120 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 176.
B5.2.121 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 143.
B5.2.122 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 168.
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.
Field Type Number of Characters Detailed ReferenceNumbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 167 New MSC id data field
Field Used In: Module: DS.
Generic field type used by other fields. Character Description Values
1 Number Type 0 - None1 - IMSI2 - MSISDN3 - MSRN4 - IMEI5 - TMSI6 - Dialled Digits7 - Charge Number/ANI8 - Generic Address Parameter 9 - Normalised
2 Sign Character CDefault: 0CExample:Number Type (IMEI): 4C
Table 168 Number type atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 216 (Approved) 30th March 2005
B5.2.123 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 169.
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.124 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 145.
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.
Generic field type used by other fields. Character Description Values
1 Spare 02 Extension Indicator 0 - Extension
1 - No Extension3 (See Note) Nature of Address Indicator 0 - Unknown
1 - International Number2 - National Significant Number3 - Network Specific Number4 - Dedicated PAD Access
4-5 (See Note) Numbering Plan Indicator 00 - Unknown01 - ISDN (E.164) Number02 - Spare03 - Data Numbering Plan04 - Telex NUmbering Plan05 - National Use 06 - National Use07 - Spare08 - National Numbering Plan09 - Private Numbering Plan
6 (See Note) Sign Character CDefault: 01000C (See Notes)
FFFFFCExample:Numbering Plan Identifier (Extension, Unknown, National Use): 00005C (See Note)
Table 169 Numbering plan identifier atomic data field
Field Used In: Records: MO, MT.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 217
B5.2.125 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 170.
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.126 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 171.
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.
Character Description Values 1 Unused 0 2-3 Off-Board IN Service Identifier 00-04 Unused
05-15 Off-board IN service identifier 4 Sign C Default: FFFCExample: IN Service Identifier: 014C
Table 170 Off-board IN service identifier atomic data field
Field Used In: Module: IN.
Character Description Values 1-3 Off-Board IN Service Indicator 000 - 255 4 Sign C Default: FFFCExample: IN Service Indicator: 001C
Table 171 Off-board IN service indicator atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 218 (Approved) 30th March 2005
B5.2.127 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 172.
NOTE If the Old AN information is not available, the field defaults to value 0C.
B5.2.128 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 173.
B5.2.129 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 174 (2-digit MNCs) and Table 175 (3-digit MNCs).
Field Used In: Record: LU.
Character Description Values 1 Access Network 0 - GSM
1 - UMTS 2 Sign Character C Default: 0CExample: Access Network (UMTS Network): 1C
Table 172 Old AN atomic data field
Field Used In: Record: LU.
Character Description Values1-5 Cell Identity/Service Area Code (Integer value) {00000....99999}6 Sign Character CDefault: FFFFFCExample:Cell-SAC Id: 00124C
Table 173 Old Cell-SAC id atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 219
B5.2.130 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 176.
B5.2.131 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 177.
Field Used In: Record: LU.
Character Description Values1 Spare 02-4 Mobile Country Code {000....999}5-6 Mobile Network Code {00....99}7-11 Location Area Code {00000....99999}12 Sign Character CDefault: 00000000000CExample:Location Area Code: 00011300234C
Table 174 Old LAC atomic data field - 2-digit MNCs Character Description Values
1-3 Mobile Country Code {000....999} 4-6 Mobile Network Code {000....999} 7-11 Location Area Code {00000....99999} 12 Sign Character C Default: 00000000000C Example: Location Area Code: 11378600234C
Table 175 Old LAC atomic data field - 3-digit MNCs
Field Used In: Record: LU.
Field Type Number of Characters Detailed ReferenceNumbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 176 Old MSC id data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 220 (Approved) 30th March 2005
B5.2.132 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 178.
(continued)
Field Used In: Module: CSMS.
Character(s) Description Values1 - 25Each character in the field can take one of the indicated values
Operation History 1 - Unsupported Operation 2 - InitialDP SMS 3 - SCP Empty End4 - SSF Empty End5 - SCP Error (Error/reject/abort)6 - SSF Error (Error/reject/abort)7 - EventReportSMS8 - ConnectSMS9 - ContinueSMSA - Release SMSB - FCI (Furnish Charging Information) SMSC - RequestReportSMSD - ResetTimerSMS
26 Sign Character CDefault: FFFFFFFFFFFFFFFFFFFFFFFFFCExample:Operation History: FFFFFFFFFFFFFFFFFFF2BBC87CEach 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 177 Operation history atomic data field
Field Used In: Module: IN.
Character Description Values 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 178 Operation indication atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 221
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.
B5.2.133 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.25 on page 154) captures the number of the redirecting party. It consists of three fields as shown in Table 179.
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).
Field Used In: Module: GA.
Field Type Number of Characters Detailed Reference Number Type 2 B5.2.122 Numbering Plan Identifier 6 B5.2.123 BCD or Hex String (32) 32 B5.2.10
Table 179 Original calling number data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 222 (Approved) 30th March 2005
B5.2.134 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 143. 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.135 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 143. 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.136 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 180.
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.
Character Description Values1 Spare 02-3 Event Code 01 - First
02 - Subsequent 03 - Last
4 Sign Character CDefault: FFFCExample:Partial record event code: 001C
Table 180 Partial record event code atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 223
B5.2.137 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 181.
B5.2.138 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 143.
B5.2.139 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 143.
Field Used In: Module: PI.
Character Description Values1 Spare 02-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 CDefault: FFFCExample:Partial record reason (Long duration): 000C
Table 181 Partial record reason atomic data field
Field Used In: Module: PI.
Field Used In: Module: PI.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 224 (Approved) 30th March 2005
B5.2.140 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 182.
NOTE The party to charge is always set to 01C (calling party) for CAMEL mobile originated SMS.
B5.2.141 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 143.
B5.2.142 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 183.
Field Used In: Module: CC.
Character Description Values 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 182 Party to charge atomic data field
Field Used In: Module: Pa.
Field Used In: Module: MNP.
Character Description Values 1 Query Method Type 0 Unknown
1 Ported Number2 Non-ported Number
2 Sign Character C Default: 0C. Example: 1C - Ported number
Table 183 Ported status atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 225
B5.2.143 Positioning Data
This field captures information about the positioning method used or attempted during a Location Service (LCS) to provide the subscriber’s location. The positioning method is used to get an estimate of the subscriber’s 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 for UTRAN positioning methods and to 3GPP TS 43.059 for GERAN positioning methods. The field encoding is shown in Table 184 and information about the positioning values and methods is provided in Table 185.
Field Used In: Module: LCS.
Character Description Values: see Table 185
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
13-14 5th Positioning method 00 - 12
15 5th Usage 0 - 5
16-17 6th Positioning method 00 - 12
18 6th Usage 0 - 5
19-20 7th Positioning method 00 - 12
21 7th Usage 0 - 5
22-23 8th Positioning method 00 - 12
24 8th Usage 0 - 5
25-27 9th Positioning method 00 - 12
27 9th Usage 0 - 5
28 Sign Character C
Default: FFFFFFFFFFF FFFFFFFFFFFFFFFFC
Example:Attempted Unsuccessfully: result used to generate location, TOA: 011FFFFFFFFFFFFFFFFFFFFFFFFC
Table 184 Positioning Method atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 226 (Approved) 30th March 2005
B5.2.144 Pre-Translated Called Party Number
This field captures the pre-translated called party number as shown in Table 186. The number generated by the translation process on the MSC is captured in the called number field (see B5.2.21). 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.145 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 187.
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 can’t 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 185 Values for Positioning Method and Usage
Field Used In: Module: GA.
Field Type Number of Characters Detailed Reference Number Type 2 B5.2.122 Numbering Plan Identifier 6 B5.2.123 BCD or Hex String (32) 32 B5.2.10
Table 186 Pre-translated called party number data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 227
B5.2.146 Priority Call Duration
This field contains the duration of a high priority call measured in tenths of a second as shown in Table 188. 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.147 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 189.
Field Used In: Record: Ack.
Character Description Values1-3 Priority call cause 000 - No error
001 - Mobile was powered off when receiving (power fail)002 - Call was interrupted due to radio link error004 - Spare008 - Spare016 - Call was left on a user command032 - Spare064 - Spare128 - Spare
4 Sign Character CDefault: 000C.Example:Priority call cause (no error): 000C
Table 187 Priority call cause atomic data field
Field Used In: Record: Ack.
Character Description Values1 Unused 02-9 Call duration in tenths of a second 00000000 - 1677721510 Sign Character CDefault: 000000000C.Example:Priority call duration: 001200600C
Table 188 Priority call duration atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 228 (Approved) 30th March 2005
B5.2.148 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 190.
B5.2.149 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 191. 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.
Field Used In: Record: Ack.
Character Description Values1 Initiator/receiver of original group call 0 - Spare
1 - Spare2 - Receiver3 - Initiator
2 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Priority call tag (Initiator): 3C
Table 189 Priority call tag atomic data field
Field Used In: Record: Ack.
Character Description Values1 Unused 02-3 Priority Level 07 - Priority Level A (highest)
06 - Priority Level B05 - Priority Level 004 - Priority Level 103 - Priority Level 202 - Priority Level 301 - Priority Level 4
4 Sign Character CDefault: 000C.Example:Priority level 0: 005C
Table 190 Priority level atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 229
B5.2.150 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 192.
B5.2.151 Privacy Override
This field contains an indicator which shows whether or not a subscriber’s 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 subscriber’s privacy may be overridden during an emergency call and for lawful intercept. The field encoding is shown in Table 193.
Field Used In: Record: Ack.
Character Description Values1 Unused 02-11 Time between call release and the acknowledgement call
in tenths of a second0000000000 - 4294967295
12 Sign Character CDefault: 00000000000C.Example:Priority release time: 00214755300C
Table 191 Priority release time atomic data field
Field Used In: Record: LCS.
Character Description Values
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 192 Privacy Notification atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 230 (Approved) 30th March 2005
B5.2.152 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 194.
B5.2.153 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 195.
(continued)
Field Used In: Record: LCS.
Character Description Values1 Condition 0 - Privacy Not Override
1 - Privacy Override 2 Sign Character CDefault: FCExample:Privacy Override: 1C
Table 193 Privacy Override atomic data field
Field Used In: Module: MNP.
Character Description Values1 Query Method Type 0 Unknown
1 IN Solution2 SRF Solution
2 Sign Character C Default: 0C. Example: 1C - IN solution
Table 194 Query method atomic data field
Field Used In: Module: DS.
Character Description Values1 Data Rate 0 - No rate adaptation
1 - V.1102 - X.313 - V.1204 - H.223 and H.2455 - PHS Internet Access Forum Standard (PIAFS)
2 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Rate Adaptation (V.110): 1C
Table 195 Rate adaptation atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 231
NOTE The data rate field (B5.2.43 on page 166) 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.154 Record Count
This field is defined as a value in the range 000000001 to 000065535. It is encoded as a 10 character BCD/hex string as defined in Section B5.2.10 on page 143.
B5.2.155 Record Header
This field is the first piece of information included in the structured record. It consists of four fields as shown in Table 196.
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 197, a Call Type Code may be associated with more than one Structure Code.
Field Used In: Switch/Billing File Record: BFTOR.
Field Used In: Records: All Call Detail Records. All Switch/Billing File Records.
Field Type Number of Characters Detailed ReferenceHexadecimal ID 2 B5.2.71Release Id 6 B5.2.161Structure Code 6 B5.2.186 Call Type Code 4 B5.2.19
Table 196 Record header data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 232 (Approved) 30th March 2005
B5.2.156 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 198.
B5.2.157 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.45 on page 167.
Structure Code Call Type Code Values Description Values Description
0001 Location Update 003 Location Update Call0002 Mobile Originated 001 Mobile Originated Call0003 Mobile Terminated 002 Mobile Terminated Call0004 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 Record0008 Transfer Out0009 Time Change 008 Time Change Record0010 Switch Restart 009 Switch Restart Record0011 Block Header 010 Block Header Record0013 Incoming Gateway 011 Incoming Trunk Call0014 Outgoing Gateway 012 Outgoing Trunk Call 0015 Incoming Intra-PLMN Trunk 011 Incoming Trunk Call0016 Outgoing Intra-PLMN Trunk 012 Outgoing Trunk Call 0017 Transit0018 Roaming 014 Roaming Call 0019 Common Equipment Usage 015 Common Equipment 0020 Acknowledgement 016 Acknowledgement0021 Location Services (LCS) 017 Location Services (LCS)
Table 197 Mapping of structure codes to call type codes
Field Used In: Records: All Call Detail Records. Switch/Billing File Records: TCR, SRR, BFTIR, BFTOR.
Character Description Values1-11 Record Number {00000000001....04,294,967,295}12 Sign Character CDefault: FFFFFFFFFFFCExample:Record Number: 00000000254C
Table 198 Record number atomic data field
Field Used In: Record: Ack.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 233
B5.2.158 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 fields as shown in Table 199.
B5.2.159 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 is shown in Table 200.
B5.2.160 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 201.
Field Used In: Record: LU.
Field Type Number of Characters Detailed ReferenceNumbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 199 Recording entity data field
Field Used In: Records: All Switch/Billing File Records.
Character Description Values1 Spare 02-7 Office Identity {000000....999999}8 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Recording Office Identity: 0123456C
Table 200 Recording office identity atomic data field
Field Used In: Records: All Switch/Billing File Records.
Character Description Values1-3 Recording Office Type / Sensor Type 001 - MSC4 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Recording Office Type / Sensor Type: 001C
Table 201 Recording office type atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 234 (Approved) 30th March 2005
B5.2.161 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.155 on page 231. The field encoding is shown in Table 202.
B5.2.162 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.45 on page 167.
B5.2.163 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 203.
Field Used In: Records: All Call Detail Records. All Switch/Billing File Records.
Character Description Values1 Unused 02-3 GSM/UMTS Release {00....99}4-5 Version 006 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.The Release Id shall be set to the following in the GSM/UMTS releases indicated:NSS release 18: 01800C
Table 202 Release id atomic data field
Field Used In: Records: MO, MT.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 235
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.164 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 204.
B5.2.165 Result Indicator
This field provides information about the outcome of invoking a supplementary service. The field encoding is shown in Table 205.
Field Used In: Record: LCS.
Character(s) Description Values1 Spare F2 Vertical Coordinates Request 1 3 Response Time Category 0 - Delay Tolerant
1 - Low Delay4-6 Horizontal Uncertainty 000 ... 1277 Horizontal Accuracy 1 - Horizontal Accuracy (Most Significant Bit)8-10 Vertical Uncertainty 000 ... 12711 Vertical Accuracy 1 - Vertical Accuracy (Most Significant Bit) 12 Sign Character CDefault: FFFFFFFFFFFCExample:Requested QoS: F1112311221C
Table 203 Requested QoS atomic data field
Field Used In: Record: LCS.
Field Type Number of Characters Detailed Reference
Numbering Plan Identifier 6 B5.2.123
BCD or Hex String (20) 20 B5.2.10
Table 204 Requesting MLC atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 236 (Approved) 30th March 2005
Field Used In: Record: SSA. Module: SS.
Character Description Values1 Spare 02-3 Result Indicator
General 00 - Unknown/No Value01 - Successful Outcome02 - Service Not Provided By Network04 - Wrong Procedure Used 05 - Insufficient Information06 - Conflict with Other Supplementary Services 09 - Destination Not part of CUG 10 - Subscriber Busy11 - No Answer 12 - Timer Expired13 - Network Congestion 14 - Network Resources Not Available15 - Call Cleared for Abnormal Reasons16 - Wrong Password 17 - Use of Password Not Allowed
Supplementary Service 18 - Not a Subscribed-to Supplementary Service 21 - SS Invoked by Subscriber22 - SS Invoked by Network 25 - Supplementary Service Control Procedure Not Correct
Number Identification 26 - Calling Number Identity Restriction27 - Calling Line Identity Presentation Overridden28 - Connected Number Identity Restriction29 - 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
4 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Result Indicator (No Answer): 011C
Table 205 Result indicator atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 237
B5.2.166 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 143.
NOTE Because the RNC is part of the UMTS radio access, the Access Network field (B5.2.2 on page 140) 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.167 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 206.
B5.2.168 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 subscriber’s 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 143.
Field Used In: Module: LaC
Field Used In: Record: Ro. Module: LaC.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 206 Roaming number data field
Field Used In: Module: MNP.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 238 (Approved) 30th March 2005
B5.2.169 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 143.
B5.2.170 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 encoding is shown in Table 207.
Field Used In: Record: SSA. Module: GASSP.
Field Used In: Module: IN.
Character Description Values1 Spare 02 Format Indicator 0 - Explicit
1 - Embedded3-33 SCF ID {0,1,2,3,4,5,6,7,8,9,0,A,B,C,D,E,F}34 Sign Character CDefault: FF0000000000000000000000000000000CExample:SCF ID / ETC Parm 1: 000000000000000000000000000099673C
Table 207 SCF ID / ETC Parm 1 atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 239
B5.2.171 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 143.
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 SCP’s address.
Field Used In: Modules: CSMS, GASSP, IN.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 240 (Approved) 30th March 2005
B5.2.172 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 is shown in Table 208.
NOTE The Sensor identity can be used to distinguish between different billing files from different MSCs.
B5.2.173 Served IMEI
This field captures the International Mobile Equipment Identity (IMEI) of the party associated with the location request. The format of the IMEI is specified in 3GPP TS 23.002. This field is captured when the location service (LCS) is initiated (mobile originated, mobile terminated and network initiated location request - MO-LR, MT-LR, NI-LR). It is encoded as a 16 character BCD or hex string field as shown in Section B5.2.10 on page 143. A valid IMEI is composed of digits and any used characters in the field are populated with Hex Fs.
B5.2.174 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 fields as shown in Table 209.
Field Used In: Records: All Switch/Billing File Records.
Character Description Values1 Record 0 - Original Record
1 - Rewritten Record2-7 Office Identity {000000....999999}8 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Sensor Identity: 0001234C
Table 208 Sensor identity atomic data field
Field Used In: Records: LCS.
Field Used In: Record: LU.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 209 Served IMSI data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 241
B5.2.175 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 210.
B5.2.176 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 143.
B5.2.177 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 211.
Field Used In: Record: LU.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 210 Served MSISDN data field
Field Used In: Record: LCS.
Field Used In: Records: SMSMO, SMSMT. Module: CSMS.
Field Type Number of Characters Detailed ReferenceNumbering Plan Identifier 6 B5.2.123BCD or Hex String (22) 22 B5.2.10
Table 211 Service centre data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 242 (Approved) 30th March 2005
B5.2.178 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 212.
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.
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.
(continued)
Field Used In: Modules: CSMS, IN.
Character Description Values 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 212 Service key atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 243
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.179 SMS Message Type
This field contains an indication of the type of SMS message. The field encoding is shown in Table 213.
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.
Character(s) Description Values1 SMS Type 0 - SMS SUBMIT
1 - SMS COMMAND2 Sign Character CDefault: FCExample: 1C
Table 213 SMS message type atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 244 (Approved) 30th March 2005
B5.2.180 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 214.
Field Used In: Module: CSMS.
Character(s) Description Values1 Spare 02-3 Unassigned (Unallocated) Number 01
Operator Determined Barring 02Call Barred 03Short Message Transfer Rejected 04Destination Out Of Service 05Unidentified Subscriber 06Facility Rejected 07Unknown Subscriber 08Reserved 09Network Out Of Order 10Temporary Failure 11Congestion 12Resources Unavailable, Unspecified 13Requested Facility Not Subscribed 14Requested Facility Not Implemented 15Invalid Short Message Transfer Reference Value 16Semantically Incorrect Message 17Mandatory Information Element Missing 18Message Type Non-existent or Not Implemented 19Message Not Compatible With Short Message Protocol State 20Information Element Non Existent or Not Implemented 21Protocol Error Unspecified 22Interworking Unspecified 23
4 Sign Character CDefault: FFFCExample: SMS Release Cause Value: (Short Message Transfer Rejected) F05C
Table 214 SMS release cause value atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 245
B5.2.181 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.51 on page 173.
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.182 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.45 on page 167.
B5.2.183 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.45 on page 167.
Field Used In: Records: SMSMO, SMSMT.
Field Used In: Module: CSMS.
Field Used In: Module: CSMS.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 246 (Approved) 30th March 2005
B5.2.184 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.45 on page 167.
B5.2.185 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.179 on page 243). The field is encoded as shown in Table 215.
B5.2.186 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.155 on page 231. The field encoding is shown in Table 216.
Field Used In: Records: SMSMO, SMSMT.
Field Used In: Record: SMSMO.
Character(s) Description Values1 Spare 02 - 3 SMS Validity Period Format 01 - TP-Validity-Period-Not-Present
02 - TP-Validity-Enhanced-Format03 - TP-Validity-Relative-Format04 - 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 CDefault: 0FFFFFFFFFFFFFFFFCExample: 002FFFFFFFFFFFF13C
Table 215 SMS validity period atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 247
B5.2.187 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 217.
Field Used In: Records: All Call Detail Records. All Switch/Billing File Records.
Character Description Values1 Module Indicator 0 - Record Contains No Modules
1 - Record Contains Modules2-5 Structure Code 0001 - Location Update
0002 - Mobile Originated0003 - Mobile Terminated0004 - SMS Mobile Originated0005 - SMS Mobile Terminated 0006 - Supplementary Service Action 0007 - Transfer In0008 - Transfer Out0009 - Time Change0010 - Switch Restart0011 - Block Header0013 - Incoming Gateway0014 - Outgoing Gateway0015 - Incoming Intra-PLMN Trunk0016 - Outgoing Intra-PLMN Trunk0017 - Transit0018 - Roaming0019 - Common Equipment Usage0020 - Acknowledgement of High Priority Call0021 - Location Services (LCS)
6 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Structure Code (No Modules, Outgoing Gateway): 00014C
Table 216 Structure code atomic data field
Field Used In: Records: All Call Detail Records.
Character Description Values1 Study Indicator 0 - Normal Record
1 - Study Generated Record2 Sign Character CDefault: 0CExample:Study Indicator (Normal Record): 0C
Table 217 Study indicator atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 248 (Approved) 30th March 2005
B5.2.188 Subscriber Service
This field captures details of the service provided to the subscriber. The field encoding is shown in Table 218.
Field Used In: Module: TC.
Character Description Values1-5 Subscriber Service 00000 - Mobile Terminated Telephony
00001 - Mobile Originated Telephony00002 - Mobile Terminated Fax Group 300003 - Mobile Originated Fax Group 300004 - Mobile Terminated Alternate Speech/Fax.00005 - Mobile Originated Alternate Speech/Fax.00006 - Mobile Terminated CDA 3.1kHz00007 - Mobile Originated CDA 3.1kHz00008 - 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.1kHz00013 - Mobile Originated CDS 3.1kHz00014 - Mobile Terminated CDS UDI00015 - Mobile Originated CDS UDI00016 - 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 CDefault: Not applicable. When captured only valid values shall be recorded.Example:Subscriber Service (Mobile Terminated Telephony): 00000C
Table 218 Subscriber service atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 249
B5.2.189 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 219.
B5.2.190 Supplementary Service Code
This field captures a code which shows the supplementary service invoked by the subscriber. The field encoding is shown in Table 220.
Field Used In: Record: SSA. Module: SS.
Character Description Values1 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 CDefault: FC.Example:Supplementary Service Action (Invoke): 5C
Table 219 Supplementary service action data field
Field Used In: Record: SSA. Modules: SS, AoC.
Character Description Values1 Spare 02 SS Group 1 - Number Identification Services
2 - Forwarding Services3 - Explicit Call Transfer 4 - Call Completion Services 5 - Multiparty Services6 -Community of Interest Services7 - Charging Services8 - Additional Information Transfer Services 9 - Call Restriction ServicesA - GSM Railways Services B - National Specific Services F - Nortel proprietary supplementary service
Option3 Character 2 = 1 SS Type 1 - Calling Number Identity Presentation
2 - Calling Number Identity Restriction3 - Connected Line Identity Presentation4 - Connected Line Identity RestrictionF - Calling Name Delivery (CNAM) (continued)
Table 220 Supplementary service code atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 250 (Approved) 30th March 2005
(continued)
or3 Character 2 = 2 SS Type 0 - All Forwarding SS
1 - Call Forwarding Unconditional 5 - Call Forwarding in Gateway (Unknown) 8 - Call Forwarding All Conditional9 - 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 or3 Character 2 = 4 SS Type 1 - Call Waiting
2 - Call Hold4 - Proprietary Voice Mail Call Dropback5 - Call Reorigination6 - Call Reorigination By Cause 9 - Proprietary Release Link Trunk Service
or3 Character 2 = 5 SS Type 1 - Multiparty Servicesor3 Character 2 = 6 SS Type 1 - Closed user Groups (CUG) Service
8 - Account Code Service 9 - Proprietary Customer Information
or3 Character 2 = 7 SS Type 1 - Advice of Charge Information
2 - Advice of Charge Chargingor3 Character 2 = 8 SS Type 1 - Unstructured Supplementary Service Data (USSD) or3 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 Serviceor 3 Character 2 = B SS Type 0 - Directory Assistance Service Call or 3 Character 2 = F SS Type 7 - Anonymous Call Rejection
9 - Extension ServiceA - Malicious Call Trace (MCT) B - Optimal Routing (of Late Call Forwarding)
or 1-3 254 - Hot billing service (see note)4 Sign Character CDefault: 000CExample:Supplementary Service Code (Advice of Charge Information): 071C
Table 220 Supplementary service code atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 251
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.
B5.2.191 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 101. 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 143.
B5.2.192 System Type
This field indicates the type of wireless system on which a Location Service (LCS) was initiated. The field encoding is shown in Table 221.
B5.2.193 Switch Restart Type
This field identifies the type of switch restart. The field encoding is shown in Table 222.
Field Used In: Record: SSA. Module: SS.
Field Used In: Record: LCS.
Character Description Values1 System Type 1 - UTRAN
0 - GERAN2 Sign Character CDefault: FCExample:UTRAN: 1C
Table 221 System Type atomic data field
Field Used In: Switch/Billing File Record: SRR.
Character Description Values1 Switch Restart Type 0 - Warm Restart
1 - Cold Restart 2 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Switch Restart Type (Warm Restart): 0C
Table 222 Switch restart type atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 252 (Approved) 30th March 2005
B5.2.194 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 327. The tariff class consists of a single field as shown in Table 223.
B5.2.195 Teleservice
This field captures details of the teleservice used by the subscriber for the call. The field encoding is shown in Table 224.
Field Used In: Module: TC.
Character Description Values1-5 Tariff Class 00000....010236 Sign Character CDefault: FFFFFCExample:Tariff Class: 00104C
Table 223 Tariff class atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 253
NOTE Teleservice codes are defined in accordance with 3GPP TS 29.002.
Field Used In: Module: TS.
Character Description Values1 Spare 02 TS Group 0 - All Teleservices
1 - Basic2 - Short Message Service6 - Facsimile7 - Data Teleservices 8 - Teleservices Except SMS 9 - Voice Group Call Services D - Proprietary service group
Option3 Character 2 = 0 TS Type 0 - All Teleservice Codes or3 Character 2 = 1 TS Type 0 - All Speech Transmission Services
1 - Telephony2 - Emergency Calls
or3 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 33 - 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
or3 Character 2 = D TS Type 0 - Auxiliary Speech
1 - Auxiliary Telephony 4 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Teleservice (Basic Telephony): 011CTeleservice (Auxiliary Telephony): 0D1C
Table 224 Teleservice atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 254 (Approved) 30th March 2005
B5.2.196 Terminating Location
This field captures details of the location of the terminating party on the call. The field encoding is shown in Table 225.
B5.2.197 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 226.
B5.2.198 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 227.
Field Used In: Module: OA.
Character Description Values1-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 - South8-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 - West16 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Terminating Location: 213432101123454C
Table 225 Terminating location atomic data field
Field Used In: Module: TU.
Character Description Values1-3 Trunk Usage Reason 000 - Handover
001 - Call Monitoring4 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Trunk usage reason - 000C
Table 226 Trunk usage reason atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 255
B5.2.199 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 228.
B5.2.200 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 229.
Field Used In: Module: EA.
Character Description Values1 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 CDefault: FCExample:Type of Carrier Identification Code: 6C
Table 227 Type of carrier identification code atomic data field
Field Used In: Module: PaI.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (32) 32 B5.2.10
Table 228 Unused Number 1 data field
Field Used In: Module: PaI.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Identifier 6 B5.2.123BCD or Hex String (32) 32 B5.2.10
Table 229 Unused Number 2 data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 256 (Approved) 30th March 2005
B5.2.201 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 field atomic field as described in Section B5.2.45 on page 167.
B5.2.202 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 field atomic field as described in Section B5.2.45 on page 167.
B5.2.203 Update Result
This field captures the result of a mobility management service failure. The field encoding is shown in Table 230.
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 93) is not generated.
Field Used In: Module: PaI.
Field Used In: Module: PaI.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 257
B5.2.204 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.45 on page 167.
Field Used In: Record: LU.
Character Description Values1-3 User Error 000 - Unauthorized Requesting Network
001 - Unauthorized Privacy Class002 - Unauthorized Call Unrelated External Client003 - Unauthorized Call Related External Client004 - Privacy Override Not Applicable005 - Congestion006 - Insufficient Resources007 - Insufficient Measurement Data008 - Inconsistent Measurement Data009 - Location Procedure Not Completed010 - QoS Not Attainable011 - Position Method Not Available In Network012 - Position Method Not Available In Location Area013- Unknown or Unreachable LCS Client
Provider Error 100 - Duplicated Invoke Id101 - Not Supported Service102 - Mistyped Parameter103 - Resource Limitation104 - Initiating Release105 - Unexpected Response From The Peer106 - Service Completion Failure107 - No Response From The Peer108 - Invalid Response Received
4 Sign Character CDefault: FFFCExample:Update Result (Insufficient resources - User) - 006C
Table 230 Update result atomic data field
Field Used In: Record: LU.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 258 (Approved) 30th March 2005
B5.3 PCS 1900 Fields
These fields are only generated by the PCS modules described in Section B4.3. Table 231 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-TerminatorTF 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 232.
Data Field Size Type Ref. PCS 1900 ModulesAutomatic Number Identification indicator 2 Atomic B5.3.1 O-TCalled Party Off-Hook Indicator 2 Atomic B5.3.2 TFCharge Number/Automatic Number Identification (ANI)Number Type (2)Numbering Plan Identifier (6)BCD/Hex String (32)
40 Compound B5.3.3 O-T
Generic Address Parameter 30 Atomic B5.3.4 O-TInter-exchange/International Carrier (IC/INC) Routing Indicator 2 Atomic B5.3.5 TFLATA BCD/Hex String (4) 4 Atomic B5.3.6 TFLocation 16 Atomic B5.3.7 LNPLocation Routing Number (LRN) 12 Atomic B5.3.8 LNPModule Code 4 Atomic B5.3.9 O-T, TF, LNPOriginating Line Information/II Parameter 4 Atomic B5.3.10 O-TOriginating Numbering Plan Area (and Area Code) 8 Atomic B5.3.11 O-TOverseas Indicator 4 Atomic B5.3.12 TFParty Identifier 4 Atomic B5.3.13 LNPSCP Determined Terminated Number BCD/Hex String (20) 20 Atomic B5.3.14 TFService Feature Code 4 Atomic B5.3.15 TFService Provider Identity 10 Atomic B5.3.16 LNPSupporting Information 8 Atomic B5.3.17 LNPTerminating Numbering Plan Area 4 Atomic B5.3.18 O-TToll Free Call Type Code 4 Atomic B5.3.19 TF
Table 231 PCS 1900 market-specific data fields
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 259
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 party’s 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 consists of a single field as shown in Table 233.
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.
Character Description Values1 ANI Indicator 0 - No ANI or Calling number provided
1 - ANI provided, no Calling number 2 - Calling number provided, No ANI3 - Both Calling number and ANI provided
2 Sign Character CDefault: FCExample:Automatic number identification indicator - 2C
Table 232 Automatic number identification indicator atomic data field
Field Used In: Information Module: Toll Free.
Character Description Values1 Called Party Off-Hook Indicator 0 - terminating party has gone off-hook
1 - terminating party off-hook not detected2 - an answer attempt (operator or collect call)3 - simulated called party off-hook detected9 - unknown
2 Sign CDefault: 1CExample:Called Party Off-Hook Indicator: 0C
Table 233 Called party off-hook indicator atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 260 (Approved) 30th March 2005
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 234.
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 235.
Field Used In: Information Module: Originator-Terminator.
Field Type Number of Characters Detailed ReferenceNumber Type 2 B5.2.122Numbering Plan Indicator 6 B5.2.123BCD or Hex String (32) 32 B5.2.10
Table 234 Charge number/ANI data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 261
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 236.
Field Used In: Information Module: Originator-Terminator.
Character Description Values1-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 number9-10 Numbering Plan Indicator 00 - Unknown
01 - ISDN/Telephone numbering plan11 Presentation Restriction
Indicator0 - 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 CDefault: 25508100003FFFFFFFFFFFFFFFFFFCExample:Generic Address Parameter: 00018002011500239345FFFFFFFFFC
Table 235 Generic address parameter atomic data field
Field Used In: Information Module: Toll Free.
Character Description Values1 IC/INC Routing Indicator 0 - call routed directly
1 - call routed to AT2 Sign CDefault: FCExample: IC/INC Routing Indicator: 1C
Table 236 IC/INC routing indicator atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 262 (Approved) 30th March 2005
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 143.
B5.3.7 Location
This captures the location of a party’s switch when that party (called or calling) uses the local number portability (LNP) service. It consists of a single field as shown in Table 237.
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 238.
Field Used In: Information Module: Toll Free.
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 237 Location data atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 263
B5.3.9 Module Code (PCS 1900 Market-Specific)
This field contains a code value which identifies the information module containing the field. It consists of a single field as shown in Table 239.
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 240.
(continued)
Field Used In: Information Module: Local Number Portability.
Character Description Values 1 Spare 0 2-11 Location Routing Number
(NPA-NXX XXXX) {0000000000....9999999999}
12 Sign Character C Default: FFFFFFFFFFFC Example: Location Routing Number: 02146841111C
Table 238 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 Information021 - Local Number Portability (LNP) Information
4 Sign Character CDefault: Not applicableExample:Module Code (Toll Free Information): 014C
Table 239 Module code atomic data field
Field Used In: Information Module: Originator-Terminator.
Character Description Values1-3 Type of Calling line See Note 4 Sign Character CDefault: FFFCExample:Originating line information: 010C
Table 240 Originating line information parameter atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 264 (Approved) 30th March 2005
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 consists of a single field as shown in Table 241.
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 242.
Field Used In: Information Module: Originator-Terminator.
Character Description Values1 Spare 02-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 CDefault: FFFFFFFCExample:Originating numbering plan area: 0214684C
Table 241 Originating numbering plan area atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 265
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 243.
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 143.
Field Used In: Information Module: Toll Free.
Character Description Values1-3 Overseas indicator 000 - not an overseas call (NPA dialled)
001 - not an overseas call (NPA not dialled) determined by network002 - Not an overseas call (non-NANP terminating number)003 - 7 digit overseas number004 - 8 digit overseas number005 - 9 digit overseas number006 - 10 digit overseas number007 - 11 digit overseas number008 - 12 digit or more overseas number009 - operator special dialled code is in the called number field
4 Sign CDefault: FFFCExample:Overseas Indicator: 003C
Table 242 Overseas indicator atomic data field
Field Used In: Information Module: Local Number Portability.
Character Description Values 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 243 Party identifier atomic data field
Field Used In: Information Module: Toll Free.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 266 (Approved) 30th March 2005
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 244.
NOTE The MSC does not edit or screen this value. It simply copies the value received inthe 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 single field as shown in Table 245.
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 single field as shown in Table 246.
Field Used In: Information Module: Toll Free.
Character Description Values1-3 Service Feature Code 000-9994 Sign Character CDefault: FFFCExample:Service Feature Code: 001C
Table 244 Service feature code atomic data field
Field Used In: Information Module: Local Number Portability.
Character Description Values 1 Spare 0 2-9 Service Provider Identity {00000000 - 99999999} 10 Sign Character C Default: FFFFFFFFFC. Example:
Table 245 Service provider identity atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 267
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 247.
Field Used In: Information Module: Local Number Portability.
Character Description Values 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 5 Reserved for Future Use 0 6 Reserved for Future Use 0 7 Reserved for Future Use 0 8 Sign Character C Default: FFFFFFFC Example:Supporting Information (LNP database, with no query failure): 1010000C
Table 246 Supporting information atomic data field
Field Used In: Information Module: Originator-Terminator.
Character Description Values1-3 BCD or Hex String (3) Numbering plan area code 4 Sign Character CDefault: FFFCExample:Terminating numbering plan area: 214C
Table 247 Terminating numbering plan area atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 268 (Approved) 30th March 2005
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 248.
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 249.
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 encoding is shown in Table 250.
Field Used In: Information Module: Toll Free.
Character Description Values1-3 Toll Free Call Type Code 141 - Call is routed to IXC
142 - Call is routed to LEC4 Sign Character CDefault: Not applicable. When captured only valid values shall be recorded.Example:Toll free call type code: 142C = call routed to LEC
Table 248 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 249 Singapore market-specific data fields
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 269
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 encoding is shown in Table 251.
B5.4.3 Module Code
The MSC module code for the Singapore Specific Information Module is 017C.
Character Description Values 1 Unused 0 2-3 Calling Party Category 00 - Calling Party’s 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 Party’s Category (Ordinary): 00AC
Table 250 Calling party category atomic data field
Character Description Values 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 251 City wide centrex atomic data field
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 270 (Approved) 30th March 2005
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 252.
B5.4.5 Other Subscriber CUSTGRP
This field provides other agent’s customer user group information, if available. It is only available on mobile to mobile calls. The field encoding is shown in Table 253.
B5.4.6 Other Subscriber NCOS
This field provides the other agent’s class of service information, if available. It is only available on mobile to mobile calls. The field encoding is shown in Table 254.
Character Description Values1 Spare 02-3 National/International Indicator 00 - National call
01 - International call4 Sign Character CDefault: FFFCExample:National/International Indicator Code (International Call): 001C
Table 252 National / international indicator atomic data field
Character Description Values1-5 Customer Group 00000-040956 Sign Character CDefault: 00000CExample:CUSTGRP: 01234C
Table 253 Other subscriber CUSTGRP atomic data field
Character Description Values1-5 Network Class of Service 00000 - 0002556 Sign Character CDefault: 00000CExample:NCOS: 00255C
Table 254 Other subscriber NCOS atomic data field
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 271
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 255.
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 256.
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 257 to 260.
Character Description Values1 spare 02-3 XCLI Code 00 - Presentation allowed
01 - Presentation restricted02 - Address not available03 - Spare
4 Sign Character CDefault: FFFCExample:XCLI Indicator Code: 001C
Table 255 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 256 German and Austrian market-specific data fields
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 272 (Approved) 30th March 2005
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.
Character Description Values 1 Unused F 2-3 CIC 10 - 99 4 Sign Character C Default: FFFC Example: Carrier Identification Code: F24C
Table 257 Default CIC - 2-digit German Market CIC
Character Description Values 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 258 Default CIC - 3-digit German Market CIC
Character Description Values 1 Unused F 2-3 CIC 11 - 99 4 Sign Character C Default: FFFC Example: Carrier Identification Code: F24C
Table 259 Default CIC - 2-digit Austrian market CIC
Character Description Values 1-3 CIC 601 - 999 4 Sign Character C Default: FFFC Example: Carrier Identification Code: 689C
Table 260 Default CIC - 3-digit Austrian market CIC
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 273
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 261 to 264.
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.
Character Description Values 1 Unused F 2-3 CIC 10 - 99 4 Sign Character C Default: FFFC Example: Carrier Identification Code: F24C
Table 261 Selected CIC - 2-digit CIC Character Description Values
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: 037C
Table 262 Selected CIC - 3-digit CIC
Character Description Values1 Unused F 2-3 CIC 11 - 99 4 Sign Character C Default: FFFC Example: Carrier Identification Code: F24C
Table 263 Selected CIC - 2-digit Austrian market CIC Character Description Values
1-3 CIC 601 - 999 4 Sign Character C Default: FFFC Example: Carrier Identification Code: 689C
Table 264 Selected CIC - 3-digit Austrian market CIC
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 274 (Approved) 30th March 2005
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 265.
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.
Character Description Values 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 265 Subscriber Customer Group
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 275
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.
The following examples are included:
• B6.1, ‘Mobile to Land (Outgoing) Call’ on page 276• B6.2, ‘Partial Billing in a Mobile to Land (Outgoing) Call’ on page 277• B6.3, ‘Land to Mobile (Incoming) Call’ on page 278• B6.4, ‘Mobile to Mobile Call Within the Same Network’ on page 278• B6.5, ‘Calls Involving Roaming Mobile Subscribers’ on page 280• B6.6, ‘Incoming Call to a PLMN Service Center’ on page 282• B6.7, ‘Call Forwarding’ on page 283• B6.8, ‘Delivery and Origination of Short Messages’ on page 285• B6.9, ‘Call Hold and Multi-party Services’ on page 287• B6.10, ‘Explicit Call Transfer Service’ on page 288 • B6.11, ‘Redirection and Call Dropback Services’ on page 290 • B6.12, ‘Handover’ on page 294• B6.13, ‘Local Number Portability’ on page 296 • B6.14, ‘Extension Services’ on page 298 • B6.15, ‘Intelligent Network (IN) Scenarios’ on page 299• B6.16, ‘CAMEL Mobility Management Service’ on page 307 • B6.17, ‘Call Independent Supplementary Service Action’ on page 307 • B6.18, ‘Invoking the Billing Zone Query Service Using USSD’ on page 308 • B6.19, ‘Optimal Routing of a Late Forwarded Call’ on page 309 • B6.20, ‘Mobile Number Portability (MNP)’ on page 311 • B6.21, ‘Location Services (LCS)’ on page 314 • B6.22, ‘GSM-R Call Scenarios’ on page 316• B6.23, ‘Market-Specific Call Scenarios’ on page 322
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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 276 (Approved) 30th March 2005
B6.1 Mobile to Land (Outgoing) Call
Figure 11 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 11 Mobile to land (outgoing) call
If the mobile station is served directly by the gateway MSC, the scenario shown in Figure 11 is simplified. In this case, the gateway MSC produces a MOC record and an OG record.
GatewayMSC
MSC
HLR
ISDN/PSTN
HPLMN
RecordICIP
OGRecord
RecordOGIP
MOCRecord
L&CTS
EoM
Key ICIP Incoming Intra-PLMN Trunk RecordMOC Mobile Originated Call Attempt RecordOG Outgoing GatewayOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleTS Teleservice Information Module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 277
B6.2 Partial Billing in a Mobile to Land (Outgoing) Call
Figure 12 depicts the same call scenario shown Section B6.1 Figure 11, 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 call’s 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 call’s 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 60.
GatewayMSC
MSC
HLR
ISDN/PSTN
HPLMN
RecordOGIP
MOCRecord
L&CTS
EoM
Key ICIP Incoming Intra-PLMN Trunk RecordMOC Mobile Originated Call Attempt RecordOG Outgoing GatewayOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModulePart Partial Information ModuleTS Teleservice Information Module
(part 1)
Part
MOCRecord
L&CTS
EoM
(final)
Part
EoMPart
(part 1)RecordOGIP
EoMPart
(final)
RecordICIP
EoMPart
(part 1)RecordICIP
EoMPart
(final)
RecordOG
EoMPart
(part 1)RecordOG
EoMPart
(final)
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 278 (Approved) 30th March 2005
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.
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.
GatewayMSC
MSC
HLR
ISDN/PSTN
HPLMN
IGRecord
RecordOGIP
RecordICIP
MTCRecord
SRI
RecordRoaming
TSEoM
L&CTS
EoM
Key ICIP Incoming Intra-PLMN Trunk RecordIG Incoming Gateway Record MTC Mobile Terminated Call Attempt RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleTS Teleservice Information Module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 279
In Figure 14, 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 subscriber’s 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.
Figure 14 Mobile to mobile call with both mobiles at the same MSC
Figure 15 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 subscriber’s 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.
MOCRecord
SRIMSC
HLR
L&CTS
EoM
MTCRecord
L&CTS
EoM
Key MOC Mobile Originated Call Attempt RecordMTC Mobile Terminated Call Attempt RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleTS Teleservice Information Module
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 280 (Approved) 30th March 2005
Figure 15 Mobile to mobile call with the subscribers on different MSCs
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 14 and 15. In these scenarios, the HPLMN is the called party’s. The information which shows that the calling party is roaming is captured in the MOC record. This record contains the calling party’s IMSI, part of which is the mobile network code (MNC) of the subscriber’s home network. The roaming record shown in Figure 15 captures information for the called party and results from the interrogation of the HLR.
MSC MSC
HLR
HPLMN
RecordICIPOGIP
Record
OGIPRecord
RoamingRecord
ICIPRecord
MTCRecord
SRI
GatewayMSC
MOCRecord
L&CTS
EoMTS
EoM
L&CTS
EoM
Key ICIP Incoming Intra-PLMN Trunk RecordMOC Mobile Originated Call Attempt Record MTC Mobile Terminated Call Attempt RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleTS Teleservice Information Module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 281
B6.5.2 Incoming Call to a Roaming Subscriber
Figure 16 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 subscriber’s 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 16 Incoming call to a roaming subscriber
As a variation on the scenario shown in Figure 16, 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 16 routes the call to the roaming party’s 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 16 as the roaming party’s HPLMN provides information on the mobile’s 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.
GatewayMSC
HLR
HPLMN
GatewayMSC
MSC
VPLMN
RoamingRecord
MTCRecord
IGRecord
OGRecord Record
OGIP
RecordICIP
SRI
ISDN/PSTN
IGRecord
L&CTS
EoMTS
EoM
Key ICIP Incoming Intra-PLMN Trunk RecordIG Incoming GatewayMTC Mobile Terminated Call Attempt RecordOG Outgoing Gateway RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleTS Teleservice Information Module
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 282 (Approved) 30th March 2005
B6.6 Incoming Call to a PLMN Service Center
Figure 17 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.
Figure 17 Incoming call to a PLMN service centre
GatewayMSC
MSC
ISDN/PSTN
HPLMN
Service Center
IGRecord
OGIPRecord
ICIPRecord Transit
Record
Key ICIP Incoming Intra-PLMN Trunk RecordIG Incoming GatewayOGIP Outgoing Intra-PLMN Trunk Record
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 283
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 18 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.
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 18, 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 party’s number.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 284 (Approved) 30th March 2005
Figure 18 Call forwarding
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.
GatewayMSC
MSC
HLR
ISDN/PSTN
HPLMN
IGRecord
MTCForwardingRecord
MOCForwardingRecord
OGRecord
SRI
TSSS
EoM
TSSS
EoM
Key IG Incoming Gateway RecordMOC Mobile Originated Call Attempt RecordMTC Mobile Terminated Call Attempt RecordOG Outgoing Gateway RecordEoM End of Module List ModuleSS Supplementary Service Information ModuleTS Teleservice Information Module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 285
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. When a call is forwarded NDUB, an MSRN allocated and a page request is sent to the VLR. However, the VLR determines the mobile is busy and does not actually perform the page. As a result, the mobile’s location is not known. The location and channel information module appended to the forwarding record captures the MSRN, but all other location information is defaulted to all Fs.
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 19 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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 286 (Approved) 30th March 2005
Figure 19 Delivery of short message to a mobile subscriber
B6.8.2 Origination of a Short Message
Figure 20 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.
Figure 20 Origination of a short message
MSC
HPLMNSMS-SC HLR
MTSMSRecord
LO
Key MT SMS Mobile Terminated Short Message Service RecordEoM End of Module List ModuleLO Location Only Information ModuleEoM
MSCHPLMN
SMS-SC
MOSMSRecord
LOEoM
Key MO SMS Mobile Originated Short Message Service RecordEoM End of Module List ModuleLO Location Only Information Module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 287
B6.9 Call Hold and Multi-party Services
Figure 21 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 C’s 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 A’s records to indicate the invocation of the multi-party service. Subscriber A’s 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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 288 (Approved) 30th March 2005
Figure 21 Call hold and multi-party services
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 22 shows an example scenario.
GatewayMSC
MSC
ISDN/PSTN
MSC
HPLMN
MOCRecord(A to
A C
PSTN)
MTCRecord
OGIPRecord(A toPSTN)
OGRecord
ICIPRecord(A toPSTN)
OGIPRecord (A to C)
ICIPRecord(A to C)
(A to C)
(A toPSTN)
CEURecord
MOCRecord
HLR
RoamingRecord
(A to C)
(A to C)
Key CEU Common Equipment Usage RecordICIP Incoming Intra-PLMN Trunk RecordMOC Mobile Originated Call Attempt RecordMTC Mobile Terminated Call Attempt RecordOG Outgoing Gateway RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleSS Supplementary Service Information ModuleTS Teleservice Information Module
L&CTS
EoMSS
L&CTS
EoMSS
TS
TS
L&CTS
EoMEoM
EoM
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 289
Figure 22 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.
GatewayMSC
MSC
ISDN/PSTN
MSC
HPLMN
MTCRecord(PSTN
A C
to A)MTCRecord
ICIPRecord(PSTNto A)
IGRecord
OGIPRecord(PSTNto A)
OGIPRecord(A to C) (A to C)
(PSTNto A)
MOCRecord
HLR
RoamingRecord
(A to C) (A to C)
ICIP
B RoamingRecord(PSTN to A)
Key ICIP Incoming Intra-PLMN Trunk RecordIG Incoming Gateway RecordMOC Mobile Originated Call Attempt RecordMTC Mobile Terminated Call Attempt RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleSS Supplementary Service Information ModuleTS Teleservice Information Module
L&CTS
EoM
SSSS
Record(A to C)
L&CTS
EoMSS
L&CTSEoM TS
EoM
TSEoM
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 290 (Approved) 30th March 2005
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 22.
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 23 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 291
Figure 23 Voice mail call dropback
Figure 23 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 23, 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.
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.
MSC VMS
MOCRecordA
B
MTCRecord(new call)
(call toVMS)
TransitRecord(call toVMS)
ICIPRecord(newcall)
Key ICIP Incoming Intra-PLMN Trunk RecordMOC Mobile Originated Call Attempt RecordMTC Mobile Terminated Call Attempt RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleSS Supplementary Service Information ModuleTS Teleservice Information Module
L&CTS
EoMSS
EoM
SSEoM
L&CTS
EoM
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 292 (Approved) 30th March 2005
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 party’s 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 23. 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 23 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.
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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 293
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 party’s 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 23. 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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 294 (Approved) 30th March 2005
B6.12 Handover
Figure 24 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 295
Figure 24 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.
GatewayMSC
ISDN/PSTN
MSC
A A - new MSC’s area
ICIPRecord
IGRecord OGIP
Record
MSC
OGIPRecord
HPLMN
Anchor MSC
ICIPRecord
MTCRecord
L&CTS
EoM
L&CL&C
TUEoM
L&CEoM
Key ICIP Incoming Intra-PLMN Trunk RecordIG Incoming Gateway RecordMTC Mobile Terminated Call Attempt RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleTS Teleservice Information ModuleTU Trunk Usage Information Module
TU
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 296 (Approved) 30th March 2005
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 25 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 25 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 25. 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.
GatewayMSC
ISDN/PSTN
IGRecord
HPLMNLocal LNPdatabase
HLR
OGGatewayRecord
Key IG Incoming Gateway RecordOG Outgoing Gateway RecordEoM End of Module List ModuleLNP Local Number Portability Information Module
LNPEoM
ISDN/PSTN
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 297
Figure 26 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 26 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.
GatewayMSC
ISDN/PSTN
IGRecord
HPLMN
Local LNPdatabase HLR
MTCRecord
Key IG Incoming Gateway RecordMTC Mobile Terminated Call Attempt RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleLNP Local Number Portability Information ModuleTS Teleservice Information Module
LNPEoM
L&C
EoMTS
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 298 (Approved) 30th March 2005
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 27, 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 299
Figure 27 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.
GatewayMSC
ISDN/PSTN
MTCRecord
TransitRecord
HPLMNVMS
MTCRecord
IGRecord
OGRecord
MOCRecord
MOCRecord
MOCRecord
MOCRecord
OGRecord
HLR call1 call 2 call3
Key IG Incoming Gateway RecordMOC Mobile Originated Call Attempt RecordMTC Mobile Terminated Call Attempt RecordOG Outgoing Gateway RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleSS Supplementary Service Information Module TS Teleservice Information Module
EoMSS
EoMSS
EoMSS
EoMSS
EoMSS
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 300 (Approved) 30th March 2005
B6.15.1 IN Nodes and Signalling
The IN introduces new nodes and signalling interfaces into the network. Figure 28 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 28 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 networkCAMEL network
MAPIP
gsmSSF
gsmSRF
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 301
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 29 where they are denoted by the term “(IN Service)”.
Figure 29 Billing for a mobile originated IN service
MSC/SSP
MOCRecord
gsmSCF
OGIntra-PLMNRecord
Call routed through the PLMN to the called party
(INservice)
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 302 (Approved) 30th March 2005
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 115). 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 120). 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 115), the MOC record may have an appended IN Charging Information module (Section B4.2.15 on page 118). 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 30 indicates that IN modules are appended to the call record.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 303
Figure 30 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 115) 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 120), 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
GatewayMSC/SSP
ICGatewayRecord
gsmSCF
Incoming callsetup information
MTCRecord(IN service)
VisitedMSC/SSP
MTCRecord(IN service)
ICIntra-PLMNRecord
RoamingRecord
MOCRecord (IN Service)
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 304 (Approved) 30th March 2005
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 115) 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 118) 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 31 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 305
Figure 31 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 115) and a GSM Call Reference module (Section B4.2.17 on page 120). 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
GatewayMSC/SSP
ICGatewayRecord
OGIntra-PLMNRecord
Incoming callsetup information
MOCRecord
MTCRecord
Call routed to the forwarded-to party
(IN service)
(IN service)
gsmSCF
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 306 (Approved) 30th March 2005
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 115) attached to the MOC record. However, it may also include appended GSM IN Charging Information modules (Section B4.2.15 on page 118) 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 32.
Figure 32 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
MAPISUP
MSC
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 307
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 33 shows an example scenario.
Figure 33 CAMEL mobility management service
The mobile station (MS) starts the location update procedure. After the MS is authenticated, the HLR downloads the subscriber’s 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 34 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)
LURecord
INEoM
SCP
Key LU Location Update Record EoM End of Module List ModuleIN Intelligent Network Information
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 308 (Approved) 30th March 2005
Figure 34 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 subscriber’s 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 subscriber’s 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 35 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 subscriber’s 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 35 Invoking the billing zone query service using USSD
MSC
SSAActionRecord
HLR
MSC
SSAActionRecord
HLR
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 309
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 station’s 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 36 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 GMSC’s 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 GMSC’s 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.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 310 (Approved) 30th March 2005
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 GMSC’s 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 36. 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 GMSC’s 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 311
Figure 36 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 37 shows an example MNP call scenario in which the MSC routes a call to a ported number.
VPLMN
HLR
MTCRecord
ISDN/PSTN
HPLMN
GatewayMSC
(GMSC)
VisitedMSC
(VMSC)
IGRecord
OGRecord
RoamingRecord
OGRecord
MOCRecord
Busy
ICIPRecord
TSEoM
Key ICIP Incoming Intra-PLMN Trunk RecordIG Incoming Gateway Record MOC Mobile Originated Call Attempt Record MTC Mobile Terminated Call Attempt Record OG Outgoing GatewayEoM End of Module List ModuleGCR GSM Call Reference Information ModuleL&C Location and Channel Information ModuleSS Supplementary Services Information ModuleTS Teleservice Information Module
GCRL&CTS
SS (CFB)EoM
MTCRecord
GCRTS
SS (OR)EoM
GCRTS
SS (OR)EoM
2
13
4
5
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 312 (Approved) 30th March 2005
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 37 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
GatewayMSC
(GMSC)
Key ICIP Incoming Intra-PLMN Trunk RecordIG Incoming Gateway Record MOC Mobile Originated Call Attempt Record MTC Mobile Terminated Call Attempt Record OG Outgoing GatewayOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleMNP Mobile Number PortabilityTS Teleservice Information Module
PLMN AA
MSC(VMSC)
NPDBMOCRecord
L&CTS
EoM
HLR
MNP
B
OGRecord
VisitedMSC
(VMSC)
MTCRecord
L&CTS
EoM
OGIPRecord
IGRecord
RecordRoaming
ICIPRecord
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 313
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 operator’s 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 38 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 party’s 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 38 MNP using the MNP Signal Relay Function (SRF)
MSC(GMSC)
NPDB HLRMNP-SRF
MSC(VMSC)
NPDB HLRMNP-SRF
PLMN A PLMN B
1
2 3a
3b
4a 4b
5a
5b
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 314 (Approved) 30th March 2005
B6.21 Location Services (LCS)
B6.21.1 3GPP Release 99 Messaging
Location Services (LCS) allow information about a subscriber’s 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 39 shows an example LCS scenario in which an LCS client requests location information.
Figure 39 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 users’s 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 EoM End of Module List ModuleLO Location Only Information Module
VMSC
LCSRecord
LOEoM
SRNC
SMLCGMLC
LMU
LCSClient
HLR
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 315
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 40 shows an example of a mobile originated location request.
Figure 40 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 EoM End of Module List ModuleLO Location Only Information Module
VMSC
LCSRecord
LOEoM
SRNC
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 316 (Approved) 30th March 2005
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 GSM-R Call Scenarios
This section contains some example call scenarios for GSM-R calls:
• Section B6.22.1, ‘Enhanced Multi-level Precedence And Pre-emption Service (eMLPP) Call’
• Section B6.22.2, ‘Voice Group and Broadcast Calls’
• Section B6.22.3, ‘Functional Addressing’
B6.22.1 Enhanced Multi-level Precedence And Pre-emption Service (eMLPP) Call
This section contains two eMLPP call scenarios:
• B6.22.1.1, ‘Called Party Pre-emption’
• B6.22.1.2, ‘Resource Pre-emption’ on page 318
B6.22.1.1 Called Party Pre-emption
Figure 41 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 317
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 41 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 not captured in an SS information module.
MSC
HLR
MSC
MTCRecordA
BMOCRecord
RoamingRecord
OGIPRecord
ICIPRecord
C MSC
MOCRecord
RoamingRecord
(A to B)
(A to B)
(A to B) (A to B) (A to B)
(C to A)
(A to C)
OGIPRecord(C to A)
ICIPRecord(C to A)
MTCRecord(C to A)
Key ICIP Incoming Intra-PLMN Trunk Record MOC Mobile Originated Call Attempt Record MTC Mobile Terminated Call Attempt RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleSS Supplementary Services Information ModuleTS Teleservice Information Module
SS (Hold)EoM
SS (eMLPP)EoM
SS (Wait)
L&C
TS
L&CTS
EoM
L&CTS
EoMTS
EoM
TSEoM
SS (eMLPP)
L&CTS
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 318 (Approved) 30th March 2005
B6.22.1.2 Resource Pre-emption
Figure 42 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.
Figure 42 Resource Preemption
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 preemption 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 preemption 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 preempted call (the originally active call) and the preempting call (the new mobile originated call). The result indicator indicates that the preempting 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.
MSC
HLR
MOCRecord Roaming
Record
OGIPRecord
ICIPRecord
active Call
OGIPRecord
EoM
TSEoM
L&CTS
SS (eMLPP)
SS (eMLPP)EoM
Key ICIP Incoming Intra-PLMN Trunk Record MOC Mobile Originated Call Attempt RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleSS Supplementary Services Information ModuleTS Teleservice Information Module
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 319
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 43 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.
Figure 43 Terrestrial Resource Preemption
B6.22.2 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.22.2.1 Mobile Dispatcher Group Call
Figure 44 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
RoamingRecord
OGRecord
active Call
OGIPRecord
MOCRecord
A
B
L&CTS
SS (eMLPP)EoM
MOCRecord
L&CTS
SS (eMLPP)EoM HLR
TSEoM
Key MOC Mobile Originated Call Attempt RecordOG Outgoing Gateway OGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleL&C Location and Channel Information ModuleSS Supplementary Services Information ModuleTS Teleservice Information Module
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 320 (Approved) 30th March 2005
Figure 44 Mobile Dispatcher Group Call
B6.22.2.2 Service Subscriber Group Call
Figure 45 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 45 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 45. 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
AMOCRecord
Key MOC Mobile Originated Call Attempt Record EoM End of Module List ModuleL&C Location and Channel Information ModuleTS Teleservice Information Module
TSEoM
L&C
MSC
AMOCRecord
BC
D
MTCRecord
MTCRecord
MTCRecord
(to B) (to C) (to D)
Key MOC Mobile Originated Call Attempt Record MTC Mobile Terminated Call Attempt RecordL&C Location and Channel Information ModuleEoM End of Module List ModuleTS Teleservice Information Module
TSEoM
L&C
TSEoM
L&CTS
EoM
L&CTS
EoM
L&C
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 321
B6.22.3 Functional Addressing
Figure 46 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 B’s 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 46 Functional Addressing Call
MSC
HLR
MSC
MTCRecord
ABMOC
Record
RoamingRecord
ICIPRecord
OGIPRecord
(A to B)SCP
Key ICIP Incoming Intra-PLMN Trunk RecordMOC Mobile Originated Call Attempt Record MTC Mobile Terminated Call Attempt RecordOGIP Outgoing Intra-PLMN Trunk RecordEoM End of Module List ModuleIN Intelligent Network Information ModuleL&C Location and Channel Information ModuleTS Teleservice Information Module
TS
EoM
INEoM
L&CTS
L&CEoM
TS
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 322 (Approved) 30th March 2005
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 B’s MSISDN, the CoLP information is captured in an SS information module appended to the MOC record. If B displays A’s MSISDN the CLIP information is captured in an SS information module appended to the MTC record.
B6.23 Market-Specific Call Scenarios
B6.23.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 47 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 B’s 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).
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part B: Billing Records and Formats30th March 2005 (Approved) Page: 323
Figure 47 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 B’s 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 C’s number as the called party number and party B’s 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 A’s number. The message also contains a redirecting party id parameter which contains party B’s number and a destination routing address parameter which contains party C’s 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 47.
MSC/SSP
HLR
A CMOCRecord
SCP
Key MOC Mobile Originated Call Attempt Record MTC Mobile Terminated Call Attempt RecordEoM End of Module List ModuleIN Intelligent Network Information ModuleL&C Location and Channel Information ModuleNCR Network Call ReferenceSS Supplementary Service Information ModuleTS Teleservice Information Module
TS
IN
EoM
MTCRecordMOC
Record
TS INEoM
L&CNCRTS
EoM
NCRL&C
SS
IN
MTCRecord
TSEoM
L&C
B
Calling Number field containsParty B’s number irrespective
Calling Number field contains Party A’s 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_FORBILLING office parameter.
NSS18 Billing and Accounting Q272-1Part B: Billing Records and Formats Standard APP 4.9Page: 324 (Approved) 30th March 2005
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 B’s 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 A’s 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.
NSS18 Billing and Accounting
Part C:Tariff Administration
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 327
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 48.
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 328 (Approved) 30th March 2005
Figure 48 Logical Networks, Metering Zones and Route Groups
Figure 48 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 48 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 49. 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 operator’s 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 4Home network(LNET 1)
MZ 1
MZ 32
MZ 63
A
BMZ - MZONEKey
- Service Switching Point (SSP)- Signal Transfer Point (STP)- Route group
1
3
14
101
MZ 2
MZ 3
MZ 32
MZ 60
MZONE 3MZONE 60 126
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 329
Figure 49 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 50.
Figure 50 Tariff System Tables
LNETNUM LNET
LNETNAME
RGRP CONTYPE DIR TRKGRPSCDRREQ
RTEGRP
LNET MZONE RGRP TIDX
DESTZGRP
Universaltranslations
The LNETs defined in table LNETNAMEare used in the universal translations tables.
TIDX is the index used to accessthe relevant tariffing scheme defined in the tariff system tables.
TIDX Date DayClass
tsDate DayClass = holiday
TIDX Day DayClass
tsDayDayClass = weekday or weekend
TIDX SPeriod EPeriod DayClass ChrgBnd
tsTime
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 330 (Approved) 30th March 2005
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 51. 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 331
Figure 51 Tariff analysis for AoC
Table 266 summarises the analysis performed for a mobile originated and a mobile terminated call.
Figure 52 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
1Charging origin Based on cell of origination Don’t 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 266 Information analysed at each level
Chargingorigin
Chargingdestination
Level 1Analysis
Service
Tariffclass
Tariffswitchingpattern
CAIelements
CAI elements (E parameters)
Level 2Analysis
Level 3Analysis
Level 4Analysis
type
E3 CAIelement
sent to mobile station
Chargingzone
Defined in Section C1.3
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 332 (Approved) 30th March 2005
Figure 52 Deriving Charging Parameters for the AoC Service
TARIDTARCLAID CHRGBAND
LAC KEY MZONE
1 1 0. . . . . .
ZONEIDORIGID DESTID
Table LAC/LACSAC
Table CHRGZONE
Table TARDETA
TARCLAIDSUBSERV ZONEID
Translation SystemLAC 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-IDDialled digits (MSISDN)
Table LAC/LACSAC
Table TARCLASS
Tariff Switch. Pattern
DESTIDLNET MZONE
Table DESTZGRP
LNET, MZONE
HOMENET 02 01
10 2
CHRGBAND
0
5
5
2MOTMobile originated/
RGRP
02
RGRP TRKGRP
1 trkgrp1. . . . . .
Table RTEGRPDirection = outgoing
DIR
og
outgoing trunk
CAIELEMSTARID
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 partyIf the called party is on the sameMSC 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
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 333
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.
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 334 (Approved) 30th March 2005
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 335
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.
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 336 (Approved) 30th March 2005
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.104 and B5.2.106 respectively). In the event that the switch destination of the call differs from the originating MSC then the outgoing route group (B5.2.79) 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.106). The originating logical network (B5.2.104) shall always be assumed to be the home network. A simple string name may be associated with each defined charging origin.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 337
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 subscriber’s 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.
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 338 (Approved) 30th March 2005
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 53. 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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 339
Figure 53 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
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 340 (Approved) 30th March 2005
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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 341
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 327.
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 subscriber’s 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 52 on page 332.
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.
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 342 (Approved) 30th March 2005
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.
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 343
C3.3 AoC and MRP Data Tables
C3.3.1 AoC and MRP Tables for Intra-PLMN Calls
Figure 54 AoC with MRPs for Intra-PLMN Calls
Table LAC/LACSACTable LAC/LACSAC
LAC KEY MZONE. . . . . . . . .
301 8 . . . . . . . . . 1
UXLA
Originating MS Location Area Code (LAC) and Cell IDIf the called party is on the same MSC as thecalling 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 TRKGRPSKEY
107 GATEWAY OG Y ANSIISUP
MZONE RGRP DESTID DESTNAMELNET
1 43 107 77 DEST77
Universal Translations
LNET MZONE
DESTID ZONEID ZONENAMEORIGID
1 5 11 AOCZONE
Table RTEGRP
Table DESTZGRP
1 77 43 ATUPLOOP
Table CHRGZONE
AOCSERV TARCLSID TIDXZONEID
11 2 11 0
43 2 43 0
Table TARCLASS
CHRGBND TARID
11 7 117
43 5 435
Table TARDETATARCLSID
CHRGIND AOCSERVCALLTYPE
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 E7PARMTARNAME
117
10
10
1
1
MSORIG1
MSORIG2
600
600
10
10
0
0
0
0
0
0
600
600
MSVLR Translations
Table TARAOC2
for CUSTGRP andNCOS
Note: For MT call, the defaultORIGID of “0” is used.
Note: From this point, the first row represents a scenario in which the called partyis on a different MSC to the calling party. Thesecond row represents a scenario in whichthe called party is on the same MSC as thecalling party.
Table LAC for GSM: Originating MS location area code (LAC) & Cell-IDTable LACSAC for UMTS: Originating MS LAC and service area code (SAC)
LAC KEY MZONE. . . . . . . . .
301 7 . . . . . . . . . 5
Terminating MS LAC & Cell-IDTerminating MS LAC and SAC
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 344 (Approved) 30th March 2005
C3.3.2 AoC and MRP For Roaming Subscribers
Figure 55 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 343.
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 E5PARM E6PARM E7PARMTARNAME
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 E5PARM E6PARM E7PARM
02 5 10 100 0 0 0 600
Table PLMNSUPA
E1PARM
600
From Subscriber IMSI
From table TSTIMEA.Please refer to the previousfigure.
See Figure 54 for these three inputs to TARAOC2
505 02 7 10 100 0 0 0 600600
For Inter-PLMN call, E3 is retrieved fromPLMNSUPA. Other E Parameters are retrieved from:1) MO call, TARAOC22) MT call, PLMNSUPA
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part C: Tariff Administration30th March 2005 (Approved) Page: 345
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 VPLMN’s 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 54 and Figure 55. 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.
NSS18 Billing and Accounting Q272-1Part C: Tariff Administration Standard APP 4.9Page: 346 (Approved) 30th March 2005
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 HPLMN’s 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 55. 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.
NSS18 Billing and Accounting
Part D:Frequently Asked Questions
Q272-1 NSS18 Billing and AccountingAPP 4.9 Standard Part D: Frequently Asked Questions30th March 2005 (Approved) Page: 349
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 267. 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 49, 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 268 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 0GCDR GSMFMT N NIL_FM Y N 0GHOT GSMFMT N NIL_FM Y Y 2
Table 267 Examples definition of billing stream formats in CRSFMT
Datafill to enable the normal and hot billing streams KEY STREAM
GSM GCDRHOT GHOT
Datafill to disable the hot billing stream KEY STREAM
GSM GCDRHOT AMA
Table 268 Example datafill of billing streams in CRSMAP
NSS18 Billing and Accounting Q272-1Part D: Frequently Asked Questions Standard APP 4.9Page: 350 (Approved) 30th March 2005
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 .
2004 - 2005 Nortel
UMTS Network Signalling SystemsGSM/UMTS MSC Billing and Account-ing SpecificationNSS18SIM Specification (Approved)
Document Number: Q272-1Document Status: APP 4.9Classification: StandardActivity: 12557317Date: 30th March 2005
Related Documents
