Prepaid International Roaming

1 2 1 Prepaid International Roaming 2 CDG Document 159 3 Version 0.4 4 2009-06-01 5 6 7 8 9 10 11 12 13 CDMA Development Group 575 Anton Boulevard, Suite 560 Costa Mesa, California 92626 PHONE +1 888 800-CDMA +1 714 545-5211 FAX +1 714 545-4601 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,