Patent Application
20070124254
This invention relates to the charging of end users for the use of communications networks.
End users of an Internet Protocol (IP) network, such as a private or public internet or intranet may communicate with the IP network via an access network. The end user uses an end user equipment such as a mobile or stationary telephone or computing device connected to the access network in order to send and receive communications over the IP network. The IP network may be made up of several sub-networks interfaced with each other.
The access network may be a packet switched network, such as a General Packet Radio Service (GPRS) network as defined by the Third Generation Partnership Project (3GPP). The IP network and the access network are generally interfaced by a gateway node of the access network. Where the access network is a GPRS network the gateway node will typically be a Gateway GPRS Support Node (GGSN). The gateway node transports data packets between the access network and the IP network. For charging purposes the gateway node, or a network entity associated with the gateway node, identifies packet streams or service flows between an end user connected to the access network and the IP network. Each packet stream or service flow is a flow of data transported between the access network and the IP network via the gateway node and associated with a particular application, service or group of applications and services, such as browsing on a particular site of the IP network or a VoIP (Voice over IP) or multimedia call carried over the IP network.
To facilitate real-time pre-paid charging of the end user, the gateway node requests charging vouchers from a credit control function of the network, for example a Service Control Point (SCP) or Online Charging System (OCS), for each service flow it carries. These charging vouchers or tokens granted by the OCS represent a right of the end user to send and/or receive a set volume of data over a certain service flow carried by the gateway node and or to send and/or receive data over a certain service flow carried by the gateway node for a set time period. When the end user requests resources for a new service flow from the gateway node, the gateway node requests a voucher for that service flow from the OCS. Before the OCS grants a voucher it checks that the end user's account has a credit level equal to or above the value of the voucher. When the OCS grants the voucher it either reduces the end user's account credit level by the relevant amount or it reserves the relevant amount of credit so that other applications cannot use that reserved amount.
In prior art systems the gateway node must obtain a charging voucher for each service flow it carries. When the voucher is granted the gateway node, for example the GGSN, consumes the voucher, for example by counting the number of bytes carried in the relevant service flow and deducting a corresponding amount from the voucher. In addition or alternatively, the voucher may expire after a predetermined time period. When the voucher is used up or expires, the gateway node must obtain a further voucher from the OCS or have the voucher re-authorized by the OCS. If the end user does not consume all of the voucher by the termination of the service flow, the voucher is returned to the OCS and the OCS credits the end user's account by the appropriate amount or releases the un-used amount from the credit reserved.
The above online charging arrangement, as applied to a GPRS access network allows usage charges to be deducted from end user's accounts in real time. These usage charges are generally based on the amount of data (in bytes) that are sent and/or received by the end user. The data sent and/or received is counted by the GGSN; the gateway node. The charging policies and the end user's account are controlled by the SCP/OCS; the credit control function. By granting vouchers on a per service flow basis, different service flows can be charged at different rates in accordance with the policy of the network operator. Also, by granting vouchers on a per service flow basis, special rates for certain data flows may be applied for a predetermined time or a predetermined volume of data (after which a further voucher at a different rate will be granted).
As end user equipments become more complex, the number of service flows typically operating simultaneously is likely to increase. The different service flows may relate to communication services such as, browsing sessions, E-mails, messaging, VoIP or multimedia calls, file transfers or system backups. Where several flows are on-going simultaneously, the gateway node has to obtain several vouchers, ie. one for each service flow. It is possible that an end user's account can become empty or completely reserved as a result of several vouchers being granted, especially where the vouchers are large. In addition, it may not be straightforward for the gateway to determine when a service flow is terminated. For example, data transfer may stop for some period, whilst the user reads a web page, and then resumes. As a result vouchers may remain granted for some time after the user has finished using a service flow and this contributes to increasing the number of vouchers granted at any one time. When the end user's account becomes empty in this situation, the next new service flow for which a voucher is requested or the next existing service flow for which a new voucher or a re-authorized voucher is requested will have this request denied. This may be despite the end user having a significant amount of credit still existing but allocated to or reserved for other vouchers. This will result in the service flow, for which a voucher is denied, being blocked. This will be confusing to the end user who believes they still have credit due to the un-interrupted operation of other service flows. Accordingly, in the prior art systems there is a problem that an end user is denied access to services while they still have credit remaining. As credit exhaustion is approached, the end user is affected by service disruption on some service flows and/or they might not be able to use their credit completely.
The present invention relates generally to a communications network wherein service flows between an end user and the network are transported via a gateway which identifies different service flows and notifies them to a credit control function of the network. The credit control function grants a cache of units representing an amount of credit and/or an amount of network resource to the gateway for the identified service flows and provides instructions to the gateway for the identified service flows which enable the gateway to share the cache between service flows, for example if there is a threat of a service flow becoming blocked due to a lack of credit in an end users account.
A service flow as identified by a gateway may correspond to one or more user data flows. Matching between user data flows and gateway service flows is based on gateway local policy or on instructions sent by the credit control function or by any external data source.
According to a first aspect of the present invention there is provided a method of charging end users for the use of a communications network according to claim 1.
According to a second aspect of the present invention there is provided a communications network according to claim 31.
The granted cache may be communicated to the gateway in a number forms, such as, for example, a number of bytes (Volume allowance) to be allowed through the gateway for the given service flow and the instructions may include a service flow-specific conversion factor, allowing the gateway to transfer units of granted caches from one service flow to another and/or to share units of granted caches between service flows. The cache may also be granted in terms of a right of the end user to send and/or receive data over a certain service flow for a set time period (Time allowance) or to send and/or receive a set volume of data over a certain service flow for a set time period (Time+volume allowance). Time may be measured either in absolute terms (i.e. the time elapsed after the token has been issued) or in terms of active time which only elapses when there is some active traffic for the given service flow (i.e. the counting of active time is frozen when a timeout expires after the latest packet in the service flow). Conversion factors to facilitate resource sharing/transferring also apply to these cases. The cache may also be granted in terms of a right of the end user to generate a given number of events (1 or more). An event in this context represents any possible match by one or more packets sent or received by the user of a generic policy in the gateway. The policy may be pre-provisioned in the gateway or sent as part of the instructions from the credit control function. Conversion factors to facilitate resource sharing/transferring also apply to these cases. The cache may also be granted in terms of combinations of data volume, time and number of events. The units of a granted cache may represent in general any measurable entity that can be counted by the gateway on the specific service flow, and any combination thereof.
The first and second aspects of the present invention facilitate the sharing of the units of a cache between service flows by the gateway based on information from the credit control function. Thus, the credit control function maintains control over issuing or reserving credit for service flows and setting charging rates to be applied to service flows. The possibility of sharing the granted caches between service flows is delegated to the gateway. This enables a more flexible charging function to be implemented so that the gateway is able to share caches between service flows where this is desirable.
The instructions for an identified service flow may specify a measure of network resource to be counted by the gateway for the service flow and an operator, for example a multiplier, to be applied to the counted amount of resource so as to enable the gateway to calculate an amount of a cache consumed by the identified service flow. By providing the gateway with the information to make the charging calculation the gateway has the information it needs to transfer or share units of caches between different service flows. Again, the control of the allocation of charging rates and the issuing or reserving of credit is within the control of the credit control function.
The instructions for an identified service flow may reference a charging pool and the gateway may, for example, in response to a trigger, identify the service flows having instructions referencing the same charging pool and perform the cache sharing procedure in relation to these service flows. In this way, the service flows funded by the same end user and having a compatible charging policy can be allocated to the same charging pool by the credit control function. Then the gateway can share the remaining units of caches granted from the end user's account between these service flows. The trigger may occur at any time, based on policy in the gateway and/or based on instructions from the credit control function. As an example, the trigger may occur when a request from the gateway to the credit control function for a cache is denied for a service flow associated with that charging pool.
In one embodiment, the gateway applies the cache sharing procedure by pooling units from caches for service flows identified in the instructions and by decrementing the resulting charging pool. The charging pool may be decremented in accordance with instructions provided by the credit control function for the service flows. Alternatively, the cache sharing procedure may involve the gateway redistributing units of the caches between service flows identified in the instructions. Different caches may have different units and so associated conversion factors may need to be applied to the units from different caches in order to form a charging pool.
The credit control function may grant the cache and the instructions for a particular service flow simultaneously. In this way the amount of signalling between the credit control function and the gateway is minimised. In response to the gateway identifying a new service flow and requesting an allocation of resource for such a flow, the credit control function issues the gateway with the instructions and the cache and thereafter, the gateway monitors the relevant service flows and decrements the cache by following the instructions, with a possibility to apply a cache sharing procedure as required and in accordance with the instructions.
The cache and the instructions for a particular service flow may be issued in a charging voucher for the service flow. In this case, the gateway may have a first operational phase in which it decrements the cache in a charging voucher for a service flow by applying basic instructions in the charging voucher to that service flow and a second operational phase in which it performs the cache sharing procedure on a plurality of charging vouchers identified by the instructions. The decision to proceed from the first phase to the second phase may be made in response to instructions from the credit control function or may be made by the gateway based on local policy.
The gateway may be arranged so that in response to a cache for an identified service flow becoming exhausted, the gateway makes a decision either to request a further cache for the identified service flow from the credit control function or to perform the cache sharing procedure for identified service flows. Thus, the gateway can be arranged to balance the processing overhead associated with the cache sharing procedure with the signalling overhead associated with the request for a further cache in order to facilitate efficient running of the charging of end users by the network. The request for a further cache may include a request for further units for a cache.
According to a third aspect of the present invention there is provided a method of charging end users for the use of a communications network according to claim 19.
By using rate plans referenced to credit vouchers in this way different charging policies for different service flows can be implemented flexibly without significant network overhead. Where the same credit voucher is specified in at least two of the rate plans, different service flows are funded from the same credit vouchers which reduces the number of credit vouchers as compared to the number of prior art charging vouchers (one per service flow).
According to a fourth aspect of the present invention there is provided a method of charging end users for the use of a communications network according to claim 22.
The credit control function maintains control over the issuing and/or reserving of credit to service flows and over the allocation of charging rates to service flows. However, the additional instructions in the charging voucher give the gateway flexibility to commence a cache sharing procedure, if required. The trigger may occur for example when a request from the gateway to the credit control function for a cache is denied for a service flow having a charging voucher referencing that charging pool so that units from a cache associated with other service flows funded by the same end user can be used by the gateway to fund the service flow for which the request is denied.
According to a fifth aspect of the present invention there is provided a method of charging end users for the use of a communications network according to claim 26.
According to a sixth aspect of the present invention there is provided a method of charging end users for the use of a communications network according to claim 30.
According to a seventh aspect of the present invention there is provided a gateway for transporting service flows between an end user and a communications network according to claim 43.
According to an eighth aspect of the present invention there is provided a credit control function for a communications network according to claim 49.
According to further aspects of the present invention there is provided a communications network according to claims 53, 55, 56 and 57.
According to another aspect of the present invention there is provided a credit control function for a communications network according to claim 60. The instructions may take the form of a charging voucher or a rate plan, as described above. The measure of network resource to which the limit is to be applied may be the same as or different to the measure of network resource to which the operator is to be applied. The instructions relating to the operator to be applied and the limit to be applied may be applied simultaneously. A plurality of network resources and associated operators or limits may be included in a set of instructions. By issuing the instructions in this format flexible charging policies may be implemented.
According to a further aspect of the present invention there is provided a method of charging end users for the use of a communications network according to claim 62.
According to another aspect of the present invention there is provided a credit control function for a communications network according to claim 63.
The end user may use an end user equipment connected to an access network to communicate over the communications network via the service flows with the gateway interfacing the access network and the main network. For example, the communications network may be an Internet Protocol (IP) network, the access network may be a General Packet Radio Service (GPRS) network and the gateway may be a Gateway GPRS Support Node (GGSN).
Other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying Figures.
In order that the present invention is more fully understood and to show how the same may be carried into effect, reference shall now be made, by way of example only, to the Figures as shown in the accompanying drawing sheets, wherein:
a shows schematically a first approach to the sharing of credit from a credit pool between two charging vouchers of the embodiment of
a shows schematically a first approach to the sharing of credit from a credit pool between three charging vouchers of the embodiment of
a to 12c show three steps that can be carried out by the gateway of the network of
a to 16g show further examples of vouchers or tokens issued by the OCS of the network of
There will now be described by way of example the best mode contemplated by the inventor for carrying out the invention. In the following description, numerous specific details are set out in order to provide a complete understanding of the present invention. It will be apparent, however, to those skilled in the art that the present invention may be put into practice with variations of the specific.
With reference to
The access network (4) may be a packet switched network, such as a General Packet Radio Service (GPRS) network, which is interfaced with the IP network (6) via a gateway node or Gateway GPRS Support Node (GGSN) (8) of the GPRS Network. The IP network (6) may be a public or private intranet or internet, which may be made up of several interfaced networks.
The GGSN (8) transports data packets between the access network (4) and the IP network (6) and so is a traffic plane function network element. The GGSN (8) or an entity associated with the GGSN, for example the unit (10) shown in dotted lines in
The network includes an Online Charging System (OCS) (12) for controlling online charging to end users. The end user of the equipment (2) establishes a GPRS session by requesting a Primary Packet Data Protocol (PDP) context. The end user may then access services available on the IP network (6) via the GPRS network (4). The GGSN (8) accesses the charging policies and/or rules for the end user of the equipment (2) and identifies any service flows that are initiated by the end user of the equipment (2) (box a in
Each credit voucher contains a cache which contains a number of abstract units which represent an amount of an end user's credit issued from or reserved in an end user's account by the OCS (12). The cache may be decremented unit by unit by the gateway (8) as service flows are transported over the gateway. For example, a unit of a cache may be decremented for a predetermined amount of network resource being consumed by a service flow. In this sense the cache also represents an amount of network resource.
The rate plan (14) carries a multiplier by which a measure of network resource over the service flow 1 counted by the GGSN (8) is multiplied in order to obtain an amount of units to be deducted from the cache of the credit voucher (20) referenced by that rate plan. As data is sent and/or received over the service flow 1, the GGSN (8) counts the amount of the network resource measure used and applies the relevant multiplier to the counted amount in order to obtain an amount of units (box g in
A credit voucher (20, 22) is granted by the OCS (12) if the end user of the equipment (2) has sufficient credit in their account. The OCS (12) deducts the relevant amount of credit from or reserves the relevant amount of credit in the end user's account when the credit voucher (20, 22) is granted. The end user can increase the amount of credit held in their account, for example by making a payment of money into that account.
When the end user of the equipment (2) initiates a service flow 2 (shown in dotted lines in
When the end user of the equipment (2) initiates a service flow 3 (shown in dot-dashed lines in
By issuing one credit voucher (20) for a plurality of service flows (flows 1 and 2) the number of credit vouchers for a given number of service flows is reduced as compared with the prior art system when one charging voucher is issued for each service flow. Therefore, the problems caused by an end user's credit becoming used up due to the allocation or reservation of that credit to a large number different vouchers are reduced.
A rate plan may expire at a predetermined time, as shown in
Alternatively, the OCS (12) may supply a rate plan indicating new multipliers that are to take effect at some specified future time or after a specified volume of data has been used. Such a rate plan is shown in
In the examples shown in
Credit vouchers may also expire at a pre-determined time, for example where a charging policy is applied which allocates the end user a free allowance of credit per day, with no carrying over of credit. Then the credit vouchers for that end user would all be set to expire at 00.00 hours each day. The OCS (12) would then grant replacement credit vouchers using the next day's credit allocation.
According to the present invention the right is granted to an end user to receive network resource (eg. data) at a particular charging rate by the OCS (12) issuing a rate plan (14-18) separately from the grant of credit, which is granted by the OCS issuing a credit voucher (20-22). Each rate plan (14-18) references a single credit voucher (20-22) and a plurality of rate plans (14, 16) can reference the same credit voucher (20). As in the prior art systems, the OCS (12) decides which charging rate to allocate to which service flow. A difference from the prior art systems, is that the GGSN (8) undertakes the charging rate calculation, based on information received from the OCS (12) in the rate plans (14-18), by applying the multiplier to the amount of resource counted by the GGSN (8) to determine the number of units to deduct from the cache of the credit voucher (20-22).
The rate plans (14-16) may share a credit voucher (20) if the rate plans are compatible, i.e. if the credit held on the credit voucher (20) is transferable between the rate plans and their associated service flows. In the example of
The GGSN (8) may be set up in accordance with a first approach, illustrated in
When the OCS (12) grants a voucher (20) or a rate plan (14, 16), the message passed from the OCS (12) to the GGSN (8) granting the voucher or the rate plan can also provide the GGSN (8) with rules as to how the cache in the credit voucher (20) should be split between the rate plans (14, 16) and rules as to when and how to re-share the units of the cache in the voucher between the rate plans.
As the cache in the a credit voucher (20) becomes diminished, this re-sharing procedure will become more frequent, because the number of units allocated to each pot (30, 32) will reduce at each re-sharing of the remaining units of the cache of the credit voucher (20). In accordance with the present invention, the GGSN (8) can be set up to balance the processing resource associated with the re-division of the remaining units of the cache with the signalling resource required to request more units for the cache of a credit voucher. Thus, the GGSN (8) can avoid repeated re-sharing operations on a smaller and smaller pool of units provided there is still credit available for that end user at the OCS. For example, the GGSN (8) may request a further cache from the OCS when one of the pots (30, 32) becomes exhausted and allocate this cache directly to the exhausted pot. If there is no remaining credit in the end user's account, the re-sharing is carried out by the OCS which continues until the remaining units of the cache in the credit voucher fall below a predetermined threshold and then the GGSN (8) will block the service flows 1 and 2 funded by the credit voucher (20), or may carry out a cache sharing procedure with the caches of other credit vouchers granted for the same end user.
Alternatively, the GGSN (8) can be set up in accordance with a second approach, as illustrated in
A rate plan (14-18) can be composed in a generic format. In an example of this generic format a rate plan consists of at least one element, with each element having the same structure. The structure of a single element consists of the following two pieces of information:
The unit type (i) indicates the measure of network resource which the GGSN (8) counts, examples of which are time, data volume and active time (time which is only counted while data is transported over the service flow). For a unit type of time or active time, the amount of the unit type could typically be a number of minutes and/or hours. For a unit type of data volume, the amount of the unit type could typically be a number of bytes. Alternatively, the amount of unit type could be a multiplier plus a reference to a credit voucher (20, 22).
In the examples shown in
Rate plan (14);
The resources identified by all the elements in the rate plan are applied simultaneously. Thus, for rate plan (14) the charging rate of 1 unit of the credit voucher (20) per byte in service flow 1 is available to the end user until 1800 hours on Feb. 12, 2003. For rate plan (16) the charging rate of 0.75 units of credit voucher (20) per byte of service flow 2 is available to the end user until 0000 hours on Feb. 13, 2003. For rate plan (18) the charging rate of 0.5 units of the credit voucher (22) per byte in service flow 3 is available until 10 Mb of data has been transported over service flow 3. The multiplier used in the rate plans (14-18) is a number which converts between the measure of network resource identified in the rate plan by the unit type and the abstract units of the cache of the credit voucher (20, 22) referenced by that rate plan.
The credit vouchers (20, 22) need only to contain a number of units in a cache, the units of this cache need not be specified in the credit voucher. The units contained in a cache of a credit voucher only become meaningful when combined with a rate plan. The rate plan provides the means to convert from the abstract units in the cache to a measure of network resource which is counted by the GGSN (8), such as time or data volume.
There is advantage associated with the prior art system in which a charging voucher is granted for each service flow and an amount of credit is deducted from the end users account or reserved in the end users account for each charging voucher the OCS (12) grants. However, the problem still exists that when the end user's account becomes empty the next voucher requested by the GGSN (8) for a service flow will not be granted and that service flow will be blocked, even if the end user still has credit allocated or reserved for other vouchers granted by the OCS which vouchers ensure the ongoing operation of their associated service flows.
According to a further embodiment of the present invention, when an end users account becomes empty, and the OCS (12) has to deny a request from the GGSN (8) for a charging voucher, the GGSN (8) then combines caches from charging vouchers associated with different service flows of that end user into a charging pool for that end user. The GGSN then uses the charging pool to fund each of the end users service flows, including the one for which the OCS (12) denied the request for a charging voucher. In this way the service flows requested by the end user will continue to operate until the end users credit is used up.
Considering now
However, the charging vouchers shown in
Consider the situation for
When sharing the charging pool 001 between the service flows in accordance with the instructions in the rate vouchers (14′) and (16′), a first approach, as illustrated in
Accordingly, when the user's credit is exhausted the online charging system switches from a procedure, which is used in the prior art, in which:
In the
When sharing the charging pool between the service flows in accordance with the instructions in the charging vouchers (14′) to (18′) of
The embodiments of
Referring now to
In the example in
In one embodiment, the GGSN (8) identifies charging vouchers (14″) and (16″) as referencing the same charging pool as charging voucher (18″) and returns all of these vouchers to the OCS (12) requesting replacement vouchers (box a in
In an alternative embodiment, after the GGSN (8) identifies the charging vouchers (14″) and (16″ as referencing the same charging pool as charging voucher (18″) it could itself carry out a redistribution of units between the caches of the charging vouchers (box z in
If the units of the caches in the charging vouchers are different then for the GGSN (8) to share or transfer units between the caches the GGSN (8) needs instructions about how to convert between the different units from the OCS (12). Where the units in the caches to be shared are different, the gateway requires instructions, for example in the form of a conversion factor, in order to convert between the different units. For example, associated conversion factors may be applied to each different units to convert into generic units which can then be shared between caches and reconverted back into the different units. For example, this can be done as described below in relation to
The processes described above in relation to
The charging vouchers (14′, 14″ to 18′, 18″) may use the same generic structure including elements as described above in relation to the rate plans (14-18). The charging vouchers (14′, 14″ to 18′, 18″) can also take the form of the rate voucher of
According to a further embodiment of the present invention a decision of whether to request an additional cache from the OCS (12) or to carry out a cache sharing procedure is delegated to the gateway (8). Referring now to
Certain aspects of the charging processes described above and identified as being carried out by the gateway (8), may equally be carried out by a network entity, such as the unit (10), associated with the gateway (10). The term gateway is used generally herein to include any such associated network entities.
In an alternative embodiment of the present invention, shown in
The vouchers shown in
The voucher has a conversion factor of 123 per A event, 1350 for B events and 444 per C event and references a credit pool (equivalent to a charging pool) no. 5.
Now consider that the vouchers of
Consider now the situation when the voucher of
Thus, the conversion factors provided in the vouchers of
| Number | Date | Country | Kind |
|---|---|---|---|
| 03076426.0 | May 2003 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/GB04/01815 | 4/28/2004 | WO | 10/23/2006 |
