Prepaid International Roaming

1

2

1

Prepaid International Roaming

2

CDG Document 159

3

Version 0.4

4

2009-06-01

5

6
7
8
9
10
11
12
13

CDMA Development Group
575 Anton Boulevard, Suite 560
Costa Mesa, California 92626
PHONE +1 888 800-CDMA
+1 714 545-5211
FAX +1 714 545-4601



14
15

16
17
18
19
20
21
22
23
24
25
3

Notice
Each CDG member acknowledges that CDG does not review the
disclosures or contributions of any CDG member nor does CDG verify
the status of the ownership of any of the intellectual property rights
associated with any such disclosures or contributions. Accordingly, each
CDG member should consider all disclosures and contributions as being

made solely on an as-is basis. If any CDG member makes any use of
any disclosure or contribution, then such use is at such CDG member's
sole risk. Each CDG member agrees that CDG shall not be liable to any
person or entity (including any CDG member) arising out of any use of


Prepaid International Roaming

Contents

1

1
2

2

any disclosure or contribution, including any liability arising out of
infringement of intellectual property rights.

Ref Doc 159, Ver 0.4

2009-06-01

ii


1

1

2

Ref Doc 159, Ver 0.4

2009-06-01

iii


Prepaid International Roaming

Contents

1

1

1 Executive Summary

Prepaid International Roaming represents a largely untapped revenue source for
3CDMA operators today.

2

While various technical and commercial issues exist, the recommended solution can
5allow for a “seamless” roaming experience for prepaid subscribers. The solution is
6already the most commonly deployed approach for operators’ existing domestic
7prepaid offerings.
4

This document introduces the recommended (“WIN-based”) approach, and provides
9descriptions and possible solutions for the most significant anticipated issues.
8

Operators and other involved parties are encouraged to review and where appropriate
11implement the recommendations contained herein.
10

2

Ref Doc 159, Ver 0.4

2009-06-01

iv


1

Contents

1

2

Prepaid International Roaming................................................................................................. i

3

CDG Document 159................................................................................................................... i

4

Version 0.4................................................................................................................................. i

5

2009-06-01.................................................................................................................................. i

1 Executive Summary.............................................................................................................. iv

6

Contents.................................................................................................................................... v

7

1 Introduction............................................................................................................................. 8

8

2 Solution Options..................................................................................................................... 9

9
10

2.1 Handset Based............................................................................................................... 9

11

2.2 Service Node.................................................................................................................. 9

12

2.3 ISUP Triggers with Service Node.................................................................................10

13

2.4 ANSI-41/WIN Triggers with Service Node....................................................................10

14

2.5 Service Node with Call-back......................................................................................... 11

15

2.6 IS-826........................................................................................................................... 11

3 Introduction to IS-826........................................................................................................... 12

16
17

3.1 WIN Overview............................................................................................................... 12

18

3.2 Subscriber Registration................................................................................................. 12

19

3.3 Prepaid Origination....................................................................................................... 14

20

3.4 Originating Call with Pre- and Post-Call Announcements.............................................16

21

3.5 Commanded Disconnect...............................................................................................19

22

3.6 Terminating Call............................................................................................................ 20
4 International Implementation of IS-826...............................................................................23

23
24

4.1 Dialplan Support........................................................................................................... 23

25

4.2 Terminating Call Charges............................................................................................. 24

26

4.2.1 Serving Side Triggers Only............................................................................24

27

4.2.2 Service Node for Terminations.......................................................................25

2

Ref Doc 159, Ver 0.4

2009-06-01

v


Prepaid International Roaming

Contents

1

1

4.2.3 Custom HLR Handling....................................................................................25

2

4.3 Announcements............................................................................................................ 26

3

4.3.1 Serving System IP.......................................................................................... 26

4

4.3.2 Home System IP............................................................................................27

5

4.3.3 Serving MSC Tones Only...............................................................................27

6

4.4 Account Replenishment While Roaming.......................................................................28

7

4.4.1 Obtaining Recharge Information....................................................................29

8

4.4.2 Connection to Prepaid System.......................................................................31

9

4.4.3 Alternative Approaches..................................................................................33

10

4.5 Signaling Link Occupancy and Message Length..........................................................34

11

4.6 RSP support................................................................................................................. 35

12

