NGN Functional Architecture for Resource Allocation

and Admission Control

Hassan Yeganeh1, Amir Hassan Darvishan2, Maryam Shakiba3
Abstract - A technical prerequisite for a converged network is
a common service delivery platform that is independent from the
access networks below. The 3GPP SIP-based IP Multimedia
Subsystem (IMS) is defined for this purpose. By specification,
IMS is the first implementation towards reaching converged
communications which allows users to communicate with video,
audio and multimedia content, via any fixed, mobile and wireless
access network type, with controllable QoS. This article analyzes
the mechanisms of resource allocation and admission control by
employing logical interfaces that carry SIP messages.
Keywords - NGN, IMS, QoS, Resource Allocation, Admission
Control, RACS, NASS.

I. INTRODUCTION
The concept of Next Generation Network (NGN) provides
a new network infrastructure with features and capabilities
that support the provision of value-added multimedia services
over multiple and heterogeneous QoS enabled transport
technologies. In this respect, the ETSI TISPAN group [1] is
working on the specification of an NGN based on the IP
Multimedia Subsystem (IMS). IMS was introduced in the
release 5 of 3GPP standards in 2002, as an IP-based
architecture to control of the new value-added services with
QoS requirements that were envisioned for UMTS. But,
although IMS has conceptually been designed to be
independent from the technology used in the access network,
the standards developed by the 3GPP are mainly focused on
the UMTS IP connectivity access network. From the previous
work done by the 3GPP, ETSI and 3GPP started to cooperate
in 2004 in the ETSI TISPAN group, in order to define a Core
IMS suitable for wireless and wire line networks. TISPAN has
published a first release of ETSI IMS standards and is
currently working on a second release. We could say that
3GPP describes the point of view of mobile operators (support
of new applications), while TISPAN adds the wire line
operators specifications (convergence). TISPAN makes
specifications for several non IMS subsystems like Network
Attachment Subsystem (NASS) and the Resource Admission
Control Subsystem (RACS) [2]. Most of the IMS protocols
are standardized by the Internet Engineering Task Force
(IETF) (e.g. the Session Initiation Protocol (SIP)). Other
standardization bodies are involved in the development of
IMS. On the other hand, with the rapid development of
broadband services, carriers have gradually shifted their focus

to broadband AN after expanding and reconstructing the core

and service access control layers of MAN. This leads to an
analysis of Metro AN (Metro Access Network) technology
development. This paper aims at depicting the overall IMS
architecture, protocols and technologies of metro access, as
well as the related motivation. This paper is divided into five
sections. After a short introduction to IMS, we introduce its
basic principles and technical purposes in section 2.
Overview of TISPAN NGN is presented in section 3. In
section 4, the mechanisms for QoS support are explained,
focusing on the resource allocation and admission control
solutions. In the last section access network technologies is
explained.

II. MOTIVATION FOR THE USE OF IMS

A. Basic Principles
IMS is a converged driver around IP-centric networks for
delivering multimedia services from any access technology.
One of the basic principles of IMS is Access independence.
IMS will eventually work with any network (fixed, mobile or
wireless) with packet switching functions such as GPRS,
UMTS, CDMA2000, WLAN, WIMAX, DSL and Cable; The
older circuit-switched phone system (POTS, GSM) are
supported through gateways. Open interfaces between control
and service layers allow elements and call/sessions from
different access networks to be mixed. The next-generation
solutions represent a more efficient to build networks using a
common multi-service layered architecture with the capability
to simultaneously support multiple service architectures
including Class 5 Switches as well as IMS-based SIP
application servers and soft switches. The IMS architecture
provides for a number of common functions that are generic
in their structure and implementation, and can be reused by
virtually all services in the network.
B. Business and Technical Motivations

Hassan Yeganeh, Iran Telecommunication Research Center, Email: [email protected]

Amir Hassan Darvishan, Iran Telecommunication Research
Center, E-mail: [email protected]
Maryam Shakiba, Iran Telecommunication Research Center, Email: [email protected]

Stepping back, we can see that the IMS standardization

comes at an opportune time to exploit a number of technology
developments that are already well under way. These include:
Ubiquitous IP An underlying IP packet transport network
can accommodate different multimedia streams that require
substantially different bandwidths. By contrast, the voice
telephony network uses a single uniform 64-kbit/s
bandwidth for media streams, making it an impractical
solution for these new multimedia services.
Wireless personal terminals Wireless phones and a plethora
of personal devices (such as PDAs, gaming machines, and
Black Berry devices) that have had wireless or WLAN

