Offline Charging White Paper

Doc.
Code
eLTE2.2
Offline Charging Whitepaper
Issue
01
Date
2014-2-21
HUAWEI TECHNOLOGIES CO., LTD.
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
Issue 01 (2014-2-21)
Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.
eLTE2.2
About This Document
About This Document

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

00129458)

ii
eLTE2.2
Contents
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
Issue 01 (2014-2-21)

iii
eLTE2.2
1 Overview
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
OCS/CCF
Gy
eNodeB
UE
Uu
S-GW
S1-U
P-GW
S5
SGi
PDN
Network
Ga
CG
Billing System
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).
Issue 01 (2014-2-21)

eLTE2.2
1 Overview
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.
Issue 01 (2014-2-21)

eLTE2.2
1 Overview
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
Issue 01 (2014-2-21)

eLTE2.2
1 Overview
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.
Issue 01 (2014-2-21)

eLTE2.2
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
Issue 01 (2014-2-21)

eLTE2.2
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
Issue 01 (2014-2-21)

eLTE2.2
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
0xBF4F
SET
Indicates the PGW-CDR.
recordType
0x80
INTEGER
servedIMSI
0x83
TBCD-STRING
(SIZE (3..8))
IMSI of a subscriber.
pGWAddress
0xA4
GSNAddress
Control-plane IP address of the

P-GW.
chargingID
0x85
INTEGER
(0..4294967295)
Used to identify different IP CAN

bearers created by PCNs.
servingNodeAddress
OC
0xA6
SEQUENCE OF
GSNAddress
List of control-plane IP addresses

of serving nodes (SGSN or S-GW)
used during the record.
accessPointNameNI
OM
0x87
IA5String
(SIZE(1..63))
APN network identity (NI).
pdpPDNType
OM
0x88
OCTET STRING
(SIZE(2))
PDN type, such as IPv4, IPv6, and

IPv4v6.
servedPDPPDNAddress
OC
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
OC
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
OM
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.
Issue 01 (2014-2-21)

10
eLTE2.2
Field Name
Attribute
Tag
Value
Type
Description
recordOpeningTime
0x8D
OCTET STRING
(SIZE(9))
Opening time of a record.
duration
0x8E
INTEGER
Duration of a CDR.
causeForRecClosing
0x8F
INTEGER
Closure cause of a CDR.
diagnostics
OM
0xB0
Diagnostics
Detailed cause of a connection

release.
recordSequenceNumber
0x91
INTEGER
SN of certain CDRs displayed only

in certain CDRs.
nodeID
OM
0x92
IA5String
(SIZE(1..20))
P-GW name.
recordExtensions
OC
0xB3
ContentInfo
A series of CDR extension

information defined by the network
or vendor.
localSequenceNumber
OM
0x94
INTEGER
(0..4294967295)
SN for the generation of all CDR

types.
apnSelectionMode
OM
0x95
ENUMERATED
APN selection mode.
servedMSISDN
OM
0x96
AddressString(SIZE
(1..9))
MSISDN of a subscriber.
chargingCharacteristics
0x97
OCTET STRING
(SIZE(2))
Charging characteristics used for

an IP CAN bearer.
chChSelectionMode
OM
0x98
ENUMERATED
Charging characteristics selection

mode.
iMSsignalingContext
OC
0x99
NULL
IP CAN bearer used for IMS

signaling when the signaling flag of
the IM-CN subsystem is set to 1.
externalChargingID
OC
0x9A
OCTET STRING
Charging ID received from a

non-EPC external network entity,
such as ICID.
servingNodePLMNIdenti
fier
OM
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.
Issue 01 (2014-2-21)

11
eLTE2.2
Field Name
Attribute
Tag
Value
Type
Description
pSFurnishChargingInfor
mation
OC
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
OC
0x9D
TBCD-STRING
(SIZE (8))
International mobile station

equipment identity and software
version (IMEISV) of a mobile
device if this field is set.
rATType
OC
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
OC
0x9F1F
OCTET STRING
(SIZE(2))
Current time zone of an MS if this

field is set.
userLocationInformation
OC
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
Issue 01 (2014-2-21)
OC
0x9F21
OCTET STRING
A group of CAMEL information

related to the IP CAN bearer. This
field applies only to GPRS.

12
eLTE2.2
Field Name
Attribute
Tag
Value
Type
Description
listOfServiceData
OM
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
OC
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.
Issue 01 (2014-2-21)

