Prepaid International Roaming

8/3/2019 Prepaid International Roaming

1/52

Prepaid International Roaming

CDG Document 159

Version 0.4

2009-06-01

CDMA Development Group575 Anton Boulevard, Suite 560Costa Mesa, California 92626PHONE +1 888 800-CDMA

+1 714 545-5211FAX +1 714 545-4601

http://[email protected]

Notice

Each CDG member acknowledges that CDG does not review thedisclosures or contributions of any CDG member nor does CDG verifythe status of the ownership of any of the intellectual property rightsassociated with any such disclosures or contributions. Accordingly, eachCDG member should consider all disclosures and contributions as beingmade solely on an as-is basis. If any CDG member makes any use ofany disclosure or contribution, then such use is at such CDG member'ssole risk. Each CDG member agrees that CDG shall not be liable to anyperson or entity (including any CDG member) arising out of any use of

1

2

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

3
http://www.cdg.org/mailto:[email protected]://www.cdg.org/mailto:[email protected]


2/52

Prepaid International Roaming Contents

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

Ref Doc 159, Ver 0.4 2009-06-01 ii

1

1

2

2


3/52

Ref Doc 159, Ver 0.4 2009-06-01 iii

1

1

2


4/52


1 Executive Summary

Prepaid International Roaming represents a largely untapped revenue source for

CDMA operators today.

While various technical and commercial issues exist, the recommended solution can

allow for a seamless roaming experience for prepaid subscribers. The solution is

already the most commonly deployed approach for operators existing domestic

prepaid offerings.

This document introduces the recommended (WIN-based) approach, and provides

descriptions and possible solutions for the most significant anticipated issues.

Operators and other involved parties are encouraged to review and where appropriate

implement the recommendations contained herein.

Ref Doc 159, Ver 0.4 2009-06-01 iv

1

1

2

3

4

5

6

7

8

9

10

11

2


5/52

Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.6 Terminating Call............................................................................................................20

4 International Implementation of IS-826 ........................................................................... ....23

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

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

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

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

Ref Doc 159, Ver 0.4 2009-06-01 v

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

2


6/52


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

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

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

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

4.3.3 Serving MSC Tones Only...............................................................................28

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

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

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

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

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

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

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

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

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

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

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

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

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

4.8 Inter-Operator Billing.....................................................................................................394.9 Failure Scenarios..........................................................................................................39

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

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

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

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

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

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

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

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

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

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

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

Ref Doc 159, Ver 0.4 2009-06-01 vi

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

2


7/52


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

6 Operator Recommendations ........................................................................................... ....46

7 Terminology ..........................................................................................................................47

8 References ............................................................................................................................50

9 Appendix ............................................................................................................................ ..51

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

Figures

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

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

Figure 4-3 - Prepaid Origination..............................................................................................15

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

Figure 4-5 - Application Commanded Disconnect.................................................................19

Figure 4-6 - Prepaid Termination.............................................................................................21

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

Tables

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

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

Revision History

Date 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

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

2


8/52

1 Introduction

Prepaid subscribers represent a significant proportion of total cellular subscribers:

across all technologies, prepaid subscriptions are estimated at approximately 70%

of total cellular subscriptions1.

To date, CDMA prepaid subscribers have had limited options for international

roaming. This document aims to describe implementation options and

recommendations for the CDMA operator community.

The document recommends use of the [IS-826] Industry Standard. IS-826 describes

various capabilities that can be used to create a prepaid service. The intention of

this document is to assist in ensuring that these capabilities can be used to extend

an operators prepaid service to its roaming subscribers it does not attempt to

describe or mandate a complete prepaid service.

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

Ref Doc 159, Ver 0.4 2009-06-01 8

1

1

2

3

4

5

6

7

8

9

10

11

12

2

3


9/52

Prepaid International Roaming Erreur ! Utilisez l'onglet Accueilpour appliquer Heading 1 au texte

que vous souhaitez faire apparatreici.

2 Solution Options

This section briefly describes various solution options that were considered by the

CDMA Development Group International Roaming Team Voice & SMS Working

Group (CDG IRT VSWG) for prepaid international roaming. Through various team

meetings in 20072, a clear preference was expressed for the IS-826-based

approach.

2.1 Handset Based

In this approach, an application resident in the handset (or R-UIM) maintains the

subscriber balance, without reference to a central network-based system.

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

even for own-network prepaid service) to date. It is potentially subject to fraud as the

prepaid functionality resides in equipment under the control of the subscriber

(although it is designed to be tamper-proof). Careful planning would be required to

ensure the application was able to determine its own location and interpret/charge

dialed digit strings accordingly.

2.2 Service Node

The Service Node (SN) approach is common for initial deployments of prepaid

systems, and/or in smaller networks. Using vendor-dependent subscriber

provisioning and MSC datafill, calls from prepaid subscribers are trunked through

the SN before connecting to their destination. To distinguish it from the method

described in the following sections, this approach is also referred to in this document

as pure-SN.

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

-CLI) accordingly. It can also disconnect the call if the subscriber balance isexhausted.

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

2 Seehttp://wiki.cdg.org/wiki/Prepaid_Roaming#Discussion

Ref Doc 159, Ver 0.4 2009-06-01 9

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

2

3
http://wiki.cdg.org/wiki/Prepaid_Roaming#Discussionhttp://wiki.cdg.org/wiki/Prepaid_Roaming#Discussionhttp://wiki.cdg.org/wiki/Prepaid_Roaming#Discussion


10/52



in the serving country would involve two international call legs. The CLI may also be

