5 PS domain charging principles and scenarios

32.2513GPPCharging managementPacket Switched (PS) domain chargingRelease 17Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 PS charging principles

5.1.0 General

The charging functions specified for the PS domain relate to:

– mobility management, refer to TS 23.060 [201];

– SMS transmissions / receptions, refer to TS 23.060 [201] , and TS 23.272 [213];

– IP-CAN bearers, refer to TS 23.060 [201], TS 23.401 [208] and TS 23.402 [209];

– LCS events, refer to TS 32.271 [31];

– service data flows, refer to TS 23.203 [215] , within IP-CAN session and IP-CAN bearer;

– TDF session, refer to TS 23.203 [215];

– network usage for specific applications within a TDF session, refer to TS 23.203 [215] ;

– MBMS bearer contexts, refer to TS 23.246 [207] and TS 32.273 [33].

IP-CAN bearer, when described for PS Charging in S-GW and P-GW, refers to bearer related to IP data and Non-IP data as well.

5.1.1 Requirements

The following are high-level charging requirements specific to the packet domain, derived from the requirements in TS 22.115 [101], TS 23.060 [201], TS 23.401 [208], TS 23.402 [209] and TS 23.203 [215].

1) Every IP-CAN bearer shall be assigned a unique identity number for billing purposes. (i.e. the Charging Id).

NOTE: An IP-CAN session is identified by the unique identity number assigned to the default bearer for the
IP-CAN session.

2) Data volumes on both the uplink and downlink directions shall be counted separately. The data volumes shall reflect the data as delivered to and from the user. When the P-GW includes PCEF, the data volumes shall also reflect the data as delivered to and from the serving node at the bearer level.

3) The charging mechanisms shall provide the duration of the IP-CAN bearer with date and time information.

4) The network operator may define a subset of the charging information specified by PS domain charging standards. This means that it shall be possible to configure the PCN for the CDR information generated.

5) The PCNs shall be capable of handling the Charging Characteristics. Charging Characteristics can be specific for a subscription, subscribed IP-CAN bearer (i.e. per APN) or per TDF session, see annex A for details.

6) The SGSN shall support charging of CAMEL services.

7) The SGSN shall support charging for location requests.

8) The SGSN may support online charging using CAMEL techniques.

9) The P-GW may support online charging using IETF based techniques.

10) The P-GW may be capable of identifying data volumes, elapsed time or events for individual service data flows (Flow Based bearer Charging). One PCC rule identifies one service data flow.

11) When online charging is used in the P-GW/TDF, the Credit-Control shall be per rating group.

12) P-GW/TDF shall allow reporting of the service or detected application /detected application usage per rating group or per combination of the rating group and service id. This reporting level can be activated per PCC/ADC rule.

13) The P-GW shall collect charging information for IP -CAN session as it would for one IP-CAN bearer in case of PMIP based connectivity is used.

14) Charging support in the SGSN shall apply only for SGSN with Gn/Gp connectivity.

15) The data volume shall be counted regardless of whether the subscriber’s traffic has been offloaded from the mobile operator’s network.

Editor’s Notes: This requirement should be rerefined after finalization of the architecture for Selected IP Traffic Offload charging.

16) The TDF may support online charging using IETF techniques.

17) The TDF shall be capable of identifying data volumes, elapsed time or events for specific applications (ABC).

18) The charging mechanisms shall provide the duration of the TDF session with date and time information.

19) The P-GW/S-GW shall support charging for Non-IP PDN connection.

These requirements apply equally to PS domain online charging and offline charging.

5.1.2 Charging information

Charging information in the PS domain network is collected for each MS/UE by the SGSNs, MMEs, S-GWs, ePDG,
TWAG, P-GWs and TDFs, which are serving that MS/UE. The SGSN, S-GW, ePDG and TWAG collect charging information for each MS/UE related with the radio network usage, while the P-GW and TDF collect charging information for each MS related with the external data network usage. PCNs also collect charging information on usage of the PS domain network resources. For MBMS, charging information in the PS domain network is collected for each MBMS bearer context.
The following paragraphs list the charging information to be collected by the PCNs for both online and offline charging.

For IP-CAN bearers, the PCNs shall collect the following charging information:

1. usage of the radio interface: the charging information shall describe the amount of data transmitted in MO and MT directions categorized with QoS, user protocols, and use of Control Plane CIoT EPS Optimisation as specified in TS 23.401[208];

2. usage duration: duration of IP-CAN bearer is counted as the time interval from IP-CAN bearer activation to
IP-CAN bearer deactivation;

3. usage of the general PS domain resources: the charging information shall describe the usage of other PS domain-related resources and the MSs PS domain network activity (e.g. mobility management);

4. destination and source: the charging information shall provide the actual source addresses used by the subscriber for the IP-CAN bearer. The charging information shall describe the destination addresses with a level of accuracy as determined by the Access Point Name (APN);

5. usage of the external data networks: the charging information shall describe the amount of data sent and received to and from the external data network. External networks can be identified by the APN.

NOTE: When charging per IP-CAN session is deployed in the P-GW, the usage of the external data networks is provided only at the session level and not per bearer.

6. location of MS/UE: HPLMN, VPLMN, plus optional higher-accuracy location information.

7. User CSG information: a user consumes network services via a CSG cell or a hybrid cell according to the user CSG information. The charging information shall include CSG ID, access mode and CSG membership indication.

8. User inside/outside of a Presence Reporting Area: the charging information shall include indication on whether the UE is inside or outside of a Presence Reporting Area, and identification of the Presence Reporting Area, and is collected by SGW and PGW

For service data flows defined for FBC, the P-GW shall collect the following charging information:

1. the information described above for IP-CAN bearer charging;

2. the amount of data transmitted in MO and MT directions categorized by rating group or combination of the rating group and service id when volume based charging applies;

3. the duration of service data flows is counted and categorized by rating group or combination of the rating group and service id when time based charging applies;

4. the number of events and corresponding time stamps categorized by rating group or combination of the rating group and service id when event based charging applies.

For TDF sessions, the TDF shall collect the following charging information:

1. usage duration: duration of TDF sesion is counted as the time interval from TDF session activation to TDF session deactivation;

2. usage of the general PS domain resources: the charging information shall describe the usage of other PS domain-related resources and the MSs PS domain network activity (e.g. mobility management);

3. destination and source: the charging information shall provide the actual source addresses used by the subscriber for the TDF session. The charging information shall describe the destination addresses with a level of accuracy as determined by the APN;

4. usage of the external data networks: the charging information shall describe the amount of data sent and received to and from the external data network. External networks can be identified by the APN.

5. location of MS/UE: HPLMN, VPLMN, plus optional higher-accuracy location information.

6. User CSG information: a user consumes network services via a CSG cell or a hybrid cell according to the user CSG information. The charging information shall include CSG ID, access mode and CSG membership indication.

7. voidFor application traffic defined for ABC, the TDF shall collect the following charging information:

1. the information described above for TDF session charging;

2. the amount of data transmitted as specific application in MO and MT directions categorized by rating group or combination of the rating group and service identifier when volume based charging applies;

3. the duration of application traffic is counted and categorized by rating group or combination of the rating group and service identifier when time based charging applies;

4. the number of events and corresponding timestamps categorized by rating group or combination of the rating group and service identifier when event based charging applies.

For non-IP-CAN bearer related activities, the SGSN shall collect the following charging information:

1. mobility management actions for GPRS attached UEs/MSs;

2. short messages passing through the SGSN in MO and MT directions;

3. location requests passing through the SGSN, triggered by the UE/MS, by an external source, or by the network.

For MBMS bearer contexts, the PCNs shall collect the following charging information:

1. usage of the radio interface: the charging information shall describe the amount of data transmitted categorized with QoS and MBMS specific information defined in TS 32.273 [33];

2. usage duration: duration of MBMS bearer context is counted as the time interval from the local creation of the MBMS bearer context to the local deletion of the MBMS bearer context;

3. source: the charging information shall provide the source address used by the MBMS bearer service for the MBMS bearer context. The charging information may describe the destination addresses with a level of accuracy as determined by the APN;

4. location information: the charging information shall describe a list of the downstream nodes being sent the MBMS bearer service.

The MME shall collect short messages passing through the MME in MO and MT directions.

5.1.3 Identifiers and correlation

The EPC charging identifier assigned per IP-CAN bearer, is used for correlation purpose within PS domain, as specified in TS 32.240 [1].

Within a single-access PDN connection, the EPS default bearer remains established throughout the lifetime of this PDN connection and is assigned with its "EPS default bearer charging identifier". Other additional IP-CAN bearers (i.e. dedicated bearers) which may be activated and deactivated during this PDN connection, are each assigned with their own "IP-CAN bearer charging identifier". For correlation of charging information for the whole PDN connection, this "EPS default bearer charging identifier" is shared by all these IP-CAN bearers charging sessions activated during this PDN connection, as the "PDN connection charging identifier".

For PMIP based connectivity, an "unique Charging Id" is assigned by the P-GW for the PDN connection (i.e. as it would be one IP-CAN bearer).

For ABC by the TDF:

– in case of GTP based connectivity, an "EPS default bearer charging identifier",

– in case of PMIP based connectivity, an "unique Charging Id"

is assigned by the P-GW and transferred to the TDF via the PCRF for the TDF session.

During handover of a PDN connection between a GTP based connectivity access, and a PMIP based connectivity access for the P-GW (and reversely), the "EPS default bearer charging identifier" and the "unique Charging Id" respectively, are maintained in order to ensure charging continuity for the whole PDN connection over the different accesses.
Upon handover from GTP based connectivity to PMIP based connectivity, the previously assigned "EPS default bearer charging identifier" is used as the "unique Charging Id". Upon handover from PMIP based connectivity to GTP based connectivity, the previously assigned "unique Charging Id" is used as the "EPS default bearer charging identifier".

During handover of a PDN connection between a GTP based connectivity 3GPP access, and a S2a/S2b GTP based connectivity non-3GPP access for the P-GW (and reversely), the "EPS default bearer charging identifier" is maintained for the default bearer, and the "Charging Id" is maintained for the handed-over dedicated bearers (i.e. bearer with the same QCI and ARP in source and target systems). Depending on the active PCC rules, establishment of new dedicated bearers may be required after the handover. In this case each new dedicated bearer is assigned with a new "Charging Id" as per normal procedures.

When multiple simultaneous PDN connections are established for a given APN, each PDN connection is associated with its own "PDN connection charging identifier" or "unique Charging Id" and processed independently from the other PDN connections.

When a "MAPCON capable UE", as defined in TS 23.402 [209], has simultaneous PDN connections through different access networks, each PDN connection is associated with its own "PDN connection charging identifier" or "unique charging Id" over the selected access for the PDN connection.When selective transfer of PDN connections between the different accesses is performed, each PDN connection is transferred, as for a single PDN connection.

When an "IFOM capable UE", as defined in TS 23.402 [209], is simultaneously connected to 3GPP access and WLAN access for different IP flows within the same PDN connection, each service data flow is uniquely identified by a PCC Rule within the PDN connection.

For a PDN connection with NBIFOM support, a "PDN connection charging identifier" is assigned for the PDN connection and is shared by all the IP-CAN bearers for the present as well as for any future accesses used during the PDN connection. Additional IP-CAN bearers (i.e. dedicated bearers as well as any additional default bearer in a new access) which may be activated during this PDN connection, are each assigned with their own "IP-CAN bearer charging identifier."

The "PDN connection charging identifier" shall remain unchanged and be used by all serving nodes for the entire IP-CAN session. When a serving node is changed, e.g. when UE moves PDN connection between LTE and WLAN or when serving gateway relocation is performed, the individual bearer charging identifiers shall be maintained as for a single-access PDN connection.

When SIPTO function applies, as defined in TS 23.060 [201] and TS 23.401 [208] the standard charging behaviour for PDN connection activation/deactivation applies on the respective GW.

For inter-level correlation when charging per IP-CAN session is not active, the charging identifier assigned to the specific bearer serves as the PS domain access network charging identifier used for a dynamic PCC rule. For inter-level correlation when Charging per IP-CAN session is active, the charging identifier assigned to the PDN connection serves as the PS domain access network charging identifier used for a dynamic PCC rule. Transport of PS domain access network charging identifier to an external application function are specified in TS 29.212 [216].

With NBIFOM, specific service data flows can be moved from one access to another. The transfer of the service data flow to the other access causes it to be bound to another bearer (either existing or to be created). When Charging per IP-CAN session is not active, the flow is then using a bearer with a charging identifier which would be different than that originally notified to the application function for inter-level correlation. To maintain a single access network charging identifier for inter-level correlation, when NBIFOM is accepted for a PDN connection, then the charging identifier assigned to the PDN connection serves as the PS domain access network charging identifier used for a dynamic PCC rule.

NOTE: When Charging per IP-CAN session is active the "PDN connection charging identifier" remains unchanged so the information provided to the application function remains unchanged throughout the IP-CAN session.

For non-IP data, the PDN connection established with an unique IP-CAN bearer as specified in TS 23.401 [208], is assigned with an "unique Charging Id" by the P-GW.

5.1.4 UE presence in Presence Reporting Area (PRA)

5.1.4.1 Single Presence Reporting Area (PRA)

The Single Presence Reporting Area is not supported.

Non-support of single Presence Reporting Area is determined by the release included in Service-Context-Id AVP.

5.1.4.2 Multiple Presence Reporting Areas (PRAs)

UE presence in multiple presence reporting area (s) charging information, as defined in TS 23.401 [208] and TS 23.203 [215], is collected for each UE by S-GWs, P-GWs which are serving that UE.

During IP-CAN session establishment/modification, and independently from the PCRF, the OCS may provide to the P-GW, a list of:

– Presence Reporting Area (PRA) Identifiers to be activated for Core Network pre-configured Presence Reporting Areas,

– Presence Reporting Area (PRA) Identifiers and their elements for UE-dedicated Presence Reporting Areas.

By providing the corresponding above lists in Presence-Reporting-Area-Information AVP(s), the OCS subscribes to the notifications of change of UE presence status in the PRA(s) through the Trigger-Type AVP. UE presence status in the PRA(s) describes whether the UE is entering or leaving Presence Reporting Area (s) and if the corresponding Presence Reporting Area(s) is set to inactive by the serving node.

The OCS may change the notifications of whether the UE is entering or leaving Presence Reporting Area (s) through Trigger-Type AVP in a CCA, with the Presence-Reporting-Area-Information AVP(s) to replace previous provided list.

The OCS may unsubscribe to the change of UE presence in Presence Reporting Area through Trigger-Type AVP in a CCA without the value of CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA_REPORT (73), if it has been provided in the previous CCA.

The UE presence initial status in the PRA(s) at the time of the subscription shall be reported by the P-GW to the OCS for online charging in Debit / Reserve Units Request[Update] when the subscription is activated. The UE presence initial status in the PRA(s) at the time of the subscription shall be reported by the S-GW and P-GW for offline charging in Charging Data Request[Start] / [Interim] when the subscription is activated. Subsequently, whether the UE enters or leaves the PRA(s), shall be reported by the P-GW to the OCS for online charging, and by the S-GW and P-GW for offline charging.

When a PRA set i.e. PRA Identifier was subscribed to, the SGW/PGW additionally receives the PRA Identifier of the PRA set from the serving node, along with the individual PRA Identifier(s) belonging to the PRA set and indication(s) of whether the UE is inside or outside the individual Presence Reporting Area(s) , as described in TS 23.401[208]. Only the individual PRA Identifier(s) belonging to the PRA set and UE presence status(es) are reported to the OCS according to the corresponding subscription.

For offline charging, the initial status of UE presence in the PRA(s) shall be captured in current counts and reported on first charging event. For online charging, this initial status shall be reported when received by the PCEF if quota have already been requested for the service usage, otherwise this initial status shall be reported on the first quota request.

For PRA(s) subscribed-to by the OCS, the PRA(s) and their UE presence status(es) which are reported to OCS are captured in offline charging from P-GW, with an indication for each PRA, the PRA was subscribed-to by OCS.

For PRA(s) subscribed-to by the PCRF, the PRA(s) and their UE presence status(es) which are reported to PCRF are captured in offline charging from P-GW, with an indication for each PRA, the PRA was subscribed-to by PCRF.

In the S-GW the PRA(s) and their UE presence status(es) are captured in offline charging without any differentiation between OCS and PCRF subscription, since the S-GW is unaware about this difference.

5.1.5 3GPP PS Data Off

When 3GPP PS Data off is activated by the user, PGW prevents downlink traffic except for 3GPP PS Data Off Exempt Services. The 3GPP PS Data Off Exempt Services are a set of operator services, defined in TS 22.011 [102]. And if 3GPP PS Data Off is activated, the UE prevents the sending of uplink IP packets except those related to 3GPP PS Data Off Exempt Services, based on the pre-configured list of Data Off Exempt Services.

The UE reports its 3GPP PS Data Off status in PCO (Protocol Configuration Option) to PGW during Initial Attach procedure and report a change of its 3GPP PS Data Off status in PCO by using Bearer Resource Modification procedure, described in TS 23.401 [208]. The 3GPP PS Data Off status is sent transparently through the MME and the Serving GW from UE to PGW. If the PGW detects that the 3GPP PS Data Off Status has changed, the PGW shall indicate this event to the charging system for offline and online charging.

5.1.6 Flexible Mobile Service Steering

The PGW/PCEF/TDF shall send the Traffic Steering Policy Identifier which has been used by the PGW/PCEF/TDF for sending the service data flow to a specific set of service functions(based on the PCC rule), to the offline charging system for information.

5.2 PS domain offline charging scenarios

5.2.1 Basic principles

5.2.1.0 General

In order to provide the data required for the management activities outlined in TS 32.240 [1] (billing, accounting, statistics etc.), the SGSN shall be able to produce CDRs, and the MME, S-GW, ePDG, TWAG, P-GW and TDF shall be able to produce CDRs or report charging events for CDRs generation by CDF, as specified for each node type in the following:

– Charging data related to IP-CAN bearers in the SGSN (S-CDR), S-GW (SGW-CDR), ePDG (ePDG-CDR) , TWAG (TWAG-CDR) and P-GW (PGW-CDR);

– Charging data related to service data flows in the P-GW (PGW-CDR);

– Charging data related to MM contexts (Mobile Station Mobility Management Data) in SGSN (M-CDR);

– SMS Mobile Originated data (S-SMO-CDR) and SMS Mobile Terminated Data (SMS-SMT-CDR) in the SGSN;

– Charging data related to mobile originated location requests (LCS-MO-CDR), mobile terminated location request (LCS-MT-CDR), and network induced location request (LCS-NI-CDR) passing through the SGSN;

– Charging data related to MBMS bearer contexts (S-MB-CDR, G-MB-CDR, and MBMS-GW-CDR).

– SMS Mobile Originated data (S-SMO-CDR) and SMS Mobile Terminated Data (S-SMT-CDR) in the MME;

– Charging data related to TDF session (TDF-CDR) in the TDF;

– Charging data related to application traffic in the TDF (TDF-CDR).

The contents and purpose of each of these CDRs, as well as the chargeable events that trigger CDR creation, information addition, or closure are described in the following clauses. A detailed formal description of the CDR parameters defined in the present document is to be found in TS 32.298 [51].

When the CDF is implemented as a separate entity (for the MME, S-GW, ePDG, TWAG, P-GW and TDF), the charging events triggering and contents for CDRs handling by the CDF, are described in clause 5.2.2.

5.2.1.1 IP-CAN bearer charging

SGSN, ePDG, TWAG, P-GW, and S-GW collect charging information per user per IP-CAN bearer. In case of P-GW is not aware of IP-CAN bearers, i.e. in case of PMIP based connectivity, P-GW collects charging information per IP-CAN session as it would be one IP-CAN bearer. IP-CAN bearer charging allows the PCNs to collect charging information related to data volumes sent to and received by the UE/MS, categorised by the QCI and ARP applied to the IP-CAN bearer. The user can be identified by MSISDN and/or IMSI, while the IP-CAN bearer can be determined by a unique identifier generated by the P-GW when creating a IP-CAN bearer. This identifier is also forwarded to the S-GW/ ePDG/ TWAG/SGSN so as to allow correlation of S-GW/ ePDG/ TWAG/SGSN IP-CAN bearer CDRs with the matching P-GW CDRs in the BD.

NOTE1: The control plane IP address of SGSN or P-GW(acting as GGSN) is the IP address used at Gn/Gp interface.

The control plane IP address of S-GW or P-GW is the IP address used at S5/S8 interface.

The control plane IP address of ePDG or P-GW is the IP address used at S2b interface.

The control plane IP address of TWAG or P-GW is the IP address used at S2a interface.

IP-CAN bearer specific offline charging in P-GW, is achieved by FBC offline charging, with specific rating group/service identifier, see clause 5.2.1.3.

The main collected information items are duration of the IP-CAN bearer and data volume transferred during the lifetime of the IP-CAN bearer. The following chargeable events are defined for SGSN, S-GW, ePDG and TWAG IP-CAN bearer charging:

– Start of IP-CAN bearer. Upon encountering this event, a new CDR for this IP-CAN bearer is created and the data volume is captured for the IP-CAN bearer.

– Access of a multi-access PDN connection becomes unusable: when this event is encountered, the current volume count is captured for the IP-CAN bearer of the unusable access.

– Access of a multi-access PDN connection becomes usable: when this event is encountered, new volume counts are started for the IP-CAN bearer of the access that has become usable.

– End of IP-CAN bearer in the SGSN/S-GW/ePDG/TWAG. The CDR is closed upon encountering this trigger.

– Tracking Area Update of:

