PrePay in Network Call Flows CAMEL III Voice1 PDF

PrePay IN Network Call Flows:
CAMEL III Voice Rating
VERSION 2
Responsible
Approves
Supports
Consults
Informed
Documentation Roles and Responsibilities

Engineering
Product, Product Architect, Engineering Lead, QA,
Deployment/Operations, Vendor,
Product, Engineering, Vendor
Product Architect, QA, Product and Engineering
Prepay Review team
This document is the property of Lightbridge, Inc., and its licensors and contains their confidential
trade secrets. Use, examination, copying, transfer and disclosure to others, in whole or in part,
are prohibited except with the express prior written consent of Lightbridge, Inc.
Prepay IN
Network Call Flows: Camel III Voice Rating
Version: 1.0
Date: 07/17/2004
Revision History
All revisions made to this document are listed below in chronological order.
Date
07/17/2004
10/27/2004
Release
1.0 (draft)
1.1 (draft)
Modified By
Sapnesh Sukumar
Sapnesh Sukumar
Lightbridge Confidential and Proprietary
Description
Initial Document Creation
Incorporating review comments
Page 2 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Table of Contents
1
INTRODUCTION...................................................................................................................... 6
1.1
SCOPE ..................................................................................................................................... 7
2.1
OVERVIEW .......................................................................................................................... 6
ASSUMPTIONS ..................................................................................................................... 7
NETWORK / PROTOCOL ARCHITECTURE.......................................................................... 8

3.1
3.2
PROTOCOL COMPLIANCE ..................................................................................................... 8

SUMMARY OF VENDOR SPECIFIC CHANGES .......................................................................... 9
NOTATIONS .......................................................................................................................... 10
MOBILE ORIGINATED CALLS............................................................................................. 11

5.1
5.2
5.3
SUCCESSFUL MO CALL: CALLED PARTY DISCONNECTS ...................................................... 11

SUCCESSFUL MO CALL: CALLING PARTY DISCONNECTS AFTER MID-CALL W ARNING ........... 17
SUCCESSFUL MO CALL: PPAS DISCONNECTS CALL UPON FUNDS EXPIRY WITH MIDCALL
TONE 20
5.4 SUCCESSFUL MO CALL: PPAS DISCONNECTS CALL UPON FUNDS EXPIRY WITH MIDCALL
TONE 23
5.5 UNSUCCESSFUL MO CALL: CALLING PARTY ABANDONS BEFORE CALL ANSWER.................. 23
5.6 UNSUCCESSFUL MO CALL: CALLED PARTY DOES NOT ANSWER OR IS BUSY ...................... 25
5.7 UNSUCCESSFUL MO CALL: INSUFFICIENT ACCOUNT BALANCE FOR CALLING MS................... 26
5.8 UNSUCCESSFUL MO CALL: ROUTE TO DESTINATION NOT AVAILABLE.................................. 26
6
MOBILE TERMINATED CALLS............................................................................................ 28

6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
SUCCESSFUL MT CALL: CALLED PARTY DISCONNECTS ...................................................... 28

SUCCESSFUL MT CALL: CALLED MS DISCONNECTS AFTER MID-CALL W ARNING ................. 36
SUCCESSFUL MT CALL: PPAS DISCONNECTS CALL UPON FUNDS EXPIRY .......................... 39
UNSUCCESSFUL MT CALL: INSUFFICIENT ACCOUNT BALANCE FOR CALLED MS ................... 41
UNSUCCESSFUL MT CALL: CALLED PARTY DOES NOT ANSWER.......................................... 41
UNSUCCESSFUL MT CALL: CALLING PARTY ABANDONS BEFORE CALL ANSWER .................. 43
UNSUCCESSFUL MT CALL : CALLED PARTY BUSY ............................................................... 45
UNSUCCESSFUL MT CALL: UNABLE TO GET ROAMING NUMBER .......................................... 46
FEATURE CALLS ................................................................................................................. 49

7.1 CALL ORIGINATION USING HOLD ....................................................................................... 49
7.1.1
Successful Call Origination After HOLD: Pre-Paid MS Is On An MO Call ........................ 49
7.1.2
Successful Call Origination After HOLD: Pre-Paid MS Is On An MT Call......................... 54
7.1.3
Call Origination After HOLD: PPAS Disconnects Call Upon Funds Expiry....................... 59
7.1.4
Unsuccessful Call Origination After HOLD : Insufficient Balance For Call To Third-Party
63
7.2 CALL W AITING ................................................................................................................... 66
7.2.1
Successful Call Delivery With Call Waiting: MS On A MT Call .......................................... 66
7.2.2
Successful Call Delivery With Call Waiting: MS On A MO Call ......................................... 71
7.2.3
Call Waiting: Pre-Paid Subscriber Ignores CW Notification Or Indicates UDUB.............. 76
7.2.4
Unsuccessful Call Waiting Call: Insufficient Funds............................................................. 79
7.2.5
Call Delivery With Call Waiting: PPAS Disconnects Call Upon Funds Expiry................... 80
7.3 CALL FORWARDING ........................................................................................................... 84
7.3.1
Successful Call Forwarding On No Reply ............................................................................ 84
7.3.2
Successful VLR-Determined CFNRc: MS Not Reachable .................................................... 91
7.3.3
Successful Call Forwarding On Subscriber Busy NDUB or UDUB ................................. 93
Page 3 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
7.3.4
Unsuccessful CFNRy/CFNRc/CFB: Calling Party Abandons Call Before Forwarded-To
Party Answer ........................................................................................................................................ 95
7.3.5
Unsuccessful CFNRy/CFNRc/CFB: Forwarded-To Party Does Not Answer Or Is Busy .... 97
7.3.6
Successful Call Forward Unconditional............................................................................... 99
7.3.7
Unsuccessful CFU: Calling Party Abandons Call Before Forwarded-To Party Answer... 109
7.3.8
Unsuccessful CFU: Forwarded-To Party Is Busy Or Does Not Answer ............................ 110
7.3.9
HLR-Determined CFNRc, CFU: PPAS Disconnects Call Upon Funds Expiry.................. 112
7.3.10 CFNRy/CFNRc/CFB: PPAS Disconnects Call Upon Funds Expiry .................................. 115
7.3.11 Unsuccessful HLR-Determined CFNRc, CFU: Insufficient Balance For Forwarded Call 118
7.3.12 Unsuccessful CFNRy/CFNRc/CFB: Insufficient Balance For Forwarded Call................. 119
8
ERROR SCENARIOS .......................................................................................................... 121

8.1
8.2
8.3
8.4
8.5
8.6
8.7
9
10
PPAS RECEIVES UNSUPPORTED CAP MESSAGE (OPERATION) .......................................... 121

PPAS RECEIVES UNSUPPORTED APPLICATION CONTEXT (AC) .......................................... 121
PPAS RECEIVES MISMATCHED APPLICATION CONTEXT (AC) AND CAP OPERATION ........... 121
PPAS RECEIVES A N/W MESSAGE IN AN INVALID TCAP PACKAGE TYPE .............................. 121
PPAS DETECTS A PROBLEM WITH THE CAP MESSAGE AT THE COMPONENT LEVEL.............. 122
PPAS DETECTS DIALOGUE ABORT (EITHER LOCAL OR MSC/GSMSSF INITIATED)............... 122
PPAS DETECTS LOCAL CONGESTION OR FACES PROBLEM WITH THE PROCESSING OF THE CALL
122
REVIEW FORM.................................................................................................................... 124

SIGNOFF SHEET ............................................................................................................. 125
Page 4 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Table of Figures
Figure 1 Successful MO Call: Called Party Disconencts ............................................................................ 11
Figure 2 Successful MO Call: Calling Party Disconencts After Mid-Call Warning.................................... 18
Figure 3 Successful MO Call: PPAS Disconnects Call Upon Funds Expiry ............................................... 21
Figure 4 Unsuccessful MO Call: Calling Party Abandons Before Call Answer .......................................... 24
Figure 5 Unsuccessful MO Call: Called Party Does Not Answer Or Is Busy.............................................. 25
Figure 6 Unsuccessful MO Call: Insufficient account balance for calling MS ............................................ 26
Figure 7 Unsucfcessful MO Call: Route To Destination Not Available....................................................... 27
Figure 8 Successful MT Call: Called Party Disconnects ............................................................................. 29
Figure 9 Successful MT call: Called MS Disconnects After Mid-Call Warning .......................................... 37
Figure 10 Successful MT Call: PPAS Disconnects Call Upon Funds Expiry .............................................. 40
Figure 11 Unsuccessful MT Call: Insufficient Account Balance for Called MS .......................................... 41
Figure 12 Unsuccessful MT Call: Called Party Does Not Answer .............................................................. 42
Figure 13 Unsuccessful MT Call: Calling Party Abandons Before Call Answer......................................... 44
Figure 14 Unsuccessful MT Call: Called Party Busy .................................................................................. 45
Figure 15 Unsuccessful MT Call: Unable to get Roaming Number............................................................. 47
Figure 16 Successful Call Origination After HOLD: Pre-Paid MS is on an MO Call................................. 50
Figure 17 Successful Call Origination After HOLD: Pre-Paid MS Is On An MT Call................................ 55
Figure 18 Call Origination After HOLD: PPAS Disconnects Call Upon Funds Expiry.............................. 61
Figure 19 Unsuccessful Call Origination After HOLD : Insufficient Balance For Call To Third-Party..... 64
Figure 20 Successful Call Delivery With Call Waiting: MS On A MT Call ................................................. 67
Figure 21 Successful Call Delivery With Call Waiting: MS On A MO Call ................................................ 72
Figure 22 Call Waiting: Pre-Paid Subscriber Ignores CW Notification Or Indicates UDUB..................... 77
Figure 23 Unsuccessful Call Waiting Call: Insufficient Funds.................................................................... 79
Figure 24 Call Delivery With Call Waiting: PPAS Disconnects Call Upon Funds Expiry.......................... 81
Figure 25 Successful Call Forwarding On No Reply ................................................................................... 85
Figure 26 Successful VLR-Determined CFNRc: MS Not Reachable ........................................................... 92
Figure 27 Successful Call Forwarding On Subscriber Busy NDUB or UDUB ........................................ 94
Figure 28 Unsuccessful CFNRy/CFNRc/CFB: Calling Party Abandons Call Before Forwarded-To Party
Answer .......................................................................................................................................................... 96
Figure 29 Unsuccessful CFNRy/CFNRc/CFB: Forwarded-To Party Does Not Answer Or Is Busy ........... 98
Figure 30 Successful Call Forward Unconditional.................................................................................... 100
Figure 31 Unsuccessful CFU: Calling Party Abandons Call Before Forwarded-To Party Answer.......... 109
Figure 32 Unsuccessful CFU: Forwarded-To Party Is Busy Or Does Not Answer ................................... 111
Figure 33 HLR-Determined CFNRc, CFU: PPAS Disconnects Call Upon Funds Expiry......................... 113
Figure 34 CFNRy/CFNRc/CFB: PPAS Disconnects Call Upon Funds Expiry ......................................... 116
Figure 35 Unsuccessful HLR-Determined CFNRc, CFU: Insufficient Balance For Forwarded Call ....... 118
Figure 36 Unsuccessful CFNRy/CFNRc/CFB: Insufficient Balance For Forwarded Call........................ 120
Page 5 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
1 Introduction
1.1 Overview
This document describes CAMEL III network call flows used to implement full call control services
to be provided in the Prepay Release 10.0. The following is an outline of the services discussed.
Mobile Origination Call
Mobile Termination Call
Feature Calls
1. Call On Hold
2. Call Waiting
3. Call Forwarding
Page 6 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
2 Scope
The following outlines the scope of the CAMEL III switch interface application developed as part
of Prepay Release 10.0
Requirements Covered
1. Normal call scenarios corresponding to the originating and terminating call legs will be
supported.
2. Call forwarding scenarios will be supported.
3. Other features, such as Call-Waiting and Call-Hold will be supported.
4. SCF SRF interface / support will be supported. Refer to CAMEL-3 SRF Interaction
Network Call Flows for details.
5. Various possible error scenarios including network external and system internal will
be supported.
Requirements Not Covered

1. Network congestion control using Call Gapping will not be supported.
2.1 Assumptions
None
Page 7 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
3 Network / Protocol Architecture

The following diagram shows the functional architecture for the support of CAMEL.
gsmSCF
This is the functional entity that contains the CAMEL service-level logic.
gsmSSF
This functional entity interfaces the MSC/GMSC to the gsmSCF.
gsmSRF
This functional entity provides various specialized resources. It interfaces with the
gsmSCF and the gsmSSF.
HLR
HLR stores the subscribers current CAMEL subscription information regarding OCSI, D-CSI, T-CSI, VT-CSI, and TIF-CSI. The O-CSI, D-TSI, and VT-CSI are sent
to the VLR on location update, data restoration, or if it is updated by
administrative action. The O/T-CSI is sent to the GMSC when the HLR responds
to a request for routing information.
GMSC
The receipt of the O/T-CSI from the HLR indicates to the GMSC to request
instructions from the gsmSSF. On request from the gsmSSF, the GMSC monitors
the call states (i.e. events) and informs the gsmSSF of these events. This
enables the gsmSSF to control call execution in the GMSC.
MSC
While processing calls for subscribers requiring CAMEL support, the MSC
receives the O-CSI and/or VT-CSI from the VLR. This indicates that the MSC
should request instructions from the gsmSSF. On request from the gsmSSF, the
MSC monitors the call states (i.e. events) and informs the gsmSSF of these
events. This enables the gsmSSF to control call execution in the MSC.
3.1 Protocol Compliance

This document and its call flows are compliant to CAMEL Phase 3 specifications for Prepay
Release 10.0.
Page 8 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
3.2 Summary of Vendor Specific Changes

Not Applicable.
Page 9 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
4 Notations
This section contains a set of notations that will be used in the call flows. These notations should
help the reader understand the call flows meaningfully.
1. The internal call flows between the various entities of PPAS SCF have not been shown for
the sake of clarity. They have been separately dealt with in the Internal Call Flows document.
2. SCF refers to the PPAS product of Lightbridge, Inc.
3. For incoming messages, any parameter that is part of the message sequence received will
be validated. Any validation failure will be reported as an error condition, regardless of
whether the parameter concerned is mandatory or optional from a protocol or application
standpoint.
4. For incoming messages, the Type column has entries in the following notational format X (Y).
Here is a description of the same:
X refers to the support of a parameter that is mandated by the protocol, as part of SCF
handling procedures. X can have values M (mandatory) or O(optional). If a parameter is
of type M, then this parameter must be included as part of the message. The absence of
this parameter will be reported as an error condition. The absence of a parameter of type
O will not be reported as an error condition.
Y refers to the support of a parameter that is mandated by the SCF application
requirements. This value can have values R (required error reported if missing), r
(required by call scenario but no error reported if missing) and O (optional). If a
parameter is of type R, then its presence is mandatory in a message from a SCF
standpoint. Non-inclusion of this parameter will be reported as an error condition. If a
parameter is of type r, then PPAS will be able to do certain things more appropriately if
this parameter is present but will not cause an error if it isn't. A parameter of type O will
not be used by the PPAS application. Non-inclusion will not be reported as an error
condition.
5. Parameters, which are not applicable to the context of this document, are not included in the
message detail description.
6. Parameters, whose inclusions are prohibited by the SCF handling procedures, if any, will be
separately mentioned.
7. For outgoing messages, the type column will have entries in the format X. Here X can be R
(required) or O (optional).
If a parameter is of type R, it indicates that the parameter is required from the

application and protocol standpoint. This parameter will invariably be populated.
If a parameter is of type O, it indicates that the parameter is not required from a
protocol/application standpoint. This parameter may or may not be populated.
Page 10 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
5 Mobile Originated Calls