unreliable in this case, making identification of the correct subscriber difficult.

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

datafill to route these subscribers differently may be more burdensome than the

serving operator is willing to accept for a roaming partner.

The SN approach may also be more challenging to implement for terminating call

charges, which are necessary for international call delivery while roaming.

2.3 ISUP Triggers with Service Node

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 arerouted by the MSC on a loop-around trunk to simulate the pure SN behavior.

Although the inefficient trunking issue for international roaming may be removed

(assuming it is possible to establish this ISUP-signaling-only arrangement

internationally), other limitations of the pure-SN approach remain. The MSC

configuration is even more extensive in this case as the loop-around trunks must be

defined.

2.4 ANSI-41/WIN Triggers with Service Node

This approach uses ANSI-41 / WIN Phase 1 triggers (i.e. pre-IS-826 capabilities) tosteer a prepaid subscribers calls through an SN. The advantage over other SN

solutions is that the subscriber provisioning and MSC handling can be largely

standards-compliant.

An All-Calls trigger can be used to invoke the SCP at subscriber origination. The

SCP can return a TLDN obtained from the SN to allow call routing as well as

potentially subscriber identification. For terminating calls, custom HLR handling

could prefix a handoff code to the TLDN to ensure routing (from the home network)

through the SN before call delivery.

While this method has definite interoperability advantages over other SN-basedapproaches, it retains the inefficient call routing path, which may be a significant

problem for international roaming deployments. Some RSPs may already offer this

kind of service.

Ref Doc 159, Ver 0.4 2009-06-01 10

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

2


11/52



2.5 Service Node with Call-back

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 anSMS to a specific address in the home network and provides the desired called

party digits. The Service Node in the home network initiates a call-back to the

subscriber and a simultaneous outcall to the desired called party.

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

standards-based, trunk-efficient international service.

Of the operators who responded to a 2007 survey3

, IS-826 was the most commonlydeployed approach for existing prepaid offerings.

3 Seehttp://wiki.cdg.org/w/images/2/26/PrepaidSurvey1Results.xls

Ref Doc 159, Ver 0.4 2009-06-01 11

1

1

2

3

4

5

6

7

8

9

10

11

12

2

3
http://wiki.cdg.org/w/images/2/26/PrepaidSurvey1Results.xlshttp://wiki.cdg.org/w/images/2/26/PrepaidSurvey1Results.xlshttp://wiki.cdg.org/w/images/2/26/PrepaidSurvey1Results.xlshttp://wiki.cdg.org/w/images/2/26/PrepaidSurvey1Results.xls


12/52



3 Introduction to IS-826

IS-826, TIA/EIA-41-D Pre-Paid Charging, is a standard for prepaid services using

the Wireless Intelligent Network (WIN) framework. WIN allows service logic to run

from a location remote from the switching equipment, using signaling messages to

control the call. This characteristic makes it ideal for use in the international roaming

scenario, where the home (service logic/call control) and serving (switching)

equipment) are widely separated.

The following subsections present a summary of WIN operations, and some

simplified callflows for key scenarios. For further details, refer to the standard

directly.

3.1 WIN Overview

This is an extremely simplified view of WIN. For a full treatment, please see [IS-

771].

WIN operates around the concept of triggers. Triggers may be armed, or

provided to the serving switch in the subscriber profile from the HLR, or may be

statically defined in the serving system. Triggers may also be dynamically armed(sent from the HLR during an actual call). Each trigger is associated with a particular

detection point (DP) in the call model defined in the switch. When a detection point

(e.g. the call has been answered by the other party) is encountered, and the

subscriber has a trigger armed for that DP, the trigger fires, and a message is sent

from the switch to a service logic instance at the Service Control Point (SCP),

typically a separate network element in the home network. The message advises

the SCP that the particular event has occurred. Depending on the trigger, the switch

may wait for further instructions in the response to the trigger message.

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 usageof this message in a prepaid scenario is to disconnect the subscribers call when the

credit (monitored by the SCP) reaches zero.

3.2 Subscriber Registration

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

Ref Doc 159, Ver 0.4 2009-06-01 12

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

2


13/52


14/52



disconnected

Table 4-1 - Typical Subscriber Profile Triggers

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

TriggerAddressList

TriggerList

DestinationAddress

WIN_TriggerList

Figure 4-2 - WIN Trigger Parameter Structure

The actual triggers are contained in the WIN_TriggerList parameter. Multiple

TriggerLists can be present, each containing a different set of triggers with an

associated SCP.

3.3 Prepaid Origination

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

The steps for a prepaid subscriber origination are shown in Figure 4-3 below. Notethat this is a simple case where there are no pre- or post-call tones or

announcements played.

Ref Doc 159, Ver 0.4 2009-06-01 14

1

1

2

3

4

5

6

7

8

9

10

11

12

13

2


15/52



Home

HLR

Serving

VLR/

MSC

Home

SCP

ORREQ ab

anlyzd

ANLYZD

OANSWER

ODISCONNECTodisconnect

c

d

e

f

g

h

i

j

k

l

m

orreq

Figure 4-3 - Prepaid Origination

Steps are as follows:

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.

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.

d) 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 theMSC.

4 In IS-826, the check is described as the SCP checking that the subscriber hasPrepPaid Charging active and the subscribers account balance is above thethreshold level.

Ref Doc 159, Ver 0.4 2009-06-01 15

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

2

3

4

5

6


16/52



e) 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 thecall

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.

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.

k) 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 MSCs message.

m) The serving MSC releases the external call leg.

3.4 Originating Call with Pre- and Post-Call Announcements

