The PCC architecture works on a service data flow level. The PCC architecture provides the functions for policy and charging control as well as event reporting for service data flows.

Reporting refers to the differentiated IP-CAN resource usage information (measured at the PCEF/TDF) being reported to the online or offline charging functions. The PCEF/TDF shall report usage information for online and offline charging. The PCEF/TDF shall report usage information for each charging key value. For service data flow charging, for the case of sponsored data connectivity, the reports for offline charging shall report usage for each charging key, Sponsor Identity and Application Service Provider Identity combination if Sponsor Identity and Application Service Provider Identifier have been provided in the PCC rules. The PCEF shall report usage information for each charging key/service identifier combination if service identifier level reporting is requested in the PCC/ADC rule. The TDF shall report usage information for each charging key/service identifier combination if service identifier level reporting is requested in the ADC rule. For the case where the BBF locates in the PCEF, charging information shall be reported based on the result from the service data flow detection and measurement on a per IP-CAN bearer basis. For the case where the BBF is not located in the PCEF, charging information shall be reported based on the result from the service data flow detection and measurement, separately per QCI and ARP combination (used by any of the active PCC rules). In case 2a defined in clause 7.1, charging ID is provided to the BBERF via the PCRF if charging correlation is needed. A report may contain multiple containers, each container associated with a charging key, charging key and Sponsor Identity (in case of sponsored connectivity) or charging key/service identifier.

The credit management applies for online charging only and shall operate on a per charging key basis. The PCEF should initiate one credit management session with the OCS for each IP-CAN Session subject to online charging, unless specified otherwise in an IP-CAN specific annex. Alternatively, the PCEF may initiate one credit management session for each IP-CAN bearer as defined in the applicable annex. The TDF should initiate one credit management session with the OCS for each TDF Session subject to online charging. The PCEF/TDF shall request a credit for each charging key occurring in a PCC/ADC rule. It shall be up to operator configuration whether the PCEF/TDF shall request credit in conjunction with the PCC/ADC rule being activated or when the first packet corresponding to the service/the application is detected. The OCS may either grant or deny the request for credit. The OCS shall strictly control the rating decisions. During IP-CAN session establishment and modification, the PCEF shall request credit using the information after applying policy enforcement action (e.g. upgraded or downgraded QoS information), if applicable, even though the PCEF has not signalled it yet in the IP-CAN. It shall be possible for the OCS to form a credit pool for multiple (one or more) charging keys, applied at the PCEF/TDF, e.g. with the objective of avoiding credit fragmentation. Multiple pools of credit shall be allowed per IP-CAN bearer/TDF session. The OCS shall control the credit pooling decisions. The OCS shall, when credit authorization is sought, either grant a new pool of credit, together with a new credit limit, or give a reference to a pool of credit that is already granted for that IP-CAN bearer/TDF session. The grouping of charging keys into pools shall not restrict the ability of the OCS to do credit authorisation and provide termination action individually for each charging key of the pool. It shall be possible for the OCS to group service data flows/applications charged at different rates or in different units (e.g. time/volume/event) into the same pool. For each charging key, the PCEF/TDF may receive credit re-authorisation trigger information from the OCS, which shall cause the PCEF/TDF to perform a credit re-authorisation when the event occurs. If there are events which can not be monitored in the PCEF/TDF, the PCEF/TDF shall provide the information about the required event triggers to the PCRF. If information about required event triggers is provided to the PCRF, it is an implementation option whether a successful confirmation is required from the PCRF in order for the PCEF/TDF to consider the credit (re-)authorization procedure to be successful. The credit re-authorisation trigger detection shall cause the PCEF/TDF to request re-authorisation of the credit in the OCS. It shall be possible for the OCS to instruct the PCEF/TDF to seek re-authorisation of credit in case of the events listed in Table 6.1.

If the Location change trigger is armed, the PCEF shall activate the relevant IP-CAN specific procedure which reports any changes in location to the level indicated by the trigger. If credit-authorization triggers and event triggers require different levels of reporting of location change for a single UE, the location to be reported should be changed to the highest level of detail required. However, there should be no request being triggered for credit re-authorization to the OCS if the report received is more detailed than requested by the OCS. The OCS determines at credit management session establishment/modification, based on local configuration, if the UE is located in an access type that supports reporting changes of UE presence in Presence Reporting Area. If the access type supports it, the OCS may subscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the credit management session. When activating reporting for change of UE presence in Presence Reporting Area, the OCS provides all of the PRA Identifier(s) to be activated for Core Network pre-configured Presence Reporting Area(s) and additionally all of PRA Identifier(s) and the list(s) of its elements for UE- dedicated Presence Reporting Area(s). (See Table 6.4 in clause 6.4 for details of the PRA Identifier(s) and the list(s) of elements comprising each Presence Reporting Area). If OCS is configured with a PRA identifier referring to the list of PRA Identifier(s) within a Set of Core Network predefined Presence Reporting Areas as defined in TS 23.401, it activates the reporting of UE entering/leaving the individual PRA in the Set of Core Network predefined Presence Reporting Areas without providing the complete set of individual PRAs. The OCS may change (activate/modify/remove) the Presence Reporting Area(s) to be reported by providing the updated PRA Identifier(s) to PCEF. For UE dedicated PRAs, the OCS may also change the list(s) of Presence Reporting Area elements related to the PRA Identifier(s). The OCS may unsubscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the credit management session. The OCS may be notified during the life time of a credit management session that the UE is located in an access type where local OCS configuration indicates that reporting changes of UE presence in Presence Reporting Area is not supported. If so, the OCS unsubscribes to Change of UE presence in Presence Reporting Area, if previously activated. Some of the re-authorization triggers are related to IP-CAN bearer modifications. IP-CAN bearer modifications, which do not match any credit re-authorization trigger (received from the OCS for the bearer) shall not cause any credit re-authorization interaction with the OCS. If the PCRF set the Out of credit event trigger (see clause 6.1.4), the PCEF/TDF shall inform the PCRF about the PCC/ADC rules for which credit is no longer available together with the applied termination action.