The Event Reporting Function (ERF) performs event trigger detection. When an event matching the event trigger occurs, the ERF shall report the occurred event to the PCRF. The Event Reporting Function is located either at the PCEF or, at the BBERF (if applicable) or, at the TDF for solicited application reporting (if applicable).
The event triggers define the conditions when the ERF shall interact again with PCRF after an IP-CAN session establishment. The event triggers that are required in procedures shall be unconditionally reported from the ERF, while the PCRF may subscribe to the remaining events. Whether an event trigger requires a subscription by the PCRF is indicated in column 4 in Table 6.2 below.
The PCRF subscribes to new event triggers or remove armed event triggers unsolicited at any time or upon receiving a request from the AF, an event report or rule request from the ERF (PCEF or BBERF or TDF) using the Provision of PCC Rules procedure or the Provision of QoS Rules procedure (if applicable) or the Provision of ADC Rules procedure (if applicable). If the provided event triggers are associated with certain parameter values then the ERF shall include those values in the response back to the PCRF. Event triggers are associated with all rules at the ERF of an IP-CAN session (ERF is located at PCEF) or Gateway Control session (ERF is located at BBERF) or with Traffic Detection session (ERF is located in TDF). Event triggers determine when the ERF shall signal to the PCRF that an IP-CAN bearer has been modified. It shall be possible for the ERF to react on the event triggers listed in Table 6.2.
The QoS of the IP-CAN bearer has changed (note 3).
QoS change exceeding authorization
The QoS of the IP-CAN bearer has changed and exceeds the authorized QoS (note 3).
Traffic mapping information change
The traffic mapping information of the IP-CAN bearer has changed (note 3).
Resource modification request
A request for resource modification has been received by the BBERF/PCEF (note 6).
Routing information change
The IP flow mobility routing information has changed (when IP flow mobility as specified in TS 23.261 applies) or the PCEF has received Routing Rules from the UE (when NBIFOM as specified in TS 23.161 applies) (note 11) (note 16).
Always set (note 15)
Change in type of IP-CAN (see note 1)
The access type of the IP-CAN bearer has changed.
Loss/recovery of transmission resources
The IP-CAN transmission resources are no longer usable/again usable.
Location change (serving cell) (see note 10)
The serving cell of the UE has changed.
Location change (serving area) (see notes 4 and 10)
The serving area of the UE has changed.
Location change (serving CN node) (see notes 5 and 10)
The serving core network node of the UE has changed.
Change of UE presence in Presence Reporting Area (see note 17)
The UE is entering/leaving a Presence Reporting Area
Out of credit
Credit is no longer available.
Enforced PCC rule request
PCEF is performing a PCC rules request as instructed by the PCRF.
Enforced ADC rule request
TDF is performing an ADC rules request as instructed by the PCRF.
UE IP address change (see note 9)
A UE IP address has been allocated/released
Access Network Charging Correlation Information
Access Network Charging Correlation Information has been assigned.
Usage report (see note 7)
The IP-CAN session or the Monitoring key specific resources consumed by a UE either reached the threshold or needs to be reported for other reasons.
Start of application traffic detection and
Stop of application traffic detection (see note 8)
The start or the stop of application traffic has been detected.
SRVCC CS to PS handover
A CS to PS handover has been detected
Access Network Information report
Access information as specified in the Access Network Information Reporting part of a PCC rule.
Credit management session failure
Transient/Permanent Failure as specified by the OCS
PCRF for PCEF,
Always set for TDF
Addition / removal of an access to an IP-CAN session (note 11)
The PCEF reports when an access is added or removed
Change of usability of an access (note 11)
The PCEF reports that an access becomes unusable or usable again (note 14)
UE resumed from suspend state
The PCEF reports to the PCRF when it detects that the UE is resumed from suspend state.
This list is not exhaustive. Events specific for each IP-CAN are specified in Annex A.
A change in the type of IP-CAN may also result in a change in the PLMN.
Available only when the bearer binding mechanism is allocated to the PCRF.
A change in the serving area may also result in a change in the serving cell, and a change in the serving CN node.
A change in the serving CN node may also result in a change in the serving cell, and possibly a change in the serving area.
Available only when the IP-CAN supports corresponding procedures for bearer independent resource requests.
Usage is defined as either volume or time of user plane traffic.
The start and stop of application traffic detection are separate event triggers, but received under the same subscription from the PCRF. For unsolicited application reporting, these event triggers are always set for the TDF.
If TDF for solicited application reporting is applicable, upon receiving this event report from PCEF, PCRF always updates the TDF.
Due to the potential increase in signalling load, it is recommended that such event trigger subscription is only applied for a limited number of subscribers.
Used when NBIFOM is supported by the IP-CAN session. Refer to clause 6.1.18 for the description of NBIFOM impacts to PCC. NBIFOM Routing Rules are defined in clause 6.12.
Used in Network-initiated NBIFOM mode. The PCEF reports that an access becomes unusable or usable again are based on notifications received from the UE. This may correspond to the procedure "Access becomes Unusable and Usable" and to the procedure "IP flow mobility triggered by RAN Rule indication" defined in TS 23.161.
This event is always set when IFOM per TS 23.261 applies or when NBIFOM per TS 23.161 applies. In the latter case it applies in both Network-initiated NBIFOM mode and in UE-initiated NBIFOM mode.
In UE-initiated NBIFOM mode this event indicates that the UE has created, modified or deleted Routing Rules. In Network-initiated NBIFOM mode this event indicates that the UE requests the network to create, modify or delete Routing Rules.
The maximum number of PRA(s) per UE per PDN connection is configured in the PCRF. The PCRF may have independent configuration of the maximum number for Core Network pre-configured PRAs and UE-dedicated PRAs. The exact number(s) should be determined by operator in deployment.
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 PCC rules or QoS rules (if applicable) update to the PCRF if the report received is more detailed than requested by the PCRF.
The PCRF determines at IP-CAN 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 PCRF may subscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the IP-CAN session
When activating reporting for change of UE presence in Presence Reporting Area, the PCRF 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 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). Setting the Change of UE presence in Presence Reporting Area event trigger shall not preclude the PCRF from simultaneously setting another Location change event trigger. If PCRF 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 PCRF 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 PCRF may also change the list(s) of Presence Reporting Area elements related to the PRA Identifier(s).
The PCRF may unsubscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the IP-CAN session.
The PCRF may be notified during the life time of an IP-CAN session that the UE is located in an access type where local PCRF configuration indicates that reporting changes of UE presence in Presence Reporting Area is not supported. The PCRF unsubscribes to Change of UE presence in Presence Reporting Area, if previously activated.
IP-CAN bearer modifications, which do not match any event trigger, shall cause no interaction with the PCRF.
The QoS change event trigger shall trigger the PCRF interaction for all changes of the IP-CAN bearer QoS. The QoS change exceeding authorization event trigger shall only trigger the PCRF interaction for those changes that exceed the QoS of the IP-CAN bearer that has been authorized by the PCRF previously. The ERF shall check the QoS class identifier and the bandwidth.
The Resource modification request event trigger shall trigger the PCRF interaction for all resource modification requests not tied to a specific IP-CAN bearer received by PCEF/BBERF. The resource modification request received by PCEF/BBERF may include request for guaranteed bit rate changes for a traffic aggregate and/or the association/disassociation of the traffic aggregate with a QCI and/or a modification of the traffic aggregate.
The routing information change event trigger shall trigger the PCRF interaction for any change in how the IP flow is routed. The routing information change received by the PCEF is specified in TS 23.261 (i.e. IP flow mobility routing rules) or TS 23.161 (i.e. Routing Rules).
The enforced PCC rule request event trigger shall trigger a PCEF interaction to request PCC rules from the PCRF for an established IP-CAN session. This PCEF interaction shall take place within the Revalidation time limit set by the PCRF in the IP-CAN session related policy information (clause 6.4).
The enforced ADC rule request event trigger shall trigger a TDF interaction to request ADC rules from the PCRF for an established TDF session for solicited application reporting. This TDF interaction shall take place within the ADC Revalidation time limit set by the PCRF in the TDF session related policy information (clause 6.4).
The UE IP address change event trigger applies to the PCEF only and shall trigger a PCEF interaction with the PCRF in case a UE IPv4 address is allocated or released during the lifetime of the IP-CAN session.
The Access Network Charging Correlation Information event shall trigger the PCEF to report the assigned access network charging identifier for the PCC rules that are accompanied with a request for this event at activation.
To activate usage monitoring, the PCRF shall set the Usage report event trigger and provide applicable usage thresholds for the Monitoring key(s) that are subject to usage monitoring in the requested node (PCEF or TDF, solicited application reporting). The PCRF shall not remove the Usage report event trigger while usage monitoring is still active in the PCEF/TDF.
If the Usage report event trigger is set and the volume or the time thresholds, earlier provided by the PCRF, are reached, the PCEF or TDF (whichever received the event trigger) shall report this event to the PCRF. If both volume and time thresholds were provided and the thresholds, for one of the measurements, are reached, the PCEF or TDF shall report this event to the PCRF and the accumulated usage since last report shall be reported for both measurements.
The Start of application traffic detection and Stop of application traffic detection events shall trigger an interaction with PCRF once the requested application traffic is detected (i.e. Start of application traffic detection) or the end of the requested application traffic is detected (i.e. Stop of application traffic detection) unless it is requested within a specific PCC Rule or ADC Rule to mute such a notification for solicited application reporting or unconditionally in case of unsolicited application reporting. The application identifier and service data flow descriptions, if deducible, shall also be included in the report. An application instance identifier shall be included in the report both for Start and for Stop of application traffic detection when service data flow descriptions are deducible. This is done to unambiguously match the Start and the Stop events.
The SRVCC CS to PS handover event trigger shall trigger a PCEF interaction with the PCRF to inform that a CS to PS handover procedure has been detected. The PCRF shall ensure, as specified in TS 23.216, to allow voice media over the default bearer during the course of the CS to PS SRVCC procedure.
At PCC rule activation, modification and deactivation the ERF shall send, as specified in the PCC/QoS rule, the User Location Report and/or UE Timezone Report to the PCRF.
The PCRF shall send the User Location Report and/or UE Timezone Report to the AF upon receiving an Access Network Information report corresponding to the AF session from the ERF.
If the event trigger for Access Network Information reporting is set, the ERF shall check the need for access network information reporting after successful installation/modification or removal of a PCC/QoS rule or upon termination of the IP-CAN session/bearer. The ERF shall check the Access Network Information report parameters (User Location Report, UE Timezone Report) of the PCC/QoS rules and report the access network information received in the corresponding IP-CAN bearer establishment, modification or termination procedure to the PCRF. The ERF shall not report any subsequent access network information updates received from the IP-CAN without any previous updates of related PCC/QoS rules unless the associated IP-CAN bearer or connection has been released.
If the ERF receives a request to install/modify or remove a PCC/QoS rule with Access Network Information report parameters (User Location Report, UE Timezone Report) set and there is no bearer signalling related to this PCC/QoS rule (i.e. pending IP-CAN bearer signalling initiated by the UE or bearer signalling initiated by the ERF), the ERF shall initiate a bearer signalling to retrieve the current access network information of the UE and forward it to the PCRF afterwards.
If the Access Network Information report parameter for the User Location Report is set and the user location (e.g. cell) is not available to the ERF, the ERF shall provide the serving PLMN identifier to the PCRF which shall forward it to the AF.
The Credit management session failure event trigger shall trigger a PCEF or TDF interaction with the PCRF to inform about a credit management session failure and to indicate the failure reason, and the affected PCC/ADC rules.
If the UE resumed from suspend state event trigger is set and the UE is resumed from suspend state in EPC, the PCEF shall report this event to the PCRF. The PCEF shall not report any subsequent UE resumed from suspend state updates received from the IP-CAN to the PCRF. When receiving the event report that the UE is resumed, the PCRF may provision PCC Rules to the PCEF to trigger an IP-CAN Session modification procedure.
Binding, i.e. the generation of an association between a service data flow and the IP-CAN bearer transporting that service data flow;
Gating control, i.e. the blocking or allowing of packets, belonging to a service data flow or specified by an application identifier, to pass through to the desired endpoint;
Event reporting, i.e. the notification of and reaction to application events to trigger new behaviour in the user plane as well as the reporting of events related to the resources in the GW (PCEF);
QoS control, i.e. the authorisation and enforcement of the maximum QoS that is authorised for a service data flow, an Application identified by application identifier or an IP-CAN bearer;
Redirection, i.e. the steering of packets, belonging to an application defined by the application identifier to the specified redirection address;
IP-CAN bearer establishment for IP-CANs that support network initiated procedures for IP-CAN bearer establishment.
In case of an aggregation of multiple service data flows (e.g. for GPRS a PDP context), the combination of the authorised QoS information of the individual service data flows is provided as the authorised QoS for this aggregate.
The enforcement of the authorized QoS of the IP-CAN bearer may lead to a downgrading or upgrading of the requested bearer QoS by the GW (PCEF) as part of a UE-initiated IP-CAN bearer establishment or modification. Alternatively, the enforcement of the authorised QoS may, depending on operator policy and network capabilities, lead to network initiated IP-CAN bearer establishment or modification. If the PCRF provides authorized QoS for both, the IP-CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules shall take place first.
QoS authorization information may be dynamically provisioned by the PCRF or, if the conditions mentioned in clause 6.3.1 apply, it can be a predefined PCC rule in the PCEF. In case the PCRF provides PCC rules dynamically, authorised QoS information for the IP-CAN bearer (combined QoS) may be provided. For a predefined PCC rules within the PCEF the authorized QoS information shall take affect when the PCC rule is activated. The PCEF shall combine the different sets of authorized QoS information, i.e. the information received from the PCRF and the information corresponding to the predefined PCC rules. The PCRF shall know the authorized QoS information of the predefined PCC rules and shall take this information into account when activating them. This ensures that the combined authorized QoS of a set of PCC rules that are activated by the PCRF is within the limitations given by the subscription and operator policies regardless of whether these PCC rules are dynamically provided, predefined or both.
For policy control, the AF interacts with the PCRF and the PCRF interacts with the PCEF as instructed by the AF. For certain events related to policy control, the AF shall be able to give instructions to the PCRF to act on its own, i.e. based on the service information currently available. The following events are subject to instructions from the AF:
The authorization of the service based on incomplete service information;
The immediate authorization of the service;
The gate control (i.e. whether there is a common gate handling per AF session or an individual gate handling per AF session component required);
The forwarding of IP-CAN bearer level information or events:
Type of IP-CAN (e.g. GPRS, etc.);
Transmission resource status (established/released/lost);
Access Network Charging Correlation Information;
To enable the binding functionality, the UE and the AF shall provide all available flow description information (e.g. source and destination IP address and port numbers and the protocol information). The UE shall use the traffic mapping information to indicate downlink and uplink IP flows.
If PCEF indicates that a PDN connection is carried over satellite access (of WB-E-UTRAN, NB-IoT or LTE-M RAT Types and specific values as defined in TS 23.401), the PCRF may take this information into account for the policy decision, e.g. together with any delay requirements provided by the AF.
Service pre-emption priority enables the PCRF to resolve conflicts where the activation of all requested active PCC rules for services would result in a cumulative authorized QoS which exceeds the Subscribed Guaranteed bandwidth QoS.
For example, when supporting network controlled QoS, the PCRF may use the pre-emption priority of a service, the activation of which would cause the subscriber's authorized QoS to be exceeded. If this pre-emption priority is greater than that of any one or more active PCC rules, the PCRF can determine whether the deactivation of any one or more such rules would allow the higher pre-emption priority PCC rule to be activated whilst ensuring the resulting cumulative QoS does not exceed a subscriber's Subscribed Guaranteed Bandwidth QoS.
If such a determination can be made, the PCRF may resolve the conflict by deactivating those selected PCC rules with lower pre-emption priorities and accepting the higher priority service information from the AF. If such a determination cannot be made, the PCRF may reject the service information from the AF.