– Inter-SGSN/inter S-GW. The IP-CAN bearer CDR is closed in SGSN/S-GW upon encountering this trigger.

– Inter-MME. In S-GW a new MME address is added to CDR upon encountering this trigger.

– S4-SGSN to MME. In S-GW a new MME address is added to CDR upon encountering this trigger.

– MME to S4-SGSN. In S-GW a new S4-SGSN address is added to CDR upon encountering this trigger.

– Intersystem change (e.g. change of radio interface from GSM to UMTS or vice versa). This event closes the CDR. A new one is opened if the IP-CAN bearer is still active.

– PLMN change visible in the P-GW. This event closes the CDR. A new one is opened if the IP-CAN bearer is still active.

– MS Timezone change visible in the P-GW. This event closes the CDR. A new one is opened if the IP-CAN bearer is still active.

– Expiry of an operator configured time limit per IP-CAN bearer. This event closes the CDR, and a new one is opened if the IP-CAN bearer is still active.

– Expiry of an operator configured data volume limit per IP-CAN bearer. This event closes the CDR, and a new one is opened if the IP-CAN bearer is still active.

– Change of charging condition in the SGSN: e.g. QoS change, tariff time change, user CSG information change or direct tunnel establishment/removal. When this event is encountered, the current volume count is captured and a new volume count is started.

– Change of charging condition in the S-GW: e.g. QoS change, tariff time change, user location change, user CSG information change, change of UE presence in Presence Reporting Area(s), change in User Plane to UE, Serving PLMN Rate Control change. When this event is encountered, the current volume counts are captured and a new volume counts are started.

– MO exception data counter receipt in the S-GW: This event closes the CDR. A new one is opened if the IP-CAN bearer is still active.

– Change of charging condition in the ePDG: e.g. QoS change, tariff time change. When this event is encountered, the current volume counts are captured and a new volume counts are started.

– Change of charging condition in the TWAG: e.g. QoS change, tariff time change. When this event is encountered, the current volume counts are captured and a new volume counts are started.

– Expiry of an operator configured change of charging condition limit per IP-CAN bearer. This event closes the CDR, and a new one is opened if the IP-CAN bearer is still active.

– Management intervention may also force trigger a chargeable event.

When the CDF is implemented as a separate entity, all these chargeable events defined for IP-CAN bearer, trigger charging events reporting, for CDRs (S-GW, ePDG, TWAG and P-GW CDRs) to be constructed, enriched or closed by CDF, according to description in clause 5.2.2.

NOTE 2: For non-IP type PDN connection in the S-GW:

– Access of a multi-access PDN connection does not apply;

– Mobility occurs between MMEs.

5.2.1.2 MM context charging

The SGSN collects charging information for mobility management actions per attached UE/MS, i.e. per user. The user can be identified by MSISDN and/or IMSI. There can be only one MM context per UE/MS at a time, and only the SGSN is involved. Therefore there is no need for special MM context identifiers. The main information items collected are changes of location pertaining to the UE/MS. The following chargeable events are defined for MM context charging:

– Start of MM context (UE/MS attaches to a SGSN). A new M-CDR is created upon encountering this event.

– End of MM context: explicit or implicit GPRS detach, including SGSN change (inter-SGSN routing area update including intersystem change). This event triggers the closure of the M-CDR.

– Mobility Change, i.e. a change in the Routing Area. The new location information is captured for the M-CDR.

– Expiry of an operator configured time limit. This event triggers the closure of the M-CDR.

– Expiry of an operator configured mobility change limit. This event triggers the closure of the M-CDR.

– Intra-SGSN intersystem change (change of radio interface from GSM to UMTS or vice versa). This event triggers the closure of the M-CDR.

Management intervention may also force trigger a chargeable event.

5.2.1.3 Flow Based bearer Charging (FBC)

IP-CAN bearer charging allows the P-GW to collect charging information related to data volumes sent to and received by the UE/MS, categorised by the QoS applied to the IP-CAN bearer. FBC is supported by the P-GW by the integration of a PCEF. With PCEF, the normal IP-CAN bearer charging is enhanced by the capability to categorise the service data flows within IP-CAN bearer data traffic by rating group or combination of the rating group and service id, i.e., while there is only one uplink an one downlink data volume count per IP-CAN bearer in IP-CAN bearer charging, FBC provides one count per each rating group or combination of the rating group and service id. In case that sponsored connectivity level reporting is active, FBC categorise within IP-CAN bearer data traffic by combination of rating group, sponsor identity and application service provider identity. The level of the reporting is defined per PCC rule. Details of this functionality are specified in TS 23.203 [215] and TS 32.240 [1].

NOTE: The P-GW can only include one QoS Information occurrence per service data container. This implies if an operator wishes to be able to separate usage according to QCI and ARP within their billing system they will need to ensure that services having different QCI and ARP do not have the same:

– rating group in cases where rating reporting is used;

– rating group/service id where rating group/service id reporting is used;

– rating group/sponsor identity/application service provider identity where sponsored connectivity level reporting charging is used.

IP-CAN bearer specific offline charging is achieved with IP-CAN bearer specific rating group/service identifier defined in clause 5.3.1.1.

According to TS 23.203 [215], FBC shall support different charging models per PCC rule. These charging models may be based on volume and/or time and on number of events matching a specific service data flow template in PCC rule.
In general the charging of a service data flow shall be linked to the IP-CAN bearer under which the service data flow has been activated. The following chargeable events are defined for FBC:

– Start of IP-CAN bearer. Upon encountering this event, a new PGW-CDR for this context is created.

– Start of service data flow. If service identifier level reporting is required by the PCC rule new counts and time stamps for this combination of the rating group and service id are started. If rating group level reporting is required by the PCC rule needed new counts and time stamps for this rating group are started. If sponsored connectivity level reporting is required by the PCC rule needed new counts and time stamps for this rating group, sponsor identity and application service provider identity are started. The type of counters shall depend on the measurement method configured for the PCC rule. When event based charging applies, the first occurrence of an event matching a service data flow template in PCC rule shall imply that a new count is started. When new events occur, the counter shall be increased. Each event shall be time stamped.

– Termination of service data flow. If service identifier level reporting is required by the PCC rule and this was the last active service data flow for this combination of the rating group and service id or if rating group level reporting is required by the PCC rule and this was the last active service data flow for this rating group, or if sponsored connectivity level reporting is required by the PCC rule and this was the last active service data flow for this combination of rating group, sponsor identity and application service provider identity, the counters and time stamps are closed and added to the PGW-CDR. For information on how the termination of service data flows is detected, refer to TS 23.203 [72].

– Access of a multi-access PDN connection becomes unusable: the Termination of service data flow chargeable event applies for all the service data flows carried under the IP-CAN bearer of the unusable access.

– Access of a multi-access PDN connection becomes usable: the Start of service data flow chargeable event applies for all the service data flows carried under the IP-CAN bearer of the access that has become usable.

– End of IP-CAN bearer in the P-GW. The PGW-CDR is closed upon encountering this trigger.

– Serving node (e.g. SGSN/S-GW/ePDG/TWAG) change in the P-GW. New SGSN/S-GW/ePDG/TWAG address is added to PGW-CDR.

– Expiry of an operator configured time limit per IP-CAN bearer. This event closes the PGW-CDR, and a new one is opened if the IP-CAN bearer is still active.

– Expiry of an operator configured time limit per rating group. The counters and time stamps are closed and added to the PGW-CDR. A new service data flow container is opened if any matching service data flow is still active.

– Expiry of an operator configured data volume limit per IP-CAN bearer. This event closes the PGW-CDR, and a new one is opened if the IP-CAN bearer is still active.

– Expiry of an operator configured data volume limit per rating group. The counters and time stamps are closed and added to the PGW-CDR. A new service data flow container is opened if any matching service data flow is still active.

– Expiry of an operator configured data event limit per rating group. The counters and time stamps are closed and added to the PGW-CDR. A new service data flow container is opened if any matching service data flow is still active.

– Change of charging condition: IP-CAN bearer modification (e.g. QoS change, SGSN change, S-GW change, user location change,user CSG information change, change of UE presence in Presence Reporting Area(s), change of 3GPP PS Data Off status, Serving PLMN Rate Control change, APN Rate Control change), tariff time change or failure handling procedure triggering. When this event is encountered, all current configured counts and time stamps are captured and new counts and time stamps for all active service data flows are started.

– Intersystem change (e.g. change of radio interface from GSM to UMTS, RAT change) visible in the P-GW. This event closes the PGW-CDR, and a new one is opened if the IP-CAN bearer is still active.

– PLMN change visible in the P-GW. This event closes the PGW-CDR. A new one is opened if the IP-CAN bearer is still active.

– MS Timezone change visible in the P-GW. This event closes the PGW-CDR. A new one is opened if the IP-CAN bearer is still active.

– MO exception data counter receipt in the P-GW: This event closes the CDR. A new one is opened if the IP-CAN bearer is still active.

– SGSN change in the P-GW. New SGSN address is added to PGW-CDR.

– Expiry of an operator configured report of service flow data limit per IP-CAN bearer. This event closes the PGW-CDR, and a new one is opened if the IP-CAN bearer is still active.

– Completion of a time envelope as defined in TS 32.299 [50]. This event closes a service data flow container. Further details are described in clause 5.2.3.4.1 "Triggers for PGW-CDR Charging Information Addition"’. The need for reporting time envelopes may be statically configured for each rating group or dynamically controlled by online charging.

Management intervention may also force trigger a chargeable event.

Relevant service data flows for a certain IP-CAN bearer are determined when FBC is applied. PCC rules are used for this determination. One PCC rule identifies service data flow to be measured but it can also include certain characteristics related to that service data flow.

PCC rules can be activated, deactivated and modified any time during the IP-CAN bearer lifetime. PCC rule activation, deactivation and modification are not chargeable events. However these PCC rule changes may lead to "start of service data flow" and "termination of service data flow" chargeable events.

A PCC rule can contain e.g.:

– service data flow template (service data flow filters or application identifier) to identify packets belonging to certain service data flow,

– charging method to identify whether online/offline/both/neither charging interface is used,

– measurement method for offline charging to identify whether time/volume/events are measured for this service data flow,

– Charging key (i.e. rating group) for that service data flow,

– service identifier for that service data flow,

– Sponsor Identifier (offline charging only),

– Application Service Provider Identifier (offline charging only),

– application function record information to correlate the measurement with application level reports,

– reporting level for the service data flow (rating group, combination of the rating group and service id or combination of the rating group, sponsor identity and application service provider identity),

– precedence to the situations where two or more PCC rules are overlapping,

– allowed access type (for NBIFOM control) See clause 5.2.1.7A..

PCC rules can be:

– pre-defined in P-GW (can be activated either by the PCRF or PCEF itself) or,

– dynamically provisioned and activated by the PCRF over the Gx interface.

This is specified in TS 23.203 [215] and TS 29.212 [216].

According to TS 23.203 [215] , the PCRF can modify the following charging information in a dynamic PCC rule which is active in the PCEF: Charging key, Service identifier, Sponsor Identifier, Application Service Provider Identifier, Measurement method, and reporting level The PCRF can also modify the allowed access type in the case of NBIFOM.. A change of any of this charging or allowed access type information will trigger a "start of service data flow" chargeable event when a valid counter does not exist corresponding to that changed PCC rule. A change of any of this charging or allowed access type information will trigger a "termination of service data flow" chargeable event when this was the last active service data flow for the counter corresponding to the original PCC rule.

When the CDF is implemented as a separate entity, all these FBC related chargeable events, trigger charging events reporting, for P-GW CDRs to be constructed, enriched or closed by CDF, according to description in clause 5.2.2.

Extended packet inspection can be done in the PCEF with pre-defined PCC rules. The PCEF also have the possibility to output service specific information related to the packet inspection in the CDR.

The capability of P-GW to support ABC is achieved with PCRF providing appropriate PCC rules to the P-GW. Such PCC Rule shall be defined with service data flow template including an Application Identifier for the application which needs to be detected, enforced and charged.

For non-IP type PDN connection in the P-GW:

– non-3GPP access types are not supported, a multi-access PDN connections do not apply;

– A single PCC Rule is used with the service data flow descriptor matching the whole non-IP data traffic, and can contain e.g.:

– service data flow template matching all the packets;

– charging method to identify whether online/offline/both/neither charging interface is used;

– measurement method for offline charging to identify whether time/data volume/events are measured for this service data flow;

– Charging key (i.e. rating group) for that service data flow;

– service identifier for that service data flow;

– reporting level for that service data flow:

– rating group level in case a specific rating group is used for non-IP traffic charging;

– combination of the rating group and service id in case a specific rating group/service Id is used for non-IP traffic charging.

5.2.1.4 SMS charging

The SGSN and the MME collect charging information for each Short Message sent to, or received by, a MS/UE.
There are two chargeable events for SMS charging in the SGSN and MME:

– the transfer of a SM through the SGSN and MME in MO direction;

– the transfer of a SM through the SGSN and MME in MT direction.

Management intervention may also force trigger a chargeable event.

5.2.1.5 LCS charging

The SGSN collects charging information for each Location Request for a MS/UE.
The following chargeable events are specified for LCS:

– A location request for a MS/UE triggered by that MS/UE (LCS-MO);

– A location request for a MS/UE triggered by an external entity (LCS-MT);

– A location request for a MS/UE triggered by the network (LCS-NI).

Management intervention may also force trigger a chargeable event.

5.2.1.6 MBMS context charging for GPRS

The SGSN and GGSN collects charging information for each MBMS bearer service activated.
The following chargeable events are specified for MBMS:

– Start of MBMS bearer context. Upon encountering this event, a new CDR for this MBMS bearer context is created and the data volume is captured for the MBMS bearer context.

– End of MBMS bearer context in the SGSN/GGSN. For the SGSN only, this trigger includes inter-SGSN routing area update (e.g. the last UE using the MBMS bearer context leaves the routeing area).
The MBMS bearer context CDR is closed upon encountering this trigger.

– Expiry of an operator configured time limit per MBMS bearer context. This event closes the MBMS bearer context CDR, and a new one is opened if the MBMS bearer context is still active.

– Expiry of an operator configured data volume limit per MBMS bearer context. This event closes the MBMS bearer context CDR, and a new one is opened if the MBMS bearer context is still active.

– Change of charging condition: tariff time change. When this event is encountered, the current volume count is captured and a new volume count is started.

– Expiry of an operator configured change of charging condition limit per MBMS bearer context. This event closes the MBMS bearer context CDR, and a new one is opened if the MBMS bearer context is still active.

Management intervention may also force trigger a chargeable event.

5.2.1.6A MBMS context charging for EPS

In EPS, MBMS GW is the function entity which may be stand alone or co-located with other network elements such as BM-SC or combined S-GW/PDN-GW. The MBMS GW collects charging information for each MBMS bearer service activated. The following chargeable events are specified for MBMS:

– Start of MBMS bearer context. Upon encountering this event, a new CDR for this MBMS bearer context is created and the data volume is captured for the MBMS bearer context.

– End of MBMS bearer context in the MBMS GW.

– Expiry of an operator configured time limit per MBMS bearer context. This event closes the MBMS bearer context CDR, and a new one is opened if the MBMS bearer context is still active.

– Expiry of an operator configured data volume limit per MBMS bearer context. This event closes the MBMS bearer context CDR, and a new one is opened if the MBMS bearer context is still active.

– Change of charging condition: tariff time change. When this event is encountered, the current volume count is captured and a new volume count is started.

Management intervention may also force trigger a chargeable event.

The MBMS control plane function is supported by MME for E-UTRAN access and by SGSN for UTRAN access.

5.2.1.7 IP Flow Mobility (IFOM) charging

An "IFOM capable UE", as defined in TS 23.402 [209], may be simultaneously connected to 3GPP access and WLAN access for different IP flows within the same PDN connection, as described in TS 23.261 [212].
In the P-GW, FBC (as described in clause 5.2.1.3) applies to the corresponding service data flows, carried by appropriate IP-CAN bearer(s) activated for both accesses.

For a PDN connection, charging for each service data flow, is performed within the IP-CAN bearer charging session of the IP-CAN bearer it belongs to, according to its associated PCC Rule.

As described in TS 23.261 [212], the UE may also move one or more IP flow(s) from 3GPP access to WLAN access (and reversely). The transfer of the corresponding service data flow(s) from one access to the other access, results in PCC Rule(s) removed from the IP-CAN bearer(s) of the source access, leading to termination of service data flow", and PCC Rule(s) installed into the IP-CAN bearer(s) of the target access.

For each service data flow, identified by its PCC Rule, this PCC Rule may be provided with a different description depending on the access type where it has to be enforced. In particular, the rating group may differ, as a way to apply charging differentiation per-access type. The charging method, measurement method, reporting level may also potentially be different, in case charging behaviour is not expected to be unified between both domains.

In order to ensure the accurate level of granularity of service data flows charging, the associated PCC Rule shall be defined with the service identifier level reporting.

For the case where dynamic PCC is not deployed, per-access Charging Characteristics and pre-defined PCC Rule(s) in
P-GW may be used as a way to apply charging differentiation.

5.2.1.7A Network-Based IP Flow Mobility (NBIFOM) charging

To support Network-Based IP Flow Mobility (NBIFOM), multi-radio (i.e. 3GPP and WLAN) capable UEs establish and maintain a PDN connection over both 3GPP access and WLAN access simultaneously for both S2b and S2a connectivity, as specified in TS 23.161 [242]. When such a multi-access PDN connection is established, there is one default bearer for each access. On a multi-access PDN connection established over both 3GPP access and WLAN access, it is possible to move individual IP flows from one access network to another, when policies determine that flows should be moved and the target access is available for the UE. As described in TS 23.203 [215], it shall be possible to apply different rates depending on the access used to carry a service data flow.

For a multi-access PDN connection, IP-CAN bearer charging as defined in clause 5.2.1.1 and FBC as defined in clause 5.2.1.3 apply for each bearer under each access for this PDN connection, and IP-CAN bearer charging as defined in clauses 5.2.1.10.1 and FBC as defined in clauses 5.2.1.10.2 apply when charging per IP-CAN session is active for this PDN connection, based on:

– Establishment of a multi-access PDN connection and addition of access to a multi-access PDN connection result in the default bearer and potential dedicated bearer(s) creation for this access, to carry the service data flows based on PCC Rule(s).

– Release of a multi-access PDN connection and removal of an access from a multi-access PDN connection result in release of all the IP-CAN bearer(s) for this access.

– Access change for service data flow(s), results in corresponding PCC Rule(s) removed from the IP-CAN bearer(s) of the source access, and PCC Rule(s) installed into the IP-CAN bearer(s) of the target access.

– Access of a multi-access PDN connection becomes unusable: for the service data flows maintained as result from PCC Rules decision, under the IP-CAN bearer that becomes unusable, no traffic will be detected.

– Access of a multi-access PDN connection becomes usable: for the service data flows which were maintained as result from PCC Rules decision under the IP-CAN bearer when detected as usable, the new traffic will be counted.

For each service data flow, identified by its PCC Rule, a different access type is specified where it has to be enforced. A different rating group may be used as a way to apply charging differentiation per-access type. The charging method, measurement method, reporting level may also potentially be different, in case charging behaviour is not expected to be unified between both domains.

For the case where dynamic PCC is not deployed, per-access Charging Characteristics and pre-defined PCC Rule(s) in
P-GW may be used as a way to apply charging differentiation.

5.2.1.8 Sponsored data connectivity charging

According to TS 23.203 [215] two deployment scenarios exist for sponsored data connectivity. The Sponsor Identifier and Application Service Provider Identifier are provided for sponsored services to the PCRF from the AF over the Rx interface.

In the first scenario the PCRF assigns a service specific Charging Key (i.e. r atingg roup) for a sponsored IP flow. The Charging Key is used by the PCEF to collect separate charging information for offline charging for the sponsored flows. Correlation of charging information for offline charging from multiple users per sponsor and/or application service provider is then performed using the Charging Key.

In a second scenario the Sponsor Identifier and Application Service Provider Identity is included in PCC-rules from the PCRF to the PCEF. For this scenario, the same Charging Key may be used both for IP flows that are sponsored and for flows that are not sponsored. Charging information generated by the PCEF for offline charging include the Sponsor Identity and the Application Service Provider Identity. Correlation of charging information from multiple users per sponsor and/or application service provider can then be based on Sponsor Identity and Application Service Provider Identity instead of the Charging Key.

5.2.1.9 Application Based Charging (ABC)

5.2.1.9.0 Introduction

For the sub-clauses that follow, a single CDR is defined to handle both TDF session and ABC information when both are to be used. E ither TDF session charging, ABC or both may be active as determined by Charging Characteristics. For ABC the opening and closing of CDRs is bound to the TDF session start and end respectively. Many application containers per TDF session can be active simultaneously within the TDF CDR see clause 5.2.3.9.1.

When the CDF is implemented as a separate entity, all of these TDF session and ABC related chargeable events, trigger charging events reporting, for CDRs to be constructed, enriched or closed by CDF, according to clause 5.2.2.

5.2.1.9.1 Charging per application

ABC allows collection of charging information for network usage of application traffic, categorized within the TDF session by rating group or combination of rating group and service identifier. ABC supported by TDF is based on ADC rules. Details of this functionality are specified in TS 23.203 [215].

NOTE: ABC is supported by the P-GW embedding PCEF enhanced with application detection and control functionality as defined in TS 23.203 [215], by mean of appropriate PCC Rules, and therefore specified under FBC clause 5.2.1.3 and clause 5.2.1.10.2.

