Communication methods and systems

A system arranged to receive an authorization request from an application server using a first communication protocol; identify a charging server associated with the authorization request from a plurality of charging servers, each charging server associated with a respective charging server communication protocol; and communicate with the identified charging server using the respective charging server communication protocol.

This application claims priority from European Patent Application 07301551.3, filed on Nov. 15, 2007. The entire content of the aforementioned application is incorporated herein by reference.

BACKGROUND TO THE INVENTION

Telecommunication systems often provide multiple services or content to an end user. Examples of services include voice calls, video calls, messaging and other data services. A difficulty in providing such content and services is the large diversity of protocols supported by billing and charging systems operated by content/service providers. All applications and services on an application server must be able to interface with those various billing and charging systems to enable charging and billing users for use of the applications and services. This leads to complex and costly integration projects for adapting applications and services to the various billing and charging systems. In addition to cost, this can also significantly delay the availability of the application or service to the market, thus reducing service providers' revenues.

It is an object of embodiments of the invention to at least mitigate one or more of the problems of the prior art.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

Embodiments of the invention relate to communication methods and systems. For example, embodiments of the invention relate to a telecommunication system where content or services are provided by one or more applications on an application sever. The content or services are supplied to a user agent (such as, for example, a mobile phone, laptop computer, PDA and the like) that is typically operated by an end user. Applications on the application server communicate with a plurality of charging servers via a charging gateway. The charging gateway presents a common (generic) interface to the applications such that the applications communicate with the charging gateway using a common protocol that is independent of the charging server currently being communicated with. The charging gateway implements the required communication protocol in communications with the charging server. Thus, applications need only be configured to use one interface and/or protocol, and may still communicate with a plurality of charging servers implementing a plurality of communication protocols. The charging servers do not need reconfiguration to operate with embodiments of the invention as the charging gateway implements communication protocols used by the charging servers.

FIG. 1shows an example of a system100according to embodiments of the invention. The system100includes a user agent102. The user agent102is a device that is accessed by a user such that the user has access to and/or can use applications and services of the system100and can access content supplied by the applications. For example, the content and services may include one or more of voice calls, video calls, messaging, data services (for example internet browsing) and other services and/or content. The user agent102may comprise, for example, a mobile device such as a mobile telephone, PDA, laptop/notebook computer or the like. Alternatively, the user agent102may comprise another device such as, for example, a personal computer (PC). Embodiments of the invention are not dependent on the type of user agent102and the user agent102may comprise any device or devices capable of accessing applications and services such as those indicated above. The user agent102may comprise an application that is operated by a user on a device (such as a fixed or mobile device).

The system100also includes an applications server104. The applications server104is a server on which applications are running or can be running. These applications can be accessed by the user agent102to provide content and/or services to the user agent102. The applications server104may comprise, for example, a Telecom Applications Server (TAS). The TAS may comprise a computing system including an operating system, application server software (for example, JBoss) and applications.

The user agent102may communicate with the applications server104over a wired or wireless communications link, as appropriate. For example, where the user agent102is a mobile telephone and the applications server104is a TAS, the user agent102and applications server104may communicate, at least in part, over a mobile telephone communications link such as, for example, GSM, 3G and the like. In certain networks, such as internet protocol (IP) networks, a protocol such as SIP or H.323 may be used for communications between the user agent102and the applications server104(transfer of media may be done, for example, using Real-time Transport Protocol, RTP). In legacy networks, this protocol may be, for example, ISDN or ISUP for signalling and TDM for media transfer (for example, voice, messaging and data transmission), whereby communications flow between the user agent and a media server, for example, which is controlled by the applications server.

The applications server104may also communicate with a user profile server106. The user profile server106may store a user profile associated with a user of the user agent106. For example, a user profile may store one or more of the name, address, telephone number, subscription data (whether the user pays for services in advance or after usage), account status, presence status (whether or not the user is currently in a telephone conversation) and other information. The user profile server106may comprise, for example, a LDAP (Lightweight Directory Access Protocol) server in a corporate network, a Home Location Register (HLR) accessible using MAP (mobile application part) in a mobile telecommunications network, or a LDAP or SQL database or Home Subscriber Server (HSS) in IP networks.