4.6.1 Basic Message Transport...............................................................................36

13

4.6.2 Analysis and Modification of Embedded Address..........................................36

14

4.6.3 Identification of True Serving Network............................................................36

15

4.6.4 Message/Parameter Modification...................................................................37

16

4.6.5 No Trigger Support......................................................................................... 38

17

4.6.6 Prepaid System Interconnectivity...................................................................38

18

4.7 Serving Network Trigger Support..................................................................................38

19

4.8 Inter-Operator Billing..................................................................................................... 38

20

4.9 Failure Scenarios.......................................................................................................... 39

21

4.9.1 Billing Integrity................................................................................................ 39

22

4.9.2 Sanity Checks................................................................................................ 40

23

4.9.3 Recovery Procedures.....................................................................................40

24

4.10 SMS............................................................................................................................ 40

25

4.11 Prepaid Data............................................................................................................... 41

26

4.12 Time Zones................................................................................................................. 41

27

4.13 Emergency Calls......................................................................................................... 42

28

4.14 Subscriber Provisioning.............................................................................................. 42

29

4.15 Timer Expiry................................................................................................................ 43

5 Commercial and Other Issues.............................................................................................44

30
31

2

5.1 Roaming Agreement..................................................................................................... 44

Ref Doc 159, Ver 0.4

2009-06-01

vi

Prepaid International Roaming

Contents

1

1
2

5.2 Recharge Agreements.................................................................................................. 44

6 Operator Recommendations...............................................................................................46
7 Terminology.......................................................................................................................... 47

3
4

8 References............................................................................................................................ 50
9 Appendix .............................................................................................................................. 51

5
6

9.1 Signaling Link Occupancy Calculations........................................................................51

7
8

Figures

9

Figure 4-1 - Prepaid Registration............................................................................................13

10

Figure 4-2 - WIN Trigger Parameter Structure.......................................................................14

11
12

Figure 4-3 - Prepaid Origination.............................................................................................. 15
Figure 4-4 - Prepaid Origination with Pre- and Post-Call Announcements.........................17

13
14

Figure 4-5 - Application Commanded Disconnect.................................................................19
Figure 4-6 - Prepaid Termination............................................................................................. 21

15

Figure 5-7 - Possible Card-Sharing Process..........................................................................30

16
17

Tables

18

Table 4-1 - Typical Subscriber Profile Triggers.....................................................................14

19

Table 5-2 - Additional Signaling Load for Prepaid.................................................................35

20

21

Revision History

22

Date

2

Version

Description

9 October 2007

0.1

Initial Release for Comment

4 February 2008

0.2

Update following team discussion

4 March 2008

0.3

Minor update following conference call

1 June 2009

0.4

Minor update for solution availability

Ref Doc 159, Ver 0.4

2009-06-01

vii


1

1 Introduction

1

Prepaid subscribers represent a significant proportion of total cellular subscribers:
3across all technologies, prepaid subscriptions are estimated at approximately 70%
1
4of total cellular subscriptions .
2

To date, CDMA prepaid subscribers have had limited options for international
roaming. This document aims to describe implementation options and
7recommendations for the CDMA operator community.
5
6

The document recommends use of the [IS-826] Industry Standard. IS-826 describes
9various capabilities that can be used to create a prepaid service. The intention of
10this document is to assist in ensuring that these capabilities can be used to extend
11an operator’s prepaid service to its roaming subscribers – it does not attempt to
12describe or mandate a complete prepaid service.
8

2

1 Source: StrategyAnalytics Worldwide Cellular User Forecasts, 2007-2012

Ref Doc 159, Ver 0.4

3

2009-06-01

8


Prepaid International Roaming

Terminology

1

1

2 Solution Options

This section briefly describes various solution options that were considered by the
3CDMA Development Group International Roaming Team Voice & SMS Working
4Group (CDG IRT VSWG) for prepaid international roaming. Through various team
2
5meetings in 2007 , a clear preference was expressed for the IS-826-based
6approach.
2

7

2.1 Handset Based

In this approach, an application resident in the handset (or R-UIM) maintains the
9subscriber balance, without reference to a central network-based system.
8

