WO2013041261A1

WO2013041261A1 - Method of implementing master service control function for facilitating enhanced inter carrier value added services

Info

Publication number: WO2013041261A1
Application number: PCT/EP2012/063822
Authority: WO
Inventors: Varun G GUPTA
Original assignee: Alcatel Lucent
Priority date: 2011-09-20
Filing date: 2012-07-13
Publication date: 2013-03-28
Also published as: CN103814583A; KR20140068110A; JP2014531155A; JP5859129B2; KR101573672B1

Abstract

A Master SCP for extended cross -operator features is disclosed. The present invention relates to telecommunication networks and, more particularly, to systems and methods of utilizing a Master Service Control Point to provide inter-operator value added and supplementary services to a subscribers belonging to varied and independent network operators and service providers. A master SCP acts as a central node providing communication between multiple SCP's of different network operators using diameter protocol messages. It facilitates provisioning of operator- specific services as operator-independent services for use by/among subscribers associated to varied network operators.

Description

"Method of implementing Master Service Control Function for facilitating enhanced inter carrier value added services"

The following specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed :-

TECHNICAL FIELD

[001] The present invention relates to telecommunication networks and, more particularly, to systems and methods of utilizing a Master Service Control Point to provide access-rights based inter-operator value- added and supplementary services associated to a telecom operator to subscribers of another operator.

BACKGROUND

[002] Present day telecommunication services are provided by a host of network operators and service providers. These network operators and service providers operate independent of each other with limited interoperability. However, with the growth of telecommunication technology and competitive pressure, network operators and service providers need to provide newer applications along with improved customer subscriber services.

[003] Each operator network makes use of an intelligent network to control and manage various services provided by the operator and any third party applications. The Intelligent Network (IN) is an operator specific network architecture, which facilitates communication between various network components to provide operator specific, value added and supplementary services to subscribers . The IN makes use of service switching points -SSP's, service control points -SCP's, a signaling system called SS7 (Signaling System 7) and various signal transfer points to provide services to users. The intelligent network makes use of Service Control Point (SCP) to control and manage network services. SCPs are connected with either Service Switching Points-SSP or Signal Transfer Points-STP. This is dependent upon the network architecture of the network service provider.

[004] Each subscriber registered with a service provider, is associated to a specific service control function inside the network, which connects him to the operator's intelligent network logic. Any subscriber connected to one single intelligent network can subscribe and access all the services provided by the operator network via the Service Control Point. The subscriber is restricted to services provided by the service provider and cannot access services provided by other operators. Alternately, most of the value added / supplementary service offering requires interaction among two subscribers like peer-to-peer refill and need these subscribers to belong to the same operator.

[005] With the growing number of service providers, subscribers tend to have multiple subscriptions with various service providers in order to get the best services from each service provider. In such a scenario, subscribers need to manage various subscriptions independently. Inter- operator services are generally restricted to basic services, due to isolated functioning of Operator specific SCPs catering to their own set of subscriber base. Also, as the network architecture of each service provider may differ, providing inter-operator services becomes challenging.

SUMMARY

[006] In view of the foregoing, embodiments herein provide a method for providing inter-operator services to multiple subscribers of multiple network operators by employing a Master Service Control Point (SCP). In addition to cross operator services; it also provides a mechanism of dynamically sharing of other relevant information among SCPs. The method comprises of receiving a service request message by the Master SCP from an operator network 'A"s SCP for providing / requesting access to an inter-operator service along with relevant parameters required for processing the request to an operator network 'B', authenticating the service request message by the master SCP for analyzing access rights of the operator network A over the operator network B, processing the service request by the master SCP including interaction with the operator network B's SCP if required, and sending of response message by the master SCP back to the operator network A's SCP indicating either positive access acknowledgement or denial of service. The access rights define the services supported/granted by service control point of one operator to service control point of another operator. Mediating SCPs use diameter protocol for sending and receiving request and response messages. The processing of the request message involves use of information available on the server of the Master Service Control Point.

[007] 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 comprises of receiving a service request message from an operator network A for service related to an operator network B, authenticating the service request message for analyzing access rights of the operator network A over the operator network B, processing the service request which may include interaction with operator B's SCP, if the service is permitted and sending a reply message to the operator network A. The access right defines the services supported by service control point of one operator for service control to another operator. Mediating SCPs use diameter protocol for sending and receiving messages. Processing of the reply message involves use of information available on the server of the Master Service Control Point.