According to TS 23.203 [215], ABC shall support different charging models per ADC rule.
These charging models may be based on volume and/or time and on number of event matching specific detected application traffic in ADC rule. The following chargeable events are defined for ABC when offline charging is activated:

– Start of TDF session. Upon encountering this event, a new TDF-CDR for this context is created.

– Start of application traffic. If service identifier level reporting is required by the ADC rule, new counts and time stamps for this combination of the rating group and service identifier are started. If rating group level reporting is required by the ADC rule new counts and time stamps for this rating group are started. The type of counters shall depend on the measurement method configured for the ADC rule. When event based charging applies, the first occurrence of an event detected by the pre-defined ADC rules shall imply that a new count is started.
When new events occur, the counter shall be increased. Each event shall be time stamped.

– Termination of application traffic. If service identifier level reporting is required by the ADC rule or if rating group level reporting is required by the ADC rule, the counters and time stamps are closed and added to the TDF-CDR.

– End of TDF session in the TDF. The TDF-CDR is closed upon encountering this trigger.

– Expiry of an operator configured time limit for keeping a CDR open. This event closes all counters. The resulting containers are data to the CDR and the CDR is closed. A new CDR is opened if the TDF session is still active.

– Expiry of an operator configured time limit per rating group. The counters and time stamps are closed and added to the TDF-CDR. A new application traffic container is opened if any application related to the rating group is still active.

– Expiry of an operator configured data volume limit per TDF session. This event closes the TDF-CDR, and a new one is opened if the TDF session is still active.

– Expiry of an operator configured data volume limit per rating group. The counters and time stamps are closed and added to the TDF-CDR. A new one is opened if any application related to the rating group is still active.

– Expiry of an operator configured data event limit per rating group. The counters and time stamps are closed and added to the TDF-CDR. A new one is opened if any application related to the rating group is still active.

– Expiry of an operator configured data event limit per TDF session. This event closes the TDF-CDRs, and new one is opened if the TDF session is still active.

– Change of charging condition: TDF session modification (e.g. SGSN change, S-GW change, user location change, user CSG information change), tariff time change or failure handling procedure triggering. When this event is encountered, all current configured counts and time stamps are captured and new counts and time stamps for all active applications are started.

– Intersystem change (e.g. change of radio interface from GSM to UMTS, RAT change) visible in the TDF. This event closes the TDF-CDR, and a new one is opened if the TDF session is still active.

– PLMN change visible in the TDF. This event closes the TDF-CDR. A new one is opened if the TDF session is still active.

– MS Timezone change visible in the TDF. This event closes the TDF-CDR. A new one is opened if the TDF session is still active.

– Completion of a time envelope as defined in TS 32.299 [50]. This event closes an application traffic container. Further details are described in clause 5.2.3.9.2 "Triggers for TDF-CDR Charging Information Addition". The need for reporting time envelopes may be statically configured for each rating group or dynamically controlled by online charging.

Management intervention may also force trigger a chargeable event.

ADC rules can be activated, deactivated and modified any time during the TDF session lifetime. ADC rule activation, deactivation and modification are not chargeable events of ABC. However these rule changes may lead to "start of application traffic" and "termination of application traffic" chargeable events.

Application Detection and Control rule can contain e.g.:

– Application Identifier to identify or service data flow filters to identify the packets belonging to an application detected application,

– charging method to identify whether online/offline/both/neither charging interface is used,

– measurement method for online/offline charging to identify whether time/volume/events are measured for this application,

– Charging key (i.e. rating group) for that application,

– service identifier for that application,

– reporting level for the application (rating group or combination of the rating group and Service identifier),

– precedence to the situations where two or more ADC rules are overlapping.

Application Detection and Control rule can be:

– pre-defined in TDF (can be activated by the PCRF) or,

– dynamically provisioned and activated by the PCRF over the Sd interface.

This is specified in TS 23.203 [215] and TS 29.212 [216].

According to TS 23.203 [215], the PCRF can modify the following charging information in a dynamic ADC rule: Charging key, Service identifier, Measurement method, and Service identifier level reporting. A change of any of this charging information triggers a "start of application traffic" chargeable event when a valid counter does not exist corresponding to that changed ADC rule. A change of any of this charging information triggers a "termination of application traffic" chargeable event when this was the last active application for the counter corresponding to the original ADC rules.

5.2.1.9.2 Charging per TDF session

TDF collects charging information per user per TDF session. TDF session charging allows the TDF to collect charging information related to data volumes sent to and received by the UE/MS for the timeframe since the establishment till the termination of TDF session. The user can be identified by MSISDN and/or IMSI, while the TDF session can be determined by a unique identifier generated by the P-GW (an "EPS default bearer Charging Identifier" for GTP based connectivity or an "unique Charging Id" for PMIP based connectivity when establishing TDF session.

TDF session specific offline charging in TDF is achieved by ABC offline charging, with a vendor specific rating group/service identifier associated with the TDF session.The main collected information items are duration of the TDF session and data volume transferred during the lifetime of the TDF session. When Charging per TDF session is active, the following chargeable events are defined:

– Start of TDF session. Upon encountering this event, a new TDF-CDR for this context is created.

– End of TDF session in the TDF. The TDF-CDR is closed upon encountering this trigger.

– Expiry of an operator configured time limit per TDF session. This event closes the CDR, and a new one is opened if the TDF session is still active.

– Expiry of an operator configured data volume limit per TDF session. This event closes the TDF-CDR, and a new one is opened if the TDF session is still active.

– Intersystem change (e.g. change of radio interface from GSM to UMTS, RAT change) visible in the TDF.
This event closes the TDF-CDR, and a new one is opened if the TDF session is still active.

– PLMN change visible in the TDF. This event closes the TDF-CDR. A new one is opened if the TDF session is still active.

– MS Timezone change visible in the TDF. This event closes the TDF-CDR. A new one is opened if the TDF session is still active.

Expiry of an operator configured change of charging condition limit per TDF session. This event closes the CDR, and a new one is opened if the TDF session is still active.

NOTE: All the events defined above are a shared events with ABC in clause 5.2.1.9.1 for the single shared CDR.

Management intervention may also force trigger a chargeable event.

5.2.1.10 Charging per IP-CAN session

5.2.1.10.0 General

Charging per IP-CAN session is an optional capability in the P-GW that provides for a consolidated view of the charging information across all bearers in the IP-CAN session. When charging per IP-CAN session is active, the basic principles in this clause apply to the P-GW instead of the principles in clause 5.2.1.1 and clause 5.2.1.3 above.

For the sub-clauses that follow, a single PGW-CDR is defined to handle both types of charging information when both are to be used. When Charging per IP-CAN session is active, either IP-CAN bearer charging, FBC or both may be active as determined by Charging Characteristics.

When the CDF is implemented as a separate entity, all of these IP-CAN bearer and FBC related chargeable events, trigger charging events reporting, for CDRs to be constructed, enriched or closed by CDF, according to description in clause 5.2.2.

5.2.1.10.1 IP-CAN bearer charging

For the purpose of interoperator charging, the P-GW collects charging information per user per IP-CAN bearer.
In case the P-GW is not aware of IP-CAN bearers, i.e. in case of PMIP based connectivity, P-GW collects charging information per IP-CAN session as it would be one IP-CAN bearer. IP-CAN bearer charging allows the P-GW to collect charging information related to data volumes sent to and received by the UE/MS, categorised by the QCI and ARP applied to the IP-CAN bearer. The user can be identified by MSISDN and/or IMSI, while the IP-CAN bearer can be determined by a unique identifier generated by the P-GW when creating an IP-CAN bearer. This identifier is forwarded to the S-GW/ePDG/ TWAG/SGSN so as to allow correlation of S-GW/ePDG/ TWAG/SGSN IP-CAN bearer CDRs with the matching P-GW charging information in the BD.

The amount of data counted in P-GW shall be based on:

– in case of GTP based tunnelling and interworking with external IP networks; the inner IP packets in the GTP-U packet (T-PDU, see TS 29.281 [217])

– in case of GTP based tunnelling and interworking with external networks handling other data services (e.g. non-IP, PPP); the T-PDU packets (see TS 29.281 [217])

– In case of PMIP based protocol; the payload of the GRE tunnel

– In case of DSMIPv6 based protocol; the payload of the tunnelling layer.

As minimum behaviour, the full payload shall be included. Time metering is started when IP-CAN bearer is activated.

NOTE 1: The control plan address of the P-GW, together with the unique charging identifier assigned by the P-GW, enables the correlation of charging information. The control plane IP address of SGSN or P-GW (acting as GGSN) is the IP address used at Gn/Gp interface.
The control plane IP address of S-GW or P-GW is the IP address used at S5/S8 interface.
The control plane IP address of ePDG or P-GW is the IP address used at S2b interface.
The control plane IP address of TWAG or P-GW is the IP address used at S2a interface.

When Charging per IP-CAN session is active and measurements for IP-CAN bearers are captured in the same CDR as FBC measurements, the following chargeable events are defined:

– Start of the default bearer for an IP-CAN session when single access is used or start of the first default bearer for a multi-access PDN connection (i.e., when NBIFOM is accepted by PCRF).
Upon encountering this event, a new CDR for the IP-CAN session is created and the data volume counts
(i.e., uplink and downlink) are started and captured for the IP-CAN bearer.

NOTE 2: Start of the default bearer or start of the first default bearer for an IP-CAN session is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

– Addition of access to a PDN connection.
Additional volume counts are started and captured for IP-CAN bearers of the access. New SGSN/S-GW/ePDG/TWAG address is added to data for the IP-CAN bearer in the CDR.

– Start of a dedicated bearer for an IP-CAN session.
Additional volume counts are started and captured for the dedicated bearer.

– End of dedicated bearer in the P-GW.
The counters and time stamps for the IP-CAN bearer are closed and resulting container added to the CDR.

– Removal of access from a multi-access PDN connection.
The counters and time stamps for the IP-CAN bearers of the removed access are closed and resulting containers added to CDR.

– Access of a multi-access PDN connection becomes unusable.
The counters and time stamps for the IP-CAN bearers of the unusable access are closed and resulting containers added to the CDR.

– Access of a multi-access PDN connection becomes usable.
New volume counts are started and captured for all bearers of the access that has become usable. These may not be the same as those that were previously active when the access became unusable due to changes in PCC Rules.

– End of IP-CAN session (i.e. end of the default bearer for a single access PDN connection or end of the last default bearer for a multi-access PDN connection) in the P-GW.
The counters and time stamps for all IP-CAN bearers and the resulting containers added to the CDR. The CDR is closed.

NOTE 3: The End of IP-CAN session event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

– Serving node (e.g. SGSN/S-GW/ePDG/TWAG) change in the P-GW.
New SGSN/S-GW/ePDG/TWAG address is added to data for the IP-CAN bearer in the CDR.

– Expiry of an operator configured time limit for keeping a CDR open.
This event closes all counters. The resulting containers are added to the CDR and the CDR is closed.
A new CDR is opened if the IP-CAN session is still active.

NOTE 4: The expiry of an operator configured time limit for keeping a CDR open event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

– Expiry of an operator configured time limit per IP-CAN bearer.
The counters and time stamps for the IP-CAN bearer are closed and added to the CDR. A new IP-CAN bearer traffic volume container is opened if the IP-CAN bearer is still active.

– Expiry of an operator configured data volume limit per IP-CAN session.
This event closes the CDR and a new one is opened if the IP-CAN session is still active.

NOTE 5: The expiry of an operator configured data volume limit per IP-CAN session event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

– Expiry of an operator configured data volume limit per IP-CAN bearer.
The counters and time stamps are closed and added to the CDR. A new IP-CAN bearer traffic volume container is opened if the IP-CAN bearer is still active.

– Change of charging condition specific to APN-AMBR change.
This event closes the CDR, and a new one is opened if the IP-CAN session is still active.

– Change of charging condition specific to IP-CAN bearer modification QoS change.
When this event is encountered, all counts and time stamps for the modified bearer are captured and new counts and time stamps for the specific bearer are started.

– Change of charging condition.
IP-CAN bearer modification except QoS change (e.g. SGSN change, S-GW change, user location change, user CSG information change, change of UE presence in Presence Reporting Area(s) , change of 3GPP PS Data Off status, Serving PLMN Rate Control change, APN Rate Control change), or tariff time change. When this event is encountered, all current configured counts and time stamps are captured and new counts and time stamps for all active bearers are started.
IP-CAN bearer modification except QoS change events are associated with one access of a multi-access PDN connection and all counts associated with affected access are identified with the specific event. All counts associated with the other access of a multi-access PDN connection are identified as an indirect change of charging condition.

NOTE 7: The change of charging condition event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

Editor’s Note: whether the special case of user location reporting on dedicated bearer release triggers a change of charging condition for the IP-CAN session is ffs.

– Intersystem change (e.g. change of radio interface from GSM to UMTS, RAT change) for any connected access visible in the P-GW.
This event closes the CDR, and a new one is opened if the IP-CAN session is still active.

NOTE 8: The intersystem change event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

– PLMN change visible in the P-GW. This event closes the CDR.
A new one is opened if the IP-CAN session is still active.

NOTE 9: The PLMN change event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

– MS Timezone change visible in the P-GW. This event closes the CDR.
A new one is opened if the IP-CAN session is still active.

NOTE 10: The MS Timezone change event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

– Expiry of an operator configured limit of number of charging condition changes per IP-CAN session.
This event closes the CDR, and a new one is opened if the IP-CAN session is still active.

NOTE 11: The expiry of an operator configured limit of number of charging condition changes event is a shared event for FBC in clause 5.2.1.10.2 for the single shared CDR.

Management intervention may also force trigger a chargeable event.

NOTE 12: For non-IP type PDN connection, the following do not apply:

– Addition of access to a PDN connection;

– Start of a dedicated bearer for an IP-CAN session;

– End of dedicated bearer in the P-GW;

– Removal of access from a multi-access PDN connection;

– Access of a multi-access PDN connection becomes unusable;

– Access of a multi-access PDN connection becomes usable.

5.2.1.10.2 Flow Based Charging (FBC)

For the purpose of end-user charging, FBC is supported by the P-GW by the integration of a PCEF. With PCEF, charging is enhanced by the capability to categorise the service data flows within IP-CAN session data traffic by rating group or combination of the rating group and service id. FBC provides separate counts per each rating group, combination of the rating group and service id or combination of rating group, sponsor identity and application service provider identity. The level of the reporting is defined per PCC rule. Details of this functionality are specified in TS 23.203 [215] and TS 32.240 [1].

NOTE 1: Even though an individual service data flow template is bound to a specific IP-CAN bearer, the assigned rating group or combination of rating group and service id applies to the entire IP-CAN session.
As a result, data traffic from multiple bearers can be included in the count maintained for the rating group or combination of the rating group and service id. This implies if an operator wishes to be able to separate usage according to IP-CAN bearer within their billing system they will need to ensure that services having different QCI and ARP do not have the same:

– rating group in cases where rating group reporting is used;

– rating group/service id where rating group/service id reporting is used;

– rating group/sponsor identity/application service provider identity where sponsored connectivity level reporting is used.

NOTE 2: The P-GW can only include one QoS Information occurrence per service data container.
This implies if an operator wishes to be able to separate usage according to QCI and ARP within their billing system they will need to ensure that services having different QCI and ARP do not have the same:

– rating group in cases where rating group reporting is used;

– rating group/service id where rating group/service id reporting is used ;

– rating group/sponsor identity/application service provider identity where sponsored connectivity level reporting is used.

NOTE 2a: The P-GW can only include one RAT type per service data container.
This implies if an operator wishes to be able to separate usage according to RAT type within their billing system they will need to ensure that services having different RAT type do not have the same:

– rating group in cases where rating group reporting is used;

– rating group/service id where rating group/service id reporting is used;

– rating group/sponsor identity/application service provider identity where sponsored connectivity level reporting is used.

When Charging per IP-CAN session is active and FBC measurements are captured in the same CDR as measurements for IP-CAN bearers, the following chargeable events are defined:

– Start of the default bearer for an IP-CAN session when single access is used ors tart of the first default bearer for a multi-access PDN connection(i.e., when NBIFOM is accepted by PCRF). Upon encountering this event, a new CDR for the IP-CAN session is created. No service data flow counters are started.

NOTE 3: The start of the default bearer or the start of the first default bearer for an IP-CAN session event is a shared trigger for IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

– Start of service data flow.
If service identifier level reporting is required by the PCC rule, and no counts are present already for this combination of the rating group and service id, then new counts and time stamps for this combination of the rating group and service id are started. If rating group level reporting is required by the PCC rule, and no counts are present already for this rating group, then new counts and time stamps for this rating group are started. If sponsored connectivity level reporting is required by the PCC rule, and no counts are present already for this combination of rating group, sponsor identity and application service provider identity, then new counts and time stamps for this rating group are started. The type of counters shall be according to the measurement method configured for the PCC rule. When event based charging applies, the first occurrence of an event matching a service data flow template in PCC rule shall imply that a new count is started. When new events occur, the counter shall be increased. Each event shall be time stamped.

– Access change of service data flow.
If service identifier level reporting is required by the PCC rule and all service data flows for this combination of the rating group and service id are changing from one access to another, or if rating group level reporting is required by the PCC rule and all service data flows for this rating group are changing from one access to another, or if sponsored connectivity level reporting is required by the PCC rules and all service data flows for this combination of rating group, sponsor identity and application service provider identity are changing from one access to another, the counters and time stamps are closed and the resulting containers added to the CDR.

– Termination of service data flow. If service identifier level reporting is required by the PCC rule and this was the last active service data flow for this combination of the rating group and service id or if rating group level reporting is required by the PCC rule and this was the last active service data flow for this rating group, or if sponsored connectivity level reporting is required by the PCC rule and this was the last active service data flow for this combination of rating group, sponsor identity and application service provider identity, the counters and time stamps are closed and the resulting containers added to the CDR. For information on how the termination of service data flows is detected, refer to TS 23.203 [215].

– End of IP-CAN session (i.e. end of the default bearer for a single access PDN connection or end of the last bearer for a multi-access PDN connection) in the P-GW.
The counters and time stamps for all rating groups and all combinations of rating group and service id are closed and the resulting containers added to the CDR. The CDR is closed.

NOTE 4: The end of IP-CAN session event is a shared event for IP-CAN Bearer Charging in clause 5.2.1.10.1 for the single shared CDR.

NOTE 5: The end of operator configured time limit for keeping a CDR open event is a shared event for IP-CAN Bearer Charging in clause 5.2.1.10.1 for the single shared CDR.

– Expiry of an operator configured time limit per rating group.
The counters and time stamps are closed and added to the CDR.
A new service data flow container is opened if any matching service data flow is still active.

– Expiry of an operator configured data volume limit per IP-CAN session.
This event closes the CDR and a new one is opened if the IP-CAN session is still active.

NOTE 6: The expiry of an operator configured data volume limt per IP-CAN session event is a shared event for
IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

– Expiry of an operator configured data volume limit per rating group.
The counters and time stamps are closed and added to the CDR.
A new service data flow container is opened if any matching service data flow is still active.

– Expiry of an operator configured data event limit per IP-CAN session.
This event closes the CDR and a new one is opened if the IP-CAN session is still active.

NOTE 7: The expiry of an operator configured data event limit per IP-CAN session event is a shared event for IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

– Expiry of an operator configured data event limit per rating group.
The counters and time stamps are closed and added to the CDR.
A new service data flow container is opened if any matching service data flow is still active.

– Change of charging condition.
IP-CAN bearer modification except QoS change (e.g. SGSN change, S-GW change, user location change,
user CSG information change, change of UE presence in Presence Reporting Area(s)), tariff time change or failure handling procedure triggering.
When this event is encountered, all current configured counts and time stamps are captured and new counts and time stamps for all service data flows are started.
IP-CAN bearer modification except QoS change events are associated with one access of a multi-access PDN connection and all counts associated with affected access are identified with the specific event.A ll counts associated with the other access of a multi-access PDN connection are identified as an indirect change of charging condition.

Editor’s Note: The handling of "Serving PLMN Rate Control change", "APN Rate Control change" events when charging per IP-CAN session applies is FFS.

NOTE 8: The change of charging condition event is a shared event for IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

Editor’s Note: whether the special case of user location reporting on dedicated bearer release triggers a change of charging condition for the IP-CAN session is ffs.

NOTE 9: The intersystem change event is a shared event for IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

– PLMN change visible in the P-GW.
This event closes the CDR. A new one is opened if the IP-CAN session is still active.

NOTE 10: The PLMN change event is a shared event for IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

– MS Timezone change visible in the P-GW.
This event closes the CDR. A new one is opened if the IP-CAN session is still active.

NOTE 11: The MS Timezone change event is a shared event for IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

– Expiry of an operator configured limit of charging condition changes per IP-CAN session.
This event closes the CDR, and a new one is opened if the IP-CAN session is still active.

NOTE 12: The expiry of an operator configured limit of charging condition changes per IP-CAN session event is a shared event for IP-CAN bearer charging in clause 5.2.1.10.1 for the single shared CDR.

– Completion of a time envelope as defined in TS 32.299 [50].
This event closes a service data flow container. Further details are described in clause 5.2.3.10.1 "Triggers for PGW-CDR charging information addition’".
The need for reporting time envelopes may be statically configured for each rating group or dynamically controlled by online charging.

Management intervention may also force trigger a chargeable event.

Relevant service data flows for an IP-CAN session are determined when FBC is applied. PCC rules are used for this determination. One PCC rule identifies service data flow to be measured but it can also include certain characteristics related to that service data flow.

PCC rules can be activated, deactivated and modified any time during the IP-CAN session lifetime.
IP-CAN bearer deactivation also leads to deactivation of all PCC rules associated with that bearer.
PCC rule activation, deactivation and modification are not chargeable events.
However these PCC rule changes may lead to "start of service data flow’"and "termination of service data flow’" chargeable events.

According to TS 23.203 [215], the PCRF can modify the following charging information in a dynamic PCC rule which is active in the PCEF: Charging key, Service identifier, Sponsor Identifier, Application Service Provider Identifier, IP-CAN types, Measurement method and reporting level. The PCRF can also modify the allowed access type in the case of NBIFOM.
A change of allowed access type in the case of NBIFOM will trigger an "access change for service data flow" chargeable event when all service data flows for the associated counter are changed from one access to another and takes priority over change of charging information.
A change of any of this charging information will trigger a "start of service data flow’" chargeable event when a valid counter does not exist corresponding to that changed PCC rule.
A change of any of this charging information will trigger a "termination of service data flow’" chargeable event when this was the last active service data flow for the counter corresponding to the original PCC rule.

Removal of an access from a PDN connection is not a trigger for FBC. Subsequent PCC rule handling, may lead to the "access change for a service data flow" or "termination of service data flow" events for the service data flows that were active on the removed access.

Extended packet inspection can be done in the PCEF with pre-defined PCC rules.
The PCEF also have the possibility to output service specific information related to the packet inspection in the CDR.

For non-IP type PDN connection:

– non-3GPP access types are not supported;

– multi-access PDN connections do not apply;

– A single PCC Rule is used with the service data flow descriptor matching the whole non-IP data traffic, and can contain e.g.:

– service data flow template matching all the packets;

– charging method to identify whether online/offline/both/neither charging interface is used;

– measurement method for offline charging to identify whether time/data volume/events are measured for this service data flow;

– Charging key (i.e. rating group) for that service data flow;

– service identifier for that service data flow;

– reporting level for that service data flow:

– rating group level in case a specific rating group is used for non-IP traffic charging;

– combination of the rating group and service id in case a specific rating group/service Id is used for non-IP traffic charging.

5.2.1.11 Data Volume Reporting for Secondary RAT usage

5.2.1.11.1 General

Volume reporting for Secondary RAT is an optional capability in the S-GW and P-GW that provides accounting functionality when a Secondary RAT is used in conjunction with E-UTRAN. Use of Secondary RAT refers to options supported by E-UTRAN with dual radio accesses specified in TS 23.401 [208]. This is valid for both HPLMN and VPLMN.

To align with existing per IP-CAN bearer accounting procedures, the following principles are used:

– The reporting of Secondary RAT Data Volume is controlled by the E-UTRAN.

– The uplink and downlink data volumes for the Secondary RAT are reported (from E-UTRAN to EPC) on a per EPS bearer basis. The report contains Secondary RAT (e.g. NR) resources used for transport of user data and indicated separately for uplink and downlink per EPS bearer and per time interval. The time interval used for the measurements reported (from RAN) may be partitioned to indicate usage that occurred before respectively after an absolute time (that occurs while measurement for secondary RAT usage report is ongoing). For example, the RAN is configured to partition reports in usage, that occurred before respectively after midnight.

– The reporting (performed by E-UTRAN) in association with UE-related control signaling and via standalone reporting is internally triggered by E-UTRAN.

NOTE: Volumes for the secondary RAT are reported in addition to, and uncorrelated from volumes of reported usage, which are undifferentiated between primary and secondary RAT. Considering both volumes would imply the same traffic to be counted twice.

When available by the S-GW, the PSCELL Id associated to the Secondary RAT is collected for SGW-CDR.

5.2.1.12 Volume Based Charging for VoLTE Services

Volume based charging for VoLTE services allows the P-GW to collect charging information for VoLTE service. This functionality is supported by the P-GW by the integration of a PCEF. In the P-GW, FBC (as described in clause 5.2.1.3) applies to the VoLTE service data flows. Details of this functionality are specified in TS 23.203 [215].

NOTE: Some VoLTE service specific charging information include in the PGW-CDR in VoLTE bearer specific offline charging: caller information, callee information, and status of VoLTE service delivery.

The following chargeable events are specified for volume based charging for VoLTE services:

– Start of VoLTE bearer context. Upon encountering this event, a new CDR for this VoLTE bearer context is created and the data volume is captured for the VoLTE bearer context.

– End of VoLTE bearer context. The VoLTE bearer context CDR is closed upon encountering this trigger.

– Expiry of an operator configured time limit per VoLTE bearer context. This event closes the VoLTE bearer context CDR, and a new one is opened if the VoLTE bearer context is still active.

– Expiry of an operator configured data volume limit per VoLTE bearer context. This event closes the VoLTE bearer context CDR, and a new one is opened if the VoLTE bearer context is still active.

– Change of charging condition: tariff time change. When this event is encountered, the current volume count is captured and a new volume count is started.

– Expiry of an operator configured change of charging condition limit per VoLTE bearer context. This event closes the VoLTE bearer context CDR, and a new one is opened if the VoLTE bearer context is still active.

– Management intervention may also force trigger a chargeable event.

5.2.2 Rf message flows

5.2.2.0 General

When the CDF is implemented as a separate entity, the offline charging functionality is based on the PCN nodes (MME, S-GW, ePDG, TWAG, P-GW and TDF) reporting charging information for chargeable events. This reporting is achieved by sending Charging Data Request [start, interim, stop and event] from the PCN network elements to the CDF.

The PCNs shall use the Charging Characteristics profiles to determine whether Charging events (Charging Data Request[start, interim, stop and event]) reporting has to be activated or not.

The trigger conditions for the chargeable events described in 5.2.3.5 for the MME, 5.2.3.3 for the S-GW, 5.2.3.8 for the ePDG, 5.2.3.11 for the TWAG, 5.2.3.9 for the TDF and in 5.2.3.4 for the P-GW are also applicable, and charging events are reported to the external CDF when these trigger conditions are met.

The following clauses provide the charging events reporting description for MME, S-GW, ePDG, TWAG, P-GW and TDF.

5.2.2.1 Triggers for charging events from S-GW

When a Charging Event is reported to the CDF, it includes details such as Subscription id (e.g. IMSI..), Charging-id, SGW address etc. and also a container identifying, for the IP-CAN bearer, the volume count (separated for uplink and downlink traffic), with charging condition change information.

As stated above, the same trigger conditions described in 5.2.3.3 are applicable for charging information addition and Charging Data Request closure.

Charging Data Request[Start] is sent at IP-CAN bearer activation.

For an Charging Data Request[Interim] to be sent with only one container reported, the Partial Record Reason "Maximum number of charging condition changes" should be set to value 1.

5.2.2.2 Triggers for charging events from P-GW

When a Charging Event is reported to the CDF, it includes details such as Subscription id (e.g. IMSI), Charging-id, SGW address, ePDG address, TWAG address, FBC specific charging data etc.,and also a container identifying per rating group or combination of the rating group and service id within the same IP-CAN bearer; the volume counts (separated for uplink and downlink traffic), elapsed time and/or number of events, with associated charging condition change information.

As stated above, the same trigger conditions described in clause 5.2.3.4 are applicable for charging information addition and Charging Data Request closure.

Charging Data Request[Start] is sent at IP-CAN bearer activation.

For an Charging Data Request[Interim] to be sent with only one container reported, the Partial Record Reason "Maximum number of charging condition changes" should be set to value 1.

Editor’s Note : tight interworking with online charging and DCCA failure handling is FFS.

5.2.2.3 Triggers for charging events from ePDG

When a Charging Event is reported to the CDF, it includes details such as Subscription id (e.g. IMSI), Charging-id, ePDG address etc. and also a container identifying for the IP-CAN bearer, the volume count (separated for uplink and downlink traffic), with charging condition change information.

As stated above, the same trigger conditions described in clause 5.2.3.8 are applicable for charging information addition and Charging Data Request closure.

Charging Data Request[Start] is sent at IP-CAN bearer activation.

For an Charging Data Request[Interim] to be sent with only one container reported, the Partial Record Reason "Maximum number of charging condition changes" should be set to value 1.

5.2.2.4 Triggers for charging events from MME

Each Short Message transferred through the MME to/from the SMSC, triggers a Charging Event towards the CDF:

– Short Message received by a UE via the MME (MT direction) from the SMSC;

– Short Message sent by a UE via the MME (MO direction) to the SMSC.

This Charging event reporting is achieved by the MME in Event mode, by sending Charging Data Request[event] to the CDF, on successful or unsuccessful Short Message transfert transaction with UE.

5.2.2.5 Triggers for charging events from TDF

When a Charging Event is reported to the CDF, it includes details such as Subscription id (e.g. IMSI.), Charging-id, SGW address, ePDG address, TWAG address, ABC specific charging data etc., and also a container identifying per rating group or combination of the rating group and service id within the same TDF session; the volume counts (separated for uplink and downlink traffic), elapsed time and/or number of events, with associated charging condition change information TDF session charging is achieved by ABC offline charging with vendor specific rating group or a combination of vendor specific rating group and service id within the same TDF session, see clause 5.2.1.9..

As stated above, the same trigger conditions described in 5.2.3.9 are applicable for charging information addition and Charging Data Request closure.

Charging Data Request Start] is sent at TDF session activation.