978-1-4244-4383-3/09/$25.00 2009 IEEE

533

communications added to them have changed the telephony

model. A wireless phone is a personal phone people can
use it and are reachable wherever they can get coverage.
The PSTN, on the other hand, is not designed to exploit the
opportunities for personalization that this development
provides.
Affordable terminal displays Todays end devices (such as
cell phones, Black Berry devices, and PDAs) have not only
powerful processing capabilities but also graphical display
screens to enable features and applications, such as presence
and location, that are impossible to provide using the man
machine interface of a POTS phone.

functions in the NGN. The RACS subsystem provides

applications with the capability of reserving resources from
the transport networks, guaranteeing QoS provision for the
value-added services in the NGN. Further details can be
found in [2]. On the other hand, the functional entities that
constitute the transfer sub layer are covered in detail in [1].
The service layer comprises a set of subsystems that
provide service control functionalities. Among them, the
Core IMS [3] provides the means to negotiate SIP-based
multimedia services to NGN terminals. It is a subset of the
IMS as it was defined in the 3GPP Release 6 specifications,
restricted to the session control functionalities. Finally, the
service layer also provides a set of common components.
One of these components is the Application Server
Function (ASF). The functionality of the ASF in the NGN
architecture consists of providing value-added services to
the NGN terminals.

III. TISPAN NGN OVERVIEW

A TISPAN NGN Functional Architecture
Fig. 1 shows a simplified overview of the functional
architecture of TISPAN NGN release 1. This functional
architecture is covered in detail in [1].

B. The IMS Core

When broken down to its bare essentials, the role of IMS is
to provide a secure and reliable means for terminals and
applications to reach, negotiate and communicate with each
other. This facilitates for the operator to provide multiple
services to the user and maximizing equipment reuse through
horizontalization. The horizontalization provides common;
supervision and control of services in the IMS network,
management and routing of sessions, as well as supporting the
authorization and manipulation of media in the network. The
IMS core is access independent which means that same
services can be delivered over different types of access
technologies. In the IMS specification the core of IMS
comprises two main nodes: the Call Session Control Function
(CSCF) and the Home Subscriber Server (HSS).

Fig. 1. Overview of the functional architecture of

TISPAN NGN release 1

As it indicated in the figure, the architecture is structured in

two layers, the transport layer and the service layer, that are
built up by a set of subsystems and functional entities. The
transport layer provides IP connectivity to the user equipment
in client premises. The functionality supported by this layer is
in turn divided in two sub layers, a transport control sub layer
and a transfer sub layer. A Transport layer consisting of the
user equipment (UE), Access Network, NGN core, NASS (see
section D) and RACS (see section E). The service layer is
composed of the following components:
The IP Multimedia subsystem core components.
The PSTN/ISDN Emulation Subsystem (PES).
Other multimedia subsystems (e.g. streaming, content
broadcasting etc.) and applications.
Common components used by several subsystems such as
those required for accessing applications, charging
functions, user profile management, security management,
routing databases etc. Regarding QoS provision
mechanisms, in the transport control sub layer the most
relevant component is the Resource and Admission Control
Subsystem (RACS). This subsystem performs policy
control, resource reservation and admission control

Fig. 2. IMS architecture overview

In the IMS architecture overview (Fig. 2) the General

Switched Telephony Network (GSTN) inter-working
functions Media Gateway Control Function (MGCF) and
Media Gateway (MGW) have been depicted beside the IMS
Core [3], [8], and [9]. The Call Session Control function
(CSCF) is the heart of the IMS architecture and is used to
process SIP signaling. The main function of the CSCF is to
provide session control for terminals and applications using
the IMS network. Session control includes the secure routing
of the SIP messages, subsequent monitoring of the SIP
sessions and communicating with the policy architecture to

534

support media authorization. It has also the responsibility for

