Offline Charging White Paper

Doc.
Code

eLTE2.2
Offline Charging Whitepaper

Issue 01
Date 2014-2-21

HUAWEI TECHNOLOGIES CO., LTD.

Issue 01 (2014-2-21) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees or
representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com

eLTE2.2
Offline Charging Whitepaper About This Document

ii

About This Document
Change History
Date Issue Description Prepared by
2014-2-21 01 Completed the draft. Liu Shaofeng (employee ID:
00129458)

eLTE2.2
Offline Charging Whitepaper Contents

iii

Contents
About This Document ............................................................................................................... ii
1 Overview ................................................................................................................................... 4
1.1 LTE Charging System ................................................................................................................................ 4
1.2 Charging Modes ........................................................................................................................................ 5
1.3 Online Charging ........................................................................................................................................ 6
1.4 Offline Charging ........................................................................................................................................ 7
1.5 Charging Mode Comparison ...................................................................................................................... 7
2 eLTE Offline Charging ............................................................................................................ 8
2.1 Solution Overview ..................................................................................................................................... 8
2.1.1 Network Architecture ........................................................................................................................ 8
2.1.2 Offline Charging CDRs ....................................................................................................................10
2.1.3 Mechanisms.....................................................................................................................................18
2.1.4 Specifications and Restrictions .........................................................................................................23
2.2 Solution Application Scenarios .................................................................................................................24
2.2.1 Application Solutions .......................................................................................................................24
2.2.2 Characteristics .................................................................................................................................28
2.3 Configuration Guide .................................................................................................................................30
3 References ............................................................................................................................... 31
A Acronyms and Abbreviations .............................................................................................. 32

eLTE2.2
Offline Charging Whitepaper 1 Overview

4

1 Overview
1.1 LTE Charging System
Charging systems are set up by carriers to apply the desired charging policies to subscribers to
evaluate network resource usage.
The LTE charging system is divided into two parts: offline charging and online charging.
The offline charging involves the P-GW, charging gateway (CG), and billing system
(BS).
The online charging involves the P-GW and online charging system (OCS).
Figure 1-1 shows the structure of the LTE charging system.
Figure 1-1 Structure of the charging system
Uu
S5
P-GW
S-GW
eNodeB
UE
PDN
Network
CG
Ga
SGi
Billing System
OCS/CCF
Gy
S1-U

In the preceding figure, the dotted line indicates a signaling interface and the solid line
indicates a signaling and data interface.
Devices related to the offline charging system in the preceding figure are described as
follows:
P-GW: collects charging information, generates charging data records (CDRs), and sends
the CDRs to the CG.
CG: After receiving CDRs, the CG stores, consolidates, and standardizes CDRs, and
then sends the processed standardized CDRs to the billing system (BS).
eLTE2.2

5

BS: processes received CDRs and generated final CDRs. The BS is the proprietary
system of customers. Huawei does not provide any device.
Devices related to the online charging system in the preceding figure are described as follows:
P-GW
Implements the traffic plane function (TPF). This function allows the P-GW to differentiate
and collect statistics of flow-based charging services, communicate with the OCS over the Gy
interface, and provide the prepayment for common subscribers and flow-based charging
subscribers.
Based on the filter information in the predefined or dynamically delivered charging rules, the
P-GW differentiates packets by service flows.
OCS
Provides the credit control function (CCF) for subscribers and implements the CCF of PS
services by enhancing the current online charging system. For the P-GW, the OCS can
determine whether a subscriber is prepaid and perform rating, credit quota allocation, and fee
deduction for prepaid subscribers.
1.2 Charging Modes
Charging modes are classified based on the three dimensions:
Based on whether charging is implemented in real time, charging modes are classified
into online charging and offline charging.
Based on whether charging is service-specific, charging modes are classified into
content-based charging and normal charging.
Based on charging granularities, charging modes are classified into time-based charging,
volume-based charging, and event-based charging.
Charging modes can overlap. For example, a subscriber may undergo online charging,
content-based charging, and time-based charging at the same time. The preceding aspects
from which charging modes are classified can be further categorized into three levels for a
better understanding of charging functions. The first level concerns real-time monitoring, the
second level concerns whether charging is implemented based on services, and the third level
concerns charging granularities, as shown in Figure 1-2.
eLTE2.2

6

Figure 1-2 Charging mode categories

1.3 Online Charging
Online charging enables the P-GW to implement real-time charging on mobile subscribers for
packet data network (PDN) resource usage.
When an online charging subscriber requests access to data services, the OCS server
determines whether to provide quotas (volume, time, or number of events) to the P-GW for
the subscriber based on the subscriber's subscription data and account balance. When the
subscriber is using data services, the OCS server monitors the usage of resources purchased
by the subscriber and deducts used quotas from the subscriber's account in real time. When
the account balance is exhausted, services are terminated.
Table 1-1 describes compliant specifications of online charging.
Table 1-1 Compliant specifications of online charging
Category Specification
IETF RFC 3588 Diameter Base Protocol
RFC 4006 Diameter Credit-Control Application
3GPP 3GPP TS 32.299 Telecommunication management; Charging
management; Diameter charging applications
3GPP TS 32.251 Telecommunication management; Charging
management; Packet Switched (PS) domain charging
eLTE2.2

7