5.1 Successful MO Call: Called Party Disconnects
This call scenario describes a successful call origination by a Pre-Paid Mobile Subscriber (MS).
Assumptions:
Calling Subscriber is a valid Prepay subscriber (Pre-Paid charging is Active).

Calling Subscribers account balance is above a pre-defined threshold value.
No pre-call announcement will be played.
No mid-call tone will be played as subscriber disconnects before funds drop below threshold.
gsmSSF
gsmSCF
Collected_Info
InitialDP
RequestReportBCSM
b
Continue
O_Answer
EventReportBCSM (O_Answer)
d
ApplyCharging
ApplyChargingReport
f
ApplyCharging
g Repeated
N times
O_Disconnect
ApplyChargingReport
h
EventReportBCSM (O_Disconnect)
i
TC_END
Figure 1 Successful MO Call: Called Party Disconencts
Page 11 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
a. The Serving MSC/gsmSSF detects the Collected_Info trigger on receiving a call origination
request from a Pre-Paid Mobile Subscriber. The Serving MSC/gsmSSF sends an InitialDP
message to the Pre-Paid Application Server (PPAS) requesting for call processing
instructions.
InitialDP
Parameter
Description/Usage
Type
serviceKey
Identifies the requested IN service. This parameter is used

to address the Application within PPAS.
M(R)
calledPartyNumber
Indicates the Called Party in the forward direction.
O(R)
callingPartyNumber
Indicates the Calling Party Number.
O(R)
callingPartysCategory
Indicates the type of calling party (e.g. operator,

payphone,
and
ordinary subscriber). Refer to
Recommendation Q.763 for encoding.
O(O)
locationNumber
This parameter is used to convey the geographical area

address for mobility services, see Recommendation
Q.762. It is used when callingPartyNumber' does not
contain any information about the geographical location of
the calling party (e.g. origin dependent routing when the
calling party is a mobile subscriber).
O(O)
originalCalledPartyID
This parameter carries the dialed digits if the call has

encountered call forwarding en-route to the SSF.
O(O)
highLayerCompatibility
This parameter indicates the type of the high layer

compatibility, which will be used to determine the ISDN
teleservice of a connected ISDN terminal. For encoding
DSS-1 (see Recommendation Q.931) is used. The
highlayerCompatibility can also be transported by ISUP
within the ATP (see Recommendation Q.763) parameter.
O(O)
additionalCallingParty
Number
This parameter indicates the calling party number

provided by the access signaling system of the calling
user, e.g. provided by a PBX.
O(O)
bearerCapability
Indicates the type of Bearer Capability connection to the

user. This parameter is not being used by PPAS, but
could be used in the future to determine the type of call
(e.g. voice, fax etc.)
O(O)
eventTypeBCSM
Identifies the armed BCSM DP event, resulting in the

InitialDP operation i.e. CollectedInfo. This determines
the direction of the call (origination/termination, origination
for CollectedInfo).
O(R)
redirectingPartyID
This parameter indicates the last directory number the call

was redirected from.
O(O)
redirectionInformation
This parameter contains forwarding related information.
O(O)
iPSSPCapabilities
This parameter indicates which SRF resources are

supported and available for the SSF. The absence of this
parameter indicates that no SRF resources are attached
and available.
O(O)
Page 12 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type
serviceInteractionIndic
atorsTwo
This parameter contains indicators, which are exchanged

between the SSF and SCF to resolve interactions
between IN based services and network based services,
respectively between different IN based services.
O(O)
IMSI
IMSI of the mobile subscriber for which the service is

invoked.
O(O)
subscriberState
The state of the mobile subscriber for which the service is

invoked. The possible states are busy, idle and notreachable.
O(O)
locationInformation
This parameter indicates the whereabouts of the MS, and

the age of the information defining the whereabouts.
O(R)
ext-BasicServiceCode
Indicates the Basic Service Code.
O(O)
callReferenceNumber
This parameter gives the call reference number assigned

to the call by the CCF.
O(O)
mscAddress
This parameter indicates the mscId assigned to the MSC.
O(O)
gmscAddress
This parameter indicates the gmscId assigned to the

GMSC.
O(O)
CalledPartyBCDNumb
er
This parameter contains the number used to identify the

called party in forward direction. It may also include the
service selection information, including * and # characters.
O(O)
time&TimeZone
This parameter contains the time that the gsmSSF was

triggered and the time-zone that the invoking gsmSSF
resides in.
O(R)
gsmForwardingPending
This parameter indicated that a forward-to-number was

received and the call will be forwarded due to GSM
supplementary service call forwarding in the GMSC or in
the VMSC.
O(O)
Carrier
This parameter indicated the carrier information. It

consists of the carrier selection field followed by the
Carrier ID information associate with the calling subscriber
of a mobile originating call, the called subscriber of a
mobile terminating call or the forwarding subscriber of a
mobile forwarding call.
O(O)
cug-Index
This parameter is used to select a CUG for an outgoing

call at the user, or to indicate an incoming CUG call to the
user.
O(O)
cug-Interlock
This parameter uniquely identifies a CUG within a

network.
O(O)
cug-OutgoingAccess
This parameter indicates if the calling user has subscribed

to the outgoing access inter-CUG accessibility
subscription option.
O(O)
cGEncountered
This parameter indicates the type of gapping the related

call has been subjected to, if any.
O(O)
cause
This parameter indicates the release cause which

triggered the event
O(O)
Page 13 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
b. The PPAS sends a RequestReportBCSMEvent operation to monitor and request the

following event notifications from the gsmSSF:
O_Abandon
O_Busy
O_Answer
O_NoAnswer
RouteSelectFailure
O_Disconnect
Calling Party (i.e. pre-Paid MS) abandons the

call.
Called Party is busy.
Called Party answers the call.
Called Party does NOT answer the call.
Failed to select route for the call.
Call is disconnected.
RequestReportBCSM
Parameter
Description/Usage
Type
bcsmEvents
eventTypeBCSM: This parameter specifies the type of event of which a

report is requested.
monitorMode: This parameter indicates how the event shall be reported.

All
events,
except
O_Disconnect
are
armed
as
EDP-N
(notifyAndContinue) to maintain control relationship with the SSF.
O_Disconnect is armed as EDP-R (interrupted) to maintain monitor
relationship with the SSF.
legID: This parameter indicated the party in the call for which the event
shall be reported. The O_Disconnect trigger should be armed for both the
Calling Party (leg ID = 1) as well as the Called Party (leg ID = 2) so that
the SSF is able to notify call disconnects for both the Calling Party and the
Called Party. O_Abandon is always armed for Calling Party (legID = 1)
whereas
O_CalledPartyBusy,
O_Answer,
O_NoAnswer
and
RouteSelectFailure are always armed for Called Party (leg ID = 2).
dpSpecificCriteria: This parameter indicates information specific to the

EDP to be armed. The PPAS SCF will not populate this parameter.
c.
PPAS determines that
Subscriber has Pre-Paid Charging (PPC) Active,

Subscribers account balance is above a pre-determined threshold level, and
The call can be allowed.
Hence it requests the Serving MSC to continue call processing (from the DP at which it was
previously suspended awaiting instructions from PPAS) by sending a Continue operation to
the gsmSSF.
Note:
Continue operation has no invocation arguments.

Continue operation is sent in a TC_CONTINUE package to ensure that all the Detection
Points are armed (RRBCSM is processed) before call is allowed to progress.
d. Once the called party answers the call, the SSF encounters the O_Answer Detection Point.
The SSF sends an EventReportBCSM message to the SCF and implicitly disarms the
O_Answer, O_CalledPartyBusy, O_Abandon, O_NoAnswer and RouteSelectFailure
detection points.
EventReportBCSM
Page 14 of 125
Prepay IN
Parameter
eventTypeBCSM
Version: 1.0
Date: 07/17/2004
Description/Usage
Type
This parameter specifies the event being reported

O_Answer.
M(R)
eventSpecificInformationBCSM
This parameter contains call related information

specific to the event being reported.
O(O)
legID
This parameter indicates the party in the call for

which the event is being reported. A value of 2 will
indicate that the called party answered the call.
O(O)
miscCallInfo
This parameter indicates DP related information.
O(O)
messageType
This parameter indicates whether the message is a

request or notification.
O(O)
At this stage the voice paths have been established and the call is in progress. Upon receipt
of the O_Answer event notification, the PPAS starts to decrement the Pre-Paid subscribers
account balance - dynamically.
To handle SS7link failures, the PPAS sends multiple ApplyCharging messages to rate
the call as accurately as possible. To achieve this, the maximum call period duration is
splitted into a configured number (N) of small duration. For each of this small duration,
PPAS sends a Cancel, RequestReportBCSM and ApplyCharging operations in a single
TCAP message to the gsmSSF. This action is repeated N number of times. The
message details below show only one cycle.
e. The gsmSCF sends an ApplyCharging operation to the Serving MSC/gsmSSF in order to
start the T-cp timer on gsmSSF side with the configured duration.
ApplyCharging
Parameter
Description/Usage
Type
achBillingChargingCharacteristics
Specifies charging related information. Includes the

following:
maxCallPeriodDuration: Specifies the time period
for which the call can progress further before an
ApplyChargingReport operation can be sent to the
PPAS. This parameter will be populated with the
configured duration.
(Note: A call period timer, T-cp, for the call is started
in the gsmSSF for the value of this parameter).
releaseIfDurationExceeded: Specifies the action to
be taken at gsmSSF when the T-cp timer expires. If
present releases the call.
This parameter will be populated.
tone: If this parameter is present, a tone is played
when the warning tone timer expires on gsmSSF
side.
This parameter will not be populated.
tariffSwitchInterval: Indicates to the gsmSSF the
time duration until the next tariff switch.
Indicates the party in the call.
This parameter will be populated with the
CallingPartyNumber.
partyToCharge
Page 15 of 125
Prepay IN
f.
Version: 1.0
Date: 07/17/2004
The gsmSSF sends a ApplyChargingReport operation to the gsmSCF to indicate that the
time specified by the previous ApplyCharging message has elapsed and that the call is still
active
ApplyChargingReport
Parameter
Description/Usage
Type
callResult
Provides the charging related information previously requested through

ApplyCharging. Contains parameter timeDurationChargingResult the
following sub-parameters:
timeInformation: Indicates if tariff switch was encountered or not.
M(R)
M(O)
partyToCharge: As received in ApplyCharging message.
M(R)
callActive: Indicates whether the call is active or not (false).
M(R)
callReleasedAtTcpExpiry: Indicates that the gsmSSF has released the

call and terminated the dialogue. This parameter shall be present when Tcp
timer expires at gsmSSF.
O(R)
g. The gsmSCF sends an ApplyCharging operation to the Serving MSC/gsmSSF in order to

ApplyCharging
Parameter
Description/Usage
Type

following:
side.
CallingPartyNumber.
partyToCharge
As indiacted above, steps f and g forms a cycle and this cycle is repeated N
(configured) number of times.
h. When the called party disconnects the call, the SSF encounters an O_Disconnect detection
point. The gsmSSF determines that a charging report is to be sent (as requested by the
PPAS in a previous ApplyCharging operation) and hence it sends an ApplyChargingReport
operation to the PPAS.
Page 16 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
callActive: Indicates whether the call is active or not.
M(R)

O(R)
i.
The gsmSSF sends an EventReportBCSM message to the SCF for O_Disconnect event.
EventReportBCSM
Parameter
EventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)
EventSpecificInformationBCSM

O(O)
legID

indicate that the called party disconnected the call.
O(R)
miscCallInfo
O(O)
messageType

O(O)
Note: If the calling party disconnects the call, there will only be one change in the call flow the legID parameter in the EventReportBCSM message (in step f above) will indicate the
calling party.
j.
On receiving a disconnect notification, the SCF does a Basic End by sending a blank
TC_END to the SSP to make sure all TCAP dialog related resources are released.
5.2 Successful MO Call: Calling Party Disconnects After MidCall Warning

This call scenario describes a successful call origination by a Pre-Paid Mobile Subscriber (MS)
where the Pre-Paid subscriber ends the call before expiry of funds in the account.
Assumptions:
Calling Party is a valid Prepay subscriber (Pre-Paid charging is Active)

Calling Partys account balance is above a pre-defined threshold value
No pre-call announcement will be played
The Serving MSC plays a warning tone to the subscriber indicating an impending call
disconnection
Calling Party disconnects the call before the expiry of funds in its Pre-Paid account.
Page 17 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
Collected_Inf
o
InitialDP
RequestReportBCSM
Continue
O_Answer
ApplyCharging
ApplyChargingReport
ApplyCharging
g Repeated
N times
Warning timer
expires
h
ApplyChargingReport
ApplyCharging
O_Disconnect
ApplyChargingReport
TC_END
Figure 2 Successful MO Call: Calling Party Disconencts After Mid-Call Warning

The steps a to g are the same as described in Section 5.1 Successful MO Call (Called MS
disconnects before expiry of funds).
h. The Warning Timer expires in the PPAS. At this point, the SCP waits for the
ApplyChargingReport operation from the gsmSSF to indicate that the time specified in the
previous ApplyCharging has expired.
ApplyChargingReport
Page 18 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
i.
An ApplyCharging operation is sent to the Serving MSC/gsmSSF in order to specify that a

Mid-Call Warning should be played to the Pre-Paid subscriber. This operation also specifies
the maximum allowed remaining duration for the call.
ApplyCharging
Parameter
Description/Usage
Type
AchBillingChargingCharacteristics

following:
PPAS.
This parameter is populated with the remaining time
left for the call.
(Note: A call period timer, T-cp, for the call is
started in the gsmSSF for the value of this
parameter).
This parameter is populated.
side.
This parameter is populated to indicate MSC to play
a tone to the subscriber.
This parameter is not populated.
This
parameter
is
populated
with
the
CallingPartyNumber.
partyToCharge
The SSF plays a mid-call warning tone to the subscriber.

j.
On hearing the warning tone, the calling party disconnects before the expiry of funds. At this
point the SSF encounters an O_Disconnect detection point. The gsmSSF determines that a
charging report is to be sent (as requested by the PPAS in a previous ApplyCharging
operation) and hence it sends an ApplyChargingReport operation to the PPAS.
ApplyChargingReport
Page 19 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
k.
After sending ApplyChargeReport message, the gsmSSF sends an EventReportBCSM

message to the SCF.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
legID

indicate that the calling party disconnected the call.
O(R)
miscCallInfo
O(O)
messageType

O(O)
l. On receiving a disconnect notification, the SCF does a Basic End by sending a blank
5.3 Successful MO Call: PPAS Disconnects Call Upon Funds

Expiry with MidCall tone
This call scenario describes a successful call origination by a Pre-Paid Mobile Subscriber (MS) in
which the PPAS directs the Serving MSC to disconnect the ongoing call.
Assumptions:

When the subscriber runs out of funds in the Pre-Paid account, the PPAS directs the serving
MSC to disconnect the call. The PPAS also requests the MSC to play a warning tone before
disconnecting the call.
Page 20 of 125
Prepay IN
gsmSSF
Version: 1.0
Date: 07/17/2004
gsmSCF
Collected_Inf
o
InitialDP
RequestReportBCSM
Continue
O_Answer
ApplyCharging
ApplyChargingReport
ApplyCharging
Warning timer
expires
h
ApplyChargingReport
ApplyCharging
Tcp timer
expires
Repeated
N times
ApplyChargingReport
TC_END
Figure 3 Successful MO Call: PPAS Disconnects Call Upon Funds Expiry with MidCall Tone
The steps a to i are the same as described in Section 5.2 Successful MO Call: Calling Party
Disconnects After Mid-Call Warning.
j.
After hearing the warning tone, the subscriber conitues with the call till the funds expire.
When Tcp timer expires on gsmSSF side, the gsmSSF determines that a charging report is to
be sent (as requested by the PPAS in a previous ApplyCharging operation) and hence it
sends an ApplyChargingReport operation to the PPAS.
ApplyChargingReport
Parameter
Description/Usage
Type
Page 21 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
k.
Note: If the ApplyChargingReport is not received by the PPAS in the stipulated time
(maxCallPeriodDuration sent in ApplyCharging), the PPAS sends ReleaseCall operation to
forcefully disconnect the call.
Page 22 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
5.4 Successful MO Call: PPAS Disconnects Call Upon Funds

