In order to allow for charging control on service data flow, the information in the PCC rule identifies the service data flow and specifies the parameters for charging control. The PCC rule information may depend on subscription data.

M

C

In order to allow for charging control on detected application traffic identified by ADC Rule for the TDF, the information in the ADC rule contains the application identifier and specifies the parameters for charging control. The ADC rule information may depend on subscription data.

M

PC

For the purpose of charging correlation between application level (e.g. IMS) and service data flow level, applicable charging identifiers shall be passed along within the PCC architecture, if such identifiers are available.

M

C

For the purpose of charging correlation between service data flow level and application level (e.g. IMS) as well as on-line charging support at the application level, applicable charging identifiers and IP CAN type identifiers shall be passed from the PCRF to the AF, if such identifiers are available.

M

NC

It shall be possible to indicate to the PCEF or TDF that interactions with the charging systems are not required for a PCC or ADC rule, i.e. to perform neither accounting nor credit control for this the service data flow/detected application traffic, and then no offline charging information is generated.

M

PC

Only predefined ADC rules are supported

It shall be possible to enforce policies based on subscriber spending limits as per TS 22.115 [27].

M

C

The PCRF shall request information regarding the subscriber's spending from the OCS, to be used as input for dynamic policy decisions for the subscriber, using subscriptions to spending limit reports.

M

C

The Gx reference point resides between the PCEF and the PCRF.

M

C

The Gx reference point enables the PCRF to have dynamic control over the PCC behaviour at a PCEF.

The Gx reference point enables the signalling of PCC decision, which governs the PCC behaviour, and it supports the following functions:

- Establishment of Gx session (corresponding to an IP CAN session) by the PCEF;

- Request for PCC decision from the PCEF to the PCRF;

M

C

- Provision of IP flow mobility routing information from PCEF to PCRF; this applies only when IP flow mobility as defined in TS 23.261 [23] is supported;

M

NC

IP flow mobility is not supported by the SAPC.

- Reporting of the start and the stop of detected applications and transfer of service data flow descriptions and application instance identifiers for detected applications from the PCEF to the PCRF;

M

C

- Provision of PCC decision from the PCRF to the PCEF;

M

C

- Reporting of the accumulated usage of network resources on a per IP-CAN session basis from the PCEF to the PCRF;

M

C

- Delivery of IP CAN- session specific parameters from the PCEF to the PCRF, if Gxx is deployed, from the PCRF to the PCEF per corresponding request;

M

NC

- Negotiation of IP CAN bearer establishment mode (UE-only or UE/NW);

M

C

- Termination of Gx session (corresponding to an IP CAN session) by the PCEF or the PCRF.

M

C

Note: The PCRF decision to terminate a Gx session is based on operator policies. It should only occur in rare situations (e.g. the removal of a UE subscription) to avoid service interruption due to the termination of the IP CAN session.

M

C

The Sd reference point resides between the PCRF and the TDF.

M

C

The Sd reference point enables a PCRF to have dynamic control over the application detection and control behaviour at a TDF.

M

C

The Sd reference point enables the signalling of ADC decision, which governs the ADC behaviour, and it supports the following functions:

1. Establishment of Sd session between the PCRF and the TDF;

M

C

2. Termination of Sd session between the PCRF and the TDF;

M

C

3. Provision of ADC decision from the PCRF for the purpose of application's traffic detection, enforcement and charging at the TDF;

M

C

4. Request for ADC decision from the TDF to the PCRF;

M

PC

Only APPLICATION_START and APPLICATION_STOP Event-Triggers are supported

5. Reporting of the start and the stop of a detected applications and transfer of service data flow descriptions and application instance identifiers for detected applications from the TDF to the PCRF;

M

C

6. Reporting of the accumulated usage of network resources on a per TDF session basis from the TDF to the PCRF;

M

NC

Usage monitoring not supported in TDF interactions

7. Request and delivery of IP CAN session specific parameters between the PCRF and the TDF.

M

PC

Location information is not delivered to the TDF

When Sd is used for traffic steering control only, then the following function is supported:

- Provision of ADC Rules from the PCRF for the purpose of application's traffic detection and traffic steering control.

M

PC

Only predefined ADC rules are supported

The Sy reference point resides between the PCRF and the OCS.

M

C

The Sy reference point enables transfer of policy counter status information relating to subscriber spending from OCS to PCRF and supports the following functions:

- Request for reporting of policy counter status information from PCRF to OCS and subscribe to or unsubscribe from spending limit reports (i.e. notifications of policy counter status changes).

M

PC

UnSubscription is not supported

- Report of policy counter status information upon a PCRF request from OCS to PCRF.

M

C

- Notification of spending limit reports from OCS to PCRF.

M

C

- Cancellation of spending limit reporting from PCRF to OCS.

M

C

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.

M

NC

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.

M

PC

Only application detection and control interactions with TDF are supported

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 rules for which credit is no longer available together with the applied termination action.

M

PC

Only application detection and control interactions with TDF are supported

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

M

PC

BBERF interactions are not supported

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.

M

C

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

M

PC

Only subscription to APPLICATION_START and APPLICATION_STOP Event-Triggers during TDF session establishment is supported

BBERF interactions are not supported.

PLMN change

M

C

QoS change

M

C

QoS change exceeding authorization

M

C

Traffic mapping information change

C

NC

Resource modification request

M

NC

Routing information change

M

NC

Change in type of IP CAN (see note 1)

M

C

Loss/recovery of transmission resources

M

NC

Location change (serving cell)

M

C

Location change (serving area) (see note 4)

M

C

Location change (serving CN node) (see note 5)

M

C

Change of UE presence in Presence Reporting Area

M

C

Out of credit

M

C

Enforced PCC rule request

M

C

Enforced ADC rule request

M

NC

UE IP address change

M

NC

Access Network Charging Correlation Information

M

NC

Usage report (see note 7)

M

C

Start of application traffic detection and Stop of application traffic detection (see note 8)

M

C

SRVCC CS to PS handover

M

NC

Access Network Information report

M

C

Credit management session failure

M

NC

Addition / removal of an access to a IP-CAN session

M

NC

Change of availability of an Access

M

NC

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

M

C

NOTE 2: If Presence Reporting Area reporting is not supported, the PCRF may instead activate Location change reporting at cell and/or serving area level but due to the potential increase in signalling load, it is recommended that such reporting is only applied for a limited number of subscribers.

