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: [email protected]

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-GWS-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 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.

eLTE2.2




11


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 OM 0xB0 Diagnostics Detailed cause of a connection

release.

recordSequenceNumber C 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 M 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.

eLTE2.2




12


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.

cAMELChargingInformation

OC 0x9F21 OCTET STRING A group of CAMEL information

related to the IP CAN bearer. This

field applies only to GPRS.

eLTE2.2




13


Type Description

listOfServiceData OM 0xBF22 SEQUENCE OF

ChangeOfServiceConditions


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.

eLTE2.2




14


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)


Type Description

PGWRecord M 0xBF4F SET Indicates the PGW-CDR.

recordType M 0x80 INTEGER Indicates the PGW-CDR.

eLTE2.2




15


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 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

ChangeOfCharCondition


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 OM 0xB0 Diagnostics Detailed cause of a connection

release.

recSequenceNumList C 0xB1 SequenceList Accumulated list of SNs of certain P-GW CDRs.

eLTE2.2




16


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 M 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.

eLTE2.2




17


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

ChangeOfServiceConditions


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


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 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

Documents

huawei trademarks

huawei proprietary

document issue

elte offline charging

charging modes

online charging

huawei industrial base

lte charging system