|
[ Also see: Part
2 ]
Overview and Comparison of QoS Control in Next Generation Networks
Part 1
By Cathal Mc Daid
Abstract - A variety of Next Generation Networks are currently
being developed throughout the telecommunications industry, each with
differing origins and designs. The unifying aim of these networks is to
deliver an acceptable end-user experience. To achieve this a central QoS
control point must be provisioned to link, control and thus ensure that
the differing strands of communication required to deliver that user
experience are handled appropriately. This article reviews how the control
entity is implemented and designed within the differing Next Generation
Network topologies, and how its roles and functions compare depending on
the network model being standardized.
Introduction
Traditionally control of Quality of Service (QoS) within
telecommunications networks has been achieved by a combination of
best-effort data delivery, network resources reservation (IntServ) or data
packet marking (DiffServ) on data communication paths. However the design
of emerging Next Generation Network (NGN) architectures will render this
approach no longer viable. A key feature of network topology within the
various NGNs is that the signaling required to negotiate a data transfer
(the application signaling) may not travel on the same logical path as the
actual data transfer itself (the data traffic). Therefore an entity must
be inserted to link the application signaling on the "upper"
service plane to data traffic on the "lower" transport plane, to
allow a means for applications to request QoS to be performed on the
traffic plane. To achieve this, the policy entity requires a variety of
functions such as QoS authorization, service-to –traffic QoS mapping and
the means to provision the resultant QoS policy decided. This policy
entity should also (ideally) take into account the QoS control end-to-end,
i.e. operating across combinations of networks, carriers and service
providers which will comprise the future NGNs. However due to the plethora
of NGN standards being developed this policy control entity's roles and
functions varies considerably. This article will outline the means of QoS
control within 6 differing NGN architecture standards:
- 3GPP IMS
- 3GPP2 MMD
- ITU-T NGN-GSI
- ETSI TISPAN
- CableLabs® PCMM
- MSF
and examine the similarities and differences between them.
3GPP IMS
The 3rd Generation Partnership Project group is an
open-standards body founded in December 1998, originally producing
Specifications and Technical Reports based on evolved GSM core networks.
Currently 3GPP is finalizing standardization of the 3GPP IP Multimedia
Subsystem (IMS).
Within IMS the PCRF (Policy and Charging Rules Function) [1] is
the policy entity that forms the linkage between the service and transport
layers. The PCRF collates subscriber and application data, authorizes QoS
resources, and instructs the transport plane on how to proceed with the
underlying data traffic.
The PCRF is connected on its northbound Rx interface to the Application
Function (AF), an element residing on the service plane, which represents
applications that require dynamic policy and QoS control over the traffic
plane behavior. Within an IMS network, a P-CSCF would commonly fulfill the
role of an AF.
On the traffic plane, connected to the PCRF via the southbound Gx
interface, is the Policy and Charging Enforcement Function (PCEF).
The PCEF's role encompasses applicable traffic detection and resultant
policy enforcement. This entity is typically located at a Gateway node,
which varies by transport layer (e.g. a GGSN, PDG etc.). A Subscriber
Policy Register (SPR) node also provides subscriber specific data to the
PCRF, to assist in evaluating policy decisions.
Figure 1: Positioning of Elements in NGN Networks
QoS control is applied per service data flow in the PCEF, these service
data flows can be thought of as a set of packet flows, typically IP flows.
The PCEF utilizes PCC (policy and charging control) rules to classify
traffic by service data flow. Rules can be pre-defined or dynamically
provisioned in the PCEF. Dynamic PCC rules are derived within the PCRF
from information supplied by the AF (such as requested bandwidth), PCEF
data (such as requested QoS at traffic level by user) and other Subscriber
specific data if available. Provisioning of rules via the Gx interface to
the PCEF can take place in two ways:
- "Pushed" – i.e. unsolicited provisioning, where the PCRF
may decide to provision PCC rules without obtaining a request from the
PCEF, or
- "Pulled" – i.e. where Provisioning has been solicited by
a request from the PCEF.
Each rule uses a series of data flow filters to allow the PCEF to
detect the relevant traffic plane packets. The resultant activated PCC
rule contains a QoS class identifier and the uplink + downlink bit-rates
authorized for the service data flow. As each PCC rule can only be bound
to a single data bearer (i.e. for GPRS the data bearer would be the PDP
context), this may require a series of rules to be installed to control
QoS across multiple underlying traffic bearers.
The actual policy enforcement procedures for authorized QoS per PCC
Rule is bearer dependent, possible procedures include Packet scheduling,
data packet (Diffserv) marking, and packet discarding. Gating control is
achieved by opening or closing the gate contained within the current
active PCC rule per data flow. Event mechanisms can also be set by the
PCRF in the PCC rules to cause the PCEF to inform it of changes in the
underlying traffic bearer.
3GPP2 MMD
The 3rd Generation Partnership Project 2 is an
open-standards body, founded in late 1998, to produce standards based on
the CDMA2000 3G model. 3GPP2 is currently in the process of defining
Release B of the all-IP core network Multimedia Domain (MMD), an
architecture closely based on the IMS network being standardized by 3GPP.
Within the MMD model, control of QoS is part of the Service Based
Bearer Control mechanism, the policy decision point here is also termed
the Policy and Charging Rules Function (PCRF)[2]. This PCRF has a
northbound interface (Tx) to an Application Function - AF (e.g. a P-CSCF)
that is responsible for application level service decisions, whereas the
southbound interface (Ty) connects the PCRF to the Access Gateway - AGW
(e.g. a PDSN), that is responsible for bearer resources policy
enforcement.
Policy based QoS authorization and control can be Service Based,
Subscriber Based, and/or and Local Resource Based Policy. Not all
authorization and control methods may be used in any one data session,
however all must agree in order for the control to be implemented.
Regardless of the origin of the policy control, the PCRF always has the
last say regarding use of local resources.
1) Service Based: This form of
control is essentially the authorization for use of bearer resources in
the access network based on negotiation between what the user requests and
what the network can support. The QoS control sequence of events depends
on whether a "Push" or "Pull" model is applied. In the
Pull model, the User (1) exchanges application information (e.g.
bandwidth, media type in SDP) with the AF. The AF maps the
application-level signalling to service data flows passed to the PCRF(2).
At some later point the subscriber makes a request to reserve bearer
resources from the AGW (3). The AGW passes the subscriber's binding
information to the PCRF (4). The PCRF matches the traffic information to
the authorized service data flow, optionally requests more information
(5), and then authorizes the packet flow by sending the authorized QoS to
the AGW (6). The AGW compares the requested QoS to the authorised QoS and
creates a gate for each packet flow. Finally the AGW informs the UE that
bearer resources have been granted (7), allowing the traffic to flow. The
Push model follows the same principle, except in this model the AGW has
already established an association with the PCRF (3), so that the
authorized QoS parameters are directly pushed to the AGW upon their
receipt from the AF (6), and therefore the AGW does not need to forward
the binding information to the PCRF
Figure 2: Pull QoS Authorization flow (3GPP2 model)
2) Subscriber Based: This is the authorization for use of bearer
resources in the access network based on a user's subscription; a typical
authorizing entity in this model is an AAA server. This form of QoS
control is subscriber specific and would typically be applied as part of
admission control, or as part of a Local Resource policy.
3) Local Resource Based: This is policy that is applicable to a
particular operator or local area. It is enforced within the PCRF as part
of its input in sending authorized QoS parameters to the AGW, is only
considered during bearer resource authorization and is not communicated to
AFs.
ITU-T NGN-GSI
The ITU-T, founded in 1992, is the standards body subcommittee of the
International Telecommunication Union (ITU). Currently ITU-T is
standardizing what it refers to as the Next Generation Network, under the
umbrella of the Global Standards Initiative (NGN-GSI).
Within the ITU-T NGN Release 1 model [3], the Resource and Admission
Control Functions (RACF), is the linkage entity between the service
and traffic planes. In this model, there is a split within the RACF, with
a PD-FE handling the upper application specific QoS control, and a TRC-FE
making lower transport dependent QoS control decisions.
- The PD-FE provides a single northbound contact point (Rs) to the
Service Control Functions (SCF) requiring QoS control. It role is to
make the final decision on resource and admission control in the
network under its control, map the service QoS requested to network
QoS parameters, and instruct (Rt) the TRC-FE to detect and determine
the required QoS resources along the transport path.
- The TRC-FE's role is to deal with the diversity of the underlying
transport technologies, monitor the availability of resources, and
provide resource-based admission control decisions to the PD-FE.
Both the PD-FE and TRC-FE have southbound interfaces to the transport
layer, with the PD-FE communicating with the PE-FE (Rw) in the transport
layer; to enforce dynamic QoS and resource control, gating, as well as
features needed for multi-domain QoS, such as NAT traversal and NAPT
control. The TRC-FE maps received network QoS parameters to transport
(technology dependent) QoS parameters, and gathers information and traffic
performance from the underlying transport function (Rc), in order to
authorize admission control based on network information.
To handle end to end admission and QoS control, the standards allow for
multiple TRC-FE and PD-FE nodes within one domain, depending on the
operators configuration. For example the PD-FE may contact only one
designated TRC-FE instance, and then the respective TRC-FE instances would
inter-communicate (Rp) to detect and set the requested QoS from edge to
edge in a set network. Multiple PD-FEs can be linked (Rd) within a domain
to handle large networks, whereas an intra-domain interface (Ri) at the
PD-FE allows resource and admission control to be requested between
domains. Finally, various Network Access Attachment Functions (NACFs)
interact (Ru) with the PD-FEs to provide subscriber information to the
PD-FE.
In this architecture, policy rules can either be "Pushed" or
"Pulled", depending on the user's QoS negotiation capabilities
at the service and transport layers. Three different possibilities can
arise:
- If the user does not have any specific QoS negotiation capabilities,
it first communicates with the SCF. The SCF determines the QoS
required and signals this to the RACF, the RACF can then execute a one
or two step process to push the gate control, packet marking and
bandwidth allocation to the transport functions.
- If the user performs QoS negotiation (such as bandwidth) at the
service layer, the SCF extracts the received QoS information and again
submits this to the RACF, which then can execute a one or two step
process of pushing authorization, reservation and commitment of
resources to the transport functions.
- If the user performs QoS negotiation (such as GPRS session
management) at the transport layer, then policy rules may be pushed or
pulled from the RACF. In the pull case this can occur as a two or
three step process, with the transport layer receiving the QoS request
and then pulling the policy rules from the RACF.
As the implementation of the TRC-FE is different for various transport
technologies, traffic policy enforcement will vary as well. The TRC-FE
will typically handle route look-up, link-by-link resource allocation and
admission control for each media flow that requires a QoS guarantee.
Next - Part 2 - ETSI TISPAN |
|
