D.2 WiMAX IP‑CAN

23.2033GPPPolicy and charging control architectureRelease 17TS

In the WiMAX IP‑CAN, the UE (also referenced as Mobile Station or MS in IEEE 802.16 standards) connects to the WiMAX Access Service Network (ASN). The ASN logically communicates with a Connectivity Service Network (CSN) which is a collection of core networking functions (e.g. Mobile IP HA, AAA Server, DHCP, DNS etc.). The ASN manages traffic admission and scheduling, enforces QoS for an authorized UE and performs accounting functions for the UE (per session, flow, or UE). WiMAX PCEF is part of WiMAX IP‑CAN and is to be defined by WiMAX Forum [15]. WiMAX PCEF terminates the Gx reference point from the PCRF and may be a distributed enforcement architecture.

The PCC functional mapping to WiMAX IP‑CAN is shown in the following figure where PCC Gx and Rx are applied.

Figure D.2.1: WiMAX IP‑CAN and 3GPP PCC

D.2.1 High level requirements

D.2.1.1 General

No new requirements have been identified.

D.2.1.2 Charging related requirements

No new requirements have been identified.

D.2.1.3 Policy control requirements

No new requirements have been identified.

D.2.2 Architecture model and reference points

D.2.2.1 Reference points

D.2.2.1.1 Rx reference point

WiMAX IP‑CAN imposes no new requirements to the Rx reference point.

D.2.2.1.2 Gx reference point

WiMAX IP‑CAN imposes no new requirements to the Gx reference point other than WiMAX specific values for existing Gx parameters (e.g. RAT type) as described in [15].

D.2.2.1.3 Sp reference point

WiMAX IP‑CAN imposes no new requirements to the Sp reference point.

D.2.3 Functional description

D.2.3.1 Overall description

The WiMAX IP‑CAN employs for an IP‑CAN bearer, the concept of a WiMAX service flow, in order to provide a data path between the UE and the WiMAX CSN via the ASN. When a UE is registered in the WiMAX IP‑CAN, it is associated with one or more WiMAX service flows. Based on session information provided by the AF via the Rx reference point, the PCRF determines the QoS requirements for each service by constructing PCC rules. The PCRF requests the WiMAX IP‑CAN via Gx interface to enforce the authorized PCC rules on the WiMAX service flows. The PCEF function in the WiMAX IP‑CAN enforces the PCC rules received from the PCRF. Provided that resources are available, the ASN creates and configures logical bearers and enforces creation of appropriate traffic classes associated with service flows compliant with IEEE 802.16 standards for the air interface and IP‑CAN bearer capabilities in the ASN (e.g. DiffServ).

D.2.3.1.1 Binding mechanism

D.2.3.1.2 Credit management

D.2.3.1.3 Event triggers

D.2.3.2 Functional entities

D.2.3.2.1 Policy Control and Charging Rules Function (PCRF)

The 3GPP PCRF is used for the WiMAX IP‑CAN. The PCRF interacts with WiMAX IP‑CAN using 3GPP Gx reference point.

D.2.3.2.2 Policy and Charging Enforcement Function (PCEF)

For WiMAX IP‑CAN, PCEF functions may be distributed. It additionally:

– Terminates the Gx reference point from PCRF and may act as a proxy for the PCRF.

– Handles the enforcement function relocation in WiMAX IP‑CAN in a way that is transparent to the PCRF.

D.2.3.2.3 Application Function (AF)

WiMAX IP‑CAN imposes no requirements to the AF functionalities.

D.2.3.3 Policy and charging control rule

D.2.3.3.1 General

D.2.3.3.1 Policy and charging control rule operations

Annex E (informative):
Void

Annex F (informative):
Void

Annex G (informative):
PCC rule precedence configuration

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.

NOTE: This ensures that traffic described by service data flow filters can be precluded from the enforcement of application detection filter based PCC rules if this is necessary (e.g. for sponsored data connectivity).

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

Annex H (normative):
Access specific aspects (EPC-based Non-3GPP)