This approach is not known to have been implemented in any CDMA systems (i.e.

11even for own-network prepaid service) to date. It is potentially subject to fraud as the
12prepaid functionality resides in equipment under the control of the subscriber
13(although it is designed to be tamper-proof). Careful planning would be required to
14ensure the application was able to determine its own location and interpret/charge
15dialed digit strings accordingly.
10

2.2 Service Node

16

The Service Node (SN) approach is common for initial deployments of prepaid
systems, and/or in smaller networks. Using vendor-dependent subscriber
19provisioning and MSC datafill, calls from prepaid subscribers are trunked through
20the SN before connecting to their destination. To distinguish it from the method
21described in the following sections, this approach is also referred to in this document
22as “pure-SN”.
17

18

Since it is present in the ISUP call path, the SN can determine call answer and end
times easily, and debit the subscriber balance (identified via Calling Line Identity
25-CLI) accordingly. It can also disconnect the call if the subscriber balance is
26exhausted.
23

24

27

This approach does not translate well to the international roaming case. As calls
must be trunked through the SN, a call from a roaming subscriber to a local number

28

2

2 See />
Ref Doc 159, Ver 0.4

3

2009-06-01

9


Prepaid International Roaming

Terminology

1

in the serving country would involve two international call legs. The CLI may also be
2unreliable in this case, making identification of the correct subscriber difficult.
1

The subscriber provisioning sent from the home network HLR may not be
4recognized in the serving network. Even if it is recognized, defining the necessary

5datafill to route these subscribers differently may be more burdensome than the
6serving operator is willing to accept for a roaming partner.
3

The SN approach may also be more challenging to implement for terminating call
8charges, which are necessary for international call delivery while roaming.

7

2.3 ISUP Triggers with Service Node

9

A refinement of the pure SN approach to reduce trunking costs, in this method the
SN is in-line with the ISUP signaling, but not the actual traffic circuits, which are
12routed by the MSC on a “loop-around” trunk to simulate the pure SN behavior.
10
11

Although the inefficient trunking issue for international roaming may be removed
14(assuming it is possible to establish this ISUP-signaling-only arrangement
15internationally), other limitations of the pure-SN approach remain. The MSC
16configuration is even more extensive in this case as the loop-around trunks must be
17defined.
13

2.4 ANSI-41/WIN Triggers with Service Node

18

This approach uses ANSI-41 / WIN Phase 1 triggers (i.e. pre-IS-826 capabilities) to
20steer a prepaid subscriber’s calls through an SN. The advantage over other SN
21solutions is that the subscriber provisioning and MSC handling can be largely
22standards-compliant.
19

An “All-Calls” trigger can be used to invoke the SCP at subscriber origination. The
24SCP can return a TLDN obtained from the SN to allow call routing as well as
25potentially subscriber identification. For terminating calls, custom HLR handling
26could prefix a “handoff code” to the TLDN to ensure routing (from the home network)
27through the SN before call delivery.
23

While this method has definite interoperability advantages over other SN-based
approaches, it retains the inefficient call routing path, which may be a significant
30problem for international roaming deployments. Some RSPs may already offer this
31kind of service.

28
29

2

Ref Doc 159, Ver 0.4

2009-06-01

10

Prepaid International Roaming

Terminology

1

2.5 Service Node with Call-back

1

An even simpler approach from an interoperability perspective is to disallow all
originating calls from the subscriber. To make a call the subscriber instead sends an
4SMS to a specific address in the home network and provides the desired called
5party digits. The Service Node in the home network initiates a call-back to the
6subscriber and a simultaneous outcall to the desired called party.
2

3

7

2.6 IS-826

[IS-826] has been selected as the preferred method for deploying CDMA prepaid
international roaming. Unlike the other methods discussed above, it allows for a
10standards-based, trunk-efficient international service.
8
9

Of the operators who responded to a 2007 survey3, IS-826 was the most commonly

12deployed approach for existing prepaid offerings.
11

2

3 See />
Ref Doc 159, Ver 0.4

3

2009-06-01

11


Prepaid International Roaming

Terminology

1

1

3 Introduction to IS-826

IS-826, “TIA/EIA-41-D Pre-Paid Charging”, is a standard for prepaid services using
3the Wireless Intelligent Network (WIN) framework. WIN allows service logic to run
4from a location remote from the switching equipment, using signaling messages to
5control the call. This characteristic makes it ideal for use in the international roaming
6scenario, where the home (service logic/call control) and serving (switching)