For an Charging Data Request[Interim] to be sent with only one container reported, the Partial Record Reason "Maximum number of charging condition changes" should be set to value 1.

5.2.2.6 Triggers for charging events from P-GW when charging per IP-CAN session is active

When a Charging Event is reported to the CDF and charging per IP-CAN session is active, it includes details such as Subscription id (e.g. IMSI), Charging-id, SGW address, ePDG address, TWAG address, FBC specific charging data etc.,and contains either one or both of the following different types of containers:

– traffic volumes, used for IP-CAN bearer charging, identifying per QCI/ARP combination, the volume counts (separated for uplink and downlink traffic) with associated charging condition change information

– service data, used for FBC, identifying per rating group or combination of the rating group and service id within the IP-CAN session, the volume counts (separated for uplink and downlink traffic), elapsed time and/or number of events, with associated charging condition change information.

The trigger conditions described in clause 5.2.3.10 are applicable for charging information addition and Charging Data Request closure.

Charging Data Request[Start] is sent at IP-CAN session activation.

For an Charging Data Request[Interim] to be sent with only one container reported, the Partial Record Reason "Maximum number of charging condition changes" should be set to value 1.

5.2.2.7 Triggers for charging events from TWAG

When a Charging Event is reported to the CDF, it includes details such as Subscription id (e.g. IMSI), Charging-id, TWAG address etc. and also a container identifying for the IP-CAN bearer, the volume count (separated for uplink and downlink traffic), with charging condition change information.

As stated above, the same trigger conditions described in clause 5.2.3.11 are applicable for charging information addition and Charging Data Request closure.

Charging Data Request [Start] is sent at IP-CAN bearer activation.

For an Charging Data Request [Interim] to be sent with only one container reported, the Partial Record Reason "Maximum number of charging condition changes" should be set to value 1.

5.2.3 CDR generation

5.2.3.0 Introduction

The S-CDR, M-CDR, S-SMO-CDR, S-SMT-CDR, LCS-MO-CDR, LCS-MT-CDR, LCS-NI-CDR and S-MB-CDR are generated by the SGSN, the S-SMO-CDR, S-SMT-CDR by the MME,the SGW-CDR by the S-GW, the ePDG-CDR by the ePDG, the TWAG-CDR by the TWAG, the PGW-CDR and G-MB-CDR by the P-GW, the TDF-CDR by the TDF to collect charging information that they subsequently transfer to the Charging Gateway Function (CGF).

The PCNs shall use the Charging Characteristics to determine whether to activate or deactivate CDR generation.
The Charging Characteristics are also used to set the coherent chargeable event conditions (e.g. time/volume limits that trigger CDR generation or information addition). Multiple Charging Characteristics "profiles" may be configured on the PCNs to allow different sets of trigger values. Further details of this functionality, including the mechanism of conveying the Charging Characteristics data item (HLR -> SGSN -> P-GW, HSS -> MME/ S4-SGSN -> S-GW -> P-GW, AAA -> ePDG -> P-GW, or AAA -> TWAG -> PGW), are specified and then in case of TDF, P-GW -> PCRF -> TDF in annex A.
Charging Characteristics are not applicable to MBMS CDR generation.

If CDR generation is activated, it shall be possible to define separate trigger conditions values per Charging Characteristics profile for the following triggers:

– data volume limit;

– time (duration limit);

– maximum number of charging conditions changes (QoS change, Tariff Time change).

The following clauses describe the trigger conditions for the chargeable events described in clause 5.2.1.1 – 5.2.1.6A.
In EPC offline charging, these chargeable events correspond to the triggers for collection of charging information and CDR generation by the SGSN/ MME/S-GW/ePDG/ TWAG/P-GW/TDF.

5.2.3.1 Triggers for S-CDR charging information collection

5.2.3.1.0 General

An S-CDR is used to collect charging information related to the IP-CAN bearer data information for a MS/UE in the SGSN.

If according to the Charging Characteristics, CDR generation is activated an S-CDR shall be opened at IP-CAN bearer activation, and the volume for the context is counted separately in uplink and downlink direction. When a change of charging condition occurs, the volume count is added to the S-CDR and a new count is started. The S-CDR includes details such as Record Type, Served IMSI, Sequence Number etc. Not all of the charging information to be collected is static, and other charging information is directly depending on dynamic Packet-Switched service usage.

The subsequent clauses identify in detail the conditions for adding information to, and closing the S-CDR for generation towards the CGF.

5.2.3.1.1 Triggers for S-CDR charging information addition

The "List of Traffic Volumes" attribute of the S-CDR consists of a set of containers, which are added when specific trigger conditions are met, and identify the volume count per IP-CAN bearer, separated for uplink and downlink traffic, on encountering that trigger condition. Table 5.2.3.1.1.1 identifies which conditions are supported to trigger S-CDR charging information addition.

Table 5.2.3.1.1.1: Triggers for S-CDR charging information addition

Trigger Conditions	Description/Behaviour
QoS Change	A change in the QoS shall result in a "List of Traffic Data Volumes" container being added to the CDR.
Tariff Time Change	On reaching the Tariff Time Change a "List of Traffic Data Volumes" container shall be added to the CDR.
User CSG Information change	A change in user CSG information shall result in a "List of Traffic Data Volumes" container being added to the CDR, if CSG information reporting is required, and a report of User CSG information change is received.
Direct Tunnel establishment/removal	When the SGSN establishes or removes a Direct Tunnel a "List of Traffic Data Volumes " container shall be added to the CDR. See NOTE.
CDR Closure	A list of "List of Traffic Data Volumes" container shall be added to the S-CDR.
NOTE: When a direct tunnel is established, the SGSN will no longer be able to count data volumes associated with the IP-CAN bearer for which the direct tunnel is established

The first volume container of a IP-CAN bearer identifies the uplink/downlink volume since the IP-CAN bearer was opened. Subsequent volume containers store the volume count accrued since the closure of the last container.

5.2.3.1.2 Triggers for S-CDR closure

The S-CDR shall be closed on encountering some trigger conditions.
Table 5.2.3.1.2.1 identifies which conditions are supported to permit closure of the S-CDR.

Table 5.2.3.1.2.1: Triggers for S-CDR closure

Closure Conditions

Description/Behaviour

End of IP-CAN bearer within the SGSN

Deactivation of the IP-CAN bearer in the SGSN shall result in the CDR being closed.
The trigger condition covers:

– termination of IP-CAN bearer;

– SGSN change (inter-SGSN routing area update including intersystem change);

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– data volume limit;

– time (duration) limit;

– maximum number of charging condition changes (QoS/tariff time change);

– management intervention;

– Intra-SGSN intersystem change (change of radio interface from GSM to UMTS or vice versa).

The Partial Record generation trigger thresholds are those associated with the Charging Characteristics.
The Partial Record generation trigger thresholds are GSN configuration parameters defined per Charging Characteristics profile by the operator through OAM&P means, as specified in annex A.

In the event that the S-CDR is closed and the IP-CAN bearer remains active, a further S-CDR shall be opened with an incremented Sequence Number in the SGSN.

5.2.3.2 Triggers for M-CDR charging information collection

5.2.3.2.0 General

An M-CDR is used to collect charging information related to the mobility management of a mobile in the SGSN.

An M-CDR shall be opened for each mobile upon GPRS Attach, indicating the current location information for that MS/UE. When a location change occurs for the attached MS/UE, the new location information is added to the M-CDR. The M-CDR records details such as Record Type, Served IMSI, Sequence Number etc.
Not all of the charging information to be collected is static, and other charging information is directly dependent on the mobility of the MS as provided by the Radio Access Network (RAN). Subsequent partial records may be opened if the M-CDR is closed and the MS is still attached to the network.

The subsequent clauses identify in detail the conditions for adding information to, and closing of the M-CDR for generation towards the CGF.

5.2.3.2.1 Triggers for M-CDR charging information addition

The "Change of Location" attribute of the M-CDR consists of a set of containers, which are added when specific trigger conditions are met, and identify the time stamped routing area on encountering that trigger condition.
Table 5.2.3.2.1.1 identifies which conditions are supported to trigger M-CDR charging information addition.

Table 5.2.3.2.1.1: Triggers for M-CDR charging information addition

Trigger Conditions	Description/Behaviour
Mobility Change	The first "Change of Location" container shall be captured when the MM context is created. Subsequent changes in the Routing Area shall result in a "Change of Location" container being added to the M-CDR.

5.2.3.2.2 Triggers for M-CDR closure

The M-CDR shall be closed on encountering some trigger conditions.
Table 5.2.3.2.2.1 identifies which conditions are supported to permit closures of the M-CDR.

Table 5.2.3.2.2.1: Triggers for M-CDR closure

Closure Conditions

Description/Behaviour

End of MM Context within SGSN

Deactivation of the MM context in the SGSN shall result in the CDR being closed.
The trigger condition covers:

– SGSN change (inter-SGSN routing area update including intersystem change);

– GPRS detach;

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– time (duration) limit;

– maximum number of mobility changes; and

– Management intervention;

– Intra-SGSN intersystem change (change of radio interface
from GSM to UMTS or vice versa).

The Partial Record generation trigger thresholds are those associated with the Charging Characteristics.
The Partial Record generation trigger thresholds are SGSN configuration parameters defined per Charging Characteristics profile by the operator through OAM&P means, as specified in annex A.

In the event that the M-CDR is closed and the mobile is still known to the SGSN, a further M-CDR shall be opened with an incremented Sequence Number in the SGSN.

5.2.3.3 Triggers for SGW-CDR charging information collection

5.2.3.3.0 Introduction

A SGW-CDR is used to collect charging information related to the IP-CAN bearer data information for a UE/MS in
the S-GW.

SGW-CDR separates collected charging information per QCI/ARP pair. SGW-CDR can include:

IP-CAN bearer specific container reporting the usage and authorized QCI/ARP for IP-CAN bearer.

Each SGW-CDR includes at least IP-CAN bearer specific container(s).

If, according to the Charging Characteristics, CDR generation is activated a SGW-CDR shall be opened at IP-CAN bearer activation and IP-CAN bearer specific container is opened..

When a change of charging condition occurs, the volume counts are added to the SGW-CDR and new counts are started. The SGW-CDR includes details such as Record Type, Served IMSI, Sequence Number etc.
Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

The subsequent clauses identify in detail the conditions for adding information to, and closing the SGW-CDR for generation towards the CGF.

5.2.3.3.1 Triggers for SGW-CDR charging information addition

The "List of Traffic Data Volumes" attribute of the SGW-CDR consists of a set of containers, which are added when specific trigger conditions are met, and identify the volume count per QCI/ARP pair, separated for uplink and downlink traffic, on encountering that trigger condition.
Table 5.2.3.3.1.1 identifies which conditions are supported to trigger SGW-CDR charging information addition.

Table 5.2.3.3.1.1: Triggers for SGW-CDR charging information addition

Trigger Conditions	Description/Behaviour
QoS Change	A change in the QoS shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR and new IP-CAN bearer specific container is opened.
Tariff Time Change	On reaching the Tariff Time Change open "List of Traffic Data Volumes" containers shall be closed and added to the CDR.
User Location Change	A change in the User Location Info (e.g. ECGI, TAI, RAI, SAI or CGI) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR, if location reporting is required, and a report of User Location Change is received.
User CSG Information change	A change in the User CSG info (e.g. CSG ID, access mode or CSG membership indication) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR, if CSG information reporting is required, and a report of User CSG information change is received.
Change of UE presence in Presence Reporting Area	A change of UE presence in Presence Reporting Area(s) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR, if such reporting is required, and a report that user enters/leaves the area or the Presence Reporting Area(s) is set to inactive by the serving node , are received.
Change in UP to UE	A change in the User Plane to UE (i.e. switch between S11-U and S1-U) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR and new IP-CAN bearer specific container is opened.
Serving PLMN Rate Control Change	A change in the Serving PLMN Rate Control shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR and new IP-CAN bearer specific container is opened.
CDR Closure	Open "List of Traffic Data Volumes" containers shall be closed and added to the SGW-CDR.

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 (e.g. S4-SGSN/MME) addresses. New serving node address is added to the list when e.g. S4-SGSN/MME changes.

When Charging Event (ACR) is triggered by table 5.2.3.3.1.1 conditions, the Change-Condition sub-field associated to the added volume container, indicating the appropriate condition shall be present, excluding CDR Closure case.

When Charging Event (ACR) is triggered by CDR Closure condition, this Change-Condition sub-field associated to the added volume container shall be omitted, except when CDR closure is due to "maximum number of charging condition changes", where it shall be present with the original condition change.