(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

addition of announcements made before and after the call. The announcements are

played from an Intelligent Peripheral (IP) under the control of the SCP. The MSC is

directed to set up a call leg to the IP via the ConnectResource message.

From a standards perspective the location of the IP is immaterial provided it can

be accessed from the MSC, and controlled by the SCP, it could be in the home,

serving or theoretically even another network. In practice, the location of the IP (if

used at all) will be an important issue for international roaming deployments.

The call flow is shown in Figure 4-4:

Ref Doc 159, Ver 0.4 2009-06-01 16

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

2


17/52



IP

Serving

VLR/

MSC

Home

SCP

ORREQ ab

anlyzd

ANLYZD

OANSWER

ODISCONNECT

odisconnect

c

d

e

f

g

h

i

s

orreq

SEIZERES

seizeres

CONNRES

INSTREQ

SRFDIR

srfdir

instreq

seizeres

CONNRES

INSTREQ

SRFDIR

srfdir

SEIZERES

instreq

j

k

l

m

n

o

p

q

r

t

u

v

w

x

y

z

aa

bb

cc

dd

ee

ff

gg

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

Ref Doc 159, Ver 0.4 2009-06-01 17

1

1

2

2


18/52




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.

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.

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.

j) The SCP sends an SRFDirective to the IP including the AnnouncementList

parameter for the announcements that are to be played.

k) 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.

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.

v-cc) 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.

Ref Doc 159, Ver 0.4 2009-06-01 18

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

2


19/52



dd) The SCP sends an odisconnect to the MSC.

ee) The MSC releases the call leg to the IP.

ff) The SCP concludes the IP conversation.gg) The serving MSC releases the MS.

3.5 Commanded Disconnect

(IS-826 Reference Ch4 8.X.8)

In this scenario the subscribers call is terminated by the prepaid application

typically because of balance exhaustion. The call flow is shown in Figure 4-5:

Serving

VLR/

MSC

HomeSCP

CCDIRa

b

ODISCONNECT

odisconnect

c

d

e

f

g

ccdir

Figure 4-5 - Application Commanded Disconnect


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.

c) 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).

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.

Ref Doc 159, Ver 0.4 2009-06-01 19

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

2


20/52



f) 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.

3.6 Terminating Call

(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

case both originating and terminating call flows are effectively running

independently). This scenario will be important for all operators offering prepaidroaming, even those who normally use a Calling Party Pays (CPP) model. For

further discussion on this issue, see 4.

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

actions before it is aware of the location of the prepaid subscriber. The call flow is

shown in Figure 4-6:

Ref Doc 159, Ver 0.4 2009-06-01 20

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

2


21/52



Home

HLR

In-call

MSC

Serving

MSC/

VLR

LOCREQ ab

anlyzd

ANLYZD

ROUTREQ

c

d

e

f

g

h

i

locreq

Home

SCP

LOCREQ

routreq

locreq

anlyzd

ANLYZD

TANSWER

TDISCONNECT

tdisconnect

j

k

l

m

n

o

p

q

r

s

Figure 4-6 - Prepaid Termination


a) The call origination is received by the in-call MSC (termed Originating MSC

in the standard).

b) The MSC determines that the call is for a mobile subscriber, and sends a

LocationRequest to the mobiles 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.

c) 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.

Ref Doc 159, Ver 0.4 2009-06-01 21

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

2


22/52



d) The Initial_Termination trigger fires and the MSC sends AnalyzedInformation

to the SCP.

e) 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 returninganalyzd. This check is equivalent to the one performed via the

Origination_Attempt_Authorized trigger in the mobile origination scenario.

f) Now the Location trigger fires and the MSC sends a second

LocationRequest to the HLR. The LOCREQ contains an indication of the

trigger encountered,

g) The HLR sees that the Location trigger fired (so it doesnt go into an infinite

loop) and sends a ROUTREQ to the serving VLR/MSC as per a normal

termination.

h-i) A TLDN is assigned by the serving system, and returned via the HLR to the

in-call MSC, as per a normal termination.

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).

k) 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 subscribers balance.

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.

s) The calling party is disconnected.

Ref Doc 159, Ver 0.4 2009-06-01 22

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

2


23/52



4 International Implementation of IS-826

Although IS-826 appears to offer the best solution for an international deployment,

there are several areas which will require careful examination and co-operation to

ensure a successful service. Specific issues are described in the following

subsections.

4.1 Dialplan Support

Unlike in a postpaid scenario, the SCP in the home network is responsible for ratingthe prepaid call. This means the SCP needs to not only know which operator is

serving the subscriber in order to apply the correct rate (see 4), but also to

understand the dialplan used by the subscriber in the serving network in order to

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

dialed.

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

home operator to reconcile roamer charges with dialed calls, but this information

may not always be examined in detail. For a prepaid call, this information must be

used to replicate a detailed rating table in the SCP for each serving operator.

Home operators may have a simplified rating plan (e.g. divide the globe into a few

zones with common retail call charges anywhere within a zone), but the dialing

patterns from different countries within a rate zone may still be different, and

necessitate explicit entry into the SCP datafill. Given the likelihood of clashes (e.g.

10-digit local dialing possible in both USA and Mexico), it is assumed that the SCP

will require the capability to index into different dialing plans based on subscriber

location (MSCID).

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 betweendifferent rate zones will still be necessary at the SCP, a common format for dialed

digit strings can be used. Further investigation into this approach would be

necessary to determine other impacts, e.g. reconciliation difficulty if the dialed digit

string at the SCP is different to that received via CIBER for wholesale settlement.

