System and method for determining tariffs for real-time calls involving ported directory numbers

Technical Field of the Invention

0001This invention relates to telecommunication systems. More particularly, and not by way of limitation, the present invention is directed to a system and method of determining tariffs for wireless calls made to or from ported directory numbers.

Description of Related Art

0002Today, each wireless network operator has its own number series of Mobile Station Integrated Services Digital Network (MSISDN) numbers, referred to herein as directory numbers (DNs). A particular operator can easily tell which subscribers are its own subscribers, and which subscribers belong to other operators, by simply determining whether each subscriber's DN falls within the particular operator's number series. Because the wireless operators can tell which subscribers are their own, the operators typically set up different tariffs for calls between two or more of their own mobile subscribers, between one of their own mobile subscribers and a landline subscriber, or between one of their own subscribers and a mobile subscriber belonging to another wireless operator. For example, one tariff level (T1) may apply to in-network mobile-to-mobile calls between mobile subscribers who subscribe to a particular operator's services. A second tariff level (T2) may apply to calls that are from a landline subscriber to a mobile subscriber who subscribes to the particular operator's services and is operating within the operator's own network. A third level (T3) may apply to inter-network calls from a mobile subscriber in another operator's network towards a mobile subscriber who subscribes to the particular operator's services and is operating within the operator's own network. The operators have rating tables set up for calling numbers and called numbers so they can determine which tariff to set up.

0003When a call is set up as a prepaid call, or some other service requiring real-time billing, the operator uses the tariff derived from the rating table and deducts money from a prepaid account in real time as the call progresses. If the prepaid account is depleted while the call is still in progress, the operator may terminate the call. For other calls which are not billed in real time (i.e., post-paid calls), call data records (CDRs) are generated after the call is completed, and are sent to a billing center for processing.

0004Local Number Portability (LNP) (i.e., service provider portability) allows mobile subscribers to retain their directory numbers as the subscribers "port" from one service provider to another. In other words, a subscriber who initially obtains his service from Operator-A, and is provided with a DN within Operator-A's number series, may subsequently change his service to another operator such as Operator-B, and still retain the original DN. Since this subscriber continues to operate with a DN in Operator-A's number series, Operator-B cannot utilize the calling DN or called DN to determine the applicable tariff when the subscriber makes a real-time call such as a prepaid call. For example, if the subscriber above, who is ported-in to Operator-B's network, calls another mobile subscriber who subscribes to Operator-B's services and is operating within Operator-B's own network, the call should be charged at the T1 rate. However, by using the existing rating table, Operator-B would charge the call at the T3 rate because the ported subscriber would appear to be from Operator-A's network.

0005For post-paid calls, an LNP database is queried prior to the generation of the CDRs to determine whether the calling DN or called DN involved in a call have been ported. When one of the numbers has been ported, the CDRs indicate that fact, and the operators are then able to use their existing rating tables to determine the proper tariff, and to apply the tariff in the post processing, However, for calls requiring real-time billing, the rating using the current methodology will not be correct because the rating of the prepaid call takes place before the LNP database is queried.

0006In order to overcome this problem, it would be advantageous to have a system and method of determining in real time during call setup, when ported numbers are involved in a call. The present invention provides such a system and method.

0007<patcit id="pcit0001" dnum="WO0019702A"><text>WO 00/19702</text></patcit> refers to the provision of a prepaid service in a communications system. A user is provided with an individual code that he enters after initiating a call between the telephone terminal and a prepaid calling service. A database record that is related to the individual code is retrieved from a database, If any balance on the user account is left, the call is triggered to the desired destination number, otherwise it is disconnected. Costs for the call are dynamically charged from the account dedicated to the individual code. The user is dynamically informed about the remaining calling time and/or balance.

SUMMARY OF THE INVENTION

0008In one aspect, the present invention is directed to a method of determining a tariff for a real-time wireless service provided for a wireless telephone call. The method includes the steps of determining during call setup whether the call is made to or from a ported telephone number, and if so, determining whether the ported telephone number points to a particular network. If the ported telephone number points to the particular network, the call is rated with a first tariff. If the ported telephone number does 30 not point to the particular network, the call is rated with a second tariff.

