Sei sulla pagina 1di 22
Guide

Guide

GPRS Charging Guide R8

Contents

1 Introduction

3

2 Charging Support in GPRS

4

2.1

Charging Parameters

4

2.2

Invoicing

8

3 Charging in the GPRS Network

10

3.1

Generation of Call Detail Record

10

3.2

Keeping track of CDRs

10

3.3

Countable charging information

11

3.4

Roaming

11

3.5

The CDRs and ETSI standard

11

3.6

Handling of CDRs in GSN

14

3.7

Connection to external system

15

4 The Ericsson Billing Gateway

16

5 Charging Record Contents

16

5.1

GPRS charging data in SGSN (S-CDR)

17

5.2

GPRS charging data in GGSN (G-CDR)

18

5.3

GPRS mobile station mobility management data in SGSN (M-CDR)

18

5.4

GPRS MO SMS data in SGSN (S-SMO-CDR)

19

5.5

GPRS MT SMS data in SGSN (S-SMT-CDR)

20

6 Abbreviations

21

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 2 (22)

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 3 (22)

1

Introduction

With the introduction of General Packet Radio Service (GPRS) a whole new array of charging and billing is possible. This guide is intended to give an understanding of the charging capabilities of Ericsson’s initial GPRS system in GSM system R8.

Operators are given a wide range of charging possibilities. Some examples of these are:

Flexible charging, new parameters that allow for charging based on data volume,

Quality of Service (QoS), duration, location, etc. Possibility to offer both post- and pre-paid charging

Efficient use of capacity gives the operator the possibility to lower the price for

mobile data communication Enhanced charging features with the Ericsson Billing Gateway (BGw). The Ericsson BGw allows for a fast introduction and gives the operator the possibility to customise the handling of charging information.

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 4 (22)

2 Charging Support in GPRS

The charging criteria used in GPRS are fundamentally different from the circuit- switched services. Using circuit-switched data as a bearer service implies that a connection will be in place for the total duration of a session, even when no data is sent. This is a waste both for the operator, who will use up scarce radio resources, and for the user who has to pay for the duration of the call even if little or no data is transmitted. Datacommunication is typically bursty with no traffic when a user is replying to an e- mail or reading a web page. This is the reason volume-based charging is of interest to both end-users and operators. The charging feature in GPRS R8 provides the operator with sufficient information about subscriber activity to produce bills based on a number of parameters like data volume, duration, charging a flat rate. These parameters can be used individually or in different combinations.

In a GPRS network, the charging information is generated from the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). Collection and output of charging is done for each packet data transfer session. A packet data transfer session, is also known as a Packet data protocol (PDP) context, and starts at successful packet communication attach and ends at packet communication detach or at a certain timeout. In principal, charging information in the first GPRS release R8 can be sent to the billing system directly or via a mediation device such as the Ericsson Billing Gateway (BGw). See figure 1 below.

BillingBilling SystemSystem Ericsson CDR’ file BGw CDR’ BTS file CDR’ file BSC SGSN GGSN
BillingBilling
SystemSystem
Ericsson
CDR’
file
BGw
CDR’
BTS
file
CDR’
file
BSC
SGSN
GGSN

Figure 1. Call Detail Records (CDR) are files sent directly to the Billing System or via the Ericsson BGw.

2.1 Charging Parameters

In Ericsson’s first GPRS release, new billing criteria are supported. In the rest of this section, the charging parameters are described. The parameters are data volume, duration, final destination, location, Short Message Service (SMS), free-numbers/800 numbers (reverse charging), flat rate and bearer services. All of these charging parameters except flat rate can be combined with time (day of the week and time of day) and Quality of Service (QoS). Operators can do the billing based on one parameter or based on a combination of different parameters.

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 5 (22)

Data Volume

Volume-based charging is expected to be one of the preferred charging methods. The call detail records (CDRs) from the GSN nodes contain information about the data volume, in the ‘list of traffic data volumes’ field. This enables the operator to charge the end-user based on the amount of transferred bytes.

The operator could combine this parameter with QoS, time of day and mobile class mark to create a more differentiated tariff plan.

To enable a fast introduction of GPRS charging, taking into consideration that existing billing system may not be prepared for volume based charging, Ericsson’s solution with the Ericsson BGw will transform the volume-based information in the CDRs to time based charging information. The CDRs could also be formated in the Ericsson BGw into the same format, as “standard” circuit-switched CDRs meaning the adaptation in the existing billing centre would be kept to a minimum.

Duration

Another alternative is to charge based on duration of a data transfer session i.e. PDP context. The duration of a data transfer session will start when an attached subscriber does a PDP context activation that is starts sending/receiving data and end when the subscriber does a PDP context deactivation i.e. stops sending/receiving data. The CDRs from the GSN nodes will contain information on the duration of the data transfer session in the ‘Duration’ field. It is possible to specify in seconds how long time the subscriber has been active.