interacting with the HSS. It can play three different roles:
Serving-, Interrogating and Proxy- Call Session Control
Function (S-, I- and P-CSCF). The Home Subscriber Server
(HSS) is the master database that contains user and subscriber
information to support the network entities handling calls and
sessions. It provides the following functions: identification
handling, access authorization, authentication, mobility
management (keeping track of which session control entity is
serving the user), session establishment support, service
provisioning support, and service authorization support. When
a user registers in the IMS domain, the user profile (relevant
information related to the services to be provided to the user)
is downloaded from the HSS to the CSCF. For session
establishment, HSS provides information on which CSCF
currently serves the user. When more than one HSS is
deployed in the network, a Subscriber Location Function
(SLF) is needed to locate the HSS that holds the subscription
data for a given user. Both the HSS and SLF use Diameter.
C. Key Protocols used in the IMS Network
Session Initiation Protocol (SIP): SIP is the main signaling
protocol used in IMS networks. It was developed by the IETF
and was selected by 3GPP as a standard for IMS in Release 5.
The function of SIP is to establish, modify and terminate
multimedia sessions with medias such as voice, video and
chat over IP networks, where the media delivery part is
handled separately. In SIP there is just one single protocol,
which works end-to-end and supports the establishment and
termination of user location, user availability, user capability,
session set-up and session management. SIP is also designed
to enable additional multimedia sessions and participants to be
dynamically added or removed from a session. These are the
major reasons SIP has been selected in IMS; it is also
considered to be flexible and secure.
Diameter; the
Authentication, Authorization, and Accounting protocol:
Diameter, a development of the current RADIUS protocol,
was chosen as the policy support and Accounting,
Authentication, Authorization (AAA) protocol for IMS.
Diameter is used by the S-CSCF, I-CSCF and the SIP
application servers in the Service Layer, and in their
exchanges with the HSS containing the user and subscriber
information. Compared with RADIUS, Diameter has
improved transport it uses Transmission Control Protocol
(TCP) or Stream Control Transmission Protocol (SCTP), and
not UDP, as transport improved proxy, enhanced session
control and higher security. H.248 media control protocols:
H.248 is a control protocol used between media control
functions and media resources. Examples of nodes with media
control functions are the Media Gateway Control Function
(MGCF) and Media Resource Function Controller (MRFC).
Typical media resources are the Media Gateway and Media
Resource Function Processor (MRFP). IPv6: Internet Protocol
version 6 (IPv6) is a network-layer IP standard used by
devices to exchange data across a packet-switched network. It
follows IPv4 as the second version of the Internet Protocol to
be formally adopted for general use. Originally, IMS was
specified to use IPv6; however, with 3GPP Release 6, IMS

does provide support for IPv4 and private address scheme.

This means that even though IMS is expected to drive the
adoption of IPv6, it is not dependent on IPv6 availability in
order to be successfully launched.
D. NASS (Network Attachment Subsystem)
This module provides registration and (potentially)
initialization of user equipment so that the subscriber can
access the services provided in the Service Layer. From a
network perspective, NASS provides network-level
identification and authentication. This module is also
responsible for managing the IP address space within the
Access Network and providing authentication to service
sessions. Network attachment is provided based on either
implicit or explicit user identification credentials stored in its
database (respectively, physical or logical Layer 2 addresses,
or user name and password) (see Fig. 3). This subsystem
provides five essential functions3:
Dynamic provisioning of IP addresses and other terminalconfiguration parameters
Authentication at the IP layer prior to or during the addressallocation procedure
Authorization of network access based on user profiles
Access network configuration based on user profiles
Location management at the IP layer

Fig. 3. ETSI TISPAN NASS Architecture

E. RACS (Resource and Admission Control Subsystem)

The Resource and Admission Control Subsystem (RACS)
arbitrates between service control functions (SCF) and
transport functions for QoS related transport resource control
within access and core networks. The RACS performs the
policy based transport resource control upon the request of the
SCF, determines the transport resource availability and
admission, and applies controls to the transport functions to
enforce the policy decision, including resource reservation,
admission control and gate control, NAPT (Network Address
and Port Translation) traversal, and firewall control. It
interacts with transport functions to control the following
functions in the transport layer: bandwidth reservation and
allocation, packet filtering; traffic classification, policing,
priority handling; network address and port translation;
firewall. This way, the RACS ensures that service layer
entities do not need to be concerned with details related with
transport networks, like the network topology and
transmission technologies. The RACS is the most important

535

logical network element for the interaction between the