Ref Doc 159, Ver 0.4 2009-06-01 23

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

2


24/52



4.2 Terminating Call Charges

As shown in 3, IS-826 defines a mechanism to charge a prepaid subscriber for

receiving a call. For operators who normally charge subscribers for terminating calls,this mechanism will already be defined in their prepaid systems and network

elements, along with the necessary subscriber triggers. Provided the serving

network also supports the terminating triggers (and even in some cases if it doesnt -

see 4), this mechanism adapts well to the international roaming case, and the

subscriber can be charged for the international call delivery leg in addition to any

serving network airtime charges.

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

model: no terminating triggers may be assigned in the subscriber profile, or be

returned from the HLR in the initial LocationRequest. While this is no problem for

on-network operation, it is an issue for international roaming, where even CPP

operators still charge the roaming subscriber to receive the call. Even if the serving

network does not charge airtime for a roamer-terminated call, the international call

delivery leg is still charged to the roaming subscriber.

To allow charging for outbound roamer-terminated calls, the CPP operator could

enable the full terminating call scenario. However, this would impact allprepaid-

terminated calls for the operators subscribers, regardless of their location. This

would increase signaling load on both the HLR and SCP by a potentially significant

amount, and is assumed not to be an acceptable solution for CPP operators.

The following subsections describe three potential solutions for enabling terminating

call charges.

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

This is the least preferred option. In this approach, the HLR does not treat thesubscriber as if they had were prepaid (for terminating calls). The RSP (required to

be present for this option) inserts the T_Answerand T_Disconnecttriggers into the

subscriber profile at registration time. Call delivery proceeds as per a normal

(postpaid call) until the call is answered, at which point the T_Answertrigger fires

and the prepaid terminating call flow picks up (i.e. at step n ofFigure 4-6). This

approach has the advantage of simplicity for the home operator with no modification

Ref Doc 159, Ver 0.4 2009-06-01 24

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2


25/52



required. There is some impact on the RSP, but some subscriber profile

modification is within existing RSP capabilities.

The (significant) drawback to this approach is that the SCP is not involved tovalidate the subscribers balance until after the call has been answered. TANSWER

is a unidirectional message the MSC does not wait for a reply from the SCP

before connecting the call. If the subscribers balance is such that this call should

not have been allowed, the SCP must immediately send a CCDIR to disconnect the

call. The delays involved in this process represent a revenue leakage for the home

operator (the serving operator will charge the home for the brief call), and an

annoyance for the subscriber who will receive and answer a call only for it to be

disconnected a few seconds later.

4.2.2 Service Node for Terminations

In this approach, the international call delivery legs are routed through a Service

Node (SN) in the home network. This is analogous to a pre-WIN approach to

prepaid, where the SN sits in-line in the call, and can easily disallow or disconnect

the call as appropriate, was well as communicate with whatever platform maintains

the subscriber balance.

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

prepaid service. When used solely for terminations however, this inefficiency is

considerably less as the call must anyway traverse the home network (excluding a

DRRR scenario).

All international TLDNs could be routed through the SN, which would then need to

determine (perhaps via communication with the SCP) whether the called subscriber

was prepaid or not (appropriate ISUP parameter population e.g. Redirecting

Number - would be required to ensure the called subscriber could be identified). No

terminating triggers would be required in the subscriber profile at the serving

network.

This option involves the introduction of a new network element into the home

operator network, of a type which an operator offering IS-826-based prepaid service

may have worked hard to remove/avoid. For large operators, the internal trunkingcosts from the in-call MSC to the SN may be significant.

4.2.3 Custom HLR Handling

This is the preferred option. If the HLR were pre-provisioned with a list of which

MSCIDs required terminating charging, it could include the subscriberprofile

Ref Doc 159, Ver 0.4 2009-06-01 25

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

2


26/52



terminating triggers at registration time for these MSCs only, as well as invoke the

prepaid termination model at call time only for subscribers registered in these

MSCs.

For calls to subscribers registered on the home operators own network (or other

domestic partners with no terminating charge) the HLR would respond to the first

(and only) LOCREQ from the in-call MSC with a TLDN as per a normal postpaid

call. If the subscriber were registered on an international MSC, the HLR would

return the TriggerAddressList in the locreq as per step c ofFigure 4-6. Currently, no

HLRs are known or suspected to support this handling.

This approach does require the SCP be upgraded/configured to understand the

standard prepaid terminating call flow, even if it is not invoked for all terminating

calls. Currently, no HLRs are known or suspected to support this handling.

4.3 Announcements

Although actual implementations may vary, IS-826 allows for the possibility of many

announcements and tones to be played to the prepaid subscriber in the course of

call attempts. Announcements can describe a subscribers balance before a call,

and give the cost of the call and/or the updated balance after a call. There are also

various tones that can be played to a subscriber, such as low balance warning,

disconnect warning etc.

Naturally, different operators may choose to implement different announcements,

and in an international scenario are even likely to use different languages toimplement the same announcement function.

Announcements may be played from a Service Node (SN) in the home network, an

Intelligent Peripheral (IP) in either the home or serving network, or from the serving

MSC. Any of these elements can also play tones to the subscriber.

An important decision for an international roaming prepaid implementation is where

to host the announcements that will be played to the subscriber. The following

subsections describe the advantages and disadvantages of the various options.

Note that an alternative or adjunct to any of the options described below is to

provide information to the subscriber via SMS (e.g. to provide remaining balance

after a call finishes).

4.3.1 Serving System IP

This is the least preferred option. Although it represents a cost-effective approach to

providing announcements (no international trunk usage), it requires a significant co-

