This patent application claims priority to a foreign patent application filed in the Chinese Patent Office, having the application number 200510079122.5 and filed on Jun. 24, 2005.
1. Field of the Invention
The invention is related to the field of communications, and in particular, to IMS gateway systems and methods that validate routing to online charging systems (OCS) so that charging information for a call session are routed to the correct OCS.
2. Statement of the Problem
As set forth in the 3rd Generation Partnership Project (3GPP), an IP Multimedia Subsystem (IMS) provides a common core network having access-agnostic network architecture for converged networks. Service providers are accepting this architecture in next generation network evolution. The IMS architecture is initially defined by the 3GPP to provide multimedia services to mobile subscribers over an IP network. IP networks have become the most cost savings bearer network to transmit video, voice, and data. IMS uses the advantage of IP networks to provide multimedia services for IMS subscribers on an IMS platform. The signaling used within IMS networks is SIP protocol. IMS defines the standard SIP interface between application servers, the IMS core network (CSCF), the IMS subscriber, the IMS database (HSS), and IMS billing elements. These standards can reduce the network integration costs and let the subscriber enjoy more stable services.
On the IMS platform, the traditional supplementary services, such as call forwarding, conferencing, and call waiting could be available for IMS subscribers. Also, many new data services, such as instant messaging, video calls, video on wait, and web-based services, will also be available for the IMS subscribers.
Providing efficient IMS online charging for operator revenue generation is important to the successful deployment of IMS networks. Several 3GPP technical specifications describe online charging for IMS networks. For instance, the 3GPP TS 32.200 specification describes an online charging system (OCS) having a session-based charging function. The OCS is coupled to a call session control function (CSCF) through an IMS service control (ISC) interface. The CSCF controls a call session for a calling party or a called party and needs to communicate with the OCS over the ISC interface to provide online charging for the call session. However, an ISC interface is a service interface and does not support online charging. Therefore, in order to use the ISC interface between the CSCF and the OCS for online charging, additional functionality would unfortunately need to be added to the OCS.
In order to avoid overloading the OCS with additional functionality and to keep the online charging architecture consistent, the interface between the CSCF and the OCS may be changed to support online charging instead of adding functionality to the OCS. One option for an interface that supports online charging is to extend the ISC interface to allow for charging mechanisms. The ISC interface would then be both a service interface and a charging interface. Unfortunately, using the ISC interface as a hybrid service/charging interface may not be acceptable for standardization desired by the 3GPP.
Another option is to use the Ro interface instead of the ISC interface because the Ro interface already supports online charging. The 3GPP TS 32.296 specification suggests using the Ro interface for online charging by introducing an IMS gateway function that acts as a gateway between the CSCF and the OCS.
Unfortunately, the 3GPP TS 32.296 specification and the other 3GPP specifications do not describe how to use the IMS gateway function 102 for online charging. For instance, the specifications do not define how the IMS gateway function 102 is to operate to provide online charging. The specifications also do not resolve how the ISC interface 105, the Ro interface 107, and the CSCF 104 would function together. For instance, the specifications state that whether the CSCF 104 is directly connected to the OCS 106 via a gateway (IMS gateway function) is beyond the scope of the standardization. The physical position of the IMS gateway function 102 is in confusion in the specifications.
In addition, in one operator's network there could be multiple OCSs 106.
Provisioning of the OCS routing address for each IMS subscriber can be done at HSS 217. 3GPP TS 29.228 and 29.229 define HSS charging information to be provisioned for each subscriber in HSS 217. For online charging, each subscriber will have two OCS routing addresses provisioned as the Primary Event Charging Function Name and the Secondary Event Charging Function Name, which are mapped to primary and secondary OCSs 201-203. The primary and secondary OCSs 201-203 have this subscriber's account balance.
One problem is that the 3GPP standards definition in above specifications are not sufficient to guarantee that the OCS routing address is included in SIP messages sent to the IMS gateways 206-207 for online charging. There may be instances when the IMS gateways 206-207 receive SIP INVITE messages from S-CSCFs 210-213 without an OCS routing address or with an incorrect OCS routing address. If they receive no or an incorrect OCS routing address, then IMS gateways 206-207 need to search for OCS mapping for the IMS subscriber to route the call. There is no definition in the 3GPP and other standards on how an IMS gateway can search for OCS mapping for an IMS subscriber. There is also no definition in the 3GPP on how to validate an OCS routing address that is provided in the INVITE message.
There are many possible cases that SIP messages transmitted to IMS gateways 206-207 will not include an OCS routing address or the OCS routing address is not valid. First, HSS 217 has subscriber charging information provisioned but not correct. Second, HSS 217 has no subscriber charging information provisioned because it is optional. Third, HSS 217 has subscriber charging information provisioned but there is no charging function name and IP address mapping provisioned at the S-CSCF 210-213. Fourth, HSS 217 has subscriber charging information provisioned but S-CSCF/HSS cannot determine whether the call is an online or an offline call. The S-CSCF 210-213 may consider it an online call and route the SIP message to the IMS gateway 206-207 first. The IMS gateway 206-207 must figure out where to route the call. Fifth, a legacy subscriber has no registration data at HSS 217. The IMS call from/to legacy subscribers has no charging information mapped to the correct OCS 201-203.
It would be desirable to increase the effectiveness of OCS routing for online IMS call sessions.
The invention solves the above and other related problems by defining systems and methods that validate routing information for routing charging information to online charging systems (OCS) in an IMS network. In an IMS network, an IMS gateway system is provisioned with one or more OCS routing addresses for the subscribers of the IMS network. The provisioned OCS routing addresses are used in the IMS gateway system to validate OCS routing addresses received from a call session control function (CSCF) in messages. By validating the OCS routing addresses in the messages, the IMS gateway system advantageously routes charging information for calls to the correct or appropriate OCS.
One embodiment of the invention comprises an IMS gateway system that is coupled to a CSCF and a plurality of OCSs to provide online charging. The IMS gateway system includes a first interface for communicating with the CSCF, a second interface for communicating with the OCS, a call control system, and a subscriber database. When in operation, the call control system receives a message from the CSCF for a call session through the first interface. The call session may be already established or may be initiated by the message. The message may comprise a SIP message, such as a SIP INVITE message, or a message of another protocol. The call control system identifies an OCS routing address from the message, if an OCS routing address is included in the message. The call control system also identifies a corresponding OCS routing address from the subscriber database, if an OCS routing address is included in the subscriber database. The call control system compares the OCS routing address from the message with the OCS routing address from the subscriber database. If the OCS routing address from the message matches the OCS routing address from the subscriber database, then the call control system validates the OCS routing address from the message and/or the subscriber database. The call control system then transmits a charging request to the appropriate OCS based on the validated OCS routing address. If the OCS routing address from the message does not match the OCS routing address from the subscriber database, then the call control system transmits a charging request to the appropriate OCS based on the OCS routing address from the subscriber database.
The invention may include other exemplary embodiments described below.
The same reference number represents the same element on all drawings.
Subscriber database 316 is provisioned with a plurality of entries for a plurality of subscribers to the IMS network 300 or other services. Subscriber database 316 may be pre-provisioned or subscriber database 316 may be updated periodically. An entry for a subscriber includes at least one OCS routing address mapped to the subscriber. For instance, each subscriber may have two OCS routing addresses provisioned as the Primary Event Charging Function Name and the Secondary Event Charging Function Name, which are mapped to a primary OCS and a secondary OCS where the subscriber's prepaid account balance resides. Subscriber database 316 may be indexed by a subscriber identifier (ID), a name, or some other indication of the subscriber. Subscriber database 316 may be dynamically synced up by NMS/OSS 309.
Subscriber database 316 may include all mapping information for subscribers from IMS, packet, and circuit domains. Thus, IMS gateway system 304 may route IMS calls for even legacy (both wireless and wireline) subscribers. Subscriber database 316 may also have a function to convert a point code routing address (which is used in SS7 signalling) to an IP address of one of the OCSs 306-308 in IMS network 300.
IMS gateway system 304 and the following description defines how online charging may be accomplished in an IMS network 300. As a brief overview, IMS gateway system 304 in
In step 407, call control system 314 compares the OCS routing address from the message to the OCS routing address from subscriber database 316. If the OCS routing address from the message matches the OCS routing address from subscriber database 316, then the call control system 314 validates the OCS routing address from the message and/or the subscriber database 316 in step 408. To match in this embodiment means that the two routing addresses include information that points to the same OCS. One or both of the OCS routing address may be encrypted or otherwise altered so that the two OCS routing addresses are not exactly the same. However, the two OCS routing address will point to the same OCS if they match. Call control system 314 then transmits a charging request to the appropriate OCS 306-308 based on the validated OCS routing address in step 409.
If the OCS routing address from the message does not match the OCS routing address from subscriber database 316, then the call control system 314 transmits a charging request to the appropriate OCS 306-308 based on the OCS routing address from the subscriber database 316 in step 410. Call control system 314 may also update the OCS routing address in the message which loops back to CSCF 302. Call control system 314 may also query NMS/OSS 309 for the most updated OCS routing address, and update subscriber database 316 with the updated OCS routing address.
Alternatively, call control system 314 may query NMS/OSS 309 for the most updated OCS routing address before transmitting the charging request. Call control system 314 may then transmit the charging request to the appropriate OCS 306-308 based on the updated OCS routing address provided by NMS/OSS 309.
Alternatively, call control system 314 may query NMS/OSS 309 for the most updated OCS routing address before transmitting the charging request. Call control system 314 may then transmit the charging request to the appropriate OCS 306-308 based on the updated OCS routing address provided by NMS/OSS 309.
Alternatively, call control system 314 may query NMS/OSS 309 for the most updated OCS routing address before transmitting the charging request. Call control system 314 may then transmit the charging request to the appropriate OCS 306-308 based on the updated OCS routing address provided by NMS/OSS 309.
In any of
Subscriber database 316 may also include subscriber online/offline charging information. Asssume a subscriber has an offline charging account with the service provider but has no online charging account. The CSCF 302 routes the message to IMS gateway system 304 when the CSCF 302 has no subscriber account data whether the call is for online or offline charging. IMS gateway system 304 will not route the call to an OCS 306-308 because IMS gateway system 304 routes online charging messages to the OCS, not offline charging messages. IMS gateway system 304 may return an error message to CSCF 302 with offline charging information included in the message, so that CSCF 302 will re-direct the call to the offline charging system (not shown).
For this embodiment, a calling party 801 dials a number for a called party 803 to place a call (such as an event-based call) to called party 803 over IP network 820. Assume that both calling party 801 and called party 803 are IMS subscribers. IP network 820 routes the call to P-CSCF 831 by transmitting a SIP INVITE message (arrow 872) to P-CSCF 831. P-CSCF 831 transmits the INVITE message to S-CSCF 832 (arrow 873).
S-CSCF 832 checks the INVITE message header to determine if the service profile for calling party 801 is already downloaded from HSS 834. If the service profile for calling party 801 is already downloaded from HSS 834, then S-CSCF 832 uses that service profile. If the service profile is not already downloaded, then S-CSCF 832 downloads the service profile for calling party 801 from HSS 834 by transmitting a service assignment request (SAR) message to HSS 834 (arrow 874). HSS 834 returns a service assignment answer (SAA) message that includes the IMS service profile for calling party 801 (arrow 875). S-CSCF 832 stores the service profile data for calling party 801 locally. For the performance consideration, the service profile may be kept for a while. If no more calls are made from the same subscriber after a pre-defined period of time, S-CSCF 832 clears the data and downloads the data again if the subscriber makes a new call. S-CSCF 832 processes the service profile for calling party 801.
The service profile indicates charging information for calling party 801, such as an OCS routing address or an offline charging service node address. Assume calling party 801 has a prepaid account with the service provider and the call is considered an online charging call. The OCS routing address in the service profile is used to route the call for online charging purposes.
S-CSCF 832 further processes the service profile for calling party 801 to decide if it needs to trigger AS 836. If S-CSCF 832 determines that an AS 836 is needed, then S-CSCF 832 transmits the INVITE message to the AS 836 (arrow 876). AS 836 goes through the service of calling party 801, and returns the INVITE message back to S-CSCF 832 (arrow 877).
Because there is online charging for this call, S-CSCF 832 needs to transmit a charging request to OCS 837. S-CSCF 832 may or may not have the OCS routing address for OCS 837. S-CSCF 832 does have the IP address of IMS gateway system 838, so S-CSCF 832 transmits the INVITE message to IMS gateway system 838 (arrow 878). If S-CSCF 832 has the OCS charging information name, then it converts the OCS charging information name into an OCS routing address and transmits the OCS routing address in the INVITE message.
IMS gateway system 838 compares the OCS routing address from the INVITE message to a corresponding OCS routing address stored in a subscriber database within IMS gateway system 838. If the OCS routing address is missing or there is not a match, then IMS gateway system 838 queries NMS/OSS 880 to download the most updated OCS routing address (arrow 879) and updates the subscriber database within IMS gateway system 838. The updated OCS routing address is used to contact the correct OCS 837. If the two OCS routing addresses match, then IMS gateway system 838 validates the OCS routing address from the message, and transmits a charging request to the appropriate OCS 837 based on the validated OCS routing address.
IMS gateway system 838 transmits a Credit Control Request (CCR) message of Diameter Ro interface to the appropriate OCS 837 for online charging (arrow 880) based on the validated OCS routing address. OCS 837 validates the prepaid account balance for calling party 801. If there is a sufficient balance in the prepaid account for calling party 801, then OCS 837 grants the call and transmits a Credit Control Answer (CCA) message of Diameter Ro interface back to IMS gateway system 838 (arrow 881). OCS 837 deducts the call cost from the prepaid account for calling party 801. IMS gateway system 838 transmits the INVITE message with OCS 837 approval to S-CSCF 832 (arrow 882).
S-CSCF 832 queries the ENUM database 840 with the E164 number of the called party 803 to get the called party's URL address (arrow 883). S-CSCF 832 then transmits the INVITE message to a pre-arranged I-CSCF 853 based on the URL (arrow 884). I-CSCF 853 transmits a Location Information Request (LIR) message for the called party 803 to HSS 854 (arrow 885). HSS 854 returns a Location Information Answer (LIA) message to I-CSCF 853 (arrow 886).
If I-CSCF 853 gets back an LIA message from HSS 854, then I-CSCF 853 transmits the call to S-CSCF 852 (arrow 887). When the terminating S-CSCF 852 receives the INVITE message, terminating S-CSCF 852 checks the INVITE message header to see if the called party 803 is an IMS subscriber. If the service profile for called party 803 is already downloaded from HSS 854, then S-CSCF 852 uses that service profile. Otherwise, S-CSCF 852 downloads the service profile for called party 803 from HSS 854 using a SAR message (arrow 888). HSS 854 returns an SAA message that includes the service profile for called party 803 (arrow 889). S-CSCF 852 stores the service profile for called party 803 locally. For performance consideration, the service profile may be kept for a while. If no more calls are made from the same subscriber after a pre-defined period of time, S-CSCF 852 clears the data and downloads the data again if the subscriber makes a new call. S-CSCF 852 processes the service profile for called party 803.
The service profile for called party 803 indicates charging information, such as an OCS routing address or an offline charging service node address. Assume called party 803 also has a prepaid account with the service provider and the call is considered an online charging call. The OCS routing address is used to route the call for online charging purposes.
Terminating S-CSCF 852 further processes the service profile of called party 803 to decide if it needs to trigger AS 856. If S-CSCF 852 determines a need for AS 856, then S-CSCF 852 transmits the INVITE message to the AS 856 (arrow 890). AS 856 goes through the terminating service of called party 803 and returns the INVITE message back to terminating S-CSCF 852 (arrow 891).
Because there is online charging for this call, S-CSCF 852 needs to transmit a charging request to OCS 857. S-CSCF 852 may or may not have the OCS routing address for OCS 857. S-CSCF 852 does have the IP address of IMS gateway system 858, so S-CSCF 852 transmits the INVITE message to IMS gateway system 858 (arrow 892). If S-CSCF 852 has the OCS charging information name, then it converts the OCS charging information name into an OCS routing address and transmits the OCS routing address in the INVITE message.
IMS gateway system 858 compares the OCS routing address from the INVITE message to a corresponding OCS routing address stored in a subscriber database within IMS gateway system 858. If the OCS routing address is missing or there is not a match, then IMS gateway system 858 queries NMS/OSS 880 to download the most updated OCS routing address (arrow 893) and updates the subscriber database within IMS gateway system 858. The updated OCS routing address is used to contact the correct OCS 857. If the two OCS routing addresses match, then IMS gateway system 858 validates the OCS routing address from the message, and transmits a charging request to the appropriate OCS 857 based on the validated OCS routing address.
IMS gateway system 858 transmits a Credit Control Request (CCR) message of Diameter Ro interface to OCS 857 for online charging (arrow 894) based on the validated OCS routing address. OCS 857 validates the prepaid account balance for called party 803. If there is a sufficient balance in the prepaid account for called party 803, then OCS 857 grants the call and transmits a Credit Control Answer (CCA) message of Diameter Ro interface back to IMS gateway system 858 (arrow 895). OCS 857 deducts the call cost from the prepaid account for called party 803. IMS gateway system 858 transmits the INVITE message with OCS 857 approval to S-CSCF 852 (arrow 896).
Terminating S-CSCF 852 then transmits the INVITE message to P-CSCF 851 of called party 803 (arrow 897). P-CSCF 851 transmits the INVITE message to IP network 820 to connect the call to called party 803 (arrow 898).
Number | Date | Country | Kind |
---|---|---|---|
200510079122.5 | Jun 2005 | CN | national |