D.2 QoS Provisioning

32.1013GPPPrinciples and high level requirementsRelease 17Telecommunication managementTS

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

D.2.0 Introduction

In the 3GPP systems, multiple network domains must inter-work in order to provide the end-to-end quality of service required by end-user applications. To add to this complexity, there are many classes of Network Elements from many network infrastructure suppliers, each of which require configuration in a consistent manner in order to the network operator’s QoS objectives. Within each Network Element, there are many QoS functions (such as Admission Control, Policers, Shapers, Queue Manager and Scheduler), which must be configured.

In order to configure these heterogeneous networks so that they can deliver the desired QoS, the operator needs a management solution that meets the following high-level requirements:

– Automation of management tasks.

– Centralized management with fewer classes of management interface.

– Abstracted (or simplified) management data.

– End-to-End provisioning of the network.

– Consistent and uniform provisioning across all Network Elements.

– Standards-based solution in order to allow inter-operability at Network Element and OSS level.

– Scalable solution for large networks.

The IETF Policy Management Framework has been designed with these requirements in mind

The various standards that apply to QoS Policy Provisioning as described in the following clauses are listed in D.4.1. At time of publication of the present document there are also a significant amount of IETF Drafts available on the subject at http://www.ietf.org,

D.2.1 Conceptual Architecture

The conceptual architecture for a policy-based QoS Management System is shown in figure D.2.

Figure D.2: QoS Provisioning

The architectural components identified in figure D.2 are described in the following clauses.

NOTE: The Policy Repository and the Policy Decision Point can be implemented on the same node.

The Itf N interface is specified in the 32 series.

The Itf Po, between the Policy Repository and the Policy Decision Point is to be defined. The protocols under consideration includes: LDAP, LDUP, SNMP and COPS-PR.

The reference point Go is defined in TS 23.207 (see D.4 QoS Management Reference [22]) and the interface implementing the reference point is defined in TS 29.207 (see D.4 QoS Management Reference [23]).

D.2.2 NML QoS Policy Provisioning

This is a network-level operational support function that serves as the policy administration point for the entire network.

The NML QoS Policy Provisioning provides the following functions:

– Network policy administration user interface

– Master network policy repository for storage of all network policies for all domains

– Policy distribution capability to distribute policy data to the EML Policy servers.

– Global policy conflict detection

The policy repositories will use an LDAP-based directory to store the policy information.

D.2.3 EML QoS Policy Provisioning

This is an element management function that serves as the policy administration point for a network domain. A domain is an area of the network that contains equipment that performs a logically related function. Examples of network domains are: access network, core network and transport network, or supplier specific sub-networks within these networks.

The EML QoS Policy Provisioning provides the following functions:

– An optional EML-level policy administration user interface.

– EML-specific policy repository.

– Policy distribution capability to distribute policy data to the Policy Decision Points.

– Local policy conflict detection

It is envisioned that the optional EML-level policy administration user interface will be required in small networks that do not have a network-level policy provisioning OSS.

Note that EML-specific policy repositories contain policies that apply only to that domain as well as general network policies that apply across domains.

D.2.4 Policy Decision Point

The Policy Decision Point is the point in the network at which policy decisions are made for the Policy Enforcement Points under its scope of control. Whereas the Policy Enforcement Point is a function within a network node, the Policy Decision Point is separate functional entity that may reside within a separate Policy Server, for example, on an application server. The Policy Decision Point will make decisions based on the policy information held within the Policy Repository.

The Policy Decision Point provides the following functions:

– Retrieval of Policy Information from the policy repository

– Evaluates the policy information retrieved and decides what actions needs to taken.

– Distributes policy data to the Policy Enforcement Points. This distribution can either be sent to the PEP by the Policy Decision Point or the Policy Decision Point can wait for the PEP to request the information.

– Translation from QoS policy schema employed by the policy servers to Policy Information Base (PIB) format employed by the Policy Enforcement Points.

– Optional real-time policy decision-making function.

– Local policy conflict detection

The optional real-time policy decision-making function may be required when dynamic policy decisions must be made in response to current network conditions.

NOTE: The 3GPP Term Policy Decision Function (PDF) used in 23.207 and 29.207 is equivalent to the IETF Term Policy Decision Point.

TS 23.207 describes the End-to-end Quality of Service (QoS) concept and architecture, and TS 29.207 describes Policy control over Go interface (see D.4 QoS Management Reference [22]) and TS 29.207 (see D.4 QoS Management Reference [23]). If there are any inconsistencies then the definitions in 23.207 and 29.207 take precedence.

D.2.5 Policy Enforcement Point

The Policy Enforcement Point is a function that is part of a Network Element that must implement the policies defined by the policy administration system(s).

The Policy Enforcement Point provides the following functions:

– Storage of policy-related data locally.

– Execution of policies as network conditions dictate.

– Support for the Differentiated Services QoS mechanism (diffserv).

On initialization, the Policy Enforcement Point will contact its parent Policy Decision Point and request download of any policy data that it requires for operation. Note that information such as the address of the parent Policy Decision Point function must be provisioned in the Policy Enforcement Point MIB as part of normal network provisioning.