Duration-based charging enables a fast introduction of GPRS in networks where the billing system is already prepared for time-based charging. The Ericsson BGw can also transform CDRs into ‘standard-CDRs’ used for circuit-switched traffic. This helps keep changes to the existing billing centre to a minimum.

The duration parameter can be combined with other parameters such as time of day and day of the week.

Charging based on only duration, is nothing that Ericsson recommends. Ericsson rather sees that subscribers should be able to be “logged-on” and always be connected and thus have the possibility to send and receive data. Charging based on duration would most likely discourage the usage of GPRS as the end-users only would “logg-on” when using the terminal for sending/receiving data.

Time

This parameter enables operators to charge end-users based on time of day and day of the week. The CDRs include information on the time when the data transfer session was started (‘Record opening time’ field). The time is specified by date, hour, minute, and second. Operators can offer lower tariffs at off-peak hours. Lower tariffs attract users when traffic is normally low (in the evening, weekends and holidays).

Several switching times can be defined for tariff changes. For example, when a data transfer session goes into a time when the tariff has changed, it will be visible in the CDRs as a new container (a list of data) for volume counters. The new container is visible in the ‘List of traffic data volumes’ field.

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 6 (22)

The ‘List of traffic data volumes’ field lists one or several containers. Each container includes the following fields: data volume uplink, data volume downlink, change condition and change time. The ‘change condition’ field defines why a container has been closed, e.g. tariff change, QoS change, or closing the CDR. Refer to section 5, “Charging Record Content”.

Destination Point

A subscriber can be charged for accessing a specific network e.g. via proxy server, i.e.

charging based on the destination address/point. The CDR then specifies the final destination in the ‘Access Point Name’ (APN) field. If several service providers are connected it is possible to distinguish between them providing that a dedicated APN and

PDP context is defined for them. Note the APN is constant during a data transfer session.

A service provider (SP) can provide either access services (e.g. traditional ISPs) and/or

content services (value added SP).

This type of charging will require that agreements be made between the operator and SPs. The amount of traffic that has been sent to/from an SP will also be information included in the CDRs. This means operators could use traffic volume for charging SPs. To illustrate this, a certain tariff could be applied for traffic volumes > X and another tariff for traffic volumes < X. Information accessed from one service provider could be more expensive than information from another service provider.

Destination charging can be linked to service charging. The standardisation group SMG6 GPRS is already addressing this issue under the topic ‘Itemised Billing’, which means capability to differentiate traffic volume per connected remote server address. This approach has several drawbacks and a better solution is still being worked on. For example, it is not possible to predict how much charging information there will be which could result in decreased capacity for the end-users (web browsing, control messages, illicit attacks from external networks etc.). Further there is no correlation between volume and service content. It is believed that these issues, which one access network can not solve on its own, are better handled on application layer rather than on access layer.

Location

The operator can charge based on the location of the subscriber. The CDR gives information about the cell, the routing area and the location area of the subscriber when the data transfer session was set up. This information is stored in the ‘Cell Identity’ (CI), ‘Routing Area’ (RA), and ‘Location area’ (LA) fields.

Operators could apply different rates to different areas/zones. Perhaps ‘hot-spots’ with different tariffs could be a way to charge the end-user. In other words, the operator could offer lower costs in home areas compared to office areas enabling ‘home-zone’ and ‘office-zone’ concepts. The CDRs include updated location information. If a data transfer session lasts very long, it is possible to notice at precision of partial record interval, the changes in location. This means the operator can monitor or charge differently when the subscriber moves from one zone to the next.

In addition to the GPRS unique charging capabilities it would be possible to base

location charging on Mobile Positioning System (MPS) or on the Global Positioning System (GPS). This is likely to imply that the operator has an own ISP with an application that can utilise the MPS/GPS.

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 7 (22)

Quality of Service (QoS)

GPRS networks provide QoS, giving operators one more parameter for charging. QoS enables end-users the option of paying more for higher priority/higher QoS. The CDRs from the GSN nodes give QoS information in the ‘list of traffic data volumes’ field. Operators can set different rates according to the different levels of service. If the QoS that the subscriber requested could not be achieved for some reason, the lower fee could apply. The QoS is recorded per PDP context and therefore the QoS will not apply for SMS. The CDR also indicates the ‘Requested QoS’ and the ‘Negotiated QoS’ meaning if the subscriber’s QoS level changes this will be visible.

If a session lasts over a time when the QoS requested can not be met and consequently the QoS is changed, then the change will appear on the CDRs, as a new container for volume counters in the CDR is generated. Refer to section 3.1, “Generation of Call Detail Record”.