[008] Embodiments herein further disclose a system in a communication network for providing inter-operator services to subscribers of multiple network operators, the system comprising plurality of service control points, a Master Service Control Point, further the Master Service Control Point configured for receiving a service request message from an operator network A for service related to an operator network B, authenticating the service request message for analyzing access rights of the operator network A over the operator network B, processing the service, for the operator network A if the service is permitted and sending a response message back to the operator network A. The system authenticates the message to determine the access rights where the access rights define the services supported by service control point of one operator for service control to another operator. The system sends and receives the request and the reply messages using diameter protocol. The system processes the reply message by using information available on the server of the Master Service Control Point.

[009] Embodiments herein also disclose methods for inter- operator subscriber to subscriber collaborative charging, inter- operator deposit and withdrawals and employing the Master SCP for inter-operator voucher based recharge.

[0010] Embodiments further disclose a method for processing messages between network operators and service control points, the method comprising defining various services and creating new "attribute value pairs" for relevant messaging between the service control points. The method wherein defining of services includes inter-operator services offered by the network operators connected to each other using a Master Service Control Point (SCP). The attribute value pairs are defined for each service provided by the master SCP.

[0011] 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.

BRIEF DESCRIPTION OF THE FIGURES

[0012] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:

[0013] FIG. 1 illustrates a block diagram of the network of telecommunication operators connected to a Master Service Control Point, according to the embodiments as disclosed herein;

[0014] FIG. 2 illustrate a block diagram of the Master Service Control Point, according to the embodiments as disclosed herein;

[0015] FIG. 3 A and 3B illustrate an example of a diameter packet format used as the communication protocol, according to the embodiments disclosed herein;

[0016] FIG. 3C and 3D illustrate the Call Control Request and Call Control Answer messages and their definitions, according to the embodiments disclosed herein; [0017] FIG. 4 shows an example describing access rights shared by a calling/requesting operator network's SCP with other service provider's service control point, according to the embodiments disclosed herein;

[0018] FIG. 5 illustrate a Global MSISDN - SCP ID - SCP ADDRESS MAPPING Table, according to the embodiments disclosed herein;

[0019] FIG. 6 illustrates a Global Profile to Function Mapper table, according to the embodiments disclosed herein;

[0020] FIG. 7A, 7B, 7C are example flowcharts describing a method - an inter- operator subscriber (belonging to OP1) to subscriber (belonging to OP2) credit deposit, according to embodiments disclosed herein;

[0021] FIG. 8A, 8B, 8C are example flowcharts describing a method of inter-operator subscriber (belonging to OP1) to subscriber (belonging to OP2) credit withdrawal according to embodiments disclosed herein;

[0022] FIG. 9A, 9B, 9C are flowcharts describing a method of inter- operator subscriber to subscriber collaborative charging, according to embodiments disclosed herein;

[0023] FIG 10A, 10B illustrates flowchart diagrams describing the use case where Master SCP is used for inter-operator voucher based recharge; and [0024] FIG. 11 illustrates local SCP functions, according to embodiments disclosed herein;

DETAILED DESCRIPTION OF EMBODIMENTS

[0025] The embodiments herein, the various features, and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well- known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

[0026] FIG. 1 illustrates a block diagram of the network of telecommunication operators connected to a Master Service Control Point- Master SCP, according to the embodiments as disclosed herein. A master SCP 101 in a base operator 102 acts as a hub for communication between the shown operators - OP1, OP2, OP3, and OP4. The base operator 102 is generally one of the existing operators in the network environment. The base operator 102 is the one which provides the basic network architecture which all the other operators may use and implement on their own operator networks. Each operator (OPl, OP2, OP3, OP4) connects to a huge number of subscribers (shown as mobile phones in the figure) using a service control point-SCP. For example, OPl consists of an SCP1, which communicates with subscriber A, and subscriber C and OP2 consists of SCP2, which communicates with subscriber B and subscriber D. The SCP of an operator network is a standard component of an operator network, hosting core call control logic for controlling and handling the call (voice, data, SMS) initiated by the respective SSP- Service Switching Point. The SCP implements the services. The subscribers communicate with the SCP via a service switching point-SSP. The SSP is responsible for routing of call initiated by a subscriber of one operator to another subscriber of same/other operator. It implements a call state machine, whose transitions are guided by the instructions given by the SCP. The SCP also communicates with a service data point-SDP for accessing subscriber related information during processing of a service. The figure shows a single SCP associated with each operator network. However, multiple SCP's may be present in every operator's network. The base operator 102 may be considered as the one containing the Master SCP 101 and the other operators (OPl, OP2,OP3,OP4) may be called local operators The master SCP 101 communicates with the SCP'S of other operators- SCP1, SCP2, SCP3, SCP4 using a diameter protocol. The diameter protocol ensures authentication, authorization and accounting -AAA at each stage of the communication. The diameter protocol provides attribute value pairs - AVP's which allows new commands, attributes and functions to be defined by the operator networks. In Figure 1, the Master SCP 101 may be considered as a central diameter node containing processing means and a server with information required for inter operator communication. The other operators -OP1, OP2, OP3, and OP4 act as client diameter nodes. The figure 1 shows only network components relevant to the embodiments of the present invention. Not all the components in a telecommunication operator network are shown. Any mobile computing device can be used to connect to an operator network. Also, the subscribers shown are an example and in reality hundreds of thousands of subscribers may be part of one operator network. Each mobile operator network shown a cloud may be using different architectural frameworks. The network operators shown may be using different signaling and communication approaches like GSM architecture, an Internet Protocol based Multimedia system (IMS) or even an session initiation protocol (SIP) for audio and video communications. The Master SCP 101 is configured such that it can communicate and process information between any type of operator networks.