7equipment) are widely separated.
2

The following subsections present a summary of WIN operations, and some
9simplified callflows for key scenarios. For further details, refer to the standard
10directly.
8

3.1 WIN Overview

11

This is an extremely simplified view of WIN. For a full treatment, please see [IS13771].
12

WIN operates around the concept of “triggers”. Triggers may be “armed”, or
15provided to the serving switch in the subscriber profile from the HLR, or may be
16statically defined in the serving system. Triggers may also be “dynamically armed”
17(sent from the HLR during an actual call). Each trigger is associated with a particular
18“detection point” (DP) in the call model defined in the switch. When a detection point
19(e.g. “the call has been answered by the other party”) is encountered, and the
20subscriber has a trigger armed for that DP, the trigger “fires”, and a message is sent
21from the switch to a service logic instance at the Service Control Point (SCP),
22typically a separate network element in the home network. The message advises
23the SCP that the particular event has occurred. Depending on the trigger, the switch
24may wait for further instructions in the response to the trigger message.
14

An important addition for IS-826 is the ability for the SCP to initiate a “call control
directive” to the switch, rather than merely responding to triggers. A common usage

27of this message in a prepaid scenario is to disconnect the subscriber’s call when the
28credit (monitored by the SCP) reaches zero.
25
26

3.2 Subscriber Registration

29

(IS-826 Reference: Ch 4 §8.X.1)

30

2

Ref Doc 159, Ver 0.4

2009-06-01

12


Prepaid International Roaming

Terminology

1

The registration steps are shown in Figure 4 -1 below:

1

2

Figure 4-1 - Prepaid Registration

3

4

Steps are as follows:
a)

5
6
7
8

b)

9
10
11
12
13
14
15
16

2

Resulting from a MS registration (not shown), the MSC/VLR initiates a
RegistrationNotification to the HLR. This is as per normal (postpaid)
operation, however the serving system reports on its WIN capabilities with
various parameters in the REGNOT.
The HLR returns the subscriber profile information in the Return Result. The
key addition for prepaid is the presence of specific triggers in the
TriggerAddressList parameter. This parameter lists the triggers which are
armed for the subscriber, as well as the address to which the trigger
messages should be sent (i.e. the SCP).
The exact set of triggers armed will depend on operator configuration, but a
typical set (to allow charging for both originating and terminating calls) is as
follows:
Trigger

Event

OAA

Origination_Attempt_Authorized – a valid mobile is
trying to make a call

CgRAA

Calling_Routing_Address_Available - the routing
address and call type have been determined for an
outgoing call

O_ANS

O_Answer – a call originated by the triggering
subscriber has been answered

O_DISC

O_Disconnect - a call originated by the triggering
subscriber has disconnected (e.g. by either party
hanging up).

T_ANS

T_Answer – a call to the triggering subscriber has been
answered

T_DISC

T_Disconnect – a call to the triggering subscriber has
disconnected

Ref Doc 159, Ver 0.4

2009-06-01

13


Prepaid International Roaming

Terminology

1

1

2

Table 4-1 - Typical Subscriber Profile Triggers

A complex parameter structure is used to carry the triggers and their associated
address, as shown in Figure 4 -2:

3

4

5

Figure 4-2 - WIN Trigger Parameter Structure

The actual triggers are contained in the WIN_TriggerList parameter. Multiple
7TriggerLists can be present, each containing a different set of triggers with an
8associated SCP.
6

3.3 Prepaid Origination

9

(IS-826 Reference Ch 4 §8.X.4)

10

The steps for a prepaid subscriber origination are shown in Figure 4 -3 below. Note
that this is a “simple” case where there are no pre- or post-call tones or
13announcements played.
11
12

2

Ref Doc 159, Ver 0.4

2009-06-01

14


Prepaid International Roaming

Terminology

1

1

Figure 4-3 - Prepaid Origination

2

Steps are as follows:

3
4

a)

The prepaid subscriber originates a call

b)

The MSC detects the OAA trigger, and notifies the SCP

c)

The SCP confirms that this is a valid prepaid subscriber, with a non-zero
balance, and instructs the MSC to continue processing the call.

5
6
7
8
9
10
11
12

d)

13
14

15
16