Ref Doc 159, Ver 0.4 2009-06-01 26

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

2


27/52



ordination effort between the home and serving operators to ensure that the correct

announcements are available in the serving network. ANSI-41/IS-826 provides a

means to support the same announcement in multiple languages via the

PreferredLanguage parameter, however this is not believed to be widely supportedin the industry today. Serving operators may be reluctant to devote capacity on their

own elements to each of their inbound roaming partners, and to give a measure of

control over this element to their partners. Some serving operators may also not

have implemented an IP at all, even though the home network is expecting to have

one available.

An IP in the serving system will also require a somewhat increased amount of

international signaling, as the various control messages that pass between the SCP

and IP are now inter-operator.

In the home network, logic will be required in the SCP to select an IP based on the

subscribers location. This kind of routing may already be in place for large domestic

networks. Different AnnouncementCode parameters might be required to access the

desired announcement in the serving networks IP, as compared to home network

IPs for on-network usage.

Careful handling may be required at the RSP (if present) to ensure the TLDN

returned from the IP reaches the MSC in an appropriate format after two

international signaling legs (to and from the SCP).

4.3.2 Home System IP

Using the home network IP represents a simplerbut potentially expensive option.

No custom configuration is required on the SCP or IP to enable the announcements.

The IP TLDN may require internationalization, but as described in 4 this is a

relatively standard RSP capability. The subscriber receives the announcements with

which s/he is familiar.

The primary concern with this method is the international call leg that is required to

connect the subscriber to the IP. The subscriber is typically not charged for the

duration of the announcement, but the serving operator may be charged by their

international provider, and would then pass this charge on to the home operator.

A mitigating factor is that the IP in the home network may not provide an ISUP

answer signal before playing the announcement. The lack of answer signal may

(depending on operator and long-distance provide policies) prevent billing starting

for the international leg. Use of low-cost international bearers (e.g. VoIP) may also

help to make this approach less financially burdensome.

Ref Doc 159, Ver 0.4 2009-06-01 27

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

2


28/52



4.3.3 Serving MSC Tones Only

This option is the preferred approach, on the basis of operator simplicity. It is a

simple and cost-effective way to provide a basic level of service to the roamingsubscriber. By using the MSC as the source, no extra signaling or additional call

legs are required. By using only tones, there is no need to co-ordinate

announcement loading between the home and serving operators. Even if the tone is

not exactly the same as is used in the home network, the subscriber is likely to

understand e.g. that beeps during the call are some indication of low balance.

The main drawback of this method is that a lower level of service is experienced by

the roamer they will not hear details about their remaining balance at the

beginning/end of a call. Nevertheless the basic components of the prepaid service

will still be available with a minimum level of complexity. Some custom handling may

be required in the SCP to avoid trying to set up announcements when thesubscriber is known to be in an international location. As noted above, notification

via SMS remains an an alternative method for providing at least some of the same

information.

Of course, operators are free to implement by mutual agreement a method which

provides for a better customer experience.

4.4 Account Replenishment While Roaming

An important component of the prepaid service is the ability for subscribers to

replenish (aka recharge or top-up) their account as their credit becomes depleted.This activity presents several challenges while roaming internationally.

For the purposes of discussion, this document makes a distinction between two

parts of the recharge process: obtaining the necessary recharge information

(credentials which represent a purchase of credit); and transferring this information

to the home prepaid system. There may also need to be a transfer of funds to the

home operator from the entity managing the purchase transaction with the

subscriber.

The division may be somewhat arbitrary not all information and transfer

methods can logically be combined, and in some cases the two parts are essentiallycombined into a single transaction.

Operators may choose to deploy several of the methods described below (or

additional methods), and are not necessarily limited to a single choice per operator.

The selected options will depend on the ease of implementation, the demographics

of the individual operators prepaid roaming subscribers, and the willingness of key

Roaming Partners to integrate solutions in their own networks.

Ref Doc 159, Ver 0.4 2009-06-01 28

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2


29/52



4.4.1 Obtaining Recharge Information

4.4.1.1 Recharge Card Purchase

This is believed to be a common recharge method for subscribers at home. The

subscriber purchases a scratchy card from any of the operators retail partners

(e.g. gas stations). The card provides a series of digits (loosely referred to here as a

PIN number) which must be provided to the prepaid system to validate the recharge.

Variations on a similar theme include making the transaction via a Point-Of-Sale

terminal or ATM, which print out a paper slip containing the equivalent card

number. The actual payment mechanism (credit/debit card, cash etc) becomes the

responsibility of the retail outlet.

In a roaming scenario, an obvious issue is that of having the operators cards

available in a foreign country. One possibility is to use a universal card which is

valid for recharge to multiple operators systems. Although such cards exist today, it

is not known whether there are any solutions that are available in multiple countries.

At least initially, the size of the CDMA prepaid international roaming market may not

be sufficient to justify the international expansion of an existing single-country

provider.

Where there is significant travel by an operators subscribers to a particular country,

or especially to specific regions within that country, it may prove feasible for the

operator to arrange for their recharge cards to be available in select retail locations

in the foreign country.

An alternative may be a bilateral agreement to allow the use of a Roaming Partners

recharge cards on the operators system. A roamer could then take advantage of

the serving operators existing retail distribution network for recharge card purchase.

Some back-end connection would be required between the home country prepaid

system, and the serving country Card Management System (CMS). This option may

be attractive in a bilateral sense, but may not scale well to multiple roaming

partners, although an RSP could in theory (they do not today) act as a hub in this

case.