13
eLTE2.2
Field Name
Attribute
Tag
Value
Type
Description
pDNConnectionCharging
ID
OM
0x9F29
INTEGER
(0..4294967295)
PDN connection ID used to

identify different CDRs that belong
to the same PDN connection.
iMSIunauthenticatedFlag
OC
0x9F2A
NULL
The provided servedIMSI is not

authenticated in emergency bearer
services.
userCSGInformation
OC
0xBF2B
UserCSGInformation
User CSG information about a UE.

The information includes CSG ID,
access mode, and CSG member ID.
threeGPP2UserLocationI
nformation
OC
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
OC
0xBF2D
PDPAddress
IPv4 IP address assigned for an IP

CAN bearer or PDN connection
when the PDN type is IPv4v6.
dynamicAddressFlagExt
OC
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)
Field Name
Attribute
Tag
Value
Type
Description
PGWRecord
0xBF4F
SET
recordType
0x80
INTEGER
Issue 01 (2014-2-21)

14
eLTE2.2
Field Name
Attribute
Tag
Value
Type
Description
servedIMSI
0x83
TBCD-STRING
(SIZE (3..8))
IMSI of a subscriber.
pGWAddress
0xA4
GSNAddress
Control-plane IP address of the

P-GW.
chargingID
0x85
INTEGER
(0..4294967295)
Used to identify different IP CAN

bearers created by PCNs.
servingNodeAddress
0xA6
SEQUENCE OF
GSNAddress
List of control-plane IP addresses

of serving nodes (SGSN or S-GW)
used during the record.
accessPointNameNI
OM
0x87
IA5String
(SIZE(1..63))
APN NI.
pdpPDNType
OM
0x88
OCTET STRING
(SIZE(2))
PDN type, such as IPv4, IPv6, and

IPv4v6.
servedPDPPDNAddress
OC
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
OC
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
OM
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
0x8D
OCTET STRING
(SIZE(9))
Opening time of a record.
duration
0x8E
INTEGER
Duration of a CDR.
causeForRecClosing
0x8F
INTEGER
Closure cause of a CDR.
diagnostics
OM
0xB0
Diagnostics
Detailed cause of a connection

release.
recSequenceNumList
0xB1
SequenceList
Accumulated list of SNs of certain

P-GW CDRs.
Issue 01 (2014-2-21)

15
eLTE2.2
Field Name
Attribute
Tag
Value
Type
Description
nodeID
OM
0x92
IA5String
(SIZE(1..20))
P-GW name.
recordExtensions
OC
0xB3
SEQUENCE OF
ContentInfo
A series of CDR extension

information defined by the network
or vendor.
localSequenceNumberLi
st
OM
0xB4
LocalSequenceNumb
erList
Accumulated list of SNs for the

generation of all CDR types.
apnSelectionMode
OM
0x95
ENUMERATED
APN selection mode.
servedMSISDN
OM
0x96
AddressString(SIZE
(1..9))
MSISDN of a subscriber.
chargingCharacteristics
0x97
OCTET STRING
(SIZE(2))
Charging characteristics used for

an IP CAN bearer.
chChSelectionMode
OM
0x98
ENUMERATED
Charging characteristics selection

mode.
iMSsignalingContext
OC
0x99
NULL
IP CAN bearer used for IMS

signaling when the signaling flag
of the IM-CN subsystem is set to 1.
externalChargingID
OC
0x9A
OCTET STRING
Charging ID received from a

non-EPC external network entity,
such as ICID.
servingNodePLMNIdenti
fier
OM
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
OC
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
OC
0x9D
TBCD-STRING
(SIZE (8))
Records the IMEISV of a mobile

device if this field is set.
rATType
OC
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.
Issue 01 (2014-2-21)

16
eLTE2.2
Field Name
Attribute
Tag
Value
Type
Description
mSTimeZone
OC
0x9F1F
OCTET STRING
(SIZE(2))
Current time zone of an MS if this

field is set.
userLocationInformation
OC
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
OC
0x9F21
OCTET STRING
A group of CAMEL information

related to the IP CAN bearer. This
field applies only to GPRS.
listOfServiceData
OM
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
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.
Issue 01 (2014-2-21)

17
eLTE2.2
Field Name
Attribute
Tag
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
OM
0x9F29
INTEGER
(0..4294967295)
PDN connection ID used to

identify different CDRs that belong
to the same PDN connection.
servedPDPPDNAddress
Ext
OC
0xBF2B
PDPAddress
IPv4 IP address assigned for an IP

CAN bearer or PDN connection
when the PDN type is IPv4v6.
dynamicAddressFlagExt
OC
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
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.
Issue 01 (2014-2-21)