0009In another aspect, the present invention is directed to a method of determining a tariff for a real-time wireless service provided for a wireless call made to or from a ported telephone number. The method includes receiving, by real-time service scripts, a call setup message formatted in a first signaling protocol and containing a called party number. The called party number is sent to a protocol converter where the first signaling protocol is converted to a second signaling protocol compatible with a Local Number Portability (LNP) database. This is followed by sending a query containing the called party number from the protocol converter to the LNP database, and receiving a query result from the LNP database. The result, which contains a routing number if the called party number has been ported, is returned to the service scripts. The service scripts then determine whether the routing number points to a particular network, and if so, the call is rated with a first tariff. If not, the call may be rated with a second tariff.

0010In yet another aspect, the present invention is directed to a system in a radio telecommunications network for determining a tariff for a real-time wireless service provided for a wireless telephone call. The system includes means for accessing an LNP database during call setup to determine whether the call is made to or from a ported telephone number; means for determining whether the ported telephone number points to a particular network, in response to a determination that the call is made to or from a ported telephone number; and means for assigning a tariff to the call in response to a determination that the call is made to or from a ported telephone number, and in response to a determination that the ported telephone number points to a particular network.

0011In still yet another aspect, the present invention is directed to a Service Control Point (SCP) in a telecommunications network. The SCP includes service scripts that implement a real-time service. The scripts include means for receiving a call setup message containing a called party number, and means for sending rated events to a Service Data Point (SDP) for assigning a tariff to a call. The tariff may vary if the called party number is ported-in or ported-out of a particular network. The SCP also includes an interface that receives the called party number from the service scripts and sends a query message containing the called party number to an LNP database. The interface also receives a query result from the LNP database containing a routing number if the called party number is ported, and passes the routing number to the service scripts. The means for sending rated events to the SDP then sends an indication to the SDP of whether the called party number is ported-in or ported-out of the particular network.

0012In still yet another aspect, the present invention is directed to service logic for implementing a real-time service in a telecommunications network. The service logic includes means for receiving a call setup message containing a called party number, and means for sending the called party number to an interface with an LNP database, and for receiving a routing number from the interface if the LNP database reports that the called party number is ported. The service logic also includes means for sending rated events to an SDP for assigning a tariff to the call, the tariff varying if the called party number is ported-in or ported-out of a particular network. The means for sending rated events notifies the SDP whether the called party number is ported-in or ported-out of the particular network, or whether the called party number is an un-ported number that belongs to the particular network or another network.

BRIEF DESCRIPTION OF THE DRAWINGS

0013The invention will be better understood and its numerous objects and advantages will become more apparent to those skilled in the art by reference to the following drawings, in conjunction with the accompanying specification, in which: <ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">FIG. 1</figref> is a simplified block diagram of a plurality of interconnected telecommunications networks in which the system of the present invention has been implemented;</li><li><figref idref="f0002">FIG. 2</figref> is a simplified block diagram of a first embodiment of the system of the present invention when handling a mobile origination and forwarding traffic case;</li><li><figref idref="f0002">FIG. 3</figref> is a simplified block diagram of the first embodiment of the system of the present invention when handling a mobile termination traffic case;</li><li><figref idref="f0003">FIG. 4</figref> is a simplified block diagram of a second embodiment of the system of the present invention when handling a mobile origination and forwarding traffic case; and</li><li><figref idref="f0003">FIG. 5</figref> is a simplified block diagram of the second embodiment of the system of the present invention when handling a mobile termination traffic case.</li></ul>

DETAILED DESCRIPTION OF EMBODIMENTS

0014The present invention enables wireless system operators to correctly charge for and switch prepaid calls to mobile subscribers with numbers that have been ported using LNP. The invention can be used in a multi-vendor network with multi-vendor Mobile Switching Centers/Service Switching Points (MSC/SSFs) and/or Home Location Registers (HLRs). The invention can be used with any prepaid or other real-time service.

0015The invention allows the operators to determine tariffs in real time, even when one or more of the DNs involved in the call is ported. The invention enables the operators to continue to provide different tariff rates for different types of calls (for example, mobile-to-mobile calls, landline-to-mobile calls, etc.), thereby stimulating more calls of a desirable type.