An example of a possible process for this kind of recharge is shown inFigure 5-7:

Ref Doc 159, Ver 0.4 2009-06-01 29

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

2


30/52



Prepaid Application&

Recharge System

Card Management System

HomeServe

Figure 5-7 - Possible Card-Sharing Process


1) The subscriber purchases a recharge card from a retail location in the visited

country

2) The subscriber contacts the home operator recharge system and provides

the recharge card number3) The recharge system recognizes the card number as belonging to the

serving operator (care would be required to ensure card numbers did not

overlap between operators), and contacts the serving operator CMS to

validate the card. The CMS marks the card as used, and the home operator

Prepaid Application adds credit to the subscriber balance

4) Separately, the serving operator (who received payment for the initial card

purchase) pays the home operator

An alternative process has the roaming subscriber contacting the servingoperator

recharge system. This system recognizes the subscriber as belonging to the home

operator, and contacts that operators Prepaid Application to add credit to the

subscriber balance (see 4).

Finally, a default option is of course for the subscriber to purchase multiple recharge

cards in the home country before traveling, for use as required.

Ref Doc 159, Ver 0.4 2009-06-01 30

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

2


31/52



4.4.1.2 Credit/Debit Card

Subscribers with a valid Credit or Debit Card can authorize account credit

purchases directly by providing the card details: rather than using the credit/debitcard to purchase a scratchy card, and then providing that cards PIN to the prepaid

system, the credit/debit card details can be provided by the subscriber directly to the

prepaid system.

This process is attractive for a roaming scenario, as the purchase method is valid for

the subscriber in a foreign country. The issue of connectivity to the home prepaid

system remains. To add simplicity and a measure of security for the subscriber, the

card may be pre-authorized while in the home network (e.g. via a web interface or

voice call to a Customer Service Representative - CSR), and a subscriber-

nominated security alias (PIN) associated with the card details and with the

specific subscriber number. When the subscriber connects to the prepaid system to

replenish their account, they only need to provide the security alias, rather than the

full card details.

While simple from a technical perspective, relying on a credit/debit card may not be

suitable for operators whose prepaid subscribers are often unbanked5. In some

markets prepaid credit cards may be suitable for these subscribers.

4.4.2 Connection to Prepaid System

4.4.2.1 Wired Internet Connectivity

The home operator may provide a website through which a subscriber can enter

their account information (e.g. phone number) and recharge information. This is

essentially a default option, with no direct mobile network involvement. While simple

for the operator, it may not represent a convenient option for the roamer.

As an alternative, the home operator may work with one or more financial

institutions in the home country to allow recharges direct from those institutions

internet banking sites. For subscribers with internet-enabled bank accounts, this

addresses both the recharge information and connection stages in a single

transaction.

4.4.2.2 Wireless Connectivity

If prepaid international packet data roaming is implemented between the two

networks, an equivalent site may be available through the mobiles browser. This

5or "underbanked" - they do not have accounts at banks and other mainstream financial

institutions

Ref Doc 159, Ver 0.4 2009-06-01 31

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

2

3

4


32/52



may be a more cost-effective approach (in terms of the inter-operator charge

absorbed by the home operator) than an equivalent voice-call.

4.4.2.3 Voice Call to Home Network IVR

This approach is assumed to be the most common for own-network recharges.

When in the home network, the subscriber dials a toll-free number (or a convenient

short code), is routed to a CSR or Interactive Voice Response (IVR) system, and

provides their recharge information. The CLI (Calling Line Identity) may be used to

identify the prepaid account to be credited.

When roaming internationally, the primary issue with this approach is the cost of the

call. Assuming the subscriber will not be charged, the cost must be borne by the

home operator, as the serving operator will view this as a normal international call to

the home country. Use of a Universal International Freephone Number (UIFN), e.g.

+ 800 01234567, may help to reduce the cost. Failure to provide an ISUP answer

signal (see 4) may not prove helpful in this case as the forward speech path might

not be connected without an answer).

Since prepaid subscribers calls are under the control of the home network, it should

be possible to allow use of the familiar home network short code, and simply return

a modified digit string to the serving network for routing.

The CLI may not be reliable due to the international call leg. The subscriber identity

is however available via the trigger messages sent as part of normal prepaid

originations. The SCP and IVR can communicate (effectively treating the IVR as an

IP as per 3) to provide this information. Note that this call scenario is not explicitlyshown in IS-826, however (since in this case the pre-call announcement is actually

the final destination for the call).

4.4.2.4 Recharge via SMS

SMS may provide a relatively simple and cost-effective means of connecting to the

home network for recharge. Assuming two-way (i.e. mobile-originated and

-terminated) SMS international roaming is implemented between the home and

serving operators, the subscriber could send their recharge information (e.g. scratch

card number or credit card details/security alias) in an SMS to a short-code address

determined by the home operator. The connection between the MC and SCP toeffect the recharge is entirely within the control of the home operator, and can be

the same as is used by subscribers while in their home network.

4.4.2.5 Local IVR

A more cost-effective approach than the call to a home network IVR described in 4

may be to call an IVR in the serving country. If the subscriber has purchased a local-

Ref Doc 159, Ver 0.4 2009-06-01 32

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

2
http://www.itu.int/ITU-T/universalnumbers/uifn/http://www.itu.int/ITU-T/universalnumbers/uifn/


33/52



network recharge card (as described in 4), the subscriber would navigate the

serving operators IVR in much the same way that one of that operators own

subscribers would. A back-end connection would be required to the home operators

prepaid system to effect the recharge, as well as an inter-operator settlementrelated to the purchased value. The subscriber would need to be identified as