service layer and the transfer functions for resource control
and QoS support within the respective NGN (see Figure 4).
RACS can be divided into two functional blocks: the Serving
Policy Decision Function (S-PDF) and the Access Resource
and Admission Control Function (A-RACF), as described in
[4]. The A-RACF and the SPDF perform similar functions,
such as making bandwidth management decisions, but they do
this at different points in the network. An A-RACF would
typically be assigned to a specific access network, while an
SPDF would interact with one or multiple A-RACFs. The ARACF and the SPDF interact using the Diameter protocol,
which is an AAA (authentication, authorization, and
accounting) protocol defined by the IETF. The SPDF, in turn,
interacts with a Policy Enforcement Point (PEP) in the
underlying core network via a profile of H.248, the media
gateway controller signaling protocol defined jointly by the
ITU-T and the IETF. In the core network, this PEP could be,
for instance, a border gateway function. In the access network,
the A-RACF interacts with PEPs located in the underlying
access (and metro) networks, such as access nodes and IP
edge routers, via the Ra and Re reference points. The basic
RACS functionalities in TISPAN NGN are indicated below:
Policy Control. The RACS subsystem applies to resource
reservation requests a set of policy rules to check if these
requests can be authorized and to determine how must they be
served. Policy control is also performed in the access network,
applying network policies specific to each particular access
line.
Admission Control. The RACS subsystem verifies if the
requested QoS demands can be satisfied with the resources
that are available in the involved access network.
Resource reservation. The RACS subsystem provides the
means to reserve bearer resources on the access network.
NAT/Gate Control. The RACS subsystem controls NAT
functionalities and performs gate control functions, at the
limit between the access and core networks and in the limit
between core networks [2], [5].

Attachment Subsystem (NASS), which is responsible for authentication and authorization of the subscriber to the access
network. The NASS also provides the IP address and binds
this IP address with such parameters as a line identifier, which
identifies the access type. Once attached to the access
network, the NASS uploads a set of static policy parameters to
the A-RACF in the RACS. These static policy parameters are
derived from the user network profile, which is stored in the
profile database in the access network. Static policy
parameters may include such items as the maximum
bandwidth that the access line can support. At this point, the
user can begin to interact with the services. To do this, some
application signaling will take place between the user and an
Application Function (AF) in order to register the user with
the application. When a user starts to use a service (e.g.,
through the initiation of a SIP INVITE to a CSCF in the case
of an IMS service), it is at this point that the AF begins to
interact with the RACS specifically to communicate the
bandwidth and potentially other resource control requirements
to the SPDF. Note that the AF discovers which SPDF to talk
to either by querying the NASS specifically the
Connectivity Session Location Function (CLF) to obtain the
IP address or Fully Qualified Domain Name (FQDN) of the
SPDF, or via some other means, such as static configuration
(see Fig. 5).

Fig. 5. RACS and NASS

Fig. 4. TISPAN RACS architecture (Release 1)

F. Putting RACS and NASS All Together

To better understand how the various components of the
RACS architecture work together, the following example is a
walk-through of a RACS session. Prior to any interaction
with services (such as IMS), an IP connection must first be
established. To obtain an IP pipe, the user connects to the
network through another subsystem called the Network

The SPDF then applies policies (which may include simple

rules such as is this application allowed to make this request
for network resources?) and, if appropriate, initiates a command to the BGF to enforce particular traffic policies. The
SPDF may also initiate a further resource request to the ARACF to request reservation of resources in the access
network. This subsequent request may result (after application
of policy at the A-RACF) in a command to the IP edge router
to apply a particular traffic policy. Note that RACS Release 1
does not specify a protocol for the interface between the ARACF and the IP edge router, although limited stage-2
guidance is provided in ES282003. Given that it acts as the
fulcrum for policy-based resource control in the network, the
SPDF also supports the coordination of resource control requests/responses for a particular RACS session. For example,
the SPDF may wait for a response from the A-RACF as to
whether or not resources can be assigned before replying to
the AF with the overall status of all resources that have been
assigned [2], [6], and [7].

536

G. PSTN Emulation and Service Architecture

Fig. 6. PSTN/ISDN Emulation Subsystem and its environment

Fig. 6 shows the PSTN/ISDN Emulation Subsystem and its