Expiry with MidCall tone
gsmSSF
Collected_Inf
o
gsmSCF
InitialDP
RequestReportBCSM
Continue
O_Answer
ApplyCharging
ApplyChargingReport
ApplyCharging
ApplyChargingReport
ApplyCharging
ReleaseCall
a
b
c
d
e
f
g
Repeated
N times
Warning timer
expires
h
Call Duration
timer expires
j
Figure 4 Successful MO Call: PPAS Disconnects Call Upon Funds Expiry without MidCall Tone
In a normal system, this call flow should not occur. Even if the end call timer expires for
whatever reason, PPAS will should drop the call so that the exposure to the provider is
minimized.
5.5 Unsuccessful MO Call: Calling Party Abandons Before Call

Answer
This call scenario describes a call origination by a Pre-Paid Mobile Subscriber (MS) wherein the
Calling MS abandons the call before the Called Party answers the call.
Assumptions:

Calling MS abandons the call before the Called Party answers the call.
Page 23 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
Collected_Info
InitialDP
RequestReportBCSM
Continue
c
O_Abandon
EventReportBCSM (O_Abandon)
TC_END
Figure 5 Unsuccessful MO Call: Calling Party Abandons Before Call Answer

The steps a to c are the same as described in Section 5.1 Successful MO Call (Called MS
d. When the calling party abandons the call, the SSF encounters an O_Abandon detection
point. The SSF reports the abandon event to the SCF by sending an EventReportBCSM
operation.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Abandon
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
e. On receiving abandon notification, the SCF does a Basic End by sending a blank TC_END to
the SSP to make sure all TCAP dialog related resources are released.
Page 24 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
5.6 Unsuccessful MO Call: Called Party Does Not Answer Or Is

Busy
This call scenario describes a call origination by a Pre-Paid Mobile Subscriber (MS) wherein the
Called party does not answer or is busy.
Assumptions:

Call Forwarding No Answer and Call Forwarding Busy features are NOT Active for the
subscriber.
gsmSSF
gsmSCF
Collected_Info
InitialDP
RequestReportBCSM
b
Continue
c
O_Busy /
O_NoAnswer
EventReportBCSM (O_Busy/O_NoAnswer)
TC_END
Figure 6 Unsuccessful MO Call: Called Party Does Not Answer Or Is Busy

d. The called party does not answer or is busy with some other call. SSF detects the
O_NoAnswer or O_Busy event. The SSF reports the O_Busy/O_NoAnswer event to the SCF
by sending an EventReportBCSM operation.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_NoAnswer / O_Busy
M(R)

O(O)
legID

indicate that the event was triggered at called party
leg.
O(R)
miscCallInfo
O(O)
Page 25 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
EventReportBCSM
Parameter
messageType
Description/Usage
Type

O(O)
e. On receiving O_NoAnswer/O_Busy notification, the SCF does a Basic End by sending a

blank TC_END to the SSP to make sure all TCAP dialog related resources are released.
5.7 Unsuccessful MO Call: Insufficient account balance for

calling MS
This call flow describes an unsuccessful mobile call scenario on the originating call leg. The
called subscriber does not have sufficient funds to complete the call.
Assumptions:

The called subscriber does not have sufficient funds to complete the call. Hence, the PPAS
SCF denies the call.
No pre-call announcement will be played.
gsmSSF
Collected_Info
gsmSCF
InitialDP
a
Release Call
Figure 7 Unsuccessful MO Call: Insufficient account balance for calling MS

The step a. is the same as described in Section 5.1 Successful MO Call (Called MS
b. When the PPAS determines that the subscribers account balance does not have sufficient
funds to continue the call, the PPAS SCF denies the call. In order to achieve this, the PPAS
SCF sends a ReleaseCall message to the SSF in a TC_END package.
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
This parameter indicates the reason for releasing the call. This may
be used by the SSF for generating specific tones to the different
parties in the call, or to fill in the cause in the ISUP Release
message.
M(R)
5.8 Unsuccessful MO Call: Route To Destination Not Available

This call scenario describes the case where the Pre-Paid Calling MS originates a call, but the
Serving MSC is unable to successfully get a route to the destination switch.
Assumptions:
Page 26 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004

Call Forwarding No Answer and Call Forwarding Busy features are NOT Active for the
subscriber.
Serving MSC attempts to set up a call with the Called Party. However, the destination switch
releases the call.
gsmSSF
gsmSCF
Collected_Info
InitialDP
RequestReportBCSM
Continue
c
Route_Select_
Failure
EventReportBCSM (RouteSelectFailure)
d
TC_END
Figure 8 Unsucfcessful MO Call: Route To Destination Not Available

d. The destination exchange releases the call. The Serving MSC determines that the release
message has a cause that is neither Busy nor No Answer, and hence it detects the
Route_Select_Failure event. The Serving MSC/gsmSSF sends an EventReportBCSM
operation to PPAS to inform the Route_Select_failure event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

RouteSelectFailure
M(R)

O(O)
legID

leg.
O(R)
miscCallInfo
O(O)
messageType

O(O)
e. On receiving the RouteSelectFailure notification, the SCF does a Basic End by sending a
Page 27 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
6 Mobile Terminated Calls

All the call scenarios described below are specific for roaming. MSC will not trigger on
DP12 if the subscriber is in the home circle. This is controlled via the HLR. PPAS would be
able to rate the home mobile terminated calls correctly.
6.1 Successful MT Call: Called Party Disconnects

This call flow describes a successful mobile call scenario on the terminating call leg.
Assumptions:
Called subscriber is a valid Prepay subscriber (Pre-Paid charging is Active).

Called subscribers account balance is above a pre-defined threshold value.
No pre-call announcement is possible, as this call is on a terminating leg.
No mid call tone will be played as the subscriber disconnects before the account funds drops
below the threshold level.
Page 28 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
GMSC/
gsmSSF
gsmSCF
MT Call
Term_Attempt
Authorized
b
c
T_Answer
d
e
f
g
T_Disconnect
h
i
j
InitialDP
RequestReportBCSM
Continue
EventReportBCSM
(T_Answer)
ApplyCharging
ApplyChargingReport
Repeated
N times
ApplyCharging
ApplyChargingReport
EventReportBCSM
(T_Disconnect)
TC_END
Figure 9 Successful MT Call: Called Party Disconnects
The GMSC receives a call setup request for the Pre-Paid MS. The GMSC determines that it
needs to get the T_CSI information (essentially the CAMEL TDP list). Hence it sends a
SendRoutingInfo Invoke MAP operation to the subscribers HLR. The HLR sends the
subscribers T-CSI in the SendRoutingInfo ReturnResult.
a. The SSF determines that a TermAttemptAuthorized trigger detection point has been
encountered. The SSF sends an InitialDP message to the SCF and suspends processing
until further instructions are received from the SCF.
InitialDP
Parameter
Description/Usage
Type
serviceKey
Identifies the requested IN service. This parameter is

used to address the Application within PPAS.
M(R)
calledPartyNumber
Indicates the Called Party in the forward direction.
O(R)
Page 29 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004

InitialDP
Parameter
Description/Usage
Type
callingPartyNumber
O(R)

payphone, and ordinary subscriber). Refer to
O(O)
locationNumber
This parameter is used to convey the geographical

area
address
for
mobility
services,
see
Recommendation
Q.762.
It
is
used
when
callingPartyNumber' does not contain any information
about the geographical location of the calling party
(e.g. origin dependent routing when the calling party is
a mobile subscriber).
O(O)

O(O)

teleservice of a connected ISDN terminal. For
encoding DSS-1 (see Recommendation Q.931) is
used. The highlayerCompatibility can also be
transported by ISUP within the ATP (see
Recommendation Q.763) parameter.
O(O)
additionalCallingPartyNumber

O(O)
bearerCapability
Indicates the type of Bearer Capability connection to

the user. This parameter is not being used by PPAS in
Prepay 9.5 release, but could be used in the future to
determine the type of call (e.g. voice, fax etc.)
O(O)
eventTypeBCSM

InitialDP operation i.e. TermAttemptAuthorized.
This determines the direction of the call
(origination/termination,
termination
for
TermAttemptAuthorized).
O(R)
redirectingPartyID
This parameter indicates the last directory number the

call was redirected from.
O(O)
This
parameter
information.
related
O(R)
iPSSPCapabilities

supported and available for the SSF. The absence of
this parameter indicates that no SRF resources are
attached and available.
O(O)
serviceInteractionIndicatorsTwo
This parameter contains indicators, which are

exchanged between the SSF and SCF to resolve
interactions between IN based services and network
based services, respectively between different IN
based services.
O(O)
contains
forwarding
Page 30 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type
iMSI

invoked.
O(O)
subscriberState
The state of the mobile subscriber for which the service

is invoked. The possible states are busy, idle and notreachable.
O(O)
locationInformation
This parameter indicates the whereabouts of the MS,

and the age of the information defining the
whereabouts.
O(R)
O(O)
callReferenceNumber
This parameter gives the call reference number

assigned to the call by the CCF.
O(O)
mscAddress
This parameter indicates the mscId assigned to the

MSC.
O(O)
gmscAddress

GMSC.
O(R)
calledPartyBCDNumber
This parameter contains the number used to identify

the called party in forward direction. It may also include
the service selection information, including * and #
characters.
O(O)
time&TimeZone

resides in.
O(R)
gsm-ForwardingPending

supplementary service call forwarding in the GMSC or
in the VMSC.
O(O)
Carrier

Carrier ID information associate with the calling
subscriber of a mobile originating call, the called
subscriber of a mobile terminating call or the
forwarding subscriber of a mobile forwarding call.
O(O)
cug-Index

call at the user, or to indicate an incoming CUG call to
the user.
O(O)
cug-Interlock

network.
O(O)
cug-OutgoingAccess
This parameter indicates if the calling user has

subscribed to the outgoing access inter-CUG
accessibility subscription option.
O(O)
cGEncountered
This parameter indicates the type of gapping the

related call has been subjected to, if any.
O(O)
cause

triggered the event
O(O)
Page 31 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
b. The PPAS sends a RequestReportBCSMEvent operation to monitor and request the

T_Abandon
T_Busy
T_Answer
T_NoAnswer
RouteSelectFailure
T_Disconnect
Calling Party (i.e. pre-Paid MS) abandons the call.

RequestReportBCSM
Parameter
Description/Usage
Type
bcsmEvents


All
events,
except
T_Disconnect
are
armed
as
EDP-N
T_Disconnect is armed as EDP-R (interrupted) to maintain monitor
shall be reported. The T_Disconnect trigger should be armed for both the
Called Party. T_Abandon is always armed for Calling Party (legID = 1)
whereas
T_CalledPartyBusy,
T_Answer,
T_NoAnswer
and

c.
PPAS determines that

the gsmSSF.
Note:

As part of the GMSCs preparation to setup the call to the Called MS, the GMSC sends a
SendRoutingInfo Invoke MAP operation to the HLR requesting it to obtain the routing address
of the MSC that is serving the Called MS. The SRI operation will contain the suppress T-CSI
parameter, which indicates to the HLR NOT to do CAMEL CSI processing but to get the
Roaming Number from the VLR/MSC. The HLR sends a ProvideRoamingNumber Invoke
MAP operation to the VLR. The VLR allocates a Roaming Number for the call, and returns it
in the ProvideRoamingNumber ReturnResult. The HLR forwards the Roaming Number to the
Page 32 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
GMSC by sending a SendRoutingInformation ReturnResult. Using the Roaming Number, the

GMSC sets up the call to the Called MS.The serving MSC pages the MS and alerts the MS.
The MS answers the call.
d. Once the called party answers the call, the SSF encounters the T_Answer Detection Point.
The SSF sends an EventReportBCSM message to the SCF and implicitly disarms the
T_Answer, T_CalledPartyBusy, T_Abandon, T_NoAnswer and RouteSelectFailure detection
points.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Answer.
M(R)

O(O)
legID

O(O)
miscCallInfo
O(O)
messageType

O(O)
of the T_Answer event notification, the PPAS starts to decrement the Pre-Paid subscribers
To handle SS7link failures, the PPAS sends multiple ApplyCharging messages to rate
the call as accurately as possible. To achieve this, the maximum call period duration is
splitted into a configured number (N) of small duration. For each of this small duration,
PPAS sends a Cancel, RequestReportBCSM and ApplyCharging operations in a single
TCAP message to the gsmSSF. This action is repeated N number of times. The
message details below show only one cycle.
e. The gsmSCF sends an ApplyCharging operation to the Serving MSC/gsmSSF in order to
ApplyCharging
Parameter
Description/Usage
Type

following:
Page 33 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyCharging
Parameter
partyToCharge
f.
Description/Usage
Type

side.
CalledPartyNumber.
The gsmSSF sends a ApplyChargingReport operation to the gsmSCF to indicate that the
time specified by the previous ApplyCharging message has elapsed and that the call is still
active
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
callActive: Indicates whether the call is active or not (false).
M(R)

O(R)

ApplyCharging
Parameter
Description/Usage
Type

following:
Page 34 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyCharging
Parameter
partyToCharge
Description/Usage
Type

side.
CalledPartyNumber.
As indiacted above, steps f and g forms a cycle and this cycle is repeated N
(configured) number of times.
h. When the called party disconnects the call, the SSF encounters a T_Disconnect detection
point. The gsmSSF determines that a charging report is to be sent (as requested by the
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)
callReleasedAtTcpExpiry: wIndicates that the gsmSSF has released the

O(R)
i.
The SSF then sends an EventReportBCSM message to the SCF to report the T_Disconnect
event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
Page 35 of 125
Prepay IN
j.
Version: 1.0
Date: 07/17/2004
calling party.
6.2 Successful MT Call: Called MS Disconnects After Mid-Call

Warning
This call flow describes a successful mobile call scenario on the terminating call leg. The called
Pre-Paid subscriber disconnects after mid-call warning tone.
Assumptions:

The Serving MSC plays a warning tone to the subscriber indicating an impending call
disconnection
Called Party disconnects the call before the expiry of funds in its Pre-Paid account.
Page 36 of 125
Prepay IN
GMSC/
gsmSSF
Version: 1.0
Date: 07/17/2004
gsmSCF
MT Call
Term_Attempt
Authorized
InitialDP
RequestReportBCSM
Continue
EventReportBCSM
(T_Answer)
T_Answer
ApplyCharging
ApplyChargingReport
ApplyCharging
ApplyChargingReport
T_Disconnect
Warning timer
expires
ApplyCharging
i
j
Repeated
N times
ApplyChargingReport
EventReportBCSM(T_Disconnect)
TC_END
Figure 10 Successful MT call: Called MS Disconnects After Mid-Call Warning

The steps a to g are the same as described in Section 6.1 Successful MT Call (Called MS
h. The Warning Timer expires in the PPAS. At this point, the SCP waits for the
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)
Page 37 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
i.
Description/Usage
Type

O(R)

ApplyCharging
Parameter
Description/Usage
Type

following:
PPAS.
This parameter will be populated with the remaining
duration for the call.
when the warning tone timer expires on the gsmSSF
side.
CalledPartyNumber.
partyToCharge

j.
On hearing the warning tone, the called party disconnects before the expiry of funds. At this
point the SSF encounters an T_Disconnect detection point. The gsmSSF determines that a
charging report is to be sent (as requested by the PPAS in a previous ApplyCharging
operation) and hence it sends an ApplyChargingReport operation to the PPAS.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
Page 38 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
k.
Description/Usage
M(R)

O(R)
After sending ApplyChargeReport message, the gsmSSF sends an EventReportBCSM

message to the SCF.
EventReportBCSM
Parameter
eventTypeBCSM
l.
Type
Description/Usage
Type

T_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
6.3 Successful MT Call: PPAS Disconnects Call Upon Funds

Expiry
This call flow describes a successful mobile call scenario on the terminating call leg. The called
PPAS SCF forcefully disconnects the call after the called subscribers account balance expires.
Assumptions:

When the subscriber runs out of funds in the Pre-Paid account, the call is disconnected. The
PPAS also requests the MSC to play a warning tone before disconnecting the call.
Page 39 of 125
Prepay IN
GMSC/
gsmSSF
Version: 1.0
Date: 07/17/2004
gsmSCF
MT Call
Term_Attempt
Authorized
b
c
T_Answer
d
e
f
g
h
i
Tcp timer
expires
j
k
InitialDP
RequestReportBCSM
Continue
EventReportBCSM
(T_Answer)
ApplyCharging
ApplyChargingReport
ApplyCharging
ApplyChargingReport
Repeated
N times
Warning timer
expires
ApplyCharging
ApplyChargingReport
TC_END
Figure 11 Successful MT Call: PPAS Disconnects Call Upon Funds Expiry

The steps a to i are the same as described in Section 6.2 Successful MT Call: Called MS
Disconnects After Mid-Call Warning.
j.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
Page 40 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
k.
M(R)

O(R)
(maxCallPeriodDuration sent in ApplyCharging), it sends ReleaseCall to forcefully
disconnect the call.
6.4 Unsuccessful MT Call: Insufficient Account Balance for

Called MS
This call flow describes an unsuccessful mobile call scenario on the terminating call leg. The
called subscriber does not have sufficient funds to complete the call.
Assumptions:
The called subscriber is a valid Prepay subscriber (Pre-Paid charging is Active).
The called subscriber does not have sufficient funds to complete the call. Hence, the PPAS
SCF denies the call.
GMSC/
gsmSSF
gsmSCF
HLR
VLR
IAM
Term_Attempt
Authorized
InitialDP
a
ReleaseCall
b
Figure 12 Unsuccessful MT Call: Insufficient Account Balance for Called MS

The step a. is the same as described in Section 6.1 Successful MT Call (Called MS
b. When the PPAS determines that the subscribers account balance does not have sufficient
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
6.5 Unsuccessful MT Call: Called Party Does Not Answer

called subscriber does not answer the call.
Page 41 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Assumptions:
The called subscriber has sufficient funds to complete the call, i.e. the called subscribers
account balance is above a pre-defined threshold value.
Call Forwarding is not applicable.
GMSC/
gsmSSF
gsmSCF
HLR
VLR
VMSC
MT Call
Send Routeing Info (SRI)
SRI ack (T-CSI)
Term_Attempt
Authorized
InitialDP
RequestReportBCSM
b
c
Continue
SRI ack (Routing Number)
Provide Roaming
Number (PRN)
PRN ack
IAM
T-TNRy timer
started
SIFIC
Page MS
Page MS
negative ack
Complete Call
negative response
T-TNRy timer
expires
T_NoAnswer
EventReportBCSM
(T_NoAnswer)
d
e
TC_END
Figure 13 Unsuccessful MT Call: Called Party Does Not Answer

The steps a to c are the same as described in Section 6.1 Successful MT Call (Called MS
d. The called party does not answer the call. The T_TNRy timer expires at SSF side due to
which it detects the T_NoAnswer event. The SSF then sends an EventReportBCSM
message to the gsmSCF to report the T_NoAnswer event.
Page 42 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
EventReportBCSM
Parameter
EventTypeBCSM
Description/Usage
Type

T_NoAnswer
M(R)

O(O)
LegID

leg.
O(R)
MiscCallInfo
O(O)
MessageType

O(O)
e. On receiving the T_NoAnswer notification, the SCF does a Basic End by sending a blank
6.6 Unsuccessful MT Call: Calling Party Abandons Before Call

Answer
calling subscriber abandons the call before the called subscriber answers the call.
Assumptions:

Page 43 of 125
Prepay IN
GMSC/
gsmSSF
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
VMSC
MT Call
SRI ack (T-CSI)
Term_Attempt
Authorized
InitialDP
RequestReportBCSM
b
Continue
Provide Roaming
Number (PRN)
PRN ack
IAM
T_Abandon
EventReportBCSM
(T_Abandon)
TC_END
Figure 14 Unsuccessful MT Call: Calling Party Abandons Before Call Answer

d. The calling party abandons the call due to which the SSF detects the T_Abandon event. The
SSF reports the T_Abandon event to SCF by sending an EventReportBCSM message.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Abandon
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
Page 44 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
e. On receiving an abandon notification, the SCF does a Basic End by sending a blank
6.7 Unsuccessful MT Call : Called Party Busy

gsmSSF determines that the called subscriber is busy when a call delivery request arrives for
the called MS.
Assumptions:
GMSC/
gsmSSF
gsmSCF
HLR
VLR
MT Call
SRI ack (T-CSI)
Term_Attempt
Authorized
InitialDP
RequestReportBCSM
b
c
Continue
Provide Roaming
Number (PRN)
PRN ack
IAM
T_Busy
d
e
EventReportBCSM
(T_Busy)
TC_END
Figure 15 Unsuccessful MT Call: Called Party Busy

d. The calling party is busy with some other call due to which the SSF detects the T_Busy
event. The SSF reports the T_Busy event to SCF by sending an EventReportBCSM
message.
EventReportBCSM
Page 45 of 125
VMSC
Prepay IN
Parameter
eventTypeBCSM
Version: 1.0
Date: 07/17/2004
Description/Usage
Type

T_Busy
M(R)

O(O)
legID

leg.
O(R)
miscCallInfo
O(O)
messageType

O(O)
e. On receiving the T_Busy notification, the SCF does a Basic End by sending a blank TC_END
to the SSP to make sure all TCAP dialog related resources are released.
6.8 Unsuccessful MT Call: Unable To get Roaming Number

gsmSSF determines that the HLR is unable to get the routing number for the called party MS.
Assumptions:

Page 46 of 125
Prepay IN
GMSC/
gsmSSF
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
MT Call
SRI ack (T-CSI)
Term_Attempt
Authorized
InitialDP
RequestReportBCSM
b
Continue
Provide Roaming
Number (PRN)
PRN ack
SRI negative response

T_Busy
EventReportBCSM
(T_Busy)
TC_END
Figure 16 Unsuccessful MT Call: Unable to get Roaming Number

d. The gsmSSF sends SendRouteingInfo (SRI) request to the HLR to get the roaming number.
The HLR in turn tries to get the data from VLR by sending ProvideRouteingNumber (PRN)
request to the VLR. The VLR could not retrieve the routeing information and sends a PRN
negative response to the HLR. HLR conveys this error to gsmSSF by sending SRI negative
response message. This action triggers the T_Busy event. SSF detects the T_Busy event
and gsmSSF reports the T_Busy event to SCF by sending an EventReportBCSM message.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Busy
M(R)

O(O)
legID

leg.
O(R)
miscCallInfo
O(O)
Page 47 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
EventReportBCSM
Parameter
messageType
Description/Usage
Type

O(O)
e. On receiving the T_Busy notification, the SCF does a Basic End by sending a blank TC_END
Page 48 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
7 Feature Calls
7.1 Call Origination using HOLD
This section captures the CAMEL III call flow scenarios involved in a call origination by a Pre-Paid
subscriber after using the HOLD Supplementary Service on an active call.
This invocation is one where the Pre-Paid subscriber, while active on a call, puts the active call
on hold and then originates another call to a Third Party. The initial call (by the Pre-Paid
subscriber) that is active could be either MO or an MT call. When one call is on hold, and another
active, the Pre-Paid subscriber can do any of the following:
Toggle between the held call and the active call privacy between the calls is maintained.
Disconnect the held call
Disconnect the active call
Disconnect both the calls, the active call and the held call
From the above, it is implied that for the Pre-Paid subscriber to be able to originate another call
simultaneously, the Call Hold Supplementary Service must be Provisioned and be Active in the
HLR.
It is to be noted here that call origination after HOLD invocation is different from a GSM MultiParty call. The precondition under which a served mobile subscriber can request the network to
begin the Multi-Party service is that, the served mobile subscriber is in control of one active call
and one call is on hold, and that both calls should have been answered.
It should also be noted that 3-way calls (a conference call involving two call legs and three MS)
are not dealt with in this document. From the view of PPAS (or gsmSCF) the 3-way conf calls
are similar to Call-Hold calls as in there are two independent legs (second leg being an MO
call).
7.1.1 Successful Call Origination After HOLD: Pre-Paid MS Is On An MO

Call
This call scenario describes a successful call origination, after invocation of the HOLD
supplementary service, by a Pre-Paid Mobile Subscriber (MS).
Assumptions:
Pre-Paid Charging (PPC) is Active for Calling MS, and the Pre-Paid account
balance is above a pre-determined threshold value. The Pre-Paid subscriber is
engaged in a MO call before the subscriber makes the call to the second Called
Party.
A Pre-Call announcement is not played to the subscriber.
The Third Party disconnects the call first, after which the Pre-Paid MS continues its
call with the Original Called Party. The Pre-Paid MS then disconnects the call before
the expiry of funds in the account.
Page 49 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsm S S F
gsm S C F
C A LL 1
S u cce ssful N orm a l M O call - S te ps a-e
H O LD request
C ollected_Info
C allR efN um 2
C A LL 2
InitialD P
R equestR eportB C S M
C ontinue
O _Answ er
E ventR eportB C S M (O _A nsw er)
A pplyC harging
C all pro cessin g a s in d icated in S ec 5.1 ste ps f an d g
O _D isconnect
A pplyC hargingR eport
E ventR eportB C S M (O _ D isconnect)
TC _E N D
R etreive
H O LD call
C A LL 1
C all pro cessin g a s in d icated in S ec 5.1 ste ps f, g a n d h
O _D isconnect
A pplyC hargingR eport
E ventR eportB C S M (O _ D isconnect)
TC _E N D
Figure 17 Successful Call Origination After HOLD: Pre-Paid MS is on an MO Call

The steps a to e are the same as described in Section 5.1 Successful MO Call (Calling MS
f.
During the 2-Way conversation, as part of preparing to originate another call, the Pre-Paid
subscriber sends a hold request to the network, requesting to put the call on hold. The
Page 50 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Serving MSC puts the original Called Party on hold. The Pre-Paid MS originates another call
by entering the called digits, which triggers the Collected_info trigger at Serving MSC side.
The gsmSSF then sends an InitialDP message to the gsmSCF.
It must be noted here that the CallReferenceNum parameter in the InitialDP operation for the
second MO call will contain a value that is different from that contained in the InitialDP
operation for the initial MO call.
The PPAS determines that it has received another InitialDP operation for a second MO call
while the initial call is still ongoing.
PPAS also notes from the serviceInteractionIndicatorsTwo parameter of the first InitialDP
operation that the Pre-Paid MS can invoke the HOLD feature for the call. Hence the PPAS
concludes that the Pre-Paid MS has put the first call on hold and is originating a second call.
If the serviceInteractionIndicatorsTwo parameter is not available, the PPAS assumes that the
Pre-Paid MS can invoke the HOLD feature for the call.
g. The PPAS sends a RequestReportBCSMEvent operation to monitor and request the
following event notifications from the Serving MSC/gsmSSF for the second call origination:
O_Abandon

call.
O_Busy
O_Answer
O_NoAnswer
RouteSelectFailure
O_Disconnect
RequestReportBCSMEvent
Parameter
Description/Usage
Type
bcsmEvents


All
events,
except
O_Disconnect
are
armed
as
EDP-N
(notifyAndContinue). O_Disconnect is armed as EDP-R (interrupted) to
maintain monitor relationship with the SSF.
whereas O_Busy, O_Answer, O_NoAnswer and RouteSelectFailure are
always armed for Called Party (leg ID = 2).

h. Upon receipt of the (second) InitialDP operation, the PPAS validates the subscriber and it
requests the Serving MSC to continue call processing (from the DP at which it was previously
suspended awaiting instructions from PPAS) by sending a Continue operation to the Serving
MSC/gsmSSF.
i. The Serving MSC sets up the call to the second Called Party. The second Called Party
answers the call. The Serving MSC detects the O_Answer event and determines that PPAS
Page 51 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
has requested that it be notified of this call-related event (previously through a

RequestReportBCSMEvent operation). Hence the Serving MSC/gsmSSF sends an
EventReportBCSM operation to PPAS. Also, the Serving MSC (implicitly) disarms the
O_Answer, O_Busy, O_Abandon, and O_No_Answer detection points for the Pre-Paid MS
call to the second Called Party.
EventReportBCSM
Parameter
EventTypeBCSM
Description/Usage
Type

O_Answer.
M(R)

O(O)
LegID

O(O)
MiscCallInfo
O(O)
MessageType

O(O)
j. The gsmSCF sends an ApplyCharging operation to the Serving MSC/gsmSSF in order to

ApplyCharging
Parameter
Description/Usage
Type

following:
side.
CallingPartyNumber.
partyToCharge
Steps f and g of Section 5.1 follow to indicate the sending of multiple ApplyCharging
messages for handling SS7 link failure.
Page 52 of 125
Prepay IN
k.
Version: 1.0
Date: 07/17/2004
The PPAS starts to decrement the (Calling) Pre-Paid subscribers account balance for the
call. The second Called Party ends the call. The Serving MSC detects the O_Disconnect
event that has been armed for the Called Party leg and determines that a charging report is
to be sent (as requested by the PPAS in a previous ApplyCharging operation) and hence it
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
l.
The Serving MSC/gsmSSF sends an EventReportBCSM operation to PPAS to report the

O_Disconnect event.
EventReportBCSM
Parameter
EventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
LegID

O(R)
MiscCallInfo
O(O)
MessageType

O(O)
m. On receiving the O_Disconnect notification, the SCF does a Basic End by sending a blank
n. Steps f, g and h of Section 5.1 follow to indicate the sending of multiple Cancel,
RequestReportBCSM and ApplyCharging message for handling SS7 link failure.
The Serving MSC releases the Pre-Paid MS call to the second Called Party. Since the initial
call is on hold, the Pre-Paid subscriber will get a notification (from the MS itself and not the
MSC). The Pre-Paid subscriber retrieves the held call and hence the call to the initial called
party becomes active. The Pre-Paid subscriber ends the call.
The Serving MSC detects the O_Disconnect event that has been armed for the Calling Party
leg (of the initial call). It determines that PPAS has requested that it be notified of this callrelated event (previously requested by PPAS in a RequestReportBCSMEvent operation). The
second Called Party ends the call. The Serving MSC determines that a charging report is to
Page 53 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
o. The Serving MSC/gsmSSF sends an EventReportBCSM operation to PPAS to report the

O_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
LegID

O(O)
miscCallInfo
O(O)
messageType

O(O)
p. On receiving the O_Disconnect notification, the SCF does a Basic End by sending a blank
7.1.2 Successful Call Origination After HOLD: Pre-Paid MS Is On An MT

Call
This call scenario describes a successful cal origination by a Pre-Paid Mobile Subscriber (MS)
after the invocation of the HOLD supplementary service, while already on a MT call.
Assumptions:
engaged in a MT call before the subscriber originates the call to the second Called
Party.
The Third Party disconnects the call first, after which the Pre-Paid MS continues its
call with the Original Called Party. The Pre-Paid MS then disconnects the call before
the expiry of funds in the account.
Page 54 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
CALL 1
Successful Normal MT call - Steps a-e
HOLD request
CALL 2
Collected_Info
InitialDP
CallRefNum2
RequestReportBCSM
g
Continue
O_Answer
ApplyCharging
i
j
Call processing as indicated in Sec 5.1 steps f, g and h
O_Disconnect
ApplyChargingReport
k
l
TC_END
Retreive
HOLD call
m
CALL 1
Call processing as indicated in Sec 6.1 steps f, g and h
T_Disconnect
ApplyChargingReport
n
EventReportBCSM (T_Disconnect)
o
TC_END
Figure 18 Successful Call Origination After HOLD: Pre-Paid MS Is On An MT Call
Page 55 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The steps a to e are the same as described in Section 6.1 Successful MT Call (Called MS
f.
During the 2-Way conversation, as part of preparing to originate a call, the Pre-Paid
subscriber sends a hold request to the network, requesting to put the call on hold. The
Serving MSC puts the original Calling Party on hold. The Pre-Paid MS originates a call by
entering the called digits, which triggers the Collected_info trigger at Serving MSC side. The
gsmSSF then sends an InitialDP message to the gsmSCF.
MO call will contain a value that is different from that contained in the InitialDP operation for
the initial MT call.
The PPAS determines that it has received another InitialDP operation for a MO call while the
initial call is still ongoing.
operation that the Pre-Paid MS can invoke the HOLD feature for the call. Hence the PPAS
concludes that the Pre-Paid MS has put the first call on hold and is originating a second call.
If the serviceInteractionIndicatorsTwo parameter is not available, the PPAS assumes that the
Pre-Paid MS can invoke the HOLD feature for the call.

following event notifications from the Serving MSC/gsmSSF for the second call origination:
O_Abandon

call.
O_Busy
O_Answer
O_NoAnswer
RouteSelectFailure
O_Disconnect
Parameter
Description/Usage
Type
bcsmEvents


All
events,
except
O_Disconnect
are
armed
as
EDP-N
whereas O_Busy, O_Answer, O_NoAnswer and RouteSelectFailure are
always armed for Called Party (leg ID = 2).

Page 56 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
MSC/gsmSSF.
i. The Serving MSC sets up the call to the second Called Party. The second Called Party
answers the call. The Serving MSC detects the O_Answer event and determines that PPAS
has requested that it be notified of this call-related event (previously through a
RequestReportBCSMEvent operation). Hence the Serving MSC/gsmSSF sends an
EventReportBCSM operation to PPAS. Also, the Serving MSC (implicitly) disarms the
O_Answer, O_Busy, O_Abandon, and O_No_Answer detection points for the Pre-Paid MS
call to the second Called Party.
EventReportBCSM
Parameter
eventTypeBCSM
j.
Description/Usage
Type

O_Answer.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
The gsmSCF sends an ApplyCharging operation to the Serving MSC/gsmSSF in order to

ApplyCharging
Parameter
Description/Usage
Type

following:
side.
partyToCharge
Page 57 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004

This parameter will
CallingPartyNumber.
be
populated
with
the
k.
The PPAS starts to decrement the (Calling) Pre-Paid subscribers account balance for the
call. The second Called Party ends the call. The Serving MSC detects the O_Disconnect
event that has been armed for the Called Party leg and determines that a charging report is
to be sent (as requested by the PPAS in a previous ApplyCharging operation) and hence it
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
l.

O_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
m. On receiving the O_Disconnect notification, the SCF does a Basic End by sending a blank
n. Steps f, g and h of Section 5.1 follow to indicate the sending of multiple Cancel,
The Serving MSC releases the Pre-Paid MS call to the third Party. Since the initial call is on
hold, the Pre-Paid subscriber will get a notification (from the MS itself and not the MSC). The
Pre-Paid subscriber retrieves the held call and hence the call from the initial calling party
becomes active. The Pre-Paid subscriber ends the call.
Page 58 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The Serving MSC detects the T_Disconnect event that has been armed for the Called Party
Serving MSC determines that a charging report is to be sent (as requested by the PPAS in a
previous ApplyCharging operation) and hence it sends an ApplyChargingReport operation to
the PPAS.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)

T_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
p. On receiving the T_Disconnect notification, the SCF does a Basic End by sending a blank
7.1.3 Call Origination After HOLD: PPAS Disconnects Call Upon Funds
Expiry
This call scenario describes a successful call origination by a Pre-Paid Mobile Subscriber (MS) in
which the Serving MSC disconnects the three-party call when the subscriber runs out of funds in
the Pre-Paid account.
Assumptions:
Page 59 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Party.
The PPAS requests the Serving MSC to play a Mid-Call warning to the Calling MS
indicating that the duration allowed for the call is about to come to an end. The PPAS
also directs the Serving MSC to disconnect the Pre-Paid subscribers calls after the
maximum allowed call duration.
The warning timer can expire for the initial call or the second call. This scenario
caters the expiry of timer for the second call.
Page 60 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
CALL 1
Successful Normal MO call - Steps a-e
HOLD request
CALL 2
Collected_Info
InitialDP
CallRefNum2
RequestReportBCSM
g
Continue
O_Answer
ApplyCharging
Call processing as indicated in Sec 5.1 steps f and g
Warning timer
expires
ApplyChargingReport
ApplyCharging
Tpa
expires
Apply Charging Report

m
Retreive
HOLD call
CALL 1
Release Call
Figure 19 Call Origination After HOLD: PPAS Disconnects Call Upon Funds Expiry
Page 61 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The steps a to j are the same as described in Section 7.1.1 Successful Call Origination
After HOLD : Pre-Paid MS Is On An MO Call.
k.
The Warning Timer expires in the PPAS. At this point, the SCP waits for the
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
l.
After arming the O_Disconnect event, an ApplyCharging operation is sent to the Serving
MSC/gsmSSF in order to specify that a Mid-Call Warning should be played to the Pre-Paid
subscriber. This operation also specifies the maximum allowed remaining duration for the
call.
ApplyCharging
Parameter
Description/Usage
Type

following:
PPAS.
parameter).
when the warning tome timer expires on the
gsmSSF side.
This parameter is populated
partyToCharge
O
O

m. After hearing the warning tone, the subscriber conitues with the call till the funds expire.
Page 62 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
n. The Serving MSC releases the Pre-Paid MS call to the second Called Party. On PPAS side,
the call timer expires and the PPAS sends a ReleaseCall message to the gsmSSF and
forcefully disconnects the call.
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
7.1.4 Unsuccessful Call Origination After HOLD : Insufficient Balance For

Call To Third-Party
This call scenario describes a successful call origination by a Pre-Paid Mobile Subscriber (MS)
wherein the Calling MS has insufficient funds for originating the call to the Third Party (i.e. the
second Called party).
Assumptions:
Party.
The subscriber does not have sufficient balance in the Pre-Paid account to cover the
cost of the call to the second Called Party. Hence the PPAS denies the call
origination to the second Called Party.
The Pre-Paid subscriber continues with the call with the initial Called Party.
Page 63 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
CALL 1
Successful Normal MO call - Steps a-e
HOLD request
Collected_Info
InitialDP
CallRefNum2
Release Call
Retreive
HOLD call
CALL 2
f
g
CALL 1
O_Disconnect
ApplyChargingReport
TC_END
h
i
j
Figure 20 Unsuccessful Call Origination after HOLD: Insufficient Balance for Call to Third-Party
The steps a to e are the same as described in Section 7.1.1 Successful Call Origination
After HOLD : Pre-Paid MS Is On An MO Call.
f.
The PPAS determines that the subscribers account balance does not have sufficient funds to
continue the call, the PPAS SCF denies the call. In order to achieve this, the PPAS SCF
sends a ReleaseCall message to the SSF in a TC_END package.
ReleaseCall
Parameter
Description/Usage
Type
Page 64 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
g. Steps f and g of Section 5.1 follows to indicate the sending of multiple ApplyCharging
The Serving MSC releases the Pre-Paid MS call to the second Called Party. Since the initial
call is on hold, the Pre-Paid subscriber will get a notification (from the MS itself and not the
MSC). The Pre-Paid subscriber retrieves the held call and hence the call to the initial called
party becomes active. The Pre-Paid subscriber ends the call.
gsmSSF determines that a charging report is to be sent (as requested by the PPAS in a
previous ApplyCharging operation) and hence it sends an ApplyChargingReport operation to
the PPAS.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
h. The Serving MSC/gsmSSF sends an EventReportBCSM operation to PPAS to report the

O_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
Page 65 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
j. On receiving the O_Disconnect notification, the SCF does a Basic End by sending a blank
7.2 Call Waiting

This section captures the CAMEL III call flow scenarios for delivery of a call with Call Waiting to a
Pre-Paid Mobile Subscriber.
The Call Waiting feature permits the Pre-Paid mobile subscriber to be notified of an incoming call
while the traffic channel is not available for the incoming call and the mobile subscriber is
engaged in an active (either an MO or MT call) or held call. Subsequently, the subscriber can
accept, reject, or ignore the incoming call.
The maximum number of waiting calls at one time per mobile access is one. This means that no
further calls will be offered to the subscriber while a call is waiting.
As far as CAMEL processing is concerned, a Call Waiting call is treated by the GMSC and the
VMSC, in the same manner as that for a Mobile Terminated call leg. This means that for a MT
call that contains a Call Waiting leg, there would be two CAMEL relationships in the GMSC, one
each for the initial MT call leg and the subsequent CW leg.
7.2.1 Successful Call Delivery With Call Waiting: MS On A MT Call

This call scenario describes a successful call delivery to a Pre-Paid Mobile Subscriber with Call
Waiting when the Pre-Paid subscriber is engaged in a MT call.
Assumptions:
engaged in a MT call before the subscriber receives a call from the third Party.
Subscriber is engaged in a MT call when the Call Waiting notification arrives.
During the conversation with the Pre-Paid MS, the Third Party disconnects.
Page 66 of 125
Prepay IN
G M SC/
gsm SSF
gsm SCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
C ALL 1
Norm al M T C ALL IN PRO G RESS - Steps a-e
M T Call
S end Routeing Info (SRI)
CALL 2
SRI ack (T-CSI)

Term _Attem pt
Authorized
VM SC
InitialDP
RequestR eportBC SM
C ontinue
S end Routeing Info (SRI)

SRI ack (Routing Num ber)
Provide R oam ing

N um ber (PRN )
PRN ack
IAM
SIFIC
Page M S
Page ack
ACM
C om plete Call
ANM
T_A nsw er
EventReportBCSM (T_Answer)
ApplyCharging
ApplyC hargingReport
T_D isconnect
EventR eportBC SM
(T_D isconnect)
TC_EN D

T_D isconnect
n
o
p
C ALL 1
ApplyChargingReport
EventR eportBC SM
(T_D isconnect)
TC_EN D
Figure 21 Successful Call Delivery With Call Waiting: MS On A MT Call

The steps a to e are the same as described in Section 6.1 Successful MT Call (Called MS
Page 67 of 125
Prepay IN
f.
Version: 1.0
Date: 07/17/2004
During the 2-Way conversation, the GMSC receives a call for the Prepay subscriber. This
triggers the TermAttempt_Authorized trigger at Serving MSC side. The gsmSSF then sends
an InitialDP message to the gsmSCF.
second MT call will contain a value that is different from that contained in the InitialDP
operation for the initial MT call.
The PPAS determines that it has received another InitialDP operation for a MT call while the
initial call is still ongoing.
operation that the Pre-Paid MS can invoke the CALL WAITING feature for the call.

following event notifications from the Serving MSC/gsmSSF for the call origination:
T_Abandon

call.
T_Busy
T_Answer
T_NoAnswer
RouteSelectFailure
T_Disconnect
Parameter
Description/Usage
Type
bcsmEvents


All
events,
except
T_Disconnect
are
armed
as
EDP-N
whereas
T_CalledPartyBusy,
T_Answer,
T_NoAnswer
and

MSC/gsmSSF.
i. The Serving MSC pages the Pre-Paid MS, and offers the Call Waiting indication for this
second call delivery. The Pre-Paid subscriber accepts and answers the call. The Serving
MSC detects the T_Answer event and determines that PPAS has requested that it be notified
of this call-related event (previously through a RequestReportBCSMEvent operation). Hence
the Serving MSC/gsmSSF sends an EventReportBCSM operation to PPAS. Also, the
Page 68 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Serving MSC (implicitly) disarms the T_Answer, T_Busy, T_Abandon, and T_No_Answer
detection points for the Pre-Paid MS call.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Answer.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
j. The gsmSCF sends an ApplyCharging operation to the Serving MSC/gsmSSF in order to

ApplyCharging
Parameter
Description/Usage
Type

following:
side.
CallingPartyNumber.
partyToCharge
k.
Upon receipt of the T_Answer event notification, the PPAS starts to decrement the (Called)
Pre-Paid subscribers account balance for the call. The third Party ends the call. The Serving
Page 69 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
MSC detects the T_Disconnect event that has been armed for the Called Party leg. The SSF
determines that a charging report is to be sent (as requested by the PPAS in a previous
ApplyCharging operation) and hence it sends an ApplyChargingReport operation to the
PPAS.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
l.

T_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
m. On receiving the T_Disconnect notification, the SCF does a Basic End by sending a blank
n. The Serving MSC releases the Pre-Paid MS call to the third Party. Since the initial call is on
Pre-Paid subscriber retrieves the held call and hence the call to the initial called party
leg (of the initial call). The SSF determines that a charging report is to be sent (as requested
by the PPAS in a previous ApplyCharging operation) and hence it sends an
ApplyChargingReport operation to the PPAS.
ApplyChargingReport
Parameter
Description/Usage
Type
Page 70 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)

T_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
p. On receiving the T_Disconnect notification, the SCF does a Basic End by sending a blank
7.2.2 Successful Call Delivery With Call Waiting: MS On A MO Call

This call scenario describes a successful call delivery to a Pre-Paid Mobile Subscriber with Call
Waiting when the Pre-Paid subscriber is engaged in a MO call.
Assumptions:
engaged in a MO call before the subscriber receives a call from the third Party.
Subscriber is engaged in a MO call when the Call Waiting notification arrives.
During the conversation with the Pre-Paid MS, the Third Party disconnects.
Page 71 of 125
Prepay IN
GMSC/
gsmSSF
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
CALL 1
N orm al M O CALL IN PROGR ESS- Steps a-e
MT Call
Term_Attempt
Authorized
VMSC
CALL 2
SRI ack (T-CSI)
InitialDP
RequestReportBCSM
Continue

Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Page MS
Page ack
Complete Call
ACM
ANM
T_Answer
ApplyCharging

T_Disconnect
k
l
ApplyChargingReport
EventReportBCSM
(T_Disconnect)
TC_END
CALL 1

O_Disconnect
n
o
p
ApplyChargingReport
EventReportBCSM
(O_Disconnect)
TC_END
Figure 22 Successful Call Delivery With Call Waiting: MS On A MO Call
Page 72 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The steps a to e are the same as described in Section 5.1 Successful MO Call (Called MS
f.
During the 2-Way conversation, the GMSC receives a call for the Prepay subscriber. This
triggers the TermAttempt_Authorized trigger at Serving MSC side. The gsmSSF then sends
an InitialDP message to the gsmSCF.
second MT call will contain a value that is different from that contained in the InitialDP
operation for the initial MT call.
The PPAS determines that it has received InitialDP operation for a MT call while the initial call
is still ongoing.
operation that the Pre-Paid MS can invoke the CALL WAITING feature for the call.

following event notifications from the Serving MSC/gsmSSF for the call origination:
T_Abandon

call.
T_Busy
T_Answer
T_NoAnswer
RouteSelectFailure
TO_Disconnect
Parameter
Description/Usage
Type
bcsmEvents


All
events,
except
T_Disconnect
are
armed
as
EDP-N
whereas
T_CalledPartyBusy,
T_Answer,
T_NoAnswer
and

MSC/gsmSSF.
i.
The Serving MSC pages the Pre-Paid MS, and offers the Call Waiting indication for this
second call delivery. The Pre-Paid subscriber accepts and answers the call. The Serving
Page 73 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
MSC detects the T_Answer event and determines that PPAS has requested that it be notified
of this call-related event (previously through a RequestReportBCSMEvent operation). Hence
the Serving MSC/gsmSSF sends an EventReportBCSM operation to PPAS. Also, the
Serving MSC (implicitly) disarms the T_Answer, T_Busy, T_Abandon, and T_No_Answer
detection points for the Pre-Paid MS call.
EventReportBCSM
Parameter
eventTypeBCSM
j.
Description/Usage
Type

T_Answer.
M(R)

O(O)
legID

O(O)
miscCallInfo
O(O)
messageType

O(O)

ApplyCharging
Parameter
Description/Usage
Type

following:
side.
CallingPartyNumber.
partyToCharge
k.
Page 74 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Upon receipt of the T_Answer event notification, the PPAS starts to decrement the (Called)
Pre-Paid subscribers account balance for the call. The third Party ends the call. The Serving
MSC detects the T_Disconnect event that has been armed for the Called Party leg. The SSF
determines that a charging report is to be sent (as requested by the PPAS in a previous
ApplyCharging operation) and hence it sends an ApplyChargingReport operation to the
PPAS.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
l.

T_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
n. The Serving MSC releases the Pre-Paid MS call to the third Party. Since the initial call is on
Pre-Paid subscriber retrieves the held call and hence the call to the initial party becomes
active. The Pre-Paid subscriber ends the call.
ApplyChargingReport
Parameter
Description/Usage
Type
Page 75 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)

O_Disconnect event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
p. On receiving the O_Disconnect notification, the SCF does a Basic End by sending a blank
7.2.3 Call Waiting: Pre-Paid Subscriber Ignores CW Notification Or

Indicates UDUB
This call scenario describes an unsuccessful call delivery to a Pre-Paid Mobile Subscriber (MS)
with Call Waiting, unsuccessful because the Pre-Paid subscriber ignores the Call Waiting
notification.
Assumptions:
engaged in a MT call before the subscriber receives a call from the third Party.
Subscriber is engaged in a MT call when the Call Waiting notification arrives.
While engaged in the call, the Pre-Paid subscriber receives a Call Waiting
notification. The subscriber either ignores the notification or indicates UDUB
condition.
Page 76 of 125
Prepay IN
GMSC/
gsmSSF
IAM
Term_Attempt
Authorized
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
VMSC
Normal MT CALL IN PROGRESS- Steps a-e
CALL 1
CALL 2
SRI ack (T-CSI)
InitialDP
RequestReportBCSM
Continue

Provide Roaming
Number (PRN)
PRN ack
IAM
Start
T_TNRy
SIFIC
Page MS
Page MS
negative ack
Complete Call
negative
Response
T-TNRy
expires
T_NoAnswer
i
j
EventReportBCSM
(T_NoAnswer)
TC_END
CALL 1

T_Disconnect
k
l
m
ApplyChargingReport
EventReportBCSM
(T_Disconnect)
TC_END
Figure 23 Call Waiting: Pre-Paid Subscriber Ignores CW Notification Or Indicates UDUB
Page 77 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The steps a to h are the same as described in Section 7.2.1 Successful Call Delivery with
Call Waiting: MS On A MT Call.
i. The subscriber receives the Call Waiting notification and decides to ignore the call. The
T_TNRy timer at Serving MSC side expires, which triggers the T_NoAnswer trigger at the
Serving MSC side. The Serving MSC sends an EventReportBCSM operation to PPAS to
report the T_NoAnswer event. Also, the Serving MSC (implicitly) disarms the T_Answer,
T_Busy, T_Abandon, and T_No_Answer detection points for the Pre-Paid MS call.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

T_NoAnswer.
M(R)

O(O)
legID

indicate that the called party did not answer the call.
O(R)
miscCallInfo
O(O)
messageType

O(O)
j. On receiving the T_NoAnswer notification, the SCF does a Basic End by sending a blank
k.
The Serving MSC releases the Pre-Paid MS call to the third Party. Since the initial call is on
Pre-Paid subscriber retrieves the held call and hence the call to the initial called party
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
l.

T_Disconnect event.
EventReportBCSM
Page 78 of 125
Prepay IN
Parameter
eventTypeBCSM
Version: 1.0
Date: 07/17/2004
Description/Usage
Type

T_Disconnect.
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
7.2.4 Unsuccessful Call Waiting Call: Insufficient Funds

This call scenario describes an unsuccessful call delivery to a Pre-Paid Mobile Subscriber (MS)
with Call Waiting, unsuccessful because the Pre-Paid subscriber does not sufficient funds to
receive a call.
Assumptions:
Pre-Paid Charging (PPC) and Call Waiting features are Active for the Called MS,
and the account balance is above a pre-determined threshold value.
While engaged in a call with an initial Calling Party, the Pre-Paid subscriber receives
a Call Waiting call. However, the Pre-Paid MS does not have sufficient balance in its
account to cover the cost of the Call Waiting call. Hence the PPAS denies this call.
GMSC/
gsmSSF
gsmSCF
MT Call
CALL 1
CALL 2
SRI ack (T-CSI)

Term_Attempt
Authorized
InitialDP
f
g
Release Call
Release Call
CALL 1
Figure 24 Unsuccessful Call Waiting Call: Insufficient Funds
Page 79 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The steps a to f are the same as described in Section 7.2.1 Successful Call Delivery With
g. The PPAS determines that the Pre-Paid subscriber does not have sufficient funds in the
account for the call. Hence it denies the PPC service to the Pre-Paid (Called) MS for the Call
Waiting call by sending a ReleaseCall operation to the GMSC/gsmSSF.
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
h. The PPAS also terminates the initial call by sending ReleaseCall operation to the
GMSC/gsmSSF.
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
7.2.5 Call Delivery With Call Waiting: PPAS Disconnects Call Upon Funds
Expiry
This call scenario describes a successful call delivery to a Pre-Paid Mobile Subscriber (MS) with
Call Waiting where in the PPAS disconnects the calls when the subscriber runs out of funds in the
Pre-Paid account.
Assumptions:
Pre-Paid Charging (PPC) and Call Waiting features are Active for the Called MS,
and account balance is above a pre-determined threshold value.
The Pre-Paid subscriber accepts a Call Waiting call while already on a MT call.
During the conversation with the Third Party (i.e. the second call), the PPAS
disconnects both the Call Waiting call as well as the initial MT call after playing a MidCall warning.
Page 80 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSCF
VLR
GMSC/
gsmSSF
HLR
VMSC
CALL 1
MT Call
Term_Attempt
Authorized
g
h
CALL 2
SRI ack (T-CSI)
InitialDP
RequestReportBCSM
Continue
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Page MS
Page ack
Complete Call
ACM
ANM
T_Answer
i
j
ApplyCharging
k
Tcp
expires
l
n
ApplyChargingReport
Warning timer
expires
ApplyCharging
ApplyChargingReport
CALL 1
ReleaseCall
Figure 25 Call Delivery With Call Waiting: PPAS Disconnects Call Upon Funds Expiry
The steps a to j are the same as described in Section 7.2.1 Successful Call Delivery With
Page 81 of 125
Prepay IN
k.
Version: 1.0
Date: 07/17/2004
The Warning Timer expires in the PPAS. Hence the PPAS sends a Cancel operation to the
gsmSSF to disarm all the pending events and to cancel all the pending reports. Cancel
operation has no parameters.
Cancel
Parameter
Description/Usage
Type
invokeID
Specifies which parameter invocation to be cancelled, in case of pre-call

announcement. This parameter will not be populated.
allRequests
This parameter indicates all the active requests for EDP reports,
ApplyChargingReport and CallInformationReport to be cancelled. This
parameter will be populated.
l.
The PPAS then sends a RequestReportBCSMEvent operation to arm the Disconnect event
for both legs.
RequestReportBCSM
Parameter
Description/Usage
Type
bcsmEvents


Only T_Disconnect is armed as EDP-R (interrupted) to maintain monitor
Called Party.

m. After arming the T_Disconnect event, an ApplyCharging operation is sent to the Serving
MSC/gsmSSF in order to specify that a Mid-Call Warning should be played to the Pre-Paid
subscriber. This operation also specifies the maximum allowed remaining duration for the
call.
ApplyCharging
Parameter
Description/Usage
Type

following:
PPAS.
This parameter is populated with the remaining time
duration of the call.
parameter).
Page 82 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyCharging
Parameter
partyToCharge
Description/Usage
Type

when the warning tone timer expires on the gsmSSF
side.
This
parameter
is
populated
with
the
CalledPartyNumber.
O
R

n. After hearing the warning tone, the subscriber conitues with the call till the funds expire.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
o. The Serving MSC releases the Pre-Paid MS call to the third Party. On PPAS side, the call
timer expires for the initial call. PPAS sends a ReleaseCall message to the gsmSSF and
forcefully disconnects the initial call.
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
Page 83 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
7.3 Call Forwarding

This section captures the CAMEL III call flow scenarios involved in Call Forwarding for a Pre-Paid
subcriber.
The following types of call forwarding are considered:
Call Forwarding Unconditional (CFU)

The CFU feature permits a called Pre-Paid mobile subscriber to have the network
forward all incoming calls to another directory number. The ability of the Pre-Paid mobile
subscriber to originate calls is not affected. If CFU is active, calls are forwarded
regardless of the condition of the termination.
Call Forwarding Busy (CFB)

The CFB feature permits a called Pre-Paid mobile subscriber to have the network forward
all incoming calls to another directory number when the network encounters the mobile
subscriber busy condition. The ability of the Pre-Paid mobile subscriber to originate calls
is unaffected. If CFB feature is active, a call is forwarded only if the call meets mobile
subscriber busy condition.
Call Forwarding On No Reply (CFNRy)

The CFNRy feature permits a called Pre-Paid mobile subscriber to have the network
forward all incoming calls to another directory number when the network encounters a
No reply condition. The ability of the Pre-Paid mobile subscriber to originate calls is
unaffected. If CFNRy feature is active, a call is forwarded only if the call meets No Reply
condition.
Call Forwarding On MS Not Reachable (CFNRc)

The CFNRc feature permits a called Pre-Paid mobile subscriber to have the network
forward all incoming calls to another directory number when the subscriber is not
reachable. The ability of the Pre-Paid mobile subscriber to originate calls is unaffected.
There can be two cases of CFNRc - one detected by HLR (i.e. First HLR Forwarding),
and the other detected by the VLR (i.e. Late Forwarding; e.g. No page response, radio
congestion, IMSI Detach condition)
7.3.1 Successful Call Forwarding On No Reply
This call scenario describes a successful call forwarding invocation on No Answer

during call delivery to a Pre-Paid subscriber.
Assumptions:
Pre-Paid Charging (PPC) and Call Forwarding On No Reply (CFNRy) features are
Active for the (Pre-Paid) Called MS, and the Pre-Paid account balance is above a
pre-determined threshold value. CFU is NOT Active for the call - if CFU is Active
then CFU takes precedence over CFNRy in the HLR.
The Called MS (i.e. the Pre-Paid subscriber) does not answer the incoming call and
hence the call gets forwarded to the Forwarded-To number.
Page 84 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004

GMSC/
gsmSSF
MT Call
gsmSCF
HLR
VLR
VMSC

SRI ack (T-CSI)
Term_Attempt
Authorized
b
c
InitialDP
RequestReportBCSM
Continue
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Start
T_TNRy
Page MS
Page MS
negative ack
Complete Call
negative response
CFNRy
detected
Collected
_Info
InitialDP
TC_END
RequestReportBCSM
Continue
O_
Answer
EventReportBCSM
(O_Answer)
ApplyCharging

O_
Disonnect
ApplyChargingReport
EventReportBCSM(O_Disconnect)
TC_END
k
l
Figure 26 Successful Call Forwarding On No Reply

The steps a to c are the same as described in Section 6.1 Successful MT Call: Called Party
Disconnects.
Page 85 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
d. The Serving MSC pages, and alerts the Called (Pre-Paid) MS. The Pre-Paid subscriber does
not answer the call. The Serving MSC/VLR detects that CFNRy is Registered and Active.
Hence it prepares to setup the forwarded leg. The Serving MSC/gsmSSF determines that the
O-CSI is available for the subscriber. It detects the Collected_Info trigger for the forwarded
leg of the call, and sends an InitialDP message to the PPAS.
InitialDP
Parameter
Description/Usage
Type
serviceKey

M(R)
calledPartyNumber
Identifies the called party in the forward direction, i.e.

the forwarded-to-party.
O(R)
callingPartyNumber
O(R)

O(O)
locationNumber

area
address
for
mobility
services,
see
Recommendation
Q.762.
It
is
used
when
O(O)

O(R)

O(O)

O(O)
bearerCapability

O(O)
eventTypeBCSM

InitialDP operation i.e. CollectedInfo.
This
determines
the
direction
of
the
call
(origination/termination, origination for CollectedInfo).
O(R)
redirectingPartyID

O(O)
This
parameter
information.
O(R)
contains
forwarding
related
Page 86 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type
iPSSPCapabilities

O(O)

based services.
The callDiversionTreatmentIndicator field within
forwardServiceInteractionIndicator will indicate that
Call Diversion (i.e. Call Forwarding or Call Deflection)
can be accepted for the call.
O(O)
iMSI

invoked.
O(O)
subscriberState

O(O)
locationInformation

whereabouts.
O(R)
O(O)
callReferenceNumber

In
the
case
of
forwarded
calls,
the
callReferenceNumber is the one set by the GMSC.
Same as that one for the related MT leg.
O(O)
mscAddress

forwarded MSC.
O(O)
gmscAddress

GMSC.
O(O)

characters.
O(O)
time&TimeZone

resides in.
O(R)

in the VMSC.
O(R)
Page 87 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type
Carrier

O(O)
cug-Index

the user.
O(O)
cug-Interlock

network.
O(O)
cug-OutgoingAccess

O(O)
cGEncountered

O(O)
cause

triggered the event
O(O)
e. The PPAS ends the TCAP transaction with the GMSC for the original MT call by sending a
TC_END message. (Note: If this is not done, then the PPAS would receive event notifications
from both the GMSC as well as the Serving MSC for the forwarded leg of the call).
f.
The PPAS sends a RequestReportBCSMEvent operation to monitor and request the

O_Abandon

call.
O_Busy
O_Answer
O_NoAnswer
RouteSelectFailure
O_Disconnect
RequestReportBCSM
Parameter
Description/Usage
Type
bcsmEvents


All
events,
except
O_Disconnect
are
armed
as
EDP-N
Page 88 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
RequestReportBCSM
Parameter
Description/Usage
Type
whereas
O_CalledPartyBusy,
O_Answer,
O_NoAnswer
and

g. PPAS determines that

the gsmSSF.
Note:

h. Once the forwarded-to party answers the call, the SSF encounters the O_Answer Detection
Point. The SSF sends an EventReportBCSM message to the SCF and implicitly disarms the
detection points.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Answer.
M(R)

Destination address of the call leg (i.e. the
forward-to leg).
ForwardedCall indicating that the call has
been subject to GSM call forwarding.
O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
Page 89 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
i.

ApplyCharging
Parameter
Description/Usage
Type

following:
side.
CallingPartyNumber.
partyToCharge
j.
When the forwarded-to party disconnects the call, the SSF encounters the O_Disconnect
detection point and the gsmSSF determines that a charging report is to be sent (as requested
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
Page 90 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
k.
The SSF sends an EventReportBCSM message to the SCF to report the O_Disconnect
event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
legID

indicate that the called party (in this case forwardedto party) disconnected the call.
O(R)
miscCallInfo
O(O)
messageType

O(O)
calling party.
l.
7.3.2 Successful VLR-Determined CFNRc: MS Not Reachable

This call scenario describes a call forwarding scenario for a Pre-Paid Mobile Subscriber
where in the VLR determines that the MS is Not Reachable. VLR determined CFNRc
could be because, during call delivery to the MS the VLR detected a power-down
condition (i.e. IMSI Detatch), or the MS failed to respond to the MSCs page request, or
because of radio congestion.
Assumptions:
Pre-Paid Charging (PPC) and CFNRc features are Active for the (Pre-Paid) Called
MS, and the Pre-Paid account balance is above a pre-determined threshold value.
CFU is NOT Active for the call - if CFU is Active then CFU takes precedence over
CFNRc in the HLR.
CFNRc is due to late-forwarding, i.e. the VLR/MSC determines that the MS is not
reachable, and hence the call has to be forwarded.
Page 91 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
GMSC/
gsmSSF
MT Call
gsmSCF
HLR
VLR
VMSC

SRI ack (T-CSI)
Term_Attempt
Authorized
b
c
InitialDP
RequestReportBCSM
Continue
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Start
T_TNRy
Page MS
Page MS
negative ack
Complete Call
negative response
CFNRc
detected
Collected
_Info
InitialDP
TC_END
RequestReportBCSM
Continue
O_
Answer
EventReportBCSM
(O_Answer)
ApplyCharging

O_
Disonnect
ApplyChargingReport
TC_END
k
l
Figure 27 Successful VLR-Determined CFNRc: MS Not Reachable

Disconnects.
Page 92 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The VLR detects a CFNRc condition. VLR determined CFNRc could be because, the VLR
detected a power-down condition (i.e. IMSI Detatch), or the MS failed to respond to the MSCs
page request, or MSC detects a radio congestion.
It also determines that CFNRc is Registered and Active for the call. Hence it requests the MSC to
forward the call. The Serving MSC prepares to set up the call to the Forwarded-To party.
The steps d to l are the same as described in Section 7.3.1 Successful Call Forwarding On No
Reply.
7.3.3 Successful Call Forwarding On Subscriber Busy NDUB or UDUB
This call scenario describes a successful call forwarding invocation on Busy condition during call
delivery to a Pre-Paid MS.
Assumptions:
Pre-Paid Charging (PPC) and Call Forwarding Busy features are Active for the
(Pre-Paid) Called MS, and the Pre-Paid account balance is above a pre-determined
threshold value.
The Serving MSC encounters a Busy condition for the Called MS, and Call Waiting
is not applicable. The call gets forwarded. The Busy condition could be either NDUB
or UDUB.
Page 93 of 125
Prepay IN
GMSC/
gsmSSF
MT Call
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
VMSC

SRI ack (T-CSI)
Term_Attempt
Authorized
b
c
InitialDP
RequestReportBCSM
Continue
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Start
T_TNRy
Page MS
Page MS
negative ack
Complete Call
negative response
UDUB/NDUB
condition
detected
InitialDP
TC_END
Collected
_Info
RequestReportBCSM
Continue
O_
Answer
EventReportBCSM
(O_Answer)
ApplyCharging

O_
Disonnect
ApplyChargingReport
TC_END
k
l
Figure 28 Successful Call Forwarding On Subscriber Busy NDUB or UDUB
Disconnects.
Page 94 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The VLR/MSC detects a Subscriber Busy condition could be either NDUB (i.e. MS fails to
respond to MSCs page) or UDUB (i.e. Pre-Paid subscriber initiates a busy condition). It also
determines that CFB is Registered and Active for the call. Hence it requests the MSC to forward
the call. The Serving MSC prepares to set up the call to the Forwarded-To party
The steps d to l are the same as described in Section 7.3.1 Successful Call Forwarding On No
Reply.
7.3.4 Unsuccessful CFNRy/CFNRc/CFB: Calling Party Abandons Call

Before Forwarded-To Party Answer
This call scenario describes an unsuccessful CFNRy, or CFNRc, or CFB invocation for a PrePaid MS, unsuccessful because the Calling Party abandons the call.
Assumptions:
Pre-Paid Charging (PPC) and the corresponding call forwarding feature (CFNRy, or
CFNRc, or CFB) is Active for the (Pre-Paid) Called MS, and the Pre-Paid account
balance is above a pre-determined threshold value.
The Calling Party abandons before the Forwarded-To Party answers the call.
Page 95 of 125
Prepay IN
GMSC/
gsmSSF
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
VMSC
MT Call
SRI ack (T-CSI)
Term_Attempt
Authorized
InitialDP
a
RequestReportBCSM
b
Continue
c
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Start
T_TNRy
Page MS
Page MS
negative ack
Complete Call
negative response
CFNRc
detected
Collected
_Info
InitialDP
d
TC_END
e
RequestReportBCSM
f
Continue
EventReportBCSM
(O_Abandon)
TC_END
h
i
Figure 29 Unsuccessful CFNRy/CFNRc/CFB: Calling Party Abandons Call Before Forwarded-To

Party Answer
The steps a to g are the same as described in Section 7.3.1 Successful Call Forwarding On
No Reply.
O_
Abandon
Page 96 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
h. As the calling subscriber abandons the call, SSF determines that O_Abandon event has
occurred. The SSF reports the O_Abandon event to SCF by sending an EventReportBCSM
message.
EventReportBCSM
Parameter
eventTypeBCSM
i.
Description/Usage
Type

O_Abandon
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
On receiving a abandon notification, the SCF does a Basic End by sending a blank TC_END
7.3.5 Unsuccessful CFNRy/CFNRc/CFB: Forwarded-To Party Does Not

Answer Or Is Busy
This call scenario describes a CFNRy/CFNRc/CFB scenario for a Pre-Paid Mobile Subscriber
(MS) where in the Forwarded-To Party is either Busy or does not answer the call.
Assumptions:
Pre-Paid Charging (PPC) and the corresponding Call Forwarding features (one of
CFNRy, CFNRc, or CFB) are Active for the Pre-Paid (Called) MS.
The call gets forwarded, but the Forwarded-To Party is either Busy or does not
answer the call.
Page 97 of 125
Prepay IN
GMSC/
gsmSSF
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
VMSC
MT Call
SRI ack (T-CSI)
Term_Attempt
Authorized
InitialDP
a
RequestReportBCSM
b
Continue
c
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Start
T_TNRy
Page MS
Page MS
negative ack
Complete Call
negative response
CFNRc
detected
Collected
_Info
InitialDP
d
TC_END
e
RequestReportBCSM
f
Continue
EventReportBCSM
(O_Busy/
O_NoAnswer)
g
O_Busy/
O_NoAnswer
TC_END
i
Figure 30 Unsuccessful CFNRy/CFNRc/CFB: Forwarded-To Party Does Not Answer Or Is Busy

The steps a to g are the same as described in
On No Reply.
Section 7.3.1 Successful Call Forwarding
h. The Forwarded-To Party is either busy or does not answer the call. Hence the switch of the
Forwarded-To Party releases the forwarded call leg towards the Serving MSC. Depending on
whether the Forwarded-To Party was busy or did not answer the call, the Serving
Page 98 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
MSC/gsmSSF detects an O_Busy or O_No_Answer event. The MSC/gsmSSF sends an

EventReportBCSM operation to PPAS to report the O_Busy/ O_NoAnswer event.
EventReportBCSM
Parameter
eventTypeBCSM
i.
Description/Usage
Type

O_Busy / O_NoAnswer
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
On receiving O_Busy/O_NoAnswer notification, the SCF does a Basic End by sending a

7.3.6 Successful Call Forward Unconditional
This call scenario describes a successful call forwarding unconditional invocation for a Pre-Paid
MS.
Assumptions:
Pre-Paid Charging (PPC) and Call Forwarding Unconditional features are Active for
the (Pre-Paid) Called MS, and the Pre-Paid account balance is above a predetermined threshold value.
CFU is due to first-forwarding in the HLR.
Forwarded-To-Party disconnects the call before expiry of funds in the subscribers

account.
Page 99 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
TermAttempt_
Authorized
InitialDP
a
Continue
b
CFU Pending
Collected_Info
InitialDP
RequestReportBCSM
Continue
O_Answer
ApplyCharging
Call processing as indicated in Sec 5.1 steps e and f
O_Disconnect
ApplyChargingReport
h
i
TC_END
Figure 31 Successful Call Forward Unconditional

The GMSC receives a call setup request (Mobile Termination) for the Pre-Paid MS. The GMSC
determines that it needs to get the T-CSI information (essentially the CAMEL TDP list). Hence it
sends a SendRoutingInfo Invoke MAP operation to the subscribers HLR. (The SRI operation will
Page 100 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
NOT contain the suppress T-CSI parameter, which indicates to the HLR to do CAMEL CSI
instead of getting the Roaming Number from the VLR/MSC).
The HLR determines that the subscriber has CFU Provisioned and Active and that the maximum
number of forwardings has not been reached for the call. Hence it returns the Forward-ToNumber to the GMSC (along with the O-CSI and T-CSI) in the SRI Response message.
a. The GMSC detects the Termination_Attempt_Authorized trigger (for the MT call leg and NOT
the forwarded leg) and hence sends an InitialDP operation to the PPAS requesting for call
processing instructions. The InitialDP operation will also indicate that forwarding is pending
for the call.
InitialDP
Parameter
Description/Usage
Type
serviceKey

M(R)
calledPartyNumber
Identifies the called party in the forward direction.

Since forwarding is pending at the GMSC for the
call, this parameter represents the MSISDN of the
Called MS (NOT the forward-to-number).
O(R)
callingPartyNumber
O(R)

O(O)
locationNumber

area
address
for
mobility
services,
see
Recommendation
Q.762.
It
is
used
when
O(O)

O(R)

O(O)

O(O)
bearerCapability

O(O)
Page 101 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type
eventTypeBCSM

InitialDP
operation
i.e.
Term_Attempt_Authorized. This determines the
direction of the call (origination/termination, termination
for Term_Attempt_Authorized).
O(R)
redirectingPartyID

O(O)
This
parameter
information.
related
O(O)
iPSSPCapabilities

O(O)

based services.
The callDiversionTreatmentIndicator field within
forwardServiceInteractionIndicator will indicate that
Call Diversion (i.e. Call Forwarding or Call Deflection)
can be accepted for the call.
O(O)
iMSI

invoked.
O(O)
subscriberState

O(O)
locationInformation

whereabouts.
O(R)
O(O)
callReferenceNumber

In
the
case
of
forwarded
calls,
the
callReferenceNumber is the one set by the GMSC.
Same as that one for the related MT leg.
O(R)
mscAddress

forwarded MSC.
O(O)
gmscAddress

GMSC.
O(O)

characters.
O(O)
contains
forwarding
Page 102 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type
time&TimeZone

resides in.
O(R)

in the VMSC.
This indicates that a Forward-to-number was
received (from the HLR) and the call will be
forwarded due to GSM Forwarding.
O(R)
Carrier

O(O)
cug-Index

the user.
O(O)
cug-Interlock

network.
O(O)
cug-OutgoingAccess

O(O)
cGEncountered

O(O)
cause

triggered the event
O(O)
b. The PPAS determines that the subscriber has Pre-Paid Charging (PPC) Active, that the
subscribers account balance is above a pre-determined threshold level, and that the MT call
can be allowed. Hence it requests the GMSC to continue call processing by sending a
Continue operation to the GSMC/gsmSSF. This Continue operation is for the original MT
call.
Since the InitialDP operation contained the gsm-ForwardingPending parameter (indicating
Call Forwarding is pending at the GMSC), the PPAS will not send a
RequestReportBCSMEvent operation to the GMSC/gsmSSF requesting to detect events like
Answer, Disconnect for this MT leg. Since no events have been armed for the MT call, the
GMSC/gsmSSF, after it receives the Continue (in the TCAP_End pkg), will not have a
CAMEL relationship with the PPAS for this MT call and start a new dialogue for the forwarded
leg as described in the steps given below.
c.
The GMSC/gsmSSF detects that the call has to be forwarded (i.e. a CFU is pending). It
detects a Collected_Info trigger for (the forwarded-leg) of the call. Hence it sends an
InitialDP operation to the PPAS requesting call processing instructions for the forwarded leg.
InitialDP
Parameter
Description/Usage
Type
Page 103 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004

InitialDP
Parameter
Description/Usage
Type
serviceKey

M(R)
calledPartyNumber
Indicates the Called Party in the forward direction i.e.

forward-to-party
O(R)
callingPartyNumber
O(R)

O(O)
locationNumber

area
address
for
mobility
services,
see
Recommendation
Q.762.
It
is
used
when
O(O)

O(O)

O(O)

O(O)
bearerCapability

O(O)
eventTypeBCSM

InitialDP operation i.e. CollectedInfo.
This
determines
the
direction
of
the
call
(origination/termination, origination for CollectedInfo).
O(R)
redirectingPartyID

O(O)
This
parameter
information.
related
O(O)
iPSSPCapabilities

O(O)
contains
forwarding
Page 104 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type

based services.
O(O)
iMSI

invoked.
O(R)
subscriberState

O(O)
locationInformation

whereabouts.
O(O)
O(O)
callReferenceNumber

O(O)
mscAddress

MSC.
O(O)
gmscAddress

GMSC.
O(O)

characters.
O(O)
time&TimeZone

resides in.
O(O)

in the VMSC.
O(O)
Carrier

O(O)
cug-Index

the user.
O(O)
cug-Interlock

network.
O(O)
cug-OutgoingAccess

O(O)
Page 105 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
InitialDP
Parameter
Description/Usage
Type
cGEncountered

O(O)
cause

triggered the event
d. The PPAS sends a RequestReportBCSMEvent operation to monitor and request the

O_Abandon

call.
O_Busy
O_Answer
O_NoAnswer
RouteSelectFailure
O_Disconnect
RequestReportBCSM
Parameter
Description/Usage
Type
bcsmEvents


All
events,
except
O_Disconnect
are
armed
as
EDP-N
whereas
O_CalledPartyBusy,
O_Answer,
O_NoAnswer
and

e. PPAS determines that

the gsmSSF.
Note:
Page 106 of 125
Prepay IN
f.
Version: 1.0
Date: 07/17/2004
Once the forwarded-to party answers the call, the SSF encounters the O_Answer Detection
Point. The SSF sends an EventReportBCSM message to the SCF and implicitly disarms the
detection points.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Answer.
M(R)

Destination address of the call leg (i.e. the
forward-to leg).
ForwardedCall indicating that the call has
been subject to GSM call forwarding.
O(O)
legID

O(O)
miscCallInfo
O(O)
messageType

O(O)
ApplyCharging
Parameter
Description/Usage
Type

following:
Page 107 of 125
Prepay IN
partyToCharge
Version: 1.0
Date: 07/17/2004

side.
CallingPartyNumber.
h. Steps f, g and h of Section 6.1 follows to indicate the sending of multiple Cancel,
When the forwarded-to party disconnects the call, the SSF encounters the O_Disconnect
detection point and determines that a charging report is to be sent (as requested by the
ApplyChargingReport
Parameter
Description/Usage
Type
CallResult

M(R)
M(O)
M(R)
M(R)

O(R)
i.
The SSF sends an EventReportBCSM message to the SCF to report the O_Disconnect
event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Disconnect.
M(R)

O(O)
legID

indicate that the called party (in this case forwardedto party) disconnected the call.
O(R)
miscCallInfo
O(O)
messageType

O(O)
Page 108 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
calling party.
j.
7.3.7 Unsuccessful CFU: Calling Party Abandons Call Before ForwardedTo Party Answer
This call scenario describes an unsuccessful call forwarding unconditional invocation for a PrePaid MS, unsuccessful because the Forwarded-To Party Calling Party abandons the call.
Assumptions:
Pre-Paid Charging (PPC) and Call Forwarding Unconditional features are Active for
the (Pre-Paid) Called MS, and the Pre-Paid account balance is above a predetermined threshold value.
CFU is due to first-forwarding in the HLR.
The Calling Party abandons before the Forwarded-To Party answers the call.
gsmSSF
gsmSCF
TermAttempt_
Authorized
InitialDP
a
Continue
CFU Pending
Collected_Info
InitialDP
RequestReportBCSM
Continue
c
d
e
O_Abandon
EventReportBCSM (O_Abandon)
TC_END
g
Figure 32 Unsuccessful CFU: Calling Party Abandons Call Before Forwarded-To Party Answer
The steps a to e are the same as described in Section 7.3.6 Successful Call Forwarding
Unconditional.
Page 109 of 125
Prepay IN
f.
Version: 1.0
Date: 07/17/2004
As the calling subscriber abandons the call, SSF determines that O_Abandon event has
occurred. The SSF reports the Abandon event to SCF by sending an EventReportBCSM
message.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Abandon
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
g. On receiving an abandon notification, the SCF does a Basic End by sending a blank
7.3.8 Unsuccessful CFU: Forwarded-To Party Is Busy Or Does Not Answer

This call scenario describes a call-forwarding scenario for a Pre-Paid Mobile Subscriber (MS)
where in the Forwarded-To Party is either Busy or does not answer the call.
Assumptions:
Pre-Paid Charging (PPC) and Call Forwarding features (any of CFU, CFNRc, or
CFB, or CFNRy) are Active for the (Pre-Paid) Called MS.
The call gets forwarded, but the Forwarded-To Party is either Busy or does not
answer the call
Page 110 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
TermAttempt_
Authorized
InitialDP
a
Continue
CFU Pending
Collected_Info
InitialDP
RequestReportBCSM
Continue
O_Busy/
O_NoAnswer
EventReportBCSM (O_Busy/O_NoAnswer)
TC_END
g
Figure 33 Unsuccessful CFU: Forwarded-To Party Is Busy Or Does Not Answer
The steps a to e are the same as described in Section 7.3.6 Successful Call Forwarding
Unconditional.
f.
The Forwarded-To Party is either Busy or does not answer the call. The GMSC hence
detects the O_Busy or O_No_Answer event. The GMSC/gsmSSF sends an
EventReportBCSM operation to PPAS to report the event.
EventReportBCSM
Parameter
eventTypeBCSM
Description/Usage
Type

O_Busy / O_NoAnswer
M(R)

O(O)
legID

O(R)
miscCallInfo
O(O)
messageType

O(O)
Page 111 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
g. On receiving O_Busy / O_NoAnswer notification, the SCF does a Basic End by sending a
7.3.9 HLR-Determined CFNRc, CFU: PPAS Disconnects Call Upon Funds

Expiry
This call scenario describes a HLR-determined CFNRc or CFU call forwarding scenario for a PrePaid Mobile Subscriber (MS) where in the subscribers account balance falls below a threshold
value during the forwarded call conversation.
Assumptions:
When the Pre-Paid subscriber runs out of funds in the account, the PPAS requests
the GMSC to disconnect the call (after playing a Mid-Call Warning).
Page 112 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
gsmSSF
gsmSCF
TermAttempt_
Authorized
InitialDP
Continue
CFU Pending
Collected_Info
InitialDP
RequestReportBCSM
Continue
O_Answer
ApplyCharging
Warning
timer
expires
h
ApplyChargingReport
Tcp
expires
ApplyCharging
ApplyChargingReport
TC_END
Figure 34 HLR-Determined CFNRc, CFU: PPAS Disconnects Call Upon Funds Expiry
The steps a to g are the same as described in Section 7.3.6 Successful Call Forwarding
Unconditional.
Page 113 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
h. The Warning Timer expires in the PPAS. At this point the PPAS waits for the
ApplyChargingReport to come in before sending the next ApplyCharging.
i.

ApplyCharging
Parameter
Description/Usage
Type

following:
PPAS.
parameter).
side.
This
parameter
is
populated
with
the
CallingPartyNumber.
partyToCharge
O
R

j.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)

O(R)
Page 114 of 125
Prepay IN
l.
Version: 1.0
Date: 07/17/2004
7.3.10 CFNRy/CFNRc/CFB: PPAS Disconnects Call Upon Funds Expiry

This call scenario describes a CFNRy, VLR-determined CFNRc, or CFB call forwarding scenario
for a Pre-Paid Mobile Subscriber (MS) where in the subscribers account balance falls below a
threshold value during the forwarded call conversation.
Assumptions:
When the Pre-Paid subscriber runs out of funds in the account, the PPAS requests
the GMSC to disconnect the call (after playing a Mid-Call Warning).
Page 115 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004

GMSC/
gsmSSF
MT Call
gsmSCF
HLR
VLR
VMSC

SRI ack (T-CSI)
Term_Attempt
Authorized
b
c
InitialDP
RequestReportBCSM
Continue
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Start
T_TNRy
Page MS
Page MS
negative ack
Complete Call
negative response
CFNRc
detected
TC_END
Collected
_Info
InitialDP
RequestReportBCSM
Continue
O_
Answer
EventReportBCSM
(O_Answer)
ApplyCharging
ApplyChargingRepo
rt
ApplyCharging
k
Tcp
timer
expires
ApplyChargingReport
TC_END
Figure 35 CFNRy/CFNRc/CFB: PPAS Disconnects Call Upon Funds Expiry
Warning
timer
expires
Page 116 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
The steps a to i are the same as described in Section 7.3.1 Successful Call Forwarding On
No Reply.
j.
k.
The Warning Timer expires in the PPAS. At this point, PPAS waits for the
ApplyChargingReport to come from the MSC for the previous ApplyCharging. After receipt of
this ApplyChargingReport, the subsaequent ApplyCharging is sent.
ApplyCharging
Parameter
Description/Usage
Type

following:
PPAS.
parameter).
side.
This
parameter
is
populated
with
the
CallingPartyNumber.
partyToCharge
O
R

l.
ApplyChargingReport
Parameter
Description/Usage
Type
callResult

M(R)
M(O)
M(R)
M(R)
Page 117 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ApplyChargingReport
Parameter
Description/Usage
Type

O(R)
m. On receiving a disconnect notification, the SCF does a Basic End by sending a blank
7.3.11 Unsuccessful HLR-Determined CFNRc, CFU: Insufficient Balance For

Forwarded Call
This call scenario describes a HLR-determined CFNRc or CFU call forwarding scenario for a PrePaid Mobile Subscriber (MS) where in the subscriber does not have sufficient funds in the PrePaid account to cover the cost for the forwarded leg.
Assumptions:
PPAS denies the call to the Forwarded-To Party because of insufficient funds for the
forwarded leg.
gsmSSF
TermAttempt_
Authorized
gsmSCF
InitialDP
a
Continue
b
CFU Pending
Collected_Info
InitialDP
Release Call
d
Figure 36 Unsuccessful HLR-Determined CFNRc, CFU: Insufficient Balance For Forwarded Call
The steps a to c are the same as described in Section 7.3.6 Successful Call Forwarding
Unconditional.
d. When the PPAS determines that the subscribers account balance does not have sufficient
ReleaseCall
Parameter
Description/Usage
Type
Page 118 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
7.3.12 Unsuccessful CFNRy/CFNRc/CFB: Insufficient Balance For

Forwarded Call
This call scenario describes a CFNRy, or VLR-determined CFNRc, or CFB call forwarding
scenario for a Pre-Paid Mobile Subscriber (MS) where in the subscriber does not have sufficient
funds in the Pre-Paid account to cover the cost for the forwarded leg.
Assumptions:
Pre-Paid Charging (PPC) and the corresponding call forwarding feature (CFNRy, or
CFNRc, or CFB) is Active for the (Pre-Paid) Called MS.
PPAS denies the call to the Forwarded-To Party because of insufficient funds for the
call leg.
Page 119 of 125
Prepay IN
GMSC/
gsmSSF
gsmSCF
Version: 1.0
Date: 07/17/2004
HLR
VLR
VMSC
MT Call
SRI ack (T-CSI)
Term_Attempt
Authorized
InitialDP
RequestReportBCSM
b
Continue
c
Provide Roaming
Number (PRN)
PRN ack
IAM
SIFIC
Start
T_TNRy
Page MS
Page MS
negative ack
Complete Call
negative response
Collected
_Info
InitialDP
d
TC_END
e
ReleaseCall
f
Figure 37 Unsuccessful CFNRy/CFNRc/CFB: Insufficient Balance For Forwarded Call

The steps a to e are the same as described in Section 7.3.1 Successful Call Forwarding On
No Reply.
f.
When the PPAS determines that the subscribers account balance does not have sufficient
ReleaseCall
Parameter
Description/Usage
Type
releaseCause
message.
M(R)
Page 120 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
8 Error Scenarios
8.1 PPAS receives unsupported CAP message (operation)
This call scenario describes handling of receipt of unsupported CAP operation by PPAS:
1. PPAS receives a TCAP message with a component containing operation thats not supported
in the PrePay service call flow.
2. PPAS sends a TC-U-Reject to the sending entity.
8.2 PPAS receives unsupported Application Context (AC)

This call scenario describes handling of unsupported Application Context received from the
gsmSSF:
1. PPAS receives a TCAP message with the dialogue portion containing the name of
Application Context that is not supported by the PPAS.
2. PPAS sends a response with the dialogue portion of the message indicating Application
Context rejected.
8.3 PPAS receives mismatched Application Context (AC) and

CAP operation
This call scenario describes handling of receipt of a CAP operation that doesnt belong to the
Application Context its received with:
1. PPAS receives a mismatched pair of CAP operation and AC. For example, InitialDP
operation is NOT received with GSM-SCF-activation.
2. PPAS sends a TCAP Abort with the dialogue portion of the message indicating Application
Context rejected.
8.4 PPAS receives a n/w message in an invalid TCAP package

type
This call scenario describes handling of receipt of a CAP message in an invalid TCAP package
type:
1. PPAS receives a CAP message in an invalid TCAP package type. For e.g. An
EventReportBCSM received in a TCAP TC_BEGIN pacakge.
2. PPAS sends a Reject message in a TC_END package indicating the error encountered.
Page 121 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
8.5 PPAS detects a problem with the CAP message at the

component level
This call scenario describes the handling of receipt of a CAP message that fails to decode
correctly or has a mandatory parameter missing in it.
1. PPAS receives an EventReportBCSM without a EventType parameter in the message.
2. PPAS sends a Reject message in a TC_END package indicating the error encountered.
8.6 PPAS detects Dialogue Abort (either local or MSC/gsmSSF

initiated)
This call scenario describes handling of receipt of a TC-Abort primitive by the PrePay application:
1. PPAS receives a TC-Abort for a particular dialogue. This may be a local dialogue abort or
one initiated by the MSC/gsmSSF.
2. PPAS ends the call related to the aborted dialogue and clears its call record table.
8.7 PPAS detects local congestion or faces problem with the

processing of the call
This call scenario describes handling of congestion or other local error situations when PPAS is
unable to process the call properly.
1. On PPAS congestion, the PPAS sends a Call Gap message to the network indicating it stop
providing InitialDPs for a configured amount of time.
2. PPAS provides a very flexible way to handle these kinds of errors in that its behavior can be
configured to send either a ReleaseCall or a SystemFailure.
3. If theres any error detected by the PPAS (e.g. congestion, database error etc.) the default
behavior of PPAS will be to send ReleaseCall operation. This can be done to retain the
control of default Camel Call handling behavior with the PPAS (as opposed to SSF/MSC with
the help of information in subscribers O/T-CSI).
4. PPAS has a configuration control that allows the vendor to override the above behavior and
send a SystemFailure instead of a ReleaseCall. This configuration can be done on a per
error-type basis.
5. If PPAS is configured to send a SystemFailure rather than a ReleaseCall, default CAMELhandling
kicks
in.
Page 122 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
Appendix 1 Acronyms
ASN
BCSM
CFU
DFC
DP
EDP-N
EDP-R
ETC
FCC
GMSC
GSM
gsmSSF / SSF
IN
INAP/CS1
IP
ISUP
IVR
MO
MS
MSC
MT
PPAS
PPC
SMSC
SCF
SRF
TCAP
VSN
Abstract Syntax Notification

Basic Call State Model
Call Forward Unconditional
Disconnect Forward Connection operation
Detection Point
Event Detection Point Notification
Event Detection Point Request
Establish Temporary Connection operation
Full Call Control
Gateway MSC
Global System for Mobile Communications
GSM Service Switching Functionality
Intelligent Network
Intelligent Network Application Protocol / Capability Set 1
Intelligent Peripheral
ISDN User Part
Interactive Voice Response
Mobile Originated
Mobile Station
Mobile Switching Center
Mobile Terminated
Prepay Application Server
Pre-Paid Charging
Serving MSC
Service Control Functionality
Specialized Resource Functionality
Transaction Capabilities Application Part
Vendor Specific (implementation) Note
Page 123 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
9 Review Form
Page 124 of 125
Prepay IN
Version: 1.0
Date: 07/17/2004
10 Signoff Sheet
Signoff of the review means the reviewer has read and agrees with the design implementation.
Document Title and version:
Required Reviewer
Author:
Name
(Print Name and sign)
Comments
Product Architect
Engineering Lead
QA Representative
Product Representative
Deployment/Operations
Representative
<Vendor Name>
Page 125 of 125

PrePay in Network Call Flows CAMEL III Voice1 PDF

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

PrePay in Network Call Flows CAMEL III Voice1 PDF

Caricato da

Copyright:

Formati disponibili

PrePay IN Network Call Flows:

CAMEL III Voice Rating

Documentation Roles and Responsibilities

Lightbridge Confidential and Proprietary

NETWORK / PROTOCOL ARCHITECTURE.......................................................................... 8

PROTOCOL COMPLIANCE ..................................................................................................... 8

MOBILE ORIGINATED CALLS............................................................................................. 11

SUCCESSFUL MO CALL: CALLED PARTY DISCONNECTS ...................................................... 11

MOBILE TERMINATED CALLS............................................................................................ 28

SUCCESSFUL MT CALL: CALLED PARTY DISCONNECTS ...................................................... 28

FEATURE CALLS ................................................................................................................. 49

Lightbridge Confidential and Proprietary

ERROR SCENARIOS .......................................................................................................... 121

PPAS RECEIVES UNSUPPORTED CAP MESSAGE (OPERATION) .......................................... 121

REVIEW FORM.................................................................................................................... 124

Lightbridge Confidential and Proprietary

Lightbridge Confidential and Proprietary

Mobile Origination Call

Mobile Termination Call

Lightbridge Confidential and Proprietary

Requirements Not Covered

Lightbridge Confidential and Proprietary

3 Network / Protocol Architecture

This functional entity interfaces the MSC/GMSC to the gsmSCF.

3.1 Protocol Compliance

Lightbridge Confidential and Proprietary

3.2 Summary of Vendor Specific Changes

Lightbridge Confidential and Proprietary

If a parameter is of type R, it indicates that the parameter is required from the

Lightbridge Confidential and Proprietary

5 Mobile Originated Calls

Calling Subscriber is a valid Prepay subscriber (Pre-Paid charging is Active).

Figure 1 Successful MO Call: Called Party Disconencts

Lightbridge Confidential and Proprietary

Identifies the requested IN service. This parameter is used

Indicates the Called Party in the forward direction.

Indicates the Calling Party Number.

Indicates the type of calling party (e.g. operator,

This parameter is used to convey the geographical area

This parameter carries the dialed digits if the call has

This parameter indicates the type of the high layer

This parameter indicates the calling party number

Indicates the type of Bearer Capability connection to the

Identifies the armed BCSM DP event, resulting in the

This parameter indicates the last directory number the call

This parameter contains forwarding related information.

This parameter indicates which SRF resources are

Lightbridge Confidential and Proprietary

This parameter contains indicators, which are exchanged

IMSI of the mobile subscriber for which the service is

The state of the mobile subscriber for which the service is

This parameter indicates the whereabouts of the MS, and

Indicates the Basic Service Code.

This parameter gives the call reference number assigned

This parameter indicates the mscId assigned to the MSC.

This parameter indicates the gmscId assigned to the

This parameter contains the number used to identify the

This parameter contains the time that the gsmSSF was

This parameter indicated that a forward-to-number was

This parameter indicated the carrier information. It

This parameter is used to select a CUG for an outgoing

This parameter uniquely identifies a CUG within a