SMS

SGSN will produce specific CDRs for SMS. Two separate CDRs are produced for Mobile Originated and Mobile Terminated SMSs and so charging can be done based the different SMS CDRs.

The charging can also be based on the location of the subscriber. The ‘Cell’, ‘Location area code’ and ‘Routing Area Code’ fields can be used for this. This way, a different tariff could apply for sending SMS in ‘hot-spot’ areas at exhibitions, sports events etc.

SMS charging can also be combined with the time parameter giving the possibility to have different tariffs depending on time of day etc. This information is included in the ‘Event time stamp’ field.

Due to SMS’ popularity in circuit-switched networks, it could be of interest for operators to lower prices to promote SMS over GPRS.

Served IMSI/Subscriber

The CDRs from the GSN nodes contain information about the end-user identity in the ‘Served IMSI’ field.

This could allow for different subscriber classes with different tariffs for e.g. frequent users. Other examples of classes could be business and private users.

The time parameter can be combined with an IMSI parameter (indicating subscriber identity) so a specific tariff will apply for a certain subscriber type depending on time of day.

Reverse Charging

Reverse charging means the sending party e.g. a Service Provider or third party is charged for the received/sent data instead of the receiving subscriber. This way, a company could for example be charged for the traffic sent from the employees. The ‘Access Point Name’ field enables this by making data from a specific ISP subject to reverse charging. Reverse charging can also either be combined with volume or flat rate.

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 8 (22)

Note that it is not possible to distinguish within a PDP context which data volume a subscriber should or should not be charged for. Only uplink/downlink traffic can be separated. Part of downlink traffic can be related to chargeable requested services and part to network (third party) initiated data. In other words, a subscriber is charged for all downlink data or none at all.

Free of Charge

Another possibility is to allow for certain data to be free of charge is. With the ‘Access Point Name’ field, the data from a specific ISP could be received free of charge for the end-user.

Flat Rate

For attracting the mass market, it is believed that the preferred way of charging will be flat rate in combination with volume. Flat rate could be based on a monthly fee so the end-user has a fixed amount (of bytes) to spend per month at a given tariff. If the user exceeds this amount, then perhaps a higher tariff could apply. Flat rate could also be combined with time so regardless of the amount of traffic there is a fixed rate at certain hours.

Bearer Service

Charging based on bearer service could be of interest if an operator has several networks e.g. GSM900 and GSM1800 and wants to promote the usage of one of the networks. Another example is ‘hot-spot’ areas where it could be less expensive for the operator to offer a particular service in a Wireless LAN rather than in the GSM network. The charging would vary depending on the bearer service. The tariff plan could be made to reflect the capacity of the network. For example, the operator could set a higher tariff in the network that offers greater capacity. Or, the operator could promote the network with higher capacity by lowering the tariffs.

2.2

Invoicing

End-users can be invoiced before or after they used a service, pre- and post-payment respectively.

Post-paid

Post- paid charging used to be the only way to invoice customers and it is still the primary way of invoicing subscribers in many markets. Corporate subscribers, for example, will probably prefer post-paid invoicing given the large invoices.

Post-paid charging in GPRS is based on a post-processing of the end-users CDRs in the external billing centre. The post-processing and the actual tariffs can be based on the charging parameters described in the previous chapter.

Pre-paid

Pre-paid service within circuit-switched networks has become popoular in many markets. It will probably be one of the preferred ways of invoicing GPRS subscribers, both on markets where pre-paid services are already used and on many new markets. The

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 9 (22)

standardisation of pre-paid service in GPRS is still going on in CAMEL phase 3, in other words there is no standardised Pre-paid solution as of yet.

The first release of the Ericsson GPRS solution supports a GPRS Pre-paid solution based on CDR output and the use of existing pre-paid systems such as ORGA’s Pre-paid system. The solution also uses the features of the Ericsson BGw. This solution is the first step for Pre-paid solution within the Ericsson GPRS solution. It requires very little or no changes to the existing billing system or to the existing pre-paid system. This enables rapid pre-paid service deployment throughout the GPRS network.

This initial solution requires support in the Ericsson BGw and the HLR. It is based on utilizing some of the functions in the Billing Gateway to process the CDRs. The Ericsson BGw will sort out the CDRs from the pre-paid subscribers and reformat the information in these CDRs from volume-based charging to time-based charging. The Ericsson BGw will transform these CDRs into the same format as ‘standard’ circuit-switched CDRs to allow for minimized adaptation in the existing pre-paid account system.

The Ericsson BGw will send the pre-paid related CDRs to the pre-paid system for account and rating handling. The pre-paid system will inform the HLR when the subscribers account is empty. The HLR will, upon receipt of this information, inform the SGSN to detach the PDP context and will not allow any set-up of PDP sessions for this subscriber.

