JP2014531155A - Method for implementing a master service control function to facilitate extended inter-carrier value-added services - Google Patents

Abstract

A master SCP for extended cross operator functionality is disclosed. The present invention relates to telecommunications networks, and more particularly to master value-added and added services between operators for subscribers belonging to various and independent network operators and service providers. -It relates to a system and method using a service control point. The master SCP serves as a central node that provides communication between multiple SCPs of different network operators using Diameter protocol messages. It facilitates the provisioning of operator specific services as an operator independent service for use by / between subscribers associated with various network operators.

Description

  The following specification describes and confirms in detail the nature of the invention and how it should be carried out.

  The present invention relates to telecommunications networks, and more particularly to a master service control point for providing value-added services and value-added services between access-based operators associated with a telecommunications operator to another operator's subscriber. TECHNICAL FIELD The present invention relates to a system and method for using a computer.

  Today's telecommunications services are provided by many network operators and service providers. These network operators and service providers have limited interoperability and operate independently of each other. However, as telecommunications technology evolves and competitive pressures increase, network operators and service providers need to provide newer applications with improved customer subscriber services.

  Each operator network uses an intelligent network to control and manage various services provided by the operator and any third party applications. Intelligent Network (IN) is an operator-specific network architecture that facilitates communication between various network components to provide operator-specific value-added services and services. Provide to subscribers. IN is a service switching point-SSP (service switching point), a service control point-SCP (service control point), a signaling system called SS7 (Signaling System 7), and various signal transfer points. To provide services to users. Intelligent networks use service control points (SCPs) to control and manage network services. The SCP is connected to either the service switching point-SSP or the signal transfer point-STP. This depends on the network architecture of the network service provider.

  Each subscriber registered with the service provider is associated with a specific service control function within the network, which connects the subscriber to the operator's intelligent network logic. Any subscriber connected to one single intelligent network can subscribe to and access all services provided by the operator network via the service control point. Subscribers are limited to services provided by their service provider and cannot access services provided by other operators. Instead, most value-added / value-added service offerings require interaction between two subscribers, such as peer-to-peer refills, and that these subscribers belong to the same operator Need.

  As the number of service providers increases, subscribers tend to make multiple subscriptions to various service providers in order to obtain the best service from each service provider. In such a scenario, the subscriber needs to manage the various subscriptions independently. Due to the isolated functionality of operator-specific SCP catering for their own set of subscriber bases, inter-operator services are generally limited to basic services only. Also, providing inter-operator services can be cumbersome because each service provider's network architecture can be different.

  In view of the above, embodiments herein provide a method for providing inter-operator services to multiple subscribers of multiple network operators by using a master service control point (SCP). Is provided. In addition to cross-operator services, it also provides a mechanism for dynamically sharing other relevant information between SCPs. The method provides for the operator network “A” to provide / request access to inter-operator services, along with the relevant parameters needed to process the request for operator network “B”. Receiving a service request message from the SCP by the master SCP, authenticating the service request message by the master SCP to analyze the access rights of the operator network A on the operator network B, and if necessary Processing the service request by the master SCP, including interaction with the SCP of the operator network B, and by the master SCP, to the SCP of the operator network A, a positive access acknowledgment for the service or And a step of returning the response message indicating either not. Access rights define services supported / authorized by one operator's service control point to another operator's service control point. The intermediary SCP uses a diameter protocol to send and receive request and response messages. The processing of the request message requires the use of information available on the master service control point server.

  The embodiments further disclose a master service control point for providing inter-operator services to multiple subscribers of multiple network operators. The master service control point receives a service request message from operator network A for a service associated with operator network B and analyzes the access right of operator network A on operator network B. And processing a service request, which may include an interaction with Operator B's SCP, if the service is authorized, and sending a response message to Operator Network A. An access right defines a service supported by one operator's service control point for service control for another operator. The mediating SCP uses a Diameter protocol to send and receive messages. Response message processing requires the use of information available on the master service control point server.

  Embodiments herein further disclose a system in a communication network for providing inter-operator services to a plurality of network operator subscribers, the system comprising a plurality of service control points, a master A service control point, and the master service control point receives a service request message from the operator network A for the service associated with the operator network B, and the operator network A on the operator network B The service request message is authenticated to analyze the access right of the user, and when the service is permitted, the service is processed for the operator network A, and a response message is returned to the operator network A. Configured for. The system authenticates the message and determines access rights, which define the services supported for service control for another operator by one operator's service control point. The system uses the Diameter protocol to send and receive request and response messages. The system processes the response message by using information available on the master service control point server.

  Embodiments herein also provide for inter-operator subscriber-to-subscriber collaborative billing, inter-operator deposit and withdrawal methods, and inter-operator voucher-based re-billing. A method for using a master SCP is disclosed.

  Embodiments further disclose a method for processing a message between a network operator and a service control point, the method comprising the steps of defining various services and between the service control point Generating a new “attribute value pair” for the relevant messaging. In the present method, the step of defining the service includes inter-operator services provided by network operators connected to each other using a master service control point (SCP). An attribute value pair is defined for each service provided by the master SCP.

  These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

  Embodiments herein will be better understood from the following detailed description with reference to the drawings.

