|
[ Also see: Part
1 ]
Overview and Comparison of QoS Control in Next Generation Networks
Part 2
By Cathal Mc Daid
The second part of 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.
ETSI TISPAN
The TISPAN body (Telecoms & Internet converged Services &
Protocols for Advanced Networks), is a standardization entity within ETSI,
founded in 2003 and focusing on creating an architecture that serves to
create the Next Generation Network. NGN Release 1 was launched by TISPAN
in December 2005.
In TISPAN the service and traffic plane linkage entity is termed the Resource
and Admission Control Sub-systems (RACS)[4]. As in ITU-T, there is a
split within the RACS, with an 'upper' Service Policy Decision Function
(SPDF) providing the AF with a single point of contact via the northbound
Gq' interface. The SPDF communicates via the Rq interface with the 'lower'
A-RACF. The A-RACF's main functions are to handle admission control
requests from the SPDF, and to store access network policies, which are
used to validate resource requests received from SPDFs across the
inter-domain Rq link. The A-RACF is assisted in its admission control
process by the NASS, communicating with this via the e4 interface. The
NASS informs the A-RACF when a subscriber attaches to the network,
providing the low-level network details that can be later matched to
high-level service requests from the AF via the SPDF.
Both the A-RACF and the SPDF have southbound interfaces to the traffic
layer. The A-RACF communicates via the Re interface to the RCEF (Resource
Control Enforcement Function) , whereas the SPDF communicates directly via
the Ia interface to the BGF (Border Gateway Function). The RCEF resides in
the IP-Edge whereas the BGF resides in the core border node - located
between an access network and a core network (C-BDG), and/or between two
Core Networks (I-BGF). Both elements can police traffic, control gates and
mark packets, whereas the BGF can perform additional services such as
allocating resources per flow, measure usage and implement NAT
handling. Depending on the policy decision made by the SPDF,
resource requests may be sent via an A-RACF to the RCEF and/or directly to
the BGF.
Policy rule provisioning in the TISPAN model is "push" mode
only. The typical sequence of operation would first involve the subscriber
registering and the NASS pushing his profile to the A-RACF. The A-RACF may
then install default traffic policies in the RCEF. At some later stage the
user would request a service, at this point the AF would map QoS
information received and submit it to the SPDF. The SPDF will map the
local policy into a request to be sent to the A-RACF and/or BGF, and then,
depending on the resource model (the RACS can support a single, two or
three stage authorize-reserve-commit resource management model), either
make resources immediately available via the A-RACF and/or BGF, or make
available after reservation and authorization.
Dynamic QoS control in TISPAN can be "Guaranteed QoS" or
"Relative QoS". Relative QoS is relative per traffic carrier,
and is performed in the IP edge, an example would be Diffserv Edge in the
RCEF. Guaranteed QoS is service delivery with absolute bounds on some or
all of the QoS parameters; this is implemented in the RCEF and may take a
variety of generic L2/L3 QoS traffic policies.
PCMM
The PacketCable™ MultiMedia (PCMM) architecture[5], first
issued in June 2003, is a CableLabs-led initiative for delivering QoS
enhanced multimedia services to the DOCSIS® based access portion of a
cable operator's network.
In this model the Policy Server (PS) is responsible for making
QoS-related policy decisions based on defined policy rules, whereas the
enforcement point is in the Cable Modem Termination System (CMTS).
The PS is connected on the northbound pkt-mm-3 interface to the
Application Manager, and on the southbound pkt-mm-2 interface to the CMTS,
which performs admission control on the requested QoS envelope, installs
the policy decision and establishes the correct flow.
The PCMM architecture identifies 3 different client classes, which
differ by QoS requesting abilities and therefore by QoS control signaling:
1)
Clients with no specific QoS handling: To handle these type of
clients, application service request are sent from the Client to the
Application Manager (possibly via the Application Server). The AM then
requests QoS setup on behalf of the client. The Policy Server can then
initiate a one or two phase model, for authorization, reservation and
commitment of QOS resources, by pushing its policy decision to the CMTS
and requesting service flow establishment. The CMTS would then establish
these flows in the Cable modem.
2)
Clients with QoS signaling support but no authorization: These
clients have the same initial flow except authorization requests only are
conducted via the AM. These are installed in the push policy decision sent
from the Policy Server to the CMTS. Afterwards the Client would initiate a
one or two stage reserve/request communication directly with the CMTS,
using DOCSIS DSx or RXVP+, to request QoS and provision it on the CM, thus
bypassing the AM.
3)
Clients with QoS and authorization signaling support: In this case
the AM is bypassed completely. The client sends QoS request based on RSVP
to the CMTS. As the CMTS has no information about the client it solicits
(pulls) a policy authorization decision from the Policy Server. The Policy
Server thus installs a policy authorization decision on the CMTS, which
the CMTS then provisions on the Cable Modem.
Within the actual traffic plane QoS control is essentially extensions
to existing DOCSIS features, these include scheduling algorithms and
supporting differing bandwidth types(constant, variable etc.).
MSF
The Multiservice Switching Forum (MSF), was established in 1998 to
develop and promote interoperable, next generation networks in real-world
deployment scenarios. In September 2006 it launched its Release 3
Architecture, incorporating many ETSI TISPAN concepts, and integrating
with the 3GPP IMS core architecture.
Within the MSF model the Bandwidth Manager (BM) [6]
provides a single point of contact for higher layers to establish QoS
resources across the Core Transport Network. A variety of entities within
the higher layers, can query the Bandwidth Manager via the northbound TC-0
interface (essentially the ETSI Gq' interface) to determine the
QoS-controlled bandwidth. The Bandwidth Manager monitors the Core networks
and will respond with a message informing the requesting component whether
adequate QoS capacity exists across the core transport network to carry
that flow.
However in this model, the Bandwidth Manager does not perform
gate control in MSF R3 architecture [7], this instead is the
responsibility of the respective controlling entity. For example, if the
P-CSC (MSF) was informed by the BM that adequate QoS capacity exists to
carry the flow in question, it would then communicate policy to be
enforced directly to the access side traffic component under its control,
such as a GGSN. Policing (filtering, shaping, marking) is enforced on a
per-flow basis at the access side by the traffic plane components.
NGN Comparison
Any comparison between the various NGN QoS control entities must be
taken from their origin point. 3GPP and 3GPP2 have developed the IMS/MMD
model from a mobile origin, and have only recently (IMS Release 7 and MMD
Revision B) begun to include elements from the fixed wireline network.
Although both are roughly equivalent, 3GPP IMS Rel7 is at a more advanced
stage than 3GPP2 MMD RevB, with the result that it tends to dictate the
pace and integration with the other NGN networks. Functionally the two
PCRFs are very similar, they occupy the same position and have the same
push/pull mode capability, however minor differences exist. The 3GPP2
model is limited in that the PDSN is currently the only defined policy
enforcement point. Both models have only begun to addresses at a high
level the concept of inter-PCRF communication. Similarly neither directly
specifies how they handle NAT traversal, Firewalls and MPLS handling in
QoS control, as well as dynamic traffic monitoring in the underlying
traffic plane. These issues are being addressed with greater emphasis by
the ITU-T and ETSI models, which have wrapped their NGN architectures
around the IMS frameworks.
Table 1: NGN QoS Roles
Both ETSI's TISPAN and ITU-T NGN-GSI initiatives have begun from a
wireline prospective, and both have included the IMS model as the nucleus
on which to base a fully converged network focusing. They also address the
broader network issues that arise in a fully converged network, such as
border control (e.g NAT & NAPT traversal and gating). They share the
same topology, with a split within the north and southbound linkage
function; one entity handling the application and generic transport
signaling (ITU-T: PD-FE, ETSI: SPDF), and the other entity (ITU-T: TRC-FR,
ETSI: A-RACF) communicating and monitoring resources within the specific
traffic network. However, significant differences arise:
- In ITU-T the TRC-FE monitors the traffic plane and makes resource
admission decisions, whereas in ETSI the A-RACF can additionally
enforce policy directly in the traffic plane.
- ITU-T RACF has handling for both push and pull policy installation,
whereas ETSI RACS has push only. This is because the NASS
automatically provisions subscriber details within the RACS at the
moment of subscriber logon, allowing default policies to be
immediately pushed to the traffic enforcement point indicated. However
ETSI TISPAN Release 2 [8] is moving towards introducing pull mode.
- The RACF addresses QoS end to end, whereas the RACS is currently
more focused on access QoS.
- The RACF has provisions for end-user with no inherent QoS
negotiation abilities, whereas the RACS again relies on the NASS to
supply subscriber details, enabling default traffic policies.
In general, the ETSI TISPAN model is somewhat more mature than the
ITU-T NGN-GSI, whereas the ITU-T model is a broader model.
In comparison to the other standards bodies, the PCMM standard is
fairly mature and is in global deployment. It differs from the other
standards in allowing a range of signaling paths to occur in the
negotiation of QoS control. Interoperability with other networks is not
directly addressed within the PCMM specification, as the focus is on QoS
in the access network or within a single operator's managed IP network.
Handling of inter-network features such as NAT traversal and IMS networks
is part of the PacketCable 2.0 release, which leverages the QoS mechanism
defined within the PCMM[9].
Initial versions of the MSF's architecture were based on the PCMM
model[10], but in the latest Release 3 model the MSF has heavily
references ETSI TISPAN concepts and interfaces. The MSF's main emphasis is
on interoperability amongst networks and environments of differing types
and standards. As a result its bandwidth manager is the only policy
control element to not be directly involved in enforcing policy in the
traffic plane. Instead the BM relies on collecting accurate traffic
measurements for the network in which QoS is being requested, allowing
clients the ability to directly request policy in the traffic plane. This
removal of QoS control from the linkage entity reduces the complexity of
the BM, yet increases the number of QoS negotiation points throughout the
network.
Table 2: NGN QoS Protocols
Conclusion
A variety of QoS control methods have been adopted within the differing
NGN networks, all are optimized for the particular telecoms arena from
which they were standardized, but they are linked in their function of
providing QoS control to the decoupled service and traffic plane under
their remit. Further alignment of standards and market impetus on
interoperability will ensure meaningful QoS control and acceptable
customer experiences across next generation networks.
References
[1] 3GPP Standard TS
23.203 v7.1.0, " Policy and charging control
architecture", Dec. 2006
[2] 3GPP2 Draft
X.S0013-012-0 v0.21.0, "Service Based Bearer Control", Apr. 2006
[3] ITU-T Standard
Y.2111, "Resource and admission control functions in next generation
networks", Sep 2006
[4] ETSI Standard ES
282 003 v1.1.1 "Resource and Admission Control Sub-system (RACS);
Function Architecture", June 2006
[5] PacketCable
Technical Report PFT-TR-MM-ARCH-V02-051221, "Multimedia
Architecture Framework", Dec. 2005
[6] MSF Standard
MSF-ARCH-003.00-FINAL, "MSF Release 3 Architecture", 2006
[7] MSF Standard
MSF-IA-DIAMETER.001-FINAL, "Implementation Agreement for Diameter
interface to Bandwidth Manager", 2006
[8] ETSI Draft ES 182
019 v0.3.3, "Resource and Admission Control Sub-system (RACS);
Function Architecture; Release 2", Dec 2006
[9] PacketCable
Technical Report PKT-TR-QoS-V02-061013, "Quality of Service
Architecture", Oct 2006
[10] Chris Gallon and Olov Schelén,
"Bandwidth Management in Next Generation Packet Networks" MSF
Technical Report, MSF-TR-ARCH-005-FINAL, August 2005
Biography
CATHAL MC DAID ( cathalm (at) gmail (dot) com )
received his B.E. honours degree in computer engineering from the
University of Limerick in 2000. In 2000 he founded Infotooth,com a
Bluetooth protocol tutorial. He subsequently was employed working with
Cadence Design Systems, Palowireless and Anam Mobile. He is currently a
solutions architect in Adaptive Mobile Security, working on NGN policy,
messaging and security solutions. |
|