Although the solution is not a real-time based solution, there will be relatively little risk of fraud due to the traffic model under a user period. A user is typically connected over a long period but only occasionally transfers data, e.g. during a session of 10-15 minutes the user is only active 5 minutes. This user behavour is repeated in cycles.

The pre-paid solution in GPRS will evolve into a solution following the standardisation of pre-paid for GPRS in ETSI (CAMEL phase 3) which is not yet terminated. As an intermediate step, Ericsson is studying how a GPRS pre-paid solution could interwork with existing circuit switching and IN-based pre-paid solutions.

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 10 (22)

3 Charging in the GPRS Network

Collection and output of charging data for packet-switched services in the Ericsson GSM System is carried out for each data transfer session set-up between a mobile terminal and an SGSN. Fields related to a session are collected in a CDR, for later output to a billing center.

3.1 Generation of Call Detail Record

In a GPRS network the SGSN and the GGSN contain the charging information for GPRS traffic i.e. collect information from the same chargeable data transfer session (PDP context). In principal, both the SGSN and the GGSN measure the same traffic. However, they differ since only the SGSN knows the location of the subscriber, and if the end-user is sending an SMS message.

This means that in principal either the SGSN or GGSN records are enough to charge the subscriber, however it is more complicated. Depending on the traffic scenarios, different information will be needed. Both SGSN and GGSN records are needed, for example, when the GGSN is in a different network than the SGSN or in SMS cases. CDRs from one data transfer session (PDP context) could also be sent from several SGSNs, e.g. if the GPRS subscriber has moved and changed SGSN routing areas.

If a session lasts longer than a specified time limit, or if any of the volume counters reach a maximum limit, the GPRS Support Nodes (GSN) will generate a partial output of charging information, called a partial CDR. Thus a partial CDR contains charging data for a time period shorter than a data transfer session. This means that there could be partial CDRs that need to be included in the consolidated charging of a data transfer session.

3.2 Keeping track of CDRs

As described above, CDRs are generated both by the SGSN and the GGSN and there could also be partial CDRs, that give charging information for a single data transfer session. CDRs need to be grouped according to data transfer sessions, as there could be up to three types of charging records for the same data transfer session. Each CDRs has charging ID information which makes it possible to group the different CDRs, giving consolidated charging information for one data transfer session.

There is another field containing a local record sequence number. This is a locally unique number that can be used e.g. to identify missing or duplicate records in the post processing system. The number is created by the GSN and is included in all CDRs.

Each partial record sequence (e.g. G-CDRs) has an internal incremental numbering (Record Sequence Number) system for sorting records.

If the SGSN has changed during the data transfer session, then the first CDR created by the new SGSN indicates that there is already an S-CDR created by another SGSN. Each SGSN numbers their records independently (partial record sequence number and local record sequence number).

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 11 (22)

3.3 Countable charging information

The data in a session used for charging is the amount of data counted in both the GGSN and SGSN. In the GGSN this is the data volume sent over the GTP layer. In the SGSN, this is the data volume above SNDCP layer. These volume counts include all overhead generated by subscribers, such as IP/TCP headers, TCP retransmissions, and CMIP messages.

Charging of data volume can either be based on SGSN or GGSN data volume counts. Even though they measure the same traffic, volume counts can differ in some special retransmission cases between GGSN and external PDN.

In the case of retransmission of data volumes, radio retransmissions are not counted but IP packet overhead and all retransmission above IP/TCP are counted.

Data volumes on uplink and downlink are counted separately.

3.4 Roaming

There are no mechanisms specified in GPRS for handling the transfer of charging information (CDRs), produced in a visiting network (while roaming), back to the home network. The GPRS standard specifies that all charging information will be produced in the network that is serving the subscriber.

Consequently, when roaming, the VPLMN will always collect charging data in the SGSN and optionally in the GGSN. The HPLMN will only collect charging data when the subscriber’s home GGSN is used.

Accounting procedures between networks is part of the TAP 3 MoU specification (Inter accounting protocol). TAP3 is a MoU proprietary protocol and is used between two operators or between Operator-Clearing house.

Note that transfer of charging information across network boarder is a part of the UMTS scope.

3.5 The CDRs and ETSI standard

There are two main types of charging records in GPRS, one for the SGSN and one for the GGSN related to the PDP context in the ETSI TS GSM 12.15. A third record is provided for mobility management in the SGSN. The SGSN can also provide two SMS- related records.

The new types of CDRs introduced in the first release of the Ericsson GPRS solution are:

S-CDR, related to the radio network usage, sent from the SGSN

G-CDR, related to the external data network usage, sent from the GGSN

S-SMO-CDR related to mobile-originated short message service with GPRS

