Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 52 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
52
Dung lượng
2,82 MB
Nội dung
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
http://www.cdg.org
cdg@cdg.org
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 http://wiki.cdg.org/wiki/Prepaid_Roaming#Discussion
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 http://wiki.cdg.org/w/images/2/26/PrepaidSurvey1Results.xls
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
Prepaid International Roaming
Terminology
1
For calls to subscribers registered on the home operator’s own network (or other
2domestic partners’ with no terminating charge) the HLR would respond to the first
3(and only) LOCREQ from the in-call MSC with a TLDN as per a normal postpaid
4call. If the subscriber were registered on an international MSC, the HLR would
5return the TriggerAddressList in the locreq as per step c of Figure 4 -6. Currently,
6no HLRs are known or suspected to support this handling.
1
This approach does require the SCP be upgraded/configured to understand the
8standard prepaid terminating call flow, even if it is not invoked for all terminating
9calls. Currently, no HLRs are known or suspected to support this handling.
7
4.3 Announcements
10
Although actual implementations may vary, IS-826 allows for the possibility of many
12announcements and tones to be played to the prepaid subscriber in the course of
13call attempts. Announcements can describe a subscriber’s balance before a call,
14and give the cost of the call and/or the updated balance after a call. There are also
15various tones that can be played to a subscriber, such as low balance warning,
16disconnect warning etc.
11
Naturally, different operators may choose to implement different announcements,
18and in an international scenario are even likely to use different languages to
19implement the same announcement function.
17
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
22MSC. Any of these elements can also play tones to the subscriber.
20
21
An important decision for an international roaming prepaid implementation is where
24to host the announcements that will be played to the subscriber. The following
25subsections describe the advantages and disadvantages of the various options.
23
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
28after a call finishes).
26
27
4.3.1 Serving System IP
29
This is the least preferred option. Although it represents a cost-effective approach to
providing announcements (no international trunk usage), it requires a significant co32ordination effort between the home and serving operators to ensure that the correct
33announcements are available in the serving network. ANSI-41/IS-826 provides a
34means to support the “same” announcement in multiple languages via the
35PreferredLanguage parameter, however this is not believed to be widely supported
30
31
2
Ref Doc 159, Ver 0.4
2009-06-01
26
Prepaid International Roaming
Terminology
1
in the industry today. Serving operators may be reluctant to devote capacity on their
2own elements to each of their inbound roaming partners, and to give a measure of
3control over this element to their partners. Some serving operators may also not
4have implemented an IP at all, even though the home network is expecting to have
5one available.
1
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
8and IP are now inter-operator.
6
7
In the home network, logic will be required in the SCP to select an IP based on the
10subscriber’s location. This kind of routing may already be in place for large domestic
11networks. Different AnnouncementCode parameters might be required to access the
12desired announcement in the serving network’s IP, as compared to home network
13IPs for on-network usage.
9
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
16international signaling legs (to and from the SCP).
14
15
17
4.3.2 Home System IP
Using the home network IP represents a simpler but potentially expensive option.
No custom configuration is required on the SCP or IP to enable the announcements.
20The IP TLDN may require internationalization, but as described in §4.6.4 this is a
21relatively standard RSP capability. The subscriber receives the announcements with
22which s/he is familiar.
18
19
The primary concern with this method is the international call leg that is required to
24connect the subscriber to the IP. The subscriber is typically not charged for the
25duration of the announcement, but the serving operator may be charged by their
26international provider, and would then pass this charge on to the home operator.
23
A mitigating factor is that the IP in the home network may not provide an ISUP
28answer signal before playing the announcement. The lack of answer signal may
29(depending on operator and long-distance provide policies) prevent billing starting
30for the international leg. Use of low-cost international bearers (e.g. VoIP) may also
31help to make this approach less financially burdensome.
27
32
4.3.3 Serving MSC Tones Only
This option is the preferred approach, on the basis of operator simplicity. It is a
34simple and cost-effective way to provide a basic level of service to the roaming
35subscriber. By using the MSC as the source, no extra signaling or additional call
33
2
Ref Doc 159, Ver 0.4
2009-06-01
27
Prepaid International Roaming
Terminology
1
legs are required. By using only tones, there is no need to co-ordinate
2announcement loading between the home and serving operators. Even if the tone is
3not exactly the same as is used in the home network, the subscriber is likely to
4understand e.g. that beeps during the call are some indication of low balance.
1
The main drawback of this method is that a lower level of service is experienced by
6the roamer – they will not hear details about their remaining balance at the
7beginning/end of a call. Nevertheless the basic components of the prepaid service
8will still be available with a minimum level of complexity. Some custom handling may
9be required in the SCP to avoid trying to set up announcements when the
10subscriber is known to be in an international location. As noted above, notification
11via SMS remains an an alternative method for providing at least some of the same
12information.
5
Of course, operators are free to implement by mutual agreement a method which
14provides for a better customer experience.
13
4.4 Account Replenishment While Roaming
15
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.
18This activity presents several challenges while roaming internationally.
16
17
For the purposes of discussion, this document makes a distinction between two
20parts of the recharge process: obtaining the necessary “recharge information”
21(credentials which represent a purchase of credit); and transferring this information
22to the home prepaid system. There may also need to be a transfer of funds to the
23home operator from the entity managing the purchase transaction with the
24subscriber.
19
The division may be somewhat arbitrary – not all “information” and “transfer”
26methods can logically be combined, and in some cases the two parts are essentially
27combined into a single transaction.
25
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.
30The selected options will depend on the ease of implementation, the demographics
31of the individual operators’ prepaid roaming subscribers, and the willingness of key
32Roaming Partners to integrate solutions in their own networks.
28
29
2
Ref Doc 159, Ver 0.4
2009-06-01
28
Prepaid International Roaming
Terminology
1
4.4.1 Obtaining Recharge Information
1
2
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 operator’s retail partners
5(e.g. gas stations). The card provides a series of digits (loosely referred to here as a
6PIN number) which must be provided to the prepaid system to validate the recharge.
3
4
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”
9number. The actual payment mechanism (credit/debit card, cash etc) becomes the
10responsibility of the retail outlet.
7
8
In a roaming scenario, an obvious issue is that of having the operator’s cards
available in a foreign country. One possibility is to use a “universal” card which is
13valid for recharge to multiple operators’ systems. Although such cards exist today, it
14is not known whether there are any solutions that are available in multiple countries.
15At least initially, the size of the CDMA prepaid international roaming market may not
16be sufficient to justify the international expansion of an existing single-country
17provider.
11
12
Where there is significant travel by an operator’s subscribers to a particular country,
19or especially to specific regions within that country, it may prove feasible for the
20operator to arrange for their recharge cards to be available in select retail locations
21in the foreign country.
18
An alternative may be a bilateral agreement to allow the use of a Roaming Partner’s
23recharge cards on the operator’s system. A roamer could then take advantage of
24the serving operator’s existing retail distribution network for recharge card purchase.
25Some back-end connection would be required between the home country prepaid
26system, and the serving country Card Management System (CMS). This option may
27be attractive in a bilateral sense, but may not scale well to multiple roaming
28partners, although an RSP could in theory (they do not today) act as a “hub” in this
29case.
22
An example of a possible process for this kind of recharge is shown in Figure 5 -7:
30
2
Ref Doc 159, Ver 0.4
2009-06-01
29
Prepaid International Roaming
Terminology
1
1
2
Figure 5-7 - Possible Card-Sharing Process
Steps are as follows:
3
4
1)
5
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 number
3)
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
6
7
8
9
10
11
12
4)
13
14
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 serving operator
recharge system. This system recognizes the subscriber as belonging to the home
17operator, and contacts that operator’s Prepaid Application to add credit to the
18subscriber balance (see §4.4.2.5).
15
16
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.
19
20
2
Ref Doc 159, Ver 0.4
2009-06-01
30
Prepaid International Roaming
Terminology
1
4.4.1.2 Credit/Debit Card
1
Subscribers with a valid Credit or Debit Card can authorize account credit
purchases directly by providing the card details: rather than using the credit/debit
4card to purchase a “scratchy card”, and then providing that card’s PIN to the prepaid
5system, the credit/debit card details can be provided by the subscriber directly to the
6prepaid system.
2
3
This process is attractive for a roaming scenario, as the purchase method is valid for
8the subscriber in a foreign country. The issue of connectivity to the home prepaid
9system remains. To add simplicity and a measure of security for the subscriber, the
10card may be “pre-authorized” while in the home network (e.g. via a web interface or
11voice call to a Customer Service Representative - CSR), and a subscriber12nominated security alias (“PIN”) associated with the card details and with the
13specific subscriber number. When the subscriber connects to the prepaid system to
14replenish their account, they only need to provide the security alias, rather than the
15full card details.
7
While simple from a technical perspective, relying on a credit/debit card may not be
suitable for operators whose prepaid subscribers are often “unbanked”5. In some
18markets prepaid “credit” cards may be suitable for these subscribers.
16
17
4.4.2 Connection to Prepaid System
19
4.4.2.1 Wired Internet Connectivity
20
The home operator may provide a website through which a subscriber can enter
22their account information (e.g. phone number) and recharge information. This is
23essentially a default option, with no direct mobile network involvement. While simple
24for the operator, it may not represent a convenient option for the roamer.
21
As an alternative, the home operator may work with one or more financial
26institutions in the home country to allow recharges direct from those institutions’
27internet banking sites. For subscribers with internet-enabled bank accounts, this
28addresses both the “recharge information” and “connection” stages in a single
29transaction.
25
4.4.2.2 Wireless Connectivity
30
If prepaid international packet data roaming is implemented between the two
32networks, an equivalent site may be available through the mobile’s browser. This
31
2
5
or "underbanked" - they do not have accounts at banks and other mainstream financial
institutions
3
4
Ref Doc 159, Ver 0.4
2009-06-01
31
Prepaid International Roaming
Terminology
1
may be a more cost-effective approach (in terms of the inter-operator charge
2absorbed by the home operator) than an equivalent voice-call.
1
4.4.2.3 Voice Call to Home Network IVR
3
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
6short code), is routed to a CSR or Interactive Voice Response (IVR) system, and
7provides their recharge information. The CLI (Calling Line Identity) may be used to
8identify the prepaid account to be credited.
4
5
When roaming internationally, the primary issue with this approach is the cost of the
10call. Assuming the subscriber will not be charged, the cost must be borne by the
11home operator, as the serving operator will view this as a normal international call to
12the home country. Use of a Universal International Freephone Number (UIFN), e.g.
13“+” 800 01234567, may help to reduce the cost. Failure to provide an ISUP answer
14signal (see §4.3.2) may not prove helpful in this case as the forward speech path
15might not be connected without an answer).
9
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
18a modified digit string to the serving network for routing.
16
17
The CLI may not be reliable due to the international call leg. The subscriber identity
20is however available via the trigger messages sent as part of normal prepaid
21originations. The SCP and IVR can communicate (effectively treating the IVR as an
22IP as per §3.4) to provide this information. Note that this call scenario is not explicitly
23shown in IS-826, however (since in this case the “pre-call announcement” is actually
24the final destination for the call).
19
4.4.2.4 Recharge via SMS
25
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
28-terminated) SMS international roaming is implemented between the home and
29serving operators, the subscriber could send their recharge information (e.g. scratch
30card number or credit card details/security alias) in an SMS to a short-code address
31determined by the home operator. The connection between the MC and SCP to
32effect the recharge is entirely within the control of the home operator, and can be
33the same as is used by subscribers while in their home network.
26
27
34
4.4.2.5 Local IVR
A more cost-effective approach than the call to a home network IVR described in
36§4.4.2.3 may be to call an IVR in the serving country. If the subscriber has
37purchased a local-network recharge card (as described in §4.4.1.1), the subscriber
35
2
Ref Doc 159, Ver 0.4
2009-06-01
32
Prepaid International Roaming
Terminology
1
would navigate the serving operator’s IVR in much the same way that one of that
2operator’s own subscribers would. A back-end connection would be required to the
3home operator’s prepaid system to effect the recharge, as well as an inter-operator
4settlement related to the purchased value. The subscriber would need to be
5identified as belonging to a different operator, through CLI (if correctly available)
6and/or explicit menu selections. The subscriber may not understand the language
7used for the IVR announcements.
1
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
10in §4.3.1, with equivalent challenges.
8
9
4.4.2.6 Third-party Network Connection
11
This approach combines both phases of the recharge action into a single step (at
least from the end-user’s perspective). The subscriber purchases credit at a third14party retail location in the visited country and provides their home network details
15and subscriber number. The third-party system then connects all the way to the
16home network prepaid system to credit the subscriber’s balance. Separately (and in
17the background), a payment is made from the third party to the home operator to
18cover the subscriber credit.
12
13
At least one such service known to exist today, in a limited deployment. Specific
20terminal capabilities may be required at the cooperating retail locations to enable
21“bill payment” to a company in another country.
19
22
4.4.3 Alternative Approaches
Several other methods are in use by operators (CDMA and/or GSM) today which
24essentially “work around” the recharge issue.
23
4.4.3.1 Temporary Conversion to Postpaid
25
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
28PSTN provider), the operator can arrange to pass the roaming charges on to the
29subscriber in a postpaid manner just like other roamers. Depending on operator
30choice, a provisioning change may not be necessary (instead just steer CIBER
31incollects to the postpaid account). Care would be required in this case when
32handling charges originating from the home network such as those for international
33call delivery and SMS.
26
27
2
Ref Doc 159, Ver 0.4
2009-06-01
33
Prepaid International Roaming
Terminology
1
4.4.3.2 Third Party Top-Up
1
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 the
4same operator, and who is currently in the home network. This third party uses the
5operator’s existing capability to add credit to someone else’s account to top up the
6roaming subscriber.
2
3
7
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
10they leave the country.
8
9
4.5 Signaling Link Occupancy and Message Length
11
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
14between the serving network and the service control residing in the home network.
12
13
In an international roaming scenario, a relatively small linkset may be used to carry
16all the operator’s roaming signaling traffic (typically connected to the RSP). A high
17proportion of prepaid subscribers among roamers may make a significant
18contribution to the load on these links. It is important to work through the
19dimensioning exercise before launching the service. The impact could be felt both
20by the home and serving operators.
15
The figures below provide an estimate of the additional signaling load, in octets per
22call, that may be expected due to MSC–to-SCP messaging for prepaid. Operators
23may combine these values with their expected prepaid roamer subscriber numbers
24and Busy-Hour Call Attempt figures to derive the actual signaling link impact.
21
The values shown in Table 5 -2 below assume the call flows as shown in §3, with
26no announcements. Further details on the derivation are given in the Appendix.
27Operators are strongly encouraged to validate these values with their own specific
28addressing and application implementations.
25
2
Call Type
Additional Signaling per call
Prepaid Originated Call
550 octets
Prepaid Terminated Call
250 octets
Ref Doc 159, Ver 0.4
2009-06-01
34
Prepaid International Roaming
Terminology
1
1
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
4require an additional 0.1 64 kbps signaling links based on 40% occupancy.
2
3
Inclusion of the TriggerAddressList parameter in the subscriber profile can add
6approximately 30 additional bytes to the message length (depending on address
7and trigger types included) for RegistrationNotification Return Results and other
8messages carrying the subscriber profile. If this inclusion causes the message from
9the HLR to exceed the maximum allowable length for the signaling medium, it will
10not be manifest as a roaming problem but rather an issue for an (assumed earlier)
11domestic deployment of the prepaid service.
5
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
14Global Title addressing). In this case the RSP and home operator would need to
15work together to identify parameters that could be safely removed from the
16message, or alternatively the message could be segmented if supported by both the
17RSP and serving network.
12
13
4.6 RSP support
18
For most CDMA-CDMA international roaming today, a Roaming Service Provider
20(RSP) is present in the ANSI-41 callflow. Prepaid roaming as described in this
21document does not require the presence of an RSP, however I if an RSP (or
22potentially multiple RSPs) is present between two operators who wish to deploy
23prepaid international roaming, certain capabilities will be required from the RSP. In
24addition, the RSP may be able to provide other optional services to simplify or
25enhance the service deployment.
19
In general, especially for early implementations, various differences in standards
interpretation can be expected between the equipment deployed by the home and
28serving operators. The RSP may have an important role to play to resolve some of
29these issues without major impacts to either operator.
26
27
For implementations without an RSP, this section may highlight potential
incompatibilities that must be resolved through other means (e.g. changes/upgrades
32to network elements, or the introduction of an “in-house RSP”, i.e. an ANSI-41
33mediation platform).
30
31
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
36this document can be deployed by operators who connect via an RSP.the basic
37message transport described in §4.6.1 and several related capabilities were
34
35
2
Ref Doc 159, Ver 0.4
2009-06-01
35
Prepaid International Roaming
Terminology
1
supported by at least one RSP in a recent upgrade. Operators considering prepaid
2roaming should contact their RSP(s) directly to determine the specifics of their
3offering.
1
4
4.6.1 Basic Message Transport
The RSP will be required to provide basic routing for the new messages introduced
6by IS-826-based prepaid service. Examples of the new messages include ANLYZD,
7OANSWER, CCDIR, etc.
5
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
10to determine the correct home network, and route the message on to the predefined
11or pre-stored address of the correct home network element. This behavior is
12equivalent to what RSPs do today for other ANSI-41 messages transferred between
13the home and serving networks.
8
9
14
4.6.2 Analysis and Modification of Embedded Address
As discussed in §3.2, the TriggerAddressList parameter contains the address of the
16SCP to which trigger messages are to be sent. When sent from the home network,
17this will be the home network address (PC/SSN or GTA) of the SCP, which may not
18be valid in the serving network. The RSP must read this value and replace it with a
19serving network address that points to the RSP itself before transferring the
20message to the serving network. In the reverse direction (i.e. when a trigger
21message is received), the RSP must remove its own address and reconstitute the
22originally received address. This modification of MTP/SCCP-layer address
23parameters embedded in the ANSI-41 layer is already performed by RSPs today to
24handle the SMS_Address parameter.
15
4.6.3 Identification of True Serving Network
25
For the SCP in the home network to be able to debit the subscriber’s balance at the
correct rate, it will likely need to know which operator is serving the subscriber (as
28different operators may charge different wholesale rates). Currently many home
29operators see only a single serving MSCID, representing the RSP. This simplifies
30the datafill required in the home network to roll out new roaming partners, and to
31accommodate network changes by existing partners.
26
27
A proposed middle ground is the use of “operator-level MSCID”, where each serving
operator’s entire network is represented by a single MSCID. This approach has
34been previously proposed for other services. Further investigation is required to
35determine whether it would be possible to retain the single MSCID for
36communication with the HLR (to retain the datafill advantages), but use the serving
32
33
2
Ref Doc 159, Ver 0.4
2009-06-01
36
Prepaid International Roaming
Terminology
1
operator-specific value for messages to the SCP. See §4.14 for one reason not to
2restrict the operator-specific MSCID only to the SCP.
1
Any MSCID consolidation may represent a challenge in a node failure/recovery
4scenario, e,g, when a MSC sends a BulkDisconnect message to advise the SCP(s)
5that all calls have ended. Care is required to avoid cancelling billing for calls at other
6MSCs.
3
7
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
10changing the value of an included parameter. These modifications may be
11“required” to address an implementation incompatibility between the home and
12serving networks, or may provide a “value-add” simplification or enhancement.
13Possible examples of this kind of modification include:
8
9
14
•
Mapping of Announcements: The AnnouncementCode sent from the home
SCP 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 network’s
capabilities. 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
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.1.
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
Ref Doc 159, Ver 0.4
2009-06-01
37
Prepaid International Roaming
Terminology
1
4.6.5 No Trigger Support
1
The RSP may choose to offer an alternative to IS-826, which could be used in the
3event that the serving network does not support the necessary triggers/operations.
4See §4.7.
2
4.6.6 Prepaid System Interconnectivity
5
The RSP may act as a central “hub” to simplify connections between different
7operator’s prepaid systems. This would be useful if for example the operators
8allowed subscribers to purchase each other’s recharge cards to account top-up –
9see §4.4.1.1. Such a connection would most likely be IP (Internet Protocol, not
10Intelligent Peripheral) –based, rather than using SS7 connectivity. This service does
11not build directly on known existing RSP functionality, but may bear some similarity
12to other services offered by RSP companies, e.g. inter-operator SMS hubbing.
6
4.7 Serving Network Trigger Support
13
A basic requirement for an IS-826-based service is that the network supports IS15826. As a starting point, a serving network that does not support the IS-826 triggers
16and related operations will not be a suitable (i.e. allowable) destination for an IS17826-based prepaid roaming subscriber. While actual implementations may throw up
18specific requirements, in general a serving network would be expected to support
19the scenarios shown in §3.
14
If a serving network does not support IS-826, it may be possible to fall back to a
21less-preferred implementation, e.g. the ANSI-41/WIN Phase 1 solution outlined in
22§2.4. An RSP may play a significant role here, replacing IS-826 triggers with ANSI2341/WIN alternatives in the subscriber profile, and potentially even hosting the
24associated Service Node. The fundamental issues of trunking inefficiency remain,
25however.
20
IS-826 does address the case of a serving network not supporting the necessary
27triggers, but only for a terminating call. In this scenario the answer and disconnect
28triggers are fired from the in-call MSC, since it sits in the call path. The case of an
29originating call is not addressed.
26
4.8 Inter-Operator Billing
30
Although the serving operator is processing a prepaid subscriber’s call in a different
manner to that of a post paid subscriber, the actual prepaid relationship exists
33between the subscriber and their home operator, not the serving operator. Inter34operator wholesale billing is therefore recommended to proceed in a similar manner
31
32
2
Ref Doc 159, Ver 0.4
2009-06-01
38
Prepaid International Roaming
Terminology
1
to post-paid calls today – via the use of a CIBER record generated after the call is
2complete, and sent as a non-real-time batch.
1
It will be important to identify pre-paid calls as such in the CIBER record. A specific
4value in the Special Features Used field and/or an indication in a field like the Toll
5Tariff Descriptor may be necessary. See §4.9.1 for discussion on a “successfully
6billed at SCP” indicator in the MSC CDR and CIBER record.
3
7
4.9 Failure Scenarios
This section describesd behavior in various cases where an expected signaling
message is not successfully exchanged.
8
9
4.9.1 Billing Integrity
10
The involvement of the WIN infrastructure provides an additional potential point of
12failure for a prepaid roaming call. Operators may choose to prioritize service
13availability (from the end-user’s perspective) over real-time account debit – i.e., if
14the SCP is not accessible when a call attempt is made, the operator may choose to
15allow the call, and “catch-up” billing later via the traditional postpaid method. Note
16that IS-826 suggests (but does not require) that the MSC disallow the call in this
17case.
11
In a roaming scenario, this choice will be made by the serving operator. The ability
to specify different behavior for the operator’s own subscribers versus inbound
20roamers will depend on the equipment vendor’s capabilities.
18
19
If the choice is made to allow the call to continue (or anyway, as a billing integrity
22check) it may be helpful to be able to distinguish billing records for calls that were
23billed by the SCP, from those that were not. Any non-billed call records can then be
24used to “catch up” and debit the subscriber balance. IS-826 includes the
25DMH_ServiceID parameter which is passed from the SCP to the MSC for the
26specific purpose of including it in the CDR. If this parameter is included (with a value
27chosen to represent “success”) in the odisconnect/tdisconnect message, and the
28value is incorporated into the CDR, then these tickets can be identified.
21
For this identification to be possible at the home operator, the DMH_ServiceID (or
30an indication derived from it) needs to be included in the CIBER record. The exact
31field to use is beyond the current scope of this document, however some potential
32locations include:
29
33
34
35
2
•
•
•
Special Features Used
Message Accounting Digits
Any of the various Filler fields.
Ref Doc 159, Ver 0.4
2009-06-01
39
Prepaid International Roaming
Terminology
1
Note that an alternative approach to billing integrity processes all call events
2received via CIBER against an output from the SCP of all calls it has billed, then
3acts on the mismatches.
1
4
4.9.2 Sanity Checks
IS-826 discusses the possibility of “runaway charging”, where the SCP does not
6receive a disconnect message, and continues to debit the subscriber’s balance after
7the call has ended. To address this, the use of a periodic “heartbeat CCDIR” is
8recommended by the standard. This CCDIR requests no action from the MSC other
9than to acknowledge that the call is still active.
5
4.9.3 Recovery Procedures
10
IS-826 contains a detailed discussion of recovery from various forms of network
12node failure. The procedures described are generally assumed to be applicable to
13the international roaming case without further modification, although there may be
14some complexity introduced with an RSP architecture..
11
4.10 SMS
15
[IS-826-A] describes procedures for pre-paid billing of SMS (note that this is really
an addendum to IS-826, not a complete revision). This standard defines the
18ShortMessageAnalyzed message sent from the MC to a SCP or SN to check/debit
19the subscriber balance before processing/delivering a short message further. Use
20of this message is not believed to be widespread, however a number of operators
21have implemented an equivalent check over IP transport from the MC to the Prepaid
22Application Server.
16
17
In either case (explicitly for IS-826-A), the mechanism relies on the use of Indirect
24Routing for Mobile-Originated SMS, where the message is sent from the originator’s
25serving MSC to the originator’s (home) MC. Indirect Routing is already the
26recommended approach for international roaming SMS (see CDG Reference
6
27Document 133 ), and is the typical implementation by operators.
23
Assuming Indirect Routing is in place, there are no additional requirements (e.g.
trigger support, over and above those for postpaid SMS roaming) on the serving
30network to support prepaid SMS – query/debit/authorization takes place entirely
31within the home network. Care may be required with timers in the serving network –
32see §4.15.
28
29
If the home operator wishes to debit the subscriber balance by an amount that
34depends on the subscriber’s location (e.g. for MO-SMS, where different serving
33
2
6 http://www.cdg.org/members_only/refdocs/133.zip
Ref Doc 159, Ver 0.4
3
2009-06-01
40
Prepaid International Roaming
Terminology
1
operators charge a different intercarrier settlement rate per SMS), then the MC
2needs to know the subscriber’s serving network. The same issue applies for
3postpaid SMS roaming, and although solutions have been defined (see the CDG
7
4wiki ) at the time of writing they have typically not been widely deployed.
1
4.11 Prepaid Data
5
Prepaid Data is out of scope for this document. Specific issues may be raised with
the PaDIRT (Packet Data International Roaming Team) group within the CDG.
6
7
For reference, some standards documents address prepaid data:
8
9
•
[IS-826-A] includes procedures for circuit-switched data. Little interest is
expected in deploying these, although the differences from standard IS-826
callflows are not major.
•
[IS-835.006] defines prepaid packet data services. In general, the “Prepaid
Client in the HA” option described in this document has been endorsed by
PaDIRT as the preferred approach for Mobile IP prepaid data roaming, as it
minimizes impacts on the serving network.
10
11
12
13
14
15
4.12 Time Zones
16
When the serving network rates a call (e.g. in postpaid roaming), it is relatively
18simple to determine the correct time, and apply the appropriate rate (e.g. peak, off19peak). In a prepaid scenario, the call is rated in the home network. For international
20roaming, the home and serving networks are likely to be in different timezones.
17
IS-826 provides the TimeOfDay (TOD) and TimeDateOffset (TDO) parameters,
22which can be transferred from the serving network to the home network SCP in
23various trigger messages. In several cases they are mandatory parameters in the
24messages.
21
It is recommended that rating uses these parameters (rather than a local time at the
26SCP) to provide greater accuracy (e.g. a subscriber making a call just before peak
27rate began may erroneously be charged peak rate by the SCP due to a transport
28delay of a few seconds) and simplicity in rating (can import the serving carrier’s rate
29plan without having to make the conversion to own timezone). If the service allows
30the subscriber to view the calls they made (e.g. over the web, or a monthly
31statement), providing subscriber-local time is likely to be more user-friendly, and is
32presumably easier if the TOD/TDO parameters are used at the SCP.
25
2
7 http://wiki.cdg.org/wiki/SMS_Roaming#SMS_Billing
Ref Doc 159, Ver 0.4
3
2009-06-01
41
Prepaid International Roaming
Terminology
1
4.13 Emergency Calls
1
An important consideration for any prepaid implementation (not just roaming) is the
need to allow a credit-expired subscriber to make an emergency call. IS-826/771
4provides two options for an emergency call:
2
3
5
•
Process the call locally, avoiding all triggers
6
•
Fire the Locally_Allowed_Specific_Digit_String trigger (statically defined in
the MSC) which allows for WIN handling of emergency type calls.
7
In the international roaming case, the home network SCP should not be triggered for
9emergency calls. Triggering to a serving-network SCP is possible (e.g. to trigger
10some location-based routing to an appropriate answer point) – prepaid roamers
11should be treated no differently to postpaid inbound roamers.
8
In some cases serving networks define other countries’ emergency numbers in their
13roamer dialplan, and convert them to the correct local code. Office data
14configuration may be required to identify these additional dial patterns as “locally
15allowed”.
12
4.14 Subscriber Provisioning
16
No special provisioning settings should be required for prepaid international
roaming. For an operator with an existing IS-826-based prepaid service, and
19existing outbound international roaming, the required provisioning will be a
20combination of both services.
17
18
In the absence of a prepaid international roaming service, prepaid subscribers are
typically prevented from roaming. The mechanism employed is operator-specific,
23but would typically involve some “white-list” of allowed MSCIDs. Changes to the
24provisioning system business rules would be required to allow prepaid subscribers
25to roam.
21
22
It is likely that initially only a subset of an operator’s roaming partners will be able to
27provide prepaid roaming to the operator’s subscribers. Roaming for prepaid
28subscribers should therefore be restricted to only these networks. The operator-level
29MSCID described in §4.6.3 could be used at the HLR to restrict roaming on a per30network basis. Alternatively the RSP could provide the resolution (e.g. by denying
31registration from a network previously known (or determined at registration time via
32WINCAP) not to support the necessary capabilities for prepaid. See §4.6.4.
26
2
Ref Doc 159, Ver 0.4
2009-06-01
42
Prepaid International Roaming
Terminology
1
4.15 Timer Expiry
1
IS-826 defines various timers which are set against the different trigger messages.
In an international roaming scenario there may be additional delays inherent in the
4signaling path, and due to processing by additional entities (e.g. an RSP), that can
5lead to a message response arriving too late to stop the timer expiring. While timers
6are defined to address the case where a message gets “lost”, the particular scenario
7possible due to excessive delay is that a message is received by one entity while
8the sender believes that it hasn’t been received.
2
3
Care is required in the implementation phase to measure the delay experienced,
10and ensure that time values are set appropriately. Incorrect values may result in
11unnecessary call failures for the subscriber, and/or additional signaling load due to
12retransmissions. Procedures should be put in place to ensure that a delayed
13response does not result in a runaway call or charging event (see §4.9).
9
SMS is a service that may be particularly affected, as the SMTnetwork timer for a
roamer-originated SMS may expire due to a “dip” into the prepaid system at the MC
16before sending an smdpp to the MSC.
14
15
The values listed in the standard are explicitly identified as default values only, that
18“should be optimized for actual operating environments”. The actual flexibility
19available to an operator (particularly any ability to specify different values for
20domestic and international subscribers) will depend on the equipment vendor.
17
2
Ref Doc 159, Ver 0.4
2009-06-01
43
Prepaid International Roaming
Terminology
1
1
5 Commercial and Other Issues
In general, prepaid is a service which tightly integrates commercial and network
3concerns. Nevertheless, some items can be reasonably separated:
2
4
5.1 Roaming Agreement
Discussions held to date (Sep 2007) in the IRT have not yet reached a conclusive
position on the impact of prepaid service on existing roaming agreements. As noted
7in §4.8, at a wholesale level the existing billing processes will remain – from a
8contract perspective prepaid could potentially be viewed as merely another service
9that is provided by the serving operator to the home operator’s subscribers.
10Provided that MSC CDRs for prepaid calls can be identified (see §4.9.1), it would be
11technically feasible for the serving operator to charge a different rate for prepaid
12calls to reflect the additional processing requirements.
5
6
In a postpaid scenario, the home operator’s retail billing is based directly off the
information (i.e. CIBER records) used for the wholesale (inter-carrier) charging: if
15the serving network for some reason does not provide billing records (e.g. a fault in
16their billing system) then both the subscriber and the home network are not charged.
17In prepaid, the retail and wholesale charging are separated. It may be possible for
18the serving network to mishandle the triggering requirements, but still allow (and
19charge the home operator for) the call (see §4.9.1). Now the home operator may not
20be able to recover the charge from the end subscriber. Some additional text may be
21warranted in the roaming agreement to address this situation
13
14
22
5.2 Recharge Agreements
If operators agree to allow the use of each other’s recharge cards (see §4.4.1.1), a
mechanism is required for monetary transfer between the operators. One option
25may be to use the existing roaming settlement arrangement between the operators,
26and apply the prepaid credit purchase as an adjustment to the operators’ net
27position.
23
24
If a third party is used to handle the recharge purchase as in §4.4.2.6, the payment
29arrangements can be made between this entity and the home operator directly,
30without any roaming involvement.
28
2
Ref Doc 159, Ver 0.4
2009-06-01
44
Prepaid International Roaming
Terminology
1
Subscribers may be used to having the credit instantly applied to their account when
2using a recharge card. To match that experience when roaming the home operator
3would potentially have to apply the credit before receiving payment for the recharge
4purchase from the serving operator or third party.
1
2
Ref Doc 159, Ver 0.4
2009-06-01
45
Prepaid International Roaming
Terminology
1
6 Operator Recommendations
1
This section aims to summarize the earlier discussion into some concise
3recommendations for operators. In general, the recommended approaches aim for
4simplicity and ease of implementation, rather than richness of service experience.
5They are aimed at an initial deployment of a challenging new service.
2
These recommendations should not be seen as restricting an operator from working
7to implement, or insisting on before launch, a fuller feature set for their subscribers.
6
8
•
Deploy an IS-826-based service. This has been identified by the IRT as the
preferred approach for CDMA prepaid international roaming
•
Use tones and not announcements for subscriber information. This
represents the simplest approach for international deployments.
•
CPP operators should pursue HLR modifications to minimize the
impact of terminating call charges for roamers. While reliant on vendor
changes, this option is believed to have the least impact on the home
operator’s network. Note that no changes are proposed to existing interoperator charging for roamer-terminating calls (e.g. “airtime charge”).
•
Decide on Recharge options. Operators must choose a recharge option or
set of options that best matches their business processes, Roaming Partner
relationships and subscriber demographics. However from a purely technical
standpoint using SMS to provide credit/debit card details or alias to the home
network would appear to represent the least deployment effort while still
retaining reasonable convenience for subscribers.
•
Serving operator does not permit a chargeable call to continue without
SCP control. Ideally this scenario should not occur at all. The recommended
approach may have a negative impact on the subscriber, but is the simplest
to implement and has fewer flow-on impacts on billing records.
•
Ensure that all emergency codes allowed bypass call triggers. This
ensures that out-of-credit subscribers will still be able to contact emergency
services if needed.
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
2
Ref Doc 159, Ver 0.4
2009-06-01
46
Prepaid International Roaming
Terminology
1
7 Terminology
1
2
ANLYZD
AnalyzedInformation
CCDIR
CallControlDirective
CDG
CDMA Development Group
CLI
Calling Line Identity
CMS
Card Management System
CONNRES
ConnectResource
CPP
Calling Party Pays
CSR
Customer Service Representative
DP
Detection Point
DRRR
Direct Routing Roamer-to-Roamer
GTA
Global Title Address
HLR
Home Location Register
INSTREQ
InstructionRequest
IP
Intelligent Peripheral
IRT
International Roaming Team
ISUP
Integrated Services Digital Network User Part
IVR
Interactive Voice response
locreq
LocationRequest RETURN RESULT
LOCREQ
LocationRequest INVOKE
MS
Mobile Station
Ref Doc 159, Ver 0.4
2009-06-01
47
Prepaid International Roaming
Terminology
1
2
MSC
Mobile Switching Center
MSCID
MSC Identification
MSID
Mobile Station Identity
MTP
Message Transfer Part
PaDIRT
Packet Data International Roaming Team
PC
Point Code
REGNOT
RegistrationNotification
ROUTREQ
RoutingRequest INVOKE
routreq
RoutingRequest RETURN RESULT
RSP
Roaming Service Provider
R-UIM
Removable User Identity Module
SCCP
Signaling Connection Control Part
SCP
Service Control Point
SEIZERES
SeizeResource
SN
Service Node
SRF
Specialized Resource Function
SRFDIR
SRFDirective
SS7
Signaling System Number 7
SSN
SubSystem Number
TAL
Trigger Address List
TCAP
Transaction Capabilities Application Part
TDO
TimeDateOffset
TDS
Technical Data Sheet
TLDN
Temporary Local Directory Number
Ref Doc 159, Ver 0.4
2009-06-01
48
Prepaid International Roaming
Terminology
1
TOD
TimeOfDay
TRIGADDRLIST TriggerAddressList
UIFN
Universal International Freephone Number
VLR
Visitor Location Register
VSWG
Voice & SMS Working Group
WIN
Wireless Intelligent Network
1
2
Ref Doc 159, Ver 0.4
2009-06-01
49
1
8 References
1
2
[IS-826]
3GPP2 N.S0018-0 (TIA IS-826). TIA/EIA-41-D Pre-Paid Charging.
v1.0. July 2000.
http://www.3gpp2.org/Public_html/specs/NS0018Re.pdf
[IS-771]
3GPP2 N.S0013-0 (TIA IS-771). WIN Phase 1. v1.0. December
1998. http://www.3gpp2.org/Public_html/specs/N.S0013-0_v1.0.pdf
[IS-826-A]
3GPP2 X.S0010-A (TIA IS-826-A). Pre-Paid Charging
Enhancements for Circuit-Switched Data and Short Message
Services. v1.0. January 2004.
http://www.3gpp2.org/Public_html/specs/X.S0010A_v1.0_010504.pdf
[IS-835.006]
3GPP2 X.S0011-006-D (TIA IS-835.006-D). cdma2000 Wireless IP
Network Standard: PrePaid Packet Data Service. v1.0. February
2006. http://www.3gpp2.org/Public_html/specs/X.S0011-006D_v1.0_060301.pdf
Ref Doc 159, Ver 0.4
2009-06-01
50
Prepaid International Roaming
Terminology
1
9 Appendix
1
2
9.1 Signaling Link Occupancy Calculations
The following discussion provides details of the derivation of the figures presented in
§4.5.
3
4
Originating Call:
5
Calculating only for the MSC → SCP direction, as this is impacted most heavily:
6
Consider ORREQ, ANLYZD, OANSWER and ODISCONNECT messages. Message
sizes are taken from the sample trace available at
9http://wiki.cdg.org/wiki/Image:Prepaid_1_clean_tcap.TXT , rounded for simplicity. In
10each case the MTP/SCCP size is estimated at ~30 octets (ITU, one-way GT with
1110-digit address). The sizes below include all signaling layers:
7
8
12
13
14
15
ORREQ: 150 octets
ANLYZD: 150 octets
OANSWER: 100 octets
ODISCONNECT: 150 octets
Terminating Call:
16
A terminating call has only the TANSWER and TDISCONNECT messages (on the
serving MSC → SCP leg). Sizes are estimated as the same as the OANSWER and
19ODISCONNECT counterparts.
17
18
Comments:
20
For the total additional international roaming signaling load in one direction, an
operator with bilateral prepaid roaming would have to consider (e.g. for the sending
23direction) both the MSC → SCP load for inbound roamers, and the SCP → MSC
24load for outbound roamers. Frequent CCDIR “heartbeat” messages (see §4.9.2)
25could potentially make the sending direction for outbound roamers significant.
21
22
Sample Calculations:
26
27
2000 subscribers
1 originating, 0.2 terminating calls per subscriber in the busy hour.
28
2
Ref Doc 159, Ver 0.4
2009-06-01
51
Prepaid International Roaming
Terminology
1
Additional busy hour bits = 2000 * 8 * (1 * 550 + 0.2 * 250) = 9600000 bits
1
2
Additional busy hour bits/second = 9600000 / 3600 = 2667 bps
Link capacity = 64000 * 0.4 = 25600 bps
3
4
New links required = 2667 / 25600 ≈ 0.1 links
2
Ref Doc 159, Ver 0.4
2009-06-01
52
[...]... 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... 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 http://wiki.cdg.org/w/images/2/26/PrepaidSurvey1Results.xls Ref Doc 159, Ver 0.4 3 2009-06-01 11 Prepaid International. .. and application implementations 25 2 Call Type Additional Signaling per call Prepaid Originated Call 550 octets Prepaid Terminated Call 250 octets Ref Doc 159, Ver 0.4 2009-06-01 34 Prepaid International Roaming Terminology 1 1 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... 12 13 4.6 RSP support 18 For most CDMA-CDMA international roaming today, a Roaming Service Provider 20(RSP) is present in the ANSI-41 callflow Prepaid roaming as described in this 21document does not require the presence of an RSP, however I if an RSP (or 22potentially multiple RSPs) is present between two operators who wish to deploy 2 3prepaid international roaming, certain capabilities will be required... 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. .. selected options will depend on the ease of implementation, the demographics 31of the individual operators’ prepaid roaming subscribers, and the willingness of key 3 2Roaming Partners to integrate solutions in their own networks 28 29 2 Ref Doc 159, Ver 0.4 2009-06-01 28 Prepaid International Roaming Terminology 1 4.4.1 Obtaining Recharge Information 1 2 4.4.1.1 Recharge Card Purchase This is believed... 29transaction 25 4.4.2.2 Wireless Connectivity 30 If prepaid international packet data roaming is implemented between the two 32networks, an equivalent site may be available through the mobile’s browser This 31 2 5 or "underbanked" - they do not have accounts at banks and other mainstream financial institutions 3 4 Ref Doc 159, Ver 0.4 2009-06-01 31 Prepaid International Roaming Terminology 1 may be a more cost-effective... 159, Ver 0.4 2009-06-01 35 Prepaid International Roaming Terminology 1 supported by at least one RSP in a recent upgrade Operators considering prepaid 2roaming should contact their RSP(s) directly to determine the specifics of their 3offering 1 4 4.6.1 Basic Message Transport The RSP will be required to provide basic routing for the new messages introduced 6by IS-826-based prepaid service Examples of... 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... 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,