The system100also includes a charging gateway108. The charging gateway108includes a number of modules. The gateway108may include any number of modules, although three modules110,112and114are shown. Each module may communicate with a respective charging server. For example, the first module110may communicate with a first charging server116, the second module112may communicate with a second charging server118, and the third module114may communicate with a third charging server120. In embodiments of the invention, the modules comprise software modules that are running or can be running on the charging gateway108(which may comprise, for example, a server). Software modules may be added and/or removed, for example, without interrupting operation of the charging gateway and thus not interrupting the availability of content and/or services requested (or to be requested) by the user agent. In alternative embodiments of the invention, one, some or all of the modules may comprise other types of module, such as hardware modules, for example. Such a modular design may allow modules to be added or removed as and when required. This may be simpler than, for example, reprogramming a non-modular charging gateway. In other embodiments of the invention, however, a non-modular charging gateway may be used instead that selects and communicates with an appropriate charging server based on communications received from the application server104.

Each module110,112and114communicates with its respective charging server116,118and120using a communication protocol that is used by the respective charging server. For example, the first charging server116may comprise an Online Charging System (OCS) charging server that uses the CCA (Credit Control Application) protocol (based on the Diameter protocol) for communications. Thus, the first module110in the charging gateway108may use the CCA protocol to communicate with the first charging server116.

In another example, the second charging server118may comprise a SCP (Service Control Point) server that uses the CAP (CAMEL Application Part) protocol for communications. Thus, the second module112may use the CAP protocol to communicate with the second charging server118.

In another example, the third charging server120may comprise a Prepaid Server (PPS) that communicates using the MBI (Message-Based Interface) protocol. Thus, the third module114may communicate with the third charging server120using the MBI protocol.

In embodiments of the invention, there may be any number of charging servers. Each charging server may communicate with a module in the charging gateway108using a respective communications protocol, although a protocol may be used by multiple charging servers. A module in the charging gateway108typically uses one protocol to communicate with one charging server, although in alternative embodiments a module may use more than one communications protocol and/or communicate with more than one charging server.

The applications server104may communicate with the charging gateway108using a single interface and protocol. The charging gateway108forwards appropriate information from the applications server104to the appropriate charging server using the appropriate module, and returns appropriate information in any reply from the charging gateway to the applications server104using the protocol for communications between the applications server104and the charging gateway108. Therefore, communications between the applications server104and the appropriate charging gateway116are effected, whereby the applications server uses a single protocol for communications with the appropriate charging server, and this protocol is not dependent on the charging server. This is enabled by the presence of the charging gateway108, which effectively translates communications from the applications server104into the appropriate charging server communication protocol for communicating with the appropriate charging server.

Thus, the appropriate charging server is identified. This may be done implicitly, for example if the application server104communicates with only one module in the charging gateway108then the charging server associated with the module is implicitly identified. Alternatively, this may be done explicitly, for example the charging server is identified (or the identification can be derived) from information in communications sent between the application server104and the charging gateway108.

In embodiments of the invention, the modules110,112and114are Java beans, i.e. small applications expressed in the Java programming language. The Java programming language is a well-known language. The charging gateway108may include appropriate software and/or hardware to enable execution of one or more of the Java beans. In such embodiments, the protocol between the applications server104and the charging gateway108may be the RMI (Remote Method Invocation) protocol, a remote procedure call protocol whereby one or more selected Java beans may be invoked by the applications server104. For example, a Java bean that is not being executed may be executed by the charging gateway when it is required. Alternatively, a currently executing Java bean may be manipulated when required.

The application server may select one of the modules110,112and114based on one or more of a number of factors. For example, information from the user profile server, such as the user's identity and/or the user's account status and information, and/or any other information such as the charging servers that are available and/or the application that is communicating with a charging server may be used by the application server for selecting which module110,112and114to use for communicating with a charging server. In certain embodiments, a user is typically associated with one charging server, and thus when the user tries to use an application or service, the application server104may select the appropriate module in the charging gateway108to communicate with the associated charging server. Information identifying the appropriate module and/or charging server may be stored, for example, in the user profile server106, for example in a user profile associated with the user. In some embodiments, for example, the single charging server associated with the user is a charging server associated with a network service provider of the user (or the user agent). The network service provider provides network services such that the user agent may be used to access content and/or services over the network.

FIG. 2shows an example of communications between the user agent (UA)102, applications server (AS)104, first module110and first charging server116. In this example, the first module110is a Java bean capable of communicating, using the Diameter CCA (Credit Control Application) protocol, with the first charging server116which is an OCS (Online Charging System) server. Communications between the UA102and the AS104in this example use SIP (Session Initiation Protocol). In this example, the user agent102is attempting to initiate a video call with another party (not shown) such as, for example, another user agent, a video portal or a video content delivery service.