1 is a block diagram of a network of telecommunications operators connected to a master service control point according to an embodiment as disclosed herein. FIG. FIG. 3 is a block diagram of a master service control point according to an embodiment as disclosed herein. FIG. 3 illustrates an example Diameter packet format used as a communication protocol according to embodiments disclosed herein. FIG. 3 illustrates an example Diameter packet format used as a communication protocol according to embodiments disclosed herein. FIG. 4 illustrates a call control request message and a call control response message and their definitions according to embodiments disclosed herein. FIG. 4 illustrates a call control request message and a call control response message and their definitions according to embodiments disclosed herein. FIG. 6 illustrates an example illustrating access rights shared by an operator network SCP calling / requesting a service control point of another service provider according to embodiments disclosed herein. FIG. 7 illustrates a global MSISDN-SCP ID-SCP address mapping table according to embodiments disclosed herein. FIG. 6 illustrates a global profile to function mapping table according to embodiments disclosed herein. 6 is an exemplary flowchart illustrating credit deposits from a subscriber (belonging to OP1) to a subscriber (belonging to OP2) between a method and an operator, according to embodiments disclosed herein. 6 is an exemplary flowchart illustrating credit deposits from a subscriber (belonging to OP1) to a subscriber (belonging to OP2) between a method and an operator, according to embodiments disclosed herein. 6 is an exemplary flowchart illustrating credit deposits from a subscriber (belonging to OP1) to a subscriber (belonging to OP2) between a method and an operator, according to embodiments disclosed herein. 6 is an exemplary flowchart illustrating one method of credit withdrawal from a subscriber (belonging to OP1) to a subscriber (belonging to OP2) between operators according to embodiments disclosed herein. 6 is an exemplary flowchart illustrating one method of withdrawing credit from a subscriber (belonging to OP1) to a subscriber (belonging to OP2) between operators according to embodiments disclosed herein. 6 is an exemplary flowchart illustrating one method of withdrawing credit from a subscriber (belonging to OP1) to a subscriber (belonging to OP2) between operators according to embodiments disclosed herein. 6 is a flow chart illustrating one method of collaborative billing from subscriber to subscriber between operators according to embodiments disclosed herein. 6 is a flow chart illustrating one method of collaborative billing from subscriber to subscriber between operators according to embodiments disclosed herein. 6 is a flow chart illustrating one method of collaborative billing from subscriber to subscriber between operators according to embodiments disclosed herein. FIG. 5 is a flowchart illustrating a use case where a master SCP is used for voucher-based re-billing between operators. FIG. 5 is a flowchart illustrating a use case where a master SCP is used for voucher-based re-billing between operators. FIG. 3 illustrates a local SCP function according to embodiments disclosed herein.

  The embodiments herein, the various features, and their advantageous details are more fully described in connection with the non-limiting embodiments shown in the accompanying drawings and described in detail in the following description. Explained. Descriptions of well-known components and processing techniques are omitted so as not to unnecessarily obscure the embodiments herein. The examples used herein merely facilitate an understanding of how the embodiments herein can be implemented, and further enable those skilled in the art to implement the embodiments herein. It is only intended to do. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

  FIG. 1 shows a block diagram of a network of telecommunications operators connected to a master service control point-master SCP according to an embodiment as disclosed herein. The master SCP 101 in the base operator 102 serves as a hub for communication between the indicated operators-OP1, OP2, OP3 and OP4. Base operator 102 is typically one of the existing operators in the network environment. Base operator 102 is an operator that provides a basic network architecture that all other operators can use and implement on their own operator network. Each operator (OP1, OP2, OP3, OP4) is connected to a vast number of subscribers (shown as mobile phones in the figure) using a service control point-SCP. For example, OP1 is composed of SCP1 that communicates with subscribers A and C, and OP2 is composed of SCP2 that communicates with subscribers B and D. The operator network SCP is a standard component of the operator network and the core call control logic to control and process calls (voice, data, SMS) initiated by each SSP-service switching point. Hosting. The SCP implements a service. The subscriber communicates with the SCP via the service switching point-SSP. The SSP is responsible for routing calls that are initiated by one operator's subscriber to another subscriber of the same / other operator. It implements a call state machine, and the transition of this call state machine is guided by instructions given by the SCP. The SCP also communicates with the service data point-SDP for accessing information associated with the subscriber during service processing. The figure shows a single SCP associated with each operator network. However, multiple SCPs can exist in any operator's network. The base operator 102 may be considered as an operator including the master SCP 101, and the other operators (OP1, OP2, OP3, OP4) may be referred to as local operators. Master SCP 101 communicates with other operators' SCP-SCP1, SCP2, SCP3, SCP4 using a Diameter protocol. The Diameter protocol ensures authentication, authorization and accounting—AAA (authentication, authorization and accounting) at each stage of communication. The Diameter protocol provides attribute value pairs (AVP) that allow new commands, attributes and functions to be defined by the operator network. In FIG. 1, the master SCP 101 may be thought of as a central diameter node that includes processing means and a server having information required for inter-operator communication. The other operators-OP1, OP2, OP3, and OP4 serve as client diameter nodes. FIG. 1 shows only the network components relevant to the embodiment of the present invention. Not all components in a telecommunications operator network are shown. Any mobile computing device can be used to connect to the operator network. Also, the subscribers shown are an example, and in practice hundreds of thousands of subscribers may be part of one operator network. Each mobile operator network, shown as a cloud, may use a different architectural framework. The network operators shown are GSM architecture, Internet Protocol based Multimedia system (IMS), and session initiation protocol (SIP) for audio and video communications May use different signaling and communication approaches. Master SCP 101 is configured so that it can communicate and process information between any type of operator network.

  FIG. 2 shows a block diagram of a master service control point according to an embodiment as disclosed herein. The depicted master SCP 101 block diagram does not show all the modules of the SCP. It shows the modules relevant to the present invention. The master SCP is part of the base operator network. The master SCP 101 includes a receiver 201, a transmitter 202, a processing device 203, and a server 204. The receiver 201 receives data and messages from various SCPs of different operators and sends it to processing logic. The processing device 203 may include a control logic 205, a decoder 206, and an encoder 207. Decoder 206 decodes the message received by processing unit 203, and control logic 205 determines an appropriate response for the received message. The encoder 207 then encodes the response into a format understandable by the SCP. The control logic 205 uses all information available at the server 204 to make decisions about the response. The control logic 205 can also have a sequence of events stored. The server 204 includes an SCP IP / SS7 based address database 208, an SCP_ID to MSISDN range mapping table 213, operator profile data 209, an operator ID 210, and an SCP ID 211. The SCP IP / SS7 base address 208 stores the IP / SS7 address of the operator network that is required for master-to-local SCP communication. The SCP_ID 211 contains a predetermined ID for the SCP of all connected operator networks. The operator profile data set 209 contains a profile for each operator network. Operator profile 209 defines the rights each operator provides to other operators. These rights define functional access rights between operators of one operator network on the other operator network. For example, operator OP2 may wish to allow balance transfer from a subscriber at OP1 to his used (OP2) subscriber. The master SCP checks the access rights granted by OP2 for the transfer function from OP1, and allows any transfer function from the OP1 subscriber to the OP2 subscriber. The MSISDN range is generally defined for operator networks. The SCP_ID to MSISDN range mapping table 213 is useful for identifying the hosting SCP of the requesting / responding subscriber. Furthermore, certain inter-operator functions require a pre-agreed agreement between the calling party and the called party, and the OP1 SCP is linked to the calling party (its own subscriber). You need to remember the number of each called party. In other cases, decision criteria / function access may be through dynamic call approval / disapproval of service requests by responding parties. Access rights may thus be defined at two levels. Subscriber-to-subscriber access decision rules / data may be limited to the calling subscriber's local SCP only, and the operator-to-operator access rights that define the operator's access capabilities are further There is a possibility of being defined in the master SCP.

  3A and 3B illustrate an example Diameter protocol packet format 300 used as a communication protocol according to embodiments disclosed herein. The Diameter protocol uses the master SCP 101 as a central node to implement the means for communication between client operator networks. Messages, commands, and functions are configured on the Diameter packet 300 and may be transmitted over the network. The Diameter protocol packet format 300 includes a message header 301 and a message payload 302. The message header 301 includes a diameter version 303, a command code version 304, a command code 305, an application ID 306, a hop-by-hop identifier 307, and an end-to-end identifier 308. Including. Command code version 304 typically includes 7 bits. Certain bits are reserved to indicate the type of message. For example, the request (R) bit may be set to indicate a request, and the proxyable bit (P) is set to indicate a message that needs to be proxied, repeated, or redirected. Sometimes. These versions may be configured and set in the service generation environment of the master SCP. A command code 305 is assigned to the command. These command codes 305 are defined for both request messages and response / answer messages. For example, the command code CCR represents a credit control request. The application ID 306 means an application in the packet. Application ID 306 may mean a third party application, authentication, or accounting. The application ID 306 may be defined in the master SCP 101. A hop-by-hop identifier 307 is used to match the request with the response. End-to-end identifier 308 is useful in identifying dual messages. The message payload 302 is comprised of various numbers of attribute value pairs—AVP 309 that encapsulate information related to the Diameter message. FIG. 3B illustrates the message payload and AVP 309 in more detail. The AVP code 310 includes the same code as the command code 305. The flag 311 is used to define AVP. The flag is 7 bits in length with some reserved bits. The AVP length 312 defines the length of the message. The vendor ID 313 is an optional field. Data field 314 contains all data transmitted / received. An AVP may be generated and used as needed.

  3C and 3D illustrate a call control request message, a call control response message, and their definitions according to embodiments disclosed herein. FIG. 3c shows the CCR request message and the AVP definition associated with the CCR request. FIG. 3d shows the CCA message and the AVP definition associated with the CCA message.

  FIG. 4 shows an example illustrating the access rights shared by the service control point of another service provider and the SCP of the calling / requesting operator network, according to embodiments disclosed herein. is there. FIG. 4 shows the calling operator SCP_ID 401, the linked operator 402, the SCP_ID 403 associated with the linked operator, and the applicable operator SCP profile 404. The SCP profile 404 defines the access rights granted for a particular operator to operator combination. Here, the calling operator 106 is XXX having the calling operator SCP_ID as XXX_SCP1. The linked operator 402 includes YYY_1 and ZZZ_1. The YYY_1 operator includes two SCP operators having YYY_SCP1 as the SCP_ID 403 and other operators having YYY_SCP2 as the SCP_ID 403. Operator_SCP_profile 404 defines access rights for inter-operator features / functions provided by each associated operator for that linked operator. YYY_SCP1 authorizes only account balance inquiry, while YYY_SCP2 authorizes account balance inquiry and account balance withdrawal permission for XXX_SCP1. ZZZ_SCP2 authorizes functions related to balance transfer for XXX_SCP1, but ZZZ_SCP1 does not give access to any inter-operator functions in any way. A mapping to the functions allowed from the profile is given in FIG. In other embodiments, functions authorized for different SCPs belonging to an operator may allow the same access rights / functions. Consider an example when both ZZZ_SCP2 and ZZZ_SCP1 allow all inter-operator functions.

  FIG. 5 illustrates a global MSISDN-SCP ID-SCP address mapping table according to embodiments disclosed herein. MSISDN range 501 indicates the range of MSISDN numbers associated with the operator. Operator ID 502 indicates the operator associated with the MSISDN range. SCP_ID 403 identifies the SCP that hosts the subscriber data for each MSISDN range for the operator. The SCP IP / SS7 address 503 defines the SS7 / IP address of each SCP of various operators for communication purposes. The SS7 / IP address should be used by the master SCP to facilitate communication between the linked operator's SCPs.

  FIG. 6 illustrates a global profile to function mapping table in accordance with embodiments disclosed herein. The operator SCP profile 404 shows available access for another operator, and the supported function 601 shows supported functions / services accessible to an operator belonging to a particular profile. Consider an example where OP1 subscriber C wishes to access the service from OP2. If the operator OP2 authorizes only the balance deposit function for OP1, then the subscriber belonging to the operator OP1 is only for the balance deposit function toward another subscriber “D” of the operator OP2. Will have access. Access to any other function will be denied.

  7A, 7B, and 7C are flowcharts illustrating one method of depositing credit from subscriber to subscriber between operators, according to embodiments disclosed herein. Subscriber A of OP1 initiates a request to deposit funds (F1) into subscriber B's account (701). Subscriber B belongs to operator 2-OP2. A request containing the amount to be transferred along with the details of the beneficiary's MSISDN is sent by subscriber A in USSD format or SMS format. The SCP1 of OP1 receives a request containing the amount to be transferred along with the MSISDN number of subscriber B (702). Next, SCP1 requests subscriber A to enter a PIN number for authentication of subscriber A (703). SCP1 then checks whether the PIN entered by the user is correct (704). If the PIN is incorrect, subscriber A is requested to enter the PIN number again (705). If the PIN is correct, SCP1 checks whether subscriber A has subscribed to the service (706). If the user is not subscribed to the service, subscriber A is sent a message requesting to subscribe to the service (707). The SCP then determines whether the called inter-operator function requires a predetermined contract between party-A and party-B, or by party “B” whose access is answered during the call. You must check whether it will be dynamically authorized. In the case of balance withdrawal / deposit, etc., a predetermined contract may not be required. OP2 subscriber B (the responding entity) may be asked to either allow or not allow service requests from the OP1 subscriber during the triggered request itself. . However, in the case of balance inquiries, etc., the one-time predetermined contract between the called party and the calling party may be stored in the OP1 SCP and during the call from the OP2 subscriber Eliminates the need for requests. SCP1 then checks whether subscriber A has sufficient balance in the account (708). If subscriber A does not have sufficient balance, service is denied (709) and subscriber A is sent a message indicating the account balance. If subscriber A has enough balance for the transaction, SCP1 sends a CCR-credit control request to master SCP 101 (710). The CCR request is sent (711) using a Diameter protocol message containing the amount to be transferred, the beneficiary MSISDN, and the subscriber A operator ID (711), and received by the master SCP 101. (711). The master SCP 101 determines the operator ID of subscriber B using the MSISDN-SCP_ID-SCP address mapping table (712). Next, the master SCP 101 checks whether the SCP_ID 403 of OP1 is valid (713). If the SCP_ID 403 is invalid, the SCP1 of OP1 is denied access to the master SCP 101 service (714). If the SCP_ID 403 of OP1 is valid, the master SCP checks whether OP2 gives OP1 the right to perform credit deposit on Form-F1 (717). If OP2 does not grant access on OP1 for function F1 (717), the function does not support messages sent to SCP1 and subscriber A (718). If OP2 grants access to OP1, the master SCP sends a CCR request to SCP2 of OP2 whose address is derived from the MSISDN-SCP_ID-SCP address mapping table (719). OP2's SCP2 receives a request including the amount to be deposited / credited along with subscriber B's details (720). SCP2 sends an acknowledgment to the master SCP about receiving the CCR request (721). SCP2 of OP2 credits the amount in subscriber B's account (722) and sends a message to subscriber B (722). Next, SCP2 sends a successful message of the CCR request to SCP1 via the master SCP (723). SCP1 then debits the account of subscriber A using the requested amount (724). SCP1 finally sends a message to subscriber A indicating successful transaction along with the debited amount (725). The various actions in method 700 may be performed in the order presented, in different orders, or simultaneously. Further, in some embodiments, some actions listed in FIGS. 7A, 7B, 7C may be omitted.

  8A, 8B, and 8C are flowcharts illustrating a method of credit withdrawal from subscriber to subscriber between operators according to embodiments disclosed herein. Subscriber A of OP1 initiates a request for withdrawal of funds (F2) from the account of subscriber B (801). Subscriber B belongs to operator 2-OP2. The request is sent by subscriber A in USSD format or SMS format. OP1's SCP1 receives a request containing the amount to be withdrawn along with Subscriber B's MSISDN number (802). Next, SCP1 requests subscriber A to enter a PIN number for authentication of subscriber A (803). SCP1 then checks whether the PIN entered by subscriber A is correct (804). If the PIN is not correct, subscriber A is requested to enter the PIN number again (805). If the PIN is correct, SCP1 checks whether subscriber A has subscribed to the service (806). If subscriber A is not subscribed to the service, subscriber A is sent a message requesting to subscribe to the service (807). The SCP then determines whether the called inter-operator function requires a predetermined contract between party-A and party-B, or by party “B” whose access is answered during the call. You must check whether it will be dynamically authorized. In the case of balance withdrawal / deposit, etc., a predetermined contract may not be required. The OP2 subscriber (responding entity) may be asked to either allow or not allow service requests from the OP1 subscriber during the triggered request itself. However, in the case of balance inquiries, etc., the one-time predetermined contract between the called party and the calling party may be stored in the OP1 SCP and during the call from the OP2 subscriber Eliminates the need for requests. SCP1 transmits a CCR-credit control request to the master SCP (808). The CCR request is sent using a Diameter protocol message that includes the amount to be transferred, the MSISDN of “B”, and the operator ID of subscriber A (809). The master SCP 101 determines the operator ID of subscriber B using the MSISDN-SCP_ID-SCP address mapping table (810). Next, the master SCP checks whether the SCP_ID of OP1 is valid (811). If the SCP_ID is invalid, the SCP1 of OP1 is denied access to the master SCP service (812). If the SCP_ID of OP1 is valid, the master SCP 101 checks whether OP2 gives OP1 the right to execute the credit withdrawal function -F2 (815). If OP2 does not grant access on OP1 for function F2 (815), the function does not support messages sent to SCP1 and subscriber A (816). If OP2 grants access rights to OP1, the master SCP sends a CCR request to the SCP2 IP address of OP2 using the MSISDN-SCP_ID-SCP address mapping table (817). SCP2 of OP2 receives a request that includes the amount to be withdrawn along with details of subscriber B (818). SCP 2 then checks whether subscriber B has sufficient balance in the account for the transaction (820). If subscriber B does not have sufficient balance, the service is rejected and a failure message is sent to subscriber A and SCP1 (821). If subscriber B has sufficient balance for the transaction, SCP 2 sends a USSD menu / message requesting permission for withdrawal to subscriber B (822). The OP2 subscriber responds to the USSD menu based request by selecting either the allow option or the disallow option. If subscriber B does not grant permission for withdrawal (823), the service is denied to subscriber A and a failure message is sent to subscriber A via master SCP 101. (824). If subscriber B authorizes withdrawal, SCP2 of OP2 withdraws the amount from subscriber B's account (825) and sends a message to subscriber B (825). SCP 2 then sends a successful message of the CCR request to master SCP 101 (826). SCP1 then credits subscriber A's account using the requested amount (827). SCP1 finally sends a message to subscriber A indicating the successful transaction along with the amount credited (828). The various actions in method 800 may be performed in the order presented, in different orders, or simultaneously. Further, in some embodiments, some actions listed in FIGS. 8A, 8B, 8C may be omitted.

  9A, 9B, and 9C are flowcharts illustrating a method of collaborative billing from subscriber to subscriber between operators according to embodiments disclosed herein. The collaborative charging method allows subscribers involved in voice / video / sms calls to share call charges at a rate specified by the calling subscriber. Subscriber A of OP1 initiates a request to request subscriber B to pay partially / entirely for the next call destined for subscriber B by subscriber A (901). Subscriber B belongs to operator 2-OP2. The request is sent by subscriber A to subscriber B's respective SCP through either a USSD request or an SMS request. A sample USSD request sent by calling party A to establish a collaborative charging relationship with called party B for the following calls: * <ACCESS CODE> ** <Fraction CHARGE> * <MSISDN of B>. OP1's SCP1 is the percentage of the total call charge to be charged to the called party “B” along with subscriber B's MSISDN number (50—50% of call charge; 100—total call charge) A request for designating is received (902). The charging of the subscriber “B” may be performed according to a charging fee applicable to the subscriber “A” as in the subscribed fee schedule plan. Next, SCP1 requests subscriber A to enter a PIN number for authentication of subscriber A (903). SCP1 then checks whether the PIN entered by subscriber A is correct (904). If the PIN is incorrect, Subscriber A is requested to enter the PIN number again (905). If the PIN is correct, SCP1 checks whether subscriber A has subscribed to the service (906). If subscriber A is not subscribed to the service, subscriber A is sent a message requesting to subscribe to the service (907). Next, SCP1 determines whether the called inter-operator function requires a predetermined contract between party-A and party-B, or by party “B” whose access responds during the call. You must check whether it will be dynamically authorized. In the case of balance withdrawal / deposit, etc., a predetermined contract may not be required. The OP2 subscriber (responding entity) may be asked to either allow or not allow service requests from the OP1 subscriber during the triggered request itself. However, in these cases, etc., the one-time predetermined contract between the called party and the calling party may be stored in the OP1 SCP, and during the call from the OP2 subscriber. Eliminates the need for requests. SCP1 calculates the fee to be charged by the called party based on the rate requested by the calling subscriber. The rest of the fee should be borne by the calling party. It is important to note here that the operator can charge a regular or usage-based fixed fee for the party calling for such a call. SCP1 sends a CCR-credit control request to the master SCP (908). The CCR request is sent using a Diameter protocol message that includes the fee that the called party needs to be charged, B's MSISDN, A's MSISDN, and subscriber A's operator ID. (909). Master SCP 101 determines the operator ID of subscriber B using the MSISDN-SCP_ID-SCP address mapping table (910). Next, the master SCP checks whether the SCP_ID of OP1 is valid (911). If the SCP_ID is invalid, the SCP1 of OP1 is denied access to the master SCP service (912). If the SCP_ID of OP1 is valid, then the master SCP 101 checks whether OP2 gives OP1 the right to execute the collaboration charging function-F7 (913). If OP2 does not grant access on OP1 for function F7, the function does not support messages sent to SCP1 and subscriber A (914). If OP2 grants access to OP1, then the master SCP sends a CCR request to OP2's SCP2 IP address whose address is derived from the MSISDN-SCP_ID-SCP address mapping table (915). . The SCP2 of OP2 receives a request including the fee to be charged for the called party “B” along with the MSISDN details of subscribers A and B (916). The SCP 2 transmits an acknowledgment of the CCR response to the master SCP (917). SCP 2 then checks whether subscriber B has sufficient balance in the account for the transaction (918). If subscriber B does not have sufficient balance, the service is denied and a failure message is sent to subscriber A and SCP1 (919). If subscriber B has sufficient balance for the transaction, SCP2 will allow the next call from subscriber "A" to be charged to subscriber B's account at a predetermined rate. A USSD menu / message requesting permission is sent to subscriber B (920). OP2 subscriber B responds to the USSD menu-based request by selecting either the allow option or the disallow option. If subscriber B does not grant (921), the service is denied to subscriber A and a failure message is sent to subscriber A via master SCP 101 (922). . When the subscriber B permits collaboration-type charging, the SCP 2 of OP2 transmits a message indicating a successful CCR request to the master SCP 101 (923). Furthermore, SCP2 also notes that on the next call from subscriber “A”, subscriber “B” should be charged at a clearly limited rate as specified by the master SCP. Should. SCP1 finally sends a message to subscriber A indicating a successful operation (924). The call charge for the next call made by subscriber “A” to subscriber “B” is distributed between the two subscribers. The various actions in method 900 may be performed in the order presented, in different orders, or simultaneously. Further, in some embodiments, some actions listed in FIGS. 9A, 9B, 9C may be omitted.

  FIGS. 10A and 10B are flowcharts illustrating the case of a user between different operators for voucher-based re-billing between subscribers to a subscriber, according to embodiments disclosed herein. . Voucher-based recharge between operators allows subscriber A belonging to operator OP1 to recharge another account of subscriber B belonging to operator OP2. Subscriber A of OP1 initiates a request to request another subscriber B to recharge (1001). Subscriber B belongs to operator 2-OP2. The request is initiated by subscriber A either through a USSD request, through an SMS request, or through OP1's interactive voice response system, presenting subscriber B's voucher number and MSISDN. The voucher can be a special voucher card provisioned by operator OP1 for the specific case of voucher-based re-billing between operators. The SCP1 of OP1 receives the request specifying the details of the re-billing voucher and the MSISDN of the subscriber B (1002). Next, SCP1 requests subscriber A to input a PIN number for authentication of subscriber A (1003). SCP1 then checks whether the PIN entered by subscriber A is correct (1004). If the PIN is incorrect, subscriber A is requested to enter the PIN number again (1005). If the PIN is correct, SCP1 checks whether subscriber A has subscribed to the service (1006). If subscriber A is not subscribed to the service, subscriber A is sent a message requesting to subscribe to the service (1007). SCP1 authenticates the voucher card number and derives the associated amount to be credited to the account. SCP1 transmits a CCR-credit control request to the master SCP (1008). The CCR request is sent using a Diameter protocol message containing the amount to be credited, Subscriber B's MSISDN, Subscriber A's MSISDN, and OP1's operator ID (1009). Master SCP 101 determines the operator ID of subscriber B using the MSISDN-SCP_ID-SCP address mapping table (1010). Next, the master SCP checks whether the SCP_ID of OP1 is valid (1011). If the SCP_ID is invalid, the SCP1 of OP1 is denied access to the master SCP service (1012). If the SCP_ID of OP1 is valid, then the master SCP 101 checks whether OP2 grants OP1 the right to perform the voucher-based recharging-function F8 (1013). If OP2 does not grant access on OP1 for function F8 (1013), the function does not support messages sent to SCP1 and subscriber A (1014). If OP2 grants access to OP1, then the master SCP sends a CCR request to the SCP2 IP address of OP2 whose address is derived from the MSISDN-SCP_ID-SCP address mapping table (1015). . The SCP2 of OP2 receives a request including subscriber A's MSISDN, subscriber B's MSISDN, and the amount to be credited to subscriber B's account (1016). The SCP 2 transmits an acknowledgment of the CCR reception response to the master SCP (1017). The SCP2 of OP2 credits the amount to the account of the subscriber B (1018), and transmits a successful message of the CCR request to the master SCP 101 (1019). In addition, SCP 2 also sends a notification to subscriber B indicating that subscriber B's account has been credited by MSISDN “A” for the respective amount (1020). SCP1 finally sends a message to subscriber A indicating a successful operation (1021). The various actions in method 1000 may be performed in the order presented, in different orders, or simultaneously. Further, in some embodiments, some actions listed in FIGS. 10A, 10B may be omitted.

  FIG. 11 illustrates a local SCP function according to embodiments disclosed herein. The master SCP may allow a subscriber belonging to one local SCP of the operator network to have multiple linked accounts with other network operators. Such subscribers may be allowed to manage and control services between operators, as well as services within each operator network. For example, a subscriber running a business holding such an account can use this system to link multiple user accounts and transfer weekly income for the user. If a subscriber uses different operator services in different cities, the subscriber may want to control and manage all of the subscriber's user accounts from any location, and Service between operators may also be required. The transmitter 202 sends a response message to each SCP in each operator network. The local SCP function indicates the basic account along with the subscriber's basic account number. The screen shows the account linked to the basic account along with the operator ID. The local function shows the basic account along with the subscriber's basic account number. The local function shows one of the linked accounts. It also shows the services that the base operator subscriber can perform on OP2 using the base account number.

  In one embodiment, the method is via the master SCP over the Diameter interface, between SCPs, or between other network entities such as Operator B's SSP and Operator A's SCP. This facilitates dynamic sharing of relevant information. This information may correspond to information about the CDR data of the roaming person (in-roamer) who roams under the coverage of operator B using the SCP of operator A, such as for billing purposes. .

  The above description of specific embodiments has facilitated such specific embodiments for various uses by others applying current knowledge without departing from the generic concept. So that the general nature of the embodiments herein, which can be modified and / or adapted to, is so well defined, and therefore such adaptations and modifications are It should be understood and intended to be within the meaning and scope of the equivalents of the disclosed embodiments. It should be understood that the terminology or terminology used herein is for the purpose of description and is not limiting. Accordingly, although the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein are within the spirit of the claims as described herein. It will be appreciated that and can be implemented using modifications within the scope.