1.4 Offline Charging
Offline charging enables the P-GW to implement non-real-time charging on mobile
subscribers for packet data network (PDN) resource usage. The eCNS600 sends generated
CDRs to the CG using GTPv2 (forwardly compatible with GTPv0 and GTPv1). The CG
stores, consolidates, and standardizes CDRs, and then sends the processed standardized CDRs
to the BS. Offline charging cannot provide real-time CDRs.
Table 1-2 describes compliant specifications of offline charging.
Table 1-2 Compliant specifications of offline charging
Category Specification
3GPP 3GPP TS 32.240, Charging management; Charging architecture and
principles
3GPP TS 32.298, Charging management; Charging Data Record (CDR)
parameter description
3GPP TS 32.251, Charging management; Packet Switched (PS) domain
charging
3GPP TS 32.295, Charging management; Charging Data Record (CDR)
transfer; Ga

1.5 Charging Mode Comparison
Compared with offline charging, online charging can trace the real-time usage of purchased
resources, deduct the used credit from the account balance in real time, inform subscribers of
insufficient account balance, and control subscriber service access flexibly.
Online charging depends on flow-based charging and has an impact on the gateway
performance. The online charging deployment requires the OCS server. The gateway reports
billing information about services to the OCS server. The OCS server delivers a quota based
on the subscribers' account balance to control service access.
On the EPC network, the PDN-GW needs to support online charging and connect to the OCF
over the Rf interface, and the S-GW does not need to support online charging. Online
charging has high requirements on real-time message interaction. You are advised to control
online charging for only local (non-roaming) subscribers.
The eLTE2.2 supports only offline charging.

eLTE2.2
Offline Charging Whitepaper 2 eLTE Offline Charging

8

2 eLTE Offline Charging
2.1 Solution Overview
Huawei eLTE broadband access solution is a LTE-based broadband access end-to-end
solution for industry application. The solution is used with NEs, such as the eCNS600 on the
LTE CN, charging gateway CG9812, base station DBS3900, UE eA660, and OSS iM2000. Its
charging solution logically inherits the charging architecture and networking of the LTE
network. It supports offline charging.
2.1.1 Network Architecture
In the eLTE offline charging solution, the P-GW is integrated in the eCNS600. The CG
(CG9812 provided by Huawei) can share the subrack and OMU with the eCNS600.
Figure 2-1 shows the eLTE offline charging networking. Arrows in the figure indicate
directions of CDR flows.
Figure 2-1 eLTE offline charging networking

eLTE2.2

9

You can configure multiple CGs. Each CG is identified by the IP address and port number. The
preceding figure is an example using two CGs.
You can configure multiple GTP' links from the eCNS600 to each CG for load sharing.
Table 2-1 describes functions of offline charging NEs.
Table 2-1 Functions of offline charging NEs
Functional Unit Description
eCNS600(P-GW)
Collects charging data, including duration and volume, generates
CDRs, and sends the CDRs to CGs.
CG9812(CG)
Stores, consolidates, and standardizes CDRs sent from the eCNS600,
adds fields customized by telecom operators to the CDRs, and sends
the standardized CDRs to a BS.
BS Processes the received CDRs from CGs and generates final CDRs.

Table 2-2 describes interfaces between offline charging NEs.
Table 2-2 Interfaces between offline charging NEs
Link Name Protocol
eCNS600-CG9812 Ga GTP'
CG9812-BS BS interface FTP/SFTP/FTAM

Figure 2-2 shows the Ga interface control plane protocol stack.
Figure 2-2 Ga interface control plane protocol stack

eLTE2.2

10

2.1.2 Offline Charging CDRs
Original CDRs
Original CDRs are unprocessed CDRs generated by the eCNS600.
Table 2-3 Original CDRs (PGW-CDR)
Field Name Attribute Tag
Value
Type Description
PGWRecord M 0xBF4F SET Indicates the PGW-CDR.
recordType M 0x80 INTEGER Indicates the PGW-CDR.
servedIMSI C 0x83 TBCD-STRING
(SIZE (3..8))
IMSI of a subscriber.
pGWAddress M 0xA4 GSNAddress Control-plane IP address of the
P-GW.
chargingID M 0x85 INTEGER
(0..4294967295)
Used to identify different IP CAN
bearers created by PCNs.
servingNodeAddress O
C
0xA6 SEQUENCE OF
GSNAddress
List of control-plane IP addresses
of serving nodes (SGSN or S-GW)
used during the record.
accessPointNameNI O
M
0x87 IA5String
(SIZE(1..63))
APN network identity (NI).
pdpPDNType O
M
0x88 OCTET STRING
(SIZE(2))
PDN type, such as IPv4, IPv6, and
IPv4v6.
servedPDPPDNAddress O
C
0xA9 PDPAddress IP address assigned for an IP CAN
bearer or PDN connection. When
the PDN type is IPv4, this field
records an IPv4 IP address. When
the PDN type is IPv6 or IPv4v6,
this field records an IPv6 IP
address.
dynamicAddressFlag O
C
0x8B BOOLEAN Indicates whether the IP address
assigned for the IP CAN bearer
activation, initial attach, and
UE-requested PDN connection is
dynamic. If the IP address is static,
this field is not displayed.
listOfTrafficVolumes O
M
0xAC SEQUENCE OF
ChangeOfCharCondit
ion
List of charging condition changes
for IP CAN bearers. Each change
contains the timestamp. Charging
conditions (for example, each rate
period) are used to categorize data
traffic. The list contains QoS
changed initially and later and
corresponding data traffic.
eLTE2.2

11

