Cisco Cisco Packet Data Gateway (PDG)
GTPP Accounting Overview
▀ Triggers for Generation of Charging Records
▄ GTPP Interface Administration and Reference, StarOS Release 17
44
Manual subscriber clearing
Abnormal Releases such as path failures
The following table lists the different values for the “CauseForRecordClosing” field depending on the different trigger
scenarios.
scenarios.
Table 14. Cause for Record Closing
Cause
Scenarios
Partial/Final
Value
Supported
normalRelease
IP-CAN bearer release or detach
Final
0
Yes
abnormalRelease
Any other abnormal release
Final
4
Yes
volumeLimit
Configured volume threshold has been exceeded
Partial
16
Yes
timeLimit
Configured interval has been reached
Partial
17
Yes
servingNodeChange
Serving node Address list overflow
Partial
18
Yes
maxChangeCondition
Limit for the LOTV containers was exceeded
Partial
19
Yes
managementIntervention
For example, using the command
gtpp interim now
Partial
20
Yes
RAT Change
Change of radio interface from (for example, EUTRAN to GSM to
UMTS)
UMTS)
Partial
22
No
mSTimeZoneChange
MS changes time zone
Partial
23
Yes
Important:
The spec 3GPP TS 32.251 mentions that a CDR must be generated whenever the PLMN-ID of the
serving node changes, but does not have a corresponding “cause for record closure” reason in 3GPP TS 32.298. In the
case when the MME changed during the call and the PLMN-ID has the same address, the MME is added to the “Serving
Node Address” list. If a “Serving Node Address” list overflow occurs, a partial CDR will be generated with "cause for
record closure" as “servingNodeChange”.
case when the MME changed during the call and the PLMN-ID has the same address, the MME is added to the “Serving
Node Address” list. If a “Serving Node Address” list overflow occurs, a partial CDR will be generated with "cause for
record closure" as “servingNodeChange”.
Important:
The unsupported triggers mentioned above will be supported when the functionality is available.
SGW-CDR Charging Information Addition
The “List of Traffic Volumes” attribute of the SGW-CDR consists of a set of containers which are added when specific
trigger conditions are met. They identify the volume count per QCI/ARP pair and are separated for uplink and downlink
traffic after encountering that trigger condition.
trigger conditions are met. They identify the volume count per QCI/ARP pair and are separated for uplink and downlink
traffic after encountering that trigger condition.
The following table identifies which conditions are supported to trigger SGW-CDR charging information addition.
Volume container identifies the uplink/downlink volume since the closure of the last container. The “Serving Node
Address” attribute of the SGW-CDR consists of a list of serving node (for example, MME) addresses. A new serving
node address is added to the list when MME changes.
Volume container identifies the uplink/downlink volume since the closure of the last container. The “Serving Node
Address” attribute of the SGW-CDR consists of a list of serving node (for example, MME) addresses. A new serving
node address is added to the list when MME changes.