Note: Steps b & c are designed as a “quick check” that the call is valid4,
before continuing to analyze the dialed digits at the serving MSC, and rate
them at the SCP. Some operators have abandoned this step (by not
provisioning the subscriber with the OAA trigger) to minimize signaling load.
The serving MSC analyzes the dialed digits and prepares to route the call.
The CgRAA trigger fires and an AnalyzedInformation message is sent to the
SCP. The message contains the dialed digits, the digits to which the MSC
will route the call (which may not be the same), and the time stamp at the
MSC.

4

In IS-826, the check is described as the SCP checking that “the subscriber has
PrepPaid Charging active and the subscriber’s account balance is above the
4threshold level.”
2

3

5

Ref Doc 159, Ver 0.4

6

2009-06-01

15


Prepaid International Roaming

Terminology

1

e)

1
2
3
4
5

f)

The call is set up to the destination

g)

The call is answered

h)

The MSC sends an answer indication to the SCP. The SCP starts charging
for the call. Note that this message has no response.

6
7

8
9

i)

The call is cut through and both parties are in conversation

j)

Some time later, the originating (prepaid) party ends the call (this makes the
scenario simpler as there is no possibility to play a post-call announcement
(e.g. “this call cost $5, you have $15 remaining”) to the prepaid subscriber.

10
11
12
13
14

k)

15
16
17
18
19
20

The MSC advises the SCP that the call has ended using the
ODISCONNECT message. Note that even if the other party had ended the
call, the same message type would be used (and not TDISCONNECT). The
fact that the originating party was the prepaid subscriber to whom the
triggers applied determines the use of the OANSWER and ODISCONNECT
messages here. The fact that it was the calling party who disconnected is
included within the message.

l)

The SCP stops charging, and acknowledges the MSC’s message.

m)

The serving MSC releases the external call leg.

21
22

The SCP determines that the subscriber has sufficient credit to allow this call
and that no pre-call announcement is required. Unlike the previous check,
this time the specific destination is used to determine the rate for the call.
The Return Result message instructs the MSC to continue processing the
call

3.4 Originating Call with Pre- and Post-Call Announcements

23

24

(IS-826 Reference Ch4 §8.X.3 & 8.X.5)

In this scenario the basic elements of the previous call flow are still present, with the
26addition of announcements made before and after the call. The announcements are
27played from an Intelligent Peripheral (IP) under the control of the SCP. The MSC is
28directed to set up a call leg to the IP via the ConnectResource message.
25

From a standards perspective the location of the IP is immaterial – provided it can
30be accessed from the MSC, and controlled by the SCP, it could be in the home,
31serving or theoretically even another network. In practice, the location of the IP (if
32used at all) will be an important issue for international roaming deployments.

29

The call flow is shown in Figure 4 -4:

33

2

Ref Doc 159, Ver 0.4

2009-06-01

16

Prepaid International Roaming

Terminology

1

1
2

2

Figure 4-4 - Prepaid Origination with Pre- and Post-Call Announcements

Ref Doc 159, Ver 0.4

2009-06-01

17


Prepaid International Roaming

Terminology

1

Steps are as follows:

1
2

a-d)

As per the previous scenario.

e)

The SCP determines that a pre-call announcement is required (e.g. “Your
balance will allow you to speak for seven minutes”). It sends a
SeizeResource to the IP requesting the resource.

3
4
5
6
7
8
9
10
11
12

f)

The IP returns a TLDN to be used to connect a voice call to the IP.

g)

The SCP returns the TLDN to the MSC in a ConnectResource.

h)

The MSC sets up the call leg to the IP

i)

The IP sends an InstructionRequest to the SCP to inform it that it has
received the incoming call, and is now ready to play announcements. There
are no parameters inside the INSTREQ.

13
14

15
16
17
18

j)

19
20

The IP plays the requested announcement(s) to the user.

l)

The IP informs the SCP that it has finished playing the announcement(s).

m)

The SCP returns an anlyzd to the MSC. Equivalent to step e in the previous
scenario.

n)

The MSC releases the call leg to the IP

o)

The SCP concludes the SCP-IP conversation.

p-s)

Call set-up, answer and conversation. Equivalent to steps f-i in previous
scenario.

23
24
25
26
27

28

t)

The called party disconnects the call

u)

The MSC informs the SCP via the ODisconnect message. An indication is
provided of which party ended the call.