relationships with other TISPAN NGN subsystem. The
service architecture for the PES and the IMS subsystems is the
same. The generic behavior of a application server functions
is identical with respect to the PSTN/ISDN Emulation
Subsystem and the TISPAN IMS. However, depending on the
type of services to be emulated, certain application servers
may need to understand and terminate the ISUP protocol
encapsulated in SIP. Three types of Application Server
Functions (ASF) can be accessed by the IMS-based PES,
through the ISC or Ma reference point (see Fig. 7).
SIP Application Servers (SIP AS).
The IM-SSF Application Server.
The OSA SCS Application Server.

Fig. 7. Value Added Services architecture

A SIP Application Server may contain "Service Capability

Interaction Manager" (SCIM) functionality and other
application servers. The SCIM functionality is an application
which performs the role of interaction management. The
internal structure of the application server is outside the
standards. The purpose of the IM SSF is to enable access to
IN service logic programs hosted in legacy SCPs. The IMSSF functionality encompasses the emulation of the IN Call
Model (BCSM) on top of SIP signaling, IN triggering and
feature management mechanisms, emulation of the IN Service
Switching Finite State Machine and inter-working with INAP.
The role of the IM-SSF is identical in the PSTN/ISDN

Emulation Subsystem and in the IMS subsystem ES 282 007