S-SMT-CDR related to mobile-terminated short message service with GPRS

The features available in the Ericsson BGw are compliant with ETSI TS GSM12.15 for the S-CDR (SGSN), G-CDR (GGSN), S-SMO-CDR (mobile-originated SMS) and the S-

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 12 (22)

SMT-CDR (mobile-terminated SMS). The M-CDR (mobility) is not supported in the first release, but is planned for in the next release. In Ericsson’s implementation the CDRs include all mandatory fields plus several conditional and optional fields. Refer to section 5, “Record Content”.

The M-CDR is currently defined to record the attachment duration and Location Area updates. It allows the operator to charge for mobility and for being attached to the GPRS service. Most users that attach will also initiate a data transfer session (PDP context). PDP context related CDR's do include already the location information (partial CDR's produced e.g. every 15 minutes, include the current known location, Location Area/Routing Area/Cell Id). In this scenario the M-CDR does not bring any new information.

Even in ETSI GPRS charging group these issues are realized and might cause some further studies. M-CDR was however decided (in current basic form) to be included as an optional in the standard.

The Charging Gateway Function (CGF)

The ETSI GSM standard TS GSM 12.15 specifies two alternatives for the Charging Gateway Function, a centralised CGF and a CGF that isdistributed to the SGSN/GGSNs, i.e. integrated with the SGSN/GGSNs. The Ericsson GRPS solution supports the CGF alternatives specified by ETSI. The main functions of the CGF are collection, intermediate storage, and transfer of CDRs.

Ericsson has implemented the CGF to support different network scenarios, giving greater flexibility, and to limit infrastructure cost.

The distributed CGF function implemented in the SGSN/GGSN is called Integrated Basic CGF. The distributed (integrated) CGF can collect, store and forward the CDRs to an external system. The ASN.1/BER encoded output from the GSN is transported using FTP over TCP/IP. See figure below.

GGSN BillingBilling SystemSystem CGF CDR’ file ASN.1/BER, FTP, TCP/IP SGSN CDR’ file CGF
GGSN
BillingBilling
SystemSystem
CGF
CDR’
file
ASN.1/BER,
FTP, TCP/IP
SGSN
CDR’
file
CGF

Figure 2. The Distributed (Integrated) CGF.

.

The integrated CGF is suitable in networks that already have a mediation device or that already have a billing system that can interconnect directly to the GSN nodes.

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 13 (22)

By combining the distributed CGF with an enhanced centralized CGF Ericsson offers a flexible solution that is highly customizable. The enhanced centralized CGF gives the possibility to reduce the number of different interfaces towards the billing system and adds the possibility for various post-processing features. The non-volatile storage of CDRs in the GSN nodes provides better security against GSN breakdown, centralized CGF breakdown and GSN-CGF link failures.

The Ericsson BGw can act as an enhanced centralized CGF. It provides various charging data post processing features, e.g. filtering and combining CDRs. Refer to section 4 “The Ericsson Billing Gateway” for further information. The ASN.1/BER encoded output from the GSN is transported using FTP over TCP/IP to the Ericsson BGw. See figure below.

GGSN CGF CDR’ file
GGSN
CGF
CDR’
file

Ericsson

BGw

Centralize

Enhanced CGF

e.g format,

filtering,

merge CDRs

Enhanced CGF e.g format, filtering, merge CDRs Billing Billing System System ASN.1/BER, FTP, TCP/IP

BillingBilling

SystemSystem

filtering, merge CDRs Billing Billing System System ASN.1/BER, FTP, TCP/IP SGSN CDR’ file CGF Figure 3
filtering, merge CDRs Billing Billing System System ASN.1/BER, FTP, TCP/IP SGSN CDR’ file CGF Figure 3

ASN.1/BER,

FTP, TCP/IP

Billing Billing System System ASN.1/BER, FTP, TCP/IP SGSN CDR’ file CGF Figure 3 . The Centralised
SGSN CDR’ file CGF
SGSN
CDR’
file
CGF

Figure 3. The Centralised Enhanced CGF.

This solution is suitable in network where there is an interest to limit the impact on on the legacy billing system. It also allows for a faster introduction of new features. It can be an interim solution, meaning adaptation is first made in the Ericsson BGw to give some leap time for updating the existing billing system to support new features. The solution also addresses the need for limiting the number of interfaces to the billing system.

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 14 (22)

3.6 Handling of CDRs in GSN

The CDRs are first stored in the SGSN and GGSN and are then forwarded to an external system.

Storage of CDRs in GSN

The CDRs produced in the GGSN/SGSN are stored in the node, in the CGF. The CDR produced in the SGSN/GGSN is first buffered in volatile memory (RAM) before being stored in non-volatile memory (hard disk). The hard disk is duplicated for security reasons. The only limits to the archiving of CDRs are the available memory (in RAM) and configurable disk usage in the non-volatile memory.