0016<figref idref="f0001">FIG. 1</figref> is a simplified block diagram of a plurality of interconnected telecommunications networks in which the system of the present invention has been implemented. A wireless operator's Own Network 10, a wireless Cooperating Network 11, the landline Public Switched Telephone Network (PSTN) 12, and an LNP Database 13 are shown, although a greater or lesser number of interconnected networks could be utilized. A number of standard network components are illustrated along with the new components provided by the present invention. Within the Cooperating Network are Mobile Switching Centers (MSCs) 14-16 and Signal Transfer Points (STPs) 17 and 18. The STPs interconnect the Cooperating Network 11 with the wireless operator's Own Network 10 through STPs 19 and 20 within the Own Network.

0017Also located within the Own Network 10 are an MSC/SSF 21, a Prepaid Service-Service Data Point (PPS SDP) 22, and a modified Service Control Point (SCP) 23. The PPS SDP includes modified rating structures (data requirements only) for implementation of the present invention. An Application Server 24 is also illustrated, and in some networks, modified Prepaid Service Logic (PSL) Scripts 25 within the Application Server are utilized along with a new Local Number Portability Point (LNPP) 26 in the modified SCP to implement the new functionality introduced by the present invention. In another embodiment, the new functionality introduced by the present invention may be implemented utilizing modified PPS Service Scripts 27 in the SCP, along with the LNPP 26. In this embodiment, the Application Server is not required.

0018In the present invention, the LNPP 26 functions as an interface and protocol converter, enabling either the PPS Service Scripts 27 or the PSL Scripts 25, depending on the network configuration, to communicate with the LNP Database 13 in real time during call setup to support real-time rating for prepaid and other real-time services. Currently, when a prepaid service is invoked, operators have no indication whether the calling or called DNs are ported numbers. With the present invention, operators can do a port on the calling number or the called number, depending on the call case, within the prepaid context.

0019<figref idref="f0002">FIG. 2</figref> is a simplified block diagram of a first embodiment of the system of the present invention when handling a mobile origination and forwarding traffic case. In this embodiment, modified PPS Service Scripts 27 within the SCP 23 are utilized along with the new LNPP 26 to implement the new functionality introduced by the present invention. The LNPP 26 is preferably implemented in the SCP 23, but may also be implemented in another node such as the PPS SDP 22 which communicates with the PPS Service Scripts 27 or the PSL Scripts 25.

0020During call setup, the MSC/SSF 21 sends a CS1+ Initial Detection Point (IDP) message 31 or a CAMEL Application Part (CAP) v2 CAP Initial Detection Point (CIDP) message to the SCP 23 where the message is received by the PPS Service Scripts 27. The Call State-1 (CS1) protocol is described in ITU-T Recommendation Q.1218, which is hereby incorporated by reference herein in its entirety. An enhanced version (CS1+) is utilized herein to carry additional message parameters to implement the functionality of the present invention. The IDP message contains the MSISDN of the PPS subscriber and the Called Party Number (CdPN).

0021The PPS Service Scripts send a CS1+ Retrieve-Invoke (R-I) message 32 to the LNPP 26 with the CdPN that potentially has been ported. The LNPP converts the CS1+ protocol to a protocol recognized by the LNP Database 13 such as an ANSI-41 interface, an 800 interface, or an INAP interface. The LNPP then sends a query 33 to the LNP Database 13 containing the CdPN received in the Retrieve-Invoke message. The LNP Database returns a query result 34 to the LNPP. If the CdPN has been ported, the query result contains a routing number (RN). If no RN is received, it is assumed that the CdPN has not been ported. The LNPP converts the protocol and sends a CS1+ Retrieve-Result (R-R) message 35 back to the PPS Service Scripts with the RN as an optional parameter.