belonging to a different operator, through CLI (if correctly available) and/or explicit

menu selections. The subscriber may not understand the language used for the IVR

announcements.

Another approach would be for the local IVR system to act as an IP under the

control of the home SCP. This is similar to the local announcement case discussed

in 4, with equivalent challenges.

4.4.2.6 Third-party Network Connection

This approach combines both phases of the recharge action into a single step (at

least from the end-users perspective). The subscriber purchases credit at a third-

party retail location in the visited country and provides their home network details

and subscriber number. The third-party system then connects all the way to the

home network prepaid system to credit the subscribers balance. Separately (and in

the background), a payment is made from the third party to the home operator to

cover the subscriber credit.

At least one such service known to exist today, in a limited deployment. Specific

terminal capabilities may be required at the cooperating retail locations to enable

bill payment to a company in another country.

4.4.3 Alternative Approaches

Several other methods are in use by operators (CDMA and/or GSM) today which

essentially work around the recharge issue.

4.4.3.1 Temporary Conversion to Postpaid

If the subscriber can establish an alternative charging mechanism such as a valid

credit card, or fixed line phone account (e.g. for an operator who also acts as a

PSTN provider), the operator can arrange to pass the roaming charges on to the

subscriber in a postpaid manner just like other roamers. Depending on operator

choice, a provisioning change may not be necessary (instead just steer CIBER

incollects to the postpaid account). Care would be required in this case when

handling charges originating from the home network such as those for international

call delivery and SMS.

Ref Doc 159, Ver 0.4 2009-06-01 33

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

2


34/52



4.4.3.2 Third Party Top-Up

Some operators allow a free SMS to be sent by a subscriber whose credit is

depleted. The SMS is sent to a friend/family member who is also a subscriber of thesame operator, and who is currently in the home network. This third party uses the

operators existing capability to add credit to someone elses account to top up the

roaming subscriber.

4.4.3.3 Top-up Before Roaming

A very simplistic approach is not to offer any roaming recharge capabilities at all,

and merely encourage subscribers to put sufficient credit on their account before

they leave the country.

4.5 Signaling Link Occupancy and Message Length

As shown in 3, the callflows for IS-826 are considerably more complicated than for

normal calls. Inherent in the nature of a WIN service , there is more communication

between the serving network and the service control residing in the home network.

In an international roaming scenario, a relatively small linkset may be used to carry

all the operators roaming signaling traffic (typically connected to the RSP). A high

proportion of prepaid subscribers among roamers may make a significant

contribution to the load on these links. It is important to work through the

dimensioning exercise before launching the service. The impact could be felt both

by the home and serving operators.

The figures below provide an estimate of the additionalsignaling load, in octets per

call, that may be expected due to MSCto-SCP messaging for prepaid. Operators

may combine these values with their expected prepaid roamer subscriber numbers

and Busy-Hour Call Attempt figures to derive the actual signaling link impact.

The values shown in Table 5-2below assume the call flows as shown in 3, with no

announcements. Further details on the derivation are given in the Appendix.

Operators are strongly encouraged to validate these values with their own specific

addressing and application implementations.

Ref Doc 159, Ver 0.4 2009-06-01 34

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

2


35/52



Call Type Additional Signaling per call

Prepaid Originated Call 550 octets

Prepaid Terminated Call 250 octets

Table 5-2 - Additional Signaling Load for Prepaid

As an example, an operator with 2000 prepaid roaming subscribers, making 1

originating and 0.2 terminating call attempts each in the busy hour could expect to

require an additional 0.1 64 kbps signaling links based on 40% occupancy.

Inclusion of the TriggerAddressList parameter in the subscriber profile can add

approximately 30 additional bytes to the message length (depending on address

and trigger types included) for RegistrationNotification Return Results and other

messages carrying the subscriber profile. If this inclusion causes the message from

the HLR to exceed the maximum allowable length for the signaling medium, it will

not be manifest as a roaming problem but rather an issue for an (assumed earlier)

domestic deployment of the prepaid service.

However if the message is close to the limit it may be pushed over by the inclusion

at the RSP of different parameters required by the serving network (e.g. change to

Global Title addressing). In this case the RSP and home operator would need to

work together to identify parameters that could be safely removed from the

message, or alternatively the message could be segmented if supported by both the

RSP and serving network.

4.6 RSP support

For most CDMA-CDMA international roaming today, a Roaming Service Provider

(RSP) is present in the ANSI-41 callflow. Prepaid roaming as described in this

document does not require the presence of an RSP, however I if an RSP (or

potentially multiple RSPs) is present between two operators who wish to deploy

prepaid international roaming, certain capabilities will be required from the RSP. In

addition, the RSP may be able to provide other optional services to simplify or

enhance the service deployment.

In general, especially for early implementations, various differences in standards

interpretation can be expected between the equipment deployed by the home and

serving operators. The RSP may have an important role to play to resolve some of

these issues without major impacts to either operator.

Ref Doc 159, Ver 0.4 2009-06-01 35

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

2


36/52



For implementations without an RSP, this section may highlight potential

incompatibilities that must be resolved through other means (e.g. changes/upgrades

to network elements, or the introduction of an in-house RSP, i.e. an ANSI-41

mediation platform).

At the time of writing, RSPs did not support the necessary transfer of IS-826

messages. Further work is required by the RSPs before the solution described in

this document can be deployed by operators who connect via an RSP.the basic

message transport described in 4 and several related capabilities were supported

by at least one RSP in a recent upgrade. Operators considering prepaid roaming

should contact their RSP(s) directly to determine the specifics of their offering.