M

C

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.

Op

C

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.

M

C

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 a traffic aggregate with a QCI and/or a modification of a traffic aggregate.

M

NC

The routing information change event trigger shall trigger the PCRF interaction for any change in how the IP flow is routed (i.e. IP flow mobility routing rules). The routing information change received by the PCEF is specified in TS 23.261.

M

NC

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

M

C

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

M

NC

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.

M

NC

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.

M

NC

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

M

PC

Usage monitoring not supported in TDF interactions

The PCRF shall not remove the Usage report event trigger while usage monitoring is still active in the PCEF/TDF.

M

PC

Usage monitoring not supported in TDF interactions

If the Usage report event trigger is set and the volume or the time thresholds, earlier provided by the PCRF, are reached, the PCEF shall report this event to the PCRF.

M

C

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.

M

PC

Usage monitoring not supported in TDF interactions

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 [28], to allow voice media over the default bearer during the course of the CS to PS SRVCC procedure.

M

NC

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.

M

C

If the Access Network Information report parameter for the User Location Report is set and the user location (i.e. 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.

M

C

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. NOTE 5: As a result, the PCRF may decide about e.g. TDF session termination, IP-CAN session termination (via PCC rule removal), perform gating of services in the PCEF/TDF, switch to offline charging, rating group change, etc.

M

NC

Policy control comprises functionalities for:

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

M

PC

UE Init mode for dedicated bearers is not supported

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.

M

C

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.

M

PC

UE Init procedures for dedicated bearers is not supported

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 pre-defined 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.

M

C

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:

M

PC

See steps below

- The authorization of the service based on incomplete service information;

NOTE 1: The QoS authorization based on incomplete service information is required for e.g. IMS session setup scenarios with available resources on originating side and a need for resource reservation on terminating side.

M

C

- The immediate authorization of the service;

M

C

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

M

C

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

- Credit denied.

NOTE 2: The credit denied information is only relevant for AFs not performing service charging.

M

PC

See Rx interface description document for the list of supported IP-CAN events (Specific-Action AVP)

ADC Rule authorization refers to the PCRF decision about which predefined and/or dynamic ADC rules to activate for a TDF session and is only applicable in case of solicited application reporting.

M

PC

Only predefined ADC rules are supported

It may also comprise the selection of parameters (monitoring key, enforcement actions etc.) for dynamic ADC rules to be applied once the traffic is detected.

Op

NC

User profile configuration, received within subscription information, indicating whether application detection and control can be enabled, shall be taken into account by PCRF, when deciding on ADC rule authorization.

NOTE 1: The enforcement actions are only applicable in case of solicited application reporting.

NOTE 2: For unsolicited application reporting, all ADC rules pre-provisioned at TDF are authorized.

M

PC

Unsolicited application reporting isnot supported

PCRF may control redirection by provisioning and modifying dynamic ADC rules over the Sd interface for a TDF, or dynamic PCC rules over the Gx interface for a PCEF enhanced with ADC. The PCRF may enable/disable redirection and set a redirect destination for every dynamic ADC rule or PCC rule.

Op

PC

Only predefined ADC rules are supported

Redirect information (redirection enabled/disabled and redirect destination) within a PCC Rule or within an ADC rule respectively, instructs the PCEF enhanced with ADC, or the TDF whether or not to perform redirection towards a specific redirect destination. The redirect destination may be provided as part of the dynamic PCC/ADC Rule, or may be preconfigured in the PCEF enhanced with ADC or the TDF. A redirect destination provided in a dynamic PCC/ADC Rule overrides the redirect destination preconfigured in the PCEF enhanced with ADC or in the TDF for this PCC/ADC Rule.

M

PC

Only predefined ADC rules are supported

The PCRF encompasses policy control decision and flow based charging control functionalities.

M

C

The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF and/or TDF.

M

PC

Only predefined ADC rules are supported

The PCRF provides network control regarding the application detection, gating, QoS and application based charging (except credit management) towards the TDF and the PCEF enhanced with ADC.

M

PC

Only predefined ADC rules are supported

The PCRF shall apply the security procedures, as required by the operator, before accepting service information from the AF.

M

C

The PCRF shall decide whether application traffic detection is applicable, as per operator policies, based on user profile configuration, received within subscription information.

M

C

The PCRF shall decide how certain service/application traffic shall be treated in the PCEF and in the TDF, if applicable, and ensure that the PCEF user plane traffic mapping and treatment is in accordance with the user's subscription profile.

M

C

If Gxx applies, the PCRF shall provide QoS rules with identical service data flow templates as provided to the PCEF in the PCC rules. If the service data flow is tunnelled at the BBERF, the PCRF shall provide the BBERF with information received from the PCEF to enable the service data flow detection in the mobility tunnel at the BBERF. In case 2a, defined in clause 7.1, the PCRF may also provide to the BBERF the charging ID information received from the PCEF.

M

NC

When IP flow mobility scenarios are supported as specified in TS 23.261 [23] if the PCRF receives IP flow mobility routing rules from the PCEF, it shall provide authorized QoS rules to the applicable BBERF as specified in clause 6.1.1.3.

M

NC

The PCRF should for an IP CAN session derive, from IP CAN specific estrictions, operator policy and SPR data, the list of permitted QoS class identifiers and associated GBR and MBR limits for the IP CAN session.

M

C

The PCRF may check that the service information provided by the AF is consistent with both the operator defined policy rules and the related subscription information as received from the SPR during IP CAN session establishment before storing the service information. The service information shall be used to derive the QoS for the service. The PCRF may reject the request received from the AF when the service information is not consistent with either the related subscription information or the operator defined policy rules and as a result the PCRF shall indicate that this service information is not covered by the subscription information or by operator defined policy rules and may indicate, in the response to the AF, the service information that can be accepted by the PCRF (e.g. the acceptable bandwidth). In the absence of other policy control mechanisms outside the scope of PCC, it is recommended that the PCRF include this information in the response.

Op

PC

The SAPC does not indicate in the response to the AF the service information that can be accepted in case of reject an AF request.

When receiving service information from the AF, the PCRF may temporarily reject the AF request (e.g. if the service information is not consistent with the operator defined policy rules for the congestion status of the user). To temporarily reject the AF request the PCRF shall indicate a re-try interval to the AF. When receiving a re-try interval from the PCRF the AF shall not send the same service information to the PCRF again (for the same IP CAN session) until the re-try interval has elapsed.

NOTE 1: How the PCRF derives the re-try interval is up to implementation.

M

NC

In this Release, the PCRF supports only a single Rx reference point, i.e. there is one AF for each AF session.

M

C

The PCRF authorizes QoS resources. The PCRF uses the service information received from the AF (e.g. SDP information or other available application information) and/or the subscription information received from the SPR to calculate the proper QoS authorization (QoS class identifier, bitrates). The PCRF may also take into account the requested QoS received from the PCEF via Gx interface.

NOTE 2: The PCRF provides always the maximum values for the authorized QoS even if the requested QoS is lower than what can be authorized.

M

C

The Authorization of QoS resources shall be based on complete service information unless the PCRF is required to perform the authorization of QoS resources based on incomplete service information. The PCRF shall after receiving the complete service information, update the affected PCC rules accordingly.

M

C

The PCRF may use the subscription information as basis for the policy and charging control decisions. The subscription information may apply for both session based and non-session based services.

Op

C

The PCRF determines whether a Gx session from the PCEF is to be linked with a Gateway Control Session from the BBERF by matching the IPv4 address and/or IPv6 network prefix and conditionally the UE Identity, PDN Connection ID and PDN ID towards open Gateway Control Sessions. When IP flow mobility as specified in TS 23.261 [23] applies, one Gx session may be linked with multiple Gateway Control Sessions

M

NC

The SAPC does not support Gateway Control sessions from BBERF

If the BBERF does not provide any PDN ID at the Gateway Control Session Establishment, then the PCRF maintains Gateway Control Session to Gx session linking to the Gx sessions where the assigned CoA and UE Identity (if available over Gxx) are equal. The PCRF and BBERF shall be capable of separating information for each IP CAN session within the common Gateway Control Session.

M

NC

If the BBERF provides a PDN ID at the Gateway Control Session Establishment, then the PCRF maintains Gateway Control Session to Gx session linking where the UE identity and PDN ID are equal. If the BBERF provides a PDN ID at Gateway Control Session establishment, it may also indicate in the Gateway Control Session establishment that the PCRF shall not attempt linking the new Gateway Control Session with an existing Gx session immediately. If the PCRF receives such an indication, it keeps the new Gateway Control Session pending and defers linking until an IP-CAN session establishment or an IP-CAN session modification with matching UE Identity, PDN ID and IP-CAN type arrives via Gx.

M

NC

If the BBERF provides a PDN ID and a PDN Connection ID at the Gateway Control Session establishment, then the PCRF maintains Gateway Control Session to Gx session linking where the UE identity, PDN Connection ID and PDN ID are equal.

M

NC

When a BBERF establishes multiple Gateway Control Sessions for the same PDN ID and the IP CAN type changes, the PCRF assumes that this constitutes inter-system BBERF relocations of existing Gateway Control Sessions. The BBERF may supply UE IP address(es) (if known) that can be used for linking the new Gateway Control Session to the existing Gx session. If the UE IP address(es) is not provided in the new Gateway Control Session establishment, the PCRF shall defer the linking with existing Gx session until receiving an IP-CAN Session modification with matching UE Identity, IP CAN type, PDN Connection ID, and PDN ID.

M

NC

The PCRF determines which case applies as described on clause 7.1.

M

NC

If an AF requests the PCRF to report on the signalling path status, for the AF session, the PCRF shall, upon indication of loss of resources from the PCEF, for PCC rules corresponding to the signalling traffic notify the AF on changes to the signalling path status. The PCRF needs to have the knowledge of which PCC rules identify signalling traffic.

M

NC

Negotiation of IP CAN bearer establishment mode takes place via Gx for 3GPP IP CANs via Gxx for non-3GPP IP CANs specified in TS 23.402 [18]. For other accesses supporting multiple IP CAN bearer establishment modes, if Gxx applies, the negotiation takes place via Gxx, otherwise via Gx.

To support the different IP CAN bearer establishment modes (UE-only or UE/NW) the PCRF shall:

M

PC

The SAPC does not support IP CAN bearer establishment via Gxx

- shall set the IP CAN bearer establishment mode for the IP CAN session based on operator configuration, network and UE capabilities;

M

C

The SAPC decides the bearer establishment mode taking into account the network and UE capabilities.

- shall, if the bearer establishment mode is UE/NW, decide what mode (UE or NW) shall apply for a PCC rule and resolve race conditions between for requests between UE-initiated and NW-initiated requests;

NOTE 3: For an operator-controlled service, the UE and the PCRF may be provisioned with information indicating which mode is to be used.

M

C

The SAPC always decide NW.

- may reject a UE request that is already served by a NW-initiated procedure in progress. When rejecting a UE-initiated request by sending a reject indication, the PCRF shall use an appropriate cause value which shall be delivered to the UE.

NOTE 4: This situation may e.g. occur if the PCRF has already triggered a NW-initiated procedure that corresponds to the UE request

Op

NC

UE-Init procedures (multiple IP-CAN bearers) are not supported.

- guarantee the precedence of dynamic PCC rules for network controlled services in the service data flow detection process at the PCEF by setting the PCC rule precedence information to appropriate values.

M

C

If an AF requests the PCRF to report on the change of type of IP CAN, the PCRF shall provide to the AF the information about the IP CAN type the user is currently using and upon indication of change of IP CAN type, notify the AF on changes of the type of IP CAN. In the case of 3GPP IP CAN, the information of the Radio Access Technology Type (e.g. UTRAN) shall be also reported to the AF.

M

NC

If IP flow mobility as specified in TS 23.161 [43] or in TS 23.261 [23] applies, the PCRF shall provide to the AF the new IP-CAN type information together with the affected service information. When IP flow mobility is allowed within an IP CAN session, the PCRF shall only report to an AF the IP CAN type change when the IP flow mobility applies to the service information provided by this AF.

M

NC

If an AF requests the PCRF to report Access Network Information, the PCRF shall set the Access Network Information report parameters in the corresponding PCC rule(s) or QoS rule(s) and provision them together with the corresponding event trigger to the PCEF or BBERF as per procedure in clause 7.4.2. For those PCC rule(s) or QoS rule(s) based on preliminary service information the PCRF may assign the QCI and ARP of the default bearer to avoid signalling to the UE. In addition the SDF filter(s) shall not be marked as to be used for signalling to the UE as traffic mapping information.

M

PC

BBERF is not supported

If an AF requests the PCRF to report Access Network Information, the PCRF shall also set the corresponding event trigger to the PCEF or BBERF as per procedure in clause 7.4.2. The PCRF shall, upon receiving the subsequent Access Network Information report corresponding to the AF session from the PCEF or BBERF, forward the Access Network Information as requested by the AF.

M

PC

BBERF is not supported

If an AF requests the PCRF to report the PLMN identifier where the UE is currently located, then the PCRF shall provide the PLMN identifier to the AF if available.Otherwise, the PCRF shall provision both the corresponding PCC rules and QoS Rules if applicable, and the event trigger to report PLMN change to the PCEF. The PCRF shall, upon receiving of the PLMN identifier from the PCEF forward this information to the AF as defined in the procedures in clause 6.1.4.

M

NC

If an AF requests the PCRF to report Access Network Charging Correlation Information, the PCRF shall provide to the AF the Access Network Charging Correlation Information, that will identify the usage reports that include measurement for the flows, once the Access Network Charging Correlation Information is known at the PCRF. If not known in advance, the PCRF subscribes for the Access Network Charging Correlation Information event for the applicable PCC rule(s), unless a single charging identifier per IP-CAN session is used as described below.

C

NC

The PCEF provides at IP-CAN session establishment both a charging identifier and an optional indication that the charging identifier is the only one for that IP-CAN session, as defined in TS 32.251 [9], clause 5.1.3. In absence of the indication there is a separate charging identifier for each IP-CAN bearer to identify usage reports that include measurements for flows served by each individual bearer. When the PCEF indicates that a single charging identifier is used for the IP-CAN session, the PCRF uses the charging identifier received at IP-CAN session establishment to provide Access Charging Correlation information to the AF for all flows, instead of subscribing to the Access Network Charging Correlation Information event trigger for the applicable PCC Rule(s) as described above.

M

NC

If Gxx applies and the PCEF provided information about required event triggers, the PCRF shall provide these event triggers to the BBERF and notify the PCEF of the outcome of the provisioning procedure by using the PCRF initiated IP CAN Session Modification procedure, as defined in clause 7.4.2. The PCRF shall include the parameter values received in the response from the BBERF in the notification to the PCEF.

C

NC

When multiple BBERFs exist (e.g. in IP flow mobility case), the PCEF may subscribe to different or common set of event triggers at different BBERFs; when the PCRF receives event notification from any BBERF, the PCRF shall include both the parameters values received from the BBERF and also the information for identifying the BBERF in the notification to the PCEF

M

NC

If Sd applies and the TDF provided information about required event triggers, the PCRF shall provide these event triggers to the PCEF or BBERF, if Gxx applies, and notify the TDF of the outcome of the provisioning procedure within the PCEF initiated IP CAN Session Modification procedure, as defined in clause 7.4.1. The PCRF shall include the parameter values, received in the response from the PCEF/BBERF, in the notification to the TDF. The relevant Event Triggers are: PLMN change, Location change, Change in type of IP CAN, RAT type change, SGSN change, Serving GW change, User CSG Information change in CSG cell, User CSG Information change in subscribed hybrid cell, User CSG Information change in un-subscribed hybrid cell, Change of UE presence in Presence Reporting Area.

M

NC

When the PCRF gets an event report from the BBERF that is required by the PCEF, the PCRF shall forward this event report to the PCEF.

M

NC

When the PCRF gets an Event Report from the PCEF/BBERF that is required by the TDF, the PCRF shall forward this Event Report to the TDF.

M

NC

The PCRF may support usage monitoring control. Usage is defined as volume or time of user plane traffic.

Op

PC

Time usage monitoring not supported

The PCRF may receive information about total allowed usage per PDN and UE from the SPR, i.e. the overall amount of allowed resources (based either on traffic volume and/or traffic time) that are to be monitored for the PDN connections of a user. In addition information about total allowed usage for Monitoring key(s) per PDN and UE may also be received from the SPR.

M

PC

Time usage monitoring not supported

For the purpose of usage monitoring per access type, the PCRF receives an individual Monitoring key per access type from SPR.

M

NC

For the purpose of usage monitoring control the PCRF shall request the Usage report trigger and provide the necessary usage threshold(s), either volume threshold, time threshold, or both volume threshold and time threshold upon which the requested node (PCEF or TDF) shall report to the PCRF.

M

PC

Usage monitoring not supported in TDF interactions

The PCRF shall decide if and when to activate usage monitoring to the PCEF and TDF.

M

PC

Usage monitoring not supported in TDF interactions

The PCRF may provide a Monitoring time to the PCEF/TDF for the Monitoring keys(s) and optionally specify a subsequent threshold value for the usage after the Monitoring time.

Op

NC

If the PCEF reports usage before the Monitoring time is reached, the Monitoring time is not retained by the PCEF. Therefore the PCRF may again provide a Monitoring time and optionally the subsequent threshold value for the usage after the Monitoring time in the response.

Op

NC

It shall be possible for the PCRF to request a usage report from the requested node (PCEF or TDF).

M

PC

Usage monitoring not supported in TDF interactions

NOTE 6: The PCRF ensures that the number of requests/following policy decisions provided over Gx/Sd reference point do not cause excessive signalling load by e.g. assigning the same time for the report only for a preconfigured number of IP-CAN/TDF sessions.

M

NC

Once the PCRF receives a usage report from the requested node (PCEF or TDF), the PCRF shall deduct the value of the usage report from the totally allowed usage for that PDN and UE (in case usage per IP-CAN session is reported). If usage is reported from the TDF or the PCEF, the PCRF shall deduct the value of the usage report from the totally allowed usage for individual Monitoring key(s) for that PDN and UE (in case of usage for one or several Monitoring keys is reported).

NOTE 7: The PCRF maintains usage thresholds for each Monitoring key and IP CAN session that is active for a certain PDN and UE. Updating the total allowance usage after the PCEF reporting, minimizes the risk of exceeding the usage allowance.

M

PC

Usage monitoring not supported in TDF interactions

If the PCEF or TDF reports usage for a certain Monitoring key and if monitoring shall continue for that Monitoring key then the PCRF shall provide new threshold values in the response to the PCEF or TDF respectively.

M

PC

Usage monitoring not supported in TDF interactions

If Monitoring time and subsequent threshold value are used then the PCRF provides them to the PCEF or TDF as well.

M

NC

The PCRF may provide a new volume threshold and/or a new time threshold to the PCEF or TDF, the new threshold values overrides the existing threshold values in the PCEF or TDF.

Op

PC

Usage monitoring not supported in TDF interactions

If monitoring shall no longer continue for that Monitoring key, then the PCRF shall not provide a new threshold in the response to the PCEF or TDF.

M

PC

Usage monitoring not supported in TDF interactions

NOTE 8: If the PCRF decides to deactivate all PCC-rules or ADC rules associated with a certain Monitoring key, then the conditions defined in clause 6.6.2 for continued Monitoring will no longer be fulfilled for that Monitoring key.

M

PC

ADC rules not supported for usage monitoring

If all IP-CAN session of a user to the same APN is terminated, the PCRF shall store the remaining allowed usage, i.e. the information about the remaining overall amount of resources, in the SPR.

M

C

The PCRF may authorise an application service provider to request specific PCC decisions (e.g. authorisation to request sponsored IP flows, authorisation to request QoS resources).

Op

NC

For sponsored data connectivity (see Annex N), the PCRF may receive a usage threshold from the AF.

Op

NC

If the AF specifies a usage threshold, the PCRF shall use the Sponsor Identity to construct a Monitoring key for monitoring the volume, time, or both volume and time of user plane traffic, and invoke usage monitoring on the PCEF/TDF.

M

NC

The PCRF shall notify the AF when the PCEF/TDF reports that a usage threshold for the Monitoring key is reached provided that the AF requests to be notified for this event.

M

NC

If the AF decides to allow the session to continue without specifying a usage threshold, then monitoring in the PCEF/TDF shall be discontinued for that monitoring key by the PCRF, unless there are other reasons for continuing the monitoring.

M

NC

If the AF revokes the service information and the AF has notified previously a usage threshold to the PCRF, the PCRF shall report the usage up to the time of the revocation of service authorization.

M

NC

If the IP-CAN session terminates and the AF has specified a usage threshold then the PCRF shall notify the AF of the accumulated usage (i.e. either volume, or time, or both volume and time) of user plane traffic since the last usage report.

M

NC

The PCRF performs authorizations based on sponsored data connectivity profiles stored in the SPR.

M

NC

If the AF is in the operator's network and is based on the OSA/Parlay-X GW (TS 23.198 [24]), the PCRF is not required to verify that a trust relationship exists between the operator and the sponsors.

M

NC

If the H-PCRF detects that the UE is accessing the sponsored data connectivity in the roaming scenario with home routed access, it may allow the sponsored data connectivity in the service authorization request, reject the service authorization request, or initiate the AF session termination based on home operator policy.

M

NC

If the AF request includes an AF application identifier then, based on the operator policies the PCRF may trigger the activation of a predefined PCC/ADC Rule or provide a dynamic PCC/ADC rule with an appropriate application identifier in the PCEF/TDF.

Op

NC

For the solicited application reporting, it is PCRF's responsibility to coordinate the PCC rules and QoS rules, if applicable, with ADC rules in order to ensure consistent service delivery.

M

NC

The PCRF uses the information relating to subscriber spending available in the OCS as input for policy decisions related to e.g. QoS control, gating or charging conditions.

M

C

The PCRF uses the RUCI received from the RCAF as input for policy decisions.

M

NC

If the AF contacts the PCRF via the SCEF (and the Nt interface) to request a time window and related conditions for future background data transfer, the PCRF shall determine possible transfer policies (as described in clause 6.1.16) and send them to the AF together with a reference ID. If the AF received more than one transfer policy, the AF selects one of them and informs the PCRF about the selected transfer policy. The PCRF shall store the selected transfer policy in the SPR together with the reference ID and the network area information. Whenever the PCRF receives a reference ID from the AF during a subsequent transfer of AF session information (via the Rx interface), the PCRF shall retrieve the corresponding transfer policy from the SPR and apply it as one of the inputs for policy decisions for this IP-CAN session.

M

NC

The PCRF uses one or more pieces of information defined in the clause 6.2.1.1 as input for the selection of traffic steering policies used to control the steering of the subscriber's traffic to appropriate (S)Gi-LAN service functions. NOTE 10: In order to allow the PCRF to select and provision an application based traffic steering policy, the reporting of detected applications to the PCRF or any other information such as the RAT type, the RUCI etc. defined in clause 6.2.1.1 can be used.

M

NC

At reception of the IMS service information from the P-CSCF, if configured through policy, the PCRF determines the Maximum Packet Loss Rate for UL and DL based on the IMS service information e.g. codec and sends it to PCEF along with the PCC rule for the voice media. NOTE 11: Based on local configuration, the PCRF sets the Maximum Packet Loss Rate (UL, DL) corresponding to either the most robust codec mode or the least robust codec mode of the negotiated set in each direction. Editor's note: It is FFS how to refer to SA WG4 specification for setting Maximum Packet Loss Rate based on local configuration.

M

NC

The SPR logical entity contains all subscriber/subscription related information needed for subscription-based policies and IP CAN bearer level PCC rules by the PCRF.

M

C

The SPR may be combined with or distributed across other databases in the operator's network, but those functional elements and their requirements for the SPR are out of scope of this document.

Op

NC

The SPR may provide the following subscription profile information (per PDN, which is identified by the PDN identifier):

- Subscriber's allowed services;

- For each allowed service, a pre-emption priority;

- Information on subscriber's allowed QoS, including the Subscribed Guaranteed Bandwidth QoS;

- Subscriber's charging related information (e.g. location information relevant for charging);

- Subscriber's User CSG Information reporting rules;

- List of Presence Reporting Area identifiers and optionally the elements for one or more of the Presence Reporting Areas;

- Subscriber category;

- Subscriber's usage monitoring related information;

- MPS EPS Priority and MPS Priority Level;

- IMS Signalling Priority.

- Subscriber's profile configuration indicating whether application detection and control can be enabled.

- Spending limits profile containing an indication that policy decisions are based on policy counters available at OCS that has a spending limit associated with it and optionally the list of policy counters.

Op

PC

The SAPC does not support Subscriber's User CSG Information.

The SAPC does not support Subscriber Guaranteed Bandwidth QoS per subscriber

Elements for one or more of the Presence Reporting Areas not supported

The SPR may provide the following sponsored data connectivity profile information:

- A list of Application Service Providers and their applications per sponsor identity.

Op

NC

The SPR may provide the following policy information related to an ASP (see clause 6.1.16):

- The ASP identifier;

- A transfer policy together with a reference ID, the volume of data to be transferred per UE, the expected amount of UEs and the network area information.

Op

NC

The Policy and charging control rule (PCC rule) comprises the information that is required to enable the user plane detection of, the policy control and proper charging for a service data flow. The packets detected by applying the service data flow template of a PCC rule are designated a service data flow.

M

C

Two different types of PCC rules exist: Dynamic rules and predefined rules. The dynamic PCC rules are provisioned by the PCRF via the Gx reference point, while the predefined PCC rules are directly provisioned into the PCEF and only referenced by the PCRF. The usage of pre-defined PCC rules for QoS control is possible if the BBF remains in the PCEF during the lifetime of an IP-CAN session. In addition, pre-defined PCC rules may be used in a non-roaming situation and if it can be guaranteed that corresponding pre-defined QoS rules are configured in the BBF and activated along with the pre-defined PCC rules.

NOTE 1: The procedure for provisioning predefined PCC rules is out of scope for this TS.

NOTE 2: There may be another type of predefined rules that are not explicitly known in the PCRF and not under the control of the PCRF. The operator may define such predefined PCC rules, to be activated by the PCEF on one IP CAN bearer within the IP CAN session. The PCEF may only activate such predefined PCC rules if there is no UE provided traffic mapping information related to that IP CAN bearer. The IP CAN session termination procedure deactivates such predefined PCC rules.

M

C

There are defined procedures for activation, modification and deactivation of PCC rules (as described in clause 6.3.2). The PCRF may activate, modify and deactivate a PCC rule at any time, over the Gx reference point. However, the modification procedure is applicable to dynamic PCC rules only.

M

C

Each PCC rule shall be installed for a single IP CAN bearer only (for further details about predefined PCC rules see clause 6.3.2).

M

C

The operator defines the PCC rules.

M

C

Table 6.3 lists the information contained in a PCC rule, including the information name, the description and whether the PCRF may modify this information in a dynamic PCC rule which is active in the PCEF. The Category field indicates if a certain piece of information is mandatory or not for the construction of a PCC rule, i.e. if it is possible to construct a PCC rule without it.

NR

Rule identifier

M

C

Precedence

M

C

Service data flow template

M

C

Mute for notification

Op

C

Charging key

M

C

Service identifier

M

C

Sponsor Identifier

Op

NC

Application Service Provider Identifier

Op

NC

Charging method

M

C

Measurement method

M

C

Application Function Record Information

M

C

Service identifier level reporting

M

C

Gate status

M

C

QoS class identifier

M

C

UL/(DL)-maximum/(guaranteed) bitrate

M

C

UL/(DL) sharing indication

M

NC

Redirect

Op

C

Redirect Destination

Op

C

ARP

M

C

Bind to Default Bearer

Op

NC

PS to CS session continuity

Op

NC

User Location Report

M

C

UE Timezone Report

M

C

Monitoring key

M

NC

Indication of exclusion from session level monitoring

M

NC

Traffic Steering Enforcement Control

M

NC

Traffic steering policy identifier(s)

M

NC

NBIFOM related control Information

M

NC

Allowed Access Type

M

NC

Routing Rule Identifier

M

NC

UL Maximum Packet Loss Rate

Op

NC

DL Maximum Packet Loss Rate

OP

NC

The PCC Rule identifier shall be unique for a PCC rule within an IP CAN session. A dynamically provided PCC rule that has the same Rule identifier value as a predefined PCC rule shall replace the predefined rule within the same IP CAN session.

M

C

The Service data flow template may comprise any number of Service data flow filters. A Service data flow filter contains information for matching user plane packets. A Service data flow filter, provided from the PCRF, contains information elements as described in clause 6.2.2.2. The Service data flow template filtering information within an activated PCC rule is applied at the PCEF to identify the packets belonging to a particular service data flow.

NOTE 3: Predefined PCC rules may include service data flow filters, which support extended capabilities, including enhanced capabilities to identify events associated with application protocols.

Op

C

Alternatively, the Service data flow template consists of an application identifier that references an application detection filter that is used for matching user plane packets. The application identifier is also identifying the application, for which the rule applies.

Op

C

The same application identifier value can occur in more than one PCC rule with the following restrictions:

- The same application identifier value can be used for a dynamic PCC rule and one or multiple predefined PCC rules. If so, the PCRF shall ensure that there is at most one PCC rule active per application identifier value at any time.

Note 4: The configuration of the Application Identifier in the PCEF can include the set of information required for encrypted traffic detection as defined in Annex X.

Op

NC

The Mute for notification defines whether notification to the PCRF of application's starts or stops shall be muted. Absence of this parameter means that start/stop notifications shall be sent.

M

C

The Precedence defines in what order the activated PCC rules within the same IP CAN session shall be applied at the PCEF for service data flow detection. When a dynamic PCC rule and a predefined PCC rule have the same precedence, the dynamic PCC rule takes precedence.

M

C

For dynamic PCC rules that contain an application identifier, the Precedence shall be either preconfigured at the PCEF or provided dynamically by the PCRF within the PCC Rules

M

C

NOTE 5: The operator shall ensure that overlap between the predefined PCC rules can be resolved based on precedence of each predefined PCC rule in the PCEF. The PCRF shall ensure that overlap between the dynamically allocated PCC rules can be resolved based on precedence of each dynamically allocated PCC rule. Further information about the configuration of the PCC rule precedence is described in Annex G.

M

C

NOTE 6: Whether precedence for dynamic PCC rules that contain an application identifier is preconfigured in PCEF or provided in the PCC rule from the PCRF depends on network configuration.

M

C

For downlink packets all the service data flow templates, activated for the IP CAN session shall be applied for service data flow detection and for the mapping to the correct IP CAN bearer. For uplink packets the service data flow templates activated on their IP CAN bearer shall be applied for service data flow detection (further details provided in clause 6.2.2.2 and the IP-CAN specific annexes).

M

C

The PCC Charging key is the reference to the tariff for the service data flow. Any number of PCC Rules may share the same charging key value. The charging key values for each service shall be operator configurable.

NOTE 7: Assigning the same Charging key for several service data flows implies that the charging does not require the credit management to be handled separately.

M

C

NOTE 8: If the IP flow mobility is supported and the tariff depends on what access network is in use for the service data flow, then a separate Charging key can be allocated for each access network, and the PCRF can set the Charging key in accordance with the access network in use.

M

C

The PCC Service identifier identifies the service. PCC Rules may share the same service identifier value. The service identifier provides the most detailed identification, specified for flow based charging, of a service data flow.

NOTE 9: The PCC rule service identifier need not have any relationship to service identifiers used on the AF level, i.e. is an operator policy option

M

C

The Sponsor Identifier indicates the (3rd) party organization willing to pay for the operator's charge for connectivity required to deliver a service to the end user.

M

NC

The Charging method indicates whether online charging, offline charging, or both are required or the service data flow is not subject to any end user charging. If the charging method identifies that the service data flow is not subject to any end user charging, a Charging key shall not be included in the PCC rule for that service data flow, along with other charging related parameters. If the charging method is omitted the PCEF shall apply the default charging method as determined at IP CAN session establishment (see clause 6.4). The Charging method is mandatory if there is no default charging method for the IP CAN session.

M

C

The Measurement method indicates what measurements apply for charging for PCC rule.

M

C

The Service Identifier Level Reporting indicates whether the PCEF shall generate reports per Service Identifier. The PCEF shall accumulate the measurements from all PCC rules with the same combination of Charging key/Service identifier values in a single report.

M

C

The Application function record information identifies an instance of service usage. A subsequently generated usage report, generated as a result of the PCC rule, may include the Application function record information, if available. The Application Function Record Information may contain the AF Charging Identifier and/or the Flow identifiers. The report is however not restricted to include only usage related to the Application function record information reported, as the report accumulates the usage for all PCC rules with the same combination of Charging key/Service identifier values. If exclusive charging information related to the Application function record information is required, the PCRF shall provide a service identifier, not used by any other PCC rule of the IP CAN session at this point in time, for the AF session.

NOTE 10: For example, the PCRF may be configured to maintain a range of service identifier values for each service which require exclusive per instance charging information. Whenever a separate counting or credit management for an AF session is required, the PCRF shall select a value, which is not used at this point in time, within that range. The uniqueness of the service identifier in the PCEF ensures a separate accounting/credit management while the AF record information identifies the instance of the service.

M

NC

The Gate indicates whether the PCEF shall let a packet matching the PCC Service data flow template, pass through (gate is open) the PCEF or the PCEF shall discard (gate is closed) the packet.

NOTE 11: A packet, matching a PCC Rule with an open gate, may be discarded due to credit management reasons.

M

C

The QoS Class Identifier for the service data flow. The QoS class identifier represents the QoS parameters for the service data flow. The PCEF maintains the mapping between QoS class identifier and the QoS concept applied within the specific IP CAN. The bitrate information is separate from the QoS class identifier value.

M

C

The bitrates indicate the authorized bitrates at the IP packet level of the SDF, i.e. the bitrates of the IP packets before any IP CAN specific compression or encapsulation.

M

C

The UL maximum-bitrate indicates the authorized maximum bitrate for the uplink component of the service data flow.

The DL maximum-bitrate indicates the authorized maximum bitrate for the downlink component of the service data flow.

The UL guaranteed-bitrate indicates the authorized guaranteed bitrate for the uplink component of the service data flow.

The DL guaranteed-bitrate indicates the authorized guaranteed bitrate for the downlink component of the service data flow.

M

C

The 'Maximum bitrate' is used for enforcement of the maximum bit rate that the SDF may consume, while the 'Guaranteed bitrate' is used by the PCEF to determine resource allocation.

M

C

The UL sharing indication indicates that resource sharing in uplink direction for service data flows with the same value in their PCC rule shall be applied by the PCEF as described in clauses 6.1.14 and 6.2.2.4.

M

NC

The DL sharing indication indicates that resource sharing in downlink direction for service data flows with the same value in their PCC rule shall be applied by the PCEF as described in clauses 6.1.14 and 6.2.2.4.

M

NC

The Allocation and Retention Priority indicates theallocation retention and priority of the service data flow. The ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. The Allocation and Retention Priority resolves conflicts of demands for network resources.

M

C

The Bind to Default Bearer indicates that the dynamic PCC rule shall be bound to the default bearer.

M

NC

The Redirect indicates whether the uplink part of the service data flow should be redirected to a controlled address.

M

C

The Redirect Destination indicates the target redirect address when Redirect is enabled.

M

C

The PS to CS session continuity is present if the service data flow is a candidate for vSRVCC according to TS 23.216 [28].

M

NC

The access network information reporting parameters (User Location Report, UE Timezone Report) instruct the PCEF about what information to forward to the PCRF when the PCC rule is activated, modified or removed.

M

C

The Monitoring Key is the reference to a resource threshold. Any number of PCC Rules may share the same monitoring key value. The monitoring key values for each service shall be operator configurable.

M

NC

The SAPC only supports usage monitoring for predefined PCC rules.

The Indication of exclusion from session level monitoring indicates that the service data flow shall be excluded from the IP-CAN session usage monitoring.

M

NC

The Traffic Steering Policy Identifier(s) is a reference to a pre-configured traffic steering policy at the PCEF as defined in clause 6.11.1.

M

NC

The Allowed Access Type applies only in case of NBIFOM. The Allowed Access Type indicates the IP-CAN type that is to be used for the transfer of traffic identified by the PCC rule. When the Allowed Access Type is not provided within a PCC rule, the traffic identified by the PCC rule is to be transferred on the NBIFOM default access.

M

NC

The Routing Rule Identifier applies only in case of NBIFOM. The PCRF provides it to the PCEF only when network-initiated NBIFOM mode applies.

M

NC

The UL Maximum Packet Loss Rate indicates the maximum rate for lost packets that can be tolerated in the uplink direction.

Op

NC

The UL Maximum Packet Loss Rate indicates the maximum rate for lost packets that can be tolerated in the uplink direction.

Op

NC

Policy and charging control rule operations consist of activation, modification and de-activation of PCC rules.

M

C

Activation of a dynamic PCC rule provides the PCC rule information to the PCEF via the Gx reference point.

M

C

Activation of a predefined PCC rule provides an identifier of the relevant PCC rule to the PCEF via the Gx reference point.

M

C

A predefined PCC rule is known at least, within the scope of one access point.

NOTE 1: The same predefined PCC rule can be activated for multiple IP CAN bearers in multiple IP CAN sessions.

M

C

A predefined PCC rule is bound to one and only one IP-CAN bearer per IP CAN session. For a predefined PCC rule whose service data flow cannot be fully reflected for the uplink direction in terms of traffic mapping information sent to the UE, the PCEF may apply the uplink service data flow detection at additional IP CAN bearers with non-GBR QCI of the same IP CAN session The deactivation of such a predefined PCC rule ceases its service data flow detection for the whole IP CAN session.

M

C

UE-Init procedures are only supported for the default bearer. In UE_NW the PCEF decides the bearer/s to install the PCC rule.

The PCRF may, at any time, modify an active, dynamic PCC rule.

Op

C

The PCRF may, at any time, deactivate an active PCC rule in the PCEF via the Gx reference point. At IP CAN bearer termination all active PCC rules on that bearer are deactivated without explicit instructions from the PCRF to do so.

Op

C

Policy and charging control rule operations can be also performed in a deferred mode. .

M

C

A PCC Rule may have either a single deferred activation time, or a single deferred deactivation time or both.

Op

C

An inactive PCC rule, that has not been activated yet, is still considered to be installed, and may be removed by the PCRF.

Op

C

The PCRF may modify a currently installed PCC rule, including setting, modifying or clearing its deferred activation and/or deactivation time

Op

C

When modifying a dynamic PCC rule with a prior and/or new deferred activation and/or deactivation time, the PCRF shall provide all attributes of that rule, including attributes that have not changed.

M

C

Deferred activation and deactivation of PCC rules can only be used for PCC rules that belong to the IP CAN bearer without traffic mapping information. NOTE 2: This limitation prevents dependencies on the signalling of changed traffic mapping information towards the UE

M

C

Deferred modification of PCC rules shall not be applied for changes of the QoS or service data flow filter information of PCC rules.

M

C

The purpose of the TDF session related information is to provide information that is applicable to the whole TDF session. The PCRF provides the TDF session related information to the TDF (if applicable) using ADC rule provision procedure.

M

C

Charging Characteristics

M

NC

Charging information

M

NC

Default charging method

M

NC

Event trigger

M

PC

Only APPLICATION_START and APPLICATION_STOP Event triggers supported

Maximum downlink bit rate

M

NC

Maximum uplink bit rate

M

NC

ADC Revalidation time limit

M

NC

Upon the initial interaction with the TDF, the PCRF may provide Charging Characteristics to the TDF, if received from the PCEF, defining how to control TDF behaviour regarding online and offline charging.

Op

NC

Upon the initial interaction with the TDF, the PCRF may provide Charging information containing OFCS and/or OCS addresses to the TDF defining the offline and online charging system addresses respectively. These shall override any possible predefined addresses at the TDF. If received by the TDF, it supersedes the Primary OFCS/OCS address and Secondary OFCS/OCS address predefined at the TDF.

Op

NC

Upon the initial interaction with the TDF, the PCRF may provide Default charging method indicating what charging method shall be used in the TDF session for every ADC rule where the charging method identifier is omitted. If received by the TDF, it supersedes the defined Default charging method.

Op

NC

If Charging Characteristics are received by the PCRF from the PCEF, the PCRF may take them into account when providing Charging information and Default charging method to the TDF. In case the TDF receives both Charging Characteristics and Charging information and Default charging method parameters, the Charging Information and Default charging method shall supersede the values received in Charging Characteristics.

Op

NC

Upon every interaction with the TDF, the PCRF may provide Maximum downlink bit rate and/or Maximum uplink bit rate for the TDF session.

NOTE: To avoid down-link packets being discarded in PCEF when TDF performs charging, the PCRF should set the Maximum downlink bit rate to the DL APN-AMBR.

Op

NC

Upon every interaction with the TDF, the PCRF may provide event triggers for the TDF session. Event triggers are used to determine which event causes the TDF to re-request ADC rules. The triggers applicable for the TDF are listed in clause 6.1.4.

Op

PC

Event triggers are only provided during TDF session establishment

The ADC Revalidation time limit defines the time period within which the TDF shall trigger a request for ADC rules for an established TDF session.

M

NC

The purpose of the APN related policy information is to provide policy and charging control related information that is applicable to all IP CAN sessions of a UE to the same APN. The PCRF provides APN related policy information to the PCEF using the PCC provision procedure together with PCC rules or separately.

M

PC

Authorized APN-AMBR

M

C

Subsequent APN-AMBR

M

NC

APN-AMBR change time

M

NC

The PCRF may provide the (unconditional) Authorized APN-AMBR in every interaction with the PCEF. The PCEF shall apply the Authorized APN-AMBR as APN-AMBR for all IP CAN sessions of the UE to the same APN and shall communicate the changed APN-AMBR to the UE.

NOTE 1: There is always an unconditional value for the APN-AMBR available at the PCEF. The initial value is received as Subscribed APN-AMBR in an access specific manner and the PCRF can overwrite it by providing an Authorized APN-AMBR.

NOTE 2: In order to reduce the risk for signalling overload, the PCRF should avoid simultaneous provisioning of Authorized APN-AMBR for many UEs (e.g. by spreading over time).

Op

C

The Authorized APN-AMBR may be provided together with conditions, i.e. a list of RAT types and/or a list of IP-CAN types. One or multiple instances of conditional APN-AMBR, with different conditions, may be provided by the PCRF. The PCEF shall apply a conditional Authorized APN-AMBR as APN-AMBR only if the current RAT type and IP-CAN type match one of the RAT types and IP-CAN types specified in the conditions, respectively. Otherwise the PCEF shall apply the unconditional Authorized APN-AMBR as APN-AMBR. A changed APN-AMBR shall be communicated to the UE.

NOTE 3: Guidance what conditional Authorized APN-AMBR value to use in case the current RAT type and IP-CAN type match multiple conditional Authorized APN-AMBRs is specified in stage 3.

Op

C

Conditional Authorized APN-AMBR(s) are not applied for a PDN connection supporting NBIFOM.

M

C

Upon PCRF changing the unconditional Authorized APN-AMBR or providing a conditional Authorized APN-AMBR, the PCEF shall discard any previously received conditional Authorized APN-AMBR.

M

C