Claims (15)

A method for providing inter-operator value-added telephone service and value-added telephone service to a plurality of subscribers of a plurality of network operators by using a master service control point (SCP), comprising:
Receiving a service request message by the master SCP from a subscriber of operator network A for a service associated with a second subscriber of operator network B;
Authenticating the service request message by the master SCP to analyze access rights of the operator network A on the operator network B;
Processing the service by the master SCP for the operator network A if the service is authorized;
Sending a response message by the master SCP to the operator network B.   The method of claim 1, wherein the access right defines the service supported by a service control point of one operator for service control for another operator.   The method of claim 1, providing a comprehensive mechanism for inter-operator function implementation that requires each operator SCP to share relevant subscriber / billing data through the master SCP.   The method of claim 1, facilitating subscribers belonging to different operators to collaboratively pay for specific services such as SMS, data calls, and the like.   The method of claim 1, facilitating dynamic subscriber approval for requested inter-operator service by another operator's subscriber.   The method according to claim 1, applicable to architectures including IP Multimedia Services (IMS), Session Initiation Protocol (SIP), Global System for Mobile Communications (GSM).   The method of claim 1, further comprising dynamically sharing relevant information between the SCP or other operator specific network entities via the provisioned Diameter interface via the master SCP. Method. Defining various services for processing messages between the network operator and the service control point;
Generating a new attribute value pair for each service provider for relevant messaging between the service control points.   9. The method of claim 8, wherein the step of defining a service comprises an inter-operator service provided by the network operators connected to each other using a master service control point (SCP). A master service control point for providing inter-operator services to multiple subscribers of multiple network operators,
Stores integrated network information about the operator SCP and service agreements between operators from operator to operator,
Receiving a service request message from operator network A for a service associated with operator network B;
Authenticating the service request message for analyzing the access rights of the operator network A on the operator network B;
If the service is authorized, process the service for the operator network A;
A master service control point comprising sending a response message to the operator network B.   The master service control point of claim 10, wherein the access right defines service access between operators authorized by one operator's service control point for another operator's service control. A system in a communication network for providing a service between operators to a plurality of subscribers of a plurality of network operators, comprising a plurality of service control points and a master service control point, wherein the master service control The point is further
Receiving a service request message from a subscriber of operator network A for a service associated with a second subscriber of operator network B;
Authenticating the service request message to analyze the access rights of the operator network A on the operator network B;
If the service is authorized, process the service for the operator network A;
A system configured to send a response message to the operator network B.   13. The message is authenticated to determine the access right, the access right defining the service supported by a service control point of one operator for service control for another operator. System.   13. The system of claim 12, further configured to facilitate subscribers belonging to different operators collaboratively paying for specific services such as SMS, data calls, and the like.   Further configured to provide a comprehensive mechanism for performing functions between operators, requiring each operator SCP to share relevant subscriber / billing data through the master SCP. Item 13. The system according to Item 12.

Images