When Charging Event (ACR) is triggered by "User CSG Information change" as a Change condition, the following shall apply for the added volume container:

– When User enters in a CSG cell or a hybrid cell: the CSG ID, access mode and CSG membership indication (when hybrid), shall be provided together with this "User CSG Information change" Change-Condition.

– User leaves a CSG cell or a hybrid cell: this "User CSG Information change" Change-Condition shall be provided without any CSG ID, access mode and CSG membership indication, unless the user is entering a new CSG cell or hybrid cell.

5.2.3.3.2 Triggers for SGW-CDR closure

The SGW-CDR shall be closed on encountering some trigger conditions.
Table 5.2.3.3.2.1 identifies which conditions are supported to permit closure of the SGW-CDR.

Table 5.2.3.3.2.1: Triggers for SGW-CDR closure

Closure Conditions

Description/Behaviour

End of IP-CAN bearer within the S-GW

Deactivation of the IP-CAN bearer in the S-GW shall result in the CDR being closed. The trigger condition covers:

– termination of IP-CAN bearer;

– inter serving node change;

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– data volume limit;

– time (duration) limit;

– maximum number of charging condition changes (QoS/tariff time change);

– management intervention;

– MS time zone change;

– PLMN change;

– radio access technology change (RAT Type).

– MO exception data counter receipt.

The Partial Record generation trigger thresholds are those associated with the Charging Characteristics.
The Partial Record generation trigger thresholds are S-GW configuration parameters defined per Charging Characteristics profile by the operator through OAM&P means, as specified in annex A.

In the event that the SGW-CDR is closed and the IP-CAN bearer remains active, a further SGW-CDR is opened with an incremented Sequence Number in the S-GW.

When Charging Event (ACR) is triggered by table 5.2.3.3.2.1conditions, the Change-Condition (at PS information level) associated to the CDR Closure, indicating the appropriate condition shall be present, and it shall be omitted otherwise.

5.2.3.4 Triggers for PGW-CDR charging information collection

5.2.3.4.0 Introduction

An PGW-CDR is used to collect charging information related to the IP-CAN bearer data information for a UE/MS in the P-GW, where the data volumes, elapsed time or number of events within each PGW-CDR are separately counted per rating group or per combination of the rating group and service id. In case of P-GW is not aware of IP-CAN bearers, i.e. in case of PMIP based connectivity, P-GW collects charging information per IP-CAN session as it would be one IP-CAN bearer.

Many service data flow containers per IP-CAN bearer can be active simultaneously in PGW-CDR. A service data flow container is activated when traffic is detected and no matching active service data flow container exist; a service data flow container is closed when the termination of the last service data flow matching to the service data flow container is detected by the P-GW. When event based charging applies, the first occurrence of an event matching a service data flow template shall imply service data flow start. Details on FBC can be found in TS 23.203 [215] and TS 32.240 [1].

If, according to the Charging Characteristics profile, CDR generation is activated an PGW-CDR shall be opened at
IP-CAN bearer activation, and the volume (separately in uplink and downlink direction), elapsed time and/or number of events are counted. When a change of charging condition occurs, all containers are added to the PGW-CDR.
The PGW-CDR includes details such as Record Type, Served IMSI, Sequence Number etc. and the FBC specific charging data. Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

It shall be possible to activate both online and offline charging interfaces for the same IP-CAN bearer.
The default online and offline charging shall work independently of each other. Optionally it may be possible to operate in a tight interworking between online and offline charging mechanism i.e. only the specified quota re-authorisation triggers armed by OCS (including e.g. tariff time change, returned quotas, etc.) are used to close the service data flow containers for the PGW-CDR charging information addition.

The subsequent clauses identify in detail the conditions for adding information to, and closing the PGW-CDR for generation towards the CGF.

5.2.3.4.1 Triggers for PGW-CDR charging information addition

IP-CAN bearer specific offline charging is achieved with IP-CAN bearer specific rating group/service identifier defined in clause 5.3.1.1.

The "List of Service Data" attribute of the PGW-CDR consists of a set of containers, which are added when specific trigger conditions are met. Each container identifies the configured counts (volume separated for uplink and downlink, elapsed time or number of events) per rating group or combination of the rating group and service id within the same
IP-CAN bearer, on encountering that trigger condition. For envelope reporting, the containers represent complete and closed time envelopes determined by mechanisms defined in TS 32.299 [50].
Table 5.2.3.4.1.1 identifies conditions that may be supported as recording triggers under consideration of additional Debit / Reserve Units triggers.

Some of the triggers are non-exclusive (e.g. IP-CAN bearer modification with a couple of reasons, IP-CAN bearer modification reasons that cause PGW-CDR closure).

Table 5.2.3.4.1.1: Triggers for PGW-CDR charging information addition "List of Service Data"

Trigger Conditions	Description/Behaviour
IP-CAN bearer modification	A change of IP-CAN bearer conditions (e.g. QoS change, SGSN/S-GW/ePDG/TWAG change, user location change, user CSG information change, change of UE presence in a Presence Reporting Area(s), Serving PLMN Rate Control, APN Rate Control, change of 3GPP PS Data off Status) shall result in a set of "List of Service Data" containers, i.e. all active service data flow containers, being added to the CDR as described in clause 5.2.1.3. In a tight interworking between online and offline charging the specified quota re-authorisation triggers armed by OCS are supported.
Tariff Time Change	On reaching the Tariff Time Change a set of "List of Service Data" containers, i.e. all active service data flow containers, shall be added to the CDR. In a tight interworking between online and offline charging the Debit / Reserve Units tariff time change from OCS is supported.
Failure Handling procedure triggering	When the Credit Control Failure Handling mechanism is triggered a "List of Service Data’”, i.e. all active service data flow containers shall be added to the CDR. The causes are only relevant in case of simultaneously usage of an active Debit / Reserve Units session.
Service data flow report	In case of independent online and offline charging a "List of Service Data" container for the service data flow shall be added when: – expiry of time limit; – expiry of volume limit; – expiry of unit limit; – termination of service data flow.
Service data flow report	In case of tight interworking online and offline charging a "List of Service Data" container for the service data flow shall be added when: – time threshold reached; – volume threshold reached; – unit threshold reached; – time quota exhausted; – volume quota exhausted; – unit quota exhausted; – expiry of quota validity time; – termination of service data flow: – re-authorization request by OCS. – access of a multi-access PDN connection becomes unusable
CDR Closure	All active "List of Service Data" containers shall be added to the PGW-CDR. Note: The trigger condition is a common value that has to be used for CDR closure together with detailed reason.

The first traffic container identifies the data traffic since the IP-CAN bearer was opened. Subsequent data traffic containers store the configured counts accrued since the closure of the last container.

For envelope reporting, each envelope contains information about the data volume transferred in both uplink and downlink and / or the number of events that occurred for the duration that envelope is open. Only completed time envelopes shall be added to the PGW-CDR. The determination of completed envelopes are defined in TS 32.299 [50]. The triggers listed in the previous table 5.2.3.4.1.1 shall not apply to envelope reporting. Envelopes that are not complete when a partial PGW-CDR is closed shall be added to the next PGW-CDR.

The "Serving node Address" attribute of the PGW-CDR consists of a list of SGSN/S-GW/ePDG/TWAG addresses.
New SGSN/S-GW/ePDG/TWAG address is added to the list when SGSN/S-GW/ePDG/TWAG changes.

When Charging Event (ACR) is triggered by table 5.2.3.4.1.1conditions, the Change-Condition sub-field associated to the added container, indicating the appropriate condition, shall be present, excluding CDR Closure case.

When Charging Event (ACR) is triggered by CDR Closure condition, this Change-Condition sub-field associated to the added container shall be omitted, except when CDR closure is due to "maximum number of charging condition changes", where it shall be present with the original condition change.

When Charging Event (ACR) is triggered by "User CSG Information change" as a Change condition, the following shall apply for the added volume container:

5.2.3.4.2 Triggers for PGW-CDR closure

The PGW-CDR shall be closed on encountering trigger conditions.

Table 5.2.3.4.2.1 identifies which conditions are supported to permit closure of the PGW-CDR.

Table 5.2.3.4.2.1: Triggers for PGW-CDR closure

Closure Conditions

Description/Behaviour

End of IP-CAN bearer within the P-GW

Deactivation of the IP-CAN bearer in the P-GW shall result in the CDR being closed.
The trigger condition covers:

– termination of IP-CAN bearer;

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– data volume limit;

– time (duration) limit;

– maximum number of charging condition changes (i.e. number of service containers);

– management intervention;

– MS time zone change;

– PLMN change;

– radio access technology change (RAT Type).

– MO exception data counter receipt.

The Partial Record generation trigger thresholds are those associated with the Charging Characteristics.
The Partial Record generation trigger thresholds are P-GW configuration parameters defined per Charging Characteristics profile by the operator through OAM&P means, as specified in annex A.

In the event that the PGW-CDR is closed and the IP-CAN bearer remains active, a further PGW-CDR is opened with an incremented Sequence Number in the P-GW.

When Charging Event (ACR) is triggered by table 5.2.3.4.2.1 conditions, the Change-Condition (at PS information level) associated to the CDR Closure, indicating the appropriate condition shall be present, and it shall be omitted otherwise.

5.2.3.5 Triggers for SMS-CDR charging information collection

The generation of the SMS related CDRs is based on the observation and capture of simple events, i.e. the transfer of Short Messages through the SGSN and MME, in MO or MT direction.

A S-SMO-CDR is used to collect charging information related to the transmission of a SM in MO direction via the SGSN or MME. If, according to the Charging Characteristics, CDR generation is activated a S-SMO-CDR shall be created when the SGSN or MME has successfully forwarded a SM to the SMSC on behalf of the UE/MS. The S-SMO-CDR includes details such as Record Type, Served IMSI, Sequence Number etc.

A S-SMT-CDR is used to collect charging information related to the transmission of a SM in MT direction via the SGSN or MME. If, according to the Charging Characteristics, CDR generation is activated a S-SMT-CDR shall be created when the SGSN or MME has successfully forwarded a SM from the SMSC to the UE/MS. The S-SMT-CDR includes details such as Record Type, Served IMSI, Sequence Number etc.

Note that the above CDR types only capture the SMS events when transferred through the SGSN and MME.
Equivalent charging functionality for the CS domain is specified in TS 32.250 [10].
3GPP specifications do not define service specific charging functionality for SMS.

5.2.3.6 Triggers for LCS-CDR charging information collection

The generation of the LCS related CDRs is based on the observation and capture of simple events, i.e. the invocation of location requests from the UE/MS (LCS-MO-CDR), an external entity (LCS-MT-CDR) or the network (LCS-NI-CDR).

A LCS-MO-CDR is used to collect charging information related to the transmission of a location request, originating from the UE/MS to be located, via the SGSN. If, according to the Charging Characteristics, CDR generation is activated a LCS-MO-CDR shall be created when the SGSN has received the RANAP "Location Report" message from the RNC.
The LCS-MO-CDR includes details such as Record Type, Served IMSI, Sequence Number etc.

A LCS-MT-CDR is used to collect charging information related to the transmission of a location request for a UE via the SGSN where the location request originates from an external entity. If, according to the Charging Characteristics, CDR generation is activated a LCS-MT-CDR shall be created when the SGSN has received the RANAP "Location Report" message from the RNC. The LCS-MT-CDR includes details such as Record Type, Served IMSI, Sequence Number etc.

A LCS-NI-CDR is used to collect charging information related to the transmission of a network induced location request via the SGSN. If, according to the Charging Characteristics, CDR generation is activated a LCS-NI-CDR shall be created when the SGSN has received the RANAP "Location Report" message from the RNC. The LCS-MO-CDR includes details such as Record Type, Served IMSI, Sequence Number etc.

Note that the above CDR types only capture the LCS events when transferred through the SGSN.
Equivalent charging functionality for the CS domain is specified in TS 32.250 [10]. Service specific charging functionality for LCS is specified in TS 32.271 [31].

5.2.3.7 Triggers for S-MB-CDR and G-MB-CDR charging information collection for MBMS context charging for GPRS

5.2.3.7.1 Triggers for S-MB-CDR and G-MB-CDR charging information creation

S-MB-CDR and G-MB-CDR are used to collect charging information related to the MBMS bearer context data information for a MBMS bearer service in the GSN. The triggers for both S-MB-CDR and G-MB-CDR to start collecting charging information are the same.

S-MB-CDR and G-MB-CDR shall be opened at MBMS bearer context creation. Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

The subsequent clauses identify in detail the conditions for adding information to, and closing the S-MB-CDR and
G-MB-CDR for generation towards the CGF.

5.2.3.7.2 Triggers for S-MB-CDR and G-MB-CDR charging information addition

The "List of Traffic Data Volumes" attribute consists of a set of containers, which are added when specific trigger conditions are met, and identify the volume count per MBMS bearer context, for downlink traffic, on encountering that trigger condition.
Table 5.2.3.7.2.1 identifies which conditions are supported to trigger S-MB-CDR and G-MB-CDR charging information addition.

Table 5.2.3.7.2.1: Triggers for S-MB-CDR and G-MB-CDR charging information addition

Trigger Conditions	Description/Behaviour
Tariff Time Change	On reaching the Tariff Time Change a "List of Traffic Data Volumes" container shall be added to the CDR.
CDR Closure	A list of "List of Traffic Data Volumes" container shall be added to the relevant CDR.

The first volume container of a MBMS bearer context identifies the volume since the record was opened.
Subsequent volume containers store the volume count accrued since the closure of the last container.

5.2.3.7.3 Triggers for S-MB-CDR and G-MB-CDR closure

The S-MB-CDR and G-MB-CDR shall be closed on encountering the trigger conditions identified in table 5.2.3.7.3.1.

Table 5.2.3.7.3.1: Triggers for S-MB-CDR and G-MB-CDR closure

Closure Conditions

Description/Behaviour

End of MBMS Bearer Context within the GSN

Deactivation of the MBMS bearer context in the GSN shall result in the CDR being closed. The trigger condition covers:

– termination of MBMS bearer context;

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– data volume limit;

– time (duration) limit;

– change in list of downstream nodes;

– management intervention.

The Partial Record generation trigger thresholds are those associated with GSN configured information.
In the event that the CDR is closed and the MBMS bearer context remains active, a further CDR is opened with an incremented Sequence Number in the GSN.

5.2.3.7A Triggers for MBMS-GW-CDR charging information collection for MBMS context charging for EPS

5.2.3.7A.1 Triggers for MBMS-GW-CDR charging information creation

MBMS-GW-CDR is used to collect charging information related to the MBMS bearer context data information for a MBMS bearer service in EPS.

MBMS-GW-CDR shall be opened at MBMS bearer context creation. Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Evolved Packet System service usage.

The subsequent clauses identify in detail the conditions for adding information to, and closing the MBMS-GW-CDR for generation towards the CGF.

5.2.3.7A.2 Triggers for MBMS-GW-CDR charging information addition

The "List of Traffic Data Volumes" attribute consists of a set of containers, which are added when specific trigger conditions are met, and identify the volume count per MBMS bearer context, for downlink traffic, on encountering that trigger condition.
Table 5.2.3.7A.2.1 identifies which conditions are supported to trigger MBMS-GW-CDR charging information addition.

Table 5.2.3.7A.2.1: Triggers for MBMS-GW-CDR charging information addition

Trigger Conditions	Description/Behaviour
Tariff Time Change	On reaching the Tariff Time Change a "List of Traffic Data Volumes" container shall be added to the CDR.
CDR Closure	A list of "List of Traffic Data Volumes" container shall be added to the relevant CDR.

5.2.3.7A.3 Triggers for MBMS-GW-CDR closure

The MBMS-GW-CDR shall be closed on encountering the trigger conditions identified in table 5.2.3.7A.3.1.

Table 5.2.3.7A.3.1: Triggers for MBMS-GW-CDR closure

Closure Conditions

Description/Behaviour

End of MBMS Bearer Context within the MBMS GW

Deactivation of the MBMS bearer context in the MBMS GW shall result in the CDR being closed. The trigger condition covers:

– termination of MBMS bearer context;

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons. The trigger condition covers:

– data volume limit;

– time (duration) limit;

– maximum number of charging condition changes;

– change in list of downstream nodes;

– management intervention.

The Partial Record generation trigger thresholds are those associated with MBMS GW configured information. In the event that the CDR is closed and the MBMS bearer context remains active, a further CDR is opened with an incremented Sequence Number in the MBMS GW.

5.2.3.8 Triggers for ePDG-CDR charging information collection

5.2.3.8.0 Introduction

A ePDG-CDR is used to collect charging information related to the IP-CAN bearer data information for a UE/MS in the ePDG.

If, according to the Charging Characteristics, CDR generation is activated an ePDG-CDR shall be opened at IP-CAN bearer activation and IP-CAN bearer specific container is opened.

When a change of charging condition occurs, the volume counts are added to the ePDG-CDR and new counts are started. The ePDG-CDR includes details such as Record Type, Served IMSI, Sequence Number etc. Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

The subsequent clauses identify in detail the conditions for adding information to, and closing the ePDG-CDR for generation towards the CGF.

5.2.3.8.1 Triggers for ePDG-CDR charging information addition

The "List of Traffic Data Volumes" attribute of the ePDG-CDR consists of a set of containers, which are added when specific trigger conditions are met, and identify the volume count per Qos, separated for uplink and downlink traffic, on encountering that trigger condition.
Table 5.2.3.8.1.1 identifies which conditions are supported to trigger ePDG-CDR charging information addition.

Table 5.2.3.8.1.1: Triggers for ePDG-CDR charging information addition

Trigger Conditions	Description/Behaviour
QoS Change	A change in the QoS shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR and new IP-CAN bearer specific container is opened.
Tariff Time Change	On reaching the Tariff Time Change open "List of Traffic Data Volumes" containers shall be closed and added to the CDR.
User Location Change	A change in UWAN User Location Information (e.g. change in UE local IP address within the ePDG) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR and new IP-CAN bearer specific container is opened.
CDR Closure	Open "List of Traffic Data Volumes" containers shall be closed and added to the ePDG-CDR.

Volume container identifies the uplink/downlink volume since the closure of the last container.

When Charging Event (ACR) is triggered by table 5.2.3.8.1.1 conditions, the Change-Condition sub-field associated to the added volume container, indicating the appropriate condition, shall be present, excluding CDR Closure case.

5.2.3.8.2 Triggers for ePDG-CDR closure

The ePDG-CDR shall be closed on encountering some trigger conditions.
Table 5.2.3.8.2.1 identifies which conditions are supported to permit closure of the ePDG-CDR.

Table 5.2.3.8.2.1: Triggers for ePDG-CDR closure

Closure Conditions

Description/Behaviour

End of IP-CAN bearer within the ePDG

Deactivation of the IP-CAN bearer in the ePDG shall result in the CDR being closed. The trigger condition covers:

– termination of IP-CAN bearer;

– any abnormal release;

– inter serving node change.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– data volume limit;

– time (duration) limit;

– maximum number of charging condition changes (QoS/tariff time change);

– management intervention;

The Partial Record generation trigger thresholds are those associated with the Charging Characteristics.
The Partial Record generation trigger thresholds are ePDG configuration parameters defined per Charging Characteristics profile by the operator through OAM&P means, as specified in annex A.

In the event that the ePDG-CDR is closed and the IP-CAN bearer remains active, a further ePDG-CDR is opened with an incremented Sequence Number in the ePDG.

When Charging Event (ACR) is triggered by table 5.2.3.8.2.1 conditions, the Change-Condition (at PS information level) associated to the CDR Closure, indicating the appropriate condition shall be present, and it shall be omitted otherwise.

5.2.3.9 Triggers for TDF-CDR charging information collection

5.2.3.9.1 Triggers for TDF-CDR charging information creation

A TDF-CDR is used to collect charging information related to the TDF session information for a UE/MS in the TDF, where the data volumes, elapsed time or number of events within each TDF-CDR are separately counted per rating group or per combination of the rating group and service id.

Many application containers per TDF session can be active simultaneously in TDF-CDR. An application container is activated when application traffic is detected and no matching active application container exist; an application container is closed when the application traffic of the matching application container is terminated as detected by the TDF.
When event based charging applies, the first occurrence of an event matching an application shall imply application traffic start. Details on ABC can be found in TS 23.203 [215] and TS 32.240 [1].

If, according to the Charging Characteristics profile, CDR generation is activated, a TDF-CDR shall be opened at TDF session establishment, and the volume (separately in uplink and downlink direction), elapsed time and/or number of events are counted. When a change of charging condition occurs, all containers are added to the TDF-CDR.
The TDF-CDR includes details such as Record Type, Served IMSI, Sequence Number etc. and the ABC specific charging data. Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

It shall be possible to activate both online and offline charging interfaces for the same TDF session.
The default online and offline charging shall work independently of each other. Optionally it may be possible to operate with tight interworking between the online and offline charging mechanisms such that only the specified quota re-authorisation triggers armed by the OCS (including e.g. tariff time change, returned quotas, etc.) are used to close the application containers for the TDF-CDR charging information addition, this information would be provided by the OCS in the Offline-Charging AVP. In this case, the information provided by the OCS shall take precedence over the default configuration at the TDF.

The subsequent clauses identify in detail the conditions for adding information to, and closing the TDF-CDR for generation towards the CGF.

5.2.3.9.2 Triggers for TDF-CDR charging information addition

TDF session specific offline charging is achieved with TDF session specific rating group/service identifier defined in clause 5.2.1.9.2.