Value
Type Description
recordOpeningTime M 0x8D OCTET STRING
(SIZE(9))
Opening time of a record.
duration M 0x8E INTEGER Duration of a CDR.
causeForRecClosing M 0x8F INTEGER Closure cause of a CDR.
diagnostics O
M
0xB0 Diagnostics Detailed cause of a connection
release.
recordSequenceNumber C 0x91 INTEGER SN of certain CDRs displayed only
in certain CDRs.
nodeID O
M
0x92 IA5String
(SIZE(1..20))
P-GW name.
recordExtensions O
C
0xB3 ContentInfo A series of CDR extension
information defined by the network
or vendor.
localSequenceNumber O
M
0x94 INTEGER
(0..4294967295)
SN for the generation of all CDR
types.
apnSelectionMode O
M
0x95 ENUMERATED APN selection mode.
servedMSISDN O
M
0x96 AddressString(SIZE
(1..9))
MSISDN of a subscriber.
chargingCharacteristics M 0x97 OCTET STRING
(SIZE(2))
Charging characteristics used for
an IP CAN bearer.
chChSelectionMode O
M
0x98 ENUMERATED Charging characteristics selection
mode.
iMSsignalingContext O
C
0x99 NULL IP CAN bearer used for IMS
signaling when the signaling flag of
the IM-CN subsystem is set to 1.
externalChargingID O
C
0x9A OCTET STRING Charging ID received from a
non-EPC external network entity,
such as ICID.
servingNodePLMNIdenti
fier
O
M
0x9B OCTET STRING
(SIZE(3))
Records the PLMN ID (MCC and
MNC) of the serving node used in
the CDR if this field is set.
eLTE2.2

12

Value
Type Description
pSFurnishChargingInfor
mation
O
C
0xBC PSFurnishChargingIn
formation
Information about a real-time
charging session. In normal cases,
the P-GW records values delivered
by the BOSS through CCA
messages. For details about
abnormal cases, see real-time
charging standards. For example,
when the FCI subtracted from the
PS is 16, the code is 0x3136
occupying two bytes. You can infer
other codes in the same way.
servedIMEISV O
C
0x9D TBCD-STRING
(SIZE (8))
International mobile station
equipment identity and software
version (IMEISV) of a mobile
device if this field is set.
rATType O
C
0x9E INTEGER (0..255) Indicates the current RAT of an
MS if this field is set. For
definitions in the GTP, eGTP, and
PMIP scenarios, see 3GPP TS
29.060, 29.274, and 29.275,
respectively.
mSTimeZone O
C
0x9F1F OCTET STRING
(SIZE(2))
Current time zone of an MS if this
field is set.
userLocationInformation O
C
0x9F20 OCTET STRING User location information if this
field is set. This field is mandatory
when the S-GW informs the P-GW
of user location information. In
addition, the P-GW must record
latest location information. When
the P-GW generates certain latest
CDRs, it records latest user
location information in CDRs.
For definitions in GPRS and EPC
scenarios, see 3GPP TS 29.060 and
29.274, respectively.
cAMELChargingInforma
tion
O
C
0x9F21 OCTET STRING A group of CAMEL information
related to the IP CAN bearer. This
field applies only to GPRS.
eLTE2.2

13

Value
Type Description
listOfServiceData O
M
0xBF22 SEQUENCE OF
ChangeOfServiceCon
ditions
of all service data flows in IP CAN
bearers. The changes are
categorized based on each rate
group or the combination of each
rate group and service key. Each
change contains the timestamp.
Charging conditions (for example,
each rate period) are used to
categorize data traffic, shared time,
and the number of events. The list
contains QoS changed initially and
later and corresponding data traffic.
The online charging information
PS Furnish Charging
Information may be added to the
container of each service data flow
in case that the online charging
system (OCS) sends the
information.
Failure-Handling: This field is
displayed when the P-GW triggers
the failure control procedure.
servingNodeType O
C
0xBF23 SEQUENCE OF
ENUMERATED
List of control-plane serving node
types. Serving node types in the list
have a one-to-one relationship with
serving node IP addresses specified
by the Serving Node Address
field.
servedMNNAI OC 0xBF24 SubscriptionID IMSI-based mobile Node IDs if
this field is set.
pGWPLMNIdentifier OC 0x9F25 OCTET STRING
(SIZE(3))
PLMN ID (MCC and MNC) used
by a P-GW.
startTime OC 0x9F26 OCTET STRING
(SIZE(9))
Start time of a user IP-CAN
session. This field is displayed in
the CDR of the first bearer of the
IP-CAN session.
stopTime OC 0x9F27 OCTET STRING
(SIZE(9))
End time of a user IP-CAN session.
This field is displayed in the CDR
of the last bearer of the IP-CAN
session.
served3gpp2MEID Oc 0x9F28 OCTET STRING Mobile equipment identifier
(MEID) of a UE. This field is used
for 3GPP2 access.
eLTE2.2

14

Value
Type Description
pDNConnectionCharging
ID
O
M
0x9F29 INTEGER
(0..4294967295)
PDN connection ID used to
identify different CDRs that belong
to the same PDN connection.
iMSIunauthenticatedFlag O
C
0x9F2A NULL The provided servedIMSI is not
authenticated in emergency bearer
services.
userCSGInformation O
C
0xBF2B UserCSGInformation User CSG information about a UE.
The information includes CSG ID,
access mode, and CSG member ID.
threeGPP2UserLocationI
nformation
O
C
0x9F2C OCTET STRING User location information about an
MS. If the information is provided
by the MME, it is defined in 3GPP
TS 29.274.
servedPDPPDNAddress
Ext
O
C
0xBF2D PDPAddress IPv4 IP address assigned for an IP
CAN bearer or PDN connection
when the PDN type is IPv4v6.
dynamicAddressFlagExt O
C
0x9F2F BOOLEAN Indicates whether the IPv4 IP
address assigned for the IP CAN
bearer activation, initial attach, and
dynamic when the PDN type is
IPv4v6. If the IPv4 IP address is
static, this field is not displayed.