[0027] FIG. 2 illustrates a block diagram of the Master Service Control Point, according to the embodiments as disclosed herein. The depicted master SCP 101 block diagram does not show all the modules of an SCP. It shows modules relevant to the present invention. The master SCP is a part of the base operator network. The Master SCP 101 contains a receiver 201, transmitter 202, a processing unit 203 and a server 204. The receiver 201 receives data and messages from various SCP's of different operators and sends it to the processing logic. The processing unit 203 may comprise of control logic 205, decoders 206 and encoders 207. The decoders 206 decode the messages received by the processing unit 203 and the control logic 205 decides on an appropriate reply for the received message. The encoder 207 then encodes the reply into a format understandable by the SCP's. The control logic 205 makes use of all the information available in the server 204 to decide on a reply. The control logic 205 may also have sequences of events stored. The server 204 comprises of an SCP IP/SS7 based address database 208, an SCP ID to MSISDN range mapping table 213, operator profile data 209, operator ID's 210, SCP ID's 211 . The SCP IP/SS7 based address 208 stores the IP/SS7 address of the operator networks required for Master-to-Local SCP communication. The SCP ID 211 contains pre-defined IDs of all the connected operator networks' SCPs. The operator profile dataset 209 contains the profile of each operator network. The operator profile 209 defines the right each operator provides to other operators. These rights define the inter-operator feature access rights of one operator network over the other. For example, the operator OP2 may want to allow balance transfer from an OPl 's subscriber to his worn (OP2'S) subscriber. The Master SCP checks the access rights given by OP2 for transfer function from OP1 and allows any transfer function from a subscriber of OP1 towards subscriber of OP2. MSISDN ranges are generally defined for operator networks. A SCP ID to MSISDN range mapping table 213 is useful for identifying the hosting SCP of the requesting/responding subscriber. While certain inter-operator features require a pre-agreed arrangement between the calling and the called party, requiring OP1 SCP to store respective called party numbers linked to the calling party (own subscriber). For other cases the decision criteria/feature access may be through dynamic in-call appro val/disapproval of service request by the responding party. Access rights may be thus be defined at two levels. A subscriber-to-subscriber access decision rules/data may be confined to the local SCP of the invoking subscriber and an Operator-to-Operator access rights defining an operator's access capability may further be defined at Master SCP.

[0028] FIG. 3A and 3B illustrate an example of a diameter protocol packet format 300 used as the communication protocol, according to the embodiments disclosed herein. The diameter protocol acts a means for communication between client operator networks using the master SCP 101 as a central node. Messages, command, and functions can be configured on a diameter packet 300, and sent across the network. The diameter protocol packet format 300 consists of a message header 301 and a message payload 302. The message header 301 comprises of a diameter version 303, a command code version 304, a command code 305, application ID 306, a hop-by-hop identifier 307 and an end-to-end identifier 308. The command code version 304 generally comprises of 7 bits. Certain bits are reserved to indicate the type of message. For example, a request (R) bit may be set to indicate a request; a proxiable bit (P) may be set to indicate a message, which needs to be proxied, repeated or redirected. These versions can also be configured and set in master SCP's service creation environment. A command is assigned with a command code 305. These command codes

305 are defined for both request and reply/answer messages. For example, command code CCR stands for credit control request. The application ID

306 refers to application in the packet. The application ID 306 may refer to a third party application, authentication, or accounting. The application ID

306 can also be defined at the master SCP 101. The hop-by-hop identifier

307 is used to match requests and replies. The end-to-end identifier 308 helps in identifying duplicate messages. The message payload 302 consists of a variable number of attribute value pairs -A VP's 309 that encapsulate information relevant to the diameter message.

Fig 3B describes the message payload and the AVP's 309 in further detail. The AVP code 310 contains the same code as command code 305. The flags 311 are used to define the AVP's. The flag is 7 bits in length with certain reserved bits. The AVP length 312 defines the length of the message. The vendor ID 313 is an optional field. The data field 314 contains all data sent/received. The AVP's can be created and used as required.

[0029] FIG. 3C and 3D illustrate the Call Control Request and Call Control Answer messages and their definitions, according to the embodiments disclosed herein. Figure 3c depicts CCR request message and the AVP definitions pertaining to the CCR request. Figure 3d depicts CCA message and the AVP definitions pertaining to the CCA message.

[0030] FIG. 4 shows an example describing access rights shared by a calling/requesting operator network's SCP with other service provider's service control point, according to the embodiments disclosed herein, Figure 4 shows a calling operator SCP ID 401, linked operators 402, the SCP ID's 403 associated with the linked operators and applicable operator SCP profile 404,. The SCP profile 404 defines the access right given for particular operator-to-operator combination. The calling operator 106 here is XXX with the calling operator SCP ID as XXX SCPl . The linked operators 402 include YYY l and ZZZ l . The YYY l operator contains two SCP's one with YYY SCPl as the SCP ID 403 and the other one as YYY SCP2 as the SCP ID 403. The Operator_SCP_profile 404 defines the access right in terms of inter-operator features/function offered by each associated Operator to its linked operators. The YYY SCPl allows only account balance enquiry while the YYY SCP2 grants account balance enquiry as well as account balance withdrawal permission to XXX SCPl . The ZZZ SCP2 grants balance transfer related functions to XXX SCPl, while ZZZ SCPl does not give access to any inter-operator function in any manner. The profile to allowed functions mapping is given in FIG 6. In other embodiments, the functions granted to different SCP belonging to an operator may allow the same access rights/functions. Consider an example when both ZZZ SCP2 and ZZZ SCPl allow all inter operator functions.

[0031] FIG. 5 illustrates a Global MSISDN - SCP ID - SCP ADDRESS MAPPING Table, according to the embodiments disclosed herein. The MSISDN range 501 shows the MSISDN number ranges associated to an operator. The operator ID 502 shows the operator associated with the MSISDN ranges. The SCP ID 403 identifies the SCP hosting the subscriber data of respective MSISDN range f the operator. The SCP IP/SS7 addresses 503 define the SS7/IP addresses of the respective SCPs of various operators for communication purposes. The SS7/IP addresses shall be used by the Master SCP to facilitate communication between the linked operators' SCPs.

[0032] FIG. 6 illustrates a Global Profile to Function Mapper table, according to the embodiments disclosed herein. The operator SCP profile 404 shows the access available to another operator and the function supported 601 shows the supported functions/services accessible to the operators belonging to the specific profile.. Consider an example where subscriber C of OP1 wants to access services from OP2. If the operator OP2 grants only balance deposit function to OP1, then subscriber belonging to operator OP1 will have access to only balance deposit function towards another subscriber 'D' of operator OP2. Access to any other functions will be rejected.

[0033] FIG. 7A, 7B, 7C are flowcharts describing a method of inters- operator subscriber to subscriber credit deposit, according to embodiments disclosed herein. Subscriber A of OP1 initiates a request (701) for depositing funds (Fl) in subscriber B's account. The subscriber B belongs to operator 2-OP2. The request containing amount to be transferred along with beneficiary MSISDN details is sent by the subscriber A in an USSD format or an SMS format. The SCP1 of OP1 receives (702) the request containing the amount to be transferred along with the MSISDN number of subscriber B. The SCP1 then requests (703) subscriber A to enter a PIN number for authentication of the subscriber A. The SCP1 then checks (704) if the PIN entered by the user is correct. If the PIN is incorrect, the subscriber A is requested (705) to enter the PIN number again. If the PIN is correct, the SCP1 checks (706) if subscriber A is subscribed to the service. If the user is not subscribed to the service, the subscriber A is sent (707) a message requesting to subscribe to the service. Next SCP shall check if the invoked inter-operator function requires a predefined agreement between party-A and party-B, or if the access would be granted dynamically by responding party 'B' during the call. For cases such as balance withdrawal/deposit, a pre-defined agreement may not be required. The OP2 subscriber B (responding entity), may be asked to either allow/disallow the service request from subscriber of OPl during the triggered request itself. However for cases, such as balance enquiry a onetime pre-defined agreement between the called and the calling party may be stored at OPl 's SCP eliminating the need for in- call request from OP2's subscriber. The SCPl then checks (708) if subscriber A has sufficient balance in the account. If the subscriber A does not have sufficient balance, the service is denied (709) and subscriber A is sent a message showing account balance. If subscriber A has sufficient balance for the transaction, SCPl sends (710) a CCR -credit control request to the master SCP 101. The CCR request is sent (711) using a diameter protocol message containing amount to be transferred, the beneficiary MSISDN and the operator ID of subscriber A and received 711 by the master SCP 101. The master SCP 101 determines (712) operator ID of subscriber B using the MSISDN - SCP ID-SCP address mapping table. The master SCP 101 then checks (713) if the SCP ID 403 of OPl is valid. If the SCP ID 403 is invalid, SCPl of OPl is denied (714) access to master SCP 101 service. If the SCP ID 403 of OPl is valid, The master SCP checks (717) if OP2 gives rights to OP1 for performing credit deposit in the form-Fl . If OP2 does not give 717-access right over OP1 for function Fl, a function is not supported message sent (718) to SCPl and the subscriber A. If OP2 gives access right to OP1, the master SCP sends (719), the CCR request to SCP2 of OP2 whose address is derived from the MSISDN - SCP ID-SCP address mapping table. The SCP2 of OP2 receives (720) the request containing the amount to be deposited/credited along with subscriber B's details. The SCP2 sends (721) an acknowledgement for receiving the CCR request to the master SCP. The SCP2 of OP2 credits (722) the amount in subscriber B's account and sends (722) a message to subscriber B. The SCP2 then sends (723) a CCR request successful message to SCPl via the master SCP. The SCPl then debits (724) the subscriber A's account with the requested amount. The SCPl finally sends (725) a message to subscriber A indicating successful transaction along with the amount debited. The various actions in method 700 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 7A, 7B, 7C may be omitted.

[0034] FIG. 8A, 8B, 8C are flowcharts describing a method of inter- operator subscriber to subscriber credit withdrawal, according to embodiments disclosed herein. Subscriber A of OP1 initiates a request (801) for withdrawal of funds (F2) from subscriber B's account. The subscriber B belongs to operator 2-OP2. The request is sent by the subscriber A in an USSD format or an SMS format. The SCP1 of OP1 receives (802) the request containing the amount to be withdrawn along with the MSISDN number of subscriber B. The SCP1 then requests (803) subscriber A to enter a PIN number for authentication of the subscriber A. The SCP1 then checks (804), if the PIN entered by subscriber A is correct. If the PIN is incorrect, the subscriber A is requested (805) to enter the PIN number again. If the PIN is correct, the SCP1 checks (806) if subscriber A is subscribed to the service. If the subscriber A is not subscribed to the service, subscriber A is sent (807) a message requesting to subscribe to the service. Next SCP shall check if the invoked inter-operator function requires a pre-defined agreement between party-A and party-B, or if the access would be granted dynamically by responding party 'B' during the call. For cases such as balance withdrawal/deposit, a pre-defined agreement may not be required. The OP2 subscriber (responding entity) may be asked to either allow/disallow the service request from subscriber of OP1 during the triggered request itself. However for cases, such as balance enquiry a one-time pre-defined agreement between the called and the calling party may be stored at OPl 's SCP eliminating the need for in-call request from OP2's subscriber. SCP1 sends (808) a CCR -credit control request to the master SCP. The CCR request is sent using a diameter protocol message containing (809) amount to be transferred, the MSISDN of 'B' and the operator ID of subscriber A. The master SCP 101 determines (810) operator ID of subscriber B using the MSISDN - SCP ID-SCP address mapping table. The master SCP then checks (811) if the SCP ID of OPl is valid. If the SCP ID is invalid, SCP1 of OPl is denied (812) access to master SCP service. If the SCP ID of OPl is valid, the master SCP 101 checks (815) if OP2 gives rights to OPl for performing credit withdrawal function-F2. If OP2 does not give 815-access right over OPl for function F2, a function is not supported message sent (816) to SCP1 and the subscriber A. If OP2 gives access right to OPl, the master SCP sends (817), the CCR request to SCP2 IP address of OP2 uses the MSISDN - SCP ID-SCP address mapping table. The SCP2 of OP2 receives (818) the request containing the amount to withdrawn along with subscriber B's details. The SCP2 then checks (820), if subscriber B has sufficient balance in the account for the transaction. If the subscriber B does not have sufficient balance, the service is denied (821) and a failure message is sent to subscriber A and SCP1. If subscriber B has sufficient balance, for the transaction, SCP2 sends (822) a USSD menu/message to subscriber B requesting permission for withdrawal. Subscriber of OP2 responds to USSD Menu based request by selecting either the allow or disallow option. If subscriber B does not, give (823) permission for withdrawal, service is denied (824) to subscriber A and a failure message is sent to subscriber A via the master SCP 101. If subscriber B allows withdrawal, the SCP2 of OP2 withdraws 825 the amount from subscriber B's account and sends 825 a message to subscriber B. The SCP2 then sends (826) a CCR request successful message to the master SCP 101. The SCP1 then credits (827) the subscriber A's account with the requested amount. The SCP1 finally sends (828) a message to subscriber A indicating successful transaction along with the amount credited. The various actions in method 800 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 8A, 8B, 8C may be omitted.

[0035] FIG. 9A, 9B, 9C are flowcharts describing a method of inter- operator subscriber to subscriber collaborative charging, according to embodiments disclosed herein. A collaborative charging method allows the subscribers involved in a voice/video/sms call to share call charges by a fraction specified by calling subscriber. Subscriber A of OP1 initiates a request (901), requesting the Subscriber B to pay partially/wholly for the next call towards him by subscriber A. The subscriber B belongs to operator 2-OP2. The request is sent by the subscriber A to his/her respective SCP either through a USSD or SMS request. A sample USSD Request sent by Calling Party A for establishing collaborative charging relationship with Called Party B for the following call is: * < ACCESS CODE> * <FRACTION CHARGE> * <MSISDN of B>. The SCP1 of OP1 receives (902) the request specifying the fraction of total call charges (SO - SO % of call charges; 100 - complete call charges) to be levied on called party 'B' along with the MSISDN number of subscriber B. The charging of subscriber 'B' may be done in accordance to the charging rates applicable to subscriber 'A' as per the subscribed tariff plan. The SCPl then requests (903) subscriber A to enter a PIN number for authentication of the subscriber A. The SCPl then checks (904), if the PIN entered by subscriber A is correct. If the PIN is incorrect, the subscriber A is requested

(905) to enter the PIN number again. If the PIN is correct, the SCPl checks

(906) if subscriber A is subscribed to the service. If the subscriber A is not subscribed to the service, subscriber A is sent (907) a message requesting to subscribe to the service. Next SCPl shall check if the invoked inter- operator function requires a pre-defined agreement between party-A and party-B, or if the access would be granted dynamically by responding party 'B' during the call. For cases such as balance withdrawal/deposit, a predefined agreement may not be required. The OP2 subscriber (responding entity) may be asked to either allow/disallow the service request from subscriber of OP1 during the triggered request itself. However for cases, such as these, one-time pre-defined agreement between the called and the calling party may be stored at OPl 's SCP eliminating the need for in-call request from OP2's subscriber. SCPl calculates the rate at which the called party shall be charged based on the fraction requested from the calling subscriber. The remainder of charges shall be borne by the Calling party. It is important to note here that Operator may levy a periodic or volume based fixed charge on the calling party for such calls. SCP1 sends (908) a CCR - credit control request to the master SCP. The CCR request is sent using a diameter protocol message containing (909) the rate at which called party needs to be charged, B's MSISDN, A' s MSISDN and the operator ID of subscriber A. The master SCP 101 determines (910) operator ID of subscriber B using the MSISDN - SCP ID-SCP address mapping table. The master SCP then checks (911) if the SCP ID of OP1 is valid. If the SCP ID is invalid, SCP1 of OP1 is denied (912) access to master SCP service. If the SCP ID of OP1 is valid, the master SCP 101 then checks (913) if OP2 gives rights to OP1 for performing collaborative charging function-F7. If OP2 does not give -access right over OP1 for function F7, a function is not supported message sent (914) to SCP1 and the subscriber A. If OP2 gives access right to to OP1, the master SCP sends (915), the CCR request to SCP2 IP address of OP2 whose address is derived from the MSISDN - SCP ID-SCP address mapping table. The SCP2 of OP2 receives (916) the request containing the rate at which the called party 'B' is to be charged along with subscriber A's and B's MSISDN details. SCP2 sends (917) a a CCR response acknowledgement to master SCP. The SCP2 then checks (918), if subscriber B has sufficient balance in the account for the transaction. If the subscriber B does not have sufficient balance, the service is denied (919) and a failure message is sent to subscriber A and SCP1. If subscriber B has sufficient balance, for the transaction, SCP2 sends (920) a USSD menu/message to subscriber B requesting permission for allowing the next call from subscriber 'A' to be charged to be charged on his account at the defined rate. Subscriber B of OP2 responds to USSD Menu based request by selecting either the allow or disallow option. If subscriber B does not, give (921) permission, service is denied (922) to subscriber A and a failure message is sent to subscriber A via the master SCP 101. If subscriber B allows collaborative charging, the SCP2 of OP2, sends (923) a CCR request successful message to the master SCP 101. In addition SCP2 also makes a note of the fact that for the next call from subscriber Ά' , subscriber 'B' shall be charged at a definite rate as specified by Master SCP. The SCP1 finally sends (924) a message to subscriber A indicating successful operation The call charges of next call made by subscriber 'A' to subscriber 'B' is shared between the two subscribers. The various actions in method 9000 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 9A, 9B, 9C may be omitted.

[0036] FIG. 10A, 10 B are flowcharts describing another inter- operator user case for subscriber-to-subscriber inter-operator voucher based recharge, according to embodiments disclosed herein. An inter-operator voucher based recharge allows a subscriber A belonging to Operator OP1 to recharge the account of another subscriber B belonging to Operator OP2. Subscriber A of OP1 initiates a request (1001), requesting to recharge another subscriber B. The subscriber B belongs to operator 2-OP2. The request is initiated by the subscriber A either through USSD or through SMS request or through an Interactive Voice Response System of OP1, presenting the voucher number and MSISDN of subscriber B. The vouchers may be a special voucher cards provisioned by the operator OP1 for specific cases of inter-operator voucher based recharge. The SCPl of OP1 receives (1002) the request, specifying the recharge voucher details and the MSISDN of subscriber B. The SCPl then requests (1003) subscriber A to enter a PIN number for authentication of the subscriber A. The SCPl then checks (1004), if the PIN entered by subscriber A is correct. If the PIN is incorrect, the subscriber A is requested (1005) to enter the PIN number again. If the PIN is correct, the SCPl checks (1006) if subscriber A is subscribed to the service. If the subscriber A is not subscribed to the service, subscriber A is sent (1007) a message requesting to subscribe to the service. SCPl derives authenticates the voucher card number and derives the associated amount to be credited to the account. SCPl sends (1008) a CCR-credit control request to the master SCP. The CCR request is sent using a diameter protocol message containing (1009) the amount to be credited, the MSISDN of the Subscriber B, the MSISDN of the Subscriber A and the operator ID of OP1. The master SCP 101 determines (1010) operator ID of subscriber B using the MSISDN - SCP ID-SCP address mapping table. The master SCP then checks (1011) if the SCP ID of OP1 is valid. If the SCP ID is invalid, SCP1 of 0P1 is denied (1012) access to master SCP service. If the SCP ID of OP1 is valid, the master SCP 101 then checks (1013) if OP2 gives rights to OP1 for performing voucher based recharge - function F8. If OP2 does not give 1013-access right over OP1 for function F8, a function is not supported message sent (1014) to SCP1 and the subscriber A. If OP2 gives access right to OP1, the master SCP sends (1015), the CCR request to SCP2 IP address of OP2 whose address is derived from the MSISDN - SCP ID-SCP address mapping table. The SCP2 of OP2 receives (1016) the request containing subscriber A's MSISDN, subscriber B's MSISDN and the amount to be credited to subscriber B's account. The SCP2 sends (1017) a CCR receipt response acknowledgement to master SCP. The SCP2 of OP2 credits (1018) the amount to subscriber B's account and, sends (1019) a CCR request successful message to the master SCP 101. In addition SCP2 also sends (1020) a notification to subscriber B, indicating that his account has been credited by the respective amount by MSISDN Ά". The SCP1 finally sends (1021) a message to subscriber A indicating successful operation. The various actions in method 1000 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 10A, 10 B may be omitted.

[0037] FIG. 11 illustrates local SCP functions, according to embodiments disclosed herein. The master SCP may allow a subscriber belonging to one local SCP of an operator network, to hold multiple linked accounts with other network operators. Such subscribers may be allowed to manage and control inters operator services as well as services within each operator network. For example, a business running subscriber holding such an account can link multiple user accounts and use this system for transferring weekly income to users. In case when a subscriber uses different operator services in different cities, he might wish to control and manage all his user accounts from everywhere and might require inter- operator services too. The transmitter 202 sends across reply messages to the respective SCP in the respective operator network. The local SCP function shows the base account along with the base account number of the subscriber. The screen shows accounts linked to the base account along with the operator ID. The local function shows the base account along with the base account number of the subscriber. It shows one of the linked accounts. It also shows the services which the subscriber of the base operator can perform on OP2 using the base account number.

[0038] In an embodiment, the method facilitates dynamic sharing of relevant information among SCPs or among other network entities like SSP of Operator B and SCP of Operator A via Master SCP over Diameter Interface. This information may correspond to be information regarding the CDR data of in-roamers, roaming under operator B coverage with operator A's SCPs for billing purposes and so on. [0039] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and is not limiting. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.

Claims

1. A method for providing inter-operator value added and supplementary telephony services to multiple subscribers of multiple network operators by employing a Master Service Control Point (SCP), said method comprising receiving a service request message by said master SCP from a subscriber of operator network A for service related to a second subscriber of an operator network B; authenticating said service request message by said master SCP for analyzing access rights of said operator network A over said operator network B; processing said service by said master SCP, for said operator network A if said service is permitted; and sending a response message by said master SCP to said operator network B.

2. The method as in claim 1, wherein said access right defines the services supported by service control point of one operator for service control to another operator.

3. The method as in claim 1, wherein said method provides a generic mechanism for inter-operator feature implementations requiring respective Operator SCPs to share relevant subscriber/charging data through said Master SCP.

4. The method as in claim 1, wherein said method facilitates subscribers belonging to different operators to pay collaboratively for a specific service like such as SMS, data call.

5. The method as in claim 1, wherein said method facilitates dynamic subscriber approval for a requested inter-operator service by a subscriber of another operator.

6. The method as in claim 1, wherein said method is applicable to architectures that include IP Multimedia Service (IMS), Session Initiation Protocol (SIP), Global System for Mobile Communication (GSM).

7. The method as in claim 1, wherein said method further comprising dynamically sharing of relevant information among SCPs or other operator specific network entities via Master SCP through the provisioned diameter interface.

8. The method as in claim 1, wherein said method further comprising defining various services for processing messages between network operators and service control points; and creating new attribute value pairs for each service provider for relevant messaging between said service control points.

9. The method as in claim 8, wherein defining of services includes inter-operator services offered by said network operators connected to each other using a Master Service Control Point (SCP).

10. A Master Service Control Point for providing inter-operator services to multiple subscribers of multiple network operators, said service control point comprising storing consolidated network information on operator SCPs, operator-to-operator inter-operator service agreements; receiving a service request message from an operator network A for service related to an operator network B; authenticating said service request message for analyzing access rights of said operator network A over said operator network B; processing said service, for said operator network A if said service is permitted; and sending a reply message to said operator network B.

11. The Master Service Control Point as in claim 10, wherein said access right defines the inter-operator service access granted by service control point of one operator to service control of another operator.

12. A system in a communication network for providing inter- operator services to multiple subscribers of multiple network operators, said system comprising plurality of service control points, a Master Service Control Point, further said Master Service Control Point configured for receiving a service request message from a subscriber of an operator network A for service related to a second subscriber of an operator network B; authenticating said service request message for analyzing access rights of said operator network A over said operator network B; processing said service, for said operator network A if said service is permitted; and sending a reply message to said operator network B.

13. The system as in claim 12, wherein said system

authenticates said message to determine said access rights where said access rights defines the services supported by service control point of one operator for service control to another operator.

14. The system as in claim 12, wherein said system is further configured to facilitate subscribers belonging to different operators to pay collaboratively for a specific service like such as SMS, data call.

15. The system as in claim 12, wherein said system is further configured to provide a generic mechanism for inter-operator feature implementations requiring respective Operator SCPs to share relevant subscriber/charging data through said Master SCP.