The operator can configure the volatile memory (RAM) on PDP context level and on bulk level, to set when CDRs are to be generated. This can be done based on a time limit and/or on a volume limit.

The bulk volume limit is related to the total amount of data that is transferred by all active users through the GSN in question. In the RAM buffer, this limit is supervised constantly.

The hard disk capacity for charging data is expected typically to be equivalent to 72 hours of charging data (around 700 Mbytes). However it is up to the operator to decide how often to output CDRs from the GSN.

Output of CDRs

All CDRs related to a packet session are contained in a Charge Record Output (CRO), a charging data file. When the size of a generated CRO reaches a predefined value or when the age of the file has reached a predefined time, it is either spontaneously sent to the billing system or made accessible to an external billing system.

The operator can choose the output of the CDRs from SGSN/GGSN to a system for further processing based on the following configurable parameters:

destination (Enhanced CGF or Billing System);

threshold for CDR file disk usage in GSN (initiating a notification);

maximum for CDR file disk usage in GSN (initiating an alarm);

max time (age) of a CDR file;

Push or pull-based file retrieval (Push-based file retrieval means the GSN notifies the next level system whenever there is a new CDR file to be retrieved).

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 15 (22)

3.7 Connection to external system

The CGF provides an interface to transfer CROs to the billing system or to the Enhanced CGF. This interface is physically separate from the user traffic, i.e. the Gn interface. The protocol used on this interface is FTP over TCP/IP. The CDRs transferred via this interface are ASN.1 coded as specified in GSM TS 12.15.

The SGSN and the GGSN use a different interface (FTP over TCP/IP) than the AXE- MSC. The SGSN and GGSN also produce new types of CDRs that have different format than circuit-switched CDRs. The Billing Gateway can to transform the CDRs produced by the SGSN and the GGSN to a similar format as circuit-switched CDRs.

The CDRs files (CRO) can be exported to a backup medium O&M commands. The backup medium can be a remote FTP filestore on an external machine.

There are three possible ways to interconnect the existing billing system (see figure 4).

1)

Directly to the GSN nodes

2)

Via Ericsson’s Billing Gateway

3)

Via an operator proprietary or third party billing gateway or mediation device

BillingBilling SystemSystem 2 1 3 Ericsson Billing Gateway BGw BackboneBackbone SGSN GGSN SGSN GGSN SGSN
BillingBilling
SystemSystem
2
1 3
Ericsson
Billing
Gateway
BGw
BackboneBackbone
SGSN
GGSN
SGSN
GGSN
SGSN
GGSN
SGSN
GGSN

Figure 4. Different ways to interconnect to the billing system

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 16 (22)

4 The Ericsson Billing Gateway

The Ericsson BGw facilitates the introduction of GPRS services in the mobile network with functions that simplify charging for datacom services in operators’ billing systems. In particular, the Advanced Processing feature is very valuable. The Ericsson BGw does this with its flexible formatting, filtering, matching and rating modules.

The operator can charge for datacom services in a number of ways, e.g volume-based charging, with minimal affect on the existing billing system. The Ericsson BGw can either transform the data into a format the existing billing system can recognise, or it can be used for building new billing applications, specifically adapted to volume-based charging. Datacom services can be introduced quickly and operators can charge for the services immediately. This can be either an interim solution until the billing system has been adapted to handle volume-based charging, or a permanent solution.

The Ericsson BGw can also format CDRs from several sources into the same format. For example, data calls, mobile calls and fixed telephony calls can all be handled in the same way and thus be presented in the same bill.

The Ericsson BGw is also required in the initial pre-paid solution based on CDR and the ORGA type pre-paid system.

In conclusion, the Ericsson BGw is a powerful tool to support datacom charging. It is especially important in the early phases of introducing wireless datacom services, when rapid introduction is crucial for success, and existing billing systems are not prepared to handle the flexible charging in GPRS.

5 Charging Record Contents

This section includes a preliminary compliance list of ETSI 12.15. Note that as the development project is ongoing, the information is subject to change.

There is a column in the ETSI 12.15 list that shows whether the element is supported in Ericsson GPRS R8. The column ‘M/O’ indicates if the element is optional or mandatory in the ETSI standard.

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 17 (22)

5.1 GPRS charging data in SGSN (S-CDR)

Field

M/O

Supported or Not Supported in R8

 

Description

 

Record Type

M

Supported

GPRS SGSN PDP context record.

Network initiated PDP context

C

Not supported

Present if this is a network initiated PDP context.

Anonymous Access

C

Not supported

Set to true to indicate anonymous access (and that the Served IMSI is not supplied)

Indicator

Served IMSI

M

Supported

