H.4 EPC-based untrusted non-3GPP Access

23.2033GPPPolicy and charging control architectureRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

In an EPC-based untrusted non 3GPP Access, the BBERF does not apply.

Specific event triggers and credit reauthorization triggers are listed in table H.4.

Table H.4: Untrusted non-3GPP access specific event/credit reauthorization triggers

Event/Credit reauthorization trigger	Description	Reported from	Condition for reporting
RAT type change.	The characteristics of the air interface, communicated as the radio access type, have changed.	PCEF	PCRF/OCS

For an IP-CAN session set-up over an untrusted non-3GPP access over S2b:

– At IP‑CAN Session Establishment the PCEF provides IP-CAN type, indication that it is untrusted RAT type, ePDG IP address and the Serving Network Identifier to the PCRF. This occurs at step 3 of Figure 7.2-1 (IP‑CAN Session Establishment). This information is also provided by the PCEF to the charging entities as described in TS 32.251 [9]. The PCEF provides also the PCRF with User location information it may have received from the ePDG. As defined in TS 23.402 [18], this User location information may contain: ePDG IP address used in IKEv2 tunnel procedures. The local IP address and the UDP or TCP port number (if NAT was detected) detected by the ePDG as the source of the UE traffic over Swu.

– WLAN Location Information and the WLAN Location Information Age. The TWAN ID within the WLAN location Information includes the identifier of the operator of the TWAN as defined in clause 16 of TS 23.402 [18].

– The IP-CAN type changes, the PLMN change event trigger defined in clause 6.1.4 and RAT type changes event trigger applies. The PCEF reports to PCRF when a Create Session Request is received including information that the UE moved to an untrusted WLAN access. This information is also provided by the PCEF to the charging entities as described in TS 32.251 [9]. As described for the case of an IP‑CAN Session Establishment, the PCEF provides also the PCRF with location information it may have received from the ePDG and the ePDG IP address used in IKEv2 tunnel procedures.

– When the PCRF subscribes to any of the listed above event triggers using the Provision of PCC Rules procedure, the PCEF provides the parameter values in the response back to the PCRF, as defined in clause 6.1.4.

– The Access Network Information Report event trigger defined in clause 6.1.4 applies. As defined in TS 23.402 [18], the user location information within the Access Network Information reporting may contain:

– The local IP address and the UDP or TCP port number (if NAT was detected) detected by the ePDG as the source of the UE traffic over Swu.

– WLAN Location Information and the WLAN Location Information Age.

When the Access Network Information reported by the PCRF to the AF corresponds to the local IP address used by the UE to reach the ePDG, this information cannot be considered as reliable.

NOTE 1: This is because the UE can spoof its IP address.

– When the IP-CAN session is terminated a UWAN Release Cause (if available) is provided to the PCRF. As defined in TS 23.402 [18], the User Location Information within the Access Network Information reporting may contain:

– The local IP address and the UDP or TCP port number (if NAT was detected) detected by the ePDG as the source of the UE traffic over Swu.

– WLAN Location Information and the WLAN Location Information Age defined in TS 23.402 [18]

When the PCEF receives no user location information from the ePDG, it provides at least information on the Serving Network of the ePDG.

The PCRF reports the ePDG IP address used in IKEv2 tunnel procedures to the AF (i.e. P-CSCF) at the time the AF instructions as described in clause 6.2.3 are received and the ePDG IP address is available, i.e. at the time the AF session is established and at the time the PCRF reports IP-CAN type change, if the AF (i.e. P-CSCF) subscribes to it.

The AF instruction to report changes of the IP‑CAN type is described in clause 6.2.3 including an indication that the access type is untrusted.

NOTE 2: In order to provide more detailed information to the AF about the characteristics of the access when the RAT type is unknown, the information on whether the access is untrusted is provided.

It shall be possible for the PCRF to authorize the QCI and ARP of the default EPS bearer to be enforced by the PCEF immediately or at a specific point in time by providing the default EPS bearer related policy information as defined in clause A.4.3.4.

Annex I (informative):
Void

Annex J (informative):
Standardized QCI characteristics – rationale and principles

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.

NOTE 1: TS 23.107 [14] permits the definition of more than 1600 valid GPRS QoS profiles (without considering GBR, MBR, ARP, and Transfer Delay) and this adds unnecessary complexity.

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

NOTE 2: The TCP’s congestion control algorithm becomes increasingly sensitive to non congestion related packet losses (that occur in addition to congestion related packet drops) as the end-to-end bit rate increases. To fully utilise "EUTRA bit rates" TCP bulk data transfers will require a PLR of less than 10^-6.

Annex K (informative):
Limited PCC Deployment

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 [18]; 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).

Annex L (normative):
Limited PCC Deployment

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.

Annex M (informative):
Handling of UE or network responsibility for the resource management of services

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.

Annex N (informative):
PCC usage for sponsored data connectivity