BRIEF DESCRIPTION OF THE DRAWINGS
The invention will in the following be further described in a non-limiting manner, and with reference to the accompanying drawings, in which:
FIG. 1 is a very schematically block diagram illustrating an arrangement in an implementation to a GSM/GPRS system wherein flexible charging is implemented in GGSN,
FIG. 2 is a very schematical block diagram similar to FIG. 1 illustrating an implementation to a UMTS/GPRS system wherein flexible charging is implemented in GGSN,
FIG. 3 is a very schematical block diagram similar to FIG. 1 and FIG. 2 for a dual access node (SGSN) and wherein flexible charging is implemented,
FIG. 4 is a block diagram illustrating an implementation in which flexible charging is implemented in SGSN,
FIG. 5 is a block diagram illustrating a combined gateway and serving packet data node (CGSN) supporting flexible charging,
FIG. 6 is a signalling diagram for an arrangement as in FIG. 1, for one particular implementation,
FIG. 7 is a signalling diagram for an arrangement as in FIG. 2 for one specific implementation,
FIG. 8 is a signalling diagram for a dual access SGSN node according to another implementation,
FIG. 9 is a flow diagram describing the procedure according to an implementation in which GGSN supports flexible/content based charging,
FIG. 10 is a flow diagram describing the procedure where SGSN supports a flexible, content based charging functionality,
FIG. 11 is a flow diagram illustrating an embodiment wherein reports are included in Charging Data records,
FIG. 12 is a flow diagram illustrating an embodiment in which real time correction/compensation is allowed,
FIG. 13 shows the signal format and introduction of info between an access node and an RNC, and
FIG. 14 shows the signal format and introduction of information between an access node and BSC.
DETAILED DESCRIPTION OF THE INVENTION
In the embodiment illustrated in FIG. 1 it is supposed that, in a GSM/GPRS system, GGSN 1A supports a type dependent charging functionality, i.e. charging depends on type of traffic, or service class belonging of the traffic (e.g. IP flow based bearer level charging). GGSN 1A communicates with SGSN 2A over the Gn-interface using the GTP (GPRS Tunneling Protocol) as is known per se, cf. 3GPP TS 29.060, which herewith is incorporated herein by reference. GGSN 1A here adds traffic type information (identified as a part of a type dependent charging functionality including classification of traffic, or separately obtaining type/classification information) to the GTP header of the downlink (DL) payload. The type information may be of different kinds, it may e.g. contain service class information, e.g. a service class tag. In addition thereto it may contain cost or rating information. It may also, in an advantageous implementation, contain chain id, which is used to identify the chain an IP packet belongs to when IP packets sharing the same service class cannot be identified until the key-IP packet for the particular chain has arrived at GGSN, or until a required number of packets have arrived. If this information is not included, it should be noted that loss of such a packet cannot be compensated for, but in some cases this might be acceptable.
SGSN 2A provides for the type information (at least) being sent also to BSC 3A (in this case). Only one BSC is shown in the figure for reasons of clarity. As is known the Gb interface is used between BSC and SGSN and BSSGP is used as communication protocol. BSSGP, Base Station System GPRS Protocol is described in 3GPP TS 48.018, which herewith is incorporated herein by reference. Since different protocols are used between GGSN and SGSN and SGSN and BSC respectively, the type info cannot simply be forwarded by SGSN to BSC, but instead a new information element with at least the type information may be added to the BSSGP DL-UNITDATA PDU (Packet Data Unit). MS 4A is shown merely for illustrative purposes in the figure.
Traffic can be discarded either by SGSN 2A or by BSC 3A. In case SGSN 2A discards traffic, the type information (at least) of the the discarded payload is added to the CDR (in a new field thereof). A loss report is sent to GGSN 1A if real-time compensation is implemented. In this embodiment it is not limited to sending of loss reports in any specific manner. It can be done based on time, volume, CDR:s may be used in a conventional manner by the operator to provide for compensation on a more or less regular basis, e.g. at night, when CDR:s are checked in any case. This will be further discussed below.
If instead it is BSC 3A that discards traffic this is reported in a loss report to SGSN 2A. This is illustrated in the figure but it may just as well be SGSN that discards traffic; SGSN has to report it to GGSN irrespectively if it being SGSN itself or BSC that has discarded traffic if real-time compensation is supported. In this embodiment BSC 3A notes the type information (e.g. at least service class tag) in the BSSGP header and includes it as a new information element in the BSSGP header, as a new information element in BSSGP LLC (Logical Link Control) Discarded message towards SGSN 2A. (Real time compensation may be supported or not as discussed above).
When a loss report from BSC 3A, i.e. a report of discarded traffic, is received in SGSN 2A, this information is included in the appropriate CDR in a new field by SGSN 2A. The CDR can then be post-processed together with the data of the type dependent charging functionality provided by the GGSN 1A to allow for a charging in which compensation is provided for lost traffic.
If real time compensation should be supported, a new GTP message, e.g. GTP Discarded traffic report has to be sent to the GGSN 1A (both if SGSN or BSC discarded the traffic) containing the information of the loss report together with IMSI and NSAPI (Network layer Service Access Point Identifier). If real time compensation is implemented, it is not, for the functioning of the inventive concept, necessary to include the loss report information in a CDR, but it may be advantageous to do so in order to keep the information that might be useful.
FIG. 2 is a Fig similar to FIG. 1 but with the difference that SGSN 2B supports communication with RNC 3B (UMTS). Also here it is supposed that GGSN 1B supports a type dependent charging functionality. MS 4B is merely shown for reasons of completeness. The interface used between SGSN 2B and RNC 3B is Iu as is known per se. However, in this case the GTP protocol is used also between SGSN 2B and RNC 3B, which makes it easier. The type information may then simply be forwarded from SGSN 2B as e.g. the same service tag to the RNC 3B. If RNC 3B discards traffic, it notes the type info, e.g. at least service tag as discussed with reference to FIG. 1, and sends this information as a new information element in RANAP Data Volume Report to SGSN 2B. (For non-real time compensation the message may be sent either when a RAB (Radio Access Bearer) is lost, or when PDP context is deactivated, whereas for real-time implementations the report should be sent immediately when traffic is discarded.)
RANAP, Radio Access Network Application Part, is discussed in 3GPP TS 25.413, which herewith is incorporated herein by reference.
When a loss report (Data Volume Report) is received in SGSN, this info may be included in the correct CDR in a new field as discussed with reference to FIG. 1.
It should be noted that for non-real time embodiments, the loss report does not have to be sent to GGSN, whereas for real time compensation embodiments the report has to be provided to GGSN (with IMSI and NSAPI (or correspondingly) as discussed above).
Generally the invention suggests a mechanism that makes it possible for an SGSN to identify which traffic class and cost/rating information discarded traffic had been allocated by a GGSN.
FIG. 3 is an embodiment in which the SGSN 2C (in communication with GGSN 1C) comprises a Dual Access Node supporting communication with BSC 3C as well as with RNC 3C′. MS 4C, 4C′ are illustrated for reasons of completeness.
The functioning is the same as that described above with reference to FIGS. 1 and 2, real time handling being supported or not, loss reports to GGSN 1C only being relevant for real time charging cases, whereas if CDR based charging is implemented, this is not necessary.
FIG. 4 shows an alternative implementation in which the type dependent, or flexible, charging functionality is provided in SGSN 2D instead of in GGSN 1D. It is here supposed that SGSN 2D is a dual access node supporting communication with BSC 3D as well as RNC 3D′. However, the inventive concept of course also covers the case when SGSN 2D only supports BSC 3D or RNC 3D′. The functioning is the same as that described with reference to FIGS. 1-3 with the difference that sending of type info (e.g. service class tag and possibly cost/rating info and/or chain id) between GGSN 1D and SGSN 2D is not necessary, neither to send any loss reports to GGSN.
FIG. 5 shows still another implementation wherein a CGSN 1E is implemented which comprises the functionality of both a GGSN and a SGSN. CGSN 1E may support a dual access functionality or not i.e. support both or either of BSC 3E, RNC 3E′. The functioning is the same as that described in the foregoing, with the difference that no communication with a separate GGSN is needed, which thus makes the procedure even more straightforward.
FIG. 6 is a signalling diagram illustrating the inventive procedure for an embodiment in which flexible/content based charging is supported in GGSN, in which SGSN supports communication with BSC:s and in which it is allowed for real time compensation of lost traffic.
It is here supposed that GGSN adds service class tag and a time stamp to the GTP header of the DL payload, 1. A time stamp is here used as an alternative to sending cost/rating info, which instead is identified in GGSN when a discarded traffic report with time stamp is received in GGSN. Chain id may be included or not. SGSN adds a new information element to BSSGP DL-UNITDATA, 2, and sends the service class tag info and time stamp on to BSC.
If SGSN discards traffic, a GTP Discarded traffic report with IMSI, NSAPI, service class tag, volume and time stamp is sent to GGSN in a new GTP message, 3, substantially immediately at occurrence of the loss.
If on the other hand BSC discards traffic, BSC includes the relevant info, here service class tag, volume, time stamp in a BSSGP LLC Discarded message towards SGSN, 3′.
To enable real-time compensation in the GGSN, a new GTP message, e.g. GTP discarded traffic report with IMSI, NSAPl, service class tag, volume and time stamp (here) is sent to GGSN, 4′, substantially as soon as SGSN detects or is informed of the loss.
In the signalling diagram of FIG. 7 it is supposed that the SGSN access node only supports RNC communication. In the other aspects the same principles as in the embodiment of FIG. 6 apply. Thus, here the service class tag and the time stamp is simply forwarded, 2, by SGSN to RNC since also between SGSN and RNC the GTP protocol is used (GTP-U, userplane). If RNC discards traffic, RNC sends a volume report with service class tag, volume and time stamp to SGSN, 3′. The signalling denoted 1, 3, 4′ in FIG. 7 corresponds to the signalling with the corresponding references in FIG. 6.
FIG. 8 is a signalling diagram relevant for another implementation supporting real-time compensation for lost packets. It is here supposed that SGSN is a dual access node, but an implementation as in FIG. 8 of course also is possible if SGSN only supports BSC or RNC, in which cases the corresponding signalling to/from the node not supported should be deleted from FIG. 8. Like in FIGS. 6, 7 it is supposed that a flexible charging functionality is supported by GGSN. The difference from FIGS. 6, 7 is that the information provided to SGSN, BSC and/or RNC contains service class tag, rating info and chain id and that the loss reports contain IMSI, NSAPI, service class tag, volume, rating info and chain id.
If flexible charging is supported by SGSN or if SGSN and GGSN are combined into a CGSN, the messageing between SGSN-GGSN is of course superfluous.
FIG. 9 illustrates, in the form of a flow diagram, the procedure when GGSN supports flexible/content based charging. GGSN here adds service class info (and preferably rating info and chain id) to the GTP header of the downlink (DL) payload, and sends to SGSN, 100. SGSN sends service class info (rating info, chain id) to BSC and/or RNC, 101. If/when traffic is discarded by SGSN, 102 yes, service class info (rating info, chain id) of the discarded payload is provided to GGSN and registered by SGSN, 103 (for a real time implementation). If (when) traffic is discarded by BSC/RNC, 104 yes, service class info (rating info, chain id) of the discarded payload is provided to SGSN and registered by BSC/RNC/SGSN, 105. Subsequently, for real time compensation, service class info (rating info, chain id) of discarded payload is provided from SGSN to GGSN, 106.
For real time implementations loss reports to SGSN/GGSN are provided substantially immediately upon occurrence to GGSN, including e.g. IMSI, NSAPI as discussed above.
FIG. 10 is a flow diagram describing a procedure as in FIG. 9, but wherein the flexible/content based charging functionality is supported by SGSN. As can be seen only steps 101, 104 and 105 remain, here denoted 200, 201, 202. As can be seen, the procedure is considerably facilitated.
The functioning will be substantially the same if a CGSN node is used.
FIG. 11 is a flow diagram describing an implementation of the inventive concept when CDR based charging (not in real time) is implemented. As discussed above, GGSN adds a service class tag to the downlink payload sent to SGSN, 301. SGSN sends/forwards the service class tag to RNC/BSC, 302. If traffic is discarded by SGSN, the service class tag is added to the appropriate Call Data Record (CDR) in a new field, 303, and compensation for lost traffic is performed e.g. by the operator using information as to type etc provided by GGSN when the CDR is handled, e.g. at night.
If traffic is discarded by RNC, RNC notes the service tag of the discarded traffic and sends this info as a new information element in a RANAP Data Volume Report. If traffic is discarded by BSC, BSC notes the service tag in the BSSGP header, includes it in a BSSGP LLC Discarded message towards SGSN, 304.
When such a discarded traffic report is received in SGSN, the report info is included in the appropriate CDR in a new field, cf. step 303 above. After step 303 and/or 305, the CDR is post-processed together with the flexible charging data info provided to SGSN by GGSN to provide for accurate charging with lost traffic compensation, 306.
FIG. 12 illustrates a procedure allowing for charging compensation for lost packets in real time. In the shown embodiment GGSN adds service class tag, rating info, chain id to the DL payload GTP header sent to SGSN, 401. SGSN in turn sends/forwards service class tag rating info, chain id to RNC and/or BSC, 402.
If traffic is discarded by SGSN, service class tag, rating info, chain id of the discarded payload may be added to the appropriate CDR in a new field, and a new GTP message is sent to GGSN with this information together with IMSI, NSAPI substantially instantaneously, 403. If RNC and/or BSC discards traffic, service class tag, rating info, chain id are provided to SGSN immediately upon traffic discarding, 404. Report information about the discarded traffic may then be included in the correct CDR in a new field in SGSN. A new GTP message with such info and IMSI, NSAPI is then sent to GGSN, 405. (cf. step 403). Charging is then corrected/compensated for lost traffic in real time in GGSN, 406.
FIG. 13 shows the signalling format used between GGSN-SGSN and SGSN-RNC which use the GTP protocol. The information (e.g. service tag, rating info and chain id), is introduced in the GTP header.
FIG. 14 shows the format used between SGSN and BSC. The relevant information is here introduced into BSSGP. The format is known as such, NS, Network service, LLC, SNDCP Sub Network Dependent Convergence Protocol.
According to the invention it gets possible to compensate flexible charging for downlink payload discarded by e.g. BSC, RNC, SGSN or a node with a similar functionality.
It should be clear that the invention is not limited to the specifically illustrated embodiments, but that it can be varied in a number of ways within the scope of the appended claims.
It should also be clear that other nodes in other communication systems having similar functionalities as e.g. GGSN, SGSN, CGSN, BSC also are covered by the inventive concept.
Patent Application
20080096523