The user agent102first sends a SIP invite202to the application server104. The invite202is a service request that indicates that the user agent102is inviting another user or service to participate in a session (that is, a voice session, video session, messaging session, data session and the like), i.e. requesting a service, or requesting content (in this example, the session is a video call session). The invite202includes information indicating the content or service required by the user agent102(for example, where the user agent is requesting a session with another user agent, the invite202may identify the user agent, for example by indicating the called party's SIP URI. In reply, the application server104sends a SIP ringing communication204back to the user agent102, indicating to the user agent204that the request for the content or service is being processed.

The application server104may at this point, if required, request information from the user profile server106(seeFIG. 1) from which the appropriate module and/or charging server can be identified. The identified charging server is the server that can perform the appropriate authorization for the user to use the requested content or service and can perform charging and billing activities in relation to the content or service. The identified module is the module that can communicate with the appropriate charging server associated with the user agent or user.

The application server104then sends a ReserveUnitReq authorization request communication206to the identified first module110(i.e. the module that can communicate with the appropriate charging server). The ReserveUnitReq communication206includes sufficient information for the charging server to carry out authorization, charging and billing activities and as such may identify the user agent102(or the user using the user agent102). In embodiments of the invention using the RMI protocol between the application server104and the charging gateway108, the ReserveUnitReq authorization request also invokes the appropriate module (for example, causes the appropriate module to begin executing).

The first module110sends a Credit Control Request (CCR) [Initial] communication208to the first charging server116. The CCR [Initial] request contains sufficient information for the charging server116to determine whether or not the user agent102should be allowed access to the requested content or service. This determination is indicated in the response210from the charging server116to the module110, which comprises a Credit Control Answer (CCA) communication. The module110then sends a ReserveUnitRes authorization response communication212to the application server104. The ReserveUnitRes communication212indicates whether or not the user agent is allowed to access the requested content or service, based on the CCA communication210from the charging server116. The communication212may also, in embodiments of the invention, indicate an amount of service to be reserved, such as, for example, time, volume and/or amount of data.

If the user agent102is authorized by the charging server116to access the requested content or service, the application server104sends a SIP “200 OK” communication214to the user agent102. The user agent102then sends a SIP ACK acknowledgement216to the application server104. Delivery of the requested service or content is then effected between the user agent102and the application server104as indicated by the arrow218(or alternatively between the user agent102and a content server, not shown, which may be controlled by the application server104). This may involve the user agent102and/or application server104communicating with third parties (not shown) depending on the requested content or service.

Once the content or service has been delivered, the user agent102sends a SIP BYE communication220to the application server104to terminate the content/service delivery. The application server104sends a SIP “200 OK” confirmation back to the user agent102in reply. The application server also sends a DebitUnitReq communication224to the module110. This communication224indicates that provision of the content or service has finished, and that an appropriate charge should be applied to an account associated with the user agent102(or user using the user agent102), for example debit of a monetary amount, usage allowance and the like. The module110sends a CCR [Terminate] communication226to the charging server116to indicate to the charging server116that the provision of the content or service is complete. The charging server sends a CCA communication228back to the module110. This communication228may indicate information relating to the cost of the provision of the content or service to the user agent102. Finally, a DebitUnitRes communication230is sent from the module110to the application server104to indicate to the application server104that charging and billing by the charging server116is complete (or, at least, the charging server is in possession of sufficient information to carry out the appropriate charging and billing). This communication may, in embodiments of the invention, include information relating to the cost of provision of the content or service.

In this way, charging and billing is effected by the charging server116while the application server104communicates with the charging gateway108(for example, communicates with the module110within the charging gateway108) using only a specific predefined protocol that is not dependent on a protocol used by the charging server116.

FIG. 3shows another example of communications300within the system100. More specifically,FIG. 3shows an example of communications300between the user agent (UA)102, applications server (AS)104, second module112and second charging server118. In this example, the second module112is a Java bean capable of communicating, using the CAP (CAMEL Application Part) protocol, with the second charging server118which is a SCP (Service Control Point) server.

Communications302-306,312-324and330are substantially identical to corresponding communications202-206,212-224and230respectively as described above in respect ofFIG. 2. The example shown inFIG. 3is different to that shown inFIG. 2as a different charging server is used and communications between the charging gateway108and the charging server use a different protocol, and so a different module is used for communications between the charging gateway108and the charging server.

Once the ReserveUnitReq communication306has been received by the module112, a CAP protocol Begin [InitialDP] communication308is sent by the module112to the charging server118. The communication308contains sufficient information for the charging server118to determine whether or not the user agent102is allowed access to the requested service or content. If the user agent is allowed access to the requested service or content, then the charging server118sends a Continue [Continue,RequestReportBCSMEvent,ApplyCharging,FurnishChargingInformation] communication310to the module112, and the module112sends a ReserveUnitRes communication312to the application server104.

Once the module112has received the DebitUnitReq communication324from the application server104, the module112sends an End [EventReportBCSM, ApplyChargingReport] communication326to the charging server118, indicating that provision of the service or content has finished. The module112then sends a DebitUnitRes communication330back to the application server104.

FIG. 4shows another example of communications400within the system100. More specifically,FIG. 4shows an example of communications400between the user agent (UA)102, applications server (AS)104, third module114and third charging server120. In this example, the third module114is a Java bean capable of communicating, using the MBI (Message-Based Interface) protocol, with the third charging server120which is a PPS (Prepaid Server).

Communications402-406,412-424and430are substantially identical to corresponding communications202-206,212-224and230respectively as described above in respect ofFIG. 2. The example shown inFIG. 4is different to that shown inFIG. 2as a different charging server is used and communications between the charging gateway108and the charging server use a different protocol, and so a different module is used for communications between the charging gateway108and the charging server.

Once the ReserveUnitReq communication406has been received by the module114, the module114sends an AuthorizeReq communication408to the charging server120according to the MBI protocol. The communication408contains sufficient information for the charging server120to determine whether or not the user agent102is allowed access to the requested service or content. If the user agent102is allowed access to the requested service or content, then the charging server120sends an AuthorizeConf communication410to the module114, and the module114sends a ReserveUnitRes communication412to the application server104.

Once the module114has received the DebitUnitReq communication424from the application server104, the module114sends an EndReq communication426to the charging server120, indicating that provision of the service or content has finished. The charging server120replies to the module114with an EndConf message428. The module114then sends a DebitUnitRes communication430back to the application server104.

FIG. 5shows an example of a case500where the appropriate charging server116does not authorize the user agent102(or user using the user agent102) to access the requested content or service. Communications502to508are substantially identical to corresponding communications202to208shown inFIG. 2. However, when the charging server116receives the CCR [Initial] communication508from the CCA bean (module)110, the charging server116determines that the user agent102(or user) is not authorized to access the requested content or service. Therefore, the charging server116returns a CCA [Terminate] communication510to the module110indicating that authorization has been refused. This is reflected in the subsequent ReserveUnitRes communication512from the module110to the application server104. The application server104then returns a “403 Forbidden” SIP communication514to the user agent102. The user agent102may return an acknowledgement to the application server104. The user agent102thus knows that it is not authorized to access the requested content or service, and may take appropriate action (for example, by displaying an error message). Communications between the application server104and module110use the predetermined communication protocol that does not depend on the protocol used for communications between the module110and the charging server116.

FIG. 6shows an example of a computing system600that may be used with embodiments of the invention. The computing system600comprises a data processor602and a main memory604. The computing system600also includes at least one communications device606for communicating with networks and/or other systems and devices. The system600may also include a permanent storage device such as a hard disk608. The system600may also include an input device (not shown) such as a mouse and/or keyboard, and/or a display device (not shown).

Where a server is indicated above, the server may comprise a physical device such as a computing system or may comprise multiple such computing systems. Alternatively, a server may comprise a virtual or logical server or an abstract concept whereby multiple “servers” are combined onto one or more physical devices.

Where communications between two entities are described, such as between two servers or between a user agent and a server, the communications may use one or more wired and/or wireless networks for transmission between the entities. Where the networks include wireless networks, one or more of a number of wireless technologies may be used, such as, for example, GSM, 3G, 802.11, WiMAX and/or other wireless technologies.

Multiple modules may be implemented within the charging gateway that are present for the purposes of redundancy and/or load balancing and sharing. For example, two or more modules serving the same purpose (communication using a particular protocol and/or with a particular charging server) may be implemented in the charging gateway such that if one module fails, another can be invoked, thus providing high availability. Additionally or alternatively, two or more modules may be implemented such that load may be balanced between the modules. For example where two modules are implemented on separate servers, where the combined servers comprise a single charging gateway, load may be balanced between the modules to balance the load between the servers.

Embodiments of the invention are suitable for use with both offline and online charging. For example, online charging is where charges are confirmed and effected in real-time with the appropriate charging server, whereas offline charging is where charges are confirmed in batches which are processed after the content or service has been deleted.