Where
M: Mandatory
O: Optional
C: Conditional. An item must be provided when prerequisites are met.
OM: A field is mandatory in CDRs if users select it.
OC: A field is mandatory in CDRs if users select it and certain conditions are met.
Final CDRs
Final CDRs are CDRs processed by the CG9812. After the CG9812 collects CDRs from the
eCNS600, it consolidates the CDRs and generates final CDRs that meet BS requirements.
Table 2-4 PGW-CDRs consolidated by the CG (China Mobile)
Value
Type Description
PGWRecord M 0xBF4F SET Indicates the PGW-CDR.
recordType M 0x80 INTEGER Indicates the PGW-CDR.
eLTE2.2

15

Value
Type Description
servedIMSI C 0x83 TBCD-STRING
(SIZE (3..8))
IMSI of a subscriber.
pGWAddress M 0xA4 GSNAddress Control-plane IP address of the
P-GW.
chargingID M 0x85 INTEGER
(0..4294967295)
Used to identify different IP CAN
bearers created by PCNs.
servingNodeAddress M 0xA6 SEQUENCE OF
GSNAddress
List of control-plane IP addresses
of serving nodes (SGSN or S-GW)
used during the record.
accessPointNameNI O
M
0x87 IA5String
(SIZE(1..63))
APN NI.
pdpPDNType O
M
0x88 OCTET STRING
(SIZE(2))
PDN type, such as IPv4, IPv6, and
IPv4v6.
servedPDPPDNAddress O
C
0xA9 PDPAddress IP address assigned for an IP CAN
bearer or PDN connection. When
the PDN type is IPv4, this field
records an IPv4 IP address. When
the PDN type is IPv6 or IPv4v6,
this field records an IPv6 IP
address.
dynamicAddressFlag O
C
0x8B BOOLEAN Indicates whether the IP address
assigned for the IP CAN bearer
activation, initial attach, and
dynamic. If the IP address is static,
this field is not displayed.
listOfTrafficVolumes O
M
0xAC SEQUENCE OF
ChangeOfCharCondit
ion
for IP CAN bearers. Each change
contains the timestamp. Charging
conditions (for example, each rate
period) are used to categorize data
traffic. The list contains QoS
changed initially and later and
corresponding data traffic.
recordOpeningTime M 0x8D OCTET STRING
(SIZE(9))
Opening time of a record.
duration M 0x8E INTEGER Duration of a CDR.
causeForRecClosing M 0x8F INTEGER Closure cause of a CDR.
diagnostics O
M
0xB0 Diagnostics Detailed cause of a connection
release.
recSequenceNumList C 0xB1 SequenceList Accumulated list of SNs of certain
P-GW CDRs.
eLTE2.2

16

Value
Type Description
nodeID O
M
0x92 IA5String
(SIZE(1..20))
P-GW name.
recordExtensions O
C
0xB3 SEQUENCE OF
ContentInfo
A series of CDR extension
information defined by the network
or vendor.
localSequenceNumberLi
st
O
M
0xB4 LocalSequenceNumb
erList
Accumulated list of SNs for the
generation of all CDR types.
apnSelectionMode O
M
0x95 ENUMERATED APN selection mode.
servedMSISDN O
M
0x96 AddressString(SIZE
(1..9))
MSISDN of a subscriber.
chargingCharacteristics M 0x97 OCTET STRING
(SIZE(2))
Charging characteristics used for
an IP CAN bearer.
chChSelectionMode O
M
0x98 ENUMERATED Charging characteristics selection
mode.
iMSsignalingContext O
C
0x99 NULL IP CAN bearer used for IMS
signaling when the signaling flag
of the IM-CN subsystem is set to 1.
externalChargingID O
C
0x9A OCTET STRING Charging ID received from a
non-EPC external network entity,
such as ICID.
servingNodePLMNIdenti
fier
O
M
0x9B OCTET STRING
(SIZE(3))
Records the PLMN ID (MCC and
MNC) of the serving node used in
the CDR if this field is set.
pSFurnishChargingInfor
mation
O
C
0xBC PSFurnishChargingIn
formation
Information about a real-time
charging session. In normal cases,
the P-GW records values delivered
by the BOSS through CCA
messages. For details about
abnormal cases, see real-time
charging standards. For example,
when the FCI subtracted from the
PS is 16, the code is 0x3136
occupying two bytes. You can infer
other codes in the same way.
servedIMEISV O
C
0x9D TBCD-STRING
(SIZE (8))
Records the IMEISV of a mobile
device if this field is set.
rATType O
C
0x9E INTEGER (0..255) Indicates the current RAT of an
MS if this field is set. For
definitions in the GTP, eGTP, and
PMIP scenarios, see 3GPP TS
29.060, 29.274, and 29.275,
respectively.
eLTE2.2

17

