SMSC R5.4 Bim PDF

Short Message Service Centre TM 5.
Billing Manual
Document Version: 2.0

Document Status: ISSUED
Document ID: SMSC_R5.4_BIM
Document Issue Date: 27 March 2013
Approved by: Dalimil Hrabovsky
Copyright © Acision BV 2007-2013
All rights reserved. This document is protected by international copyright law and may not be reprinted, reproduced, copied or utilised in whole
or in part by any means including electronic, mechanical, or other means without the prior written consent of Acision BV.
Whilst reasonable care has been taken by Acision BV to ensure the information contained herein is reasonably accurate, Acision BV shall not,
under any circumstances be liable for any loss or damage (direct or consequential) suffered by any party as a result of the contents of this
publication or the reliance of any party thereon or any inaccuracy or omission therein. The information in this document is therefore provided on
an “as is” basis without warranty and is subject to change without further notice and cannot be construed as a commitment by Acision BV.
The products mentioned in this document are identified by the names, trademarks, service marks and logos of their respective companies or
organisations and may not be used in any advertising or publicity or in any other way whatsoever without the prior written consent of those
companies or organisations and Acision BV.
SMSC_R5.4_BIM Version: 2.0

Security: Commercial-In-Confidence Status: ISSUED
Copyright © Acision BV 2007-2013 Page 2 of 138
Table of Contents
Preface...................................................................................................................... 11
1 Introduction ....................................................................................................... 13
2 SMSC Billing Model .......................................................................................... 14

2.1 SMSC in Context ................................................................................................................. 14
2.2 SMSC Billing Model ............................................................................................................. 15
2.2.1 Postpaid Events ................................................................................................... 16
2.2.2 Prepaid Billing Events .......................................................................................... 16
3 Billing Scenarios ............................................................................................... 19

3.1 Scenarios Relevant to Prepaid and Postpaid ..................................................................... 19
3.1.1 Single Recipient ................................................................................................... 19
3.1.2 Permanent Delivery Failure/Originator Deleted/Expired ...................................... 20
3.1.3 Additional Services .............................................................................................. 21
3.1.4 Concatenated Messages ..................................................................................... 22
3.1.5 SMS Alert ............................................................................................................. 24
3.1.6 Time Sensitive SM Alert ....................................................................................... 25
3.1.7 Concatenated SMS Alert ..................................................................................... 25
3.1.8 Rejected Messages ............................................................................................. 27
3.2 Scenarios Relevant to Prepaid Only ................................................................................... 28
3.2.1 Insufficient Funds ................................................................................................. 28
3.2.2 Additional Service with Insufficient Funds ........................................................... 29
3.2.3 SMSC – Prepaid System Interface Jammed ....................................................... 30
4 Prepaid Billing Configuration ........................................................................... 31

4.1 Prepaid Billing Large Account Configuration....................................................................... 31
4.2 Prepaid Billing O&M Configuration ...................................................................................... 31
4.3 Miscellaneous Prepaid Billing Configuration ....................................................................... 35
4.4 PID/TON/NPI Mapping ........................................................................................................ 35
5 Postpaid Billing Configuration ......................................................................... 36

5.1 Naming and Location of Billing Files ................................................................................... 36
5.1.1 LOGSRV Billing Files ........................................................................................... 36
5.1.2 Additional LOGSRV Billing Files .......................................................................... 36
5.1.3 CMLOG Billing Files............................................................................................. 37
5.1.4 Additional CMLOG Billing Files ............................................................................ 37
5.1.5 CMLOG State File ................................................................................................ 37
5.1.6 CMLOG – LOGSRV Interface File ....................................................................... 38
5.1.7 Availability of Billing Files ..................................................................................... 38
5.1.8 Redefining Location Billing Files .......................................................................... 38
5.1.9 Removing Billing Files.......................................................................................... 39
5.2 Operations and Maintenance (O&M) .................................................................................. 39
5.3 LOG Request Filtering ......................................................................................................... 46
5.4 IDI Filtering .......................................................................................................................... 46
5.5 CDR Format Customisation ................................................................................................ 48
6 ASN.1 CDR Format ............................................................................................ 49

6.1 CDR Format ........................................................................................................................ 49
6.2 CDR Field Description ......................................................................................................... 79
6.2.1 Bit Fields .............................................................................................................. 79
6.2.2 CDR Address Fields ............................................................................................ 84
6.2.3 Time Periods ........................................................................................................ 86
6.2.4 SMS Contents ...................................................................................................... 87
6.2.5 Teleservice Identifier ............................................................................................ 88
6.2.6 SMRI .................................................................................................................... 89
6.2.7 Message Error ..................................................................................................... 89
6.2.8 Prepaid Debit Transaction Status ........................................................................ 90
7 Toll Ticketing CDR Format ............................................................................... 91

7.1 Toll Ticketing Format ........................................................................................................... 91
8 Post-Processing of Billing Files ...................................................................... 94

8.1 BILLING_PP Script .............................................................................................................. 94
8.1.1 BILLING_PP Configuration .................................................................................. 94
8.1.2 BILLING_PP Alarm Signals ................................................................................. 96
8.1.3 User Specific Actions ........................................................................................... 96
8.2 Billing External Interface...................................................................................................... 96
8.2.1 NFS ...................................................................................................................... 96
8.2.2 FTP ...................................................................................................................... 97
8.3 FCDR_DECODE ................................................................................................................. 98
8.4 BPP_TELEP ........................................................................................................................ 98
8.4.1 Assumptions ........................................................................................................ 99
8.4.2 Configuration ........................................................................................................ 99
8.4.3 Usage ................................................................................................................. 106
9 CDR Samples................................................................................................... 108

9.1 Billing Samples File Naming Conventions ........................................................................ 108
9.2 Billing Configuration Profile Descriptions .......................................................................... 108
9.2.1 Configuration Profile P01 ................................................................................... 108
9.3 Traffic Scenarios ............................................................................................................... 110
9.4 Mobile to Mobile Successful Delivery (TC01) ................................................................... 110

9.4.1 GSM to GSM with Notification (TC01a) ............................................................. 110
9.4.2 CDMA to CDMA Delivery Acknowledgement (TC01b) ...................................... 110
9.4.3 CDMA to CDMA User Acknowledgement (TC01c) ........................................... 110
9.4.4 GSM to GSM via Public VSMSC (TC01d) ......................................................... 110
9.4.5 GSM to TDMA without Status Report (TC01e) .................................................. 110
9.4.6 TDMA to GSM without Status Report (TC01f) ................................................... 110
9.4.7 CDMA to iDEN (TC01g) ..................................................................................... 110
9.5 Mobile to Mobile Unsuccessful Delivery, ‘Permanent Error’ (TC02) ................................. 111
9.5.1 Failed GSM to GSM Delivery: Unknown Subscriber (TC02a) ........................... 111
9.6 Mobile to Mobile Unsuccessful Delivery, ‘Temporary Error’ (TC03) ................................. 111
9.6.1 Failed GSM to GSM Delivery: Absent Subscriber (TC03a) ............................... 111
9.7 Mobile to UCP Large Account (TC04) ............................................................................... 111
9.7.1 GSM to Single Address LA (TC04a) .................................................................. 111
9.7.2 GSM to Multiple Address LA (TC04b) ............................................................... 111
9.7.3 GSM to Multiple Address LA via RARR – Short Number Range (TC04c) ........ 111
9.7.4 GSM to Multiple Address LA via RARR – Mobile Number Range (TC04d) ...... 111
9.8 Mobile to SMPP Large Account (TC05) ............................................................................ 112
9.8.1 GSM to Single Address LA via RARR – Short Number Range (TC05a) ........... 112
9.8.2 GSM to Multiple Address LA via RARR – Short Number Range (TC05b) ........ 112
9.8.3 GSM to Multiple Address LA via RARR – Mobile Number Range (TC05c) ...... 112
9.9 LA to Mobile (TC06) .......................................................................................................... 112
9.9.1 Single Address UCP LA to Mobile (TC06a) ....................................................... 112
9.9.2 Multiple Address UCP LA to Mobile (TC06b) .................................................... 112
9.9.3 Single Address SMPP LA to Mobile (TC06c) .................................................... 112
9.9.4 Multiple Address SMPP LA to Mobile (TC06d) .................................................. 113
9.10 Large Account to Large Account (TC07)........................................................................... 113
9.10.1 UCP Large Account to UCP Large Account via Short Number (TC07a) ........... 113
9.10.2 UCP Large Account to SMPP Large Account via Short Number (TC07b) ........ 113
9.10.3 SMPP Large Account to UCP Large Account via Mobile Number (TC07c) ...... 113
9.10.4 SMPP Large Account to UCP Large Account via Short Number (TC07d) ........ 113
9.11 Full SMS Content, UCP LA to GSM Mobile (TC08) .......................................................... 113
9.11.1 Full SMS Content Regular Text (TC08a) ........................................................... 113
9.11.2 Full SMS Content Unicode Text (TC08b) .......................................................... 113
9.11.3 Binary Data without UDH (TC08c) ..................................................................... 114
9.11.4 Binary Data for Nokia Ringtone (TC08d) ........................................................... 114
9.11.5 Concatenated Message of Three Segments, Regular Text (TC08e) ................ 114
9.12 MSC Addresses for Roaming Subscribers (Global Titles) (TC09) .................................... 114
9.12.1 GSM to GSM Mobile with ITU Global Title addressing for Originator and
Recipient MSCs (TC09a) ................................................................................... 114
9.13 Alphanumeric LA to Mobile (TC011) ................................................................................. 114
9.13.1 Single Address Alphanumeric UCP Large Account to Mobile (TC011a) ........... 114
9.14 Mobile to Distribution List (TC012) .................................................................................... 114
9.15 Mobile to Mobile, Unconditional Forwarding (TC013) ....................................................... 115
9.16 Mobile to Mobile, Conditional Forwarding (TC014) ........................................................... 115

9.17 Mobile to Mobile, Switched Forwarding (TC015) .............................................................. 115
9.18 Mobile to Mobile, with EMS (TC016) ................................................................................. 115
Abbreviations ......................................................................................................... 136
References ............................................................................................................. 137
Version History ...................................................................................................... 138

List of Figures
Figure 2-1: SMSC Environment............................................................................................................. 14
Figure 2-2: SMSC Context Diagram ...................................................................................................... 15
Figure 2-3: Prepaid SMS Overview ....................................................................................................... 17
Figure 3-1: Call Flow – Send SM to Single Recipient ........................................................................... 20
Figure 3-2: Call Flow – Permanent Delivery Failure, SM Deletion or SM Expiry .................................. 21
Figure 3-3: Call Flow – Send SM with Additional Service ..................................................................... 22
Figure 3-4: Call Flow – Send Concatenated SMS................................................................................. 24
Figure 3-5: Call Flow – VAS/Large Account Delivery via SM ................................................................ 25
Figure 3-6: Call Flow – VAS/Large Account Delivery via CM ............................................................... 27
Figure 3-7: Call Flow – SM Submission Failure due to Originator is on Blacklist ................................. 28
Figure 3-8: Call Flow – SM Submission Failure due to Insufficient Funds ............................................ 29
Figure 3-9: Call Flow – Additional Service Failure due to Insufficient Funds ........................................ 30

List of Tables
Table Preface-1: Typographic Conventions .......................................................................................... 11
Table 2-1: CDR Status Codes ............................................................................................................... 15
Table 4-1: PBR_COMMON Attributes ................................................................................................... 31
Table 4-2: SMSC Attributes ................................................................................................................... 33
Table 4-3: SMH_COMMON Attributes .................................................................................................. 34
Table 4-4: SSD_COMMON Attributes ................................................................................................... 34
Table 4-5: Relevant Prepaid Logical Name ........................................................................................... 35
Table 5-1: LOGSRV_COMMON Attributes ........................................................................................... 39
Table 5-2: LOGSRV Attributes .............................................................................................................. 41
Table 5-3: SMSC Attributes ................................................................................................................... 42
Table 5-4: SMH_COMMON Attributes .................................................................................................. 44
Table 5-5: Logical Names for configuring ASN.1 CDR Fields ............................................................... 44
Table 5-6: CMLOG_COMMON Attributes ............................................................................................. 45
Table 5-7: IDI Filter Syntax .................................................................................................................... 47
Table 6-1: ASN.1 Definition ................................................................................................................... 49
Table 6-2: CallDetailRecord Fields ................................................................................................ 64
Table 6-3: CommandRecord Fields (Specifics) ..................................................................................... 72
Table 6-4: NotificationRecord Fields (Specifics) .......................................................................... 73
Table 6-5: SummaryRecord Fields (Specifics) ..................................................................................... 75
Table 6-6: Alert Record Fields ......................................................................................................... 77
Table 6-7: Fax Report Record Fields .............................................................................................. 77
Table 6-8: Failed Login Record Fields.......................................................................................... 78
Table 6-9: Send Routing Info Record Fields ............................................................................... 78
Table 6-10: ASER Field Description ....................................................................................................... 79
Table 6-11: MSER Field Description ....................................................................................................... 80
Table 6-12: NSER Field Description ....................................................................................................... 80
Table 6-13: XSER Field Description ....................................................................................................... 81
Table 6-14: ppAser Field Description .................................................................................................. 81
Table 6-15: ppPser Field Description .................................................................................................. 81

Table 6-16: BSER Field Description ....................................................................................................... 82
Table 6-17: BSER_NOTIF Field Description .......................................................................................... 82
Table 6-18: BSER_CM Field Description ................................................................................................ 82
Table 6-19: ISR FLAGS Field Description ............................................................................................ 83
Table 6-20: NewServicesCM Field Description ................................................................................... 83
Table 6-21: CServices Field Description ............................................................................................ 83
Table 6-22: CServicesCM Field Description ........................................................................................ 83
Table 6-23: DServices Field Description ............................................................................................ 83
Table 6-24: DServicesNTF Field Description ..................................................................................... 84
Table 6-25: CServicesNTF Field Description ..................................................................................... 84
Table 6-26: TON .................................................................................................................................... 85
Table 6-27: NPI ..................................................................................................................................... 85
Table 6-28: PID ..................................................................................................................................... 86
Table 6-29: DCS .................................................................................................................................... 87
Table 6-30: Teleservice Identifier .......................................................................................................... 88
Table 6-31: Message Error (Delivery) ................................................................................................... 89
Table 6-32: Message Error (Submission) .............................................................................................. 89
Table 7-1: Toll Ticketing Record Definition ........................................................................................... 91
Table 8-1: BILLING_PP Configuration Parameters............................................................................... 94
Table 8-2: BPP_TELEP Configuration Files.......................................................................................... 99
Table 8-3: BPP_TELEP Configuration Parameters............................................................................. 100
Table 8-4: Format of Telepath Record Parameters ............................................................................ 101
Table 8-5: Format Telepath Header- and Trailer Parameters ............................................................. 106
Table 9-1: Configuration Profile P01 ................................................................................................... 108
Table B-1: FCDR_FIELDS_TEMPLATE.CNF ..................................................................................... 118
Table C-1: ASN.1 Tags CallDetailRecord.................................................................................... 126
Table C-2: ASN.1 Tags NotificationRecord ............................................................................... 128
Table C-3: ASN.1 Tags CommandRecord .......................................................................................... 130
Table C-4: ASN.1 Tags SummaryRecord .......................................................................................... 131
Table C-5: ASN.1 Tags AlertRecord .............................................................................................. 133

Table C-6: ASN.1 Tags FailedLoginRecord ................................................................................. 134
Table C-7: ASN.1 Tag FaxReportRecord........................................................................................ 134
Table C-8: ASN.1 Tag SendRoutingInfoRecord........................................................................... 135

Preface
Purpose
The purpose of this document is to explain the billing possibilities of the Short Message
Service Centre (SMSC). It describes what billing information can be generated, and how the
billing system can be configured.
Audience
The target audience of this document are operators who want to know more about
generation of billing data by the SMSC.
Scope
The scope of the document is to describe the billing flow within the SMSC and the resulting
information flow to prepaid and postpaid systems.
Organisation
This document is organised in nine chapters.
The first chapter is an introduction to the billing system. The second chapter introduces the
billing model and describes postpaid and prepaid events. The third chapter provides details
on the common billing scenarios for both postpaid and prepaid cases. The chapters four and
five discuss the prepaid and postpaid billing configuration respectively. The chapters six and
seven deal with Toll Ticketing and ASN.1 CDR format respectively. The eighth chapter
describes the post-processing of billing files, and in chapter nine the CDR samples are
presented.
Typographic Conventions
In this document, the typographic conventions listed in Table Preface-1 are used.
Table Preface-1: Typographic Conventions
Typeface/ Meaning/Used for Example

Symbol
Courier Refers to keyboard key, system command, label, DATA directory contains...
button, filename, window, or other computer
component or output. Click Close button to...
<courier> Serves as placeholder for variable text that the Use file name <entity>.cfg for...
user will replace as appropriate to its context.
[] Refers user to external documentation listed in [ETSI 03.38]

References section.
Italic Emphasises new word or term of significance. Install, a procedure on a SUN T1.
% Denotes a Unix regular-user prompt for C shell. % ls
# Denotes a Unix super-user prompt for any shell. # ls
$ Denotes an OpenVMS Digital Command $ dir

Typeface/ Meaning/Used for Example
Symbol
Language prompt.
\ (Unix) Denotes line continuation; the character should % grep searchforthis \