0022Based on the LNP Database query result received in the R-R message 35 from the LNPP, the PPS Service Scripts 27 determine a prefix 36 used to identify whether the call is within the operator's Own Network 10, or in another network. The prefix values are operator definable. Exemplary prefix values are shown below in Table 1. <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1</title><tgroup cols="2"><colspec colnum="1" colname="col1" colwidth="14mm" /><colspec colnum="2" colname="col2" colwidth="71mm" /><thead><row><entry valign="top">Prefix</entry><entry valign="top">Description</entry></row></thead><tbody><row><entry rowsep="0">xx</entry><entry rowsep="0">RN received, RN pointing to own network</entry></row><row><entry /><entry>(i.e., ported in)</entry></row><row><entry rowsep="0">yy</entry><entry rowsep="0">RN received, RN pointing to other network</entry></row><row><entry /><entry>(i.e., ported out)</entry></row><row><entry>xx</entry><entry>RN not received, CdPN belongs to own network</entry></row><row><entry>yy</entry><entry>RN not received, CdPN belongs to other network</entry></row></tbody></tgroup></table></tables>

0023The existing PPS Service Scripts may be modified to add the correct prefix to an Originating Location Information parameter (or Terminating Location Information, depending on the traffic case) that is sent as part of each rated event (for example, First Interrogation, Intermediate Interrogation, or Final Report of Set Up USSD Call Back) to the PPS SDP 22 for rating. The prefix for an RN that is ported in, and the prefix for an un-ported CdPN that belongs to the Own Network may be the same if the operator desires the rating to be the same for these cases. Likewise, the prefix for an RN that is ported out, and the prefix for an un-ported CdPN that belongs to the other network may be the same if the operator desires the rating to be the same for these cases. After rating the call in the PPS SDP, the PPS Service Scripts 27 continue normal prepaid call processing with the prefix 36 in the Originating Location Information taken into account.

0024If the Location Information is not present in the Call Instance Data, the parameter is created and contains only the prefix. In addition to these changes, the Originating/Terminating Location Information is added to the Call Data Record (CDR).

0025<figref idref="f0002">FIG. 3</figref> is a simplified block diagram of the first embodiment of the system of the present invention when handling a mobile termination traffic case. In the mobile termination case, the call enters the system through a Gateway MSC/SSF (GMSC/SSF) 41 which sends a CS1+ IDP or CIDP message 31 to the SCP 23 where the message is received by the PPS Service Scripts 27. The IDP message contains the MSISDN of the PPS subscriber and the CdPN.

0026The PPS Service Scripts send a CS1+ Retrieve-Invoke (R-I) message 32 to the LNPP 26 with the CdPN that potentially has been ported. The LNPP converts the CS1+ protocol to a protocol recognized by the LNP Database 13 such as an ANSI-41 interface, an 800 interface, or an INAP interface. The LNPP then sends a query 33 to the LNP Database 13 containing the CdPN received in the Retrieve-Invoke message. The LNP Database returns a query result 34 to the LNPP. If the CdPN has been ported, the query result contains an RN. If no RN is received, it is assumed that the CdPN has not been ported. The LNPP converts the protocol and sends a CS1+ Retrieve-Result (R-R) message 35 back to the PPS Service Scripts with the RN as an optional parameter. Based on the LNP Database query result received in the R-R message 35 from the LNPP, the PPS Service Scripts 27 determine the prefix 36 used to identify whether the call is within the operator's Own Network 10, or in another network. Exemplary prefix values are shown above in Table 1.

0027The PPS Service Scripts 27 add the correct prefix to a Terminating Location Information parameter that is sent as part of each rated event (for example, First Interrogation, Intermediate Interrogation, or Final Report of Set Up USSD Call Back) to the PPS SDP 22 for rating. After rating the call in the PPS SDP, the PPS Service Scripts continue normal prepaid call processing with the prefix 36 in the Terminating Location Information taken into account.

0028<figref idref="f0003">FIG. 4</figref> is a simplified block diagram of a second embodiment of the system of the present invention when handling a mobile origination and forwarding traffic case. In this embodiment, modified PSL Scripts 25 within the Application Server 24 are utilized along with the new LNPP 26 in the modified SCP to implement the new functionality introduced by the present invention.