Value
Type Description
mSTimeZone O
C
0x9F1F OCTET STRING
(SIZE(2))
Current time zone of an MS if this
field is set.
userLocationInformation O
C
0xBF20 SEQUENCE OF
OCTET STRING
User location information if this
field is set. This field is mandatory
when the S-GW informs the P-GW
of user location information. In
addition, the P-GW must record
latest location information. When
the P-GW generates certain latest
CDRs, it records latest user
location information in CDRs.
For definitions in GPRS and EPC
scenarios, see 3GPP TS 29.060 and
29.274, respectively.
cAMELChargingInforma
tion
O
C
0x9F21 OCTET STRING A group of CAMEL information
related to the IP CAN bearer. This
field applies only to GPRS.
listOfServiceData O
M
0xBF22 SEQUENCE OF
ChangeOfServiceCon
ditions
of all service data flows in IP CAN
bearers. The changes are
categorized based on each rate
group or the combination of each
rate group and service key. Each
change contains the timestamp.
Charging conditions (for example,
each rate period) are used to
categorize data traffic, shared time,
and the number of events. The list
contains QoS changed initially and
later and corresponding data traffic.
The online charging information
PS Furnish Charging
Information may be added to the
container of each service data flow
in case that the OCS sends the
information.
Failure-Handling: This field is
displayed when the P-GW triggers
the failure control procedure.
servingNodeType M 0xBF23 SEQUENCE OF
ENUMERATED
List of control-plane serving node
types. Serving node types in the list
have a one-to-one relationship with
serving node IP addresses specified
by the Serving Node Address
field.
servedMNNAI OC 0xBF24 SubscriptionID IMSI-based mobile Node IDs if
this field is set.
eLTE2.2

18

Value
Type Description
pGWPLMNIdentifier OC 0x9F25 OCTET STRING
(SIZE(3))
PLMN ID (MCC and MNC) used
by a P-GW.
startTime OC 0x9F26 OCTET STRING
(SIZE(9))
Start time of a user IP-CAN
session. This field is displayed in
the CDR of the first bearer of the
IP-CAN session.
stopTime OC 0x9F27 OCTET STRING
(SIZE(9))
End time of a user IP-CAN session.
This field is displayed in the CDR
of the last bearer of the IP-CAN
session.
served3gpp2MEID Oc 0x9F28 OCTET STRING MEID of a UE. This field is used
for 3GPP2 access.
pDNConnectionCharging
ID
O
M
0x9F29 INTEGER
(0..4294967295)
PDN connection ID used to
identify different CDRs that belong
to the same PDN connection.
servedPDPPDNAddress
Ext
O
C
0xBF2B PDPAddress IPv4 IP address assigned for an IP
CAN bearer or PDN connection
when the PDN type is IPv4v6.
dynamicAddressFlagExt O
C
0x9F2F BOOLEAN Indicates whether the IPv4 IP
address assigned for the IP CAN
bearer activation, initial attach, and
dynamic when the PDN type is
IPv4v6. If the IPv4 IP address is
static, this field is not displayed.
consolidationResult M 0x9F65 ENUMERATED Consolidated result.

2.1.3 Mechanisms
Original CDR Processing of the eCNS600
CGR Transmission Based On CG Load Sharing
The eCNS600 can connect to multiple CGs and you can configure different (depending on
user planning and ranging from 0 to 5 in descending order) or same priorities for these CGs.
If the CGs have different priorities, the eCNS600 selects the CG with the highest priority.
The eCNS600 supports CG load sharing. You can configure multiple CGs of the same priority
on the eCNS600 to achieve CG loading sharing. When a large number of original CDRs need
to be processed, the eCNS600 can send these CDRs to different CGs. This reduces the
performance requirement on a single CG and improves the reliability of original CDR
transmission.
eLTE2.2

19

Ga Interface Link Detection
If the eCNS600 does not receive any response after sending original CDRs to a CG, the
eCNS600 sends the original CDRs to the CG again. If the response times out, the eCNS600
considers the CG to be faulty.
If there is no original CDR to send, the eCNS600 sends an Echo message to the CG every
other minute. If the eCNS600 does not receive any response for N consecutive times, the
eCNS considers the CG to be faulty. N is set to 3 by default.
CDR Storage
If the link between the eCNS600 and the CG is faulty, the eCNS600 buffers original CDRs.
After the link recovers, the eCNS600 sends the CDRs to the CG.
After receiving original CDRs from the eCNS600, the CG9812 generates final CDRs. The
CG9812 supports the storage of final CDRs. Final CDRs are stored on the physical medium
for a specified period. When the specified period expires, the final CDRs are automatically
deleted from the physical medium.
CDR Generation Mechanism
The eCNS600 can control whether to generate original CDRs based on a specified charging
characteristic. Therefore, users can easily control the original CDR generation based on site
requirements. After generating original CDRs, the eCNS600 sends them to the CG9812.
An original CDR contains multiple fields such as subscriber ID, service time segment, and
service duration. The BS charges subscribers based on the information.
The original CDR generation procedure consists of the following three phases:
Generating original CDRs
When the EPS bearer is set up and a UE performs services, the eCNS600 generates original
CDRs at a specific point (charging point when charging information is generated upon the
fulfillment of charging conditions) and records the UE's subsequent actions that require
charging in the original CDRs.
Generating intermediate CDRs
When the EPS bearer is set up and a UE performs services, the eCNS600 generates
intermediate CDRs if the time, volume, or number of QoS changes reaches a specified
threshold.
Generating final CDRs
When the services of the UE is about to stop and before the EPS bearer is released, the
eCNS600 generates final CDRs and the generation of new original CDRs is stopped.
The preceding procedure shows that the eCNS600 may generate multiple original CDRs for a
service procedure. The BS consolidates these original CDRs and implements final billing.
Original CDRs fixedly comply with 3GPP Release 9. Roaming subscribers, visiting
subscribers, and home subscribers are not differentiated in original CDRs. They are uniformly
taken as home subscribers for charging mode selection in CDRs.
eLTE2.2

20

