The precedence information is part of the PCC rule (see clause 6.3.1) and instructs the PCEF in which order the service data flow templates of the active PCC rules needs to be analyzed when an IP packet arrives. This mechanism ensures that the service data flows can be correctly identified even if the service data flow templates contain overlapping service data flow filters. For PCC rules that contain an application identifier (i.e. that refer to an application detection filter), the order and the details of the detection are implementation specific. Once an application has been detected, enforcement and charging shall however be applied under consideration of the PCC rule precedence, i.e. when multiple PCC rules overlap, only the enforcement and charging actions of the PCC rule with the highest precedence shall be applied. Within the PCC framework it is possible to use different types of PCC rules for which the service data flow templates may not always be known by the PCRF. Therefore, the PCC rule precedence information needs to be carefully configured to avoid certain situations e.g. a dynamic PCC rule cannot be applied for service data flow detection due to a predefined PCC rule not known to the PCRF with overlapping filter information and a higher precedence. For example, an operator could structure the value range of the precedence information into separate value ranges (in decreasing order) for the different types of PCC rules as follows:

• dynamic PCC rules;
• predefined PCC rules known to the PCRF;
• predefined PCC rules not known to the PCRF;
• dynamic PCC rules for non-operator controlled services, i.e. those which are generated by the PCRF based on the UE provided traffic mapping information (and which take over the UE provided precedence information).

The following bullets capture design rationale and principles with respect to standardized QCI characteristics:

• A key advantage of only signalling a single scalar parameter, the QCI, as a "pointer" to standardized characteristics - as opposed to signalling separate parameters for resource type, priority, delay, and loss - is that this simplifies a node implementation.
• In general, the rate of congestion related packet drops can not be controlled precisely for Non-GBR traffic. This rate is mainly determined by the current Non-GBR traffic load, the UE's current radio channel quality, and the configuration of user plane packet processing functions (e.g. scheduling, queue management, and rate shaping). That is the reason why services using a Non-GBR QCI should be prepared to experience congestion related packet drops and/or per packet delays that may exceed a given PDB. The discarding (dropping) of packets is expected to be controlled by a queue management function, e.g. based on pre-configured dropping thresholds, and is relevant mainly for Non-GBR QCIs. The discarding (dropping) of packets of an SDF aggregate mapped to a GBR QCI should be considered to be an exception as long as the source sends at a rate smaller than or equal to the SDF aggregate's GBR. Under these exceptional conditions, when required by operator policy, the eNodeB can be configured to also use the bearer's ARP priority level to assess the relative priority of packets belonging to different SDFs in determining whether to discard a packet or not.
• An operator would choose GBR QCIs for services where the preferred user experience is "service blocking over service dropping", i.e. rather block a service request than risk degraded performance of an already admitted service request. This may be relevant in scenarios where it may not be possible to meet the demand for those services with the dimensioned capacity (e.g. on "new year's eve"). Whether a service is realized based on GBR QCIs or Non-GBR QCIs is therefore an operator policy decision that to a large extent depends on expected traffic load vs. dimensioned capacity. Assuming sufficiently dimensioned capacity any service, both Real Time (RT) and Non Real Time (NRT), can be realized based only on Non-GBR QCIs.

Limited support for policy provisioning occurs in certain deployment scenarios. If PCC is deployed in the HPLMN but not the VPLMN, dynamic policy provisioning only occurs in the home routed roaming cases if no BBERF is employed, or in the non-roaming scenarios. In roaming scenarios in which the PCC is deployed in the HPLMN but not the VPLMN, and a GW (BBERF) is used:

• limited policy control is possible when the UE moves from the HPLMN to the VPLMN. In the VPLMN, the UE receives only service according to static policies or according to static subscriber policies, defined outside the PCC framework delivered as described in TS 23.402; the dynamically allocated resources associated with specific EPS Bearers no longer apply after this transition.
• If a UE moves from the VPLMN to the HPLMN, dedicated resource establishment procedures are used to dynamically allocate the appropriate resources in the HPLMN for EPS bearers.
• PCC may still be employed to provision rules to the PCEF/TDF for the purpose of charging on the basis of the IP-CAN session.

When PCC is supported in the VPLMN and not in the HPLMN, dynamic policy may only be provided for the LBO case. As the VPCRF has no access to subscriber policy information from the HPLMN, only static policy will apply. The VPCRF may however interact with the AF in the VPLMN in order to determine dynamic policy operating entirely in the VPLMN. This policy will be enforced either in the PCEF or the BBERF or the TDF to be enforced entirely in the VPLMN. Bearer binding will occur under control of the VPLMN, either in the GW (BBERF) or in the GW (PCEF) (in the case of GTP-based S5/S8 for 3GPP access).

In roaming scenarios in which the PCC is deployed in the HPLMN but not the VPLMN, and a GW (BBERF) is used:

• HPCRF and OCS shall detect based on local configuration according to roaming agreements that the event reporting is restricted. The OCS shall not set re/authorization triggers which would require event reporting that can not be generated.
• The H-PCRF shall inform the AF of event triggers that cannot be reported. The H-PCRF shall inform the AF of events that cannot be reported when AF registers event trigger to the H-PCRF. When the H-PCRF detects limited PCC deployment, some event triggers which are dependent upon reporting from the BBERF cannot be reported. The H-PCRF shall inform the AF of events that cannot be reported when the UE is in or after the UE has handed over to an Access Gateway where the BBERF functionality is not deployed.

For access networks supporting network initiated resource signalling, the network can take over the responsibility for the resource management for a service. This means the network triggers the request for resources when the service is started or modified and triggers the release of the resources when the service is terminated. The UE remains responsible for starting the service or reacting to an incoming service signalling and needs to decide about how to proceed with the service if the desired resources are not available. As the network initiated resource signalling cannot always be used due to UE, access network, roaming or other restrictions, the default responsibility for the resource management for a service is given to the UE. However, the UE and the PCRF may be configured on a per service basis to make use of the network responsibility for resource management if the current access network allows this, i.e. if network initiated resource signalling is possible. The UE configuration regarding the responsibility for the resource management of a service might be updated by device management. Regarding the PCC functionality, the main difference between the UE and the network responsibility for resource management is in the PCRF behaviour. When the UE is responsible, the PCRF waits with the authorization and installation of PCC rules until an appropriate resource request arrives. The main criteria for authorizing a PCC rule is a match of the service data flow filter information with the UE provided traffic mapping information, i.e. the UE desire to run this service on the requested resource. The QoS requested by the UE is then aligned with the authorized QoS for the PCC rules that are associated with the resource request by the PCRF. When the network is responsible for the resource management, the PCRF authorizes PCC rules immediately, i.e. when the IP-CAN session is established and when new service information is received from the AF. The authorized PCC rules are installed afterwards.