4.6.1 Basic Message Transport

The RSP will be required to provide basic routing for the new messages introducedby IS-826-based prepaid service. Examples of the new messages include ANLYZD,

OANSWER, CCDIR, etc.

The RSP must accept messages addressed to its Point Code & Sub-System

Number (PC/SSN) or Global Title Address (GTA), analyze the MSID in the message

to determine the correct home network, and route the message on to the predefined

or pre-stored address of the correct home network element. This behavior is

equivalent to what RSPs do today for other ANSI-41 messages transferred between

the home and serving networks.

4.6.2 Analysis and Modification of Embedded Address

As discussed in 3, the TriggerAddressList parameter contains the address of the

SCP to which trigger messages are to be sent. When sent from the home network,

this will be the home network address (PC/SSN or GTA) of the SCP, which may not

be valid in the serving network. The RSP must read this value and replace it with a

serving network address that points to the RSP itself before transferring the

message to the serving network. In the reverse direction (i.e. when a trigger

message is received), the RSP must remove its own address and reconstitute the

originally received address. This modification of MTP/SCCP-layer address

parameters embedded in the ANSI-41 layer is already performed by RSPs today to

handle the SMS_Address parameter.

4.6.3 Identification of True Serving Network

For the SCP in the home network to be able to debit the subscribers balance at the

correct rate, it will likely need to know which operator is serving the subscriber (as

different operators may charge different wholesale rates). Currently many home

Ref Doc 159, Ver 0.4 2009-06-01 36

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

2


37/52



operators see only a single serving MSCID, representing the RSP. This simplifies

the datafill required in the home network to roll out new roaming partners, and to

accommodate network changes by existing partners.

A proposed middle ground is the use of operator-level MSCID, where each serving

operators entire network is represented by a single MSCID. This approach has

been previously proposed for other services. Further investigation is required to

determine whether it would be possible to retain the single MSCID for

communication with the HLR (to retain the datafill advantages), but use the serving

operator-specific value for messages to the SCP. See 4 for one reason not to

restrict the operator-specific MSCID only to the SCP.

Any MSCID consolidation may represent a challenge in a node failure/recovery

scenario, e,g, when a MSC sends a BulkDisconnect message to advise the SCP(s)

that all calls have ended. Care is required to avoid cancelling billing for calls at other

MSCs.

4.6.4 Message/Parameter Modification

As with current roaming messaging, the RSP may need to modify the contents of

certain messages, both adding/removing parameters from a message, and

changing the value of an included parameter. These modifications may be

required to address an implementation incompatibility between the home and

serving networks, or may provide a value-add simplification or enhancement.

Possible examples of this kind of modification include:

Mapping of Announcements: The AnnouncementCode sent from the homeSCP may contain announcements or tones that are not supported by the

serving network. The RSP may convert these values to ones known to be

available in the serving network.

Call Barring changes: The RSP may change the OriginationIndicator of a

prepaid subscriber to indicate Origination denied when the subscriber is

roaming in a market that does not support IS-826, or it may deny the

registration altogether.

Mapping to equivalent alternatives: In some cases, there may be more

than one way to signal a similar intent in messages. The RSP may convert

from one approach to another in order to match the serving networkscapabilities. An example is replacing ActionCode:Disconnect call with

AccessDenied in an AnalyzedInformation Return Result. The RSP may also

need to remove unnecessary parameters to ensure that messages remain

within length limits.

WINCapability Mapping: The RSP may need to change the WINCapability

(WINCAP) values in the event that a single serving operator has varying

Ref Doc 159, Ver 0.4 2009-06-01 37

1

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

2


38/52



levels of IS-826 support in their network, and the home network applies

WINCAP on a MSCID-wide level.

TLDN Modification: As with existing modification for call delivery, TLDNs

used for connection to an Intelligent Peripheral (IP) or Service Node (SN)may need formatting by the RSP to ensure they are routable from the

serving MSC.

Dialplan Correction: The RSP may map all dialed digit strings to an E.164

equivalent, to simplify table population at the home SCP. See 4.

4.6.5 No Trigger Support

The RSP may choose to offer an alternative to IS-826, which could be used in the

event that the serving network does not support the necessary triggers/operations.

See 4.

4.6.6 Prepaid System Interconnectivity

The RSP may act as a central hub to simplify connections between different

operators prepaid systems. This would be useful if for example the operators

allowed subscribers to purchase each others recharge cards to account top-up

see 4. Such a connection would most likely be IP (Internet Protocol, not Intelligent

Peripheral) based, rather than using SS7 connectivity. This service does not build

directly on known existing RSP functionality, but may bear some similarity to other

services offered by RSP companies, e.g. inter-operator SMS hubbing.

4.7 Serving Network Trigger Support

A basic requirement for an IS-826-based service is that the network supports IS-

826. As a starting point, a serving network that does not support the IS-826 triggers

and related operations will not be a suitable (i.e. allowable) destination for an IS-

826-based prepaid roaming subscriber. While actual implementations may throw up

specific requirements, in general a serving network would be expected to support

the scenarios shown in 3.

If a serving network does not support IS-826, it may be possible to fall back to aless-preferred implementation, e.g. the ANSI-41/WIN Phase 1 solution outlined in

2. An RSP may play a significant role here, replacing IS-826 triggers with ANSI-

41/WIN alternatives in the subscriber profile, and potentially even hosting the

associated Service No

Date post:	06-Apr-2018
Category:	Documents
Upload:	apelei9563
View:	249 times
Download:	0 times

Prepaid International Roaming

Documents