CDR Transmission Mechanism
After the eCNS600 generates CDRs, it encodes the original CDRs in Abstract Syntax
Notation One (ASN.1) format, encapsulates the CDRs using GTP', and then sends the CDRs
to CGs.
Device Reliability
Users deploy the active and standby boards in the hardware and software systems of the
eCNS600, and by using the automatic failover mechanism in HA systems, system reliability
and service continuity are guaranteed.
Original CDR Processing of the CG9812
The CG9812 provides strong CDR processing functions as follows:
CDR collection function
CDR preprocessing function
CDR storage function
CDR auto-deletion function
CDR auto-backup function
CDR browsing and query functions
CDR Collection Function
The CG9812 collects CDRs from the eCNS600 according to the GTP' protocol and supports
the following CDR types:
S-CDR
G-CDR
M-CDR
S-SMO-CDR
S-SMT-CDR
LCS-MT-CDR
LCS-MO-CDR
LCS-NI-CDR
eG-CDR
S-MB-CDR
G-MB-CDR
S-GW-CDR
P-GW-CDR
Among them, the LCS-MT-CDR, LCS-MO-CDR, and LCS-NI-CDR exist in only 3GPP
Release 4 and later versions, S-MB-CDR, G-MB-CDR, and eG-CDR exist in only 3GPP
Release 6 and later versions, and S-GW-CDR and P-GW-CDR exist in only 3GPP Release 8
and later versions.
The eLTE offline charging solution provides only the P-GW-CDR type whose CDRs are
generated by the P-GW on the LTE network. Therefore, the type of original CDRs processed by
the CG9812 from the eCNS600 is fixed at P-GW-CDR.
eLTE2.2

21

Original CDR Preprocessing Function
CDR consolidation function
This function is optional.
PDPs or EPS bearers involved in the same activation may generate multiple intermediate
CDRs. The CG9812 can maximize the consolidation of these intermediate CDRs into one or
multiple final CDRs.
Currently, the consolidation of the S-CDR, G-CDR, eG-CDR, S-GW-CDR, and P-GW-CDR
is supported.
CDR sorting function
The CG9812 stores collected CDRs to different channels based on a sorting criterion. The
sorting criterion is configurable. There are two types of sorting criteria: CDR type and
charging characteristic. This function enables final CDRs to be sorted based on configurable
conditions required by customers, meeting different charging policy requirements of the BS
and facilitating the BS to process CDRs.
CDR validity verification function
The CG9812 supports the CDR validity verification function. When the CG9812 collects an
incorrect CDR, which might be generated by the eCNS600 or due to network conditions, the
CDR fails to be decoded on the CG9812 and will not be sent to the BS.
CDR Storage Function
Original CDR storage function
Original CDRs are unprocessed CDRs collected by the CG9812 from the eCNS600.
The CG9812 stores of original CDRs. Original CDRs are stored on the physical medium for a
specified period. When the specified period expires, the original CDRs are automatically
deleted from the physical medium.
Final CDR storage function
The CG9812 collects CDRs from the eCNS600, processes the CDRs (for example,
consolidating them), and generates final CDRs that meet BS requirements. Then, the CG9812
sends the final CDRs to the BS.
The CG9812 supports the storage of final CDRs. Final CDRs are stored on the physical
medium for a specified period. When the specified period expires, the final CDRs are
automatically deleted from the physical medium.
CDR Auto-Deletion Function
The CG9812 supports original and final CDR auto-deletion. Original and final CDRs are
stored in files and deleted automatically when they expire. You can set the storage duration of
original and final CDRs. The default value is 5 days.
CDR Auto-Backup Function
The CG9812 supports original and final CDR auto-backup. Original and final CDRs can be
backed up locally or remotely on the network according to the configurations. In local backup
mode, the CG9812 backs up files to a local disk or other storage devices. In remote backup
mode, the CG9812 backs up files to a remote disk.
eLTE2.2

22

CDR Browsing and Query Functions
CDR browsing function
You can browse CDR files in all kinds of client-based readable formats on the CG9812 client.
CDR query function
You can query CDRs based on query criteria and browse query results on the CT9812 client.
CDR Transmission Mechanism
The CG9812 sends final CDRs to the BS specified by customers using FTP, SFTP, or FTAM.
Customers have high requirements on network security. Therefore, you are advised to use
SFTP. SFTP is a secure file transfer protocol. It authenticates information and data using
encrypted transmission and provides a secure encryption method for file transmission.
The SFTP supports password authentication and key authentication.
Password authentication
The CG9812 logs in to the remote server by using the user name and password, and then
uploads CDRs to the server.
Key authentication
Indicates that a pair of keys are generated for authentication by using SSH. In this mode, a
remote security channel is set up between the CG9812 and remote server for encrypted data
transmission, which prevents attacks, DNS spoofing, and IP spoofing.
Device Fault Management
When the CG9812 uploads CDR files to the BS, alarms might be generated due to the
following causes:
An exception occurs on distribution links.
An alarm might be generated because of network error, peer server exception, or incorrect
user name and password.
Transmitting CDR files fails.
An alarm might be generated because the CG9812 is unable to access the BS or memory of
storage devices in the BS is insufficient.
In pull mode, alarms might be generated due to the following causes:
The BS does not collect CDR files for a long time.
This problem may be caused by network error and BS failure.
The BS does not delete CDR files after CDR files are collected.
In this case, final CDR files are accumulated. This results in insufficient disk memory.
Device Reliability
The reliability of final CDR files of the CG9812 can be guaranteed based on the following
two aspects:
eLTE2.2

23