29

30
31
32

v-cc)

33
34
35

dd)

36

2

The SCP sends an SRFDirective to the IP including the AnnouncementList
parameter for the announcements that are to be played.

k)

21
22

Note: Throughout the interaction between the SCP and the IP for the
announcement, there is typically no subscriber-identifying parameter (e.g.
MSID) passed in any of the messages. Instead, the TCAP Transaction ID is
maintained throughout the interaction, and is used as a reference by the
SCP to ensure the correct subscriber account information is used to
generate announcements. This also implies that there is no dependence on
maintenance of correct CLI across the MSC – IP leg.

The SCP determines that a post-call announcement (e.g. “that call cost four
dollars. Account balance now three dollars”) is required, and communicates
with the IP and MSC to set up the playing of the announcement. A repeat of
steps e-l earlier in this scenario, with a different AnnouncementList.
The SCP sends an odisconnect to the MSC.

Ref Doc 159, Ver 0.4

2009-06-01

18


Prepaid International Roaming

Terminology

1

ee)

The MSC releases the call leg to the IP.

ff)

The SCP concludes the IP conversation.

gg)

The serving MSC releases the MS.

1
2

3

4

3.5 Commanded Disconnect
(IS-826 Reference Ch4 §8.X.8)

5

In this scenario the subscriber’s call is terminated by the prepaid application –
typically because of balance exhaustion. The call flow is shown in Figure 4 -5:

6
7

8
9

Figure 4-5 - Application Commanded Disconnect

Steps are as follows:

10

a)

The parties are in conversation following a prepaid origination.

b)

The SCP determines that the call shall be disconnected, It sends a
CallControlDirective to the MSC, informing it of the necessary action, and
providing a disconnect tone/announcement to be played to the prepaid
subscriber. The same mechanism, without the “disconnect” ActionCode, is
used to play low-balance warning tones to the subscriber during the call.

11
12

13
14
15
16
17

c)

18

19

d)

The MSC clears the call leg to the other party.

e)

The MSC sends a ccdir to the SCP to inform it that the requested actions
were carried out.

20

21
22

2

The MSC plays the requested tone/announcement to the subscriber (note
that this is a MSC-based announcement, rather than one located on an IP as
in other scenarios).

Ref Doc 159, Ver 0.4

2009-06-01

19


Prepaid International Roaming

Terminology

1

f)

1
2
3
4

The MSC detects the call disconnection, and informs the SCP via the
ODISCONNECT message. The ReleaseCause parameter indicates
“commanded disconnect”.

g)

The SCP acknowledges with an odisconnect.

h)

The MSC releases the prepaid subscriber.

5

3.6 Terminating Call

6

7

(IS-826 Reference: Ch4 §8.X.22)

In this scenario, the call is initiated by a non-prepaid party, terminating to the
prepaid subscriber. (Of course a prepaid-to-prepaid scenario is possible too – in this
10case both originating and terminating call flows are effectively running
11independently). This scenario will be important for all operators offering prepaid
12roaming, even those who normally use a Calling Party Pays (CPP) model. For
13further discussion on this issue, see §4.2.
8
9

Note that the call flow does not merely involve interactions between the SCP and
the serving MSC – the originating/in-call MSC is involved as well, and takes several
16actions before it is aware of the location of the prepaid subscriber. The call flow is
17shown in Figure 4 -6:
14

15

2

Ref Doc 159, Ver 0.4

2009-06-01

20

Prepaid International Roaming

Terminology

1

1

Figure 4-6 - Prepaid Termination

2

Steps are as follows:

3
4

a)

5

b)

6
7
8
9
10

c)

11
12
13
14
15

d)

16
17

2

The call origination is received by the in-call MSC (termed Originating MSC
in the standard).
The MSC determines that the call is for a mobile subscriber, and sends a
LocationRequest to the mobile’s HLR. New for IS-826, the MSC includes an
indication of which triggers it supports, and the fact that the
Mobile_Termination trigger has fired. This is a statically defined trigger
based on the dialed digits received.
Since the dialed subscriber is prepaid, the HLR proceeds differently than for
a normal call. It returns a TriggerAddressList in the locreq, arming the
Initial_Termination, Location and Called_Routing_Address_Available
triggers. Since the subscriber profile does not reside at the in-call MSC,
these triggers are armed dynamically instead.
The Initial_Termination trigger fires and the MSC sends AnalyzedInformation
to the SCP.