The "List of Service Data" attribute of the TDF-CDR consists of a set of containers, which are added when specific trigger conditions are met. Each container identifies the configured counts (volume separated for uplink and downlink, elapsed time or number of events) per rating group or combination of the rating group and service id within the same TDF session, on encountering that trigger condition. For envelope reporting, the containers represent complete and closed time envelopes determined by mechanisms defined in TS 32.299 [50].
Table 5.2.3.9.2.1 identifies conditions that may be supported as recording triggers under consideration of additional Debit / Reserve Units triggers.

Some of the triggers are non-exclusive (e.g. TDF session modification with a couple of reasons, TDF session modification reasons that cause TDF-CDR closure).

Table 5.2.3.9.2.1: Triggers for TDF-CDR charging information addition "List of Service Data"

Trigger Conditions	Description/Behaviour
TDF session modification	A change of TDF session conditions (e.g. SGSN/S-GW/ePDG/TWAG change, user location change, user CSG information change) shall result in a set of "List of Service Data" containers, i.e. all active application containers, being added to the CDR as described in clause 5.2.1.9. In a tight interworking between online and offline charging the specified quota re-authorisation triggers armed by OCS are supported.
Tariff Time Change	On reaching the Tariff Time Change a set of "List of Service Data" containers, i.e. all active application containers, shall be added to the CDR. In a tight interworking between online and offline charging the Debit / Reserve Units tariff time change from OCS is supported.
Failure Handling procedure triggering	When the Failure Handling mechanism is triggered a "List of Service Data’”, i.e. all active application containers shall be added to the CDR. The causes are only relevant in case of simultaneously usage of an active Debit / Reserve Units session.
Application traffic report	In case of independent online and offline charging a "List of Service Data" container for the application shall be added when: – expiry of time limit; – expiry of volume limit; – expiry of unit limit; – termination of application traffic.
Application traffic report	In case of tight interworking online and offline charging a "List of Service Data" container for the application shall be added when: – time threshold reached; – volume threshold reached; – unit threshold reached; – time quota exhausted; – volume quota exhausted; – unit quota exhausted; – expiry of quota validity time; – termination of application traffic: – re-authorization request by OCS.
CDR Closure	All active "List of Service Data" containers shall be added to the TDF-CDR. NOTE: The trigger condition is a common value that has to be used for CDR closure together with detailed reason.

The first traffic container identifies the data traffic since the TDF session was opened.
Subsequent data traffic containers store the configured counts accrued since the closure of the last container.

For envelope reporting, each envelope contains information about the data volume transferred in both uplink and downlink and / or the number of events that occurred for the duration that envelope is open. Only completed time envelopes shall be added to the TDF-CDR. The determination of completed envelopes are defined in TS 32.299 [50]. The triggers listed in the previous table 5.2.3.9.2.1 shall not apply to envelope reporting. Envelopes that are not complete when a partial TDF-CDR is closed shall be added to the next TDF-CDR.

The "Serving node Address" attribute of the TDF-CDR consists of a list of SGSN/S-GW/ePDG/TWAG addresses.
New SGSN/S-GW/ePDG/TWAG address is added to the list when SGSN/S-GW/ePDG/TWAG changes.

When Charging Event (ACR) is triggered by table 5.2.3.9.2.1 conditions, the Change-Condition sub-field associated to the added container, indicating the appropriate condition shall be present, excluding CDR Closure case.

When Charging Event (ACR) is triggered by "User CSG Information change" as a Change condition, the following shall apply for the added volume container:

5.2.3.9.3 Triggers for TDF-CDR closure

The TDF-CDR shall be closed on encountering specified trigger conditions.

Table 5.2.3.9.3.1 identifies which conditions are supported to permit closure of the TDF-CDR.

Table 5.2.3.9.3.1: Triggers for TDF-CDR closure

Closure Conditions

Description/Behaviour

End of TDF session

TDF session termination shall result in the CDR being closed. The trigger condition covers:

– termination of TDF session by the PCRF;

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons. The trigger condition covers:

– data volume limit;

– time (duration) limit;

– maximum number of charging condition changes (i.e. number of service containers);

– management intervention;

– MS time zone change;

– PLMN change;

– radio access technology change (RAT Type).

The Partial Record generation trigger thresholds are those associated with the Charging Characteristics.
The Partial Record generation trigger thresholds are TDF configuration parameters defined per Charging Characteristics profile by the operator through OAM&P means, as specified in Annex A.

In the event that the TDF-CDR is closed and the TDF session remains active, a further TDF-CDR is opened with an incremented Sequence Number in the TDF.

When Charging Event (ACR) is triggered by table 5.2.3.9.3.1 conditions, the Change-Condition (at PS information level) associated to the CDR Closure, indicating the appropriate condition shall be present, and it shall be omitted otherwise.

5.2.3.10 Triggers for PGW-CDR charging information collection when IP-CAN session charging is active

5.2.3.10.1 General

A PGW-CDR is used to collect charging information related to the IP-CAN bearer data information for a UE/MS in
the P-GW. When IP-CAN session charging is active, as described in clause 5.2.2.6, two types of data can be collected: traffic volumes used for IP-CAN bearer charging and service data used for FBC.

Many traffic volume and service data flow containers per IP-CAN session can be active simultaneously in PGW-CDR.

A new traffic volume container is activated when an IP-CAN bearer is activated.

A service data flow container is activated when traffic is detected and no matching active service data flow container exist; a service data flow container is closed when the termination of the last service data flow matching to the service data flow container is detected by the P-GW. When event based charging applies, the first occurrence of an event matching a service data flow template shall imply service data flow start. Details on FBC can be found in TS 23.203 [215] and TS 32.240 [1].

If, according to the Charging Characteristics profile, CDR generation is activated, a PGW-CDR shall be opened at
IP-CAN session activation, and the volume (separately in uplink and downlink direction), elapsed time and/or number of events are counted.

When a change of charging condition occurs, all containers are added to the PGW-CDR. The PGW-CDR includes details such as Record Type, Served IMSI, Sequence Number etc. and both the traffic data and FBC specific charging data.
Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

The subsequent clauses identify in detail the conditions for adding information to, and closing the PGW-CDR for generation towards the CGF.

5.2.3.10.2 Triggers for PGW-CDR charging information addition when IP-CAN session charging is active

The "List of Traffic Data Volumes" attribute of the PGW-CDR consists of a set of containers, which are added when specific trigger conditions are met, and identify the volume counter per QCI/ARP pair, separated for uplink and downlink traffic, on encountering that trigger conditions. Table 5.2.3.10.2.1 identifies which conditions are supported to trigger PGW-CDR charging information addition for the "List of Traffic Data Volumes" attribute.

The "List of Service Data" attribute of the PGW-CDR consists of a set of containers, which are added when specific trigger conditions are met. Each container identifies the configured counts (volume separated for uplink and downlink, elapsed time or number of events) per rating group or combination of the rating group and service id within the same
IP-CAN bearer, on encountering that trigger condition. For envelope reporting, the containers represent complete and closed time envelopes determined by mechanisms defined in TS 32.299 [50]. Table 5.2.3.10.2.2 identifies conditions that may be supported as recording triggers under consideration of additional Debit / Reserve Units triggers.

Some of the triggers are non-exclusive (e.g. IP-CAN bearer modification with a couple of reasons, IP-CAN bearer modification reasons that cause PGW-CDR closure).

Table 5.2.3.10.2.1: Triggers for PGW-CDR charging information addition for List of Traffic Volumes when charging per IP-CAN session is active

Trigger Conditions	Description/Behaviour
End of dedicated bearer in P-GW	The end of a dedicated bearer in P-GW shall result that open "List of Traffic Data Volumes" containers for the dedicated bearer are closed and added to the CDR.
Serving node change	A serving node (e.g., SGSN/S-GW/ePDG/TWAG) change in the P-GW shall result that all open "List of Traffic Data Volumes" containers are closed and added to the CDR. New containers are opened for each bearer.
QoS Change	A change in the QoS shall result that open "List of Traffic Data Volumes" containers for the effected bearer being closed and added to the CDR and new IP-CAN bearer specific container is opened if the IP-CAN bearer is still active.
Tariff Time Change	On reaching the Tariff Time Change open "List of Traffic Data Volumes" containers shall be closed and added to the CDR.
User Location Change	A change in the User Location Info (e.g. ECGI, TAI, RAI, SAI or CGI) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR, if location reporting is required, and a report of User Location Change is received.
User CSG Information change	A change in the User CSG info (e.g. CSG ID, access mode or CSG membership indication) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR, if CSG information reporting is required, and a report of User CSG information change is received.
Change of UE presence in Presence Reporting Area	A change of UE presence in Presence Reporting Area(s) shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR, if such reporting is required, and a report that user enters/leaves the area or the Presence Reporting Area(s) is set to inactive by the serving node are received.
Addition of access to a PDN connection	New SGSN/S-GW/ePDG/TWAG address is added to data for the IP-CAN bearer in the CDR.
Removal of access from a multi-access PDN connection	The counters and time stamps for the IP-CAN bearers of the removed access are closed and resulting containers added to CDR
Access of a multi-access PDN connection becomes unusable	The counters and time stamps for the IP-CAN bearers of the unusable access are closed and resulting containers added to the CDR.
Traffic volume report	A "List of Traffic Data Volumes" container for an IP-CAN bearer shall be added when: – expiry of time limit per IP-CAN bearer; – expiry of data volume limit per IP-CAN bearer.
Rate Control Change	A "List of Traffic Data Volumes" container for an IP-CAN bearer shall be added when: – Serving PLMN Rate Control Change – APN Rate Control Change.
CDR Closure	Open "List of Traffic Data Volumes" containers shall be closed and added to the PGW-CDR.

Editor’s Note: The individual events associated with change of charging condition must be re-evaluated in the context of NBIFOM. Changes to this event are FFS.

Table 5.2.3.10.2.2: Triggers for PGW-CDR charging information addition for "List of Service Data" when charging per IP-CAN session is active

Trigger Conditions	Description/Behaviour
IP-CAN bearer modification except QoS change	A change of IP-CAN bearer conditions (e.g. SGSN/S-GW/ePDG/TWAG change, user location change, user CSG information change, change in UE presence in Presence Reporting Area, Serving PLMN Rate Control Change, APN Rate Control Change) shall result in a set of "List of Service Data" containers, i.e. all active service data flow containers, being added to the CDR as described in clause 5.2.1.10.2. In a tight interworking between online and offline charging the specified quota re-authorisation triggers armed by OCS are supported.
Tariff Time Change	On reaching the Tariff Time Change a set of "List of Service Data" containers, i.e. all active service data flow containers, shall be added to the CDR. In a tight interworking between online and offline charging the Debit / Reserve Units tariff time change from OCS is supported.
ASR or Failure Handling procedure triggering	When the Debit / Reserve Unitssession is terminated with ASR or Failure Handling mechanism is triggered a "List of Service Data’”, i.e. all active service data flow containers shall be added to the CDR. The causes are only relevant in case of simultaneously usage of an active Debit / Reserve Units session.
Service data flow report	In case of independent online and offline charging a "List of Service Data" container for the service data flow shall be added when: – expiry of time limit per rating group; – expiry of volume limit per rating group; – expiry of unit or data event limit per rating group; – access change of service data flow and all service data flows for the rating group, combination of rating group and service identifier, or combination of rating group, sponsor identity and application service provider identity are moved from one access to another; – termination of service data flow and this is the last service data flow for the rating group or combination of rating group and service identifier, or combination of rating group, sponsor identity and application service provider identity.
Service data flow report	In case of tight interworking online and offline charging a "List of Service Data" container for the service data flow shall be added when: – time threshold reached; – volume threshold reached; – unit threshold reached; – time quota exhausted; – volume quota exhausted; – unit quota exhausted; – expiry of quota validity time; – access change of service data flow; – termination of service data flow: – re-authorization request by OCS.
CDR Closure	All active "List of Service Data" containers shall be added to the PGW-CDR. Note: The trigger condition is a common value that has to be used for CDR closure together with detailed reason.

Editor’s Note: The individual events associated with change of charging condition must be re-evaluated in the context of NBIFOM. Changes to this event are FFS.

The first traffic container identifies the data traffic since the IP-CAN session was opened.
Subsequent data traffic containers store the configured counts accrued since the closure of the last container.

For envelope reporting, each envelope contains information about the data volume transferred in both uplink and downlink and / or the number of events that occurred for the duration that envelope is open. Only completed time envelopes shall be added to the PGW-CDR. The determination of completed envelopes are defined in TS 32.299 [50]. The triggers listed in the previous table shall not apply to envelope reporting. Envelopes that are not complete when a partial PGW-CDR is closed shall be added to the next PGW-CDR.

The "Serving node Address" attribute of the PGW-CDR consists of a list of SGSN/S-GW/ePDG/TWAG addresses.
New SGSN/S-GW/ePDG/TWAG address is added to the list when SGSN/S-GW/ePDG/TWAG changes.

When Charging Event (ACR) is triggered by table 5.2.3.10.2.1 or 5.2.3.10.2.2 conditions, the Change-Condition sub-field associated to the added container, indicating the appropriate condition, shall be present, excluding CDR Closure case.

When Charging Event (ACR) is triggered by "User CSG Information change" as a Change condition, the following shall apply for the added volume container:

5.2.3.10.3 Triggers for PGW-CDR closure when charging per IP-CAN session charging is active

The PGW-CDR shall be closed on encountering trigger conditions.

Table 5.2.3.10.3.1 identifies which conditions are supported to permit closure of the PGW-CDR.

Table 5.2.3.10.3.1: Triggers for PGW-CDR closure

Closure Conditions

Description/Behaviour

End of IP-CAN session within the P-GW

Deactivation of the IP-CAN session in the P-GW shall result in the CDR being closed. The trigger condition covers:

– termination of last IP-CAN bearer for the IP-CAN session;

– any abnormal release.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– data volume limit per IP-CAN session;

– time (duration) limit for keeping a CDR open;

– data event limit per IP-CAN session;

– maximum number of charging condition changes;

– management intervention;

– APN-AMBR change;

– MS time zone change;

– PLMN change;

– radio access technology change (RAT Type).

In the event that the PGW-CDR is closed and the IP-CAN session remains active, a further PGW-CDR is opened with an incremented Sequence Number in the P-GW.

When Charging Event (ACR) is triggered by table 5.2.3.10.3.1 conditions, the Change-Condition (at PS information level) associated to the CDR Closure, indicating the appropriate condition shall be present, and it shall be omitted otherwise.

5.2.3.11 Triggers for TWAG-CDR charging information collection

5.2.3.11.0 Introduction

A TWAG-CDR is used to collect charging information related to the IP-CAN bearer data information for a UE/MS in the TWAG.

If, according to the Charging Characteristics, CDR generation is activated a TWAG-CDR shall be opened at IP-CAN bearer activation and IP-CAN bearer specific container is opened.

When a change of charging condition occurs, the volume counts are added to the TWAG-CDR and new counts are started. The TWAG-CDR includes details such as Record Type, Served IMSI, Sequence Number etc. Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

The subsequent clauses identify in detail the conditions for adding information to, and closing the TWAG-CDR for generation towards the CGF.

5.2.3.11.1 Triggers for TWAG-CDR charging information addition

The "List of Traffic Data Volumes" attribute of the TWAG-CDR consists of a set of containers, which are added when specific trigger conditions are met, and identify the volume count per Qos, separated for uplink and downlink traffic, on encountering that trigger condition.
Table 5.2.3.11.1.1 identifies which conditions are supported to trigger TWAG-CDR charging information addition.

Table 5.2.3.11.1.1: Triggers for TWAG-CDR charging information addition

Trigger Conditions	Description/Behaviour
QoS Change	A change in the QoS shall result that open "List of Traffic Data Volumes" containers being closed and added to the CDR and new IP-CAN bearer specific container is opened.
Tariff Time Change	On reaching the Tariff Time Change open "List of Traffic Data Volumes" containers shall be closed and added to the CDR.
CDR Closure	Open "List of Traffic Data Volumes" containers shall be closed and added to the TWAG-CDR.

Volume container identifies the uplink/downlink volume since the closure of the last container.

When Charging Event (ACR) is triggered by table 5.2.3.11.1.1 conditions, the Change-Condition sub-field associated to the added volume container, indicating the appropriate condition, shall be present, excluding CDR Closure case.

5.2.3.11.2 Triggers for TWAG-CDR closure

The TWAG-CDR shall be closed on encountering some trigger conditions.
Table 5.2.3.11.2.1 identifies which conditions are supported to permit closure of the TWAG-CDR.

Table 5.2.3.11.2.1: Triggers for TWAG-CDR closure

Closure Conditions

Description/Behaviour

End of IP-CAN bearer within the TWAG

Deactivation of the IP-CAN bearer in the TWAG shall result in the CDR being closed. The trigger condition covers:

– termination of IP-CAN bearer;

– any abnormal release;

– inter serving node change.

Partial Record Reason

OAM&P reasons permit the closure of the CDR for internal reasons.
The trigger condition covers:

– data volume limit;

– time (duration) limit;

– maximum number of charging condition changes (QoS/tariff time change);

– management intervention;

The Partial Record generation trigger thresholds are those associated with the Charging Characteristics.
The Partial Record generation trigger thresholds are TWAG configuration parameters defined per Charging Characteristics profile by the operator through OAM&P means, as specified in annex A.

In the event that the TWAG-CDR is closed and the IP-CAN bearer remains active, a further TWAG-CDR is opened with an incremented Sequence Number in the TWAG.

When Charging Event (ACR) is triggered by table 5.2.3.11.2.1 conditions, the Change-Condition (at PS information level) associated to the CDR Closure, indicating the appropriate condition shall be present, and it shall be omitted otherwise.

5.2.4 Void

5.2.5 Ga record transfer flows

In EPC, both fully qualified partial CDRs (FQPC) and reduced partial CDRs (RPC), as specified in TS 32.240 [1] may be supported on the Ga interface. In line with TS 32.240 [13], the support of FQPCs is mandatory, the support of RPCs is optional. For further details on the Ga protocol application refer to TS 32.295 [54].

5.2.6 Bp CDR file transfer

In EPC, both fully qualified partial CDRs (FQPC) and reduced partial CDRs (RPC), as specified in TS 32.240 [1] may be supported on the Bp interface. In line with TS 32.240 [13], the support of FQPCs is mandatory, the support of RPCs is optional. For further details on the Bp protocol application refer to TS 32.297 [52].

5.3 PS domain online charging scenarios

5.3.1 Basic principles

5.3.1.0 General

PS domain online charging may be performed in the SGSN using CAMEL techniques.
This functionality is specified in TS 23.078 [206] and TS 29.078 [202] and is outside the scope of the present document.

PS domain online charging may be performed by the PCEF in the P-GW and by the TDF using the common Ro based Credit-Control application specified in TS 32.299 [50]. In order to provide the data required for the management activities outlined in TS 32.240 [1] (Credit-Control, accounting, statistics etc.), the PCEF shall be able to perform online charging for each of the following:

– Charging data related to IP-CAN bearers;

– Charging data related to service data flows.

The above items both pertain to sessions (IP-CAN bearers), hence session based online charging (SCUR) with centralized rating and centralized unit determination is required in the PCEF.

The TDF shall be able to perform online charging each of the following:

– Charging data related to TDF session;

– Charging data related to detected application traffic.

The above items pertain to sessions (application traffic), hence SCUR is required in the TDF with centralized or decentralized unit determination and centralized rating.

The Debit / Reserve Units Request and Debit / Reserve Units Response specified for SCUR in TS 32.299 [50] (initial/update/termination) are issued towards the OCS / received from the OCS when certain conditions (chargeable events) are met. The PS domain specific contents and purpose of each of these messages, as well as the chargeable events that trigger them, are described in the following sub-clauses. A detailed formal description of the online charging parameters defined in the present document is to be found in TS 32.299 [50]. Further information on the general principles of the common 3GPP online charging application can also be found in TS 32.299 [50] and TS 32.240 [1].

The Credit-Control is always per rating group but the reporting level can be either per rating group or per combination of the rating group and service id. Reporting level is defined per PCC rule in case of PCEF integrated in the P-GW or per ADC rule in case of TDF.In order to avoid that charging sessions remain inactive for a long period of time, the PCEF or OCS may terminate the online charging session under the condition that no granted quota has been consumed for a certain period of time. The PCEF starts a new online charging session when there is a need for new quota, for the same IP-CAN bearer or IP-CAN session, and the same Charging id as the initial session shall be used.

5.3.1.1 IP-CAN bearer charging

IP-CAN bearer online charging is achieved by FBC online charging, see clause 5.3.1.2. When the IP-CAN bearer is online charged by means of FBC, the quota handling shall also be based on the use of a Rating Group/Service Identifier.
The value of this IP-CAN bearer specific Rating Group/Service Identifier shall be vendor specific.

The amount of data counted with IP-CAN bearer specific Rating Group/Service Identifier shall be based on:

– In case of GTP based tunnelling and nterworking with external IP networks: the inner IP packets in the GTP-U packet (T-PDU, see TS 29.281 [217]).

– In case of GTP based tunnelling and interworking with external networks handling other data services (e.g. non-IP, PPP): the T-PDU packets (see TS 29.281 [217]).

– In case of PMIP based protocol: the payload of the GRE tunnel.

– In case of DSMIPv6 based protocol: the payload of the tunnelling layer.

As minimum behaviour, the full payload shall be included. Time metering is started when IP-CAN bearer is activated.

NOTE 1: P-GW is aware of bearers in case of GTP based connectivity. In case of any other PMIP based connectivity, P-GW is aware of IP-CAN sessions only. If P-GW is not aware of IP-CAN bearers, P-GW collects charging information per IP-CAN session as it would be just one IP-CAN bearer.