HA system
Users deploy the active and standby boards in the hardware and software systems of the
CG9812, and by using the automatic failover mechanism in HA systems, system reliability
and service continuity are guaranteed.
Hard disk subsystems configured as the RAID
The CG9812 uses the DRBD technology to automatically synchronize disk data on the active
and standby boards. This ensures the consistency and avoids losses of final CDR files when a
faulty board switches over to another board.
2.1.4 Specifications and Restrictions
Specifications
The following describes technical specifications for the charging solutions:
Performance data between the eCNS600 and CG9812
Original CDR output capability of a pair of eCNS600 boards: 70 CDRs/s
Receiving and processing capability of a pair of CG9812 boards: 4000 CDRs/s
Possible transmission error rate: 0.5%
Performance data between the CG9812 and BS
Size of the transmitted CDR file: 64 KB to 20 MB
FTP transmission period: 1 second to 6 hours
Throughput: About 200 MB/hour in FTP mode
Possible transmission error rate: 0.5%
Restrictions
Networking and service restrictions:
The offline charging is limited to the LTE network. It applies only to the LTE UE
charging in the LTE network.
The online charging, content-based charging, and flow-based charging are not supported.
In addition, the Gx interface used to interconnect with the standard PCRF is not
supported.
The charging function does not involve inter-PLMN roaming and does not support the
S-GW. It supports only the P-GW.
The eCNS600 can interconnect with only the CG9812. One eCNS600 supports a
maximum of 10 CG9812s.
The non-roaming and roaming scenarios described in 3GPP specifications are not
differentiated in the offline charging and both scenarios are uniformly taken as the
non-roaming scenario. Roaming subscribers, visiting subscribers, and home subscribers
are not differentiated in original CDRs. They are uniformly taken as home subscribers
for charging mode selection in CDRs.
The charging function does not support CDRs compatible with old versions. CDRs
fixedly comply with 3GPP Release 9 in October 2010.
O&M restrictions:
eLTE2.2

24

Configuring charging parameters dynamically, such as switches or thresholds, and not
affecting activated UEs.
Reloading a license file or enabling/disabling offline charging does not affect activated
UEs.
CDRs that have been generated on the active board and have not been sent to the CDR
pool of the CG9812 may be lost when the eCNS600 boards are being switched over.
Flow information that is not recorded in CDRs may be lost.
When the free space on the hard disk is insufficient, the eCNS600 discards new CDRs.
The offline charging for eCNS600 R2 supports the 600 kbit/s bearer. The CDR buffer
supports a maximum of five days according to the original CDR output capability of a
pair of eCNS600 boards.
The offline charging for eCNS600 R2 supports only the DST whose offset is 60 minutes
or 120 minutes.
2.2 Solution Application Scenarios
2.2.1 Application Solutions
Typical Independent Networking
If the customer requires offline charging in single eCNS600 networking, the offline charging
system needs to interconnect with the customer's BS. Generally, the CG9812 is deployed with
the eCNS600 in the same equipment room. The CG9812 can share one subrack and OMU
with the eCNS600 when the eCNS600 provides a pair of vacant slots. If the slots of the
eCNS600 are insufficient, the CG9812 uses an independent subrack and OMU. Figure 2-3
shows the typical independent networking.
Figure 2-3 Typical independent networking
PDN Network
CG
Billing System
SGi
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
Ga

Typical Multi-CN Networking
In multiple eCNS600 networking, eCNS600s cover different areas and support S5, S8, S10,
and S6a interfaces between them, including in the roaming scenario.
If the customer requires offline charging, the offline charging system needs to interconnect
with the customer's BS. Generally, one CG9812 is deployed if its capability is sufficient, and
it uses an independent subrack and OMU. The CG9812 needs to collect CDRs on multiple
CNs. In certain scenarios, the CG9812 shares one subrack and OMU with the eCNS600 when
eLTE2.2

25

the eCNS600 provides vacant ports. This reduces device and maintenance costs. Figure 2-4
shows the typical multi-CN networking (single CG).
Figure 2-4 Typical multi-CN networking (single CG)
PDN Network
CG
Billing System
SGi
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
Ga

In certain scenarios, multiple CG9812s are deployed for load sharing and disaster tolerance.
Each CG needs to collect CDRs of multiple CNs. Generally, the CG9812s use independent
subracks and OMUs. In certain scenarios, the CG9812 shares one subrack and OMU with the
eCNS600 when the eCNS600 provides vacant ports. This reduces device and maintenance
costs. Figure 2-5 shows the typical multi-CN networking (multiple CGs).
eLTE2.2

26

Figure 2-5 Typical multi-CN networking (multiple CGs)
PDN Network
CG
Billing System
SGi
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
Ga
CG

Multi-CN Disaster Tolerance Networking
In multiple eCNS600 pool networking, eCNS600s cover overlapped areas and inter-CN load
is shared.
with the customer's BS. One CG9812 is deployed for each eCNS600 for load sharing and
disaster tolerance. The CG9812 shares one subrack and OMU with the eCNS600 when the
eCNS600 provides vacant ports. If the slots of the eCNS600 are insufficient, the CG9812 uses
an independent subrack and OMU. Each CG9812 collects CDRs of multiple CNs in load
sharing mode. Figure 2-6 shows the multi-CN disaster tolerance networking.
eLTE2.2

27

Figure 2-6 Multi-CN disaster tolerance networking
Uu
eCNS
eNodeB
UE
S1-U
PDN Network
CG
Ga
Billing System
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
SGi
CG
Ga

LTE Dual Networking
The coverage of two eCNS600s is overlapped and services on two network are strictly
isolated.
with the customer's BS. One CG9812 is deployed on each network for isolation. Each
CG9812 collects only original CDRs of the current CN. In most scenarios, the CG9812 shares
one subrack and OMU with the eCNS600 when the eCNS600 provides vacant ports. If the
slots of the eCNS600 are insufficient, the CG9812 uses an independent subrack and OMU.
Figure 2-7 shows the LTE dual networking.
Figure 2-7 LTE dual networking
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
PDN Network
CG
Ga
Billing System
Uu
eCNS
eNodeB
UE
S1-U
LTE Network
SGi
CG
Ga