0029The MSC/SSF 21 sends a CS1+ IDP or CIDP message 51 to the Application Server 24 where the message is received by the PSL Scripts 25. The IDP message contains the MSISDN of the PPS subscriber and the CdPN. The PSL Scripts send a CS1+ Retrieve-Invoke (R-I) message 52 to the LNPP 26 in the SCP 23 with the CdPN that potentially has been ported. The LNPP converts the CS1+ protocol to a protocol recognized by the LNP Database 13 such as an ANSI-41 interface, an 800 interface, or an INAP interface. The LNPP then sends a query 53 to the LNP Database 13 containing the CdPN received in the Retrieve-Invoke message.

0030The LNP Database returns a query result 54 to the LNPP. If the CdPN has been ported, the query result contains an RN. If no RN is received, it is assumed that the CdPN has not been ported. The LNPP converts the protocol and sends a CS1+ Retrieve-Result (R-R) message 55 back to the PSL Scripts 25 in the Application Server with the RN as an optional parameter. Based on the LNP Database query result received in the R-R message 55 from the LNPP, the PSL Scripts determine a prefix 56 used to identify whether the call is within the operator's Own Network 10, or in another network. Exemplary prefix values are shown above in Table 1.

0031The PSL Scripts 25 add the correct prefix to an Originating Location Information parameter that is sent as part of each rated event (for example, First Interrogation, Intermediate Interrogation, or Final Report of Set Up USSD Call Back) to the PPS SDP 22 for rating. After rating the call in the PPS SDP, the PSL Scripts continue normal prepaid call processing with the prefix 56 in the Originating Location Information taken into account.

0032<figref idref="f0003">FIG. 5</figref> is a simplified block diagram of the second embodiment of the system of the present invention when handling a mobile termination traffic case. In the mobile termination case, the call enters the system through the GMSC/SSF 41 which sends a CS1+ IDP or CIDP message 51 to the Application Server 24 where the message is received by the PSL Scripts 25. The IDP message contains the MSISDN of the PPS subscriber and the CdPN. The PSL Scripts send a CS1+ Retrieve-Invoke (R-I) message 52 to the LNPP 26 in the SCP 23 with the CdPN that potentially has been ported. The LNPP converts the CS1+ protocol to a protocol recognized by the LNP Database 13 such as an ANSI-41 interface, an 800 interface, or an INAP interface. The LNPP then sends a query 53 to the LNP Database 13 containing the CdPN received in the Retrieve-Invoke message.

0033The LNP Database returns a query result 54 to the LNPP. If the CdPN has been ported, the query result contains an RN. If no RN is received, it is assumed that the CdPN has not been ported. The LNPP converts the protocol and sends a CS1+ Retrieve-Result (R-R) message 55 back to the PSL Scripts 25 in the Application Server with the RN as an optional parameter. Based on the LNP Database query result received in the R-R message 55 from the LNPP, the PSL Scripts determine a prefix 56 used to identify whether the call is within the operator's Own Network 10, or in another network. Exemplary prefix values are shown above in Table 1.

0034The PSL Scripts 25 add the correct prefix to a Terminating Location Information parameter that is sent as part of each rated event (for example, First Interrogation, Intermediate Interrogation, or Final Report of Set Up USSD Call Back) to the PPS SDP 22 for rating. After rating the call in the PPS SDP, the PSL Scripts continue normal prepaid call processing with the prefix 56 in the Terminating Location Information taken into account.

0035Thus, in the present invention, the SCP 23 retrieves the ported information directly from the LNP database 13. The PPS service (either modified PPS Service Scripts in the SCP or modified PSL Scripts in the Application Server) then appends a prefix to the Originating Location Information or Terminating Location Information, depending on the traffic case, before communicating with the PPS SDP 22. This prefix indicates whether the call is made between subscribers of the operator's own network. The rating of the call in the PPS SDP takes this prefix into account.

0036As noted above, the tariff structures (data requirements only) in the PPS SDP 22 may also be updated. Based on the new parameters (consisting of a prefix and Originating/Terminating Location Number) sent from the modified PPS Service Scripts 27, the prefix may be added to the number lists in the tariffs, and the rates may be differentiated based on the prefix (if desired).

0037It is thus believed that the operation and construction of the present invention will be apparent from the foregoing description. While the method, apparatus and system shown and described has been characterized as being preferred, it will be readily apparent that various changes and modifications could be made therein without departing from the scope of the invention as defined in the following claims.