NOTE 2: The control plane IP address of SGSN or P-GW (acting as GGSN) is the IP address used at Gn/Gp interface.

The control plane IP address of S-GW or P-GW is the IP address used at S5/S8 interface.
The control plane IP address of ePDG or P-GW is the IP address used at S2b interface.

The control plane IP address of TWAG or P-GW is the IP address used at S2a interface.

5.3.1.2 Flow Based bearer Charging

IP-CAN bearer charging allows the P-GW to collect charging information related to data volumes sent to and received by the UE/MS, categorised by the QoS applied to the IP-CAN bearer. FBC is supported by the P-GW by the integrated PCEF. When the PCEF is present, the normal IP-CAN bearer charging is enhanced by the capability to categorise the service data flows within IP-CAN bearer data traffic by rating group or combination of the rating group and service id. I.e., while there is only one uplink and one downlink data volume count per IP-CAN bearer in IP-CAN bearer charging, FBC may provide one count per each rating group or combination of the rating group and service id. The level of the reporting is defined per PCC rule. Details of this functionality are specified in TS 23.203 [215] and TS 32.240 [1].

NOTE: The P-GW can only include one QoS Information occurrence per Multiple Unit Operation.
This implies if an operator wishes to be able to separate usage according to QCI and ARP within their charging system they will need to ensure that services having different QCI and ARP do not have the same:

– rating group in cases where rating reporting is used;

– rating group/service id where rating group/service id reporting is used.

Extended packet inspection can be done in the PCEF with pre-defined PCC rules. The PCEF also have the possibility to output service specific information related to the packet inspection in the online charging information.

An Application Function (AF) may provide an external charging identifier to be delivered to the PCEF by the PCRF with a dynamic PCC rule. The PCEF includes this AF correlation information in the online charging information for the rating group and service identifier associated with the dynamic PCC rule when service identifier level reporting is requested.

The capability of P-GW to support ABC is achieved with PCRF providing appropriate PCC Rules to the P-GW. Such PCC Rule shall be defined with service data flow template including an Application Identifier for the application which needs to be detected, enforced and charged.

According to TS 23.203 [215], FBC shall support different charging models per PCC rule. These charging models may be based on volume and/or time and on number of events matching a specific service data flow template in PCC rule.
In general the charging of a service data flow shall be linked to the IP-CAN bearer under which the service data flow has been activated. In online charging the PCEF shall request the reservation of units prior to service delivery.

The following chargeable events are defined for FBC when online charging is activated:

– Network request for IP-CAN bearer activation before the Initiate IP-CAN bearer Activation message is sent. Associated with the network requested dedicated IP-CAN bearer activation procedure, as defined in
TS 23.203 [215] and TS 23.060 [201], upon encountering this event, a Debit / Reserve Units Request[Initial], indicating the request for activation of dedicated IP-CAN bearer is sent toward the OCS. For network requested dedicated IP-CAN bearer activation, if known by the PCEF, the PCEF may provide status of UE presence in Presence Reporting Area(s).

– Start of IP-CAN bearer. Upon encountering this event, a Debit / Reserve Units Request[Initial], indicating the start of the IP-CAN bearer, is sent towards the OCS to authorize the IP-CAN bearer. For network requested dedicated IP-CAN bearer activation, this event triggers a Debit / Reserve Units Request[Update], when the PCEF receives an Update PDP Context Request message with the RAN Procedures Ready flag. If known by the PCEF, the PCEF may provide status of UE presence in Presence Reporting Area(s). PCEF may request quota later when service usage is started.

– Start of service data flow. In case valid quota does not exist a Debit / Reserve Units Request[Update] is generated to request quota. In case charging session does not exist, the request is a Debit/ Reserve Units Request[Initial] sent towards the OCS.
The type of requested quota shall depend on measurement method configured for the PCC rule in case of decentralized unit determination. When event based charging applies, the first occurrence of an event matching a service data flow template in PCC rule shall be considered as the start of a service.

– Termination of service data flow. If reporting is per rating group and this is the last service data flow utilizing that specific rating group or if reporting is per combination of the rating group and service id and this is the last service data flow utilizing that specific rating group and service id, the required counters are updated.
Termination of the service data flow itself does not trigger Debit / Reserve Units Request[Update].

— Access of a multi-access PDN connection becomes unusable: the Termination of service data flow chargeable event applies for all the service data flows carried under the IP-CAN bearer of the unusable access.

– Expiry of Unused Quota timer for the charging session in PCEF, a Debit / Reserve Units Request[Terminate] is sent to OCS indicating that charging session is terminated, and the IP-CAN bearer is still active. In this case the OCS shall allow for a new session to be started with the same Charging Id.

– End of IP-CAN bearer. Upon encountering this event, a Debit / Reserve Units Request[Terminate], indicating the end of the IP-CAN bearer, is sent towards the OCS together with the final counts.

– Ro specific chargeable events (e.g. threshold reached, QHT expires, quota exhaustion, validity time reached, forced re-authorization). Corresponding counts for the rating group(s) are closed and Debit / Reserve Units Request[Update] is triggered according the rules defined in TS 32.299 [50].

– Change of charging condition: E.g. QoS change, user location change, user CSG information change, change of UE presence in Presence Reporting Area(s), change of 3GPP PS Data Off status, Serving PLMN Rate Control change, and APN Rate Control change.
When this event is encountered and the corresponding re-authorization trigger is armed, all current counts are captured and sent towards the OCS with a Debit / Reserve Units Request[Update].

– Tariff time change. When this event is encountered, all current counts are captured and a new counts are started. The counts are sent to the OCS in next Debit / Reserve Units Request.

Management intervention may also force trigger a chargeable event.

If the PCEF supports the Unused Quota timer it may send its locally configured value to the OCS. The OCS may in this case respond with a new value of the Unused Quota timer to the PCEF, to be used instead of the PCEF configured value.

According to TS 23.203 [215] , the PCRF can modify the following charging information in a dynamic PCC rule which is active in the PCEF: Charging key, Service identifier, Measurement method, Service identifier level reporting. The PCRF can also modify the allowed access type in the case of NBIFOM.
Change of Charging key, ServiceIdentifier, IP-CAN type, measurement method or allowed access type will trigger a "start of service data flow" chargeable event when valid quota does not exist corresponding to that changed PCC rule. Change of Charging key, Service Identifier, IP-CAN type, measurement method, Service identifier level reporting or allowed access type will trigger a"termination of service data flow’" chargeable event when this is the last service data flow utilizing the quota used for the original PCC rule.

For non-IP type PDN connection in the P-GW:

– non-3GPP access types are not supported, multi-access PDN connections do not apply;

– A single PCC Rule is used with the service data flow descriptor matching the whole non-IP data traffic, and can contain e.g.:

– service data flow template matching all the packets;

– charging method to identify whether online/offline/both/neither charging interface is used;

– measurement method to identify whether time/volume/events are measured for this service data flow;

– Charging key (i.e. rating group) for that service data flow;

– service identifier for that service data flow,

– reporting level for that service data flow:

– rating group level in case a specific rating group is used for non-IP traffic charging.

– combination of the rating group and service id in case a specific rating group/service Id is used for non-IP traffic charging.

5.3.1.3 PS Furnish Charging Information procedure

The OCS online charging function may use this procedure to add online charging session specific information to the PGW‑CDR and to the TDF-CDR. The information can be sent per online session and in case FBC is enabled for a specific APN, or ABC is enabled in case of the TDF, the OCS online charging function may also send specific information per each online charged service by means of this procedure.

5.3.1.4 Support of Failure Situations

In case the OCS fails, the P-GW and the TDF shall support the Failure Handling procedure and Failover mechanism described in TS 32.299 [50]. These mechanisms give flexibility to have different failure handling scenarios when the OCS fails.

Three different actions are described in RFC 4006 [402].

P-GW shall support the following actions when the failure handling mechanism is executed:

– Terminate: The online session is finished. The associated IP-CAN bearer session is released (ongoing sessions) or not established (new sessions). Failover for ongoing sessions is not supported. Failover for new sessions is always supported.

– Retry&Terminate: The online session is finished. The associated IP-CAN bearer session is released (ongoing sessions) or not established (new sessions). Failover for ongoing sessions is supported. Failover for new sessions is always supported.

TDF shall support the following actions when the failure handling mechanism is based on the directives received previously from the OCS:

– Terminate: This is the default behaviour. The TDF indicates to the PCRF that the charging session was terminated and the OCS does not allow the service to continue. The PCRF determines whether to continue or terminate the associated TDF session.

– Retry&Terminate: If the OCS and TDF support failover procedures and there is an alternate OCS available , the TDF shall attempt to failover to an alternative OCS. Otherwise, the TDF indicates to the PCRF that the charging session was terminated and the OCS does not allow the service to continue. The PCRF determines whether to continue or terminate the associated TDF session.

– Continue: If the OCS and TDF support failover procedures and there is an alternate OCS available , the TDF shall attempt to failover to an alternative OCS. Otherwise, the TDF indicates to the PCRF that the charging session was terminated and the OCS allows the service to continue. The PCRF determines whether to continue or terminate the associated TDF session.

If the user is simultaneously online and offline charged, the failure situation shall be registered in the PGW-CDR/TDF-CDR. When the user is only online charged, the execution of the Failure Handling mechanism with value equal to Continue shall imply that a new PGW-CDR/TDF-CDR is opened.

5.3.1.5 Application Based Charging (ABC)

5.3.1.5.0 Introduction

For the sub-clauses that follow, a single Debit / Reserve Units session is defined to handle both TDF session and application based charging information when both are to be used. Either TDF session charging or ABC but not both may be active as determined by Charging Characteristics.

For ABC the opening and closing of the Debit / Reserve Units session is bound by the TDF session start and end respectively.

5.3.1.5.1 Charging per application

ABC allows collecting charging information related to data volumes sent to and received by the UE/MS, based on the application detection. ABC supported by the TDF, i.e. ADC rules based charging defined in TS 23.203 [215] and TS 29.212 [216], is based on ADC rules. The application traffic within TDF session is categorised by rating group or combination of the rating group and service identifier. The level of the reporting is defined per ADC rule. Details of this functionality are specified in TS 23.203 [215] and TS 32.240 [1].

According to TS 23.203 [215], ABC shall support different charging models per ADC rule. These charging models may be based on volume and/or time or on number of events as the application referred by either application identifier or service data flow filters to identify the packets belonging to an application in ADC rule. In online charging the TDF shall request the reservation of units prior to service delivery.

The following chargeable events are defined for ABC when online charging is activated:

– Start of TDF session. Upon encountering this event, a Debit / Reserve Units Request[Initial] indicating the establishment of the TDF session, is sent towards the OCS to activate the online charging session with the TDF. The quota for each activated ADC rule may be requested in such Debit / Reserve Units Request[Initial] or later when application traffic is detected .

– Start of application traffic. In case valid quota does not exist for the rating group, a Debit / Reserve Units Request[Update] is generated to request quota. The type of requested quota shall depend on measurement method configured for the ADC rule in case of decentralized unit determination. When event based charging applies, the first occurrence of an event detected according to the pre-defined ADC rule shall be considered as the start of a application.

– Termination of application traffic. If reporting is per rating group and this is the last application traffic utilizing that specific rating group or if reporting is per combination of the rating group and service identifier and this is the last application traffic utilizing that specific rating group and service identifier, the required counters are updated.

– End of TDF session in the TDF. Upon encountering this event, a Debit / Reserve Units Request[Terminate], indicating the end of the TDF session, is sent towards the OCS together with the final counts.

– Change of charging condition: e.g. user location change, user CSG information change. When this event is encountered and the corresponding re-authorization trigger is armed, all current counts are captured and sent towards the OCS with a Debit / Reserve Units Request[Update].

– Tariff time change. When this event is encountered, all current counts are captured and a new counts are started. The counts are sent to the OCS in next Debit / Reserve Units Request.

Management intervention may also force trigger a chargeable event.

ADC rules can be activated, deactivated and modified any time during the TDF session lifetime. ADC rules activation, deactivation and modification are not chargeable events. However these ADC rules changes may lead to "start of application traffic’" and "termination of application traffic’" chargeable events.

Application Detection and Control rule can contain e.g.:

– Application Identifier to identify detected application or service data flow filters to identify the packets belonging to an application,

– charging method to identify whether online/offline/both/neither charging interface is used,

– measurement method for online/offline charging to identify whether time/volume/events are measured for this application,

– Charging key (i.e. rating group) for that application,

– service identifier for that application,

– reporting level for the application (rating group or combination of the rating group and service id),

– precedence to the situations where two or more ADC rules are overlapping.

Application Detection and Control rule can be:

pre-defined in TDF (can be activated by the PCRF) or,
dynamically provisioned and activated by the PCRF over the Sd interface.

This is specified in TS 23.203 [215] and TS 29.212 [216].

According to TS 23.203 [215] , the PCRF can modify the following charging information in a dynamic ADC rule which is active in the TDF: Charging key, Service identifier, Measurement method, Service identifier level reporting. Change of Charging key, Service Identifier, or measurement method will trigger a "start of application traffic’" chargeable event when valid quota does not exist. Change of Charging key, Service Identifier or measurement method, or Service identifier level reporting will trigger a"termination of application traffic’" chargeable event when this is the last application traffic utilizing the quota used for the Charging key or combination of Charging key and Service identifier of original ADC rule.

5.3.1.5.2 Charging per TDF session

TDF session online charging is achieved by ABC online charging such that the quota handling for the TDF session shall be based on associating a specific Rating Group/Service Identifier with the TDF session . The value of this TDF session specific Rating Group/Service Identifier shall be vendor specific.

The amount of data counted with TDF session specific Rating Group/Service Identifier shall be the user plane payload. Time metering is started when TDF session is activated.

5.3.1.6 Charging per IP-CAN session

5.3.1.6.0 General

Charging per IP-CAN session is an optional capability in the P-GW that provides for a consolidated view of the service data flow charging information across all bearers in the IP-CAN session. When charging per IP-CAN session is active, the basic principles in this clause apply to the P-GW instead of the principles in clause 5.3.1.1 and clause 5.3.1.2 above.

For the sub-clauses that follow, a single Debit / Reserve Units session is defined to handle both types of charging information when both are to be used. When Charging per IP-CAN session is active, either IP-CAN bearer charging or FBC but not both may be active as determined by Charging Characteristics.

5.3.1.6.1 IP-CAN bearer charging

IP-CAN bearer online charging is achieved by FBC online charging, see clause 5.3.1.6.2. When the IP-CAN session is online charged by means of FBC, the quota handling shall also be based on the use of a Rating Group. The value of this IP-CAN bearer specific Rating Group or combination of the Rating Group and Service Identifier shall be vendor specific.

The amount of data counted with IP-CAN bearer specific Rating Group/Service Identifier shall be based on:

– In case of GTP based tunnelling and interworking with external IP networks: the inner IP packets in the GTP-U packet (T-PDU, see TS 29.281 [217])

– In case of GTP based tunnelling and interworking with external networks handling other data services (e.g. non-IP, PPP): the T-PDU packets (see TS 29.281 [217])

– In case of PMIP based protocol: the payload of the GRE tunnel

– In case of DSMIPv6 based protocol: the payload of the tunnelling layer

As minimum behaviour, the full payload shall be included. Time metering is started when IP-CAN session is activated.
All bearers in the IP-CAN session are included in the single vendor-specific Rating Group/Service Identifier.

NOTE 2: The control plane IP address of SGSN or P-GW (acting as GGSN) is the IP address used at Gn/Gp interface.
The control plane IP address of S-GW or P-GW is the IP address used at S5/S8 interface.
The control plane IP address of ePDG or P-GW is the IP address used at S2b interface.
The control plane IP address of TWAG or P-GW is the IP address used at S2a interface.

NOTE 3: The vendor-specific Rating Group/Service Identifier may be configurable through the use of a predefined PCC rule in the P-GW.

5.3.1.6.2 Flow Based Charging (FBC)

FBC is supported by the P-GW by the integration of a PCEF. With PCEF, charging is enhanced by the capability to categorise the service data flows within IP-CAN session data traffic by rating group or combination of the rating group and service id. For online charging, FBC provides credit management for each rating group and may provide reporting (i.e., counts) per each rating group or combination of the rating group and service id. The level of the reporting is defined per PCC rule. Details of this functionality are specified in TS 23.203 [215] and TS 32.240 [1].

NOTE 1: Even though an individual service data flow template is bound to a specific IP-CAN bearer, the assigned rating group or combination of rating group and service id applies to the entire IP-CAN session.
As a result, data traffic from multiple bearers can be included in the count maintained for the rating group or combination of the rating group and service id. This implies if an operator wishes to be able to separate usage according to IP-CAN bearer within their charging system they will need to ensure that services having different QCI and ARP do not have the same:

– rating group in cases where rating group reporting is used;

– rating group/service id where rating group/service id reporting is used.

NOTE 2: The P-GW can only include one QoS Information occurrence per Multiple Unit Operation.
This implies if an operator wishes to be able to separate usage according to QCI and ARP within their charging system they will need to ensure that services having different QCI and ARP do not have the same:

– rating group in cases where rating group reporting is used;

– rating group/service id where rating group/service id reporting is used.

– rating group in cases where rating group reporting is used;

– rating group/service id where rating group/service id reporting is used.

According to TS 23.203 [215], FBC shall support different charging models per PCC rule. These charging models may be based on volume and/or time and on number of events matching a specific service data flow template in PCC rule.
In online charging the PCEF shall request the reservation of units prior to service delivery.

The following chargeable events are defined for FBC when online charging and Charging per IP-CAN session is activated:

– Start of IP-CAN session. Upon encountering this event, a Debit / Reserve Units Request[Initial], indicating the start of the IP-CAN session, is sent towards the OCS to authorize the IP-CAN session. PCEF may request quota later when service usage is started.

– Start of service data flow. If no valid quota has been granted for the rating group, a Debit / Reserve UnitsRequest[Update] is generated to request quota. In case charging session does not exist, the request is a Debit / Reserve Units Request[Initial] sent towards the OCS. The type of requested quota shall depend on measurement method configured for the PCC rule in case of decentralized unit determination. When event based charging applies, the first occurrence of an event matching a service data flow template in PCC rule shall be considered as the start of a service.

– Termination of service data flow. If reporting is per rating group and this is the last service data flow utilizing that specific rating group or if reporting is per combination of the rating group and service id and this is the last service data flow utilizing that specific rating group and service id, the required counters are updated. Termination of the service data flow itself does not trigger Debit / Reserve Units Request[Update].

– End of IP-CAN session. Upon encountering this event, a Debit / Reserve Units Request[Terminate], indicating the end of the IP-CAN session, is sent towards the OCS together with the final counts.

– Change of charging condition specific to APN-AMBR change: When this event is encountered and the corresponding re-authorization trigger is armed, all current counts are captured and sent towards the OCS with a Debit / Reserve Units Request[Update].

– Change of charging condition other than QoS change: E.g. user location change, user CSG information change, change of UE presence in Presence Reporting Area(s) , change of 3GPP PS DataOff status, Serving PLMN Rate Control change, APN Rate Control Change. When this event is encountered and the corresponding re-authorization trigger is armed, all current counts are captured and sent towards the OCS with a Debit / Reserve Units Request[Update].
Change of charging condition other than QoS change events are associated with one access of a multi-access PDN connection and all counts associated with affected access are identified with the specific event. All counts associated with the other access of a multi-access PDN connection are identified as an indirect change of charging condition.

– Tariff time change. When this event is encountered, all current counts are captured and new counts are started.
The counts are sent to the OCS in next Debit / Reserve Units Request.

Management intervention may also force trigger a chargeable event.

PCC rules can be activated, deactivated and modified any time during the IP-CAN session lifetime. PCC rule activation, deactivation and modification are not chargeable events. However these PCC rule changes may lead to "start of service data flow’" and "termination of service data flow’" chargeable events.

According to TS 23.203 [215], the PCRF can modify the following charging information in a dynamic PCC rule which is active in the PCEF: Charging key, Service identifier, Measurement method, Service identifier level reporting. The PCRF can also modify the allowed access type in the case of NBIFOM.
A change of allowed access type in the case of NBIFOM will trigger an "access change for service data flow" chargeable event when all service data flows for the associated counter are changed from one access to another and takes priority over change of charging information.
Change of Charging key, ServiceIdentifier, IP-CAN type or measurement method will trigger a "start of service data flow’" chargeable event when valid quota does not exist corresponding to that changed PCC rule. Change of Charging key, Service Identifier, IP-CAN type or measurement method, or Service identifier level reporting will trigger a "termination of service data flow" chargeable event when this is the last service data flow utilizing the quota used for the original PCC rule.

For non-IP type PDN connection:

– non-3GPP access types are not supported;

– multi-access PDN connections do not apply;

– A single PCC Rule is used with the service data flow descriptor matching the whole non-IP data traffic, and can contain e.g.:

– service data flow template matching all the packets;

– charging method to identify whether online/offline/both/neither charging interface is used;

– measurement method for offline charging to identify whether time/data volume/events are measured for this service data flow;

– Charging key (i.e. rating group) for that service data flow;

– service identifier for that service data flow;

– reporting level for that service data flow:

– rating group level in case a specific rating group is used for non-IP traffic charging;

– combination of the rating group and service id in case a specific rating group/service Id is used for non-IP traffic charging.

5.3.1.7 Sponsored data connectivity charging