IMSI of the served party (if Anonymous Access Indicator is FALSE or not supplied).

Served IMEI

C

Not supported

The IMEI of the ME, if available.

SGSN Address

M

Supported

The IP address of the current SGSN.

MS Classmark

O

Supported

The mobile station classmark employed.

Routing area (RA)

O

Note 2)

Routing area at the time of the record creation.

Local Area Code (LAC)

O

Note 2)

Location area code at the time of the record creation.

Cell Identity (CI)

O

Note 2)

Cell id at the time of the record creation.

Charging ID

M

Supported

PDP context identifier used to identify this PDP context in different records created by GSNs

GGSN Address Used

M

Supported

The IP address of the GGSN currently used. The GGSN address

is

always the same for an activated PDP.

Access Point Name

M

Supported

The logical name of the connected access point to the external packet data network.

PDP Type

M

Supported

PDP type, e.g. X.25 or IP

Served PDP address

M

Supported

PDP address of the served IMSI, e.g. an IPv4, IPv6 or X.121.

 

M

Supported

A

list of changes in charging conditions for this PDP context,

List of traffic data volumes

each time stamped. Charging conditions are used to categorise traffic volumes, such as per QoS/tariff period. Initial and subsequently changed QoS and corresponding data values are listed. Data volumes are in Octets above the SNDCP layer and are separated for uplink and downlink traffic.

Record opening time

M

Supported

Time stamp when PDP context activation is created in this

 

SGSN

or

record opening time on following partial records

Duration

M

Supported

Duration of this record in the SGSN.

SGSN change

C

Supported

Present if this is first record after SGSN change.

Cause for record closing

M

Supported

The reason for the release of record from this SGSN.

Diagnostics

O

Being studied

A

more detailed reason for the release of the connection.

Record Sequence number

C

Supported

Partial record sequence number in this SGSN. Only present in case of partial records.

Node ID

O

Supported

Name of the recording entity

Record extensions

O

Note 1)

A

set of network/ manufacturer specific extensions to the

record.

Table 1: GPRS SGSN PDP context data

Note 1) Open issue if manufacturer specific extensions will be needed.

Note 2) Current indication is that these fields will only be present on the first S-CDR that is opened at PDP context activation and on the first S-CDR that is opened at SGSN change.

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 18 (22)

5.2 GPRS charging data in GGSN (G-CDR)

Field

M/O

Supported or Not Supported in R8

 

Description

Record Type

M

Supported

GPRS GGSN PDP context record.

Network initiated PDP context

C

Not supported

Present if this is a network initiated PDP context.

Anonymous Access

C

Not supported

Set to true to indicate anonymous access (and that the Served IMSI is not supplied).

Indicator

Served IMSI

M

Supported

IMSI of the served party (if Anonymous Access Indicator is FALSE or not supplied).

GGSN Address

M

Supported

The IP address of the GGSN used.

Charging ID

M

Supported

PDP context identifier used to identify this PDP context in different records created by GSNs

SGSN Address

M

Supported

List of SGSN addresses used during this record.

Access Point Name

M

Supported

The logical name of the connected access point to the external packet data network.

PDP Type

M

Supported

PDP type, e.g. X.25 or IP

Served PDP Address

M

Supported

PDP address, e.g. an IPv4, IPv6 or X.121.

Remote PDP Address

O

Not supported

List of PDP addresses of the remote host or DTE e.g. an IPv4, IPv6, or X.121 (Included if the PDP type is X.25)

Dynamic Address Flag

C

Supported

Indicates whether served PDP address is dynamic that is allocated during PDP context activation.

 

M

Supported

A

list of changes in charging conditions for this PDP context,

List of traffic data volumes

each time stamped. Charging conditions are used to categorise traffic volumes, such as per tariff period. Initial and subsequently changed QoS and corresponding data values are listed. Data volumes are in octets above the GTP layer and are separated for uplink and downlink traffic.

Record opening time

M

Supported

Time stamp when this record was opened.

Duration

M

Supported

Duration of this record in the GGSN.

Cause for record closing

M

Supported

The reason for the release of record from this GGSN.

Diagnostics

O

Being studied

A

more detailed reason for the release of the connection.

Record Sequence number

C

Supported

Partial record sequence number, only present in case of partial records.

Node ID

O

Supported

Name of the recording entity.

Record extensions

O

Note 1)

A

set of network/ manufacturer specific extensions to the

record.

Table 2: GPRS GGSN PDP context data

Note 1) Open issue if manufacturer specific extensions will be needed.

5.3 GPRS mobile station mobility management data in SGSN (M-CDR)

M-CDR is not supported in GPRS 2.0 (R8) but planned for future releases.

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 19 (22)

5.4 GPRS MO SMS data in SGSN (S-SMO-CDR)