or be ignored as the user types the example, and data/*.dat
– Enter should only be pressed after the last line.
(OpenVMS) $ search [.data]*.dat -
searchforthis
- Bridges two keystrokes that should be pressed If Ctrl-C does not work, use Ctrl-Alt-
simultaneously. Del.
Denotes a “note”, a piece of text alongside the Note that the system is usually...
normal text requiring extra attention.

1 Introduction
This document describes the generation of billing information by the SMSC version 5.2. The
following sections describe the events, for which the billing records are generated, the format
of the billing records, the fields of the Call Detail Records (CDRs), and how the system and
billing output can be configured.
The postpaid billing records of the SMSC are generated by the LOGSRV and CMLOG
entities. The LOGSRV is responsible for the creation of charging information for services that
require only one short message. Enhanced Messaging Service (EMS), Concatenated short
Messages (CM) and Application Port Addressing (APA) services usually require more than
one message to send the information to the recipient. This results in the use of concatenated
messages (CMs). The CMLOG entity is responsible for the creation of charging information
for CMs.
Charging information is gathered in billing files. These billing files consist of CDRs in ASN.1
or Toll Ticketing format, of which each CDR represents one billing event. The operator has
the possibility to configure the contents of the CDRs (ASN.1 only). It is also possible to
configure which billing events, CDRs need to be written for.
The files generated by the system can be collected by an external system for further
processing, i.e. the creation of bills and/or the analysis of the requests processed by the
system. Therefore, the processing of the billing files is not part of the SMSC. However, it is
the operator’s responsibility to remove the billing files from the system.
The prepaid billing records of the SMSC are generated by the PBR entities. During the
submission of a Short Message (SM), these billing records are sent in real-time to a remote
system over a well-defined protocol. The SMSC continues to process these messages after
it has received a response from the remote system. Depending on the content of this
response, the message is either accepted or rejected by the SMSC.

2 SMSC Billing Model
2.1 SMSC in Context

Figure 2-1 shows the SMSC in its environment. As depicted, the SMSC can be connected to
several networks, namely:
• Public Land Mobile Network (PLMN) – used to submit and/or receive short messages
using a mobile entity.
• Public Switched Telephone Network (PSTN)
• LAN – used by the operator for Network Management Systems, customer care and billing
systems, voice mail and Value Added Services (VAS) such as voice and fax mail
notifications.
1 2 3
4 5 6
7 8 9
* 8 #
PSTN Network Management

Customer Care
LAN Billing
Voice Mail System
VAS
SMSC
PLMN
Figure 2-1: SMSC Environment
Figure 2-2 shows the Context Diagram of the SMSC. The focus of this manual is the Billing
System terminator that processes the Call Detail Records (CDRs).

Operator
Fax
O&M
FAXG3 Protocol
PLMN Large Account

SMSC
IS41/ UCP/SMPP/
MAP Protocol OIS Protocol
STAT
CDR
Statistics
Billing System
Figure 2-2: SMSC Context Diagram
2.2 SMSC Billing Model

The SMSC is capable of reporting events, which may be billed, during the processing of
short messages. Event details such as time stamps, A and B party addresses and many
others are logged using Call Detail Records (CDRs). In addition to CDR logging, for prepaid
subscribers it is necessary to check the subscribers account balance prior to delivering the
service. The SMSC Prepaid Billing Protocol (SPBP) is used to forward details of billable
events to an external prepaid billing system. The SPBP response from the prepaid billing
system will indicate if sufficient credit exists or not.
The SMSC uses the status codes presented in the following table to differentiate between
CDRs generated for a short message (SM).
Table 2-1: CDR Status Codes
Code Status Description
0 Delivered Message has been delivered.
1 Expired Validity period or the retry scheme has expired, before the message could be
delivered.
2 Deleted Originator has deleted the message, or it has been removed due to a
permanent failure.
3 Replaced Originator has replaced the message.
4 Submitted Initial status of a message that has been submitted.
5 Incomplete CM submission period has expired before all segments have been
Submission successfully accepted (in EMS usage).
6 Incomplete Delivery CM delivery period has expired before all segments have been successfully
delivered (in EMS usage).
7 Undeliverable Message could not be delivered due to a permanent error.

Code Status Description
8 Passed-on Message has been delivered to the next SMSC.
9 Rejected Message is rejected by the SMSC.
Status code 5 (incomplete submission) and 6 (incomplete delivery) only occur in summary
records.
2.2.1 Postpaid Events
The SMSC is able to generate postpaid billing information for the following events:
• Acceptance of a submitted SM.
• Acceptance of all submitted segments of a CM.
• Successful delivery of all segments of a CM.
• Successful delivery of a status-report or a notification message.
• Expiration of the CM submission period before all CM segments have been accepted.
• Expiration of the CM delivery period before all CM segments have been delivered
successfully.
• Rejection of a submitted SM.
• Removal of an SM from the system. This occurs in one of the following cases:
− Successful delivery of the SM.
− Expiration of the validity period of the SM.
− Deletion of the SM (by the operator or its originator).
− Replacement of the SM (by its originator).
− Routing of a SM to its forwarded address.
− Routing of a SM to its last resort address.
− Persistent error type encountered during a delivery attempt.
Note that an SM can also be a single segment of a CM: the acceptance of a single segment
of a CM is also a billing event. The billing events may lead to the creation of one of the
following CDR types:
• Short Message CDR
• Notification CDR
• Command CDR
• CM Summary CDR
It is possible to filter out billing information by using billing event and billing record types. For
more information, please refer to Chapter 1. For details on the various CDR types, please
refer to Chapters 6 and 7.
2.2.2 Prepaid Billing Events
In Figure 2-3 an overview of the SMS Prepaid solution is depicted. The numbers 1, 2 and 3
enumerate the consecutive events that go back and forth between the different elements
involved.

When the SMSC receives an SM, it determines the charged party for this service (1) and
sends a Primary Service debit request message towards the prepaid system (2). The
SMSC waits for the debit response answer from the prepaid system before accepting the
SM or not. This acknowledgement indicates whether the charged party is known in the
prepaid system as a prepaid user and, if so, whether the user is creditable or not. Whenever
the charged party is postpaid or creditably prepaid, the SMSC tries to deliver the accepted
message to its destination address (3). If it does not succeed (because the validity period
exceeded, a permanent network error is encountered or the message is explicitly removed),
and the charged party is a prepaid user, the SMSC refunds the user by sending the prepaid
system a Primary Service credit request.
Ifconfigurable
the interface to the prepaid system is JAMMED, the behaviour of the SMSC is
via the /PP_JAMMED_SETTING attribute which is described in Table 4-2.
If Additional Services (like Forwarding, Notifications, Last Resort Delivery, SMS Commands,
Provisioning or Reply Path Responses) are applied to an accepted SM, these are charged
separately to the requestor of the service through an Additional Service debit request. The
requestor can be the originator, the recipient or the operator. The SMSC waits for the debit
response answer from the prepaid system before applying the Additional Service. The
charging of Additional Services is done at the moment when these services are applied,
which can be (much) later than the time of submission. In case an Additional Service cannot
be charged, the request is ignored and not applied to the SM. The SM, however, remains in
the system. For each Additional Service that was granted and charged to a prepaid user but
could eventually not be executed successfully, an Additional Service credit request is
generated by the SMSC.
Each debit request is marked either charged or free. In the latter case, the creditability of
the charged party is not relevant for the acceptance of the service. An acknowledgement
from the prepaid system must still be generated, as it can contain information that indicates
that the charged party is not prepaid after all.
1 3
S M S C
P r e p a id
S y s t e m
Figure 2-3: Prepaid SMS Overview
The SMSC generates prepaid billing information for the following events:
• Primary Service debit request for each incoming SM
• Primary Service credit request for accepted SMs for which a prepaid user was the
charged party and which were removed from the SMSC due to an unsuccessful delivery

• Primary Service info request for each successfully delivered SM
• Additional Service debit request for each applied Additional Service:
− Generation of a Notification/Status Report
− Routing of an SM to its forwarded address
− Routing of an SM to its last resort address
− Submission of an SMS Command either through a scan tag or a GSM Phase 2
command
− Submission of a subscriber provisioning command through a scan tag
− Submission of a reply path response to an earlier reply path request
• Additional Service credit request for each unsuccessfully applied Additional Service
which has been charged to a prepaid user previously:
− Removal of a Notification/Status Report due to unsuccessful delivery
− Removal of a forwarded SM due to unsuccessful delivery
− Removal of a last resort SM due to unsuccessful delivery
− Unsuccessful execution of an SMS Command
− Unsuccessful execution of a subscriber provisioning command
− Removal of a reply path response due to unsuccessful delivery.
• Additional Service info request for each successfully applied Additional Service:
− Generation of a Notification/Status Report
− Routing of an SM to its forwarded address
− Routing of an SM to its Last Resort Address
− Submission of an SMS Command either through a scan tag or a GSM Phase 2
command
− Submission of a subscriber provisioning command through a scan tag
− Submission of a reply path response to an earlier reply path request.
A delivery is regarded unsuccessful in the following situations:

• Expiration of the validity period of the SM.
• Deletion of the message (by operator or originator).
Persistent error type encountered during a delivery attempt.

3 Billing Scenarios
This chapter describes the logical call flows used by the SMSC for common call scenarios.
This description includes the processing of SMs, Value Added Services (VAS) and fault
scenarios. Call flow diagrams are used to illustrate the types and timings of the generated
CDRs and SPBP transactions.
An arrow denotes a call flow event that is a logical communication between two components.
The number associated with the arrow “n” indicates the time related order of the event.
n. Call Flow
An arrow with an SPBP description is a specific primary or additional service request or

acknowledgement related to the SPBP interface. The identifier ‘c’ in brackets denotes either
the charging type of the request (debit/credit) or the result of the acknowledgement
(success/not_creditable).
n. SPBP[c)]
A square with a line exiting to the right is a CDR event. The number in brackets “p”
represents the value of the CDR status code.
n. CDR (p)
The call flows presented in this document are simplified, logical views of the actual call flows.
3.1 Scenarios Relevant to Prepaid and Postpaid

This section describes call flows relating to the following scenarios, which are relevant for
prepaid and postpaid billing:
1. Submission of an SM to the SMSC.
2. Submission of an SM to the SMSC with permanent delivery failure/originator
deletion/expiry.
3. Submission of an SM to the SMSC with additional services.
4. Submission of a CM.
5. VAS (using Large Account) via SMS.
6. VAS (using Large Account) via CM.
7. VAS (using Large Account) with time sensitive SMS.
3.1.1 Single Recipient
Submission of an SM to a single recipient that is delivered successfully is illustrated in Figure

3-1.
In the prepaid case, the SMSC performs the debit request before acceptance of an SM.
The events are:
1. Submission of SM from mobile device.
2. SPBP primary service debit request for the submission of an SM (prepaid only).
3. SPBP primary service acknowledgement indicating successful debit request (prepaid
only).
4. SMSC generates CDR confirming submission of an SM.
5. SMSC delivers SM.
6. SPBP primary service info request for the successful delivery of an SM (prepaid only,
configurable)
7. SMSC generates CDR confirming SM delivery.
1. Submit SM
2. SPBP prim_service (debit)

SM accepted by SMSC
3. SPBP prim_ack (success)
4. CDR (4)
5. SM Delivery
Prepaid
SMSC
6. SPBP prim_service (info) System
7. CDR (0)
Figure 3-1: Call Flow – Send SM to Single Recipient
3.1.2 Permanent Delivery Failure/Originator Deleted/Expired
The submission of an SM to a single recipient that is either not delivered successfully

because of a permanent delivery failure, deleted by the originator, or expires, is illustrated in
Figure 3-2. The events are:
3. SPBP primary acknowledgement indicating successful debit request (prepaid only).
4. SMSC generates a CDR confirming submission of SM.
SM was not delivered because the SMSC experienced a permanent delivery failure, the
originator deleted the SM, or the SM expired.
5. SPBP primary service credit request to prepaid system to credit the subscriber (prepaid
only).

6. SPBP primary service acknowledgement response indicating successful credit request
(prepaid only).
7. SMSC generates a CDR indicating either persistent delivery failure “status (2)”, originator
deleted “status (2)”, or expiry “status (1)”.
1. Submit SM
SM accepted by SMSC 2. SPBP prim_service (debit)
4. CDR (4)
Permanent Delivery
Failure or SM Deletion Prepaid
SMSC or SM Expiry
System
5. SPBP prim_service (credit)
7. CDR (1/2)
Figure 3-2: Call Flow – Permanent Delivery Failure, SM Deletion or SM Expiry
3.1.3 Additional Services

The submission of an SM including additional services, specifically submission (buffered)
and delivery notifications is illustrated in Figure 3-3. The events are the following:
1. Submission of an SM from a mobile device with a request for buffered and delivery
notifications.
3. SPBP primary service acknowledgement response indicating successful debit request
(prepaid only).
4. SMSC generates a CDR confirming submission of an SM.
5. SPBP additional service debit request for the buffered notification (prepaid only).
6. SPBP additional service acknowledgement indicating a successful debit request (prepaid
only).
7. SMSC delivers the buffered notification.
8. SPBP additional service info request for the successful delivery of the buffered
notification (prepaid only, configurable)
9. SMSC generates a CDR confirming delivery of the buffered notification.
10. SMSC delivers an SM.
configurable)
12. SMSC generates a CDR confirming SM delivery.
13. SPBP additional service debit request for the delivery notification (prepaid only).
14. SPBP additional service acknowledgement indicating a successful debit request (prepaid
only).
15. SMSC delivers the delivery notification.
16. SPBP additional service info request for the successful delivery of the notification
(prepaid only, configurable)
17. SMSC generates a notification CDR confirming the notification delivery.
1. Submit SM
4. CDR (4)
5. SPBP add_service (debit)
7. Buffered Notification 6. SPBP add_ack (success)
8. SPBP add_service (info)
9. Notification CDR (0)
Prepaid
SMSC 10. SM Delivery
System
11. SPBP prim_service (info)
12. CDR (0)
14. SPBP add_ack (success)
16. SPBP add_service (info)
17. Notification CDR (0)

15. Delivery Notification
Figure 3-3: Call Flow – Send SM with Additional Service
If the additional service could not be delivered, because of either a persistent delivery failure,
deletion by the originator, or expiration of the validity period, the SMSC will generate a
separate SPBP additional service credit transaction and CDR. The status of the CDR will be
either “2” for persistent delivery failure or originator deletion, or “1” for message expiry. In
case multiple additional services were requested, the SMSC will generate separate SPBP
additional service debit transactions and CDRs for each service.
3.1.4 Concatenated Messages
Enhanced Message Services (EMS), Concatenated Messages (CM), and Application Port
Addressing (APA) servers usually require more than one SM to send the information to the
recipient; CMs are used for this purpose. The SMSC processes each segment of a CM

independently. This means the SMSC generates a separate SPBP primary service
transaction and CDR on submission and CDR on delivery of each segment of a CM. The
SMSC also generates summary CDRs for CMs. A summary CDR is generated on
acceptance of all segments of a CM and on successful delivery of all segments.
The submission of a CM (in this example consisting of two segments) is shown in. Each
segment of the CM contains the following information: total message reference number,
segment number, and the total number of segments. This information will also be present in
the attributes of the CDR and SPBP primary service.
In case of a Long Message [OMAN] or Extended Message [OMAN], the SMSC initiates one
primary service transaction for the whole message. The field maxSegment in
ConcatInformation will contain the number of segments. The currentSegment and
cmReference fields will be set to zero. The events are the following:
1. Mobile device submits segment one of CM.

2. SPBP primary service debit request for the submission of segment one (prepaid only).
only).
4. SMSC generates a CDR confirming submission of segment one.
5. SMSC delivers segment one.
configurable)
7. SMSC generates a CDR confirming delivery of segment one.
8. Mobile device submits segment two of CM.
9. SPBP primary service debit request for the submission of segment two (prepaid only).
only).
11. Receipt acknowledgement sent to mobile device.
12. SMSC delivers segment two.
configurable)
14. SMSC generates a CDR confirming delivery of segment two.
15. SMSC generates a CDR confirming acceptance of all segments of the CM.
16. SMSC generates a CDR confirming successful delivery of all segments of the CM.
Although the delivery of segment one is indicated as occurring directly after submission, it
may occur at an indeterminate time after submission. Furthermore, submission of the
second segment is not dependent upon delivery of the first segment.
Moreover, while the CDR confirming acceptance of all segments is shown, occurring after
the delivery of segment two, it is technically possible that it will be generated immediately
after the successful submission of segment two.

1. Submit Seg. 1 SMSC
4. CDR (4)
5. SM Delivery (Seg. 1)
8. Submit Seg. 2 7. CDR (0)

SM accepted by SMSC
Prepaid
System
11. CDR (4)
14. CDR (0)
15. CM Summary CDR (4)
Figure 3-4: Call Flow – Send Concatenated SMS
3.1.5 SMS Alert
The delivery of a Value Added Service (VAS) or alert via an SM is shown in Figure 3-5.
The events are:

1. VAS/Large Account submits SM.
2. SPBP primary service debit request for the submission of the SM (prepaid only).
only).
4. SMSC generates a CDR confirming submission of SM.
5. Receipt acknowledgement sent to VAS/Large Account.
7. SPBP primary service info request for the successful delivery of the SM (prepaid only,
configurable)

1. Submit SM
4. CDR (4)
5. UCP Ack
6. SM Delivery
VAS/
Prepaid
Large SMSC
System
Account
8. CDR (0)
Figure 3-5: Call Flow – VAS/Large Account Delivery via SM
3.1.6 Time Sensitive SM Alert
The SMSC supports a number of mechanisms through which an application can replace an
undelivered SM by a more up-to-date one. For example:
• The application could use the delete/cancel command to delete the SM before submitting
the more up-to-date one.
• The application could replace the SM with a newer one by using the same “Message
Replace Type” value.
3.1.7 Concatenated SMS Alert
A VAS or alert may require more than one message to send the information to the recipient.
To support this scenario, CMs are supported. The SMSC processes each segment of a CM
independently. This means the SMSC generates a separate SPBP primary service
transaction and CDR on submission, and CDR on delivery of each segment of a CM. The
SMSC also generates summary CDRs for CMs. A summary CDR is generated on
acceptance of all segments of a CM and on successful delivery of all segments.
The delivery of a VAS or alert via CM (in this example consisting of two segments) is shown
in Figure 3-6. Each segment of the CM contains the following information: total message
reference number, segment number and total number of segments. This information will also
be present in the attributes of the CDR and SPBP primary service. The events are the
following:
1. VAS/Large Account submits segment one of CM.
2. SPBP primary service debit request for the submission of segment one (prepaid only).
only).

4. SMSC generates CDR confirming submission of segment one.
5. SMSC delivers segment one.
6. SPBP primary service info for the successful delivery of segment one (prepaid only,
configurable)
7. SMSC generates CDR confirming delivery of segment one.
8. VAS/Large Account submits segment two of CM.
9. SPBP primary service debit request for the submission of segment two (prepaid only).
only).
11. SMSC generates CDR confirming submission of segment two.
12. SMSC delivers segment two.
13. SPBP primary service info for the successful delivery of segment two (prepaid only,
configurable
14. SMSC generates CDR confirming delivery of segment two.
15. SMSC generates a CDR confirming acceptance of all segments of the CM.
16. SMSC generates a CDR confirming successful delivery of all segments of the CM.
Although the delivery of segment one is shown, occurring directly after submission, it may
occur at any indeterminate time after submission. In addition, submission of the second
segment is not dependent upon delivery of the first segment.
Moreover, while the CDR confirming acceptance of all segments is shown, occurring after
the delivery of segment two, it is technically possible that it will be generated immediately
after the successful submission of segment two.

1. Submit Seg. 1
SMSC
SM accepted by SMSC
4. CDR (4)
8. Submit Seg. 2 5. SM Delivery (Seg. 1)

SM accepted by SMSC 6. SPBP prim_service (info)
7. CDR (0)

VAS/
10. SPBP prim_ack (success) Prepaid
Large
11. CDR (4) System
Account
14. CDR (0)
Figure 3-6: Call Flow – VAS/Large Account Delivery via CM
3.1.8 Rejected Messages
Failure of an SM submission resulting from e.g. blacklisted originator in Figure 3-7.
The events are the following:

2. SMSC returns submission failure to mobile device.
3. SMSC creates CDR for rejected SM.

1. SUBMIT_SM
SMrejected by SMSC
(Blacklisted) Prepaid
SMSC
3. CDR (Rejected) System
2. Submission Failure
Figure 3-7: Call Flow – SM Submission Failure due to Originator is on Blacklist
3.2 Scenarios Relevant to Prepaid Only

This section describes call flows relating to the following scenarios relevant for prepaid billing
only:
1. Submission of an SM where the subscriber has insufficient funds.
2. Submission of an SM with additional service where there are insufficient funds.
3. SMSC – the prepaid system interface is jammed.
3.2.1 Insufficient Funds
Failure of an SM submission resulting from insufficient funds is illustrated in Figure 3-8. The
events are the following:
1. Submission of an SM from a mobile device.
2. SPBP primary service debit request for submission of an SM.
3. SPBP primary service acknowledgement indicating that the request failed due to
insufficient funds.
4. SMSC return submission failure to a mobile device.

1. Submit SM
Prepaid
SMSC
SM accepted by SMSC System
3. SPBP prim_ack (not_creditable)
4. Submission Failure
Figure 3-8: Call Flow – SM Submission Failure due to Insufficient Funds
3.2.2 Additional Service with Insufficient Funds
Submission of an SM including an additional service (e.g. generation of a notification/status

report) where there are insufficient funds for the additional service is illustrated in Figure 3-9.
Failure of an additional service because of insufficient funds will not affect delivery of the
original SMs since these are charged separately. Please note that the charge for the
additional service may be applied to the recipient rather than the originator of the SM.
The events are the following:

1. Submission of an SM from a mobile device.
2. SPBP primary service debit request for the submission of an SM.
3. SPBP primary service acknowledgement indicating successful debit request.
4. SMSC generates a CDR confirming submission of an SM.
7. SPBP additional service debit request for additional service, e.g. delivery
notification/status report.
8. SPBP additional service acknowledgement indicating failure of debit request because of
insufficient funds.

1. Submit SM
4. CDR (4)
Prepaid
SMSC
5. SM Delivery System
6. CDR (0)
8. SPBP add_service (not_creditable)
Figure 3-9: Call Flow – Additional Service Failure due to Insufficient Funds
3.2.3 SMSC – Prepaid System Interface Jammed
In the event of the SMSC – a prepaid system interface being jammed on receipt of an SM
from a mobile device, the SMSC can be configured to behave in three possible ways
depending on the setting of the /PP_JAMMED_SETTING attribute in class SMSC (see Table
4-2):
1. Accept an SM and generate a CDR (4) to signify submission of the SM to the SMSC. The
SM will be delivered as normal (/PP_JAMMED_SETTING = SMS_FREE).
2. Reject the SM (/PP_JAMMED_SETTING = SMS_REJECT).
3. Check in the prepaid cache for the status or creditability of the subscriber
(/PP_JAMMED_SETTING = SMS_FREE_USE_BLOCKED).

4 Prepaid Billing Configuration
The prepaid billing model has already been described in Chapter 2 and the possible prepaid
billing events have been detailed in Chapter 3. This chapter focuses on configuration issues
for prepaid billing.
4.1 Prepaid Billing Large Account Configuration

In this section Large Account (LA) specific configuration issues regarding prepaid billing are
presented.
• The attribute MO_PP_CHARGING determines per LA what the charging characteristics
are for prepaid users in the MO-LA traffic. The attribute can be set to:
− MOBILE_CHARGED (default) when the prepaid user is the charged party and the SM
is not free.
− MOBILE_FREE when the prepaid user is the charged party and the SM is free.
− LARGE_ACCOUNT when the LA is the charged party and the SM is charged via the
postpaid billing.
• The attribute MT_PP_CHARGING determines per LA what the charging characteristics
are for prepaid users in the LA-MT traffic. The attribute can be set to:
− MOBILE_CHARGED when the prepaid user is the charged party and the SM is not
free.
− MOBILE_FREE when the prepaid user is the charged party and the SM is free.
− LARGE_ACCOUNT (default) when the LA is the charged party and the SM is charged
via the postpaid billing.
Both LA attributes are available via PRL (qualifiers /MO_PP_CHARGING and

/MT_PP_CHARGING) and PRX (via the LA screen under ‘More Attributes’).
4.2 Prepaid Billing O&M Configuration

In this section the O&M configuration issues regarding the prepaid billing are presented.
Table 4-1, Table 4-2, Table 4-3 and Table 4-4 provide details on the most relevant O&M
attributes from SMSC classes PBR_COMMON, SMSC, SMH_COMMON and SSD
respectively. Please refer to the SMSC Command Reference Manual [SRF] for a description
of all related prepaid O&M attributes.
Table 4-1: PBR_COMMON Attributes
PBR_COMMON Attributes
Attribute Description Value
MAX_TRANS_PER_SEC The maximum number of transactions that each PBR Integer;

process will handle per second. [0 … .4,294,836,225];
Default = 1.000

PBR_COMMON Attributes
SPBP_OPT_FIELDS_ This attribute is used to specify which of the optional Bit mask;
MASK protocol fields are included by the SMSC in the transaction [0x0 … .0xFFF FFFF];
records. The bits of this field correspond to the following Default = 0x0
optional fields (bit 0 is the least significant bit):
0: sessssionErrorTxt
1: transErrorTxt
2: otherLAShortNumber
3: singleShot
4: billingField
5: primServiceTime
6: chargedGlobalTitle
7: messageOrigAddress
8: originalRecipient
9: teleserviceID
10: otherGlobalTitle
11: otherPointCode
12: otherIMSI
13: chargedGlobalTitle
14: chargedPointCode
15: chargedAddrGroup
16: otherAddrGroup
17: NetwType
18: servicePrice
19: localRegistration
20: smppBillingIdentifier
21: origMsgID
22: payloadInfo
23: consolidation
Please refer to [SPBP] for the interpretation of these fields.
USE_CACHE This attribute is used by the SMSC to determine whether Flag; YES or NO;
to remember the latest blocking status of prepaid users or Default = NO
not. If it is set to “YES”, a cache will be created and used
when the connection to the prepaid system is down. If
“NO”, then no cache will be created.
CACHE_SIZE This attribute defines the size of the local prepaid user Integer;
cache. [100…20,000,000];
Default= 10,000,000
CACHE_TO_FILE This attribute determines whether the prepaid cache is Flag; YES or NO;
mapped onto a file or not. Default = YES
PP_CM_INCLUDED This attribute is used to specify whether CM information is Flag; YES or NO;
included in the billing information sent to the prepaid Default = YES
system.
PP_EMS_INCLUDED This attribute is used to specify whether Enhanced Flag; YES or NO;
Message Service Information is included in the billing Default = YES
information sent to the prepaid system.
PP_APA_INCLUDED This attribute is used to specify whether APA Information Flag; YES or NO;
is included in the billing information sent to the prepaid Default = YES
system.
PRES_ADDR_ENABLED This attribute is used to specify whether the presentation Flag; YES or NO;
address (given by ADT) should be used in prepaid primary Default = YES
service charging requests.
UNTR_ADDR_ENABLED This attribute is used to specify whether the untranslated Flag; YES or NO;
address (given by ADT) should be used in prepaid primary Default = YES
service charging requests.

Table 4-2: SMSC Attributes
SMSC Attributes
PREPAID_SMS_ENABLED Indicates whether the prepaid functionality is enabled or Flag; ON or OFF;

not. Default = OFF
PP_SUPPORTED_SPBP_ This attribute is used to specify which transaction types Bit mask;
MSGS are generated by the SMSC. The bits of this field [0x0 … 0xFFFF FFF];
correspond to the following transaction types (0 is the Default = 0xFFF FFFF
least significant bit):
0: Support Credit for CHARGED Primary Services
1: Support Debit and Credit for FREE Primary Services
2: Not applicable
3: Support Credit for CHARGED Notifications
4: Support Debit and Credit for FREE Notifications
5: Support Credit for other CHARGED Additional
Services
6: Support Debit and Credit for other FREE Additional
Services
7: Support Delivery for CHARGED Primary Services
8: Support Delivery for FREE Primary Services
9: Support Delivery for CHARGED Primary Services
10: Support Delivery for CHARGED Notifications
11: Support Delivery for FREE Additional Services
12: Support Delivery for FREE Notifications
PP_SUPPORTED_ADD_ This attribute is used to specify which Additional Service Bit mask;
SER transaction records are supported by the SMSC. The [0x0 … 0xFFF FFF];
bits of this field correspond to the following services (0 is Default = 0xFFF FFFFF
the least significant bit):
0: Notifications
1: Forwarding
2: Last Resort Addressing
3: Provisioning
4: Reply Path
5: SMS Commands
6: Forwarding to a Unified mailbox
PP_MOMT_CHARGING This attribute is used to specify whether the originator or Flag;

the recipient is the charged party in prepaid MO-MT [ORIGINATOR_FREE,
traffic and whether this Primary Service is free or not. ORIGINATOR_CHARGED
, RECIPIENT_FREE,
RECIPIENT_CHARGED,
BOTH_CHARGED];
Default =
ORIGINATOR_CHARGED
.
PP_MOFIX_CHARGING This attribute is used to specify whether the originator or Flag;
the recipient is the charged party in the prepaid MO-FIX [ORIGINATOR_FREE,
(non-LA) traffic and whether this type of the traffic is free ORIGINATOR_CHARGED
or not. , RECIPIENT];
Default =
ORIGINATOR_CHARGED
.
PP_FIXMT_CHARGING This attribute is used to specify whether the originator or Flag; [ORIGINATOR,
the recipient is the charged party in the prepaid FIX RECIPIENT_CHARGED,
(non-LA)-MT traffic and whether this type of the traffic is RECIPIENT_FREE];
free or not. Default = ORIGINATOR.
PP_NOTIF_SETTING This attribute is used to specify whether requested Flag; [FREE, CHARGED,
Notifications or Status Reports by prepaid users are IGNORED];
free, charged or whether these requests are ignored Default = CHARGED.
altogether.

SMSC Attributes
PP_JAMMED_SETTING This attribute is used to specify the behaviour of the Flag; [SMS_REJECT,
SMSC when the SPBP interface is jammed. This SMS_FREE_USE_BLOCK
behaviour can be either: all prepaid messages are ED, SMS_FREE];
rejected; all prepaid messages are free but the last Default =
known blocking status is used to accept or reject them; SMS_FREE_USE_BLOCK
all prepaid messages are free regardless of the last ED.
known blocking status. If the PP_FIXED_BILLING
attribute has been set to PRE_AND_POSTPAID, the
generated submission and/or delivery CDR will contain
information about the JAMMED event.
PP_MODE This attribute is used to specify the operational mode of Flag; [BULK, HOT,
the SMSC for the prepaid traffic. It can only be set to REAL_TIME];
BULK when the related attribute Default = REAL_TIME.
PP_SMS_BULK_ENABLED is set to ON.
PP_SMS_BULK_ENABLED This attribute is used to specify whether SMS Prepaid Flag; ON or OFF;
bulk functionality is supported by the SMSC. Default = OFF
Table 4-3: SMH_COMMON Attributes
SMH_COMMON Attributes
PP_FIXED_BILLING This attribute is used to specify the SMSC logging behaviour Flag;
with respect to prepaid messages: messages charged to PRE_AND_POSTPAID,
pre- and postpaid users are logged, messages charged to POSTPAID_ONLY,
prepaid users only are logged or messages charged to PREPAID_ONLY;
postpaid users only are logged. Default =
POSTPAID_ONLY.
PP_PB_TIMEOUT This attribute is used to specify the timeout value (in Integer; [0…3600];
seconds) for the prepaid system response to an earlier Default = 1
transaction. A value of ‘0’ means that the SMSC will wait
infinitely for the response to arrive.
PP_PB_TIMEOUT_TI This attribute is used to specify how often the SMH checks Integer; [1-3600],
CK whether messages waiting for a prepaid system response Default = 1
have timed out.
ABN_ENABLED This attribute is used to specify whether the Account Flag; ON or OFF;
Balance Notification message functionality is supported by Default = OFF
the SMSC.
PP_REJECT_NO_RNI This attribute is used to specify that a submitted prepaid Flag: YES or NO;
message will be rejected because the Recipient Number Default = NO
Information (RNI) could not be retrieved during submission.
Table 4-4: SSD_COMMON Attributes
SSD _COMMON Attributes
MAX_PP_USERS This attribute is used to specify the maximum number Integer;

of prepaid users that the SSD will hold in memory. [0…20,000,000];
Default = 0
MSG_RULES_PP_ENABLED This attribute is used to specify that Prepaid users will Flag: ON or OFF;
be determined by rules in the Default = OFF
SSD_MSG_RULES.CNF file for the Rule Based
Decision Logic (RBDL).

4.3 Miscellaneous Prepaid Billing Configuration
This section presents the remaining configuration issues regarding the prepaid billing.
By default, the SMSC Subscriber Database does not contain tables for storing prepaid
subscriber data. In order to allocate storage space for prepaid subscriber data, the script
SMSC$ROOT:[SCRIPTS]SDB_CREATE_PREPAID should be executed.
For the configuration of the SMSC prepaid solution, the logical name specified in Table 4-5
should be defined. The definition should also be present in the file
SMSC$ROOT:[SCRIPTS]SMSC_COMMON.COM. The value can be modified by running this script on
each backend node and restarting the PBR entities.
Table 4-5: Relevant Prepaid Logical Name
Logical Description Value
PBR_CACHE_DIR This parameter determines the location of the prepaid String; VMS directory name;
user cache. Default = SMSC$ROOT:[DATA]
4.4 PID/TON/NPI Mapping

The range of values specified for the PID/TON/NPI set of values in the SMS Prepaid Billing
Protocol (SPBP) interface is different from the range of values defined in the internal Data
Interface (IDI) supported by the SMSC.
The Prepaid Billing Router (PBR) entity maps IDI values to SPBP values. If no
corresponding value for a PID/TON/NPI value is found in the SPBP, the “Unspecified” value
(12/7/7) is used.
See the SPBP documentation.

5 Postpaid Billing Configuration
This chapter describes configuration for postpaid billing. Section 5.1 provides information
about the naming and location of billing files. Section 5.2 describes the LOGSRV O&M
attributes. Section 5.3 details filtering of log requests. Finally, Section 5.5 describes CDR
format customisation.
5.1 Naming and Location of Billing Files

Billing files are generated by the LOGSRV and CMLOG entities. The billing files created by
LOGSRV contain CDRs for services that required one single SM. The billing files created by
CMLOG contain summary CDRs for services that required CMs.
5.1.1 LOGSRV Billing Files
The names of the billing files created by the LOGSRV have the following syntax:
LOGSRV<xx>_<yyy>_FILE.<nnnn>
Where:
<xx> is the two-digit identification of the LOGSRV entity.

<yyy> equals “CDR” or “FRP”.
<nnnn> is a four-digit sequence number modulo 10000.
The LOGSRV filename syntax shows two different types:
• “CDR”: Billing files containing Call Detail Records for Short Message, Notification,
Command and Concatenated Messages.
• “FRP”: Billing files containing Call Detail Records for Fax Reports (Toll Ticketing only)
The locations of the LOGSRV billing files are determined by the logical names
LOGSRV<xx>_<yyy>_PATH. These logical names should be defined in the
SMSC$ROOT:[SCRIPTS]SMSC_COMMON.COM file.
5.1.2 Additional LOGSRV Billing Files
When the additional ASN.1 CDR files are used (meaning that SMSC_COMMON class
attribute /NR_EXTRA_CDR_STREAMS has a value greater than 0), the names of the
corresponding billing files created by the LOGSRV have the following syntax:
LOGSRV<xx>_ CDR_FILE_<yy>.<nnnn>
Where:
<xx> is the identification of the LOGSRV entity.

<yy> equals to either the number of the stream (default) or a user predefined infix of
maximum five-digit sequence.
The infixes of the additional billing files are determined by the logical names
LOGSRV<xx>_CDR_<yy>_NAME. These logical names should be defined in the

The locations of the LOGSRV additional billing files are determined by the logical names
LOGSRV<xx>_CDR_<yy>_PATH. These logical names should be defined in the
5.1.3 CMLOG Billing Files
The names of the billing files created by the CMLOG entity have the following syntax:
CMLOG<xx>_CDR_SUM_FILE.<nnnn>
Where:
<xx> is the two-digit identification of the CMLOG entity.

The locations of the CMLOG billing files are determined by the logical names
CMLOG<xx>_CDR_SUM_PATH. These logical names should be defined in the
5.1.4 Additional CMLOG Billing Files
When the additional ASN.1 CDR files are used (meaning that SMSC_COMMON class
attribute /NR_EXTRA_CDR_STREAMS has a value greater than 0), the names of the
corresponding billing files created by the CMLOG have the following syntax:
CMLOG<xx>_CDR_ SUM_FILE_<yy>.<nnnn>
Where:
<xx> is the identification of the CMLOG entity.

<yy> equals to either the number of the stream (default) or a user predefined infix of
maximum five-digit sequence.
The infixes of the additional billing files are determined by the logical names
CMLOG<xx>_CDR_SUM_<yy>_NAME. These logical names should be defined in the
The locations of the CMLOG additional billing files are determined by the logical names
CMLOG<xx>_CDR_SUM_<yy>_PATH. These logical names should be defined in the
5.1.5 CMLOG State File
The CMLOG entity maintains a state file so that, when stopped and restarted, no information
is lost. Two state files are maintained; one for the current summary state of each CM and
one with extended object data.
The location of the first state file is determined by the logical name:
CMLOG<xx>_BACKUP_CONTEXT_PATH
The location of the second state file is determined by the logical name:
CMLOG<xx>_BACKUP_EO_HEADER_PATH

Where:
<xx> is the two-digit identification of the CMLOG entity.
These logical names should be defined in the SMSC$ROOT:[SCRIPTS]SMSC_COMMON.COM file.
5.1.6 CMLOG – LOGSRV Interface File
The LOGSRV provides the CMLOG with CM segment information. CM segments are usually
handled by different LOGSRV entities. In order to create CM summary CDRs, all segment
information of one CM must be handled by the same CMLOG entity. Therefore, all LOGSRV
entities provide segment information belonging to the same CM and the same CMLOG
entity. This means that each LOGSRV entity has its own interface file for each CMLOG
entity. The number of interface files is the number of LOGSRV entities multiplied by the
number of CMLOG entities.
The names of the interface files have the following syntax:
CMLOG<xx>_<yyyyyyyy>_CM_FILE.<nnnn>
Where:
<xx> is the two-digit identification of the CMLOG entity that should handle this file.
<yyyyyyyy> is the eight-digit identification of the LOGSRV entity that created the file.
The location of the interface files is determined by the logical name CMLOG<xx>_LOG_CM_PATH.
This logical name should also be defined in the SMSC$ROOT:[SCRIPTS]SMSC_COMMON.COM file.
5.1.7 Availability of Billing Files
An active LOGSRV or CMLOG entity is always accompanied with an active as well as a

standby-billing file. The standby file must be able to continue writing billing records while the
active file is being closed. When this active file is closed, another standby file is opened
while the current standby file becomes the active file. The standby-billing file has the same
name as the active file but with the sequence number increased by one.
The following is an example of a closed, active and standby (LOGSRV) billing file:
- LOGSRV03_CDR_FILE.0314 (closed)
- LOGSRV03_CDR_FILE.0315 (active)
- LOGSRV03_CDR_FILE.0316 (standby)
Note that only the closed files are available for post processing.
5.1.8 Redefining Location Billing Files
An LOGSRV or CMLOG entity may be BLOCKED due to a full storage disk. If the storage
disk is full, it is possible to redefine the location of the billing files whilst the entity is running.
To do this, choose a disk with enough free space and change the logical names accordingly.
If a permanent change of the location of the billing files is desired, change the definition into
SMSC_COMMON.COM as well. As soon as this is done the entity will become ACTIVE
again and will write the billing files to the new location.

5.1.9 Removing Billing Files
It is the operator’s responsibility to remove the billing files since they are not automatically
removed by the SMSC. Post processing of billing files is covered in Chapter 8.
5.2 Operations and Maintenance (O&M)

This section describes the most relevant O&M attributes and logical names regarding
postpaid billing. Please refer to the SMSC Command Reference Manual [SRF] for a
description of all related postpaid O&M attributes. The O&M attributes are specified in the
following tables:
• Table 5-1: LOGSRV_COMMON Attributes
• Table 5-2: LOGSRV Attributes
• Table 5-3: SMSC Attributes
• Table 5-4: SMH_COMMON Attributes
• Table 5-5: Logical Names for configuring ASN.1 CDR Fields
• Table 5-6: CMLOG_COMMON Attributes
The file contains descriptions of all LOGSRV errors,

SMSC$ROOT:[SRCREF]LOGSRV_MESG.MSG
warnings and informational messages that can appear in PML.
Table 5-1: LOGSRV_COMMON Attributes
LOGSRV_COMMON Attributes
MAX_CDR_ITEMS Number used to calculate the size of the LOGSRV_CDR Integer; [1 … 1,000,000];
files based on the maximum size of CDR records. Default = 10,000
MAX_CDR_ITEMS_ Number used to calculate the size of the LOGSRV_CDR Integer; [1 … 1,000,000];
<N> with files based on the maximum size of CDR records. Default = 10,000
N=1..10
N corresponds to the additional LOGSRV file. Refer to
section 5.1.2
LOG_SLEEP_ Time in seconds after which the LOGSRV tries to open a Integer; [1 … 60];
PERIOD new LOGSRV file in case of previous failure. Default = 5
CDR_FORMAT Format of the billing output. Flag; [TT, ASN1,NONE];

Default = ASN1
SILA_SHORTNUM_ Used for identifying a SILA by its Short Number (ON) instead Flag; [OFF/ON];
ENABLED of the network address (OFF). This applies to the following Default=OFF
fields:
• RecipAddress,
• RecipAddressGSM)
• CallingLineId
• CallingLineIDGSM
• Notifaddress
• NotifAddressGSM
• OrglRecipAddress
• OrglRecipAddressGSM
• OrglNotifAddress
• OrglNotifAddressGSM

SMS_CONTENT_ This attribute is associated with license Flag: [OFF/ON];

ENABLED SMSC_SMS_LOGGING_ENABLED which controls the Default=OFF
logging of SMS contents and Data Coding Scheme (DCS) to
the CDR. The following fields in the configuration file
FCDR_FIELDS.CNF should be enabled:
CallDetailRecord.smsContent=ON
callDetailRecord.smsContentDcs=ON
The smsContent field enables the logging of the SM to the

CDR. The smsContentDcs field enables the logging of the
DCS used for this SM.
MAX_CM_LOG_ Used to specify the maximum number of CMLOG records Integer; [1…10,000]];
ITEMS that can be stored in a single CMLOG file. The CMLOG file is Default = 1,000
used by LOGSRV entities to transport data to CMLOG
entities. The value of this attribute is used to calculate the
maximum CMLOG file size.
CM_LOG_TIME Used to specify the time in seconds the intermediate Integer; [60…600];
CMLOG file is kept open by LOGSRV before it starts writing Default = 60
to a new file. The CMLOG file is used by the CMLOG entity
to create CM summary files.
TT_CLI Determines whether an additional CLI field is added to the Flag; [OFF/ON];
Toll Ticketing Call Detail Record. When this attribute is set to Default=OFF
ON, an additional CLI field is added to the Toll Ticketing Call
Detail Record.
ROUT_ADDR_IN_ The ROUT_ADDR_IN_RECIP attribute determines whether in Flag; [OFF/ON];

RECIP case of a RARR scenario, the routed address should be Default=OFF
encoded into the fields:
• RecipAddress
• RecipAddressGSM
• OrglRecipAddress
• OrglRecipAddressGSM
If this attribute is ON and an SM is routed via RARR to an
LA, the field recipAltAddress is left empty. This attribute
is overruled by the LOGSRV_COMMON attribute
TRANSL_RECIP_ADDR.
TRANSL_RECIP_ The TRANSL_RECIP_ADDR attribute enables the SMSC to Flag: [OFF/ON];

ADDR encode the translated original recipient address into the Default=OFF
RecipAddress and RecipAddressGSM fields. The
translated original recipient address is the original recipient
address with normalised TON/NPI combinations after the
SMSC number recognition. Examples of recognized
numbers are: Short Numbers, Local Numbers, Prefixless
Numbers and Numbers with a carrier select prefix.
The presentation of the translated original recipient address

in the CDR record depends on the SMSC_COMMON
attribute LOG_INTL_ADDR_ENABLED. If this attribute is ON
and an SM is routed via RARR to an LA, the short number of
this LA is encoded into the field recipAltAddress.
NOTE: It is not recommended to enable this attribute

together with the Statistical Configuration Option
SMSC46_LOGSRV_LOG_OMRD_IN_2ADR. This will cause the
SMSC to encode the untranslated original recipient into the
RecipAddress and RecipAddressGSM fields.

PRES_ADDR_ The PRES_ADDR_ENABLED attribute is used to specify Flag: [OFF/ON];

ENABLED whether the presentation address, provided by Address Default=ON
Translation (ADT) [OMAN], should be used for encoding
address fields. When this attribute is set to ON and ADT is
enabled, the address fields origAddress,
origAddressGSM, recipAddress, recipAddressGSM,
orglOrigAddress, orglOrigAddressGSM,
orglRecipAddress and orglRecipAddressGSM contain
the presentation form of the (original) originating and
(original) destination address.
In case one of the above address fields cannot be encoded

because the presentation address does not comply with
Table 6-1: ASN.1 Definition, the field is encoded according
the setting TRANSL_RECIP_ADDR is ON. If either the Type
of Number (TON) value of the presentation address is
outside the range [0 … 7] or the Numbering Plan Indicator
(NPI) value of the presentation address is outside the range
(0...15), the appropriate part of origAddressGSM,
recipAddressGSM, orglOrigAddressGSM and
orglRecipAddressGSM is set to zero.
The PRES_ADDR_ENABLED attribute overrules the attribute

TRANSL_RECIP_ADDR.
The SMSC can be configured to use a Short Number instead of a network address for the
Single Address Large Account (SILA) identification and to log the SM content in the CDR as
described in Table 5-1.
The storage of the SMS content is a licensed option. It is the operator’s responsibility to
ensure that the storage of the SMS content does not contravene any privacy legislation.
The size of the LOGSRV billing files depends on the value of the MAX_CDR_ITEMS attribute
(Table 5-1). For performance reasons, billing records are written to the LOGSRV files in
quantities of 127 blocks. The file size is rounded to the nearest complete buffer size.
A LOGSRV file may contain less than MAX_CDR_ITEMS records, if it has been closed due to an
expired file timer. A LOGSRV file may contain more than MAX_CDR_ITEMS records due to the
rounding.
If the standby LOGSRV files cannot be opened, for instance, when there is no disk space,
the LOGSRV entity will try to reopen a standby file after a time period controlled by the
LOG_SLEEP_PERIOD attribute (Table 5-1). If the problem is unresolved before the current active
file is closed, the LOGSRV will go into the blocked state. During the BLOCKED state, the
LOGSRV will periodically continue to try to open a new file.
Table 5-2: LOGSRV Attributes
CDR_TIME Time in seconds during which a LOGSRV_CDR file will be kept open. If the Integer; [30 …
86,400];
value is changed, the LOGSRV will close the LOGSRV_CDR file.
Default = 3.600
CDR_TIME_< Time in seconds during which a LOGSRV_CDR file will be kept open. If the
N> with value is changed, the LOGSRV will close the LOGSRV_CDR file. N>
N=1..10 corresponds to the additional LOGSRV file. Refer to section 5.1.2
FLUSH_TIME Time in seconds after which the buffered billing records are flushed to the Integer; [1 …
LOGSRV_CDR file. FLUSH_TIME should be less than CDR_TIME. 3,600];
Default = 60

A LOGSRV entity is forced to close the active LOGSRV file when the CDR_TIME attribute
(Table 5-2) is set. A standby LOGSRV file is created after the file is released.
The time consuming disk access can be limited using the FLUSH_TIME attribute. This attribute
determines the frequency of LOGSRV writes from the memory to LOGSRV files.
FLUSH_TIME overrules the LOGSRV_COMMON FLUSH_CDR_REQ attribute. A LOGSRV entity
can be forced to flush out all buffered log requests to the disk by setting the FLUSH_TIME
attribute.
On each back-end node at least one LOGSRV entity should be running.
When a LOGSRV entity is BLOCKED and no other LOGSRV is available, all log requests
will be lost. When a LOGSRV (or the node on which one or more LOG servers are running)
crashes, all log requests buffered by the LOG servers or by the SMSC internal queuing
mechanism are lost.
Table 5-3: SMSC Attributes
SMSC Attributes
Attribute name Description Value
SMSC_LOGGING_MASK Determines which LOG requests are to be sent to the LOGSRV. Integer;
Refer to the SMSC Command Reference Manual [SRF] for a bitmask
description of individual bits in the bitmask. given as a
hexadecimal
number
CM_CDR_SUMMARY Controls the summary Call Detail Record (CDR) generation mode Flag; OFF,
for CM segments. If set to OFF, no CM summary CDRs are ON, ONLY
generated, only CDRs per CM segment. If set to ONLY, only CM Default = ON
summary CDRs are generated, no CDRs per CM segment. If set to
ON, CM summary CDRs and CDRs per CM segment are generated.
This attribute can only be set when all CMLOG- and LOGSRV-
entities are stopped.
NR_CMLOG Used to specify the configured number of CMLOG entities in the Integer;
system. [1…20];
Default = 1
CDR_CM_ Used to specify whether Concatenated Message information is Flag; YES,

INCLUDED included in the generated CDRs and CM summary CDRs. If set to NO; Default =
YES, CM information is included. If set to NO, the CM information is YES
not included.
CDR_EMS_ Used to specify whether Enhanced Messaging Service information Flag; YES,
INCLUDED is included in the generated CDRs and CM summary CDRs. If set to NO Default =
YES, EMS information is included. If set to NO, the EMS information YES
is not included.
CDR_APA_ Used to specify whether Application Port Address information is Flag: YES,
INCLUDED included in the generated CDRs and CM summary CDRs. If set to NO Default =
YES, APA information is included. If set to NO, the APA information YES
is not included.
NR_EXTRA_CDR_ Used to specify the number of additional CDR streams. [0…10];

STREAMS Default = 0

SMSC Attributes
CDR_STREAMS_TYPE_ Bit-mask specifying the type of the additional ASN.1 CDR streams.
MASK An additional ASN.1 CDR stream can be configured as billing
stream (set to 0) or statistical stream (set to 1). The bit positions
correspond to the stream numbers (1...10) of the additional streams
(bit 0 is the least significant bit and corresponds to additional stream
number 1).
For a stream configured as a statistical stream, all CDR formatting

options specified in Table 5-1, Table 5-3 and Table 5-5 do not apply.
Instead, the following rules apply:
• Large Accounts are identified by their LA Short Number
• The recipAddress(GSM) field contains the original recipient
address before any Recipient Address Range Routing (RARR)
rule or Rule Based Logic (RBL) rule is applied.
• In case of LA originated traffic, the origAddress(GSM) field
contains the LA provided source address.
• The following address fields are represented in international
format: origAddress(GSM), recipAddress(GSM),
notifAddress(GSM), ogtiAddress(GSM),
dgtiAddress(GSM), callingLineId(GSM),
orglOrigAddress(GSM), orglRecipAddress(GSM),
orglNotifAddress(GSM), orglOgtiAddress(GSM),
faxOrigAddress and faxRecipAddress. The
TypeOfNumber field is set to international(1).
• CDRs for rejected Short Messages (SM) have the status field
set to rejected(9).
• CDRs for SMs that terminate with a permanent delivery failure
have the status field set to undeliverable(7).
LOG_INTL_ADDR_ Used to specify whether the logging and billing of addresses will be Flag; ON ,
ENABLED in the international format. This setting applies to the following OFF
ASN.1 billing records: Default = OFF
• CallDetailRecord
• CommandRecord
• NotificationRecord
• AlertRecord
• FaxReportRecord
• FailedLoginRecord
If set to YES, the following addresses will be logged and billed in the
international format:
• OrigAddress
• OrigAddressGSM
• RecipAddress
• RecipAddressGSM
• NotifAddress
• NotifAddressGSM
• CallingLineIdAddress
• CallingLineIdAddressGSM
• OgtiAddress
• OgtiAddressGSM
• DgtiAddress
• DgtiAddressGSM
• OrglOgtiAddress
• OrglOgtiAddressGSM
• FaxOrigAddress
• FaxRecipAddress
NOTE: Physical addresses with a TON different from NATIONAL or
INTERNATIONAL or short numbers are not affected by this attribute.

SMSC Attributes
DELLOG_ENUM_LASN Used to specify whether the submission record will contain Flag: ON,
information from the ENUM_BEFORE query result if Delayed OFF Default =
Submission Logging is used together with the ENUM number OFF
mapping.
Table 5-4: SMH_COMMON Attributes
SMSC Attributes
PRE_CATCHALL_MSTA Defines the value of the Message Status (MSTA) in billing Parameter;
and statistical records for the last Intermediate Delivery [PERMANENT,
Attempt to a mobile network when the Catchall Routing INTERMEDIATE,
feature applies. CATCHALL];
Default = PERMANENT
Table 5-5: Logical Names for configuring ASN.1 CDR Fields
Logical Names for configuring ASN.1 CDR Fields
Logical Name Description
SMSC46_ASN1_ When the LA provided source address is Alphanumeric and this logical name is set to
ALPHA2LASN YES, the address digits of the fields OrigAddress, OrigAddressGSM,
OrglOrigAddress and OrglOrigAddressGSM will contain the LA Short Number with
TON = Short(4).
The default behaviour for this traffic scenario is that the address digits of the fields
OrigAddress and OrglOrigAddress will be empty with TON = Alpha(5). The
address digits of the fields OrigAddressGSM and OrglOrigAddressGSM will contain
the Alphanumeric LA provided source address. This logical name is overruled by the
logical names SMSC46_SILA_ALPHA2NETWORK,
SMSC_LA_ADDRESS_IN_NOTIF_ORGLORIG and
SMSC45_LOGSRV_MULA_SN_IN_MOAD.
SMSC46_TT_ When the LA provided source address is Alphanumeric and this logical name is set to
ALPHA2LASN YES, the Toll Ticketing field A-subscriber will contain the LASN. The default behaviour
for this traffic scenario is that the field A-Subscriber contains the Alphanumeric LA
provided source address.
SMSC45_LOGSRV_ When the originator is a MULA and this logical name is defined to YES, the address
MULA_SN_IN_MOAD digits of the fields OrigAddress, OrigAddressGSM, OrglOrigAddress and
OrglOrigAddressGSM will contain the MULA Short Number with TON = Short(4). The
default behaviour for this traffic scenario is that these fields contain the MULA provided
source address.
SMSC_LA_ADDRESS When the requestor of the Notification is an LA and this logical name is set to YES, the
_IN_NOTIF_ address digits of the fields OrglOrigAddress and OrglOrigAddressGSM will contain
ORGLORIG the LA address. Note that the presentation of the LA address depends on the nature of
the LA (MULA or SILA) and the value of the O&M SILA_SHORTNUM_ENABLED attribute
of class LOGSRV_COMMON. The default behaviour for this traffic scenario is that these
fields contain the LA provided source address.
SMSC46_SILA_ When the SILA provided source address is Alphanumeric and this logical name is set to
ALPHA2NETWORK YES, the address digits of the field OrigAddress will contain the SILA network address
with TON = Unknown(0). The default behaviour for this traffic scenario is that the
address digits of this field are empty with TON = Short(4). This logical name overrules
the logical name SMSC46_ASN1_ALPHA2LASN.
SMSC35_2ADDR_ When a Mobile user submits a message using a Private Virtual SMSC and this logical
BILLING name is set to any non-empty value, the fields RecipAddress and RecipaddressGSM
will contain the original recipient address as it was provided by the Mobile User.
When a message is routed via RARR and this logical name is set to any non-empty

Logical Names for configuring ASN.1 CDR Fields
Logical Name Description
value, the field RecipAddress will contain the original recipient address with the PID
value replaced by the PID value of the application to which the message was routed.
The field RecipAddressGSM will contain the original recipient address. This logical
name is overruled by the O&M attribute setting LOGSRV_COMMON
/TRANSL_RECIP_ADDR = ON.
SMSC46_CDR_ When this logical name is set to ON, the following adapted definition applies for the
SMSC40_ ASN.1 Call Detail Record:
COMPATIBLE SmsContents [48] SMS-STRING OPTIONAL,
smsContentDcs [49] VisibleString OPTIONAL,
messageReference [69] MsgRef OPTIONAL
lmsgNrSeg [70] LmsgNumseg OPTIONAL,
In this case, the corresponding ASN.1 tag values are:

SmsContents 9F 30
smsContentDcs 9F 31
MessageReference 9F 45
lmsgNrSeg 9F 46
The default definition is:

SmsContents [49] SMS-STRING OPTIONAL,
messageReference [70] MsgRef OPTIONAL
The corresponding default ASN.1 tag values are:

SmsContents 9F 31
smsContentDcs 9F 30
MessageReference 9F 46
lmsgNrSeg 9F 45
SMSC46_LOGSRV_ When this logical name is set to YES, ON or TRUE, the SMSC internal status “persistent
STATUS_ delivery error” will be mapped on the ASN.1 status ‘undeliverable’. By default, this
UNDELIVERABLE internal status is mapped on ‘deleted’. Please refer to Table 6-1.
SMSC46_LOGSRV_ When this logical name is set to NO, OFF or FALSE, the SMSC internal status “Message
STATUS_PP_ Not Accepted” will be mapped on the ASN.1 status ‘2’ (deleted). By default, this internal
REJECTED status is mapped on value ‘9’ (rejected). Please refer to Table 6-1.
Table 5-6: CMLOG_COMMON Attributes
CMLOG_COMMON Attributes
CM_SUBMIT_INTERVAL Used to specify the submit time interval in minutes. This Integer; [1…60] ;
interval multiplied with the number of segments of a Default = 1
Concatenated Message gives the maximum interval after
which a CM submission summary CDR is generated,
independently of whether or not all segments are received by
a CMLOG entity. The timer starts after receipt of the first
segment by CMLOG.
CM_DELIVERY_ Used to specify the delivery time interval in minutes. This Integer; [1…60];
INTERVAL interval multiplied with the number of segments of a Default = 1
Concatenated Message gives the maximum interval after
which a CM delivery summary CDR is generated, regardless
of whether or not all segments have been received by a
CMLOG entity. The timer starts after first receipt of the first
segment by CMLOG.

CMLOG_COMMON Attributes
MAX_NR_CM_PER_ Used to specify the maximum number of CMs a CMLOG Integer;

CMLOG entity can handle at the same time. Each CMLOG entity [1,000…100,000];
keeps track of the status of a CM until all requested Default = 10.000
summaries are created for that CM. When a CMLOG entity
receives a request to handle a CM above the maximum, the
request will be ignored.
MAX_SUM_CDR_ITEMS Used to specify the maximum number of summary CDRs that Integer;
can be stored in a single summary CDR file. This value is [1…1,000,000];
used to calculate the maximum summary CDR file size. Default = 1.000
SUM_FLUSH_CDR_REQ Used to specify when data is flushed to the summary CDR Integer;
files in relation to the amount of summary CDRs in the [1…10.000];
CMLOG flush buffer. If SUM_FLUSH_CDR_REQ summary Default = 100
CDRs are in the buffer, the data is automatically flushed to
the summary CDR file.
WRITE_SLEEP_PERIOD Used to specify the time period, in seconds, for which the Integer; [1…60];
CMLOG entity postpones the creation of a new current Default = 5
Concatenated Message summary file. The CMLOG entity
always tries to open two summary files: the current summary
file in which the summary records are actually written and a
backup or hot standby summary file. When the current
summary file is full, the backup will become the current
summary file and a new backup summary file will be created.
When the CMLOG entity runs out of disk space and there is
no current file, that is, the CMLOG entity is unable to write
summary records to the disk, it will go to sleep for
WRITE_SLEEP_PERIOD seconds. When this time expires the
entity will try to create a new current summary file. If this fails
it will go to sleep again. If the current summary file can be
created it will try to create a new backup summary file.
READ_SLEEP_PERIOD Used to specify the time, in seconds, for which the CMLOG Integer; [5…60];
entity sleeps in case no LOG_CM file is found in the directory Default = 30
for CMLOG. After this period, CMLOG checks for new files in
the directory again. The files are put in the directory by
LOGSRV entities.
BACKUP Used to switch on or off the backup functionality. When the Flag; ON, OFF
backup is enabled, the concatenated message summary Default = ON
cache is written to disk regularly. The CM summary cache
contains all the current incomplete concatenated message
summary data.
5.3 LOG Request Filtering

The basic filtering of billing and statistical records is controlled by the SMSC_COMMON
/SMSC_LOGGING_MASK attribute. Its value is a bitmask with individual bits determining
which types of generated LOG requests are to be sent to the LOGSRV. The requests which
are filtered out by this feature never occur in the billing and/or statistical files. Refer to the
SMSC Command Reference Manual [SRF] for a description of the meaning of individual bits
in the bitmask. Before setting this attribute make sure that your logging and statistical system
is able to process all the records enabled by this feature.
5.4 IDI Filtering

It is possible to filter CDRs by the value of their Internal Data Interface (IDI) fields:
• CDRs will only be generated for billing events matching the filter conditions that can be
defined in the SMSC$ROOT:[DATA]LOGSRV_CDR_FILTER.CNF configuration file,

• CDRs in an additional CDR stream will only be generated for billing events matching the
filter conditions that can be defined in the SMSC$ROOT:[DATA]LOGSRV_CDR_<xx>_FILTER.CNF
file, where <xx> is the number of the corresponding additional stream.
For a complete list of all IDI fields that can be used for filtering, please refer to Appendix A.
Table 5-7 shows the syntax that must be used in order to define the filter conditions:
Table 5-7: IDI Filter Syntax
IDI Filter Syntax
Operator Description Operand Type
== Equal to Number
!= Not equal to Number
< Less than Number
> Greater than Number
<= Less than or equal to Number
>= Greater than or equal to Number
Eq Equal to String
Ne Not equal to String
Sw Starting with String
& Bitwise AND Bit field
! Logical NOT Condition term
AND Logical AND Condition term
OR Logical OR Condition term
The syntax for conditions follows the formats:
<IDI-field-name> <OPERATOR> <VALUE>
Acceptable substitutes for <VALUE> are the following:

• A decimal number;
• A hexadecimal number (for example, 0X01);
• A “text string”.
A combination of condition terms can be used with the help of the logicals “AND” and “OR”.
The brackets determine precedence. If no brackets are present, the evaluation of the filter
expression is done from left to right. Operators may be in lower or uppercase, while IDI field
names (for instance B_MSTA) must be in uppercase. When a “#” is encountered the rest of
the line is discarded (comment lines). An example of an IDI filter:
# Filter out submission and notification call detail records:
((B_MTYP != 17) AND (B_MTYP != 98))
For performance reasons, the number of condition terms must be limited. It is

recommended to use no more than 10 condition terms.

Please refer to Appendix A for more IDI filter examples.
5.5 CDR Format Customisation
The CDR format customisation applies to the ASN.1 format only.

The CDR format customisation enables the user to decide which records and fields should or
should not be present in the CDR. The presence of a record or field depends on its
corresponding assigned value (ON/OFF) in the configuration file
SMSC$ROOT:[DATA]FCDR_FIELDS.CNF. For the additional streams it depends on the
corresponding assigned value in the SMSC$ROOT:[DATA]FCDR_FIELDS_<xx>.CNF file, where
<xx> is the number of the corresponding additional stream. The presence of a field will
then depend on the traffic scenario – some fields are not relevant to particular traffic
scenarios – and on whether the field has a value in a particular traffic scenario. For example;
if prepaid service specific fields are set to ON, but the message involves postpaid users only,
those fields will have no value and will not appear in the CDR. Two configuration levels can
be distinguished:
• The Record Level;
• The Field Level.
On the Record Level the presence of the callDetailRecord, commandRecord,

notificationRecord and summaryRecord fields can be configured. On the Field Level, the
format of the records (the presence of the individual fields in the records) can be customised.
The following rules apply to the CDR format customisation:
• When a GSM field (e.g. recipAddressGSM) is enabled (with the corresponding value in
the configuration file set to “ON”), its GSM sub-fields TON, NPI, PID and MSISDN will get
the following values when they are disabled:
− The TON field will get value “UNKNOWN” (0x0);
− The NPI field will get value “UNKNOWN” (0x0);
− The PID field will get value “PLMN” (0x0);
− The MSISDN field will be empty.
• Some fields are only present under certain conditions. For instance, when a message is
submitted from a computer, it will not contain an originating point code and, therefore, the
origPointCode field will not be present in the corresponding CDR.
It is possible to, enable/disable someand

SummaryRecord NotificationRecord
fields in specific record types (CallDetailRecord,
CommandRecord) using sub-options. This sub-options
override global option value (ON/OFF). For example, to disable the ppPser field in the
Notification Record, specify line:
notificationRecord.ppPser=OFF
In other records, visibility of this field (ppPser) depends on global value. Third level sub-
options (example: notificationRecord.dgtiAddress.ton=ON) are not allowed and must be
replaced by (dgtiAddress.ton=ON).
Please refer to Appendix B for the configuration template file.

6 ASN.1 CDR Format
6.1 CDR Format

This chapter deals with CDRs written in the Abstract Syntax Notation One (ASN.1) format.
ASN.1 is an international standard that was initially developed as a formalism to negotiate
communication protocols for the Presentation Layer (Layer 6) of the ISO-OSI architecture.
ASN.1 records are binary encoded according to the ASN.1 Basic Encoding Rules (ASN.1-
BER). This makes ASN.1 independent of any machine or platform. Table 6-1 contains the
ASN.1 CDR definition.
Table 6-1: ASN.1 Definition
ASN.1 Definition
FCDR DEFINITIONS IMPLICIT TAGS ::=
BEGIN
CallDetailRecord ::= SEQUENCE

{
origAddress [0] AddressInformation OPTIONAL,
origAddressGSM [1] AddressString OPTIONAL,
recipAddress [2] AddressInformation OPTIONAL,
recipAddressGSM [3] AddressString OPTIONAL,
submitDate [4] Date OPTIONAL, -- adapted submit Date
submitTime [5] Time OPTIONAL, -- adapted submit Time
status [6] Status OPTIONAL,
terminDate [7] Date OPTIONAL,
terminTime [8] Time OPTIONAL,
lengthOfMessage [9] MessageLength OPTIONAL,
prioIndicator [10] IMPLICIT BOOLEAN OPTIONAL,
validityPeriod [11] Period OPTIONAL,
deferIndicator [12] IMPLICIT BOOLEAN OPTIONAL,
deferPeriod [13] Period OPTIONAL,
notifIndicator [14] IMPLICIT BOOLEAN OPTIONAL,
notifAddress [15] AddressInformation OPTIONAL,
notifAddressGSM [16] AddressString OPTIONAL,
vsmscid [17] RangeVSMSC OPTIONAL,
vsmsctype [18] TypeVSMSC OPTIONAL,
dgtiAddress [19] AddressInformation OPTIONAL,
dgtiAddressGSM [20] AddressString OPTIONAL,
destPointCode [21] C7PointCode OPTIONAL,
ogtiAddress [22] AddressInformation OPTIONAL,
ogtiAddressGSM [23] AddressString OPTIONAL,
origPointCode [24] C7PointCode OPTIONAL,
orglSubmitDate [25] Date OPTIONAL, -- original submit Date
orglSubmitTime [26] Time OPTIONAL, -- original submit Time
transparentPid [27] TransparentPid OPTIONAL,
mesgReplyPath [28] MesgReplyPath OPTIONAL,
recipIntlMobileSubId [29] IMSI OPTIONAL,
callingLineId [30] AddressInformation OPTIONAL,
callingLineIdGSM [31] AddressString OPTIONAL,
consolidation [32] VisibleString OPTIONAL,
portNumber [33] PortNumber OPTIONAL,
aser [34] AdditionalServices OPTIONAL,
mser [35] RequestedServices OPTIONAL,
nser [36] NewServices OPTIONAL,
xser [37] ExtraServices OPTIONAL,
origIntlMobileSubId [38] IMSI OPTIONAL,
billid [39] BillingIdentifier OPTIONAL,
lang [40] LanguageIndicator OPTIONAL,
cbat [41] VisibleString OPTIONAL,
ppPser [42] PrepaidPrimSer OPTIONAL,

ppAser [43] PrepaidAddSer OPTIONAL,
ppAserDuringJam [44] PrepaidAddSer OPTIONAL,
ppAserFree [45] PrepaidAddSer OPTIONAL,
reserved46 [46] PrepaidAddSer OPTIONAL,
smeReference [47] SmeReference OPTIONAL,
smsContents [49] SMS-STRING OPTIONAL,
cmReferenceNr [50] CmReference OPTIONAL,
currentSegment [51] CmNumber OPTIONAL,
segmentsTotal [52] CmNumber OPTIONAL,
textFormatting [53] EmsBitString OPTIONAL,
bytesCompressedData [54] EmsBytesCompressed OPTIONAL,
predefinedAnimations [55] EmsNumber OPTIONAL,
userDefinedAnimations [56] EmsNumber OPTIONAL,
predefinedSounds [57] EmsNumber OPTIONAL,
userDefinedSounds [58] EmsNumber OPTIONAL,
blackWhitePictures [59] EmsNumber OPTIONAL,
standardWvg [60] EmsNumber OPTIONAL,
characterSizeWvg [61] EmsNumber OPTIONAL,
greyscalePictures [62] EmsNumber OPTIONAL,
colourPictures [63] EmsNumber OPTIONAL,
businessCards [64] EmsNumber OPTIONAL,
calendarEntries [65] EmsNumber OPTIONAL,
polyphonicMelodies [66] EmsNumber OPTIONAL,
bit8PortNumberDest [67] EmsPortNumbers8 OPTIONAL,
messageReference [70] MsgRef OPTIONAL,
boolSer [71] BooleanServices OPTIONAL,
origLASN [72] VisibleString OPTIONAL,
recipLASN [73] VisibleString OPTIONAL,
origMsgID [74] MsgIdentification OPTIONAL,
a. ISR
recipMsgID [75] VisibleString OPTIONAL,
receiptDate [76] Date OPTIONAL,
receiptTime [77] Time OPTIONAL,
isr [78] ISRFlags OPTIONAL,
b. end ISR
recipAltAddress [79] AddressInformation OPTIONAL,
generatedSegments [80] NumGenSegments OPTIONAL,
serviceType [81] VisibleString OPTIONAL,
deliveryAttempts [82] DeliveryAttempts OPTIONAL,
untranslOrigAddress [83] UTF8AddressInformation OPTIONAL,
untranslOrigAddressGSM [84] AddressString OPTIONAL,
untranslRecipAddress [85] UTF8AddressInformation OPTIONAL,
untranslRecipAddressGSM [86] AddressString OPTIONAL,
msgError [87] MessageError OPTIONAL,
tpDCS [88] GSM-TP-DCS OPTIONAL,
genericUrgencyLevel [89] GenericUrgencyLevel OPTIONAL,
ifaceUrgencyLevel [90] IfaceUrgencyLevel OPTIONAL,
teleserviceId [91] TeleserviceIdentifier OPTIONAL,
origAddrGroup [92] AddressGroupId OPTIONAL,
recipAddrGroup [93] AddressGroupId OPTIONAL,
origNetworkType [94] MobileNetworkType OPTIONAL,
recipNetworkType [95] MobileNetworkType OPTIONAL,
origServicePrice [96] MoneyType OPTIONAL,
recipServicePrice [97] MoneyType OPTIONAL,
cser [98] CServices OPTIONAL,
origSPBPStatus [99] SPBPStatus OPTIONAL,
recipSPBPStatus [100] SPBPStatus OPTIONAL,
billidSMPP [101] BillingIdentifierSMPP OPTIONAL,
enumResult [102] ENUMResult OPTIONAL,
dser [103] DServices OPTIONAL,
importance [104] MsgImportance OPTIONAL,
forwAddress [105] AddressInformation OPTIONAL,
forwAddressGSM [106] AddressString OPTIONAL,
privateContainer [107] PrivateDataContainer OPTIONAL,
rbdlFlags1 [108] RbdlFlags1 OPTIONAL,
origSCAddress [110] AddressInformation OPTIONAL,
idMNPdb [111] IdMNPdbNumber OPTIONAL,
origMIN [112] MobileIdentificationNumber OPTIONAL,
recipMIN [113] MobileIdentificationNumber OPTIONAL,

logDate [114] Date OPTIONAL,
logTime [115] Time OPTIONAL,
mtyp [116] MTyp OPTIONAL,
presOrigAddress [117] AddressInformation OPTIONAL,
presOrigAddressGSM [118] AddressString OPTIONAL,
presRecipAddress [119] AddressInformation OPTIONAL,
presRecipAddressGSM [120] AddressString OPTIONAL,
messageID [121] UniqueMessageID OPTIONAL,
applicationData [122] ApplicationData OPTIONAL
}
CommandRecord ::= [APPLICATION 0] SEQUENCE

{
commandType [0] CommandType OPTIONAL,
origAddress [1] AddressInformation OPTIONAL,
origAddressGSM [2] AddressString OPTIONAL,
recipAddress [3] AddressInformation OPTIONAL,
recipAddressGSM [4] AddressString OPTIONAL,
cmdTerminReason [5] CmdTerminReason OPTIONAL,
orglSubmitDate [11] Date OPTIONAL, -- original submit Date
orglSubmitTime [12] Time OPTIONAL, -- original submit Time
}
NotificationRecord ::= [APPLICATION 1] SEQUENCE

{
orglOrigAddress [0] AddressInformation OPTIONAL,
orglOrigAddressGSM [1] AddressString OPTIONAL,
orglRecipAddress [2] AddressInformation OPTIONAL,
orglRecipAddressGSM [3] AddressString OPTIONAL,
orglNotifAddress [4] AddressInformation OPTIONAL,
orglNotifAddressGSM [5] AddressString OPTIONAL,
submitDate [6] Date OPTIONAL,
submitTime [7] Time OPTIONAL,
orglSubmitDate [8] Date OPTIONAL,
orglSubmitTime [9] Time OPTIONAL,
terminDate [11] Date OPTIONAL,
terminTime [12] Time OPTIONAL,
lengthOfMessage [13] MessageLength OPTIONAL,

origMsgID [24] MessageIdentification OPTIONAL,
boolSer [26] BooleanServicesNotif OPTIONAL,
dgtiAddress [29] AddressInformation OPTIONAL,
dgtiAddressGSM [30] AddressString OPTIONAL,
destPointCode [31] C7PointCode OPTIONAL,
orglOgtiAddress [32] AddressInformation OPTIONAL,
orglOgtiAddressGSM [33] AddressString OPTIONAL,
orglOrigPointCode [34] C7PointCode OPTIONAL,
deliveryAttempts [35] DeliveryAttempts OPTIONAL,
orglUntranslOrigAddress [36] UTF8AddressInformation OPTIONAL,
orglUntranslOrigAddressGSM [37] AddressString OPTIONAL,
orglUntranslRecipAddress [38] UTF8AddressInformation OPTIONAL,
orglUntranslRecipAddressGSM [39] AddressString OPTIONAL,
msgError [40] MessageError OPTIONAL,
orglOrigAddrGroup [42] AddressGroupId OPTIONAL,
orglRecipAddrGroup [43] AddressGroupId OPTIONAL,
orglRecipNetworkType [45] MobileNetworkType OPTIONAL,
orglRecipIntlMobileSubId [47] IMSI OPTIONAL,
origServicePrice [48] MoneyType OPTIONAL,
recipServicePrice [49] MoneyType OPTIONAL,
origSPBPStatus [54] SPBPStatus OPTIONAL,
recipSPBPStatus [55] SPBPStatus OPTIONAL,
orglNotifDate [56] Date OPTIONAL,
orglNotifTime [57] Time OPTIONAL,
billidSMPP [58] BillingIdentifierSMPP OPTIONAL,
cser [62] CServicesNTF OPTIONAL,
dser [63] DServicesNTF OPTIONAL,
importance [64] MsgImportance OPTIONAL,
orglOrigMIN [67] MobileIdentificationNumber OPTIONAL,
orglRecipMIN [68] MobileIdentificationNumber OPTIONAL,
ntyp [71] NTyp OPTIONAL,
messageID [77] UniqueMessageID OPTIONAL,
}
SummaryRecord ::= [APPLICATION 2] SEQUENCE

{
origAddress [ 0] AddressInformation OPTIONAL,
origAddressGSM [ 1] AddressString OPTIONAL,
recipAddress [ 2] AddressInformation OPTIONAL,
recipAddressGSM [ 3] AddressString OPTIONAL,
status [ 4] Status OPTIONAL,
vsmscid [ 5] RangeVSMSC OPTIONAL,
vsmsctype [ 6] TypeVSMSC OPTIONAL,
dgtiAddress [ 7] AddressInformation OPTIONAL,

dgtiAddressGSM [ 8] AddressString OPTIONAL,
destPointCode [ 9] C7PointCode OPTIONAL,
transparentPid [13] TransparentPid OPTIONAL,
totalUdLength [20] UdLength OPTIONAL,
submissionTimeFirst [21] Time OPTIONAL,
submissionDateFirst [22] Date OPTIONAL,
submissionTimeLast [23] Time OPTIONAL,
submissionDateLast [24] Date OPTIONAL,
deliveryTimeFirst [25] Time OPTIONAL,
deliveryDateFirst [26] Date OPTIONAL,
deliveryTimeLast [27] Time OPTIONAL,
deliveryDateLast [28] Date OPTIONAL,
cmReferenceNr [29] CmReference OPTIONAL,
segmentsTotal [30] CmNumber OPTIONAL,
segmentsAccepted [31] CmNumber OPTIONAL,
segmentsDelivered [32] CmNumber OPTIONAL,
segmentsDuplicate [33] CmNumber OPTIONAL,
segmentsReplaced [34] CmNumber OPTIONAL,
textFormatting [35] EmsBitString OPTIONAL,
bytesCompressedData [36] EmsBytesCompressed OPTIONAL,
predefinedAnimations [37] EmsNumber OPTIONAL,
userDefinedAnimations [38] EmsNumber OPTIONAL,
predefinedSounds [39] EmsNumber OPTIONAL,
userDefinedSounds [40] EmsNumber OPTIONAL,
blackWhitePictures [41] EmsNumber OPTIONAL,
standardWvg [42] EmsNumber OPTIONAL,
characterSizeWvg [43] EmsNumber OPTIONAL,
greyscalePictures [44] EmsNumber OPTIONAL,
colourPictures [45] EmsNumber OPTIONAL,
businessCards [46] EmsNumber OPTIONAL,
calendarEntries [47] EmsNumber OPTIONAL,
polyphonicMelodies [48] EmsNumber OPTIONAL,
boolSer [51] BooleanServicesCM OPTIONAL,
totalAttempts [54] DeliveryAttempts OPTIONAL,
segmError [55] MessageError OPTIONAL,
teleserviceId [56] TeleserviceIdentifier OPTIONAL,
nSer [57] NewServicesCM OPTIONAL,
prioIndicator [62] IMPLICIT BOOLEAN OPTIONAL,
deferIndicator [64] IMPLICIT BOOLEAN OPTIONAL,
deferPeriod [65] Period OPTIONAL,
notifIndicator [66] IMPLICIT BOOLEAN OPTIONAL,
notifAddress [67] AddressInformation OPTIONAL,
notifAddressGSM [68] AddressString OPTIONAL,
mesgReplyPath [69] MesgReplyPath OPTIONAL,
portNumber [71] PortNumber OPTIONAL,
aser [72] AdditionalServices OPTIONAL,
mser [73] RequestedServices OPTIONAL,
xser [74] ExtraServices OPTIONAL,
lang [75] LanguageIndicator OPTIONAL,
cbat [76] VisibleString OPTIONAL,

untranslOrigAddress [83] UTF8AddressInformation OPTIONAL,
untranslOrigAddressGSM [84] AddressString OPTIONAL,
untranslRecipAddressGSM [86] AddressString OPTIONAL,
genericUrgencyLevel [88] GenericUrgencyLevel OPTIONAL,
ifaceUrgencyLevel [89] IfaceUrgencyLevel OPTIONAL,
cser [91] CServicesCM OPTIONAL,
dser [92] DServices OPTIONAL
}
ApplicationData ::= OCTET STRING (SIZE (1..33))
FailedLoginRecord ::= [APPLICATION 3] SEQUENCE

{
userType [0] UserType OPTIONAL,
userAddress [1] UTF8AddressInformation OPTIONAL,
netwAddress [2] UTF8AddressInformation OPTIONAL,
failReason [3] FailReason OPTIONAL,
failDate [4] Date OPTIONAL,
failTime [5] Time OPTIONAL
}
FaxReportRecord ::= [APPLICATION 4] SEQUENCE

{
faxOrigAddress [0] UTF8AddressInformation OPTIONAL,
faxRecipAddress [1] UTF8AddressInformation OPTIONAL,
faxDeliveryDate [3] Date OPTIONAL,
faxDeliveryTime [4] Time OPTIONAL,
faxFirstDeliveryDate [5] Date OPTIONAL,
faxFirstDeliveryTime [6] Time OPTIONAL,
faxLastDeliveryDate [7] Date OPTIONAL,
faxLastDeliveryTime [8] Time OPTIONAL,
numberOfPages [9] NumberOfPages OPTIONAL,
numberOfAttempts [10] DeliveryAttempts OPTIONAL
}
AlertRecord ::= [APPLICATION 5] SEQUENCE

{
recipAddress [0] UTF8AddressInformation OPTIONAL,
submitDate [2] Date OPTIONAL,
submitTime [3] Time OPTIONAL,
untranslRecipAddress [4] UTF8AddressInformation OPTIONAL
}
SendRoutingInfoRecord ::= [APPLICATION 6] SEQUENCE

{
scAddress [0] UTF8AddressInformation OPTIONAL,
phishingIndicator [2] IMPLICIT BOOLEAN OPTIONAL,
recipMSC [4] AddressInformation OPTIONAL,
recipSGSN [5] AddressInformation OPTIONAL,
rbdlFlags2 [9] RbdlFlags2 OPTIONAL
}
AddressInformation ::= SEQUENCE

{
ton [0] TypeOfNumber OPTIONAL,
npi [1] NumberingPlanIndicator OPTIONAL,
pid [2] ProtocolIdentifier OPTIONAL,
msisdn [3] NumericString OPTIONAL,
msisdnUTF8 [4] UTF8String OPTIONAL
}

UTF8AddressInformation ::= SEQUENCE
{
ton [0] TypeOfNumber OPTIONAL,
npi [1] NumberingPlanIndicator OPTIONAL,
pid [2] ProtocolIdentifier OPTIONAL,
msisdn [3] UTF8String OPTIONAL
}
TypeOfNumber ::= ENUMERATED

{
unknown (0),
international (1),
national (2),
network (3),
short (4),
alpha (5),
abbreviated (6),
reserved7 (7)
-- 0..255
}
NumberingPlanIndicator ::= INTEGER

{
unknown (0),
telephone (1),
reserved2 (2),
data (3),
telex (4),
tcpip (5),
landmobile (6),
reserved7 (7),
national (8),
private (9),
ermes (10),
reserved11 (11),
reserved12 (12),
reserved13 (13),
internet (14),
reserved15 (15)
} (0 … 255)
ProtocolIdentifier ::= INTEGER

{
plmn (0),
globaltitle (24),
faxg3 (34),
faxg4 (35),
ivr (36),
ermes (37),
menu (56),
pc (57),
tap (58),
smpp (59),
wap (60),
ois (61),
vms (62),
smtp (204)
} (0 … 255)
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
BillingIdentifier ::= VisibleString (SIZE (1..20))

BillingIdentifierSMPP ::= OCTET String (SIZE (1..20))
MsgIdentification ::= VisisbleString (SIZE (1..64))
Date ::= OCTET STRING (SIZE (3)) -- 3 octets [yy][mm][dd]
Time ::= OCTET STRING (SIZE (3)) -- 3 octets [hh][mm][ss]

Status ::= ENUMERATED
{
delivered (0),
expired (1),
deleted (2),
replaced (3),
submitted (4),
incomplete-submission (5), -- SummaryRecord
incomplete-delivery (6), -- SummaryRecord
undeliverable (7),
passed-on (8), -- to foreign SMSC (Inter SMSC Router)
rejected (9),
intermediate (10), -- failed delivery attempt due to
c. non-permanent (temporary) error condition
}
MessageLength ::= INTEGER {min (0), max (4096)}
LanguageIndicator ::= INTEGER {min (0), max (255)}
Period ::= SEQUENCE

{
hours [0] HoursPeriod OPTIONAL,
minutes [1] Minutes OPTIONAL
}
HoursPeriod ::= INTEGER {min (0), max (8760)}
Minutes ::= INTEGER {first (0), last (59)}
RangeVSMSC ::= INTEGER
TypeVSMSC ::= ENUMERATED

{
none (0),
private (1),
public (2)
}
C7PointCode ::= INTEGER {max (16777215)}
TransparentPid ::= INTEGER {min (0), max (255)}
PortNumber ::= INTEGER
SmeReference ::= INTEGER { min(0), max(4294967295)}
MesgReplyPath ::= ENUMERATED

{
request (1),
response (2)
}
CommandType ::= ENUMERATED

{
phase1cmdinqm (0), -- phase1 command “inquire message”
phase1cmddelm (1), -- phase1 command “delete message”
gsmcmdcenq (2), -- gsm command “enquire message”
gsmcmdcdel (3), -- gsm command “delete message”
gsmcmdcesr (4), -- gsm command “enable status report”
gsmcmdccsr (5), -- gsm command “clear status report”
phase1cmdmodm (6), -- command “modify message”
gsmcmdssdl (7), -- provisioning command “show subsciber distribution list”
ivrmods (8), -- modified short message
vmsmodm (9) -- delete VMS short message
}
CmdTerminReason ::= ENUMERATED

{
notaccepted (0),
accepted (1),
notfound (2),
tmpnotavail (3)

}
AdditionalServices ::= BIT STRING

{
swinq (0), -- request to send a response to inquiry via SIW only
swdel (1), -- request to send a response to delete via SIW only
notifreq (7), -- the message originator has requested text notifications
-- (i.e. not native), particular notification types are
-- configured according to notification settings set by
-- the operator, for MO SMS notifreq applies to scan commands
notifalw (8), -- the operator has configured that text notifications are
-- generated automatically for MO messages
usrnotif (9), -- the message originator has explicitly requested a specific
-- notification type (UCP or SMPP only)
lradreq (10), -- indicates that the originator requested
d. for last resort delivery
ackdel (26), -- message containing an SME generated delivery ack
ackman (27), -- message containing an SME generated manual ack
singleshot (29) – single shot indication
} (SIZE(maxAdditionalServicesLength))
maxAdditionalServicesLength INTEGER ::= 32
RequestedServices ::= BIT STRING

{
svp (0), -- not default validity period for SHM
sdd (2), -- short message requires deferred delivery
nde (3), -- generate delivery notification
nnd (4), -- generate non-delivery notification
nbu (5), -- generate buffered message notfication
pri (7), -- priority message
unsol (8), -- generate unsolicited notification (SIWIVR only)
lrad (9), -- request for LRAD services
lrm (10) -- last resort message
} (SIZE(maxRequestedServicesLength))
maxRequestedServicesLength INTEGER ::= 16
NewServices ::= BIT STRING

{
mrep (2), -- indicates that a message replace PID is supplied
deleted (3), -- indicates that the message has been deleted
-- by the SME.
replaced (4), -- indicates that the message has been replaced
-- using the transparant PID.
lao (5), -- indicates that the originator of the message
-- is a large account.
lar (6), -- inidicates that the recipient of the message
-- is a large account.
fwad (7), -- the message will be sent to the forwarding
-- address FWAD.
fwad-cond (8), -- indicates that one attempt should be made to
-- the MRAD before sending it to the FWAD.
clir (9), -- indicates that the originator address should
-- be invisible at the recipient side.
modified (11), -- message is modified
switched-fwad (13),-- indicates that only the first attempt should be made to
-- FWAD, all subsequent attempts to MRAD
fwad-send (14), -- indicates that the first delivery attempt failed
-- when conditional forwarding is in effect
trace-copy (17), -- indicates that the message is a copy
e. generated by the option Message Tracing.
udhi (24), -- indicates if the user data header is present.
del-by-operator (28) -- indicates that the message has been removed
f. been removed by the operator
} (SIZE(maxNewServicesLength))
maxNewServicesLength INTEGER ::= 32
ExtraServices ::= BIT STRING

{

inqdel (4), -- MO inquiry or delete operation.
swnotif (8), -- SIWnotif, send only notification of the SIW.
dl (9), -- recipient addressed via the distribution list.
rejdupl (15) -- indicates if a duplicate message should be
g. rejected
} (SIZE(maxExtraServiceLength))
maxExtraServiceLength INTEGER ::= 16
CServices ::= BIT STRING

{
account-balance-notification (4), -- Message is an account balance
notification
provisioning-scan-command-response (5), -- Message is a provisioning scan
command response
notification-suppressed (11), -- Suppress sending all notifications
dsr-trigger (20), -- Message is a delivery status report
trigger
} (SIZE(maxCServiceLength))
CServicesCM ::= BIT STRING

{
reserved (0) – This reserved bit is to be removed when other bits are
h. added to this bit string.
} (SIZE(maxCServiceLength))
CServicesNTF ::= BIT STRING

{
dsr-trigger (20), -- Message is a delivery status report
trigger
}
maxCServiceLength INTEGER ::= 32
DServices ::= BIT STRING

{
archiving-org-cpy-created (0), -- Of this message an originator copy
has been generated
archiving-rcp-cpy-created (1), -- Of this message a recipient copy has
been generated
archiving-is-org-copy (2), -- Message is an archiving originator
copy
archiving-is-rcp-copy (3), -- Message is an archiving recipient
copy
urgency-level-forced (12), -- Message has changed urgency level
delivery-attempt (13), -- Message was object of delivery
spoofed-gt (14), -- Spoofed due to GT mismatch
spoofed-imsi (15), -- Spoofed due to IMSI mismatch
spoofed-hlr (16), -- Spoofed due to HLR failure
gti-trigger-invoked (19), -- GTI Trigger Invocation Indicator
rbdl-generated (20), -- Message was generated by RBDL
gti-suppressed (21) -- GTI Suppression Indicator
} (SIZE(maxDServiceLength))
DServicesNTF ::= BIT STRING

{
delivery-attempt (13) -- Message was object of delivery
} (SIZE(maxDServiceLength))
maxDServiceLength INTEGER ::= 32
PrepaidPrimSer ::= BIT STRING

{
orig-pp (0), -- Originator of SM is prepaid user.
recip-pp (1), -- Recipient of SM is prepaid user.
orig-blocked (2), -- Originator of SM is blocked.
recip-blocked (3), -- Recipient of SM is blocked.
prim (4), -- Primary Service was associated to this SM.
charge-recip (5), -- Recipient is the charged party for
i. Primary Service.
free (6), -- Primary Service is FREE.
during-jam (7), -- Primary Service applied during JAMMED state.
applied-pmgt (8), -- Port management settings were applied

-- to Primary Service
charge-orig (9), -- Originator is the charged party
j. for Primary Service.
bulk-match (10), -- Prepaid party charged in bulk mode
during-jam-orig (11), –- Primary Service applied to originator
-- during JAMMED state
during-jam-recip (12) –- Primary Service applied to recipient
k. during JAMMED state
} (SIZE(maxPrepaidPrimSerLength))
maxPrepaidPrimSerLength INTEGER ::= 32
PrepaidAddSer ::= BIT STRING

{
notif-buf (0), -- Buffered notification
notif-del (1), -- Delivery notification
notif-ndel (2), -- Non-delivery notification
forward-uncond (3), -- Unconditional forwarding
forward-cond (4), -- Conditional forwarding
forward-switch-cond (5), -- Switched conditional forwarding
last-resort-subs (6), -- Subscriber based last resort
l. delivery
last-resort-msg (7), -- Message based last resort delivery
provision (8), -- Provisioning
reply-resp (9), -- Reply response
sms-command (10), -- SMS command
umf (11), -- Unified Mailbox Forwarding
} (SIZE(maxPrepaidAddSerLength))
maxPrepaidAddSerLength INTEGER ::= 32
ISRFlags ::= BIT STRING

{
reg-del-nde (1),
reg-del-nnd (2),
passed-along (4)
} (SIZE(maxISRFlagsLength))
maxISRFlagsLength INTEGER ::= 8
UdLength ::= INTEGER {min (0), max (40800) }
CmReference ::= INTEGER {min (0), max (65535) }
CmNumber ::= INTEGER {min (0), max (255) }
EmsBitString ::= BIT STRING

{
formatApplied (0)
}
EmsBytesCompressed ::= INTEGER {min (0), max (35700) }
EmsNumber ::= INTEGER {min (0), max (8607) }
EmsPortNumbers8 ::= INTEGER {min (0), max (255) }
EmsPortNumbers16 ::= INTEGER {min (0), max (65535) }
LmsgNumseg ::= INTEGER {min (0), max (255)}
BooleanServices ::= BIT STRING

{
erarr (1), -- Extended RARR
transaction-mode (7), -- Handled in transaction mode
umf (10), -- Unified mailbox copied/forwarded
fsg (20), -- Received via FSG
replace-if-present (24), -- Replace If Present flag
gateway-la (25) -- sent to gateway LA
} (SIZE(maxBooleanServicesLength))

BooleanServicesNotif ::= BIT STRING
{
erarr (1), -- Extended RARR
replace-if-present (24), -- Replace If Present flag
gateway-la (25) -- sent to gateway LA
BooleanServicesCM ::= BIT STRING

{
transaction-mode (7), -- Handled in transaction mode
fsg (20), -- Received via FSG
replace-if-present (24) -- Replace If Present flag
maxBooleanServicesLength INTEGER ::= 32
SMS-STRING ::= OCTET STRING
MsgRef ::= OCTET STRING
NumGenSegments ::= INTEGER {min (0), max (255) }
DeliveryAttempts ::= INTEGER {min (1), max (65535) }
GenericUrgencyLevel ::= ENUMERATED

{
bulk (0),
normal (1),
interactive (2),
priority (3), -- (TDMA/CDMA: urgent)
emergency (4) -- (TDMA: very urgent)
}
-- This type encodes the (normalised/internal) effective generic
-- urgency level.
IfaceUrgencyLevel ::= INTEGER {min (0), max (3) }

-- This type encodes the effective urgency level as (would be) given
-- on the submission interface as a physical number.
TBCD-STRING ::= OCTET STRING

-- This type (Telephony Binary Coded Decimal String) is used to
-- reresent several digits from 0 through 9, *, #, a, b, c, two
-- digits per octet, each digit encoded 0000 to 1001 (0 … 9),
-- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used
-- as filler when there is an odd number of digits.
-- bits 8765 of octet n encoding digit 2n

-- bits 4321 of octet n encoding digit 2(n-1) + 1
AddressString ::= OCTET STRING (SIZE (1 … maxAddressLength))

-- This type is used to represent a number for addressing
-- purposes. It is composed of
-- a) one octet for the nature of the address and numbering
-- plan indicator.
-- b) digits of an address encoded as TBCD-String
-- A) The first octet includes a one bit extension indicator,

-- a 3 bits nature of the address indicator and a 4 bits
-- numbering plan indicator, encoded as follows:
-- bit 8: 1 (no extension)
-- bits 765: nature of the address indicator
-- 000 unknown, starting with international/(optional)national prefixes

-- 001 international number, starting with the country code (CC)
-- 010 national significant number, number starting with the national
-- destination code (NDC)
-- 011 network specific number

-- 100 short number, subscriber number
-- 101 alphanumeric
-- bits 4321: numbering plan indicator
-- 0000 unknown
-- 0001 ISDN/Telephony Numbering Plan (Rec CCITT E.164)
-- 0011 Data numbering plan (X.121)
-- 0100 Telex numbering plan (F.69)
-- 0101 Service Centre Specific plan – Acision: TCP/IP
-- 1001 private numbering plan
-- B) The following octets representing digits of an address

-- encoded as a TBCD-String
maxAddressLength INTEGER ::= 20
IMSI ::= TBCD-STRING (SIZE (3 … 8))

m. digits of MCC, MNC, MSIN are concatenated in this order
MessageError ::= INTEGER {min (0), max (65534)}
GSM-TP-DCS ::= INTEGER {min (0), max (255) }
TeleserviceIdentifier ::= INTEGER {min (0), max (65535)}
NewServicesCM ::= BIT STRING

{
trace-copy (17) -- indicates that the message is a copy
n. generated by the option Message Tracing.
} (SIZE(maxNewServicesCMLength))
maxNewServicesCMLength INTEGER ::= 32
AddressGroupId ::= INTEGER {min(0), max (255)}
MobileNetworkType ::= ENUMERATED

{
gsm (1),
tdma (2),
cdma (3),
ghost (4),
iden (5)
}
MoneyType ::= SEQUENCE

{
currency [0] MoneyCurrency OPTIONAL,
exponent [1] MoneyExponent OPTIONAL,
value [2] MoneyValue OPTIONAL
}
MoneyCurrency ::= INTEGER { min(1), max(1000) }

MoneyExponent ::= INTEGER { min(-10), max(10) }
MoneyValue ::= INTEGER { min(-2147483648), max(2147483647) }
SPBPStatus ::= INTEGER
ENUMResult ::= ENUMERATED

{
route-to-la (1),
route-to-plmn (2)
}
NumberOfPages ::= INTEGER {min(0), max(100)}
UserType ::= INTEGER

{
subscriber (1),
large-account(2)
}
FailReason ::= INTEGER

{
passwd-invalid (1),
passwd-nomatch (2),
passwd-new-invalid (3),
remote-usr-invalid (4),
la-addr-invalid (5),
subscr-addr-invalid (6),
no-prov-session (7)
}
MsgImportance ::= INTEGER {min(0), max (1)}
PrivateDataContainer ::= OCTET STRING (SIZE (1..41))
IdMNPdbNumber ::= INTEGER { min(0), max(256)}
RbdlFlags1 ::= BIT STRING

{
rbdl-flag-1 (0),
rbdl-flag-2 (1),
rbdl-flag-3 (2),
rbdl-flag-4 (3),
rbdl-flag-5 (4),
rbdl-flag-6 (5),
rbdl-flag-7 (6),
rbdl-flag-8 (7),
rbdl-flag-9 (8),
rbdl-flag-10 (9),
rbdl-flag-11 (10),
rbdl-flag-12 (11),
rbdl-flag-13 (12),
rbdl-flag-14 (13),
rbdl-flag-15 (14),
rbdl-flag-16 (15),
rbdl-flag-17 (16),
rbdl-flag-18 (17),
rbdl-flag-19 (18),
rbdl-flag-20 (19),
rbdl-flag-21 (20),
rbdl-flag-22 (21),
rbdl-flag-23 (22),
rbdl-flag-24 (23),
rbdl-flag-25 (24),
rbdl-flag-26 (25),
rbdl-flag-27 (26),
rbdl-flag-28 (27),
rbdl-flag-29 (28),
rbdl-flag-30 (29),
rbdl-flag-31 (30),
rbdl-flag-32 (31)
} (SIZE(maxRbdlFlagsLength))
RbdlFlags2 ::= BIT STRING

{
rbdl-flag-33 (0),
rbdl-flag-34 (1),
rbdl-flag-35 (2),
rbdl-flag-36 (3),
rbdl-flag-37 (4),
rbdl-flag-38 (5),
rbdl-flag-39 (6),
rbdl-flag-40 (7),
rbdl-flag-41 (8),
rbdl-flag-42 (9),
rbdl-flag-43 (10),
rbdl-flag-44 (11),
rbdl-flag-45 (12),
rbdl-flag-46 (13),
rbdl-flag-47 (14),
rbdl-flag-48 (15),
rbdl-flag-49 (16),
rbdl-flag-50 (17),

rbdl-flag-51 (18),
rbdl-flag-52 (19),
rbdl-flag-53 (20),
rbdl-flag-54 (21),
rbdl-flag-55 (22),
rbdl-flag-56 (23),
rbdl-flag-57 (24),
rbdl-flag-58 (25),
rbdl-flag-59 (26),
rbdl-flag-60 (27),
rbdl-flag-61 (28),
rbdl-flag-62 (29),
rbdl-flag-63 (30),
rbdl-flag-64 (31)
} (SIZE(maxRbdlFlagsLength))
maxRbdlFlagsLength INTEGER ::= 32
MobileIdentificationNumber ::= TBCD-STRING (SIZE (5))
MTyp ::= ENUMERATED

{
subs (17),
subv (23),
logs (97)
}
NTyp ::= ENUMERATED

{
ndel (2),
nnde (3),
nbuf (4),
ninq (5),
ndlt (6),
naac (7),
nmac (8),
nuac (9),
ndelc (10)
}
END
The ASN.1 definition in Table 6-1 may cause backwards compatibility

CallDetailRecord
issues with the ASN.1 definition of SMSC Release 4.0. Refer to Appendix C for details.
The contents of the CallDetailRecord, CommandRecord, NotificationRecord and SummaryRecord

fields are described in more detail in respective Table 6-2, Table 6-3, Table 6-4 and Table
6-5.

Table 6-2: CallDetailRecord Fields
CallDetailRecord Fields
Field Contents in case of MO Access Contents in case of non-MO Access
OrigAddress Subscriber A-number. Sub-fields for all User provided data. If the originator is
“*Address” fields are TON, NPI, PID and an LA, this field is set to the LA
MSDISDN. provided source address, such as the
UCP OAdC field [EMI-UCP] or the
Please refer to Table 5-3 SMPP source_address field
(LOG_INTL_ADDR_ENABLED) and [SMPPv34]).
Table 5-1 (PRES_ADDR_ENABLED) for
Configuration Options. Please refer to Table 5-5
(SMSC46_ASN1_ALPHA2LASN,
SMSC45_LOGSRV_MULA_SN_IN_MOA
D and SMSC46_SILA_
ALPHA2NETWORK), Table 5-3
(LOG_INTL_ADDR_ENABLED) and
Table 5-1 (PRES_ADDR_ENABLED) for
Configuration Options.
OrigAddressGSM Same as origAddress, formatted Same

according to [3GPP_23040]. The length
octet is represented by the ASN.1 length
field octet.
RecipAddress Subscriber B-number. If the Same

recipient is a MULA, this
field contains the MULA short
number. If the recipient is a
SILA, this field contains the
SILA network address.
Please refer to Table 5-1

(ROUT_ADDR_IN_RECIP, TRANSL_
RECIP_ADDR, PRES_ADDR_ENABLED
and SILA_SHORTNUM_ENABLED),
Table 5-3
(LOG_INTL_ADDR_ENABLED), and
Table 5-5, Table 5-4
(SMSC35_2ADDR_BILLING) for
When the catchall routing is

applied to a SM which has
been subject to forwarding,
the recipient address field
will then contain the
forwarding address.
RecipAddressGSM Same as recipAddress, formatted Same

field octet.
SubmitDate Date of submission in format YYMMDD. Same
SubmitTime Time of submission in format HHMMSS Same

–adapted format (made unique per
recipient).

Status 0 (Delivered) Same

1 (Expired)
2 (Deleted)
3 (Replaced)
4 (Submitted)
5 (Submitted) (Incomplete)
6 (Delivered) (Incomplete)
7 (Undeliverable)*
8 (Passed-on, ISR)
9 (Rejected)
10 (Intermediate)
Other value => “illegal” written to CDR
(value printed).* Please refer to Table
5-5 Table 5-4
(SMSC46_LOGSRV_STATUS_
UNDELIVERABLE and
SMSC46_LOGSRV_
STATUS_PP_REJECTED) for Mapping
Options.
TerminDate Date when the message was delivered Same

or deleted from the SMSC. Date when
the failed delivery attempt was made (in
case the Status was Intermediate).
The format is YYMMDD.
TerminTime Time when the message was delivered Same

or deleted from the SMSC. Time when
the failed delivery attempt was made (in
case Status was Intermediate).
The format is HHMMSS.
LengthOfMessage Message Content size in octets. In case Same
of a Long Message [OMAN] or
Extended Message [OMAN], the Total
Message Content size in octets.
PrioIndicator Indicates whether priority delivery was Same

requested (TRUE) or not (FALSE).
ValidityPeriod Period the message was valid in the Same

SMSC.
DeferIndicator Indicates whether deferred delivery was Same

re-quested (TRUE) or not (FALSE).
deferPeriod Indicates the period the message was Same

deferred on. Only present if
deferIndicator is TRUE.
notifIndicator Indicates whether a notification was Same

generated for this message (TRUE) or
not (FALSE).
notifAddress Recipient of the notification. If the Same

recipient of the notification is a MULA,
this field contains the MULA Short
Number. If the recipient of the
Notification is a SILA, this field contains
the SILA network address.

(SILA_SHORTNUM_ENABLED) and
Table 5-3 (LOG_INTL_ADDR_ENABLED)
for Configuration Options.

notifAddressGSM Same as notifAddress, formatted Same

field octet.
vsmscid Last three digits of the Service Centre SC address used towards the mobile
address that was used. recipient. If an LA is linked to private
VSMSC, the VSMSC is identified by
the CLI address of the LA. In other
cases, the value is determined by the
port setting VSC_VSMSC in
configuration file
SMSC$ROOT:[DATA]SIWPC_PMGT.C
NF. If this value is not present for the
port being used, the last 3 digits of the
SMSC_PLMN_ADDR attribute in class
SMSC are used. Not present if the
VSMSC license is not in use.
vsmsctype Identifies whether the VSMSC is Same
associated with an LA (1) VSMSC type
private or LA (2) VSMSC type public. If
the VSMSC license is not in use, the
value will be (0) VSMSC type none.
dgtiAddress E.164 address (called party Global Title Same

(GT)) of the MS serving MSC/SGSN.
Present for global title routed messages,
e.g. for roaming or foreign subscribers.
The called party GT of the MS serving
MSC/SGSN of the previous successful
delivery or the called party GT of the
HLR interrogation if the HLR did not
return MSC/SGSN address.
dgtiAddressGSM Same as dgtiAddress, formatted Same

field octet.
destPointCode Point Code of the destination MSC, the Same

MSC of the previous successful delivery
or HLR. This field is absent if routing
took place on global title or if the
recipient of the message was a non-
mobile.
ogtiAddress E.164 address (Calling Party Global Title Not present.
(GT)) of the MS serving MSC/SGSN.
Present for originating GT routed
messages, e.g. for roaming subscribers.
ogtiAddressGSM Same as ogtiAddress, formatted Not present.
field octet.
OrigPointCode The point code of the first MSC in the Not present.
message routing path.
orglSubmitDate Original date of submission YYMMDD Same
(non-adapted format)
orglSubmitTime Original time of submission HHMMSS Same

(un-adapted format)
transparentPid TP-PID value [3GPP_23040] as The TP-PID [3GPP_23040]] value as

provided by the mobile originator. provided by the originating application.
Examples are the UCP RPID value
[EMI-UCP] and the SMPP
PROTOCOL_ID value [SMPPv34].

MesgReplyPath Indicates if the message is: Same

(1) A reply path request
(2) A reply path response
If neither field is present.
recipInt Recipient IMSI. When “Caching Of

MobileSubId Recipient delivery Information” [OMAN]
is enabled, the SMSC may base this on
cached information, for the billing of a
new submission.
OrigIntl Originator IMSI – Present when received Not present.
MobileSubId from the network or fetched through
mobile originated HLR interrogation.
origNetworkType PLMN type of the originator. Not present.
recipNetworkType PLMN type of the recipient. When Same

“Caching Of Recipient delivery
Information” [OMAN] is enabled, the
SMSC may base this on cached
information, for the billing of a new
submission.
callingLineId Subscriber A number. Calling line identification. If the

originator is a MULA, this field
Please refer to Table 5-3 contains the MULA short number. If
(LOG_INTL_ADDR_ENABLED) for the originator is a SILA, this field
Configuration Options. contains the SILA network address.
(SILA_SHORTNUM_ENABLED) for
CallingLineId Same as CallingLineId; formatted Same
GSM according to [3GPP_23040]. The length
field octet.
consolidation Only present if the recipient is an LA. Only present if the originator is an LA.
Contents will be set to the LA’s Contents will be set to the LA’s
consolidation field. consolidation field. For the special
case when both the originator and
recipient are LAs, the contents is set
to either the originator or recipient
LA’s consolidation field, according to
the LALA_CONSOLIDATION
configuration setting in the
SSD_COMMON class.
PortNumber Not present. The physical port number accessed on

the SMSC side by the remote party
(MENU, PC and TAP access only).
Billing Not present. Only present if the originator is an LA
Identifier that submitted a UCP51 operation
with a non-empty Billing Identifier.
Please refer to [EMI-UCP].
ASER Requested and applied services to the Same

message (Additional Services). Please
refer to Section 6.2.1.
MSER Requested and applied services to the Same

message (Message Services).
Please refer to Section 6.2.1.
NSER Requested and applied services to the Same

message (New Services).

XSER Requested and applied services to the Same

message (Extra Services).
ppPser Requested and applied services to the Same

message (Prepaid Primary Services)
ppAser Requested and applied services to the Same

message (Prepaid Additional Services).
ppAserDuringJam Requested and applied services to the Same

message (Prepaid Additional Services
During Jam). Bits within
ppAserDuringJam indicate which
additional services were granted during
a JAMMED state of the prepaid system
interface.
ppAserFree Requested and applied services to the Same
Free) Bits within ppAserFree indicate
which additional services were FREE.
smsContents Contains the SM Contents. Same
smsContentDcs Indicates the DCS used. Same
cmReferenceNr Reference number of the CM. Same
currentSegment Current segment number. Same
segmentsTotal Total number of segments belonging to Same

the CM.
Text_formatting Text formatting (Yes / No). Same
bytes_ Total number of bytes in compressed Same

compressed_data EMS IE.
predefined_ Total number of predefined animations. Same

animations
User_defined_ Total number of user defined Same

animations animations.
predefined_ Total number of predefined sounds. Same

sounds
User_defined_ Total number of user defined sounds. Same

sounds
black_white_ Total number of black and white Same

pictures pictures.
standard_wvg Total number of standard wireless Same

vector graphic elements.
character_size_ Total number of character size wireless Same

wvg vector graphic elements.
greyscale_ Total number of greyscale pictures. Same

pictures
colour_ Total number of colour pictures. Same

pictures

Business_ Total number of business cards. Same

cards
Calendar_ Total number of calendar entries. Same

entries
polyphonic_ Total number of Polyphonic melodies. Same

melodies
bit_8_port_ 8 bit application destination port Same

number_dest number.
bit_16_port_ 16 bit application destination port Same

number_dest number.
message_ Unique message reference ID. Same

reference Concatenating IDI parameter SOMI
(message originator identifier) to IDI
parameter ISID (interactive session
identifier) forms this context ID. The
message reference ID will be unique
across prepaid and postpaid billing
feeds and will provide an auditable link
back to the original SM.
lmsgNrSeg Number of segments of a Long Same

Message [OMAN] or an Extended
Message [OMAN].
boolean_ Requested and applied services to the Same

services message (Boolean Services).
originating_ Originating LASN Same

LASN
recipient_ Recipient LASN Same

LASN
originating_ Originating Message ID – specific for Same

MSGId ISR.
recipient_ Destination or the recipient Message ID Same

MSGId returned to the ISR – specific for ISR.
recipient_ Date that SMPP Message Receipt was Same

delivery_date received by the ISR, from the recipient
SMSC – specific for ISR.
recipient_ Time that SMPP Message Receipt was Same

delivery_time received by the ISR, from the recipient
SMSC – specific for ISR.
isr_flags Requested and applied services to the Same

message – specific for ISR. Please refer
to Section 6.2.1.
recip_alt_ Recipient alternative address. This is Same

address only present in the case of an LA
terminated message (where an LA is not
an SMTP LA) and ensures that the
LASN will be available in the CDR.
Contains the following sub-fields:
TON = 4 (SHORT)NPI = 5 (TCPIP)PID

= RecipAddress PIDMSISDN = LASN

Delivery Number of delivery attempts when its Same

Attempts value > 0. When more messages are
queued for the same recipient address
and a delivery attempt for that address
is made, the number of delivery
attempts shall only be increased for the
1st message that is queued.
UntranslOrig User provided data. This field is set to User provided data. If the originator
Address the user provided source address. address is an LA, this field is set to the
LA provided source address.
This field must be used for correlation
with corresponding Notification CDRs This field must be used for correlation
using field with corresponding Notification CDRs
orglUntranslOrigAddress of the using field
Notification. orglUntranslOrigAddress of the
Notification.
untranslOrig Same as untranslOrigAddress, Same

AddressGSM formatted according to [3GPP_23040].
The length octet is represented by the
ASN.1 length field octet.
untranslRecip User provided data. This field is set to Same

Address the user provided recipient address.
This field must be used for correlation

with corresponding Notification CDRs
using field
orglUntranslRecipAddress of the
Notification.
untranslRecip Same as untranslRecipAddress, Same

AddressGSM formatted according to [3GPP_23040].
msgError The message delivery error code. Same

Please refer to section 6.2.7.
tpDCS The TP-DCS value (optionally modified Same

via the configuration file TP_DCS.DAT)
provided in the SM. For the possible TP-
DCS values refer to [3GPP_23038].
genericUrgencyLevel Normalised/internal generic urgency Same

level.
ifaceUrgencyLevel Effective urgency level as (would be) Same

given on the submission interface.
teleserviceID If originated from a CDMA or IS41 If a message is originated from an

network, the internal value of the IS41 SMPP LA and includes an SMPP
Teleservice identifier service type [SMPPv34], the internal
[3GPP2_PARAMS]. value of the IS41 Teleservice identifier
associated with that service type
[3GPP2_PARAMS].
origAddrGroup Identifier of Address Group which Same

contains the best matching address
pattern for the Originator address.
recipAddrGroup Identifier of Address Group which Same

contains the best matching address
pattern for the Recipient address.

origServicePrice SMRI for the originator of the SM if the Same

originator is a prepaid subscriber that is
charged for the service. Please refer to
Section 6.2.6
recipServicePrice SMRI for the recipient of the SM if the Same

recipient is a prepaid subscriber that is
Section 6.2.6
cServices Requested and applied services to the Same

message (C-Services). Please refer to
Section 6.2.1.
origSPBPStatus Status code resulting from the prepaid Not present.

debit transaction for the SMS originator.
recipSPBPStatus Status code resulting from the prepaid Same

debit transaction for the SMS recipient.
enumResult Identifies whether the message was Same

routed using the Telephone Number
Mapping (ENUM).
The values are:
1 – route to LA
2 – route to PLMN.
billidSMPP Not present. SMPP billing_identification

submitted by SMPP LA. Please refer
to [SMPPv50]
dServices Requested and applied services to the Same

message (D-Services). Please refer to
Section 6.2.1.
importance Identifies message importance level. Same

The values are:
1 – High importance
0 – Normal importance
forwAddress If forwarding of SMs is in Same
effect, this field contains
the forwarding address (if
the recipient address is
stored in the recipAddress
field) or untranslated
recipient address (if the
forwarding address is stored
in the recipAddress field).
See Configuration Options
settings described in
recipAddress.
forwAddresGSM Same as forwAddress, formatted Same

field octet.

privateContainer The private data container that was Same

attached to the message by an external
application triggered via the GTI
(Generic Triggering Interface). The
privateContainer contains binary
data. The first byte of the
privateContainer contains the
actual length of the data attached. The
remaining bytes contain the binary data
starting at the second byte.
rbdlFlags1 Contains RBDL flags 1 – 32. Same
origSCAddress Originating Service Center address of a Not present.

mobile-terminated message received by
the SMSC.
idMNPdb Contains ID of the MNP database which Same

is used (as configured in the ENUM),
when multiple MNP databases in the
ENUM are configured.
For more information on ISR (option 228), please consult the ISR Operators Guide
[ISR_OPG].
Table 6-3: CommandRecord Fields (Specifics)
CommandRecord Fields (Specifics)
Field Contents in case of MO Access Contents in case of non-MO

Access
CommandType Indicates the command type. Values are: Same

0. Scan command “inquire message”
1. Scan command “delete message”
2. GSM command “enquire message”
3. GSM command “enable status report”
4. GSM command “clear status report”
5. UCP command “modify message”
Other value => “illegal” written to CDR (value printed)
CmdTerminReason Same
0 (Not accepted)
1 (Accepted)
2 (Not found)
3 (Temporarily not available)
Other value => “illegal” written to CDR (value printed)

Table 6-4: NotificationRecord Fields (Specifics)
NotificationRecord Fields (Specifics)

Access
OrglOrigAddress Original subscriber A-Number. Please User provided data. If the

refer to Table 5-3 originator is an LA, this field is set
(LOG_INTL_ADDR_ENABLED) and to the LA provided source address
Table 5-1 (PRES_ADDR_ENABLED) for (UCP OAdC or SMPP
Configuration Options. source_address).
Please refer to Table 5-5 Table

5-4
(SMSC46_ASN1_ALPHA2LASN,
SMSC45_LOGSRV_MULA_SN_IN_
MOAD, SMSC_LA_ADDRESS_
IN_NOTIF_ORGLORIG and
SMSC46_SILA_ALPHA2NETWORK
), Table 5-3 (LOG_INTL_
ADDR_ENABLED) and Table 5-1
(PRES_ADDR_ENABLED) for
OrglOrigAddressGSM Same as OrglOrigAddress; Same

formatted according to [3GPP_23040].
OrglRecipAddress Original Subscriber B-number. Same

If the original recipient is
a MULA, this field contains
the MULA short number. If the
original recipient is a SILA,
this field contains the SILA
network address.

(ROUT_ADDR_IN_RECIP,
TRANSL_RECIP_ADDR,
PRES_ADDR_ENABLED and
SILA_SHORTNUM_ENABLED), Table
5-3 (LOG_INTL_ADDR_ENABLED),
and Table 5-5, Table 5-4
(SMSC35_2ADDR_BILLING) for
OrglRecipAddress Same as OrglRecipAddress; Same

GSM formatted according to [3GPP_23040].
OrglNotifAddress Recipient of the notification. If the Same

recipient of the notification is a MULA,
this field contains the MULA Short
Number. If the recipient of the
Notification is a SILA, this field contains
the SILA network address.

(SILA_SHORTNUM_ENABLED) and
Table 5-3 (LOG_INTL_ADDR_ENABLED)
for Configuration Options.
OrglNotifAddress Same as OrglNotifAddress; Same

GSM formatted according to [3GPP_23040].


Access
SubmitDate Date this notification was generated by Same

the SMSC in format YYMMDD.
SubmitTime Time this notification was generated by Same

the SMSC in format HHMMSS –
adapted format (made unique per
recipient).
OrglSubmitDate Adapted date of submission of the Same

original SM in format YYMMDD. In
combination with the RecipAddress
this field can be used to relate this
notification to the original SM.
OrglSubmitTime Adapted time of submission of the Same

original SM in format HHMMSS. In
combination with the RecipAddress
this field can be used to relate this
notification to the original SM.
BillingIdentifier Not present. Only present if the notification

message was initiated by the UCP
message, which was submitted by
the LA, and only if that original
message had the Billing Identifier
filled in (see EMI-UCP
specification, version 4.0).
OrglOgtiAddress E.164 address (calling party global title) Not present.

of the MS serving MSC/SGSN. Present
for originating global title routed
messages, e.g. for roaming subscribers.
OrglOgtiAddressGSM Same as OrglOgtiAddress; Not present.

formatted according to [3GPP_23040].
orglOrigPointCode Point Code of the first MSC in the Not present.

message routing path.
orglUntranslOrig Field is omitted in Notification. User provided data. If the
Address originator address is an LA, this
field is set to the LA provided
source address.
This field must be used for

correlation with corresponding
CDRs using field
untranslOrigAddress of the
CDR.
orglUntranslOrig Field is omitted in Notification. Same

AddressGSM
orglRecip The original Recipient IMSI. Not present.

IntlMobileSubId
orglRecip The original Recipient PLMN Type. Not present.

NetworkType
orglOrig Identifier of Address Group which Same

AddrGroup contains the best matching address
pattern for the original Originator
address.


Access
orglRecip Identifier of Address Group which Same

AddrGroup contains the best matching address
pattern for the original Recipient
address.
origServicePrice SMRI for the originator of the SM if the Same

originator is a prepaid subscriber that is
Section 6.2.6.
recipServicePrice SMRI for the recipient of the SM if the Same

recipient is a prepaid subscriber that is
Section 6.2.6.
ppPser Requested and applied services to the Same

message (Prepaid Primary Services).
ppAser Requested and applied services to the Same

message (Prepaid Additional Services).
ppAserDuringJam Requested and applied services to the Same

During Jam). Bits within
ppAserDuringJam indicate which
additional services were granted during
a JAMMED state of the prepaid system
interface.
ppAserFree Requested and applied services to the Same
Free). Bits within ppAserFree indicate
which additional services were FREE.
origSPBPStatus Status code resulting from the prepaid Not present
debit transaction for the SMS originator.
orglNotifDate Real date of notification generation in Same
format YYMMDD. In combination with
RecipAddress, this field can be used
to relate this notification to the original
SM.
orglNotifTime Real time of notification generation in Same
format HHMMSS. In combination with
RecipAddress, this field can be used
to relate this notification to the original
SM.
cServicesNTF Requested services applied to a Same
message
(C-Services). Please refer to section
6.2.1.
dServicesNTF Requested and applied services to the Same

Section 6.2.1.
importance Identifies message importance level. Same

The values are:
1 – High importance
0 – Normal importance
Table 6-5: SummaryRecord Fields (Specifics)

SummaryRecord Fields (Specifics)

Access
total_ud_length Accumulated length (value of TP-UDL, i.e. Same

user data header for GSM and text length)
of data of all segments accepted.
submission_time_ Submission time of the first received Same

first segment.
submission_date_ Submission date of the first received Same

first segment.
submission_time_ Submission time of the last received Same

last segment.
submission_date_ Submission date of the last received Same

last segment.
delivery_time_first Delivery outcome time of the first Same

segment.
delivery_date_first Delivery outcome date of the first Same

segment.
delivery_time_last Delivery outcome time of the last Same

segment.
delivery_date_last Delivery outcome date of the last segment Same
segments_accepted Number of segments accepted Same

(submission logging only).
segments_delivered Number of segments successfully Same

delivered.
segments_duplicate Number of duplicate segments delivered. Same
segments_replaced Number of replace segments delivered. Same
totalAttempts Accumulated number of delivery attempts Same

of all message segments.
segmError Message Error of the last failed segment Same

delivery when its value is more than 0.
NewServicesCM NewServices bits Same
lang CDMA, Language Indicator SMPP Language Indicator.
cbat TDMA, Call Back Number Alpha Tag SMPP Call Back Number
Alpha Tag.
originating_LASN None (does not make sense). Originator LASN.
recipient_LASN Recipient LASN Recipient LASN.
isr_flags None (does not make sense). Requested and applied services
to the message – specific for ISR.
Please refer to Section 6.2.1
deliveryAttempts Message Try Count Message Try Count
totalAttempts Sum of the message try count of all the Sum of the message try count of
segments. all the segments.
genericUrgencyLevel Urgency Indicator SMPP: Priority Flag

SummaryRecord Fields (Specifics)

Access
ifaceUrgencyLevel Effective urgency level as (would be) The effective urgency level as
given on the submission interface as a (would be) given on the
physical number. submission interface as a physical
number.
cServicesCM Requested and applied services to the Same

message (C-Services). Please refer to
Section 6.2.1.
dServices Requested and applied services to the Same

Section 6.2.1.
Table 6-6: Alert Record Fields
AlertRecord Fields
recipAddress Address of the Mobile/LA for which the UCP31: the content of the AdC field.
alert is received. UCP60 with implicit alert: LA network
address.
SMPP bind: LA network address
recipLASN None Short number of the LA initiating the

alert.
submitDate Date alert was received by SMSC. Same
submitTime Time alert was received by SMSC. Same
untransl Same as recipAddress (pre-address Same as recipAddress (pre-address

RecipAddress translation). translation).
Table 6-7: Fax Report Record Fields
Fax ReportRecord Fields
Field Contents in case of MO Access Contents in case of

non-MO Access
faxOrigAddress Address Subscriber requiring Fax Report. N/A
faxRecipAddress Address Recipient of Fax Report. N/A
status Delivery status Fax Report. N/A
faxDeliveryDate Delivery Date Fax Report (if delivery fails, date of the N/A
last delivery attempt).
faxDeliveryTime Delivery Time Fax Report (if delivery fails, time of the N/A
last delivery attempt).
faxFirst Date of first delivery attempt. N/A

DeliveryDate
faxFirst Time of first delivery attempt. N/A

DeliveryTime
faxLast Date of last delivery attempt. N/A

DeliveryDate

Fax ReportRecord Fields
Field Contents in case of MO Access Contents in case of

non-MO Access
faxLast Time of last delivery attempt. N/A

DeliveryTime
numberOfPages Number of Pages of the Fax Report. N/A
numberOf Number of Delivery Attempts of the Fax Report. N/A

Attempts
Table 6-8: Failed Login Record Fields
Failed Login Record Fields
userType N/A Type of user that failed to login. See

Table 6-1.
userAddress N/A Address of user that failed to login.
netwAddress N/A Network Address of user that failed to

login.
failReason N/A Reason of the login failure. See Table

6-1.
failDate N/A Date of the failed login.
failTime N/A Time of the failed login.
Table 6-9: Send Routing Info Record Fields
Send Routing Info Record Fields
Field Contents
scAddress Service Center Address in Send Routing Info request
untransl Untranslated MSISDN in Send Routing Info request

RecipAddress
phishingIndicator Set if a Send Routing Info request was detected as a phishing attempt
recipIntlMobileSub Recipient Internation Mobile Sibscriber Id

Id
recipMSC Recipient MSC
recipSGSN Recipient SGSN
ogtiAddress GT address of requestor
origPointCode Point code of requestor
rbdlFlags1 RBDL flags 1
rbdlFlags2 RBDL flags 2

6.2 CDR Field Description
6.2.1 Bit Fields
In this section, possible values for CDR bit fields are detailed along with their meaning. Bit
fields are used to indicate if certain services are present or certain conditions have occurred
in the SMSC. A bit value of zero implies FALSE. A bit value of one implies TRUE.
• Table 6-10 specifies the ASER (additional services) field.
• Table 6-11 specifies the MSER (requested services) field.
• Table 6-12 specifies the NSER (new services) field.
• Table 6-13 specifies the XSER (extra services) field.
• Table 6-14 specifies the ppAser (prepaid additional services) field. The same bit fields
apply for ppAserDuringJam and ppAserFree fields.
• Table 6-15 specifies the ppPser (prepaid primary services) field.
• Table 6-16 specifies the BSER (Boolean services) field.
• Table 6-17 specifies the BSER_NOTIF (Boolean services applied to a notification

record) field.
• Table 6-18 specifies the BSER_CM (Boolean services applied to a summary record)
field.
• Table 6-19 specifies the ISR flags field.
• Table 6-20 specifies the NewServicesCM field.
• Table 6-21 specifies the CSER (C-Services) field.
• Table 6-22 specifies the CSER_CM (C-Services applied to a summary record) field.
• Table 6-23 specifies the DSER (D-Services) field.
• Table 6-24 specifies the DSERNTF (D-Services applied to a notification record) field.
• Table 6-25 specifies the CSERNTF (C-Services applied to a notification record) field.
Table 6-10: ASER Field Description
ASER Field Description
Bit # Bit Name Description
0 SWINQ Request to send a response to inquiry via SIW only.
1 SWDEL Request to send a response to delete via SIW only.
7 NOTIFREQ The message originator has requested text notifications (i.e. not native); particular
notification types are configured according to notification settings set by the operator,
for MO SMS notifreq applies to scan commands.
8 NOTIFALW The operator has configured that text notifications are generated automatically for MO
messages.
9 USRNOTIF The message originator has explicitly requested a specific notification type (UCP or
SMPP only).

ASER Field Description
10 LRADREQ Indicates that the (mobile/non-mobile) originator requested for last resort delivery.
26 ACKDEL TDMA flag indicating that the message contains an SME generated Delivery
Acknowledgment.
27 ACKMAN TDMA flag indicating that the message contains an SME generated Manual
Acknowledgment/ CDMA flag indicating that the message contains an SME generated
User Acknowledgment.
29 SINGLESHOT Request for one delivery attempt: single shot; SMPP datagram/transaction mode
[SMPPv34].
Table 6-11: MSER Field Description
MSER Field Description
0 SVP No default validity period for SM.
2 SDD SM requires deferred delivery.
3 NDE Generate delivery notification.
4 NND Generate non-delivery notification.
5 NBU Generate buffered message notification.
7 PRI Marked for Priority delivery.
8 UNSOL Generate Unsolicited notification (SIWIVR only).
9 LRAD SM is a Last Resort Delivery message, which is a result of the request in the original
message (ASER bit 10 LRADREQ set in the original message).
Table 6-12: NSER Field Description
NSER Field Description
2 MREP Indicates that a Message Replace PID is supplied.
3 DELETED Indicates that the SM has been deleted by the SME.
4 REPLACED Indicates that the SM has been replaced using the transparent PID.
5 LAO Indicates that the originator of the SM is an LA.
6 LAR Indicates that the recipient of the SM is an LA.
7 FWAD The SM will be sent to the forwarding FWAD address.
8 FWAD_COND Indicates that one attempt should be made to deliver the SM to the MRAD before
sending it to the FWAD.
9 CLIR Indicates that the originator address should be invisible to the recipient.
13 SWITCHED_ Indicates that only the first attempt should be made to deliver the SM to FWAD before
FWAD sending it to the MRAD.
14 FWAD_SEND Indicates that the first delivery attempt failed when conditional forwarding is in effect.
17 TRACE_COPY Indicates that the message is a copy generated by the Message Tracing option.

NSER Field Description
24 UDHI Indicates if the user data header is present.
28 DEL_BY_ Indicates that the SM has been removed with the PML command: REMOVE CLASS
OPERATOR SMH/ ADDRESS_INFORMATION).
Table 6-13: XSER Field Description
XSER Field Description
4 INQDEL MO Inquiry or Delete operation
8 SWNOTIF SIWnotif, send only notification of the SIW.
9 DL Recipient addressed via the distribution list.
15 REJDUPL Indicates if a duplicate SM should be rejected.
Table 6-14: ppAser Field Description
ppAser Field Description
0 NOTIF-BUF Buffered notification
1 NOTIF-DEL Delivery notification
2 NOTIF-NDEL Non-delivery notification
3 FORWARD-UNCOND Unconditional forwarding
4 FORWARD-COND Conditional forwarding
5 FORWARD-SWITCH-COND Switched conditional forwarding
6 LAST-RESORT-SUBS Subscriber based last resort delivery
7 LAST-RESORT-MSG Message based last resort delivery
8 PROVISION Provisioning
9 REPLY-RESP Reply response
10 SMS-COMMAND SMS command
11 UMF A copy of an SM was forwarded to the Mobile Subscriber’s Unified Mailbox.
Table 6-15: ppPser Field Description
ppPser Field Description
0 ORIG-PP Originator of an SM is a prepaid user.
1 RECIP-PP Recipient of an SM is a prepaid user.
2 ORIG-BLOCKED Originator of an SM is blocked.
3 RECIP-BLOCKED Recipient of an SM is blocked.

ppPser Field Description
4 PRIM Primary Service was associated with this SM.
5 CHARGE-RECIP Recipient is the charged party for Primary Service.
6 FREE Primary Service is FREE.
7 DURING-JAM Primary Service applied during the JAMMED state.
8 APPLIED-PMGT Port management settings were applied to Primary Service.
9 CHARGE_ORIG Originator is the charged party for Primary Service.
10 BULK_MATCH Prepaid party charged in the bulk mode.
11 DURING-JAM-ORIG Primary Service applied to the originator during the JAMMED state.
12 DURING-JAM-RECIP Primary Service applied to the recipient during the JAMMED state.
Table 6-16: BSER Field Description
BSER Field Description
1 ERARR Indicates Recipient Address Range Routing (RARR) was applied.
7 TRANSACTION-MODE Indicates that a message was handled in the transaction mode. This bit will
only be set for messages handled in transaction mode. In copies of
messages that were handled in transaction mode, this bit will be cleared
since the copy will not be handled in transaction mode.
10 UMF CDR was associated with a single SM, a copy of which was forwarded to the
Mobile Subscriber’s Unified Mailbox.
20 FSG Indicates that a message was received via the FSG.
24 REPLACE-IF-PRESENT Replace If Present flag
Table 6-17: BSER_NOTIF Field Description
BSER_NOTIF Field Description
1 ERARR Indicates that Recipient range Routing (RARR) was applied.
11 UMF CDR was associated with an SM delivery notification, a copy of which was
forwarded to the Mobile Subscriber’s Unified mailbox.
Table 6-18: BSER_CM Field Description
BSER_CM Field Description
7 TRANSACTION-MODE Indicates that a message was handled in the transaction mode.
10 UMF CDR was associated with a Concatenated Message (in case of

SummaryRecord) or a single SMS (in case of a Call Detail Record), a copy
of which was forwarded to the Mobile Subscriber’s Unified Mailbox.

BSER_CM Field Description
20 FSG Indicates that a message was received via the FSG.
For more information on RARR (option 69) and UMF (option 89) consult the SMSC
Operator Manual [OMAN].
Table 6-19: ISR FLAGS Field Description
ISR FLAGS Field Description
1 REG_DEL_NDE Registered delivery NDE (delivery notification) mask.
2 REG_DEL_NND Registered delivery NND (non-delivery notification) mask.
4 PASSED_ALONG Passed along mask.
Table 6-20: NewServicesCM Field Description
NewServicesCM Field Description
17 TRACE-COPY Indicates that the message is a copy generated by the Message Tracing
option.
Table 6-21: CServices Field Description
4 ABN Indicates that the message is an Account Balance Notification.
5 PSCR Indicates that the message is a Provisioning Scan Command Response.
11 NOTIFICATION- Suppression of sending all notifications for a message.

SUPPRESSED
20 DSR-TRIGGER Indicates that the message is a Delivery Status Report trigger.
Table 6-22: CServicesCM Field Description
Currently no bit indicators assigned.
Table 6-23: DServices Field Description
0 ARCHIVING-ORG- Indicates that of this message an originator copy has been generated.
CPY-CREATED
1 ARCHIVING-RCP- Indicates that of this message a recipient copy has been generated.
CPY-CREATED

2 ARCHIVING-IS- Indicates that this message is an archiving originator copy.

ORG-COPY
3 ARCHIVING-IS- Indicates that this message is an archiving recipient copy.

RCP-COPY
12 URGENCY-LEVEL- Indicates that urgency level of this message has been changed.
FORCED
13 OBJECT-OF- Indicates that the message was an object of a delivery attempt.

DELIVERY-ATTEMPT
14 SPOOFED-GT Indicates that the message was detected as spoofed due to GT mismatch.
15 SPOOFED-IMSI Indicates that the message was detected as spoofed due to IMSI mismatch.
16 SPOOFED-HLR Indicates that the message was detected as spoofed duo to HLR failure.
19 GTI-TRIGGER- Indicates that an external application was triggered by the message.

INVOKED
20 MESSAGE- Indicates that the message was generated via RBDL.

GENERATED-BY-
RBDL
21 GTI-SUPPRESSED Indicates that the external application decision was suppressed.
22 ACCEPTED-BY- Indicates that the message has been accepted by an early acknowledgement,
EARLY-ACK i.e. before completion of the submission process.
Table 6-24: DServicesNTF Field Description
13 OBJECT-OF- Indicates that the message was an object of a delivery attempt.

DELIVERY-ATTEMPT
Table 6-25: CServicesNTF Field Description
20 DSR-TRIGGER Indicates that the message is a Delivery Status Report (DSR) triggered by the
Delivery Status Report trigger.
6.2.2 CDR Address Fields
Each Address field in the CDR (e.g. OrigAddress, RecipAddress) consists of five sub-fields:
• TON (type of number)
• NPI (number plan indicator)
• PID (protocol identifier)
• MSISDN (address digits in numeric format)
• MSISDNUTF8 (address digits in UTF8 format)

Possible CDR values for TON, NPI and PID are detailed in Table 6-26, Table 6-27 and Table
6-28 respectively. The encoding and presentation of these address fields can be adjusted
using the O&M attributes as specified in Table 5-1 and Table 5-3. Please refer to Chapter 9
for CDR Samples.
Table 6-26: TON
TON
Value Description
0 Unknown number
1 International number
2 National number
3 Network specific
4 Short Number
5 Alphanumeric number
6 Abbreviated
7 Reserved
8 … 255 Operator Specific
Table 6-27: NPI
NPI
Value Description
0 Unknown
1 Telephone numbering plan (CCITT Rec. E.164/E.163) – PSTNA and PLMN
2 Reserved
3 Data numbering plan (CCITT Rec. X.121) – X.25 and X.29
4 Telex numbering plan – ISDN
5 SC_Specific_1: TCP/IP /LA
6 Land Mobile
7 Reserved
8 National
9 Private numbering plan
10 ERMES
11 Reserved
12 Reserved
13 Reserved
14 Internet
15 Reserved

Table 6-28: PID
PID
Value Description
0 Mobile station – PLMN
24 Global Title
34 Fax Group 3
35 Fax Group 4
36 Operator Specific
37 European Radio Message System (ERMES paging system)
56 SC-specific 1: P_Menu
57 SC-specific 2: P_PC
58 SC-specific 3: P_TAP
59 SC-specific 4: P_SMPP
60 SC-specific 5: P_WAP
61 Open Interface Specification for SMSC (OIS)
62 Voice Mail System P_VMS
204 Simple Mail Transfer Protocol – SMTP
6.2.3 Time Periods
The two periods in the ASN.1 CDR are ValidityPeriod and DefermentPeriod. They are
calculated in the SMSC as follows:
…
ValidityPeriod = MAVT – MFDT

DefermentPeriod = MFDT – MAST
…
Where:
• MAVT = message adapted validity time; this may vary from the validity time requested by
the user depending on SMSC settings.
• MFDT = message first delivery time; the time when the SMSC attempted to deliver an SM
for the first time.
• MAST = message adapted submit time; this may vary from the actual submit time of an
SM. That is, if more than one SM is submitted during one second to the same recipient,
the SMSC will increase the timestamp of each received message by one second in order
to keep timestamps unique.

Example
In this example, the SM has a validity period of 48 hours. As the message has not been
deferred (DeferIndicator = FALSE), no deferment period is present in the CDR.
VALIDITYPERIOD
HOURS
--->48
MINUTES
--->00
DEFERRED
--->NO
…
6.2.4 SMS Contents
SMS Contents and Data Coding Scheme (DCS) are written to CDR in the following manner:
DCS is only written to CDR if SMS Contents is also configured, i.e. ON. The DCS parameter
identifies the coding scheme used within the User Data. Possible values for DCS are listed in
Table 6-29. Do not confuse the values listed here with the values of the mobile protocols as
the TP-DCS defined in 3GPP TS 23.038 [3GPP_23038].
Table 6-29: DCS
DCS
Value Description
0 DEFAULT
1 DATA
2 UCS2
15 NO ALPHABET
Other UNKNOWN
The DEFAULT value represents the plain text in ISO Latin 1 ISO-8859-1, converted from
GSM 7 bit alphabet and ASCII into ISO Latin 1. The actual coding may be different because
of the operator adjustment character set mapping. The Greek characters from the GSM 7 bit
alphabet are mapped to C1 control values.
The DATA data-coding scheme represents the binary text. The “UCS2” data-coding scheme
represents the Unicode text. The Unicode Standard is the universal character-encoding
standard used for representation of the text for computer processing. Versions of the
Unicode Standard are fully compatible and synchronized with the corresponding versions
of International Standard ISO/IEC 10646. The format in which SMS Contents is printed to
CDR depends on a DCS value and also on whether a User Data Header (UDH) is present or
not in the SM.
• Case 1: DCS equals DATA or UCS2, no UDH. In this scenario, SMS Contents is printed
as Hex pairs.
• Case 2: DCS equals DATA or UCS2, UDH present. UDH and User Data (UD) are
printed on separate lines as Hex pairs.
• Case 3: DCS equals DEFAULT or NO_ALPHABET, no UDH. In this scenario, SMS

Contents is printed as ASCII characters.

• Case 4: DCS equals DEFAULT or NO_ALPHABET, UDH present. UDH and UD are
printed on separate lines as Hex pairs and ASCII characters respectively.
Example
Ring tone: DCS equals DATA and UDH present.
SMSCONTENT
USER DATA HEADER
----> 0504158100000003010201
USER DATA
---->
024A3A5DA5D185B1A585B80401A6D8E4954156968154104289209349C0920820920AB49C09248412710A2
4D49C81A410415415696815410428209349C0920830920AB49C09212710A24D49C81A4104289209352660
65041069A7206986585D041069065A6A0710410490A248268495415697815410428909349C0920920A
DCS
----> DATA
6.2.5 Teleservice Identifier
The Teleservice Identifier is written to CDR if provided by CDMA/TDMA mobile originator on

submission, or when originating SMPP LA has provided a service type on submission.
Possible internal Teleservice Identifier values are listed in Table 6-30. Besides these values,
other possible values are the actual values as defined in [3GPP2_PARAMS].
Table 6-30: Teleservice Identifier
Teleservice Identifier
Value Description
0 WMT (also known as CMT)
2 WPT (also known as CPT)
3 OATS
4 GUTS
17 VMN
18 VMA
19 WAP
20 USSD
21 OTAPA
22 OTASP
23 IMAP
24 AGPS
25 WEMT
26 CATPT
27 SCPT
Other Please refer to [3GPP_PARAMS]

Example
Teleservice Identifier equals WEMT:
TELESERVICE ID ---> 0x19
6.2.6 SMRI
The Short Message Rate Information (SMRI) specifies the service price being charged to a
prepaid user. The SMRI is retained for the primary service (delivery of the SM) and for
additional services ‘Text-Notification’ and ‘Forwarding a copy to Unified Mailbox’.
The SMRI must have been received from the PBS upon a debit request. The SMRI complies
with [ISO 4217].
Example
SMRI for originator (service price is 0.13 Euro):
ORIGINATOR SERVICE PRICE

CURRENCY ---> 978
EXPONENT ---> -2
VALUE ---> 13
6.2.7 Message Error
If the logical SMSC46_LAST_FAILURE_MERR_IN_CDR is defined, for messages delivered on a retry

attempt this field contains an error code of the last failed delivery attempt. The possible
values for the Message Error (msgError and segmError) are described in Table 6-23 and
Table 6-32.
Table 6-31: Message Error (Delivery)
Message Error (Delivery)
Value Description
0x0001 – For the interpretation of the Message Error, refer to the Delivery Interface Network Error Tables
0XFFFF in the NERR and DFR files in the SMSC$ROOT:[DATA]directory.
The delivery interface is determined by the PID value of the recipAddress field. In case of a
Recipient Range Routing scenario, the PID value of the recipAltAddress field should be
used for this purpose.
Table 6-32: Message Error (Submission)1
Message Error (Submission)
Value Description
0x0107 Originator was a Blocked Prepaid User
0x0206 Recipient was a Blocked Prepaid User
1
'Status' field has value 'rejected' (9).

6.2.8 Prepaid Debit Transaction Status
The CDR fields origSPBPStatus and recipSPBPStatus contain the result of the prepaid debit
transaction as returned by the Prepaid System in the transactionStatus field of the SPBP
prim_ack or SPBP add_ack message (in the REALTIME or BULK prepaid mode).
If the originator is a prepaid charged party, then the result is stored as origSPBPStatus. If the
recipient is a prepaid charged party, then the result is stored as recipSPBPStatus. If the
SMSC is configured to charge both of the prepaid parties, the SMSC may perform a debit
transaction for each party and fills both of the fields of the single CDR. The possible values
of the origSPBPStatus and recipSPBPStatus are defined in [SPBP]. The SPBPStatus fields are
filled only for the following prepaid services:
• Primary Service
• Additional Services for the different types of notifications
• Additional Service Unified Mailbox Forwarding.
The SPBPStatus fields are included in the CDR only if the received transaction status is other
than ‘0000’. If the SMSC has currently no open session with the Prepaid System, or the
transaction times out before receiving a response, the respective SPBP status field is filled
by the SMSC using the following reserved values:
• 0x2000 debit message could not be sent (no session, jammed interface)
• 0x2001 debit transaction timed out, no acknowledgement received.
The intended application is to facilitate offline charging of prepaid users when the online
prepaid transaction failed for some reason.

7 Toll Ticketing CDR Format
Toll Ticketing (TT) is based on Ericsson Toll Ticketing format and is, therefore, compatible
with Ericsson billing systems. It is a fixed length format, not binary encoded, but in the
readable ASCII format. The length of one TT billing record is 98 bytes. The Ericsson Toll
Ticketing format is described in their CME 201 R3 (document LM/M-92:407 and 1/190 83
CNT 215 1352). Please note that with the TT format far less fields are available than with the
ASN.1 format.
7.1 Toll Ticketing Format

Table 7-1 defines the Toll Ticketing billing format.
The Ericsson Toll Ticketing specification requires that, in the mobile-to-mobile traffic case,
both MO and MT records be produced. It is not possible to produce only MO or only MT
records. Record filtering by IDI fields only applies to Log Requests and not to the creation of
Toll Ticketing Call Detail Records.
Table 7-1: Toll Ticketing Record Definition
Toll Ticketing Record Definition
Field Size2 Type Description
Record type 2 HEX TT record type: ‘E1’ = Mobile Terminated, ‘F1’ = Mobile Originated, ‘F9’ =
Fax Report).
Input/output 1 DEC Protocol used for input/output of SMs in SMSC:
module 1 = PC (UCP/SMPP/OIS) 2
= MENU
3 = IVR
4 = GSM-PLMN
5 = “This value is not applied”
6 = FAX
7 = VMS/VSMPP
8 = ERMES
9 = TAP
Access 1 DEC Access module used:
module 1 = X25/X29
2 = Reserved for future use
3 = PSTNA (modem)
4 = “This value is not applied”
5 = MAP (EMAP/GIW)
6 = ISDN
7 = Private
8 = TCP 9
= “This value is not applied”
If the value is ‘7’ and record type is ‘F1’, the ‘B-subscriber number’ should
be interpreted as a LASN. If the value is ‘7’ and record type is ‘E1’, the ‘CLI
number’ should be interpreted as an LASN. This will be the case for a
MULA.
A-subscriber 18 HEX Number of the message originator OR number of the subscriber who
number requested the fax report service. If the A-subscriber address is an LA, this
field is set to the LASN if the SMSC46_TT_ALPHA2LASN logical is set to
YES and the source address is of type Alphanumeric. Otherwise, it will be
set to the LA provided source address.
2
Size is in units of bytes.

Toll Ticketing Record Definition
Field Size2 Type Description
B-subscriber 18 HEX Number of the message recipient OR fax number to which the fax report is
number sent. If the B-subscriber address is an LA, this field is set to the LA ID
(Short Number) if LOGSRV_COMMON attribute
SILA_SHORTNUM_ENABLED=ON. Otherwise, this field is set to Short
Number only if the B-subscriber is a MULA.
GSM 2 HEX GSM Teleservice code OR ‘00’ for the fax report service record.
Teleservice
code
Requested 3 DEC Special services requested by the originator.

Services Digit 1: (0/1) non-default validity period
Digit 2: (0/1) deferred delivery
Digit 3: (0/1) notification(s) requested
OR
Number of delivery attempts of the fax report.
Delivery 1 DEC 1 = Not delivered
Status 2 = Delivered
3 = Submitted
Number of 3 DEC The number of characters in the message OR number of pages of the fax
characters report.
Time of arrival 6 DEC Format: hhmmss, time a SM arrived at the SMSC OR Delivery time of the
at SC fax report, or if delivery fails, the time of the last delivery attempt.
Date of arrival 6 DEC Format: YYMMDD, date an SM arrived at the SMSC OR Delivery date of
at SC the fax report, or if delivery fails, the date of the last delivery attempt.
SC address 18 DEC Address of the SMSC
CLI number 18 HEX CLI number OR LASN. If the A-subscriber address is an LA, this field is set
to the LA ID (Short Number) if attribute SILA_SHORTNUM_ENABLED=YES.
Otherwise, this field is set to Short Number only if the A-subscriber is a
MULA. In case of a fax report, the CLI number, if present, will contain the
fax requestor’s number. In other cases the CLI is the TCP/IP network
address of the LA and the connection port.
Note: The presence of the CLI number is optional.
Terminator 1 ASCII A record terminating character, represented within the VMS-RMS file
system as an ASCII LF (line feed).
For Toll Ticketing, the message type (i.e. MO-MT, MO-FAX) is represented by the Record
type, Input/Output (I/O) module and Access module. The Record type can be Mobile
Terminated (MT), Mobile Originated (MO) or Fax Report. The I/O module determines the
application protocol that is used and the Access Module determines the network/transport
protocol used by the I/O module. The following rules apply to the Input/Output module field
and the Access Module field for MO and MT records:
• MO records (type “F1”): I/O Module = application protocol used for message delivery.
• Access module = network/transport protocol used for message delivery.
• MT records (type “E1”): I/O Module = application protocol used for message submission.
• Access module = network/transport protocol used for message submission.
Examples:
1. Message sent from MOBILE to MOBILE:
F145 …
E145 …
F1 = Mobile Originated
4 = GSM-PLMN (Input/Output Module)
5 = MAP (Access Mode)
E1 = Mobile Terminated

4 = GSM-PLMN
5 = MAP
Note that two records (both MO and MT) are created for a message sent from a mobile to
another mobile.
2. Message sent from MOBILE to FAX:
F163 …
F1 = Mobile Originated
6 = FAX
3 = PSTNA
Note that only one record (MO) is created for a message sent from a mobile to a fax.

8 Post-Processing of Billing Files
8.1 BILLING_PP Script

The Billing files created by the LOGSRV entity do not require further processing: they can be
used as the input for external billing applications directly. Post-processing may be required to
append individual billing files from different LOGSRV entities for compatibility with pre-SMSC
3.5 billing files which were generated from the traffic log database. Acision recommends the
billing system to use the individual LOGSRV billing files directly. Post-processing is
performed by a VMS batch job called BILLING_PP.
BILLING_PP is an auto submitting VMS batch job on the SMSC account. At the start of each
job, BILLING_PP resubmits itself in the standard system batch queue. After resubmission,
the job performs the actual post-processing task that involves the concatenation and/or
renaming of all billing files. Please refer to Section 5.1 for the location of these files. The
behaviour of BILLING_PP is dependent on its parameter values in the configuration
SMSC$ROOT:[DATA]DCL_DATA.DAT file.
8.1.1 BILLING_PP Configuration
Table 8-1 lists all configurable parameters.
Table 8-1: BILLING_PP Configuration Parameters
BILLING_PP Configuration Parameters
Parameter Description Value
KEEPDAYSLOGFILE Keep days of the log file of the BILLING_PP 0-9999. Default= 2
job.
LOGSRV_LIST List of names of LOGSRV entities that List of logical names. Default=
produce LOGSRV files. LOGSRV00, LOGSRV01,
LOGSRV02
CMLOG_LIST List of names of CMLOG entities that produce List of logical names. Default=
CM CDR summary files. CMLOG00, CMLOG01, CMLOG02
APPENDFILE Append Billing files to each other. TRUE | FALSE. Default= TRUE
APPENDSIZELIMIT File size limit for the appended file. 0 is no Default= 0 (no limit)
limit, units in number of blocks.
ALLOWEMPTYFILE Allow inclusion of empty Billing files. TRUE | FALSE. Default= TRUE
FILEPATH_LIST Output file path. VMS directory specification

Default= SMSC$ROOT:[BILLING]
FILEPREFIX Output filename prefix. String. Default= CDR
FILESUFFIX Output filename suffix. String. Default= FCDR
FILESEQNR Insert 4-digit sequence number in a filename. TRUE | FALSE. Default= TRUE
FILEDATEFORMAT Insert date or timestamp period in a filename. DATE |

DATE_WITHOUT_UNDERSCORE
| TIMESTAMP. Default= DATE
RUNPERIOD Run every RUNPERIOD (hh:mm). Default= 00:15

BILLING_PP Configuration Parameters
MAXNONEWCDR Raise alarm if no new LOGSRV_CDR files HH:MM. Default 01:00

were generated by the SMSC for this period.
MAXNOREADCDR Raise alarm if no BILLING_PP output files HH:MM. Default 03:00

were read/ removed from the SMSC for this
period.
MAXNONEWLOG Raise alarm if no new LOGSRV_LOG files HH:MM. Default 01:00

were generated by the SMSC for this period.
MAXNOREADLOG Raise alarm if no LOG files were read/ HH:MM. Default 03:00
removed from the SMSC for this period.
NREXTRASTREAMS Number of extra streams. Please refer to 0-10. Default= 0

sections 5.1.2 and 5.1.4.
The naming of the output files follows the syntax:
<FILEPREFIX><EXTRAPREF>[-<nnnn>]{[_<fileday>] or [<fileday>] or
[_<begintimestamp>_<endtimestamp>]}.<FILESUFFIX>
Where:
• (FILEPREFIX) can be chosen, if the complete name (everything in front of the “.”) does
not exceed 40 characters.
• (EXTRAPREF) is “_nn_” for the extra streams (where nn is a two-digit stream number),
or “_FRH” for FRP CDR files.
• <nnnn> is optional and represents a four-digit sequence number.
• <begintimestamp> is optional and represents the (processing timestamp – 1 year) in the
yyyymmddhhmm format (for example, the begintimestamp for Jan-31-2001, 23:59 looks
like 200001312359).
• <endtimestamp> is optional and represents the processing timestamp in the
yyyymmddhhmm format.
• <fileday> is optional and represents the file closing date in the (yy_mm_dd) format (for
example, Jan-21-2000 looks like 00_01_21).
• FILESUFFIX can be chosen. Suggested is “FCDR” for the ASN.1 format and “TT” for the
TT format.
The following rules apply to configuring BILLING_PP:

• If the size of the output file would exceed APPENDSIZELIMIT on appending the next
input file, the current output file is closed and gets its final name. BILLING_PP then opens
a new output file to continue processing. When sequence numbering is enabled, the
name of the new output file equals the name of the previous output file with the sequence
number increased by one modulo 10000. Otherwise, the VMS version number is
increased by one modulo 32768.
• While appending LOGSRV files, the output file gets a temporary name. Only when
BILLING_PP has finished processing all input LOGSRV files, it will give the output file its
final name and delete all input files. Temporary files have the additional extension “_TMP”
at the end of the name.
• The name of the output file may include the end date, or both the start date-time and end
date-time. The end date is equal to the processing date of the (last) input file. The end
date-time is equal to the processing date-time of the (last) input file. The start date-time is
the end date-time minus one year for backward compatibility reasons.

Configuration changes in section
time BILLING_PP is run.
[BILLING_PP] of DCL_DATA.DAT become effective the next
8.1.2 BILLING_PP Alarm Signals
BILLING_PP will raise a DCL alarm in the following cases:

• When one of the timers [MAXNONEWCDR, MAXNOREADCDR, MAXNONEWLOG, and MAXNOREADLOG]
expires.
• When the output disk is full. BILLING_PP will stop processing input files and give the
output file its final filename.
• When the addition of the extension _TMP file fails.
• When the removal of the extension _TMP file fails.
• When disk space usage (output files) exceeds 95% (or drops below 80% again).
• When a configuration error (DCL_DATA.DAT) is detected.
8.1.3 User Specific Actions
Any user-specific actions (for instance file transfers), can be included in the script
SMSC$ROOT:[SCRIPTS]BILLING_PP_EXTRA_ACTION.COM. If present, this script is executed by
BILLING_PP at the end of each job.
The actions defined in this script should not exceed the configured RUNPERIOD.
8.2 Billing External Interface

External access to the billing files is achieved by either NFS or FTP.
8.2.1 NFS
The supported NFS configuration defines the SMSC as a server and the remote client
system as a client. The disk on the SMSC with the billing data should be mounted from the
remote client system. In order to mount disks of the SMSC system on a remote (UNIX) host,
it is necessary to configure the NFS Server of Compaq TCP/IP Services on the SMSC
system.
The NFS Server must be enabled on the SMSC system. This is done in the Server
Components Configuration Menu of the TCP/IP Network Configuration Procedure that is
started with the following command:
$ @SYS$COMMON:[SYSMGR]TCPIP$CONFIG
If the NFS Server is enabled, it can be configured. To configure the NFS Server, the
following steps must be executed:
• Add Identity: Add an identity for users of the NFS Server to the PROXY database of the
NFS Server.
• Configuration Database: Add information to the configuration database that maps an
OpenVMS disk to a Unix style path name (MAP).
• EXPORT Database: Add the path name to the EXPORT database of the NFS Server.
• Restart: Restart the NFS Server.

Examples:
1. Add Identity
The following command adds a user USER_IDENTITY to the PROXY database of the NFS
Server (USER_IDENTITY must be an OpenVMS account name. With the value -2 for UID and
GID the default user is defined):
$ TCPIP ADD PROXY USER_IDENTITY /UID=-2 /GID=-2 /HOST=*
2. Configuration Database
The following command adds the path name “/THOMAS” to the configuration database of the
NFS Server. “/THOMAS” maps to disk $1$DIA102:
$ TCPIP SET CONFIGURATION MAP “/THOMAS” $1$DIA102:
3. EXPORT Database
The path “/THOMAS/USER” is added to the EXPORT database of the NFS Server with the
command:
$ TCPIP ADD EXPORT “/THOMAS/USER” /HOST=*
4. Restart
Restarting the NFS Server to activate the new settings can be done by executing the
following two commands:
$ @SYS$COMMON:[SYSMGR]TCPIP$NFS_SHUTDOWN
$ @SYS$COMMON:[SYSMGR]TCPIP$NFS_SERVER_STARTUP
Use the following commands to check the new settings:
$ TCPIP SHOW CONFIGURATION MAP

$ TCPIP SHOW EXPORT
$ TCPIP SHOW PROXY
At the remote (UNIX) host, “$1$DIA102:[000000.USER]” (of OpenVMS node SMMS22) is

mounted to “/TOMMY” with the command:
% MOUNT –T NFS SMMS22:/THOMAS/USER /TOMMY
It is necessary to be logged in as the root to execute this command. The directory /TOMMY
must exist before using the mount command.
Use the following command for help with Compaq TCP/IP Services management
commands:
$ TCPIP HELP
8.2.2 FTP
FTP is the well-known File Transfer Protocol and can be used to copy files from and to a
remote system. If the FTP is used to transfer billing files to a remote system, it is advised to
use:
• The BINARY mode for transferring ASN.1 formatted billing files

• The ASCII mode for transferring TT formatted billing files.
8.3 FCDR_DECODE
FCDR_DECODE is the ASN.1 to CDR text format decoder. The following symbol must be
available:
$ FCDR_DECODE :== $SMSC$ROOT:[BIN]FCDR_DECODE
To run the decoder:
$ FCDR_DECODE <ASN.1 input billing file name> <CDR text file output name>
FCDR_DECODE is a tool provided for the Acision engineering personnel only; no warranty
on the correctness of the output. Usage as business tool is not allowed to convert ASN.1
CDRs to text CDRs.
8.4 BPP_TELEP
For the Next Generation SMSC to be compatible with the Telepath SMSC billing format, a
billing post-processor called “BPP_TELEP” has been created that converts the Next
Generation SMSC ASN.1 billing-files into the Telepath format.
This new billing post-processor has roughly the same functionality as the billing post-
processor which is available on the Telepath platform:
• The selection, order and representation of fields in output records are configurable.
• The format of the output can be freely configured using either predefined formats or using
a manually customisable format string.
• A header and/or footer with configurable contents can be added to each output file.
• The separators used between record-, header-, and footer-fields are configurable. Also
the XML output can be generated, if required.
Some additional functionality is added to bridge gaps between the Next Generation billing
and Telepath billing:
• If a Telepath output field has no Next Generation equivalent its output value is retrieved
from a by field configurable default storage.
• Since a Next Generation SMSC does not provide a useful equivalent for the Telepath
field “Call Reference” (=field 13) this value is created by BPP_TELEP itself.
• Manually configurable tables facilitate mapping between:
− The Next Generation “Large Account Number” and the Telepath “Customer ID”.
− The Next Generation “Status” and Telepath Termination Cause, Message State and
Message Status.
− The Next Generation and Telepath Error Code.
− The Next Generation “Virtual SMSC ID” and Telepath “Virtual Service Centre ID”.
− The Next Generation “Virtual SMSC ID” and Telepath “Virtual Service Centre
Address”.
− The SMPP Service Type and Message Class number.

The utilization of this billing post-processor increases the CPU load and disk usage.
Therefore, it may degrade the overall maximum performance of the system.
8.4.1 Assumptions
In order to be able to generate the correct Telepath output, some configurations on the
SMSC are required:
• The NextGen SMSC must be configured to put only Calldetailrecords and Notification
records in the ASN.1 output.
• The NextGen SMSC must be configured to put all possible fields in the ASN.1 output.
• The NextGen SMSC must be explicitly configured to make sure all addresses are
provided in the international 614 format. This can be achieved by setting the SMSC
common OAM attribute “LOG_INTL_ADDRESSING_ENABLED”.
• Make sure BILLING_PP is configured to call
SMSC$ROOT:SCRIPTS]BPP_TELEP_EXTRA_ACTION.COM. This way BPP_TELEP is started
automatically when the new ASN.1 billing files are available.
• The Next Generation SMSC must be configured to put a sequence number in each
ASN.1 billing filename.
8.4.2 Configuration
The Operation and Maintenance of BPP_TELEP application is done via configuration files as
explained in the table below. All configuration files have the same format: each line must
contain one key-value pair, where the key and value are separated with the ‘=’character.
Table 8-2: BPP_TELEP Configuration Files
BPP_TELEP Configuration Files

BPP_TELEP.CNF Global configuration file. Mandatory parameters are SMSC$ROOT:
described in more detail in Table 8-1. [DATA]
BPP_TELEP_DEFAULTS.CNF Contains default values for each Telepath field. SMSC$ROOT:
[DATA]
BPP_TELEP_MAP.CNF Provides numbered sections for mapping SMSC ASN.1 SMSC$ROOT:
fields to Telepath fields. [DATA]
Section [0]: ASN.1 LA Short Number to Telepath
field_6, field_7: customer ID.
Section [1]: ASN.1 msgError, segmError to
Telepath field_63: Mapped Network error.
Section [2]: ASN.1 VSMSCID to Telepath field_40:
virtual service centre identification.
Section [3]: ASN.1 VSMSCID to Telepath field_57:
Source SC Address.
Section [4]: ASN.1 status to Telepath field_12:
Cause for Termination.
Section [5]: ASN.1 serviceType and Telepath
field 116: Message Class number (accepts
numbers in the decimal, hexadecimal or octal form).
Message State.
Message Status.
Configuration files in the kit contain an additional “_template” in their filenames. In customer
specific versions the “_template” will be stripped.

The configuration parameters for the global configuration file BPP_TELEP.CNF are specified
in Table 8-3.
Table 8-3: BPP_TELEP Configuration Parameters
BPP_TELEP Configuration Parameters

DIR_INPUT Location where the application looks for Next SMSC$ROOT:
Generation SMSC ASN.1 billing files. [BPP_TELEP.IN]
DIR_OUTPUT Location where the application puts processed SMSC$ROOT:
files in the Telepath format. [BPP_TELEP.OUT]
DIR_WORK Location where the application puts its output file SMSC$ROOT:
while still processing. [BPP_TELEP.WORK]
DIR_BACKUP Location where the application puts the original SMSC$ROOT:
Next Generation SMSC ASN.1 files after [BPP_TELEP.BACKUP]
processing. This directory is cleaned up at regular
intervals by the BPP_TELEP_CLEANUP script.
DIR_FAILED Location where the application puts files that were SMSC$ROOT:
not successfully processed. [BPP_TELEP.FAILED]
INFILE File pattern used for searching for Next Generation TC*ASN.0001;*
SMSC ASN.1 billing files in the DIR_INPUT
directory. The filename pattern can contain only
one dot and must end with “00”.
OUTFILE File pattern used for creating the filename of post- %m%d_%Z%H%M%S.00
processed files in the Telepath format. For testing
purposes the FORMAT_TEST value can be used.
This will create an output file with the same as the
original input file prep ended with “BPPED_”.
TIME Time pattern used for creating timestamps in the %y%m%d%H%M%S
header and footer. The time format is specified
using the “STRFTIME” style.
HEADER Specification of the header format. Use NONE to @8$%05d,@1$%04d:
indicate that no header is required. Please refer to
Table 8-4 for details or fields and their types.
Formatting is performed using “printf” style
format specifiers.
Note: Header fields must always have a fixed
length. So always use %20s instead of %s and
%9d instead of %d.
TRAILER Specification of the footer format. Use NONE to @1$%d@2$%20s@3$%20s: This
indicate that no footer is required. Please refer to format-string will print field 1, 2, 3 in
Table 8-4 for details or fields and their types. the footer without field separators.
FORMAT Specification of the record format: Use format1, Format2: This format string will print a
format2, and format 5 for predefined formats. record in the predefined format 2.
Please refer to Table 8-4 for details or fields and
their types.
FILE_DEFAULTS Specifies the file that contains default values for SMSC$ROOT:[DATA]BPP_TELEP_DE
each Telepath field. FAULTS.CNF
FILE_MAPPING Specifies the file that contains mappings between SMSC$ROOT:[DATA]BPP_TELEP_
an LA number and customer ID and mappings MAP.CNF
between a NextGen error code and Telepath error
code.
FILE_COUNTER Contains a unique identifier that is used to fill the SMSC$ROOT:[DATA]BPP_TELEP_CO
Telepath field 13 (=call reference). The value is UNTER.TXT
incremented for each processed record. The
actual value is stored on file to keep the current
value between runs of BPP_TELEP.
SCRIPT_ALARM Script that handles an alarm on behalf of the SMSC$ROOT:[SCRIPTS]BPP_TELEP
application. This mechanism allows for flexible _ALARM.COM: provides an example
operator specific alarm propagation. alarm handler script.
ALARM_SEVERITY Specifies the severity of alarming. Only alarms Fatal, Error, Warning, Info, Success.
equal or more severe than the ALARM_SEVERITY
value will be forwarded to SCRIPT_ALARM.
TRANSFER Currently, the transfer is not supported. So the NO.
value must be set to NO.
FIELD_83 Specifies the value field 83 will be filled in with. LAR, LAO, ANY.

BPP_TELEP Configuration Parameters
SMPP_SER_TYPE_TR Enables/disables the mapping of a SMPP Service ON, OFF

ANSLATION Type into a Message Class for tag 116. If OFF, the
SMPP Service Type string is converted to tag 116.
If ON, the string is mapped to a number via
FILE_MAPPING Section [5].
INCLUDE_SME_ Includes acknowledgements originating from NO or YES
ACK CDMA or TDMA handsets.
8.4.2.1 FORMAT, HEADER and TRAILER Parameters

The FORMAT parameter is used to define which fields must appear in the record output; i.e. in
what order and in what format. The HEADER parameter is used to define which fields must
appear in the header output; i.e. in what order and in what format. The TRAILER parameter is
used to define which fields must appear in the trailer output; i.e. in what order and in what
format.
The actual appearance of a field value is performed according to rules described below.
Each field has a pre-determined type. The actual type of each field can be found in Table
8-4. The following example explains the mechanism:
FORMAT=@6$%-20s@20$%03d@15$%dC@13$%.12s
This format string will make sure that the Telepath output contains 4 fields: field 6, 20, 15
and 13:
− Field 6 of the string type will appear left aligned and will use the space of 20 characters.
− Field 20 of the integer type will use the space of 3 characters and will be padded with
zeros on the left.
− Field 15 of the integer type will have the ‘C’ character after it.
− Field 13 of the string type will always take up the space of 12 characters. In situations
when the input value of field 13 is longer than 12 characters, the output value will be cut
short after the 12th character.
Table 8-4 describes all Telepath fields as they can be used in the FORMAT parameter.
Table 8-4: Format of Telepath Record Parameters
Format of Telepath Record Parameters
Index Description Origin Type Example
1 Structure Code From file defined by parameter String @1$%s

FILE_DEFAULTS
2 Calling TON/NPI String @2$%s
3 Calling Number String @3$%s
4 Called TON/NPI String @4$%s
5 Called Number String @5$%s
6 Calling Customer ID From file defined by parameter String @6$%s
FILE_MAPPING: section [0]
7 Called Customer ID From file defined by parameter String @7$%s
8 Calling Service Level From file defined by parameter Integer @8$%d
FILE_DEFAULTS
9 Called Service Level From file defined by parameter Integer @9$%d
FILE_DEFAULTS

10 Message Submission Time When orglNotifDate and String @10$%s

orglNotifTime entries are
switched ON, the BPP_TELEP
output field @10 contains MOST of
the real notification. If these entries
are switched OFF, this field
contains MAST of the
corresponding message.
11 Message Delivery Time String @11$%s
12 Cause for Termination From file defined by parameter Integer @12$%d
13 Call Reference See note at end of this table String @13$%s
14 Message Length Integer @14$%d

15 Priority Integer @15$%d
16 Deferred Integer @16$%d
17 Receipt Integer @17$%d
18 Protocol ID Character @18$%x
19 Record Type 2 byte Integer @19$%d
20 Number of Attempts Integer @20$%d
21 Message text Type Integer @21$%d
22 Message Text String @22$%s
23 Message Text Length Integer @23$%d
24 Translated Originator TON Integer @24$%d
25 Translated Originator NPI Integer @25$%d
26 Translated Originator String @26$%s
Address
27 Originator Identifier From file defined by parameter String @27$%s
FILE_DEFAULTS
28 Originator’s User Group ID Integer @28$%d
29 Untranslated Originator Integer @29$%d
TON
30 Untranslated Originator Integer @30$%d
NPI
31 Untranslated Originator String @31$%s
Address
32 Translated Destination Integer @32$%d
TON
33 Translated Destination NPI Integer @33$%d
34 Translated Destination String @34$%s
Address
35 Destination Identifier From file defined by parameter String @35$%s
FILE_DEFAULTS
36 Recipients User Group ID Integer @36$%d
37 Untranslated Destination Integer @37$%d
TON
38 Untranslated Destination Integer @38$%d
NPI
39 Untranslated Destination String @39$%s
Address
40 Billing Format Field Name From file defined by parameter Integer @40$%d
41 Message State From file defined by parameter Integer @41$%d
42 Message Status From file defined by parameter Integer @42$%d
43 Message Priority Integer @43$%d
44 Message Class Integer @44$%d
45 Retry Profile From file defined by parameter Integer @45$%d
FILE_DEFAULTS
46 Registered Information Integer @46$%d
47 Scheduled Date Type Integer @47$%d
48 Scheduled Date Integer @48$%d
49 Expiry Date Type Integer @49$%d
50 Expiry Date Integer @50$%d
51 Submit Date Type Integer @51$%d
52 Submit Date Integer @52$%d

53 Done Date Type Integer @53$%d

54 Done Date Integer @54$%d
55 Purge Date Type Integer @55$%d
56 Purge Date Integer @56$%d
57 Source SC Address From file defined by parameter String @57$%s
58 Number of Delivery Integer @58$%d
Attempts
59 Number of Legs From file defined by parameter Integer @59$%d
FILE_DEFAULTS
60 OBSOLETE Integer @60$%d
61 Message Identifier Integer @61$%d
62 Message Leg Number From file defined by parameter Integer @62$%d
FILE_DEFAULTS
63 Mapped Network error From file defined by parameter Integer @63$%d
64 Local error From file defined by parameter Integer @64$%d
FILE_DEFAULTS
65 Protocol Identifier Integer @65$%d
66 Data Coding Scheme Integer @66$%d
67 User Reference Integer @67$%d
70 Mobile Originated Integer @70$%d
Message
71 Receipt Integer @71$%d
72 ManualAck Integer @72$%d
74 MultiRecipient From file defined by parameter Integer @74$%d
FILE_DEFAULTS
75 CasDL Integer @75$%d
76 SystemDL From file defined by parameter Integer @76$%d
FILE_DEFAULTS
77 MCENotification From file defined by parameter Integer @77$%d
FILE_DEFAULTS
78 SubmitReplace Integer @78$%d
82 enumResult Integer @82$%d
83 Consolidation of LA Fixed length restricted to String @83$%.5s
Originated (restricted to 16 16 characters; padding characters @83$%s
characters) are defined by the field’s default
value in FILE_DEFAULTS.
84 Consolidation of LA Fixed length restricted to String @84$%.5s
Terminated (restricted to 16 characters; padding characters @84$%s
16 characters) are defined by the field’s default
value in FILE_DEFAULTS.
85 SM originator is a prepaid Integer @85$%d
subscriber
86 SM recipient is a prepaid Integer @86$%d
subscriber
87 Delivery Status Report Integer @87$%d
Triggering
88 RESERVED FOR Integer @88$%d
FUTURE USE
89 Mobile subscriber Identity String @89$%s
Address B-Party IMSI
90 DeliveryCode From file defined by parameter Integer @90$%d
FILE_DEFAULTS
91 Originating MSC Address String @91$%s
92 Destination MSC Address String @92$%s
95 Charging Indicator Integer @95$%d
96 Message Class PDC only From file defined by parameter Integer @96$%d
FILE_DEFAULTS

97 Electronic Serial Number From file defined by parameter Integer @97$%d

FILE_DEFAULTS
98 Mobile Subscriber Identity Integer @98$%d
TON A-party IMSI
99 Mobile Subscriber Identity Integer @99$%d
NPI A-party IMSI
100 Mobile Subscriber Identity String @100$%s
Address A-party IMSI
101 Reply Path Integer @101$%d
102 Message Mode Integer @102$%d
103 Pre-Tx Integer @103$%d
SrcAddressLength
104 Pre-Tx DstAddress Integer @104$%d
Length
105 Length of Source Address Integer @105$%d
106 Length of Destination Integer @106$%d
Address
107 PPG flag Integer @107$%d
108 PPG flag of charging Integer @108$%d
109 First item of history of From file defined by parameter integer @109$%d
Mapped Network Error FILE_DEFAULTS
110 Second item of history of From file defined by parameter Integer @110$%d
111 Third item of history of From file defined by parameter Integer @111$%d
112 Fourth item of history of From file defined by parameter Integer @112$%d
113 Fifth item of history of From file defined by parameter Integer @113$%d
114 Name of Transmitter From file defined by parameter String @114$%s
Interface FILE_DEFAULTS
115 RESERVED FOR String @115$%s
FUTURE USE
116 SMPP Service Type If the SMPP_SER_TYPE_ String @116$%s
TRANSLATION parameter is ON:
from FILE_MAPPING: section [5]
117 FSG indicator Integer @117$%d
118 Transaction mode Integer @118$%d
indicator
TELEPATH
TELEPATH
TELEPATH
TELEPATH
TELEPATH
TELEPATH
125 Urgency level forced Integer @125$%d
126 Forward Address TON Integer @126$%d
127 Forward Address NPI Integer @127$%d
128 Forward Address String @128$%s
129 Forwarding Type Integer @129$%d
130 MNP database id @130$%d

The supported combinations of the string output formats are:
• %s to copy a value from the CDR without any change;
• %.Ns to copy a value from the CDR, as follows:
o If the value length is shorter than N, the output value is unchanged.
o If the value length is greater than N, cut it short to the N length. This can be
used only for the backward compatible behaviour in situations when a new
CDR value is longer than in the previous SMSC release.
Any other values of FORMAT for the string values are not supported.
Fields and 83 can be configured for the backward compatibility behaviour.

84
To obtain the output length of 5 characters, the configuration string in the FORMAT parameter
should be set as follows:
@83$%.5s or @84$%.5s
To maintain the output length set to 16 characters, which is the current SMSC behaviour,
the configuration string in the FORMAT parameter should be set as follows:
@83$%s or @84$%s
Do not change the default length of fields 83 and 84 in the BPP_TELEP_DEFAULTS.CNF

file. That is, maintain the respective settings as follows:
83=0000000000000000
84=0000000000000000
The values defined in the file specified by the FILE_DEFAULTS parameter are static, i.e.
they do not change. The only way to modify these values is to change the value in the file.
In(SMPP
case of a conversion, the Telepath field 13 utilizes the
CALLDETAILRECORD
MESSAGE_ID) field on condition that this field is present in the CDR and the length
origMsgID
of the hexadecimal representation of the field is less than 8. In all other cases, the field 13
value is composed as follows:
The last 2 digits of the origAddress MSISDN field substitute the first 2 digits of field 13.
If the origAddress MSISDN field is not present in the CDR, the last 2 digits of the current
timestamp are used. The last 10 digits of field 13 are equal to the unique message ID in the
SMSC$ROOT:[DATA]BPP_TELEP_COUNTER.TXT file.
In case of a NOTIFICATIONRECORD conversion, the field 13 value of origMsgID is not used even
if present in the notification record. Then, the field 13 value is composed as follows:
The last 2 digits of the orglOrigAddress MSISDN field substitute the first 2 digits of field
13. If the orglOrigAddress MSISDN field is not present in the notification record, the last
2 digits of the current timestamp are used.
The last 10 digits of field 13 are equal to the unique message ID in the
SMSC$ROOT:[DATA]BPP_TELEP_COUNTER.TXT file.

Table 8-5 describes all Telepath fields as they can be used in the HEADER or TRAILER
parameter:
Table 8-5: Format Telepath Header- and Trailer Parameters
Format Telepath Header- and Trailer Parameters
Index Description Type Example
1 File ID: Four-digit sequence-number within NextGen ASN.1 filename. String @1$%d
2 Cut-off Time String @2$%s
3 Oldest Submission Time String @3$%s
4 Newest Submission Time String @4$%s
5 Oldest Delivery Time String @5$%s
6 Newest Delivery Time String @6$%s
7 Time-zone-name String @7$%s
8 Record Count Integer @8$%d
9 Time-zone in “0<hour-offset>[DC]” format String @9$%s
8.4.2.2 Parameter FIELD_83

The possible values of FIELD_83 are the following:
• If the FIELD_83 parameter is set to LAR, only the value of the CDRs CONSOLIDATION field
of the recipient’s Large Account (LAR) is stored in field 83. If the CONSOLIDATION field is
not present, the default value (0000000000000000) is used.
• If the FIELD_83 parameter is set to LAO, only the value of the CDRs CONSOLIDATION field
of the originator’s Large Account (LAO) is stored in field 83. If the CONSOLIDATION field is
not present, the default value (0000000000000000) is used.
• If the FIELD_83 parameter is set to ANY, the value of any present CDRs consolidation
field is stored in field 83. If the consolidation field is not present, the default value
(0000000000000000) is used.
8.4.3 Usage
8.4.3.1 Command Line Parameters

The BPP_TELEP requires the following command line arguments:
• Configuration file: Global Configuration file.
• Instance ID: This allows multiple instances of BPP_TELEP to run simultaneously.
• Log level: determines the detail of logging.
• Log directory: determines the directory where log files are put.
8.4.3.2 Automatic Start-up

While in production, the BPP_TELEP runs on the Next Generation SMSC and will
automatically be started by the “BILLING_PP” process using the
BPP_TELEP_EXTRA_ACTION.COM script.
8.4.3.3 Interactive Start-up

While testing, the application can be started manually on the command line. The example
below provides information on which command line arguments are required:
$ BPP_TELEP :== $SMSC$ROOT:[BIN]BPP_TELEP.EXE

$ BPP_TELEP
Usage: BPP_TELEP.EXE;1 cfg-file instance-id trc-level trc-dir
image file identification: “0.0.1”

Compiled on Nov 4 2004 at 10:25:37
The example below provides information on how to start up the application manually:
$ BPP_TELEP BPP_TELEP.CNF 1 info SMSC$ROOT:[LOG]

Using trace-file SMSC$ROOT:[LOG]BPP_TIGER1_1_2004101509.TRC
8.4.3.4 Logging
Each hour a new log file is generated in the directory specified on the command line. Log
files conform to the following filename convention:
bpp_<node-name>_<instance_id>_<timestamp>.trc
The following log levels are available:

• Fatal
• Error
• Warning
• Notice
• Info
• Debug
For performance reasons the “notice”, “info” and “debug” log levels will not be used in a
production environment.
8.4.3.5 Cleanup
The cleanup of temporary, unneeded files (backups and log files) is performed by the
BPP_TELEP_CLEANUP.COM script. This script is started automatically by
BPP_TELEP_EXTRA_ACTION.COM. The number of days that files must be kept can be
configured in BPP_TELEP_CLEANUP.COM.
Files that could not be processed are moved to the directory specified by parameter
DIR_ERROR. This directory is never automatically cleaned up.

9 CDR Samples
9.1 Billing Samples File Naming Conventions

The naming of the CDR samples billing files corresponds with the Traffic Scenario number
described in this document and the billing set-up profile used. The billing CDR file sample
has the following format:
File Name ::= TC<tc_id>P<p_id>[sum]_ASN.[0001|TXT]

where
tc_id - Traffic Scenario identifier
p_id - billing configuration profile identifier
sum - optional suffix identifying summary CDR
0001 - file extension used for ASN.1 encoded files
TXT - file extension used for the text format generated by FCDR_DECODE tool
9.2 Billing Configuration Profile Descriptions

There are four profiles chosen for billing CDR examples. The SMSC billing parameter
settings are grouped to reflect the major changes in the CDR billing output. These settings
are also most commonly used by the billing set-ups of the mobile operators. For all CDR
samples the SMSC submission logging is enabled.
The corresponding FCDR_FIELDS.CNF configuration file, used for billing samples creation,
is supplied together with the CDR samples package.
9.2.1 Configuration Profile P01
This configuration billing profile includes the following settings:
Table 9-1: Configuration Profile P01
Configuration Profile P01
SMSC O&M Class Attribute Value
SMSC_COMMON LOG_INTL_ADDR_ENABLED ON
SSD_COMMON TRANSL_ADDR_PID_REC ON
LOGSRV_COMMON SILA_SHORTNUM_ENABLED ON
LOGSRV_COMMON ROUT_ADDR_IN_RECIP OFF
LOGSRV_COMMON TRANSL_RECIP_ADDR ON
The configuration profile P01 is a preferred profile to be used for new system rollouts.

SMSC O&M class Attribute Value
SMSC_COMMON LOG_INTL_ADDR_ENABLED OFF
SSD_COMMON TRANSL_ADDR_PID_REC ON
LOGSRV_COMMON SILA_SHORTNUM_ENABLED OFF
LOGSRV_COMMON ROUT_ADDR_IN_RECIP OFF
LOGSRV_COMMON TRANSL_RECIP_ADDR ON
This profile is recommended for new SMSC rollouts where the national address format is the
preferred format for the billing processing systems. By changing LOGSRV_COMMON
setting SILA_SHORTNUM_ENABLED to ON, the operator can enable SMSC to generate
SN into the address fields for a Single Address LA.
SMSC O&M class Attribute Value
SMSC_COMMON LOG_INTL_ADDR_ENABLED ON
SSD_COMMON TRANSL_ADDR_PID_REC OFF
LOGSRV_COMMON SILA_SHORTNUM_ENABLED ON
LOGSRV_COMMON ROUT_ADDR_IN_RECIP ON
LOGSRV_COMMON TRANSL_RECIP_ADDR OFF
This configuration profile is advised to be used for systems that are upgraded from previous
SMSC versions (younger than SMSC 4.6) where billing processing systems are not yet
adjusted to process billing files generated with configuration profile P01.
This configuration billing profile includes the following logical:
$ define SMSC35_2ADDR_BILLING “YES”
Configuration billing profile P04 is using the same SMSC attribute settings as configuration
profile P03, defined in section 9.2.3. The configuration profile P04 is designed to be used for
systems that are upgraded from previous SMSC versions (younger than SMSC 4.6) that use
the ALA address routing configuration option.

9.3 Traffic Scenarios
The following sections describe the logical call flows used by the SMSC for traffic scenarios.
The description includes the calling and the called party addresses, Value Added Services,
and the traffic flow trajectory.
9.4 Mobile to Mobile Successful Delivery (TC01)
9.4.1 GSM to GSM with Notification (TC01a)
The SM is submitted from the GSM mobile with address +31612101111 and the GSM Status
Report request to the GSM mobile address +31612105555.
The scenario is executed with configuration profiles: P01, P02.
9.4.2 CDMA to CDMA Delivery Acknowledgement (TC01b)
The SM is submitted from CDMA mobile +31613101111 with the delivery acknowledgement
request to the CDMA mobile +31613105555.
9.4.3 CDMA to CDMA User Acknowledgement (TC01c)
The SM is submitted from CDMA mobile +31613101111 with the user acknowledgement
request to the CDMA mobile +31613105555 that returns the empty user acknowledgement
back.
9.4.4 GSM to GSM via Public VSMSC (TC01d)
The SM is submitted from GSM mobile +31612101111 to GSM mobile +31612105555 with
the GSM Status Report request. GSM mobile +31612101111 uses public Virtual SMSC with
suffix 222 for SM submission.
9.4.5 GSM to TDMA without Status Report (TC01e)
The SM is submitted from GSM mobile +31612101111 to TDMA mobile +31882102222. The
SMSC selects the target network by means of the Routing Ranges.
9.4.6 TDMA to GSM without Status Report (TC01f)
The SM is submitted from TDMA mobile +31882102222 to GSM mobile +31612105555.
9.4.7 CDMA to iDEN (TC01g)
The SM is submitted from CDMA mobile +31613101111 to iDEN mobile +31613105555.

9.5 Mobile to Mobile Unsuccessful Delivery, ‘Permanent Error’ (TC02)
9.5.1 Failed GSM to GSM Delivery: Unknown Subscriber (TC02a)
The SM with the GSM Status Report request is submitted from GSM mobile +31612101111
to GSM mobile +3161210555544441. The delivery failed because of the following reason:
Unknown subscriber.
9.6 Mobile to Mobile Unsuccessful Delivery, ‘Temporary Error’ (TC03)
9.6.1 Failed GSM to GSM Delivery: Absent Subscriber (TC03a)
to GSM mobile +31612108888. The SMSC performs 5 attempts to deliver the message (first
delivery attempt plus four retries); for every delivery attempt the HLR ‘Absent Subscriber’
Temporary Error is received. The message is expired.
9.7 Mobile to UCP Large Account (TC04)
9.7.1 GSM to Single Address LA (TC04a)
directly to the Single Address LA 100. The LASN is filled in as the recipient address.
The scenario is executed with configuration profiles: P01, P02, P03, and P04.
9.7.2 GSM to Multiple Address LA (TC04b)
The SM with the notification request is submitted from GSM mobile +31612101115 directly to
the Multiple Address LA 200. The LASN is filled in as the recipient address.
9.7.3 GSM to Multiple Address LA via RARR – Short Number Range (TC04c)
The SM with the notification request is submitted from GSM mobile +31612101115 to the SN
222. The SN range 222 is routed (RARR) to the Multiple Address LA 200.
9.7.4 GSM to Multiple Address LA via RARR – Mobile Number Range (TC04d)
to mobile number +31652103333. The +31612101116 mobile number is routed (RARR) to
the Multiple Address LA 200.

9.8 Mobile to SMPP Large Account (TC05)
9.8.1 GSM to Single Address LA via RARR – Short Number Range (TC05a)
to the SN 333. The SN 333 is routed (RARR) to the Single Address SMPP LA 300.
9.8.2 GSM to Multiple Address LA via RARR – Short Number Range (TC05b)
to the SN 444. The SN 444 is routed (RARR) to the Multiple Address SMPP LA 400.
9.8.3 GSM to Multiple Address LA via RARR – Mobile Number Range (TC05c)
to mobile number +31652101212. The +31652101212 mobile number is routed to the
Multiple Address SMPP LA 400.
9.9 LA to Mobile (TC06)
9.9.1 Single Address UCP LA to Mobile (TC06a)
The SM with the Notification request is submitted by the single address UCP LA 100 (UCP
51 message) with OAdC 0031658780001 to mobile recipient 0031611201001.
Please note that the SMSC does not create a CDR notification record for the messages
submitted by the single address UCP LA, while the delivery notification message itself is
created.
9.9.2 Multiple Address UCP LA to Mobile (TC06b)
The SM with the Notification request is submitted by the multiple address UCP LA 200 (UCP
51 message) to mobile recipient 0031612101118.
9.9.3 Single Address SMPP LA to Mobile (TC06c)
The SM with the REGISTERED_DELIVERY parameter set to 1 (SMSC Delivery Receipt requested
where the final delivery outcome is delivery success or failure) is submitted by the single
address SMPP LA 300 (SUBMIT_SM message) with SOURCE_ADDRESS 31667772121 (source
address TON 1, source address NPI 1), to mobile recipient number 31612101117; TON is
set to 1, NPI is set to 1.

9.9.4 Multiple Address SMPP LA to Mobile (TC06d)
The SM with the REGISTERED_DELIVERY parameter set to 1 is submitted by the multiple

address SMPP LA 400 (SUBMIT_SM message) to mobile recipient number 31612101117; TON
is set to 1, NPI is set to 1.
9.10 Large Account to Large Account (TC07)
9.10.1 UCP Large Account to UCP Large Account via Short Number (TC07a)
The SM with the Notification request is submitted by the UCP LA 100 to the Short Number
222. The Short Number Range 222-222 is routed to the UCP LA 200.
9.10.2 UCP Large Account to SMPP Large Account via Short Number (TC07b)
The SM with the Notification request is submitted by the UCP LA 200 to the Short Number
444. The short number range 444-444 is routed to the multiple address SMPP LA 400.
9.10.3 SMPP Large Account to UCP Large Account via Mobile Number (TC07c)
The SM with the REGISTERED_DELIVERY parameter set to 1, is submitted by the SMPP LA 400
to mobile number 31615551001 (TON = 1, NPI = 1). No notification address is specified. The
31615551001 mobile number is routed (RARR) to the single address UCP LA 100.
9.10.4 SMPP Large Account to UCP Large Account via Short Number (TC07d)
The SM with the REGISTERED_DELIVERY parameter set to 1 is submitted by the SMPP LA 400
to the Short Number 333. The short number 333 is routed (RARR) to the UCP LA 300.
9.11 Full SMS Content, UCP LA to GSM Mobile (TC08)
9.11.1 Full SMS Content Regular Text (TC08a)
The SM with full message content, 160 characters of normal text (7-bit alphabet), is
submitted from the UCP LA 200 to mobile number 31623104242.
9.11.2 Full SMS Content Unicode Text (TC08b)
The SM with full message content, 70 characters of Unicode Text, is submitted from the
UCP LA 200 to mobile number 31623104242.

9.11.3 Binary Data without UDH (TC08c)
The SM with 140 bytes of binary data without UDH is submitted from the UCP LA 200 to
mobile number 31623104242.
9.11.4 Binary Data for Nokia Ringtone (TC08d)
The CM of two segments containing the Nokia Ringtone is submitted from the UCP LA 200
to mobile number 31623104243. Both the segments are delivered to the mobile. The SMSC
together with the normal billing records generates summary CDR records for the
concatenated message.
9.11.5 Concatenated Message of Three Segments, Regular Text (TC08e)
The CM of three segments containing normal text is submitted from the UCP LA 200 to
mobile number 31623104243. All three segments are delivered to the mobile. The SMSC
together with the normal billing records generates summary CDR record for the
concatenated message.
9.12 MSC Addresses for Roaming Subscribers (Global Titles) (TC09)
9.12.1 GSM to GSM Mobile with ITU Global Title addressing for Originator and
Recipient MSCs (TC09a)
The SM is submitted from GSM mobile 31615551212 to GSM mobile 31615558989; while
the SMSC is configured to route messages on global titles for these address ranges.
9.13 Alphanumeric LA to Mobile (TC011)
9.13.1 Single Address Alphanumeric UCP Large Account to Mobile (TC011a)
The SM is submitted by the Single Address UCP LA 100 with OAdC ALI_G to mobile
number +31611201001. For the LA 100, the consolidation field is configured with the
following value: CNS1.
9.14 Mobile to Distribution List (TC012)

Two mobile numbers – 0031724441111 and 0031724442222 – are configured as members
of distribution list 3 for SMSC subscriber 0031694551001. The SM is submitted from GSM
mobile +31694551001 to the recipient number 3. The SM is delivered to both the mobiles in
the distribution list.

9.15 Mobile to Mobile, Unconditional Forwarding (TC013)
Mobile number 0031735551111 is configured as a forwarding address for SMSC subscriber
0031694551002. The SM with a GSM Status Report request is submitted from GSM mobile
31694551004 to the recipient number 0031694551002. The SM is delivered to the
forwarding address from the first delivery attempt.
9.16 Mobile to Mobile, Conditional Forwarding (TC014)

Mobile number 0031735552222 is configured as conditional forwarding address for SMSC
subscriber 0031694551003. The SM with a status request is submitted from GSM mobile
31694551004 to the recipient number 0031694551003. The mobile with the 0031694551003
address is switched off. The SM is delivered to forwarding address 0031735552222.
9.17 Mobile to Mobile, Switched Forwarding (TC015)

The SMSC has the Switched Forwarding option switched on:
PML> SET CLASS SSD_COMMON /SWITCHED_FWAD_ENABLED=ON
Mobile number +31735553333 is configured as the forwarding address for SMSC subscriber
+31694551005. The SM with a status request is submitted from GSM mobile +31694551004
to mobile recipient +31694551005. The mobile with address +31735553333 is switched off.
According to the switched forwarding functionality the first delivery attempt is performed to
recipient +31735553333 and all the other delivery attempts are performed to the original
recipient address +31694551005. The SM is delivered to mobile number +31694551005.
9.18 Mobile to Mobile, with EMS (TC016)

The SM with a status request containing message text and EMS formatted small picture is
submitted from GSM mobile +31612103232 to mobile recipient +31612107878.
The SM with a status request containing message text with EMS formatted SM text
formatting is submitted from GSM mobile +31612104242 to mobile recipient +31612106868.
The SM with a status request containing message text with EMS formatted small animation
is submitted from GSM mobile +31612105252 to mobile recipient +31612109898.
All three messages are delivered to their recipients. All billing records for the sequence of
messages described above are generated into the same billing file.

Appendix A. IDI Filtering
# The IDI fields that support IDI filtering are:

# B_MOAD_PID
# B_MOAD_NPI
# B_MOAD_TON
# T_MOAD_ADDRESS
# B_MRAD_PID
# B_MRAD_NPI
# B_MRAD_TON
# T_MRAD_ADDRESS
# B_CLI_PID
# B_CLI_NPI
# B_CLI_TON
# T_CLI_ADDRESS
# B_NRAD_PID
# B_NRAD_NPI
# B_NRAD_TON
# T_NRAD_ADDRESS
# T_OGTI_ADDRESS
# T_DGTI_ADDRESS
# T_REC_IMSI_MCC
# T_REC_IMSI_MNC
# T_REC_IMSI_MSIN
# T_OIMS_MCC
# T_OIMS_MNC
# T_OIMS_MSIN
# L_OPCO
# L_DPCO
# B_MREP
# B_MRPL
# B_MSTA
# B_MTYP
# B_VCTP
# L_ASER
# L_LASN
# L_NSER
# T_CONS
# W_MSER
# W_VSMC
# W_XSER
# W_PORT
# T_BILLID
# B_LANG
# T_CBAT
# L_PP_PSER
# L_PP_ASER
# L_PP_ASER_DURING_JAM
# L_PP_ASER_FREE
# L_PP_ASER_RECIP
# W_PP_ADDR
# L_BSER
# L_OLASN
# L_NPTYP
# W_OAGR
# W_RAGR
# L_CSER
# L_DSER
# B_OMOD_PID
# B_OMOD_NPI
# B_OMOD_TON
# T_OMOD_ADDRESS
# B_OMRD_PID
# B_OMRD_NPI
# B_OMRD_TON
# T_OMRD_ADDRESS
# B_POAD_PID
# B_POAD_NPI

# B_POAD_TON
# T_POAD_ADDRESS
# B_PRAD_PID
# B_PRAD_NPI
# B_PRAD_TON
# T_PRAD_ADDRESS
# W_SPBP_ORIG
# W_SPBP_RECIP
# L_RBDL_FLAGS1
# L_RBDL_FLAGS2
# B_MNP_DB_ID
#
# The IDI field names starting with T_ are text string fields; B_, W_, L_ are
# number fields. The IDI fields W_MSER, L_NSER, L_ASER, L_CSER, L_DSER and
W_XSER are bitfields.
# Only write records for messages with the originator address
# starting with “0654”, recipient PID value equal to PC and
# LA number not equal to 123 or Virtual SC address equal to 321
((T_MOAD_ADDRESS sw “0654”) AND (B_MRAD_PID == 57) AND
((L_LASN == 123) OR (W_VSMC != 321)))
# Filter out messages that have any Additional service
# (because L_ASER&0xFF is only zero if L_ASER is zero) together
# with TCP/IP(Private) as the originator numbering plan identifier, or
# have any Requested Services together with a consolidation field
# saying “test”.
!(((L_ASER&0xFF) AND (B_MOAD_NPI==5)) OR ((W_MSER>0) AND (T_CONS ne “test”)))

Appendix B. CDR Customisation
Table B-1: FCDR_FIELDS_TEMPLATE.CNF
FCDR_FIELDS_TEMPLATE.CNF
callDetailRecord=ON
commandRecord=ON
notificationRecord=OFF
summaryRecord=ON
failedLoginRecord=OFF
faxReportRecord=OFF
alertRecord=OFF
sendRoutingInfoRecord=OFF
origAddress=ON
origAddress.ton=ON
origAddress.npi=ON
origAddress.pid=ON
origAddress.msisdn=ON
origAddress.msisdnUTF8=OFF
origAddressGSM=ON
origAddressGSM.ton=ON
origAddressGSM.npi=ON
origAddressGSM.msisdn=ON
recipAddress=ON
recipAddress.ton=ON
recipAddress.npi=ON
recipAddress.pid=ON
recipAddress.msisdn=ON
recipAddress.msisdnUTF8=OFF
recipAddressGSM=ON
recipAddressGSM.ton=ON
recipAddressGSM.npi=ON
recipAddressGSM.msisdn=ON
submitDate=ON
submitDate.year=ON
submitDate.month=ON
submitDate.day=ON
submitTime=ON
submitTime.hours=ON
submitTime.minutes=ON
submitTime.seconds=ON
status=ON
terminDate=ON
terminDate.year=ON
terminDate.month=ON
terminDate.day=ON
terminTime=ON
terminTime.hours=ON
terminTime.minutes=ON
terminTime.seconds=ON
lengthOfMessage=ON
prioIndicator=ON
validityPeriod=ON
validityPeriod.hours=ON

validityPeriod.minutes=ON
deferIndicator=ON
deferPeriod=ON
deferPeriod.hours=ON
deferPeriod.minutes=ON
notifIndicator=ON
notifAddress=ON
notifAddress.ton=ON
notifAddress.npi=ON
notifAddress.pid=ON
notifAddress.msisdn=ON
notifAddress.msisdnUTF8=OFF
notifAddressGSM=ON
notifAddressGSM.ton=ON
notifAddressGSM.npi=ON
notifAddressGSM.msisdn=ON
VSMSCid=ON
VSMSCtype=ON
consolidation=ON
portNumber=ON
dgtiAddress=ON
dgtiAddress.ton=ON
dgtiAddress.npi=ON
dgtiAddress.pid=ON
dgtiAddress.msisdn=ON
dgtiAddress.msisdnUTF8=OFF
dgtiAddressGSM=ON
dgtiAddressGSM.ton=ON
dgtiAddressGSM.npi=ON
dgtiAddressGSM.msisdn=ON
destPointCode=ON
ogtiAddress=ON
ogtiAddress.ton=ON
ogtiAddress.npi=ON
ogtiAddress.pid=ON
ogtiAddress.msisdn=ON
ogtiAddress.msisdnUTF8=OFF
ogtiAddressGSM=ON
ogtiAddressGSM.ton=ON
ogtiAddressGSM.npi=ON
ogtiAddressGSM.msisdn=ON
origPointCode=ON
orglSubmitDate=ON
orglSubmitDate.year=ON
orglSubmitDate.month=ON
orglSubmitDate.day=ON
orglSubmitTime=ON
orglSubmitTime.hours=ON
orglSubmitTime.minutes=ON
orglSubmitTime.seconds=ON
transparentPid=ON
mesgReplyPath=ON
recipIntlMobileSubId=ON

origIntlMobileSubId=ON
callingLineId=ON
callingLineId.ton=ON
callingLineId.npi=ON
callingLineId.pid=ON
callingLineId.msisdn=ON
callingLineId.msisdnUTF8=OFF
callingLineIdGSM=ON
callingLineIdGSM.ton=ON
callingLineIdGSM.npi=ON
callingLineIdGSM.msisdn=ON
commandType=ON
commandType.inqm=ON
commandType.delm=ON
commandType.cenq=ON
commandType.cdel=ON
commandType.cesr=ON
commandType.ccsr=ON
commandType.modm=ON
commandType.ssdl=ON
additionalServices=ON
requestedServices=ON
newServices=ON
extraServices=ON
cServices=ON
cmCServices=ON
dServices=ON
BillingIdentifier=ON
BillingIdentifierSMPP=ON
smeReference=ON
CallBackAlphaTag=ON
LanguageIndicator=ON
ppPser=ON
ppAser=ON
ppAserDuringJam=ON
ppAserFree=ON
ppAddr=ON
callDetailRecord.smsContent=OFF
callDetailRecord.smsContentDcs=OFF
callDetailRecord.rbdlFlags1=OFF
callDetailRecord.rbdlFlags2=OFF
notificationRecord.rbdlFlags1=OFF
notificationRecord.rbdlFlags2=OFF
messageReference=ON
totalUdLength=ON
submissionTimeFirst=ON
submissionTimeFirst.hours=ON
submissionTimeFirst.minutes=ON
submissionTimeFirst.seconds=ON
submissionDateFirst=ON
submissionDateFirst.year=ON
submissionDateFirst.month=ON
submissionDateFirst.day=ON
submissionTimeLast=ON
submissionTimeLast.hours=ON
submissionTimeLast.minutes=ON
submissionTimeLast.seconds=ON

submissionDateLast=ON
submissionDateLast.year=ON
submissionDateLast.month=ON
submissionDateLast.day=ON
deliveryTimeFirst=ON
deliveryTimeFirst.hours=ON
deliveryTimeFirst.minutes=ON
deliveryTimeFirst.seconds=ON
deliveryDateFirst=ON
deliveryDateFirst.year=ON
deliveryDateFirst.month=ON
deliveryDateFirst.day=ON
deliveryTimeLast=ON
deliveryTimeLast.hours=ON
deliveryTimeLast.minutes=ON
deliveryTimeLast.seconds=ON
deliveryDateLast=ON
deliveryDateLast.year=ON
deliveryDateLast.month=ON
deliveryDateLast.day=ON
cmReferenceNr=ON
currentSegment=ON
segmentsTotal=ON
segmentsAccepted=ON
segmentsDelivered=ON
segmentsDuplicate=ON
segmentsReplaced=ON
textFormatting=ON
bytesCompressedData=ON
predefinedAnimations=ON
userDefinedAnimations=ON
predefinedSounds=ON
userDefinedSounds=ON
blackWhitePictures=ON
greyscalePictures=ON
colourPictures=ON
businessCards=ON
calendarEntries=ON
polyphonicMelodies=ON
standardWvg=ON
characterSizeWvg=ON
bit8PortNumberDest=ON
bit16PortNumberDest=ON
lmsgNrSeg=ON
booleanServices=OFF
notifBooleanServices=OFF
cmBooleanServices=OFF
cmNewServices=ON
originatingLASN=OFF
recipientLASN=OFF
originatingMSGId=OFF
recipientMSGId=OFF
recipientDeliveryDate=OFF
recipientDeliveryDate.year=OFF
recipientDeliveryDate.month=OFF
recipientDeliveryDate.day=OFF
recipientDeliveryTime=OFF
recipientDeliveryTime.hours=OFF
recipientDeliveryTime.minutes=OFF
recipientDeliveryTime.seconds=OFF

ISRFlags=OFF
recipAltAddress=ON
recipAltAddress.ton=ON
recipAltAddress.npi=ON
recipAltAddress.pid=ON
recipAltAddress.msisdn=ON
recipAltAddress.msisdnUTF8=OFF
generatedSegments=ON
serviceType=ON
deliveryAttempts=ON
orglOgtiAddress=ON
orglOgtiAddress.ton=ON
orglOgtiAddress.npi=ON
orglOgtiAddress.pid=ON
orglOgtiAddress.msisdn=ON
orglOgtiAddress.msisdnUTF8=OFF
orglOgtiAddressGSM=ON
orglOgtiAddressGSM.ton=ON
orglOgtiAddressGSM.npi=ON
orglOgtiAddressGSM.msisdn=ON
orglOrigPointCode=ON
untranslOrigAddress=OFF
untranslOrigAddress.ton=ON
untranslOrigAddress.npi=ON
untranslOrigAddress.pid=ON
untranslOrigAddress.msisdn=ON
untranslOrigAddressGSM=OFF
untranslOrigAddressGSM.ton=ON
untranslOrigAddressGSM.npi=ON
untranslOrigAddressGSM.msisdn=ON
orglUntranslOrigAddress=OFF
orglUntranslOrigAddress.ton=ON
orglUntranslOrigAddress.npi=ON
orglUntranslOrigAddress.pid=ON
orglUntranslOrigAddress.msisdn=ON
orglUntranslOrigAddressGSM=OFF
orglUntranslOrigAddressGSM.ton=ON
orglUntranslOrigAddressGSM.npi=ON
orglUntranslOrigAddressGSM.msisdn=ON
untranslRecipAddress=OFF
untranslRecipAddress.ton=ON
untranslRecipAddress.npi=ON
untranslRecipAddress.pid=ON
untranslRecipAddress.msisdn=ON
untranslRecipAddressGSM=OFF
untranslRecipAddressGSM.ton=ON
untranslRecipAddressGSM.npi=ON
untranslRecipAddressGSM.msisdn=ON
orglUntranslRecipAddress=OFF
orglUntranslRecipAddress.ton=ON
orglUntranslRecipAddress.npi=ON
orglUntranslRecipAddress.pid=ON
orglUntranslRecipAddress.msisdn=ON
orglUntranslRecipAddressGSM=OFF
orglUntranslRecipAddressGSM.ton=ON
orglUntranslRecipAddressGSM.npi=ON
orglUntranslRecipAddressGSM.msisdn=ON
forwAddress=OFF
forwAddress.ton=OFF

forwAddress.npi=OFF
forwAddress.pid=OFF
forwAddress.msisdn=OFF
forwAddress.msisdnUTF8=OFF
forwAddressGSM=OFF
forwAddressGSM.ton=OFF
forwAddressGSM.npi=OFF
forwAddressGSM.msisdn=OFF
msgError=OFF
tpDCS=OFF
totalAttempts=OFF
segmError=OFF
teleserviceId=ON
genericUrgencyLevel=ON
ifaceUrgencyLevel=OFF
origAddrGroup=OFF
recipAddrGroup=OFF
origNetworkType=OFF
recipNetworkType=OFF
orglOrigAddrGroup=OFF
orglRecipAddrGroup=OFF
orglRecipNetworkType=OFF
orglRecipIntlMobileSubId=OFF
origServicePrice=OFF
origServicePrice.currency=ON
origServicePrice.exponent=ON
origServicePrice.value=ON
recipServicePrice=OFF
recipServicePrice.currency=ON
recipServicePrice.exponent=ON
recipServicePrice.value=ON
origSPBPStatus=OFF
recipSPBPStatus=OFF
orglNotifDate=OFF
orglNotifDate.year=OFF
orglNotifDate.month=OFF
orglNotifDate.day=OFF
orglNotifTime=OFF
orglNotifTime.hours=OFF
orglNotifTime.minutes=OFF
orglNotifTime.seconds=OFF
enumResult=OFF
! failedLoginRecord specific fields

userType=ON
userAddress=ON
userAddress.ton=ON
userAddress.npi=ON
userAddress.pid=ON
userAddress.msisdn=ON
netwAddress=ON
netwAddress.ton=ON
netwAddress.npi=ON
netwAddress.pid=ON
netwAddress.msisdn=ON
failReason=ON
failTime=ON
failTime.hours=ON
failTime.minutes=ON
failTime.seconds=ON

failDate=ON
failDate.year=ON
failDate.month=ON
failDate.day=ON
! faxReportRecord specific fields

faxOrigAddress=ON
faxOrigAddress.ton=ON
faxOrigAddress.npi=ON
faxOrigAddress.pid=ON
faxOrigAddress.msisdn=ON
faxRecipAddress=ON
faxRecipAddress.ton=ON
faxRecipAddress.npi=ON
faxRecipAddress.pid=ON
faxRecipAddress.msisdn=ON
faxDeliveryTime=ON
faxDeliveryTime.hours=ON
faxDeliveryTime.minutes=ON
faxDeliveryTime.seconds=ON
faxDeliveryDate=ON
faxDeliveryDate.year=ON
faxDeliveryDate.month=ON
faxDeliveryDate.day=ON
faxFirstDeliveryTime=ON
faxFirstDeliveryTime.hours=ON
faxFirstDeliveryTime.minutes=ON
faxFirstDeliveryTime.seconds=ON
faxFirstDeliveryDate=ON
faxFirstDeliveryDate.year=ON
faxFirstDeliveryDate.month=ON
faxFirstDeliveryDate.day=ON
faxLastDeliveryTime=ON
faxLastDeliveryTime.hours=ON
faxLastDeliveryTime.minutes=ON
faxLastDeliveryTime.seconds=ON
faxLastDeliveryDate=ON
faxLastDeliveryDate.year=ON
faxLastDeliveryDate.month=ON
faxLastDeliveryDate.day=ON
numberOfPages=ON
numberOfAttempts=ON
messageImportance=ON
scAddress=ON
scAddress.ton=ON
scAddress.npi=ON
scAddress.pid=ON
scAddress.msisdn=ON
recipSGSN=ON
recipSGSN.ton=ON
recipSGSN.npi=ON
recipSGSN.pid=ON
recipSGSN.msisdn=ON
sendRoutingInfoRecord.untranslRecipAddress=ON

phishingIndicator=ON
rbdlFlags1=ON
rbdlFlags2=ON
privateDataContainer=ON
origSCAddress=ON
origSCAddress.ton=ON
origSCAddress.npi=ON
origSCAddress.pid=ON
origSCAddress.msisdn=ON
origSCAddress.msisdnUTF8=ON
applicationData=ON

Appendix C. ASN.1 Tags
Table C-1: ASN.1 Tags CallDetailRecord
ASN.1 Tags CallDetailRecord
File Name TAG SIZE TAG VALUE TAG LENGTH SIZE

(Number of Octets) (Hexadecimal)) (Number of Octets)
CallDetailrecord 1 30 1
origAddress 1 A0 1
origAddress.TON 1 80 1
origAddress.NPI 1 81 1
origAddress.PID 1 82 1
origAddress.MSISDN 1 83 1
origAddress.msisdnUTF8 1 84 1
origAddressGSM 1 81 1
recipAddress 1 A2 1
recipAddress.TON 1 80 1
recipAddress.NPI 1 81 1
recipAddress.PID 1 82 1
recipAddress.MSISDN 1 83 1
recipAddress.msisdnUTF8 1 84
recipAddressGSM 1 83 1
submitDate 1 84 1
submitTime 1 85 1
Status 1 86 1
terminDate 1 87 1
terminTime 1 88 1
lengthOfMessage 1 89 1
prioIndicator 1 8A 1
validityPeriod 1 AB 1
deferIndicator 1 8C 1
deferPeriod 1 AD 1
notifIndicator 1 8E 1
notifAddress 1 AF 1
notifAddress.TON 1 80 1
notifAddress.NPI 1 81 1
notifAddress.PID 1 82 1
notifAddress.MSISDN 1 83 1
notifAddressGSM 1 90 1
Vsmscid 1 91 1
Vsmsctype 1 92 1
dgtiAddress 1 B3 1
dgtiAddress.TON 1 80 1
dgtiAddress.NPI 1 81 1
dgtiAddress.PID 1 82 1
dgtiAddress.MSISDN 1 83 1
dgtiAddressGSM 1 94 1
destPointCode 1 95 1
ogtiAddress 1 B6 1
ogtiAddress.TON 1 80 1
ogtiAddress.NPI 1 81 1
ogtiAddress.PID 1 82 1
ogtiAddress.MSISDN 1 83 1
ogtiAddressGSM 1 97 1
origPointCode 1 98 1
orglSubmitDate 1 99 1
orglSubmitTime 1 9A 1
transparentPid 1 9B 1
mesgReplyPath 1 9C 1
recipIntlMobileSubId 1 9D 1
callingLineId 1 BE 1
callingLineId.TON 1 80 1
callingLineId.NPI 1 81 1
callingLineId.PID 1 82 1


callingLineId.MSISDN 1 83 1
callingLineIdGSM 2 9F1F 1
Consolidation 2 9F20 1
portNumber 2 9F21 1
Aser 2 9F22 1
Mser 2 9F23 1
Nser 2 9F24 1
Xser 2 9F25 1
origIntlMobileSubId 2 9F26 1
Billid 2 9F27 1
Lang 2 9F28 1
Cbat 2 9F29 1
ppPser 2 9F2A 1
ppAser 2 9F2B 1
ppAserDuringJam 2 9F2C 1
ppAserFree 2 9F2D 1
reserved46 2 9F2E 1
smeReference 2 9F2F 1
smsContentDcs 2 9F30 3 1
smsContents 2 9F31 4 Variable 5
cmReferenceNr 2 9F32 1
currentSegment 2 9F33 1
segmentsTotal 2 9F34 1
textFormatting 2 9F35 1
bytesCompressedData 2 9F36 1
predefinedAnimations 2 9F37 1
userDefinedAnimations 2 9F38 1
predefinedSounds 2 9F39 1
userDefinedSounds 2 9F3a 1
blackWhitePictures 2 9F3B 1
standardWvg 2 9F3C 1
characterSizeWvg 2 9F3D 1
greyscalePictures 2 9F3E 1
colourPictures 2 9F3F 1
businessCards 2 9F40 1
calendarEntries 2 9F41 1
polyphonicMelodies 2 9F42 1
bit8PortNumberDest 2 9F43 1
lmsgNrSeg 2 9F45 1
messageReference 2 9F46 1
boolSer 2 9F47 1
origLASN 2 9F48 1
recipLASN 2 9F49 1
origMsgID 2 9F4A 1
recipMsgID 2 9F4B 1
receiptDate 2 9F4C 1
receiptTime 2 9F4D 1
Isr 2 9F4E 1
recipAltAddress 2 BF4F 1
recipAltAddress.TON 1 80 1
recipAltAddress.NPI 1 81 1
recipAltAddress.PID 1 82 1
recipAltAddress.MSISDN 1 83 1
generatedSegments 2 9F50 1
serviceType 2 9F51 1
deliveryAttempts 2 9F52 1
untranslOrigAddress 2 BF53 1
3
Please refer to Table 5-5 for SMSC 4.0 backwards compatibility.
4
Please refer to Table 5-5 for SMSC 4.0 backwards compatibility.
5
1 for smsContents length <= 127 characters
2 for 127 characters < smsContents length <= 255 characters
3 for smsContents length = 256 characters (an SMSC internal limit)


untranslOrigAddress.TON 1 80 1
untranslOrigAddress.NPI 1 81 1
untranslOrigAddress.PID 1 82 1
untranslOrigAddress.MSISDN 1 83 1
untranslOrigAddressGSM 2 9F54 1
untranslRecipAddress 2 BF55 1
untranslRecipAddress.TON 1 80 1
untranslRecipAddress.NPI 1 81 1
untranslRecipAddress.PID 1 82 1
untranslRecipAddress.MSISDN 1 83 1
untranslRecipAddressGSM 2 9F56 1
msgError 2 9F57 1
TpDCS 2 9F58 1
genericUrgencyLevel 2 9F59 1
ifaceUrgencyLevel 2 9F5A 1
teleserviceID 2 9F5B 1
origAddrGroup 2 9F5C 1
recipAddrGroup 2 9F5D 1
origNetworkType 2 9F5E 1
recipNetworkType 2 9F5F 1
origServicePrice 2 BF60 1
origServicePrice.currency 1 80 1
origServicePrice.exponent 1 81 1
origServicePrice.value 1 82 1
recipServicePrice 2 BF61 1
recipServicePrice.currency 1 80 1
recipServicePrice.exponent 1 81 1
recipServicePrice.value 1 82 1
cser 2 9F62 1
origSPBPStatus 2 9F63 1
recipSPBPStatus 2 9F64 1
billidSMPP 2 9F65 1
enumResult 2 9F66 1
dser 2 9F67 1
importance 2 9F68 1
forwAddress 2 BF69 1
forwAddress.TON 1 80 1
forwAddress.NPI 1 81 1
forwAddress.PID 1 82 1
forwAddress.MSISDN 1 83 1
forwAddress.MSISDNUTF8 1 84 1
forwAddressGSM 2 9F6A 1
privateContainer 2 9F6B 1
rbdlFlags1 2 9F6C 1
rbdlFlags2 2 9F6D 1
origSCAddress 2 BF6E 1
origSCAddress.TON 1 80 1
origSCAddress.NPI 1 81 1
origSCAddress.PID 1 82 1
origSCAddress.MSISDN 1 83 1
origSCAddress.MSISDNUTF8 1 84 1
idMNPdb 2 9F6F 1
Table C-2: ASN.1 Tags NotificationRecord
ASN.1 Tags NotificationRecord

NotificationRecord 1 61 1
orglOrigAddress 1 A0 1
orglOrigAddress.TON 1 80 1
orglOrigAddress.NPI 1 81 1
orglOrigAddress.PID 1 82 1
orglOrigAddress.MSISDN 1 83 1


orglOrigAddressGSM 1 81 1
orglRecipAddress 1 A2 1
orglRecipAddress.TON 1 80 1
orglRecipAddress.NPI 1 81 1
orglRecipAddress.PID 1 82 1
orglRecipAddress.MSISDN 1 83 1
orglRecipAddressGSM 1 83 1
orglNotifAddress 1 A4 1
orglNotifAddress.TON 1 80 1
orglNotifAddress.NPI 1 81 1
orglNotifAddress.PID 1 82 1
orglNotifAddress.MSISDN 1 83 1
orglNotifAddressGSM 1 85 1
submitDate 1 86 1
submitTime 1 87 1
orglSubmitDate 1 88 1
orglSubmitTime 1 89 1
status 1 8A 1
terminDate 1 8B 1
terminTime 1 8C 1
lengthOfMessage 1 8D 1
validityPeriod 1 AE 1
vsmscid 1 8F 1
vsmsctype 1 90 1
consolidation 1 91 1
billid 1 92 1
smeReference 1 93 1
smsContentDcs 1 94 1
smsContents 1 95 Variable 6
messageReference 1 96 1
recipLASN 1 97 1
origMsgID 1 98 1
isr 1 99 1
boolSer 1 9A 1
recipAltAddress 1 BB 1
serviceType 1 9C 1
dgtiAddress 1 BD 1
dgtiAddressGSM 1 9E 1
destPointCode 2 9F1F 1
orglOgtiAddress 2 BF20 1
orglOgtiAddress.TON 1 80 1
orglOgtiAddress.NPI 1 81 1
orglOgtiAddress.PID 1 82 1
orglOgtiAddress.MSISDN 1 83 1
orglOgtiAddressGSM 2 9F21 1
orglOrigPointCode 2 9F22 1
deliveryAttempts 2 9F23 1
orglUntranslOrigAddress 2 BF24 1
orglUntranslOrigAddress.TON 1 80 1
orglUntranslOrigAddress.NPI 1 81 1
orglUntranslOrigAddress.PID 1 82 1
orglUntranslOrigAddress.MSISDN 1 83 1
orglUntranslOrigAddressGSM 2 9F25 1
6


orglUntranslRecipAddress 2 BF26 1
orglUntranslRecipAddress.TON 1 80 1
orglUntranslRecipAddress.NPI 1 81 1
orglUntranslRecipAddress.PID 1 82 1
orglUntranslRecipAddress.MSISDN 1 83 1
orglUntranslRecipAddressGSM 2 9F27 1
msgError 2 9F28 1
tpDCS 2 9F29 1
orglOrigAddrGroup 2 9F2A 1
orglRecipAddrGroup 2 9F2B 1
recipNetworkType 2 9F2C 1
orglRecipNetworkType 2 9F2D 1
recipIntlMobileSubId 2 9F2E 1
orglRecipIntlMobileSubId 2 9F2F 1
origServicePrice 2 BF30 1
origServicePrice.currency 1 80 1
origServicePrice.exponent 1 81 1
origServicePrice.value 1 82 1
recipServicePrice 2 BF31 1
recipServicePrice.currency 1 80 1
recipServicePrice.exponent 1 81 1
recipServicePrice.value 1 82 1
ppPser 2 9F32 1
ppAser 2 9F33 1
ppAserDuringJam 2 9F34 1
ppAserFree 2 9F35 1
origSPBPStatus 2 9F36 1
recipSPBPStatus 2 9F37 1
orglNotifDate 2 9F38 1
orglNotifTime 2 9F39 1
billidSMPP 2 9F3A 1
origLASN 2 9F3B 1
nser 2 9F3C 1
enumResult 2 9F3D 1
cser 2 9F3E 1
dser 2 9F3F 1
importance 2 9F40 1
rbdlFlags1 2 9F41 1
rbdlFlags2 2 9F42 1
Table C-3: ASN.1 Tags CommandRecord
ASN.1 Tags CommandRecord

CommandRecord 1 60 1
commandType 1 80 1
origAddress 1 A1 1
recipAddress 1 A3 1
cmdTerminReason 1 85 1
vsmscid 1 86 1
vsmsctype 1 87 1
ogtiAddress 1 A8 1

ASN.1 Tags CommandRecord

ogtiAddressGSM 1 89 1
origPointCode 1 8A 1
orglSubmitDate 1 8B 1
orglSubmitTime 1 8C 1
origIntlMobileSubId 1 8D 1
callingLineId 1 AE 1
callingLineIdGSM 1 8F 1
consolidation 1 90 1
billid 1 91 1
smeReference 1 92 1
smsContentDcs 1 93 1
smsContents 1 94 Variable 7
messageReference 1 95 1
serviceType 1 96 1
tpDCS 1 97 1
origAddrGroup 1 98 1
recipAddrGroup 1 99 1
origNetworkType 1 9A 1
origLASN 1 9B 1
nser 1 9C 1
Table C-4: ASN.1 Tags SummaryRecord
ASN.1 Tags SummaryRecord

SummaryRecord 1 62 1
origAddress 1 A0 1
recipAddress 1 A2 1
status 1 84 1
vsmscid 1 85 1
vsmsctype 1 86 1
dgtiAddress 1 A7 1
dgtiAddressGSM 1 88 1
destPointCode 1 89 1
ogtiAddress 1 AA 1
7


ogtiAddressGSM 1 8B 1
origPointCode 1 8C 1
transparentPid 1 8D 1
recipIntlMobileSubId 1 8E 1
callingLineId 1 AF 1
callingLineIdGSM 1 90 1
origIntlMobileSubId 1 91 1
billid 1 92 1
ppPser 1 93 1
totalUdLength 1 94 1
submissionTimeFirst 1 95 1
submissionDateFirst 1 96 1
submissionTimeLast 1 97 1
submissionDateLast 1 98 1
deliveryTimeFirst 1 99 1
deliveryDateFirst 1 9A 1
deliveryTimeLast 1 9B 1
deliveryDateLast 1 9C 1
cmReferenceNr 1 9D 1
segmentsTotal 1 9E 1
segmentsAccepted 2 9F1F 1
segmentsDelivered 2 9F20 1
segmentsDuplicate 2 9F21 1
segmentsReplaced 2 9F22 1
textFormatting 2 9F23 1
bytesCompressedData 2 9F24 1
predefinedAnimations 2 9F25 1
userDefinedSounds 2 9F26 1
predefinedSounds 2 9F27 1
userDefinedSounds 2 9F28 1
blackWhitePictures 2 9F29 1
standardWvg 2 9F2A 1
characterSizeWvg 2 9F2B 1
greyscalePictures 2 9F2C 1
colourPictures 2 9F2D 1
businessCards 2 9F2E 1
calendarEntries 2 9F2F 1
polyphonicMelodies 2 9F30 1
boolSer 2 9F33 1
recipAltAddress 2 BF34 1
serviceType 2 9F35 1
totalAttempts 2 9F36 1
segmError 2 9F37 1
teleserviceID 2 9F38 1
origAddrGroup 2 9F3A 1
recipAddrGroup 2 9F3B 1
origNetworkType 2 9F3C 1
recipNetworkType 2 9F3D 1
prioIndicator 2 9F3E 1
validityPeriod 2 BF3F 1
validityPeriod.HOURS 1 80 1
validityPeriod.MINUTES 1 81 1
deferIndicator 2 9F40 1
deferPeriod 2 BF41 1


deferPeriod.HOURS 1 80 1
deferPeriod.MINUTES 1 81 1
notifIndicator 2 9B42 1
notifAddress 2 BF43 1
notifAddress.TON 1 80 1
notifAddress.NPI 1 81 1
notifAddress.PID 1 82 1
notifAddress.MSISDN 1 83 1
notifAddressGSM 2 9F44 1
mesgReplyPath 2 9F45 1
consolidation 2 9F46 1
portNumber 2 9F47 1
aser 2 9F48 1
mser 2 9F49 1
xser 2 9F4A 1
lang 2 9F4B 1
cbat 2 9F4C 1
ppAser 2 9F4D 1
ppAserDuringJam 2 9F4E 1
ppAserFree 2 9F4F 1
origLASN 2 9F50 1
recipLASN 2 9F51 1
isr 2 9F52 1
untranslOrigAddress 2 BF53 1
untranslOrigAddress.TON 1 80 1
untranslOrigAddress.NPI 1 81 1
untranslOrigAddress.PID 1 82 1
untranslOrigAddress.MSISDN 1 83 1
untranslOrigAddressGSM 2 9F54 1
untranslRecipAddress 2 BF55 1
untranslRecipAddressGSM 2 9F56 1
tpDCS 2 9F57 1
genericUrgencyLevel 2 9F58 1
ifaceUrgencyLevel 2 9F59 1
enumResult 2 9F5A 1
cser 2 9F5B 1
dser 2 9F5C 1
Table C-5: ASN.1 Tags AlertRecord
ASN.1 Tags AlertRecord

AlertRecord 1 65 1
recipAddress 1 A0 1
recipLASN 1 81 1
submitDate 1 82 1
submitTime 1 83 1
untranslRecipAddress 1 A4 1

ASN.1 Tags AlertRecord

Table C-6: ASN.1 Tags FailedLoginRecord
ASN.1 Tags Failed LoginRecord

(Number of Octets) (Hexadecimal) (Number of Octets)
FailedLoginRecord 1 63 1
userType 1 80 1
userAddress 1 A1 1
userAddress.TON 1 80 1
userAddress.NPI 1 81 1
userAddress.PID 1 82 1
userAddress.MSISDN 1 83 1
netwAddress 1 A2 1
netwAddress.TON 1 80 1
netwAddress.NPI 1 81 1
netwAddress.PID 1 82 1
netwAddress.MSISDN 1 83 1
failReason 1 83 1
failDate 1 84 1
failTime 1 85 1
Table C-7: ASN.1 Tag FaxReportRecord
ASN.1 Tags FaxReportRecord

FaxReportRecord 1 64 1
faxOrigAddress 1 A0 1
faxOrigAddress.TON 1 80 1
faxOrigAddress.NPI 1 81 1
faxOrigAddress.PID 1 82 1
faxOrigAddress.MSISDN 1 83 1
faxRecipAddress 1 A1 1
faxRecipAddress.TON 1 80 1
faxRecipAddress.NPI 1 81 1
faxrecipAddress.PID 1 82 1
faxRecipAddress.MSISDN 1 83 1
status 1 82 1
faxDeliveryDate 1 83 1
faxDeliveryTime 1 84 1
faxFirstDeliveryDate 1 85 1
faxFirstDeliveryTime 1 86 1
faxLastDeliveryDate 1 87 1
faxLastDeliveryTime 1 88 1
numberOfPages 1 89 1
numberOfAttempts 1 8A 1

Table C-8: ASN.1 Tag SendRoutingInfoRecord
ASN.1 Tags SendRoutingInfoRecord

SendRoutingInfoRecord 1 66 1
scAddress 1 A0 1
scAddress.TON 1 80 1
scAddress.NPI 1 81 1
scAddress.PID 1 82 1
scAddress.MSISDN 1 83 1
untranslRecipAddress 1 A1 1
phishingIndicator 1 82 1
recipIntlMobileSubId 1 83 1
recipMSC 1 A4 1
recipMSC.ton 1 80 1
recipMSC.npi 1 81 1
recipMSC.pid 1 82 1
recipMSC.msisdn 1 83 1
recipMSC.msisdnUtf8 1 84 1
recipSGSN 1 A5 1
recipSGSN.ton 1 80 1
recipSGSN.npi 1 81 1
recipSGSN.pid 1 82 1
recipSGSN.msisdn 1 83 1
recipSGSN.msisdnUtf8 1 84 1
ogtiAddress 1 A6 1
ogtiAddress.ton 1 80 1
ogtiAddress.npi 1 81 1
ogtiAddress.pid 1 82 1
ogtiAddress.msisdn 1 83 1
ogtiAddress.msisdnUTF8 1 84 1
origPointCode 1 87 1
rbdlFlags1 1 88 1
rbdlFlags2 1 89 1

Abbreviations
ADT Address Translation
APA Application Port Address
ASN Abstract Syntax Notation
ASN-BER Abstract Syntax Notation – Basic Encoding Rules
CDR Call Detail Record
CM Concatenated Message
DSR Delivery Status Report
DSRT Delivery Status Report Triggering
EMS Enhanced Message Service
ERARR Extended Recipient Address Range Routing
GSM Global System for Mobile communications
IDI Internal Data Interface
ISR Inter SMSC Router
LA Large Account
MSISDN Mobile Station ISDN Number
NPI Number Plan Indicator
O&M Operation and Maintenance
PBR Prepaid Billing Router
PID Protocol Identifier
PLMN Public Land Mobile Network
PSTN Public Switched Telephone Network
RARR Recipient Address Range Routing
SILA Single Address Large Account
SM Short Message
SMRI Short Message Rate Information
SMSC Short Message Service Centre
SPBP SMSC Prepaid Billing Protocol
TON Type of Number
VAS Value Added Services

References
[Apache] B. Laurie and P. Laurie, Apache – The Definitive Guide, 2nd edition,
O’Reilly, February 2006.
[Arehart et al] C. Arehart, N. Chidambaram, S. Guruprasad, A. Homer, R. Howell, S.
Kasippillai, R. Machin, T. Myers, A. Nakhimovsky, L. Passani, C.
Pedley, R. Taylor, M. Toschi, Professional WAP, Wrox Press Ltd,
Birmingham, 2006.
[EMI-UCP] Short Message Service Centre EMI-UCP Interface Specification
[ISO4217] ISO 4217:2001 Codes for the representation of currencies and funds
ISO Published Standard 4217, Ed. 6, April 2005
[ISR_OPG] SMSC Inter-SMSC Router (ISR) Operators Guide 5.2
[SMPPv34] Short Message Peer to Peer Protocol Specification v3.4
[SMPPv50] Short Message Peer to Peer Protocol Specification v5.0
[SMSC OMAN] Acision BV, SMSC Operator Manual 5.2, January 2008.
[SPBP] SMSC Prepaid Billing Protocol 1.6.2.
[SRF] SMSC Command Reference Manual 5.2
[3GPP_23040] 3GPP TS 23.040 V5.3.0, Technical realization of the Short Message
Service
[3GPP_23038] 3GPP TS 23.038: V5.0.0, Alphabets and language-specific
information.
[3GPP2_PARAMS] 3GPP 2 X.S0004-550-E Version 1.0, “MAP Parameters Signalling
Protocols”
[WAP] WAP Forum, Wireless Application Protocol Architecture Specification,
WAP-210-WAPArch-20010712-a, April 2006.

Version History
Version Status Date Details of Changes Author(s) Approver(s)
1.0 ISSUED 15 July 2011 Initial version Jana Gilarova Dalimil Hrabovsky
1.1 ISSUED 1 October 2012 PR060684 Dalimil Hrabovsky
2.0 ISSUED 27 March 2013 Update and TW review Jana Trnková Dalimil Hrabovsky
Hoffmanová
Document derived from Template Version 6.0 Generic Document Template – Standard
(APL_DOC_GENERIC_TEMPLATE_STANDARD.dot).


SMSC R5.4 Bim PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SMSC R5.4 Bim PDF

Uploaded by

Copyright:

Available Formats

Short Message Service Centre TM 5.

Document Version: 2.0

SMSC_R5.4_BIM Version: 2.0

2 SMSC Billing Model .......................................................................................... 14

3 Billing Scenarios ............................................................................................... 19

4 Prepaid Billing Configuration ........................................................................... 31

5 Postpaid Billing Configuration ......................................................................... 36

6 ASN.1 CDR Format ............................................................................................ 49

7 Toll Ticketing CDR Format ............................................................................... 91

8 Post-Processing of Billing Files ...................................................................... 94

9 CDR Samples................................................................................................... 108

SMSC_R5.4_BIM Version: 2.0

SMSC_R5.4_BIM Version: 2.0

Abbreviations ......................................................................................................... 136

References ............................................................................................................. 137

Version History ...................................................................................................... 138

SMSC_R5.4_BIM Version: 2.0

Figure 2-2: SMSC Context Diagram ...................................................................................................... 15

Figure 2-3: Prepaid SMS Overview ....................................................................................................... 17

Figure 3-1: Call Flow – Send SM to Single Recipient ........................................................................... 20

Figure 3-3: Call Flow – Send SM with Additional Service ..................................................................... 22

Figure 3-4: Call Flow – Send Concatenated SMS................................................................................. 24

Figure 3-5: Call Flow – VAS/Large Account Delivery via SM ................................................................ 25

Figure 3-6: Call Flow – VAS/Large Account Delivery via CM ............................................................... 27

SMSC_R5.4_BIM Version: 2.0

Table 2-1: CDR Status Codes ............................................................................................................... 15

Table 4-1: PBR_COMMON Attributes ................................................................................................... 31

Table 4-2: SMSC Attributes ................................................................................................................... 33

Table 4-3: SMH_COMMON Attributes .................................................................................................. 34

Table 4-4: SSD_COMMON Attributes ................................................................................................... 34

Table 4-5: Relevant Prepaid Logical Name ........................................................................................... 35

Table 5-1: LOGSRV_COMMON Attributes ........................................................................................... 39

Table 5-2: LOGSRV Attributes .............................................................................................................. 41

Table 5-3: SMSC Attributes ................................................................................................................... 42

Table 5-4: SMH_COMMON Attributes .................................................................................................. 44

Table 5-6: CMLOG_COMMON Attributes ............................................................................................. 45

Table 5-7: IDI Filter Syntax .................................................................................................................... 47

Table 6-1: ASN.1 Definition ................................................................................................................... 49

Table 6-2: CallDetailRecord Fields ................................................................................................ 64

Table 6-3: CommandRecord Fields (Specifics) ..................................................................................... 72

Table 6-4: NotificationRecord Fields (Specifics) .......................................................................... 73

Table 6-5: SummaryRecord Fields (Specifics) ..................................................................................... 75

Table 6-6: Alert Record Fields ......................................................................................................... 77

Table 6-7: Fax Report Record Fields .............................................................................................. 77

Table 6-8: Failed Login Record Fields.......................................................................................... 78

Table 6-9: Send Routing Info Record Fields ............................................................................... 78

Table 6-10: ASER Field Description ....................................................................................................... 79

Table 6-11: MSER Field Description ....................................................................................................... 80

Table 6-12: NSER Field Description ....................................................................................................... 80

Table 6-13: XSER Field Description ....................................................................................................... 81

Table 6-14: ppAser Field Description .................................................................................................. 81

Table 6-15: ppPser Field Description .................................................................................................. 81

SMSC_R5.4_BIM Version: 2.0

Table 6-17: BSER_NOTIF Field Description .......................................................................................... 82

Table 6-18: BSER_CM Field Description ................................................................................................ 82

Table 6-19: ISR FLAGS Field Description ............................................................................................ 83

Table 6-20: NewServicesCM Field Description ................................................................................... 83

Table 6-21: CServices Field Description ............................................................................................ 83

Table 6-22: CServicesCM Field Description ........................................................................................ 83

Table 6-23: DServices Field Description ............................................................................................ 83

Table 6-24: DServicesNTF Field Description ..................................................................................... 84

Table 6-25: CServicesNTF Field Description ..................................................................................... 84

Table 6-26: TON .................................................................................................................................... 85