If usage for a PCC/ADC rule is accumulated in multiple Monitoring Groups, the following solution re-uses the capabilities defined in the main body of this specification, the steps are described below:

1. The PCRF retrieves the total group allowance for the Monitoring Group and the set of services belonging to the Monitoring Group from the SPR.
2. For dynamic PCC/ADC Rules, the PCRF selects a Monitoring Key for those services that belongs to more than one Monitoring Group but does not have an individual Monitoring Key assigned.
3. For pre-configured PCC/ADC Rules the PCRF selects the PCC/ADC Rules for each of the services that belong to the monitoring group. For pre-configured PCC/ADC Rules, the PCEF is configured with an individual Monitoring Key that monitors the usage.
4. The PCRF calculates a usage threshold for each of these Monitoring Keys taking into account the minimum of the individual service allowance and the monitoring group allowance(s) the service belongs to.
5. The PCRF installs or activates the PCC/ADC Rule. The PCRF provides a usage threshold for each Monitoring Key.
6. When the PCRF receives a usage report for a Monitoring Key from the requested node (PCEF or TDF), the PCRF shall deduct the value from the corresponding group allowances and from the individual allowance if needed.
7. As long as all group usage allowances are not reached, the PCRF calculates a new usage threshold for the Monitoring Key based on the corresponding group allowances the service belongs to.

In order to provide policy and charging control (e.g. QoS enforcement) in the downlink direction for applications with non-deducible service data flows detected by the TDF, in addition to the solution described in clause 4.5, the following solution is defined: The TDF shall be able to mark detected downlink application traffic with a DSCP value received within an installed ADC Rule matching this traffic. To ensure that the DSCP value used for service data flow detection is not visible to the operator's transport network, based on operator configuration, a tunnelling protocol may be used between TDF and PCEF. In case tunnelling is used then the DSCP value used for service data flow detection shall be carried in the inner IP header. The DSCP marking used in the operator's transport network is carried in the outer IP header of the tunnel. In order to support policy and charging control in the downlink direction by the PCEF/BBERF for an application detected by the TDF (typically for services with non -deducible service data flows), the PCRF shall either install a dynamic PCC/QoS Rule or activate a pre-defined PCC rule, which identifies traffic based on the corresponding DSCP value (provided by the ToS/Traffic Class mask field within the service data flow filter). In case tunnelling is used, the PCEF shall use the inner header's DSCP for the service data flow detection defined in clause 6.2.2.2.

With the Proximity-based services, in accordance with TS 23.303, a UE acting as a Remote UE can connect to a PDN via a ProSe UE-to-Network Relay UE, using an IP-CAN session that the Relay UE has established. The Relay UE is assigned an IPv6 prefix that is shorter than /64. The PCRF does not get any Remote UE identity and is not required to be aware of the Remote UE but is expected to validate Remote UE related service information from the AF and generate any necessary PCC rules according to standard procedures already defined. PCC rule authorizations may be static (e.g. predefined PCC rules) or rely on AF provided service information. An AF serving a remote UE reaches the appropriate PCRF based on the IPv6 prefix that the UE-to-Network Relay UE has assigned to the remote UE. The AF reaches the appropriate PCRF by performing a PLMN lookup for the IPv6 prefix and using the Network Realm/Domain, as defined in TS 23.003, associated with the PLMN. In order to make a PCC rule specific for a certain Remote UE, the SDF filters used for traffic detection need to include the attribute Local Address and Mask with a value that corresponds to the Remote UE only. The value is normally an IPv6 prefix that is longer than the prefix assigned for the IP-CAN session (i.e. for the ProSe UE-to-Network Relay UE).

For the cases when it is required to detect and enforce/charge sponsored services within encrypted traffic, and those sponsored services are uniquely identifiable by a list of {IP address ranges, domain name matching strings, match type (absolute/suffix)} set, while either element in the pair of {IP address ranges, domain name matching strings} can be "any", as applicable, but not both elements simultaneously, the domain name matching solution described below may be used. The following assumptions apply for the solution:

• There exists an agreement between the operator and sponsored data connectivity content provider.
• Content provider uses HTTPS as a transport mechanism, using Web Public Key Infrastructure (PKI).

The set of information {IP address ranges, domain name matching strings, match type (absolute/suffix)} required to identify encrypted traffic is defined in the PCEF/TDF either by using pre-defined PCC/ADC Rules or by using dynamic PCC/ADC Rules that include Application Identifiers, as applicable. The detection logic to which Application Identifier in the PCEF/TDF refers to, is extended to cover ({IP address ranges, domain name matching strings, match type (absolute/suffix)} information. If such a pre-defined or dynamic PCC/ADC Rule is active for an IP-CAN/TDF session, the PCEF/TDF shall check IP address ranges, and, in case of compliancy with the received/preconfigured value (see note 2), match domain name strings, either absolutely or by suffix, against the following fields in the initial HTTPS handshake:

• TLS Server Name Indication (SNI) extension, when available (see [47]); or, if not available.
• Server certificate's Subject Alternative Name x.509 extension DNS name, when available. All relevant values shall be examined for matching; or if not available or no match was found.
• Server certificate's Subject Common Name (CN).

The information required for the detection of sponsored HTTPS (i.e. defined in Annex X to be pre-configured in the PCEF/TDF and either the TLS SNI extension or the Server certificate's Subject Alternative Name x.509 DNS name or Server certificate's Subject CN) is verified with the corresponding server IP address/prefix of the IP packets by the PCEF/TDF. The PCEF/TDF uses implementation specific logic to perform this verification.