Field

M

GPRS in R8

 

Description

/

support

 

O

Record Type

M

Supported

SGSN Mobile originated SMS.

Served IMSI

M

Supported

The IMSI of the subscriber.

Served IMEI

O

Being

The IMEI of the ME, if available.

studied

Served MSISDN

O

Supported

The primary MSISDN of the subscriber.

MS Classmark

M

Supported

The mobile station classmark.

Service Centre

M

Supported

The address (E.164) of the SMS-service centre.

Recording Entity

M

Supported

The E.164 number of the SGSN.

Location Area

O

Supported

The Location Area Code from which the message originated.

Code (LAC)

Routing Area

O

Supported

The Routing Area Code from which the message originated.

Code (RAC)

Cell Identity (CI)

O

Supported

The Cell Identity from which the message originated.

Event Time stamp

M

Supported

The time at which the message was received by the SGSN from the subscriber.

Message

M

Supported

A

reference provided by the MS uniquely identifying

Reference

this message.

SMS Result

C

Not

The result of the attempted delivery if unsuccessful.

supported

Record

O

Note1)

A

set of network/ manufacturer specific extensions to

extensions

the record.

Table 3: SGSN Mobile originated SMS record

Note 1) Open issue if manufacturer specific extensions will be needed.

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 20 (22)

5.5 GPRS MT SMS data in SGSN (S-SMT-CDR)

Field

M

GPRS in R8

Description

/

support

O

Record Type

M

Supported

SGSN Mobile terminated SMS.

Served IMSI

M

Supported

The IMSI of the subscriber.

Served IMEI

O

Being

The IMEI of the ME, if available.

studied

Served

O

Supported

The primary MSISDN of the subscriber.

MSISDN

MS Classmark

M

Supported

The mobile station classmark.

Service Centre

M

Supported

The address (E.164) of the SMS-service centre.

Recording

M

Supported

The E.164 number of the SGSN.

Entity

Location Area

O

Supported

The Location Area Code to which the message was delivered.

Code (LAC)

Note 2)

Routing Area

O

Supported

The Routing Area Code to which the message was delivered.

Code (RAC)

Note 2)

Cell Identity

O

Supported

The Cell Identity to which the message was delivered.

(CI)

Note 2)

Event Time

M

Supported

Delivery time stamp, time at which message was sent to the MS by the SGSN.

stamp

SMS Result

C

Not

The result of the attempted delivery if unsuccessful.

supported

Record

O

Note 1)

A set of network/ manufacturer specific extensions to the record.

extensions

Table 4: SGSN Mobile terminated SMS record

Note 1) Open issue if manufacturer specific extensions will be needed.

Note 2) In case of multiple SM transfers, the S-SMT- CDR will contain two sets of LAC, RAI & CI. The first set marks the LAC, RAI and CI of the first SM transferred, and the second set marks the LAC, RAI and CI for the last SM transferred. A field indicating the number of SMs summarised in the CDR will

Operator can configure how many short messages can be

combined into one CDR. This feature is used if several short messages are waiting for delivery to the subscriber in SMS Service Centre (e.g. due to subscriber being not reachable).

also be

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström

Guide 21 (22)

6

Abbreviations

ANS.1

Abstract Syntax Notation no.1

APN

Access Point Name

BER

Binary Encoding Rules

BGw

Billing Gateway

CAMEL

Customised Application for Mobile Enhanced Logic

CDR

Call Detail Record

CGF

Charging Gateway Function

CI

Cell Identity

CMIP

Common Management Information Protocol

CRO

Charging Record Output

ETSI

European Telecommunications Standard Institute

FTP

File Transfer Protocol

GGSN

Gateway GPRS Support Node

GPS

Global Positioning System

GPRS

General Packet Radio Service

GSM

Global System for Mobile Communication

GTP

GPRS Tunnelling Protocol

HLR

Home Location Register

HPLMN

Home Public Land Mobile Network

IMSI

International Mobile Station Identity

IN

Intelligent Network

ISP

Internet Service Provider

LA

Location Area

LAN

Local Area Network

MPS

Mobile Positioning System

O&M

Operation & Maintenance

LKG/X-99:0010

Rev A

04/22/99

© Ericsson. For internal use only

Charlotta Brändström

Guide 22 (22)

PDN

Packet Data Network

RA

Routing Area

QoS

Quality of Service

SMS

Short Message Service

SNDCP

Sub-Network Dependent Convergence Protocol

SP

Service Provider

TCP/IP

Transmission Control Protocol/Internet Protocol

UMTS

Universal Mobile Telecommunication System

VPLMN

Visited Public Land Mobile Network

© Ericsson. For internal use only

Rev A

04/22/99

LKG/X-99:0010

 

Charlotta Brändström