eLTE2.2

28

2.2.2 Characteristics
The eLTE offline charging solution significantly simplifies the PS charging solution provided
by Huawei. It deletes multi-level control in the PS charging solution, reserves the
customization of generating CDRs based on APNs and charging characteristics (CCs), and
reserves the flexible configuration of holidays and festivals, weeks, rate durations, and
corresponding rates, and reserves charging information collection of CDRs.
Customizing CDR Generation Modes Based on APNs and Charging
Characteristics
CC indicates the charging types for subscribers, including normal billing, hot billing, prepaid,
flat billing, and specific-value. CDRs are generated based on charging types.
The eCNS600 allows you to configure CCs for subscribers based on APNs. This function
allows carriers to specify CDR generation methods (by duration or by traffic) for different
types of subscribers.
The eCNS600 does not differentiate local, roaming, and visiting scenarios. Therefore, the
charging does not differentiate charging control in the preceding three scenarios currently. In
addition, the charging method is set to normal offline charging fixedly. Compared with the
complete configuration model of PS charging solution, the configuration model for the eLTE
offline charging solution can be simplified, as shown in Figure 2-8.
eLTE2.2

29

Figure 2-8 Simplified configuration model of hierarchical control

Normal billing
Normal billing is used to charge subscribers based on transmitted data traffic or duration
irrespective of service types of data.
It complies with 3GPP specifications and mainly records external network resources used by
an MS.
Hot billing
Hot billing is similar to normal billing. The only difference lies in that hot billing enables
CDRs to be generated faster than normal billing.
After the eCNS600 sends CDRs to the CG9812, the BS delivers dedicated commands to the
CG9812, instructing it to process the CDRs carrying the hot billing flag. Therefore, the BS
can preferentially process the CDRs carrying the hot billing flag sent from the eCNS600 to
the CG9812.
Prepaid
Prepaid subscribers need to pay certain fees before they use a service. If fees are insufficient
to cover the service, the service will be forcibly stopped.
eLTE2.2

30

Flat billing
Subscribers are charged at a fixed rate by a specified period (for example, by month).
The eCNS600 billing system collects and sends only CDR information about flat billing
subscribers, such as traffic and time, to the CG9812 and charges subscribers based on
subscription.
Specific-value
Reserved bits of the CC are canceled in 3GPP TS 32.298 V860 and later. Only normal billing,
hot billing, prepaid, and flat billing are kept for forward compatibility. Besides these
keywords, you can customize special CC values. The CC values range from 0x0000 to 0xffff.
If the UE activation request message contains the CC attribute, an AND operation is
performed on the CC value and CC mask configured on the eCNS600. If multiple results are
generated, the result of the highest priority configured based on the CC is selected based on
the configured priorities.
Customizing Rate Switch Points Based on APNs and Charging Characteristics
The eCNS600 allows users to flexibly set holidays and festivals, weeks, rate duration, and
corresponding rates, enhancing charging information collection of CDRs. Telecom operators
can set different rates for specified durations of holidays and festivals, weekends, and
workdays on the eCNS600 to attract mobile subscribers' consumption and increase telecom
operators' revenues.
Rates set for MSs apply to the following subscribers:
Normal billing subscribers
Hot billing subscribers
Prepaid subscribers
Global subscribers, including all the preceding subscribers
For example, you can set different rates for weekends and workdays for normal billing
subscribers on the eCNS600.
When it is 00:00 on Saturday, the eCNS600 charges mobile subscribers based on the
weekend rate.
When it is 00:00 on Monday, the eCNS600 charges mobile subscribers based on the
workday rate.
2.3 Configuration Guide
For details about how to configure data from the eCNS to the CG, see Ga Interface
Configuration Guide by choosing eCNS Product Documentation > Installation and
Commissioning > Initial Configuration > Configuring Data to the CG.
For details about how to activate the eCNS offline charging feature, see Activating Offline
Charging by choosing eCNS Product Documentation > Installation and
Commissioning > Feature Configuration > eCNSFD-110009 Offline Charging
Configuration.
For details about how to configure CG9812 data, see Initial Configuration by choosing
CG9812 Product Documentation > Software Commissioning.
eLTE2.2
Offline Charging Whitepaper 3 References

31

3 References
eCNS600V100R002C00 Offline Charging Requirement Analysis
eCNS600V100R002C00 Offline Charging Feature Design Guide
Huawei CDR Format Description (PS, R9 V940) (for China Mobile)
Huawei CDR ASN.1 Tags and Types (PS Domain, R9 V940)

eLTE2.2
Offline Charging Whitepaper A Acronyms and Abbreviations

32

A Acronyms and Abbreviations
A
APN access point name

C
CDR charging data record
C-GW charging gateway

G
GPRS general packet radio service
GTP GPRS tunneling protocol
GTP' The GPRS protocol used for CDR transport

I
IMSI international mobile subscriber identity
IP Internet Protocol

M
MME mobility management entity

P
PDN packet data network
P-GW PDN gateway
PGW-CDR P-GW generated CDR
PLMN public land mobile network
eLTE2.2
Offline Charging Whitepaper A Acronyms and Abbreviations

33

Q
QoS quality of service

R
RAI routing area identity
RAT radio access technology

S
S-GW serving Gateway

T
TAI tracking area identity

U
UE user equipment
ULI user location information

Offline Charging White Paper

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Offline Charging White Paper

Uploaded by

Copyright:

Available Formats

Doc.

You might also like