18
eLTE2.2
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.
Issue 01 (2014-2-21)

19
eLTE2.2
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.
Issue 01 (2014-2-21)

20
eLTE2.2
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.
Issue 01 (2014-2-21)

21
eLTE2.2
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:
Issue 01 (2014-2-21)

22
eLTE2.2
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:
Issue 01 (2014-2-21)

23
eLTE2.2
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
eNodeB
UE
Uu
S1-U
Billing System
CG
eCNS
Ga
LTE Network
SGi
PDN Network
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
Issue 01 (2014-2-21)

24
eLTE2.2
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)
eNodeB
UE
Uu
eCNS
S1-U
LTE Network
eNodeB
UE
Uu
Billing System
CG
eCNS
S1-U
Ga
LTE Network
SGi
PDN Network
eNodeB
UE
Uu
eCNS
S1-U
LTE Network
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).
Issue 01 (2014-2-21)

25
eLTE2.2
Figure 2-5 Typical multi-CN networking (multiple CGs)

eNodeB
UE
Uu
eCNS
S1-U
CG
LTE Network
eNodeB
UE
Uu
Billing System
CG
eCNS
S1-U
Ga
LTE Network
SGi
PDN Network
eNodeB
UE
Uu
eCNS
S1-U
LTE Network
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.
Issue 01 (2014-2-21)

26
eLTE2.2
Figure 2-6 Multi-CN disaster tolerance networking

eNodeB
UE
Uu
eCNS
CG
S1-U
Ga
Billing System
SGi PDN Network
eNodeB
UE
Uu
CG
eCNS
S1-U
Ga
LTE Network
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
eNodeB
UE
Uu
eCNS
S1-U
CG
Ga
Billing System
LTE Network
SGi
eNodeB
UE
Uu
CG
eCNS
S1-U
PDN Network
Ga
LTE Network
Issue 01 (2014-2-21)

27
eLTE2.2
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.
Issue 01 (2014-2-21)

28
eLTE2.2
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.
Issue 01 (2014-2-21)

29
eLTE2.2
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.
Issue 01 (2014-2-21)

30
eLTE2.2
3 References
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)
Issue 01 (2014-2-21)

31
eLTE2.2
A Acronyms and Abbreviations
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
Issue 01 (2014-2-21)

32
eLTE2.2
A Acronyms and Abbreviations
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
Issue 01 (2014-2-21)

33

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.

Offline Charging Whitepaper

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2014. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

Huawei Proprietary and Confidential

About This Document

About This Document

Completed the draft.

Liu Shaofeng (employee ID:

Huawei Proprietary and Confidential

2 eLTE Offline Charging ............................................................................................................ 8

Huawei Proprietary and Confidential

Figure 1-1 shows the structure of the LTE charging system.

Huawei Proprietary and Confidential

1.2 Charging Modes

Based on whether charging is service-specific, charging modes are classified into

Huawei Proprietary and Confidential

Figure 1-2 Charging mode categories

1.3 Online Charging

RFC 3588 Diameter Base Protocol

3GPP TS 32.299 Telecommunication management; Charging

Huawei Proprietary and Confidential

1.4 Offline Charging

3GPP TS 32.240, Charging management; Charging architecture and

1.5 Charging Mode Comparison

Huawei Proprietary and Confidential

2 eLTE Offline Charging

2 eLTE Offline Charging

2.1.1 Network Architecture

Huawei Proprietary and Confidential

2 eLTE Offline Charging

Table 2-1 describes functions of offline charging NEs.

Collects charging data, including duration and volume, generates

Stores, consolidates, and standardizes CDRs sent from the eCNS600,

Table 2-2 describes interfaces between offline charging NEs.

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

Huawei Proprietary and Confidential

2 eLTE Offline Charging

2.1.2 Offline Charging CDRs

Indicates the PGW-CDR.

Indicates the PGW-CDR.

Control-plane IP address of the

Used to identify different IP CAN

List of control-plane IP addresses

APN network identity (NI).

PDN type, such as IPv4, IPv6, and

IP address assigned for an IP CAN

Indicates whether the IP address

List of charging condition changes

Huawei Proprietary and Confidential

2 eLTE Offline Charging

Opening time of a record.

Closure cause of a CDR.

Detailed cause of a connection

SN of certain CDRs displayed only

A series of CDR extension

SN for the generation of all CDR

APN selection mode.

Charging characteristics used for

Charging characteristics selection

IP CAN bearer used for IMS