Ref Doc 159, Ver 0.4

2009-06-01

21


Prepaid International Roaming

Terminology

1

e)

1
2
3
4

f)

5
6
7

g)

8
9
10

j)

Now that the MSC has determined where to route the call, the
Called_Routing_Address_Available trigger fires, and the MSC sends another
ANLYZD to the SCP. The message contains the destination to which the
MSC will route the call (derived from the TLDN).

13
14
15
16

k)

18

The SCP returns anlyzd to allow the call to continue. It will use the received
destination digits to determine the correct rate for the call.

l-m)

Call delivery, paging and mobile answer proceed as per a normal call

n)

The serving MSC sends a TANSWER to the SCP – the SCP starts debiting
the subscriber’s balance.

19

20

21

o)

The call is cut-through and the parties are in conversation.

p)

Some time later, the called (prepaid) subscriber ends the call. A post-call
announcement is therefore not possible.

q-r)

The MSC sends TDISCONNECT to the SCP to stop debiting, and the
message is acknowledged.

23
24
25
26
27

The HLR sees that the Location trigger fired (so it doesn’t go into an infinite
loop) and sends a ROUTREQ to the serving VLR/MSC as per a normal
termination.
A TLDN is assigned by the serving system, and returned via the HLR to the
in-call MSC, as per a normal termination.

12

22

Now the Location trigger fires and the MSC sends a second
LocationRequest to the HLR. The LOCREQ contains an indication of the
trigger encountered,

h-i)

11

17

The SCP determines that this is a valid subscriber with an account balance
above a pre-defined threshold, and allows the call to continue by returning
analyzd. This check is equivalent to the one performed via the
Origination_Attempt_Authorized trigger in the mobile origination scenario.

s)

The calling party is disconnected.

28

29

2

Ref Doc 159, Ver 0.4

2009-06-01

22


Prepaid International Roaming

Terminology

1

1

4 International Implementation of IS-826

Although IS-826 appears to offer the best solution for an international deployment,
3there are several areas which will require careful examination and co-operation to
4ensure a successful service. Specific issues are described in the following
5subsections.
2

4.1 Dialplan Support

6

Unlike in a postpaid scenario, the SCP in the home network is responsible for rating
the prepaid call. This means the SCP needs to not only know which operator is
9serving the subscriber in order to apply the correct rate (see § 4.6.3), but also to
10understand the dialplan used by the subscriber in the serving network in order to

11correctly identify the type of call (e.g. local, long-distance, freephone) that was
12dialed.
7

8

Operators today typically provide information on their dialplan as part of the
Technical Data Sheet (TDS) exchange. Today this information can be used by the
15home operator to reconcile roamer charges with dialed calls, but this information
16may not always be examined in detail. For a prepaid call, this information must be
17used to replicate a detailed rating table in the SCP for each serving operator.
13
14

Home operators may have a simplified rating plan (e.g. divide the globe into a few
19“zones” with common retail call charges anywhere within a zone), but the dialing
20patterns from different countries within a rate zone may still be different, and
21necessitate explicit entry into the SCP datafill. Given the likelihood of clashes (e.g.
2210-digit local dialing possible in both USA and Mexico), it is assumed that the SCP
23will require the capability to index into different dialing plans based on subscriber
24location (MSCID).
18

A potential simplification to the required datafill may be for the RSP (if present) to
“normalize” dialed digits to a standard E.164 format. While distinction between
27different rate zones will still be necessary at the SCP, a common format for dialed
28digit strings can be used. Further investigation into this approach would be
29necessary to determine other impacts, e.g. reconciliation difficulty if the dialed digit
30string at the SCP is different to that received via CIBER for wholesale settlement.
25

26

2

Ref Doc 159, Ver 0.4

2009-06-01

23


Prepaid International Roaming

Terminology

1

4.2 Terminating Call Charges

1

As shown in §3.6, IS-826 defines a mechanism to charge a prepaid subscriber for
receiving a call. For operators who normally charge subscribers for terminating calls,
4this mechanism will already be defined in their prepaid systems and network
5elements, along with the necessary subscriber triggers. Provided the serving
6network also supports the terminating triggers (and even in some cases if it doesn’t 7see §4.7), this mechanism adapts well to the international roaming case, and the
8subscriber can be charged for the international call delivery leg in addition to any
9serving network airtime charges.
2