In the first scenario, the PCRF assigns a service specific Charging Key (i.e. rating group) for a sponsored IP flow. The Charging Key is used by the PCEF to collect charging information for online charging scenarios for the sponsored flows on which the quota allocation in OCS shall be based. Correlation of charging information for online charging from multiple users per sponsor and/or application service provider is then performed using the Charging Key.

The second scenario utilizing explicit reporting of the Sponsor Identity and Application Service Provider Identity for online charging from PCEF has not been specified in this release of the specification.

5.3.1.8 Network-Based IP Flow Mobility (NBIFOM) charging

For a multi-access PDN connection, IP-CAN bearer charging as defined in clause 5.3.1.1 and FBC as defined in clause 5.3.1.2 apply for each bearer under each access for this PDN connection, and IP-CAN bearer charging as defined in clause 5.3.1.6.1 and FBC as defined in clause 6.3.1.6.2 apply when charging per IP-CAN session is active for this PDN connection, based on:

– Release of a multi-access PDN connection and removal of an access from a multi-access PDN connection result in release of all the IP-CAN bearer(s) for this access.

For the case where dynamic PCC is not deployed, per-access Charging Characteristics and pre-defined PCC Rule(s) in
P-GW may be used as a way to apply charging differentiation.

5.3.1.9 Volume Based Charging for VoLTE

Volume based charging for VoLTE services allows the P-GW to collect charging information for VoLTE service. This functionality is supported by the P-GW by the integration of a PCEF. In the P-GW, FBC (as described in clause 5.3.1.2) applies to the VoLTE service data flows. Details of this functionality are specified in TS 23.203 [215].

NOTE: Some VoLTE service specific charging information include in P-GW online charging: caller information, callee information, and status of VoLTE service delivery.

5.3.2 Ro message flows

5.3.2.0 General

Debit / Reserve Units Request[Initial], update and termination, as defined in TS 32.299 [50], are used by the P-GW/TDF to transfer the collected charging information towards the OCS. Debit / Reserve Units Response is used by the OCS to assign quotas for the rating groups, and to instruct the P-GW whether to continue or terminate a service data flow(s) or IP-CAN bearer. Debit / Reserve Units Response is used by the OCS to assign quotas for the rating groups and to instruct the TDF whether to continue or terminate an application’s traffic.

Debit / Reserve Units Response is also used to communicate to the PCEF/TDF for the Termination Action, i.e. the P-GW/TDF behaviour when the user has consumed the final granted units. The Termination Action is specified in TS 32.299 [50].

The P-GW and TDF uses Charging Characteristics profile to determine whether to activate or deactivate online charging. Further details of this functionality, including the mechanism of conveying the Charging Characteristics data item (HLR -> SGSN -> P-GW, or HSS->MME/S4-SGSN ->S-GW->P-GW, AAA -> ePDG -> P-GW, or AAA -> TWAG -> P-GW and then in case of TDF, P-GW -> PCRF -> TDF), are specified in annex A.

The following clauses describe the trigger conditions for the chargeable events described in clauses 5.3.1.1, 5.3.1.2, 5.3.1.5 and 5.3.1.6. In FBC and ABC online charging, these chargeable events correspond to the triggers for collection of charging information and Debit / Reserve Units Request emission towards the OCS.
The responses from the OCS and the detailed behaviour of the PCEF/TDF upon receiving those responses are also specified in the sub-clauses below.

5.3.2.1 Triggers for IP-CAN bearer online charging

IP-CAN bearer online charging is achieved by FBC online charging, see clause 5.3.2.2 below.

5.3.2.1.1 Void

5.3.2.1.2 Void

5.3.2.2 Triggers for FBC online charging

5.3.2.2.0 Introduction

Debit / Reserve Units Request[Initial] / [Update] / [Termination] is used to convey charging information related to the IP-CAN bearer and service data flows collected in the PCEF. Debit / Reserve Units Response is used by the OCS to return quotas for rating groups or to instruct the PCEF on the further handling of the IP-CAN bearer (terminate, continue, reroute, etc.). The Debit / Reserve Units Request includes details such as Credit-Control Type, Served IMSI, Sequence Number etc. The Debit / Reserve Units Response includes details such as Credit-Control quotas and session management instructions (continue, terminate, interim interval, etc). Not all of the charging information to be collected is static, and other charging information is directly dependent on dynamic Packet-Switched service usage.

FBC online charging is employed if it is activated for the IP-CAN bearer. The charging method in the PCC rule defines whether service data flow requires the online charging. The PCEF shall request the quota prior to service delivery.
If only certain quotas are authorised by the OCS (e.g. due to insufficient credit), the rating groups for which no quota was authorised are handled according the received Result Code value. The quota supervision mechanism is further described in TS 32.299 [50]. Details on FBC can be found in TS 23.203 [215] and TS 29.212 [216].

Debit / Reserve Units Request[Initial] is sent to the OCS during the IP-CAN bearer activation. The OCS supplies a IP-CAN bearer authorisation and may supply volume, time or events quotas for the rating groups, based on the information provided by the PCEF, e.g. QoS, APN.

When start of the service data flow is detected and no valid quota exist, a Debit / Reserve Units Request[Update] is sent to request quota for the rating group, unless the rating group is e.g. blacklisted. In case charging session does not exist, a Debit/Reserve Units Request[Initial] is sent. See TS 32.299 [50] for further information.

When a change of charging condition occurs, and corresponding re-authorization trigger is armed, all MSCC instances are reported to the OCS with a Debit / Reserve Units Request[Update] with Reporting-Reason AVP value set to RATING_CONDITION_CHANGE together with Trigger-Type AVP indicating the accurate reason for the change.
When "User CSG Information change" occurs as a change of charging condition, how the changes (i.e. User entering/leaving a CSG cell or a hybrid cell he is member or not) are reported is further detailed in TS 32.299 [50].

At IP-CAN default bearer establishment, the OCS may provide the "Presence Reporting Area identifier" to be activated for Core Network pre-configured Presence Reporting Area(s) and additionally all of PRA Identifier(s) and list(s) of its elements for UE-dedicated Presence Reporting Area(s) to be reported when it subscribes to "Change of UE presence in Presence Reporting Area". The Presence Reporting Area(s) to be reported are applicable at IP-CAN session level.

The OCS may change (activate/modify/remove) the Presence Reporting Area(s) to be reported by providing the updated PRA Identifier(s) to PCEF during any IP-CAN dedicated bearer establishment or during any IP-CAN bearer update.

The OCS may subscribe/unsubscribe to "Change of UE presence in Presence Reporting Area" re-authorization event trigger, during IP-CAN bearer establishment (i.e. CCA answer to CCR initial), or during the lifetime of the IP-CAN bearer. When the initial UE presence status in PRA(s) resulting from subscription by the OCS is received by the PCEF, and the PCEF has previously requested quota, all MSCC instances are reported to the OCS with a CCR update, indicating this initial status. If PCEF has not previously requested quota, this initial status of UE presence in Presence Reporting Area(s) will be sent towards the OCS on CCR update triggered for quota request when service usage is started.

When Ro specific chargeable event (e.g. threshold reached, QHT expires, quota exhaustion, validity time reached, forced re-authorization) occurs required MSCC instances are reported to OCS with a Debit / Reserve Units Request[Update] with corresponding Reporting Reason value. See TS 32.299 [50] for further information.

When tariff time change is encountered, the Tariff Change Usage is used within the Used Service Units to distinguish usage before and after the tariff time change. The MSCC instances are sent to the OCS in next Debit / Reserve Units Request.

The OCS may specify the behaviour on consumption of the final granted units known as termination action.
The required termination action is indicated with Final Unit Action and possible values are TERMINATE and REDIRECT. See TS 32.299 [50] for further information.

TS 23.203 [215] specifies that it shall be possible to request online charging quotas for each charging key.
Each quota allocated to a Debit / Reserve Units session has a unique Rating Group value. TS 23.203 [215] also specifies that PCEF shall report charging information for each combination of the charging key and service identifier when service identifier level reporting is present. As defined in TS 23.203 [215] the service identifier is a piece of information which provides the most detailed identification, specified for FBC, of a service data flow.
The charging key is a piece of information used for rating purposes as defined in TS 23.203 [215].
The charging key and Service Identifier are mapped into the Rating Group and the Service Identifier respectively as defined in RFC 4006 [402].

The subsequent clauses identify in detail the conditions for reporting online charging information, management of user and Credit-Control sessions and PS domain quota supervision.

5.3.2.2.1 Triggers for starting and stopping an FBC Credit-Control session

Debit / Reserve Units Request[Initial] is sent to OCS when:

– IP-CAN bearer is activated. For network requested dedicated IP-CAN bearer activation, the Debit / Reserve Units Request[Initial] is sent to the OCS when the PCEF determines a need for the IP-CAN bearer and before any signalling towards a mobile is initiated.

– Start of service data flow is detected and no charging session exists.

Debit / Reserve Units Request[Terminate] is sent to OCS when:

– IP-CAN bearer is deactivated.

– Unused Quota timer expiry.

– Session termination is indicated by the OCS (e.g. Credit Limit Reached, Credit Control Not Applicable)

– Abort-Session-Request is received from the OCS, this also results in network initiated IP-CAN bearer deactivation.

– A Debit / Reserve Units Request[Terminate] sent due to Unused Quota timer expiry shall include an indication to the OCS that the IP-CAN bearer continues and the OCS can expect a later Debit / Reserve Units Request[Initial] request for the same IP-CAN bearer.

5.3.2.2.2 Triggers for providing interim information for an FBC Credit-Control session

Debit / Reserve Units Request[Update] is sent to OCS when:

– User starts to use certain service or application

– Start of service data flow (refer to clause 5.3.1.2)

– Termination of service data flow and this is the last service data flow utilizing corresponding to report level(refer to clause 5.3.1.2)

– Active service or application is removed from the allowed services or applications

– Granted quota runs out

– Validity time for granted quota expires

– Update is requested by the OCS

– Change of charging conditions occur and according re-authorisation trigger re-authorisation is needed

– Management intervention

– Quota Holding Timer is expired

– For network requested dedicated IP-CAN bearer activation, reception of an Update PDP Context Request message with the RAN Procedures Ready flag.

5.3.2.2A Triggers for ABC online charging

5.3.2.2A.0 Introduction

For ABC supported within the TDF, i.e. ADC rules based charging defined in TS 23.203 [215] and TS 29.212 [216], Debit / Reserve Units Request[Initial] / update / termination is used to convey charging information related to the application traffic detected in the TDF. Debit / Reserve Units Response is used by the OCS to return quotas for rating groups or to instruct the TDF on the further handling of the application traffic (terminate, continue, reroute, etc.). The Debit / Reserve Units Request includes details such as Credit-Control Type, Served IMSI and Sequence Number etc. The Debit / Reserve Units Response includes details such as Credit-Control quotas and session management instructions (continue, terminate, interim interval, etc).

ABC online charging is employed if it is activated for the TDF session defined in TS 23.203[215].
The charging method in the ADC rule defines whether application traffic requires online charging. The TDF shall request the quota prior to service delivery. If only certain quotas are authorised by the OCS (e.g. due to insufficient credit), the rating groups for which no quota was authorised are handled according the received Result Code value. The quota supervision mechanism is further described in TS 32.299 [50].

Debit / Reserve Units Request[Initial] is sent to the OCS during the TDF session activation. The OCS supplies application traffic authorisation and may supply volume, time or event quotas for the rating groups, based on the information provided by the TDF, e.g. APN.

When start of the application traffic is detected and no valid quota exist in current Ro session, a Debit / Reserve Units Request[Update] is sent to request quota for the rating group unless the rating group is e.g. blacklisted. See TS 32.299 [50] for further information.

When a change of charging condition occurs and corresponding re-authorization trigger is armed, all MSCC instances are reported to the OCS with a Debit / Reserve Units Request[Update] with Reporting Reason value set to RATING_CONDITION_CHANGE together with Trigger-Type AVP indicating the accurate reason for the change.
When "User CSG Information change" occurs as a change of charging condition, how the changes (i.e. User entering/leaving a CSG cell or a hybrid cell he is member or not) are reported is further detailed in TS 32.299 [50].

When Ro specific chargeable event (e.g. threshold reached, QHT expires, quota exhaustion, validity time reached, forced re-authorization) occurs required MSCC instances are reported to OCS with a Debit / Reserve Units Request[Update] with corresponding Reporting-Reason AVP value. See TS 32.299 [50] for further information.

The OCS may specify the behaviour on consumption of the final granted units known as termination action. The required termination action is indicated with Final Unit Action and possible values are TERMINATE and REDIRECT.
See TS 32.299 [50] for further information.

TS 23.203 [215] specifies that it shall be possible to request online charging quotas for each charging key. Each quota allocated to a Debit / Reserve Units session has a unique Rating Group value. TS 23.203 [215] also specifies that TDF shall report charging information for each combination of the charging key and service identifier when service identifier level reporting is present. As defined in TS 23.203 [215] the service identifier is a piece of information which provides the most detailed identification, specified for ABC. The charging key is a piece of information used for rating purposes as defined in TS 23.203 [215]. The charging key and Service Identifier are mapped into the Rating Group and the Service Identifier respectively as defined in RFC 4006 [402].

The subsequent clauses identify in detail the conditions for reporting online charging information, management of user and Credit-Control sessions and PS domain quota supervision.

5.3.2.2A.1 Triggers for starting and stopping an ABC Credit-Control session

Debit / Reserve Units Request[Initial] is sent to OCS when TDF session is activated.

Debit / Reserve Units Request[Terminate] is sent to OCS when:

– TDF session is deactivated

– Session termination is indicated by the OCS (e.g. Credit Limit Reached)

– Abort-Session-Request is received from the OCS.

5.3.2.2A.2 Triggers for providing interim information for an ABC Credit-Control session

Debit / Reserve Units Request[Update] is sent to OCS when:

– Start of application traffic, when no valid quota exists

– Granted quota runs out

– Validity time for granted quota expires

– Update is requested by the OCS

– Change of charging conditions occur and according re-authorisation trigger re-authorisation is needed

– Management intervention

– Quota Holding Timer is expired

5.3.2.2B Triggers for TDF session online charging

TDF session online charging is achieved by ABC online charging, see clause 5.3.2.2A.

5.3.2.2C Triggers for P-GW when charging per IP-CAN session is active

5.3.2.2C.1 General

The triggers identified in clause 5.3.2.2 are utilized when charging per IP-CAN session is active with the following changes:

1. When IP-CAN bearer charging is active, the Debit / Reserve Units Response is used by the OCS to return quotas for rating groups or to instruct the PCEF on the further handling of the IP-CAN session or service data flow, not a specific IP-CAN bearer.

2. Charging per IP-CAN session is employed if it is activated for the default IP-CAN bearer. Charging characteristics determine if the IP-CAN bearer charging is active or if the FBC is active. When IP-CAN bearer charging is active, a vendor-specific rating group and, optionally, service identifier, is used to signify that the IP-CAN session traffic is being monitored as per clause 5.3.1.6.1. This vendor-specific rating group is the only rating for which quota is requested from the OCS using the same mechanism as for FBC. When FBC is active, the charging method in the PCC rule defines whether a service data flow requires online charging.

3. In either case in which FBC is utilized, the PCEF shall request the quota prior to service delivery as in clause 5.3.2.2.

4. Debit / Reserve Units Request[Initial] is sent to the OCS during the IP-CAN session activation. No indication is provided to the OCS when an individual IP-CAN bearer is activated.

5. When IP-CAN bearer charging using the vendor-specific rating group, the OCS may only provide volume quotas.

6. At IP-CAN session establishment, the OCS may provide the "Presence Reporting Area identifier(s)" to be activated for Core Network pre-configured Presence Reporting Area(s) and additionally all of PRA Identifier(s) and list(s) of its elements for UE-dedicated Presence Reporting Area(s) to be reported when it subscribes to "Change of UE presence in Presence Reporting Area". OCS subscription to and PCEF reporting of "Change of UE presence in Presence Reporting Area" re-authorization event trigger is the same as in clause 5.3.2.2.

7. When start of the IP-CAN session traffic (if IP-CAN bearer charging is active) or the service data flow is detected and no valid quota exists, a Debit / Reserve Units Request[Update] is sent to request quota for the rating group as in clause 5.3.2.2C.3.

5.3.2.2C.2 Triggers for starting and stopping an FBC Credit-Control session when charging per IP-CAN session is active

Debit / Reserve Units Request[Initial] is sent to OCS when:

– IP-CAN session (i.e., default bearer) is activated.

– Start of service data flow is detected and no charging session exists.

Debit / Reserve Units Request[Terminate] is sent to OCS when:

– IP-CAN session is deactivated.

– Unused Quota timer expiry.

– Session termination is indicated by the OCS (e.g. Credit Limit Reached, Credit Control Not Applicable)

– Abort-Session-Request is received from the OCS, this also results in network-initiated IP-CAN session deactivation.

A Debit / Reserve Units Request[Terminate] sent due to Unused Quota timer expiry shall include an indication to the OCS that the IP-CAN session continues and the OCS can expect a later Debit / Reserve Units Request[Initial] request for the same IP-CAN session.

5.3.2.2C.3 Triggers for providing interim information for an FBC Credit-Control session when charging per IP-CAN session is active

Debit / Reserve Units Request[Update] is sent to OCS when:

– User starts to use certain service

– Start of service data flow (refer to 5.3.1.2)

– Access change of service data flow (refer to 5.3.1.6.2)

– Active service is removed from the allowed services

– Granted quota runs out

– Validity time for granted quota expires

– Update is requested by the OCS

– Change of charging conditions occur and re-authorisation trigger is set

– Management intervention

– Quota Holding Timer is expired

5.3.2.3 PS Furnish Charging Information procedure

The OCS online charging function may use this procedure to add online charging session specific information to the PGW-CDR/TDF-CDR by means of the Debit / Reserve Units operation in the Ro interface. The data can be sent either in one Debit / Reserve Units Response message or several Debit / Reserve Units Response messages with append indicator.

The OCS online charging function can send multiple concatenated PS Furnish Charging Information elements per online charging session in the Ro interface. The OCS online charging function can also send multiple concatenated PS Furnish Information Element per each quota (i.e. per rating group).

The total maximum of free format data is 160 octets per service so the total maximum of free format data per online session is n*160 octets, where n indicates the number of rating groups activated per online session.

In the OCS online charging function, a PS online charging session shall be identified by the P-GW control plane address and the ChargingId. In the P-GW, the PS online charging session and the PS offline charging session shall be identified by the same ChargingId. Therefore the ChargingId shall allow the P-GW to correlate an online charging session with an offline charging session. In the TDF, the PS online charging session and the PS offline charging session shall be identified by the combination of P-GW control plane address and ChargingId. Therefore the P-GW address/Charging Id shall allow the TDF to correlate an online charging session with an offline charging session.

This procedure can only apply when online and offline charging is performed simultaneously for the same session (IP-CAN bearer or TDF session) or rating group. In any other case, the P-GW/TDF shall discard the additional charging information sent by the OCS in the Debit / Reserve Units Response messages.

When the OCS sends session specific charging information, it must send the PS Furnish Charging Information at command level in the Debit / Reserve Units Response. In this case, the information is added to the main body of the PGW-CDR. When the OCS sends service specific charging information, it must send the PS Furnish Charging Information at MSCC level in the Debit / Reserve Units Response. In this case, the information is added to the specific service container in the PGW-CDR/TDF-CDR.

The PS Furnish Charging Information is described in TS 32.299 [50].

5.3.2.4 Support of Failure Situations

In case the OCS fails the P-GW/TDF must support the Failure Handling procedure and Failover mechanism described in TS 32.299 [50].

The Failure Handling Procedure affects the whole online session so in case FBC/ABC is enabled, the procedure shall affect all services activated during the IP-CAN bearer/TDF session triggering the online charging session.

According to TS 32.299 [50], timer Tx determines the maximum interval the P-GW/TDF shall wait for an answer to each Debit / Reserve Units Request sent to the OCS. In case FBC/ABC is enabled, it is possible that several concurrent Debit / Reserve Units Request messages are triggered for the same online charging session. In this case, each Debit / Reserve Units Request message shall reset the Tx timer. When Tx expires, P-GW/TDF shall execute the Failover and Failure Handling mechanisms according to the behaviour described in Annex B.

Three different actions are described in RFC 4006 [402].

P-GW shall support the following actions when the failure handling mechanism is executed:

– Continue: The online session is finished. The associated IP-CAN bearer session is established (new sessions) or not released (ongoing sessions). Failover for ongoing sessions is supported. Failover for new sessions is always supported. It shall be operator configurable to limit the maximum duration of the IP-CAN bearer in this situation.

When charging per IP-CAN session is active, the actions above apply to the entire IP-CAN session instead of the individual IP-CAN bearer.

TDF shall support the following actions when the failure handling mechanism is based on the directives received previously from the OCS:

– Retry&Terminate: If the OCS and TDF support failover procedures and there is an alternate OCS available, the TDF shall attempt to failover to an alternative OCS. Otherwise, the TDF indicates to the PCRF that the charging session was terminated and the OCS does not allow the service to continue. The PCRF determines whether to continue or terminate the associated TDF session.

– Continue: If the OCS and TDF support failover procedures and there is an alternate OCS available, the TDF shall attempt to failover to an alternative OCS. Otherwise, the TDF indicates to the PCRF that the charging session was terminated and the OCS allows the service to continue. The PCRF determines whether to continue or terminate the associated TDF session.

In case the user is simultaneously online and offline charged, the failure situation must be registered in the PGW-CDR/TDF-CDR. When the user is only online charged, the execution of the Failure Handling mechanism with value equal to Continue shall imply that a new PGW-CDR/TDF-CDR is opened.