[3]. Basic behavior is also identical. However, in the PES
case, mapping procedures may take into account ISUP
information encapsulated in SIP messages. The IM SSF is
intended to enable access from the PES to IN service logic
programs hosted in legacy SCPs. Access to PES services (i.e.
hosted in SIP-based Application Servers) from legacy SSPs in
the PSTN/ISDN is outside the scope of the present document.
Appropriate gateway functions (e.g. SPIRITS gateway as
defined in RFC 3136 [10] have to be implemented in the
PSTN/ISDN network for supporting such scenarios. The
purpose of the OSA Service Capability Server is to provide
access to OSA applications, according to the OSA/Parlay
framework ES 201 915-1 [11]. The Service-CSCF to AS
interface is used to forward SIP requests, based on filter
criteria associated with the originating or destination user. The
Interrogating-CSCF to AS interface is used to forward SIP
requests destined to a Public Service Identity hosted by the
AS directly to that AS.
The procedures between AGCF and AS (using reference
points Mw, Mx, Ic and ISC) shall be standard and open to
allow for interoperability of equipment from different vendors
which may be located in different operators' networks. The
range of services that can be emulated in TISPAN NGN
Release 1 is constrained by the functional architecture and the
IMS SIP profile defined in ES 283 003 [12].
Interfaces with RACS and NASS. The e2 reference point
supports information transfer between the P-CSCF or the
AGCF and the Network Attachment Subsystem. The role of
this reference point with respect to the PSTN/ISDN Emulation
Subsystem and the IMS subsystem is identical. Interaction
with the NASS is not be required in case the AGCF controls
access gateways only. The Gq' reference point enables the PCSCF or the AGCF to interact with the resource control
subsystem for the following purposes:
- authorization of QoS resources;
- resource reservation;
- gate control (including NAPT binding information relay).
With regard to the RACS architecture; the P-CSCF and the
AGCF play the role of an Application Function (AF). The role
of this reference point with respect to the PSTN/ISDN
Emulation Subsystem and the IMS subsystem is identical.
Interaction with the NASS may not be required in case the
AGCF controls access gateways only and dedicated transport
resources are used to support PES traffic.

IV. QOS PROVISIONING IN TISPAN NGN

Three different NGN QoS control scenarios can be
distinguished (ETSI TS 185 001, 2005). The application of a
specific scenario, amongst others, depends on the QoS
signaling capabilities of the respective user equipment that
initializes a session requiring certain QoS conditions within
the respective NGNs transport network. For clarity, no
protocol details, message responses or acknowledgements are
displayed in the respective figures. Only the primary QoS
signaling message ways are described. The necessary
signaling for the release of resources after a session

537

termination is not accounted. Furthermore, the inter-working

with other networks and the resulting inter-domain QoS
signaling ways have not been considered within this paper for
the purpose of simplification[13]. In real-life NGN, the
reservation and the release of resources have to be signaled by
the RACS not just to one network element within the transfer
functions block but to all network elements of the IP
transport network that are part of the respective resource path
and, at the same time, have to be kept informed about QoS
conditions for the respective call.
- Scenario 1
This scenario can be applied if the user equipment initializing
the respective session has no QoS capabilities at all. Fig. 8
shows the principal of this scenario.

Fig. 8. NGN QoS and resource control scenario 1

(ETSI TS 185 001, 2005)

A user equipment without specific QoS signaling

capabilities requests a service (e.g., the initiation of a voice
session) by sending a SIP service request (step 1.) to the
service and control functions of the NGN it is connected to.
The service and control functions identify the required
resource conditions (e.g., a certain minimum bandwidth
provided) for the respective service and, in step 2. , send a
resource request to the RACS. The RACS might authorize the
subscriber to use a specific amount of resources (depending
on the subscribers user policy) and check whether the
requested resources are available within the NGNs transport
network. If the resource request can be fulfilled, the RACS
triggers the resource reservation (step 3.) in the transfer
functions of the respective NGNs IP transport network. This
scenario is also called the push model because the resource
allocation is pushed from the top (service and call control
functions) via the RACS down to the transfer functions.
-Scenario 2
The application of scenario 2 assumes that the respective user
equipment has certain QoS signaling and managing
capabilities (i.e., the user equipment can make use of
IntServ/RSVP). It is also assumed that the resources
demanded by the user equipment have to be authorized by the
service and call control functions before the allocation of
resources in the IP transport network can be applied. Fig. 9
shows the principal of this scenario.

Fig. 9. NGN QoS and resource control scenario 2

(ETSI TS 185 001, 2005)

A user equipment supporting layer 3 QoS signaling

capabilities (such as RSVP) requests a service by sending a
SIP service request (step 1.) to the service and control
functions of the NGN it is connected to. The service and
control functions identify the required resource conditions for
the respective service and may relay an associated
authorization token to the user equipment. Also, the service
and call control functions initiate the policy enforcement
within the RACS (step 2.). The user equipment starts layer 3
QoS signaling (e.g., by sending RSVP messages, step 3.) and,
within the signaling, turns the before given authorization
token to the NGNs transfer functions. The responsible
subsystem of the transfer functions requests QoS authorization
at the RACS (step 4.) based on the authorization token
information. If the resource request can be granted, the RACS
triggers the resource reservation (step 5.) in the transfer
functions of the respective NGNs IP transport network. This
scenario can be referred to as the push-pull model, because the
resource allocation is first pushed from the top (service and
call control functions) down to the RACS and, from there, is
pulled down by the respective NGNs transfer functions after
the authorization token has been sent by the user equipment
within QoS signaling.
- Scenario 3
The application of this scenario assumes that the respective
user equipment has QoS signaling and managing capabilities
(i.e., the user equipment can make use of IntServ/RSVP). It is
also assumed that the resources demanded by the user
equipment do not have to be authorized by the service and call
control functions before the allocation of resources in the IP
transport network can be applied. Figure 10 shows the
principal of this scenario. The user equipment starts layer 3
QoS signaling (e.g., by sending RSVP messages, step 1.). The
responsible subsystem of the transfer functions requests QoS
authorization at the RACS (step 2.) based on information
given within the QoS signaling. If the resource request can be
granted, the RACS triggers the resource reservation in the
transfer functions of the respective NGNs IP transport
network (step 3.). This scenario is also referred to as the pull
model, because the permission to allocate the resources
requested by the user equipment is pulled down by the
respective NGNs transfer functions from the RACS.

538

wide adoption of this promising technology. IMS has the tools

and functions necessary to handle numerous of nonstandardized services in a standardized way: interoperability;
access-awareness; policy support; quality of service; interworking with existing networks; the properties necessary to
meet ever-increasing consumer demand for attractive and
convenient offerings.

REFERENCES
[1]
Fig. 10. NGN QoS and resource control scenario 3
(ETSI TS 185 001, 2005)

[2]

V. METRO ACCESS NGN TECHNOLOGIES

The broadband AN is the last-mile access to end users and
it is being challenged by broadband acceleration and multiservice bearing as these features require a shorter distance
from DSLAM to users. For this reason, the location of
DSLAM is constantly lowered, while the BRAS/SR locations
remain unchanged which results in greater space in the Metro
AN. As IP-based MAN will bear IPTV and NGN services, the
demands are high on bandwidth, security, reliability and QoS
[14]. Indeed, traditional Ethernet can hardly adapt to meet
them. With the purpose of a rapidly developing Metro AN,
various international standardization organizations have
proposed applicable technical standards. IEEE launched
Ethernet technology-based SVLAN (Super VLAN), RPR
(Resilient Packet Ring) and PBB (Provider Backbone Bridge),
while IETF has been developing and optimizing MPLS
(Multi-Protocol Label Switching) technology. Equipment
suppliers in turn have been developing and promoting
different solutions. Switch vendors favor SVLAN and
Ethernet ring technology; router vendors promote MPLS
extended to edge; and optical network equipment vendors
prefer RPR. Carriers have also been selecting technologies
and solutions. Many traditional carriers favor MPLS
extension, whereas new carriers tend to opt for Ethernet
enhancement. Some carriers, such as BT, prefer PBT solution.
It is clearly worthwhile to analyze and compare these Metro
AN technologies. Based on traditional Ethernet and VLAN,
various new technologies have been developed for Metro AN
including Ethernet enhanced technologies (SVLAN,
PBB/PBT and V-Switch), transport technology-based RPR,
and PWE2 and VPLS which are based on Ethernet and MPLS
integration. Each of these technologies possesses different
features.

[3]

[4]
[5]

[6]
[7]

[8]
[9]
[10]
[11]
[12]

[13]

VI. CONCLUSION
As discussed in previous sections, IMS opens up new
perspectives for network operators. But several technical and
business challenges have to be faced in order to enable the

[14]

539

TISPAN, ETSI ES 282 001 V1.1.1: Telecommunications and

Internet converged Services and Protocols for Advanced
Networking (TISPAN); NGN Functional Architecture Release
1, August 2005.
TISPAN, ETSI ES 282 003 V1.1.1: Telecommunications and
Internet converged Services and Protocols for Advanced
Networking (TISPAN); Resource and Admission Control Subsystem (RACS); Functional Architecture, March 2006.
TISPAN, ETSI ES 282 007 V1.1.1: Telecommunications and
Internet converged Services and Protocols for Advanced
Networking (TISPAN); IP Multimedia Subsystem (IMS);
Functional Architecture, June 2006.
ES 282 003: Resource and Admission Control Sub-system
(RACS); Functional Architecture, ETSI, Tech. Rep., 2006.
I. Vidal, J. Garcia, F. Valera, I.Soto, and A. Azcorra, Adaptive
quality of service for next generation residential gateways,
LNCS, 9th IFIP/IEEE International Conference on
Management of Multimedia Networks and Services (MMNS
2006), 2006, vol. 4267, pp. 183194.
For the list of TISPAN Release 1 Specifications, see
http://portal.etsi.org/docbox/TISPAN/Open/NGN_Published/P
UBLISHED_NGN_SPECIFICATIONS.doc
ES 282 004: Telecommunications and Internet converged
Services and Protocols for Advanced Networking (TISPAN);
NGN Functional Architecture; Network Attachment SubSystem (NASS)
Note: ETSI Specifications can be downloaded at:
http://pda.etsi.org/pda/queryform.asp (ETSI on-line account
required).
http://www.cablelabs.com/specifications/PKT-SP-23.228-I02061013.pdf
http://tools.ietf.org/html/rfc3261 , IETF Specs - SIP: Session
Initiation Protocol
IETF RFC 3136: "The SPIRITS architecture".
ETSI ES 201 915-1: "Open Service Access (OSA); Application
Programming Interface (API); Part 1: Overview (Parlay 3)".
ETSI ES 283 003: "Telecommunications and Internet
converged Services and Protocols for Advanced Networking
(TISPAN); IP Multimedia Call Control Protocol based on
Session Initiation Protocol (SIP) and Session Description
Protocol (SDP) Stage 3 [3GPP TS 24.229 [Release 7],
modified]".
ETSI TS 185 001 V1.1.1 (2005), Technical Specification,
Next Generation Network (NGN); Quality of Service (QoS)
Framework and Requirements, ETSI TISPAN EuQoS Project
Web Site (2006), Home - EuQoS - End-to-end Quality of
Service
support
over
heterogeneous
networks,
http://www.euqos.eu, (Accessed 16 April 2007).
Metro Ethernet Networks: A Technical Overview
http://WWW.metroethernetforum.org/MEN.