3

However, those operators who normally use the Calling Party Pays (CPP) model
may not have their networks designed to use any of the terminating prepaid call
12model: no terminating triggers may be assigned in the subscriber profile, or be
13returned from the HLR in the initial LocationRequest. While this is no problem for
14on-network operation, it is an issue for international roaming, where even CPP
15operators still charge the roaming subscriber to receive the call. Even if the serving
16network does not charge airtime for a roamer-terminated call, the international call
17delivery leg is still charged to the roaming subscriber.
10
11

To allow charging for outbound roamer-terminated calls, the CPP operator could
enable the full terminating call scenario. However, this would impact all prepaid20terminated calls for the operator’s subscribers, regardless of their location. This
21would increase signaling load on both the HLR and SCP by a potentially significant
22amount, and is assumed not to be an acceptable solution for CPP operators.
18
19

The following subsections describe three potential solutions for enabling terminating
24call charges.
23

25
26
27
28

Note: Operators who normally charge for (own-network) terminations may

have also implemented a mechanism (e.g. via SMS) to advise a prepaid
subscriber that they have missed a call due to insufficient balance. The
proposals below do not address such a mechanism for a CPP operator.

4.2.1 Serving Side Triggers Only

29

This is the least preferred option. In this approach, the HLR does not treat the
subscriber as if they had were prepaid (for terminating calls). The RSP (required to
32be present for this option) inserts the T_Answer and T_Disconnect triggers into the
33subscriber profile at registration time. Call delivery proceeds as per a normal
34(postpaid call) until the call is answered, at which point the T_Answer trigger fires
35and the prepaid terminating call flow picks up (i.e. at step n of Figure 4 -6). This
36approach has the advantage of simplicity for the home operator with no modification
37required. There is some impact on the RSP, but some subscriber profile
38modification is within existing RSP capabilities.
30
31

2

Ref Doc 159, Ver 0.4

2009-06-01

24


Prepaid International Roaming

Terminology

1

The (significant) drawback to this approach is that the SCP is not involved to
2validate the subscriber’s balance until after the call has been answered. TANSWER
3is a unidirectional message – the MSC does not wait for a reply from the SCP
4before connecting the call. If the subscriber’s balance is such that this call should
5not have been allowed, the SCP must immediately send a CCDIR to disconnect the
6call. The delays involved in this process represent a revenue leakage for the home
7operator (the serving operator will charge the home for the brief call), and an
8annoyance for the subscriber who will receive and answer a call only for it to be
9disconnected a few seconds later.
1

4.2.2 Service Node for Terminations

10

In this approach, the international call delivery legs are routed through a Service
12Node (SN) in the home network. This is analogous to a pre-WIN approach to
13prepaid, where the SN sits in-line in the call, and can easily disallow or disconnect
14the call as appropriate, was well as communicate with whatever platform maintains
15the subscriber balance.
11

A SN-based approach is inefficient for originating calls in an international roaming
scenario, as a local call must be tromboned through the home country to invoke the
18prepaid service. When used solely for terminations however, this inefficiency is

19considerably less as the call must anyway traverse the home network (excluding a
20DRRR scenario).
16

17

All international TLDNs could be routed through the SN, which would then need to
22determine (perhaps via communication with the SCP) whether the called subscriber
23was prepaid or not (appropriate ISUP parameter population – e.g. Redirecting
24Number - would be required to ensure the called subscriber could be identified). No
25terminating triggers would be required in the subscriber profile at the serving
26network.
21

This option involves the introduction of a new network element into the home
28operator network, of a type which an operator offering IS-826-based prepaid service
29may have worked hard to remove/avoid. For large operators, the internal trunking
30costs from the in-call MSC to the SN may be significant.
27

4.2.3 Custom HLR Handling

31

This is the preferred option. If the HLR were pre-provisioned with a list of which
MSCIDs required terminating charging, it could include the subscriber profile
34terminating triggers at registration time for these MSCs only, as well as invoke the
35prepaid termination model at call time only for subscribers registered in these
36MSCs.
32

33

2

Ref Doc 159, Ver 0.4

2009-06-01

25