Tài liệu Điện thoại di động băng thông rộng không dây P4 pdf

3
Network Architecture
3.1 Introduction
The successful deployment and worldwide acceptance of the second-generation (2G) mobile
telecommunication systems combined with the need for more advanced and ubiquitous
mobile services have paved the way to the initiative of the so-called third-generation (3G)
mobile telecommunication systems. In this chapter, we will discuss the network architecture
of 3G systems, i.e. we will describe how the network is built, what functional elements exist,
what overall functionality is provided, etc. Through this discussion, the main differences
between the architecture of 2G and 3G systems will be illustrated and the advanced features
of 3G systems will become apparent. Finally, we will discuss the evolution of 3G systems,
which shows how the 3G systems are expected to evolve in the future and lead to the next
generation of mobile telecommunications systems.
It is important to keep in mind that the architecture of 3G systems was based (1) on a
number of market requirements and (2) on the characteristics of the installed infrastructure
base pertaining to 2G systems. Indeed, since many network vendors had already invested in a
large number of network elements, it was desired to keep those elements in 3G systems
wherever possible. Also, both end-users and network operators have formulated a list of
requirements for 3G systems. From the end-user’s point of view, the key requirements
included worldwide operation, advanced services (with emphasis on multimedia applica-
tions), intelligent terminals and enhanced quality. On the other hand, from the network
operator’s viewpoint, key requirements included whatever was related to increased revenue
and flexible management and operation, such as, enhanced network capacity (e.g. serve more
customers in a given area), increased resources utilisation, advanced network management,
enhanced security, flexible and fast service deployment, etc. It is also important to point out
that the network architecture was not designed having in mind the provision of telephone
services but it was rather designed with multimedia services in mind. The support of multi-
media services in a mobile environment was one of the primary targets and it is considered a
key feature of 3G systems. Moreover, mobile access to the Internet services was another key
feature. This feature was considered important because the recent evolution of Internet and its
remarkable popularity called for the migration of Internet services to the mobile environment.

This migration accounts for the convergence between the mobile telephony and the Internet.
In this context, 3G systems are not merely mobile telephone systems similar to their 2G
Broadband Wireless Mobile: 3G and Beyond. Edited by Willie W. Lu
Copyright
 2002 John Wiley & Sons, Ltd.
ISBN: 0-471-48661-2
counterparts, but they look more like multimedia systems with enhanced capabilities and
Internet access.
3.1.1 Requirements for 3G Systems
Some of the most important design requirements for 3G systems include the following:
† global roaming;
† wide range of operating environments, including indoor, low mobility, full mobility, and
fixed wireless;
† wide performance range, from voice and low speed data to very high speed packet and
circuit data services;
† wide range of advanced services, including voice only, simultaneous voice and data, data
only, and location services;
† advanced multimedia capabilities supporting multiple concurrent voice, high speed packet
data, and high speed circuit data services along with sophisticated Quality of Service
(QoS) management capabilities;
† modular structure to support existing and future Upper Layer Signalling protocols;
† seamless interoperability and handoff with existing 2G systems;
† smooth evolution from existing 2G systems;
† highly optimised and efficient deployments in clear spectrum, including cellular, PCS, and
IMT-2000 spectrum;
† support for existing 2G services, including speech coders, data services, fax services,
SMS, etc.
The qualitative and quantitative differentiation between 3G and 2G systems is considered
as an important factor to the success of 3G systems. For this differentiation, the following
service requirements are considered very important:

† significantly higher voice quality;
† wide range of voice and non-voice services including packet data and multimedia services;
† high power efficiency, especially in the mobile;
† efficient spectrum utilisation (which is mandatory for the provision of high data rate
services);
† wide range of user density and coverage; etc.
3.1.2 International Standardisation Activities
The international standardisation activities for 3G systems have been mainly concentrated in
the following bodies/regions:
† European Telecommunications Standards Institute (ETSI) – Special Mobile Group (SMG)
– in Europe.
† Research Institute of Telecommunications Transmission (RITT) in China.
† Association of Radio Industry and Business (ARIB) and Telecommunication Technology
Committee (TTC) in Japan.
† Telecommunications Technologies Association (TTA) in Korea.
† Telecommunications Industry Association (TIA) and T1P1 in North America.
Broadband Wireless Mobile: 3G and Beyond138
The second-generation systems, mainly dominated by GSM, IS-136, IS-95 and PDC, have
been taken into account by the related regional bodies in the design of 3G systems. This was
mainly driven by the need for backward compatibility. As a result, two types of 3G core
networks were standardised: one based on GSM MAP signalling and another based on IS-41
signalling. The first is being standardised by the 3rd Generation Partnership Project (3GPP),
whereas the second by the 3rd Generation Partnership Project 2 (3GPP2). In general, the
3GPP initiative harmonises and standardises the similar 3G proposals proposed by ETSI,
ARIB, TCC, TIA, and T1P1. The radio access of the 3GPP system is based on WCDMA and
the core network is an evolution of GSM core network, based on MAP. On the other hand,
3GPP2 harmonises and standardised the 3G proposals proposed by TIA and TTA. The radio
access of the 3GPP2 system is based on the so-called cdma2000 and the core network is an
evolution of IS-41 core network. In addition, major international operators have initiated a
harmonisation process between 3GPP and 3GPP2 in the context of the ITU-R process, which

aims to result in a globally harmonised technology.
In the rest of this chapter, we will focus on the 3G system standardised by 3GPP, referred to
as Universal Mobile Telecommunications System (UMTS). However, we have to keep in
mind that the 3G system standardised by 3GPP2 features quite similar capabilities and it is
designed based on similar requirements. UMTS has been standardised in several releases,
starting from Release 1999 (R99) and moving forward to Release 4 (Rel-4), Release 5 (Rel-
5), Release 6 (Rel-6) etc. The features of each individual release are discussed later on.
UMTS is continuously evolving and up-to-date information about the individual releases
can be found in the official web site of 3GPP, www.3gpp.org. Typically, one new release is
frozen each year – R99 was frozen in March 2000, Rel-4 was frozen in March 2001, Rel-5
was frozen in March 2002 and Rel-6 is currently being standardised.
Before we get into the details of UMTS, let us briefly refer to the worldwide 3G proposals
that were developed in the context of IMT-2000 program [1].
The standardisation process within ETSI started at the end of 1996. ETSI Special Mobile
Group decided in January 1998 that the radio access scheme would be based on wideband
CDMA (WCDMA) in paired bands (FDD), and on time-division CDMA (TD-CDMA) in
unpaired bands (TDD). This radio access, called UMTS Terrestrial Radio Access (UTRA),
fits into 2 £ 5 MHz spectrum allocation. ETSI has submitted the UTRA proposal to ITU-R in
the context of IMT-2000 concept.
Other IMT-2000 proposals from other standardisation bodies have also been submitted.
China presented the ITU-R a TD-SCDMA proposal based on a synchronous TD-CDMA
scheme for TDD and wireless local loop (WLL) applications. The Japanese standardisation
body ARIB decided to propose a WCDMA system, aligned with the European WCDMA
FDD proposal. TTA in Korea prepared two proposals: one similar to the ARIB WCDMA
scheme and the other similar to the TIA cdma2000 approach. In the United States TIA
prepared several proposals: UWC-136 (an evolution of IS-136), cdma2000 (an evolution
of IS-95), and a WCDMA system called WIMS. T1P1 supported the WCDMA-NA system,
which corresponds to UTRA FDD. WCDMA-NA and WIMS WCDMA have been merged
into wideband packet CDMA (WP-CDMA) and all these technologies have been submitted to
ITU-R.

Network Architecture 139
3.1.3 General Aspects of 3G Systems
It is important to note that, a 3G telecommunications system does not standardise the services
themselves but rather it provides the means by which:
† users can connect to services from anywhere (whether roaming or not);
† billing and accounting functions are performed;
† the network is managed;
† security is provided;
† radio resources are managed, etc.
Services are offered to the users through a large variety of service providers and network
operators. The user experience should be the same independent of the place and time. In other
words, the user should perceive a virtual home environment (VHE) [2], wherein the same
interface and service environment is maintained regardless of the location, i.e. regardless of
the serving network and regardless of the access means. In a VHE the 3G network should be
able to adapt the service provision to the particular capabilities of the terminal and access
environment used in a particular time. Universal accessibility to services is established by
enabling several access means to a common core network, (including fixed, mobile and
satellite access) and multi-mode, multi-band terminals.
As mentioned already, the key driver for 3G systems is the increasing demand for multi-
media services. Demand is also increasing for access to multiple types of media, often used in
various combinations. Thus 3G systems need to provide both narrow and wideband services
(e.g. voice, data, graphics, pictures and video), in combination, on demand and on the move.
This flexibility needs to be economically delivered, with costs understood by the user.
It is also important to point out that, 3G systems aim to satisfy consumer (not only
business) demands for personal mobile communications. Therefore, prices subscribers
have to pay for the equipment and service usage should be kept to a minimum. This
makes it necessary to provide common standards to build a widely accepted framework
where:
† low cost mass production for the manufacturers is made possible
† open interfaces for the network operators, service and content providers are clearly

defined.
This framework should be global in order to allow the user easy service access all over the
world and in both public and private networks. 3G systems will therefore offer ubiquitous
services.
3G systems aim also to provide different kinds of mobility, typically, terminal mobility,
personal mobility and service mobility. Terminal mobility is provided when a user is served
while on the move, regardless of network boundaries. Personal mobility is provided when a
user is not restricted to a special terminal when wanting to access his or her services. This
kind of mobility is usually offered by means of a common smart card technology and the
provision of the virtual home environment. Service mobility is provided when a user can
access his or her personalised services independently of the terminal and serving network.
Broadband Wireless Mobile: 3G and Beyond140
3.1.4 Chapter Outline
In this chapter we will discuss the architecture of the 3G system standardised by 3GPP. As
mentioned before, this 3G system is typically referred to as Universal Mobile Telecommu-
nications System (UMTS).
Section 3.2 discusses the generic network model of UMTS and defines the various high-
level domains, such as the User Equipment domain, the Access Network domain, the Core
Network domain, etc. It also discusses the functional strata, including the transport stratum,
the serving stratum, etc.
Section 3.3 focuses on the network architecture of several UMTS releases and their parti-
cular features. In this context, it defines the various functional entities of a UMTS network,
the various network interfaces and it discusses some fundamental differences with the GSM
mobile networks.
Section 3.4 thoroughly discusses the architecture of UMTS Terrestrial Radio Access
Network (UTRAN), focusing on the internal UTRAN interfaces and the key functionality
provided by UTRAN.
Finally, section 3.5 discusses the network access security of UMTS, that is, the particular
means provided to limit the access to network services and resources to authorised users, to
encrypt the sensitive pieces of information, to verify the integrity of critical data, etc. Such

functions are considered key in the deployment of UMTS.
The high-level organisation of a UMTS network considered throughout this chapter is
illustrated in Figure 3.1. Note that, the network is divided into the User Equipment domain,
the Access Network domain, the Core Network domain and the Service domain. The core
network is an evolved version of the GSM core and it is backwards compatible with GSM
networks. Users access the services through the core network and by means of a particular
Network Architecture 141
Figure 3.1 High-level domains in a UMTS network.
access network. In UMTS, the core network is designed to be decoupled from the particular
aspects of the access network and for this reason several different technologies can be used in
the access network domain. Such network access technologies include the UMTS Terrestrial
Radio Access (UTRAN), the standard GSM Base Station Subsystem (GSM BSS), the GSM/
EDGE Radio Access Network (GERAN), which is an evolved version of GSM BSS, the
UMTS Satellite Radio Access Network (USRAN), various Broadband Radio Access
Networks (BRAN), e.g. HIPERLAN/2, 802.11, etc. and also fixed access networks. At first
stages of deployment, UTRAN and GSM BSS will dominate and will offer high interoper-
ability between each other. In later stages, however, more access network options are
expected to be interconnected to the UMTS core and progressively offer more access
means to a common set of advanced and globally available services.
3.2 Generic Network Model
The generic network architecture is a high-level representation that identifies the functional
model and the physical model of the system.
3.2.1 Physical Model
The physical model of the network provides a high-level physical configuration of the
network. This configuration is represented by a number of physical domains connected to
each other with a specific way. The UMTS physical model comprises two high-level
domains: the User Equipment (UE) domain and the Infrastructure domain. This is illustrated
in Figure 3.2. The reference point between these two domains is termed as Uu.
3.2.1.1 The user equipment domain
The UE domain comprises of all equipment that is operated and owned by the user. The types

Broadband Wireless Mobile: 3G and Beyond142
Figure 3.2 UMTS physical domains.
of the equipment as well as their functional capabilities can vary between each other.
However, all UE equipment must be compatible with one or more access technologies
used to access the infrastructure domain.
The UE domain is subdivided into two other domains: the User Services Identity Module
(USIM) domain and the Mobile Equipment (ME) domain. The reference point between them
is termed as Cu. The USIM includes a removable smart card that may be used in different user
equipment types and it is used to provide terminal portability and terminal personalisation.
The USIM corresponds to a subscription and provides the means for the infrastructure domain
to securely identify the subscriber. The ME domain typically contains the equipment that
execute the user applications and the radio interfacing procedures, such as physical and data
link procedures. The ME domain may be physically realised in one equipment. For instance, a
mobile terminal equipped with WAP microbrowser is an ME. However, it is customary to
physically separate the equipment that executes the user applications and the equipment that
governs the radio interface procedures. In such cases, the former equipment is referred to as
Terminal Equipment (TE), while the latter is referred to as Mobile Terminal (MT) equipment.
In general, a TE may be a laptop or a personal digital assistant (PDA), which runs the user
applications. The TE is independent of any mobile radio issues, such as transmission, mobi-
lity management, radio resources management, etc. All these mobile radio issues are handled
by the MT, which terminates the mobile protocols and the associated procedures.
3.2.1.2 The infrastructure domain
The Infrastructure domain encompasses all the network equipment needed to support the end-
to-end user connectivity. It is further split into the Access Network (AN) domain and the Core
Network (CN) domain. The AN includes the physical entities (such as radio transceivers, base
stations, etc.) that manage the resources of the AN and facilitate the user access to the CN.
Ideally, the AN is independent of the CN and can implement any kind of access technology
ranging from the legacy fixed local loop to wireless LAN technologies, satellite access
technologies, and cellular broadband technologies. Any kind of AN can be interfaced to
the CN as long as it complies with the specification of the Iu reference point. Having said

that, it becomes evident that the functionality of CN is decoupled from the specificAN
employed and the same CN can be reused with several different AN domains. For instance,
access to the same CN could be realised through an AN based on DSL technology or through
an AN based on GSM radio access technology.
The CN domain includes the physical entities that facilitate end-to-end connectivity,
transmission of user information and signalling and, in general, the provision of telecommu-
nication services. To support mobile access, the CN implements mobility management
procedures and location management procedures. The CN domain is further sub-divided
into the Serving Network (SN) domain, the Home Network (HN) domain and the Transit
Network (TN) domain. The reference points between these domains are illustrated in Figure
3.2. Strictly speaking, SN, HN and TN may be considered as different instances of the same
domain. This means that, at one time, some physical entities may be considered as a SN
domain and, at some other time, the same physical entities may be considered as a HN
domain or a TN domain. As discussed below, the definition of a domain within the CN
depends on several parameters, such as the mobile user’s location and on the mobile user’s
service requests.
Network Architecture 143
The SN domain is composed of all the physical entities that are directly connected to the
access network. The user therefore makes use of the 3G services by directly communicating
with the SN. All the service requests, including mobile terminated and mobile originated
calls, are handled by the SN. In addition, the SN provides the mobility management func-
tionality needed to accommodate the user mobility. Finally, the SN establishes and routes
calls on behalf of the user and it interacts with the HN domain to take into account the home
environment of the user, e.g. to learn what services the user is entitled to use, what particular
subscription options have been activated, what home-based services are enabled, etc. Typi-
cally, a SN serves a limited geographical area and, thus, while a user is on the go, he may
enjoy 3G services through a sequence of SN domains.
Each user is associated with a HN domain. This domain is effectively the network domain
where the user has a 3G subscription and where some permanent user specific data is stored.
Typically, a HN domain can provide the services of a SN domain for the users located in a

given geographical area. However, this may not be considered as a general rule, i.e. it is
possible for a HN domain to provide no SN services. When a HN domain can also provide SN
domain services, then it acts as both SN domain and HN domain for the users that have a 3G
subscription in this domain and are currently located in the area served by the domain. In such
cases, the SN and HN domain merge into a single domain. However, when a user is located in
the area served by a domain other than his HN domain, then his SN and HN domains are
physically separate. In such case, we say that the user is roaming to another domain. One
important characteristic of the HN domain is that its physical location is always the same no
matter where the user is located.
As shown in Figure 3.2, the TN domain is the components of CN that facilitates the
communication between the UE and the remote party. If, for example, the mobile user
makes a call to an ISDN user, then the ISDN network, which terminates the call, acts as a
TN domain. Note that, for the ISDN user, this ISDN network is effectively a SN domain. The
TN may be another SN, when the remote party is a mobile user served by another SN. In
addition, when a call is established between two parties served by the same SN, then no TN
exists. Therefore, the TN is defined on a per call/session basis and may or may not be needed
for a call/session establishment.
3.2.2 Functional Model
From a functional point of view, a 3G network can be decomposed into a number of func-
tional planes, each one providing the level of functionality needed to realise a given set of
services. These planes are characterised by a hierarchical relationship: a functional plane uses
the services provided by the functional plane below it and provides services that are available
to the functional plane above it. The decomposition of the overall functionality into several
functional planes provides for a highly structural architecture and effectively maps the high-
level functional requirements into smaller sets of clearer and more specific requirements. In
turn, this facilitates the development and makes it easier to identify the functional entities
required.
The high-level functional architecture of a 3G network is illustrated in Figure 3.3. This
figure shows three primary functional planes, which in the specifications of 3GPP are referred
to as strata [1]: the application stratum, the serving stratum and the transport stratum. A

specific part of the transport stratum is termed the ‘access stratum’. Figure 3.3 also shows the
Broadband Wireless Mobile: 3G and Beyond144
physical network entities that interact within each functional stratum. Where the interaction
between two entities is represented by a dotted line, it means that this interaction is not
specific to UMTS and possibly different interaction mechanisms could be employed.
The application stratum is the highest-level stratum and encompasses only two peer appli-
cations, one running at the TE and another running at the ‘remote party’. The remote party
could be a network server, another TE, a value-added server operated by an authority other
than the 3G operator, etc. These two applications communicate transparently through the 3G
network, which means that they don’t have to deal with any specific communication issues
other than the communication between each other. The functional strata below the application
stratum deal with all the transport and connection management issues and effectively provide
a transparent communication path between the two applications. It should be noted that, the
protocols used in the application stratum are not necessarily specified in 3GPP specifications.
This leaves space for a vast range of applications that could be or could not be specifically
developed for 3G systems. However, 3GPP specifications include also some application layer
protocols, such as the USIM Application Toolkit (USAT), the Mobile Execution Environ-
ment (MExE), etc. In general, a remote application should authenticate a user before allowing
him to utilise the application services and it could also provide for application level data
confidentiality. Such security mechanisms are of considerable importance in the application
stratum. Application-level security mechanisms are needed because the lower functional
strata may not guarantee end-to-end security provision. Lack of end-to-end security could
be envisioned when, for instance, the remote party is accessible through the Internet.
The serving stratum is mainly used to provide access to services. Through the serving
stratum a user (or an application) may request to have access to specific services. The serving
stratum aims at providing the user with the requested services, or with the services that are
accepTable 3.to him. In general, the serving stratum is a control stratum that received
service requests from the application stratum and then configures the transport stratum to
provide accepTable 3.transport (or bearer) services. For example, protocols that functionally
belong to the serving stratum include the call control protocols. In particular, the serving

stratum includes protocols across the following interfaces (see Figure 3.3):
Network Architecture 145
Figure 3.3 UMTS functional model.
† TE – MT: These protocols support exchange of control information to enable the TE to
request specific services.
† MT – SN: These protocols allow the MT to request access to services provided by the
serving network domain.
† USIM – MT (not shown in Figure 3.3): These protocols support access to subscriber-
specific information for support of functions in the UE domain.
As illustrated in Figure 3.3, there could also be serving-stratum protocols across the SN–
TN interface and across the TN–Remote party interface; however, these protocols may not be
specific to 3G architecture.
As opposed to the serving stratum, which effectively deals with signalling, the transport
stratum aims at providing the correct transport mechanisms to transport the actual user data
between various network interfaces. The transport mechanisms across each interface are
tailored to deal with the specific characteristics of that interface. For instance, the transport
mechanisms across the radio interface need to cope with the radio transmission issues, such
as, efficient modulation, power control, interference cancellation, etc. Obviously, such issues
do not exist across other interfaces, e.g. between the SN and the TN. As identified in Figure
3.3, the 3GPP specifications specify transport mechanisms applicable only between the MT
and the AN, and between the AN and the SN. For providing the required transport function-
ality, the transport stratum includes mechanisms such as:
† mechanisms for error correction and recovery;
† mechanisms to encrypt data;
† mechanisms for adaptation of data to fit into the transmission format supported by the
transport resources (e.g. adaptation of 13 kbps data to be transferred into a 64 kbps trans-
port channel);
† mechanisms for data transcoding to support interworking between entities using different
data encoding formats.
The transport stratum in a 3G system, which aims at supporting multimedia services,

should be capable of providing a vast range transport channels, each one featuring a different
set of communications characteristics.
The part of the transport stratum that is specific to the AN technology is called the Access
Stratum (see Figure 3.3). This stratum provides services related to the transmission of data
over the radio interface and the management of the radio interface. In particular, the protocols
across the MT – AN interface support the transfer of detailed radio-related information to
coordinate the use of radio resources, and the protocols across the AN – SN interface provide
access of the SN to the resources of the access network. The latter interface is independent of
the specific structure of the access network.
3.3 Network Architecture
In this section, we present the network architecture of the 3G system specified in the 3GPP
specifications [10]. The development of these specifications follow a phased approach, that is,
specifications are being developed in phases, commonly referred to as releases. As we have
seen in section 3.1.2, the first 3GPP release is known as Release 1999 (R99), the second as
Release 4 (Rel-4), the third as Release 5 (Rel-5), etc. In every new release a list of new
Broadband Wireless Mobile: 3G and Beyond146
features and capabilities are supported and in addition a list of corrections to previous releases
is introduced. This way, the 3GPP system is being evolved in small steps, starting from the
GSM system and moving towards an advanced 3G-and-beyond system featuring all-IP trans-
port, broadband radio access, sophisticated security (see section 3.5), voice-over-IP (VoIP),
enhanced mobility, innovative services, etc.
At this point, it is instructive to point out the difference between a UMTS system and a
3GPP system. A 3GPP system is typically composed of an evolved GSM core network that
can be connected to several radio access networks (such as the UTRAN, the GSM radio
access network, and other fixed or wireless access networks) through the standardised inter-
faces A, Gb and Iu. A UMTS system is similar but it does not support the A and Gb interfaces,
which are required to support the GSM radio access network. As shown in Figure 3.2, a
UMTS system supports only the so-called Iu interface between the core network and the
access network. Therefore, a 3GPP system can be considered as an integration of a UMTS
system and a GSM system. This integration is critical, as we have to provide a high degree of

interworking between these two systems. To fulfil the UMTS/GSM interworking require-
ments, the 3GPP system features a single core network with Iu, A and Gb interfaces to the
access network. The 3GPP specifications, apart from specifying the UMTS system and the
evolved GSM system, they also specify the means that assure sufficient interworking between
UMTS and GSM, and between the different 3GPP releases.
In the rest of this section we will discuss the main aspects of 3GPP R99, Rel-4 and Rel-5.
3.3.1 3GPP Release 99
One of the key characteristics of 3GPP architecture is that the core network is an evolved
GSM/GPRS core network, backwards compatible with the earlier GSM/GPRS releases. This
makes sure that legacy mobiles, compliant to earlier GSM releases, are able to interwork with
the 3GPP R99 network in a seamless fashion. However, the 3GPP R99 network supports a set
of new features and enables the provision of more advanced (3G) services over the UTRAN
radio access network.
In 3GPP R99, as well as in all later 3GPP releases, the core network is functionally
decomposed into two domains: the circuit-switched (CS) domain and the packet-switched
(PS) domain. (Note that the PS domain provides PS-type of services, which are also called as
GPRS services. In many 3GPP specifications the terms PS domain and GPRS are used
interchangeably.)
The CS domain is composed of the elements and interfaces that collectively provide
circuit-switched type of services, i.e. services based on the reservation of dedicated circuits.
This is also the kind of services provided by a GSM system. On the other hand, the PS domain
is composed of the elements and interfaces that collectively provide packet-switched type of
services, i.e. services that utilise resources on a demand basis. Basically, the CS domain
provides ‘circuits’ (i.e. dedicated resources) for connectivity to the services, whereas the PS
domain provides shared resources for connectivity to services. These shared resources are
statistically multiplexed (on a demand basis) across a number of users and typically they are
utilised far more efficiently when users’ traffic is bursty and uncorrelated to each other. In
general therefore the PS domain is more efficient for data (bursty) communications, like web
browsing, e-mail, etc., whereas the CS domain is more efficient for isochronous (i.e. constant
bit-rate) type of traffic, like voice transmission. However, since most of the modern media

Network Architecture 147
encoders today perform variable bit-rate encoding, it becomes evident that PS domain is not
only efficient for data traffic but also for multimedia traffic. This fact accounts for the
significant interest that has been developed for carrying multimedia services (including
voice and video) over the PS domain. Unavoidably, the traffic carried over the CS domain
progressively decreases in favour of the traffic carried over the PS domain. As a result, it is
necessary to migrate to all-IP networks, which will provide only packet-switched type of
services and deploy IP as a cost-effective protocol for end-to-end routing and security provi-
sion (with IPsec). If we carefully study the evolution of 3GPP and 3GPP2 specifications, we
will identify that this need is acknowledged and that the network progressively migrates to an
all-IP architecture.
In the rest of this section we undertake a concise overview of 3GPP R99 and we discuss the
basic network architecture and the key network elements and interfaces.
3.3.1.1 Basic reference architecture of 3GPP release 99
Figure 3.4 illustrates the basic reference architecture of the 3GPP R99 network, concentrating
in particular to the architecture of the core network (CN). As shown, there are two types of
radio access networks that can be interconnected to the 3GPP CN: the typical GMS BSS and
the UTRAN, which is expensively discussed in section 3.4.1. These radio access networks are
connected to the core network via standardised interfaces. In particular, the GSM BSS is
connected to the CS domain via the A interface (specified in 3GPP TS 08.06 and 3GPP TS
08.08) and to the PS domain via the classical Gb interface (specified in TS 08.16 and TS
08.18). Note that all 3GPP technical specifications can be found online at [10].
On the other hand, UTRAN is connected to CS domain via the Iu-cs interface and to the PS
domain via the Iu-ps interface. Both Iu-cs and Iu-ps will be discussed in section 3.4.6.
The mobile station (MS) illustrated in Figure 3.4 represents the physical equipment used by
a mobile network subscriber to access the 3GPP network. The MS uses the so-called Um
radio interface to access the GSM BSS and the Uu interface (discussed in Chapter 2) to access
UTRAN. Dual mode (GSM/UMTS) mobile stations have the capability to use both Um and
Uu. The MS comprises of the Mobile Equipment (ME) and a smart card, formally called
Universal Integrated Circuit Card (UICC) that contains a Subscriber Identity Module (SIM)

application and/or a UMTS Subscriber Identity Module (USIM) application. The ME
comprises of the Mobile Terminal (MT), which, in turn, may be decomposed into a Terminal
Adapter (TA) and Terminal Equipment (TE). When the MS contains a USIM application it is
also referred to as User Equipment (UE) in some of the 3GPP specifications. More informa-
tion about the MS functional split and UICC can be found in TS 23.002 [3] and TS 31.120
[48] respectively.
In the following sections we discuss some of the key aspects of the 3GPP R99 core
network. First, we briefly discuss the key network elements and network interfaces illustrated
in Figure 3.4. Later we discuss the most important features of the 3GPP R99 network. The
UTRAN architecture is discussed in section 3.4.1.
3.3.1.2 Core network elements
The Authentication Center (AuC) is an entity, which stores authentication data for each
mobile subscriber that is used to authenticate the subscriber (more correctly, the USIM card
Broadband Wireless Mobile: 3G and Beyond148
of the subscriber) and to cipher the communication over the radio path between the mobile
station and the network. The AuC interfaces only to the HLR through the H interface. When a
network element, such as an SGSN or an MSC, needs to authenticate a subscriber, it requests
authentication records from the HLR, which in turn contacts AuC to retrieve those authenti-
cation records.
AuC stores a secret key for each mobile subscriber, commonly denoted as K. This very
same key is also stored in the USIM and secured from unauthorised access. The secret key is
used to generate:
† authentication data which are used to authenticate the subscriber, and
† Ciphering and integrity keys, which after successful authentication, are used to encrypt the
data on the radio interface and to authenticate the signalling messages between the mobile
and the network.
The Equipment Identity Register (EIR) in the 3GPP system is the logical entity, which is
responsible for storing the International Mobile Equipment Identities (IMEIs), i.e. the unique
identities of the mobile equipments used to access the network. These identities are classified
as ‘white listed’, ‘grey listed’, ‘black listed’ or ‘unknown’. Typically, the network requests

the mobile equipment to send its IMEI at the beginning of every phone call. If the received
IMEI is included in the black list (because for instance it has been reported as stolen), then the
network denies the grand of mobile services to that mobile equipment. The EIR contains one
or several databases, which store the IMEIs used in the UMTS system.
Network Architecture 149
Figure 3.4 The basic reference architecture of 3GPP R99.
The Home Location Register (HLR) is a functional element that basically stores the
subscription records of the mobile subscribers (in this respect, it serves as a simple database)
and also aids in the location management procedures. Depending on the number of mobile
subscribers and on the capacity of the individual HLR equipments, a mobile network may
contain one or more HLRs. For each subscriber, the most important information typically
kept in the HLR includes:
† Subscription information, containing the services the subscriber is allowed to use.
† Information about the current location of the subscriber. This information enables the
charging and routing of calls/packets towards the MSC and/or the SGSN that currently
serves the subscriber.
† The privacy exception list for location services, which indicates the privacy class of the
subscriber.
† A list of Gateway Mobile Location Centre (GMLC), which is also used for location
services (see TS 23.071 [53]).
The HLR also stores several identifiers assigned to the user during subscription. Such
identifiers include:
† the International Mobile Station Identity (IMSI), i.e. the subscriber’s private identity;
† one or more Mobile Station International ISDN number(s) (MSISDN), i.e. the subscriber’s
public identity, or directory number;
† zero or more Packet Data Protocol (PDP) address(es), e.g. statically assigned IP addresses;
† the Location Management Unit (LMU) indicator (see TS 23.071).
The same IMSI or MSISDN is never assigned to more than one subscription therefore
either IMSI or MSIDSN can be used to uniquely identify a subscriber to the HLR.
The HLR can typically contain additional information such as:

† information about subscribed teleservices and bearer services;
† information about service restrictions (e.g. location areas wherein the subscriber in not
allowed to roam);
† a list of group IDs a subscriber is entitled to use to establish voice group or broadcast calls;
† information about supplementary services;
† information indicating if a GGSN in the visited network is allowed to dynamically allocate
PDP addresses to the subscriber.
The organisation of subscription data is specified in 3GPP TS 23.008 and the management
of subscriber data is specified in 3GPP TS 23.016.
The Visitor Location Register (VLR) is the element that manages and stores information
about the mobile stations roaming in an MSC area, i.e. in an area wherein a particular MSC
provides services. An MSC area is typically composed of one or more location areas. In turn,
every location area can be a one or more cell. Each time an MS enters a new location area it
registers on that location area. The MSC serving this area informs the VLR about the new
location area of the MS and in turn the VLR contacts the HLR to retrieve subscription
information and determine if the subscriber is allowed to roam in the new location area
and what type of services he may receive.
Although a VLR may control more than one MSC areas, it usually controls only one
because it is incorporated with the MSC into combined element referred to as MSC/VLR.
Broadband Wireless Mobile: 3G and Beyond150
The VLR keeps information needed to handle incoming calls towards the MSs located in
its MSC area. The most common information includes:
† the International Mobile Subscriber Identity (IMSI);
† the Mobile Station International ISDN number (MSISDN);
† the Mobile Station Roaming Number (MSRN), i.e. a temporary directory number assigned
to a mobile for routing incoming calls with common ISUP signalling (see 3GPP TS
23.003);
† the Temporary Mobile Station Identity (TMSI), see section 3.5.5 User Identity Confiden-
tiality;
† the Local Mobile Station Identity (LMSI);

† the location area where the mobile station is currently located;
† the identity of the SGSN that currently serves the mobile (this is applicable only when the
Gs interface is supported between the SGSN and the MSC/VLR).
The VLR also contains supplementary service parameters associated to the mobile subscri-
ber and received from the HLR.
The Mobile Switching Center (MSC) constitutes the interface between the radio system
and the fixed networks. The MSC performs all necessary functions in order to handle the
circuit switched services to and from the mobile stations. In particular, every MSC controls a
number of mobile stations (located in its MSC area) and performs the control-plane and user-
plane functions required for the provision of mobile CS services. The control-plane functions
include call control and mobility management functions and the transport of related signal-
ling is typically implemented with SS7. The user plane functions include functions that
support the user data transmission such as transcoding, echo cancellation, etc. In 3GPP
R99 the user-plane transport is usually implemented with AAL2/ATM technology.
The MSC includes an Interworking Function (IWF) that provides the required functionality
for interworking with fixed networks such as ISDN, PSTN and PDNs (Packet Data
Networks). The IWF is required to convert the protocols used in the 3GPP CS domain to
the corresponding protocols used in the external fixed network. If (for a particular type of
service) these protocols are compatible, then the IWF may be bypassed.
The main difference between an MSC and a typical switch in a fixed network is that the
MSC performs additional functions such as functions for radio resource allocation and for
mobility management. For providing service mobility, the MSC supports procedures for
location registration and procedures for handover (which transfers an ongoing call from
one BSS to another, or from one MSC to another). Typically, each MSC has interfaces to
several base station subsystems (BSSs) and controls the MSs located in the entire radio
coverage area of those BSSs (the so-called MSC area).
The Gateway MSC (GMSC) is a network element used for supporting incoming calls
from an external network to the CS domain, when the external network (for instance a PSTN)
cannot interrogate the HLR, because, for example, it does not support the MAP protocol. In
such situations, the GMSC serves as a ‘default’ gateway that receives all requests for incom-

ing calls. The GMSC interrogates the appropriate HLR to find the addressed user’s where-
abouts and then routes the call to the MSC, which currently serves this user. Usually, a mobile
operator can configure a typical MSC to serve as a GMSC too.
It is noted that, if the incoming call is a voice group/broadcast call, the GMSC routes the
Network Architecture 151
call directly to the VGCS/VBS anchor MSC, based on the information contained in the
dialled number.
The Gateway GPRS Support Node (GGSN) is a network element in the PS domain that
serves as a gateway providing connectivity to external packet data networks (PDNs) over the
Gi interface. It could be considered as a typical IP router implementing additional function-
ality for supporting mobile services. Such additional functionality includes the GPRS Tunnel-
ling Protocol (GTP), which manages user mobility by establishing and dynamically updating
GTP tunnels within the PS domain. The GGSN provides an anchor point that remains fixed
throughout a PS session and hides the mobility characteristics of the users. It implements also
routing functionality and screening, and may optionally communicate with the HLR via the
Gc interface.
More detailed information on the GGSN functionality and on GTP protocol is provided in
section 3.3.4 and in [57,58].
The Serving GPRS Support Node (SGSN) is a key network element in the PS domain
that provides the PS-related control- and user-plane functions. In the control plane, these
functions include the GPRS mobility management (GMM) and the session management (SM)
functions. The SGSN supports PS services over the Gb interface and/or the Iu interface.
The SGSN stores two types of subscriber data for handling originating and terminating
packet data transfers: the GPRS Mobility Management (GMM) information and the Session
Management (SM) information. When a mobile attaches to PS domain (i.e. to one SGSN), the
SGSN establishes a GPRS Mobility Management (GMM) for that mobile. In addition, when a
mobile establishes a new PS bearer, the SGSN creates a new PDP Context (see section 3.3.4).
The GMM context includes the mobile’s permanent identity (IMSI), its temporary identity
for the PS domain (called Packet-Temporary Mobile Station Identity – P-TMSI), its current
location, the address of the VLR currently serving the MS, information for authenticating the

MS, etc. On the other hand, the PDP context includes information about an established PS
bearer, such as the PDP address, the PDP Type, the external PDN related to this PS bearer,
etc.
The SGSN may optionally communicate with an MSC/VLR over the Gs interface. In such
situations, the SGSN may receive paging requests from the MSC/VLR, update the MSC/VLR
with a mobile’s current location, etc. More detailed information about the functionality of the
Gs interface can be found in 3GPP TS 29.018.
The SGSN may also interface with a Service Control Funtion (SCF) for providing service
control with the CAMEL protocol (see 3GPP TS 23.078). In such cases, the PS signalling
procedures may be suspended for some time and trigger the execution of CAMEL proce-
dures. Depending on the results of these CAMEL procedures, the suspended PS signalling
procedures may be resumed as normally (e.g. permit a subscriber to attach) or may be
terminated (e.g. prohibit a subscriber to attach). CAMEL is typically used to provide pre-
paid services.
The SGSN and GGSN functionalities may be implemented in the same physical node, or in
different physical nodes. The SGSN and the GGSN contain IP or other Routing functionality
and they may be interconnected with IP routers. When the SGSN and the GGSN are in
different mobile networks, they are interconnected via the Gp interface. This interface
provides the functionality of the Gn interface, plus security functionality required for the
intercommunication between different mobile networks. This security functionality is
Broadband Wireless Mobile: 3G and Beyond152
provided by means of the border gateway (see below) and it is based on mutual agreements
between different operators.
The procedures for information transfer between the SGSN, the GGSN, the VLR and the
HLR are defined in 3GPP TS 23.016 and 3GPP TS 23.060 [4]. Also, further discussion on the
SGSN functionality and related protocols is provided in section 3.3.4 and in [57,58].
The Border Gateway (BG) is an element that serves as a gateway between the PS domain
and an external IP backbone network that is used to provide connectivity with other PS
domains located in other core networks. For such interconnections, the BG provides the
appropriate level of security, e.g. support of IPsec tunnels, screening, etc. The BG is required

only to support PS-type of services. (Note that the BG is not shown in Figure 3.4.)
3.3.1.3 Interfaces in 3GPP Release 99
Interface between MSC and GSM BSS (A-interface)
The A interface operates between an MSC and a BSS and is specified primarily in 3GPP TS
08.08. The signalling protocol on this interface is called BSS Application Part (BSSAP) and
implements procedures for the provision of BSS management, call handling and mobility
management.
Interface between the MSC and RNS (Iu-cs interface)
The interface between the MSC and its RNS is discussed in section 3.4.8.
Interface between SGSN and RNS (Iu_ps-interface)
The interface between the SGSN and the RNS is discussed in section 3.4.8.
Interface between SGSN and BSS (Gb-interface)
The interface between the SGSN and the BSS supports BSSGP signalling and is further
discussed in section 3.3.4. The Gb interface is defined in 3GPP TS 08.14, TS 08.16 and
TS 08.18.
Interface between the HLR and the MSC (C-interface)
The C interface is used by the MSC in order to get subscription information from the HLR
about a particular subscriber and in order to obtain routing information for a call or a short
message directed to that subscriber. The C interface is also used to exchange routing infor-
mation, location information, subscriber status, etc. Moreover, the C interface is used as
described in 3GPP TS 23.078 to support the provision of CAMEL services. Signalling on
the C interface uses the Mobile Application Part (MAP), which operates on top of Transaction
Capabilities protocol as specified in 3GPP TS 29.002.
Interface between the HLR and the VLR (D-interface)
The D interface is used to exchange location information pertaining to a mobile station and to
manage the subscriber. The VLR sends to the HLR the location area wherein a mobile station
is currently located and provides it (either at location updating or at call set-up) with the
roaming number for that station. On the other way, the HLR sends to the VLR all the data
Network Architecture 153
needed to support the service to the mobile subscriber. When the mobile station enters an

MSC area controlled by a new VLR, the HLR instructs the old VLR to delete the location
registration of this mobile. Data exchange over the D interface may also occur when the
mobile subscriber requires a particular service, when he wants to modify data related to his
subscription or when some parameters of the subscription are modified by administrative
means. Moreover, D interface is used to send the CAMEL-related subscriber data to the
visited mobile network, to retrieve subscriber status and location information about the
mobile subscriber or to indicate suppression of a CAMEL service, etc. Signalling on the D
interface is carried out with the Mobile Application Part (MAP), which uses the services of
Transaction Capabilities.
Interface between MSC and VLR (B-interface)
The B interface is usually an internal interface since the MSC and VLR are implemented as a
single network element referred to as MSC/VLR. Therefore, signalling on this interface is not
standardised. The VLR serves as a location and management database for all mobile subscri-
bers roaming in the MSC area controlled by this VLR. Therefore, each time the MSC needs
data for a given mobile station located in its MSC area, it interrogates the VLR. When a
mobile station performs a location updating procedure with an MSC, the MSC updates its
VLR with the new location information. In addition, when a subscriber activates a supple-
mentary service or modifies some data related to a service, the MSC informs the HLR via the
VLR and the B interface.
Interface between MSCs (E-interface)
The E interface is used for inter-MSC signalling procedures required for example when a
mobile station moves from one MSC area to another during a call and a handover procedure
has to be performed. After the handover operation, the MSCs uses the E interface to transfer
Ainterface signalling as necessary. Also, the E interface is used when a short message has to
be transferred from a mobile station to a Short Message Center (SC) through the MSC
currently serving the mobile. In this case, the E interface carries the required signalling
from the MSC currently serving the mobile to the MSC that acts as the interface to the
SC. Signalling on E interface is carried out with the Mobile Application Part (MAP) as
specified in 3GPP TS 29.002.
Interface between MSC and EIR (F-interface)

The F interface is used between MSC and EIR in order to verify the status the International
Mobile Equipment Identity (IMEI) received from the mobile station. Typically, if the
received IMEI is included in a ‘black list’ (because for example the equipment has been
reported as stolen) the service to the mobile is denied. Signalling on this interface uses the
Mobile Application Part (MAP) as specified in 3GPP TS 29.002.
Interface between VLRs (G-interface)
The G interface is used when a mobile subscriber moves from one MSC area to another MSC
area, controlled by a different VLR. In this case, the location updating procedure is carried
out. This procedure may include the retrieval of the IMSI and authentication parameters from
Broadband Wireless Mobile: 3G and Beyond154
the old VLR. Signalling on this interface uses the Mobile Application Part (MAP) as specified
in 3GPP TS 29.002.
Interface between SGSN and VLR (Gr-interface)
The Gr interface is equivalent to D interface and it is used when an SGSN needs to inform the
HLR about the location of a mobile station. The HLR sends to the SGSN all data required to
support the service to the mobile subscriber. In addition, information transfer on the Gr
interface may occur when the mobile subscriber requires a particular service, when he
wants to change some data related to his subscription or when his subscription parameters
are modified by administrative means. Signalling on the Gr interface uses the Mobile Appli-
cation Part (MAP) as specified in 3GPP TS 29.002.?
Interface between SGSN and GGSN (Gn- and Gp-interface)
The Gn and Gp interfaces are used to support mobility between the SGSN and GGSN. These
interfaces are further discussed in section 3.3.4. The Gn/Gp interface is defined in 3GPP TS
29.060.
Interface between GGSN and HLR (Gc-interface)
The Gc is an optional interface that may be used by the GGSN to retrieve information about
the current location of a mobile subscriber and about the subscribed services of this subscri-
ber. This information is needed for supporting e.g. network initiated PDP context activation
(see section 3.3.4) or mobile terminating SMS delivery over the PS domain. If the GGSN
implements an SS7 interface the Gr interface uses the Mobile Application Part (MAP) as

specified in 3GPP TS 29.002. Otherwise, if the GGSN implements no SS7 interface, then the
Gr interface may be supported by any other GSN in the same mobile network, which imple-
ments an SS7 interface and an appropriate GTP-to-MAP protocol converter.
Interface between SGSN and EIR (Gf-interface)
The Gf interface is equivalent to F interface and it is used between the SGSN and the EIR in
order to verify the status of the IMEI retrieved from the mobile station. Typically, if the
received IMEI is included in a ‘black list’ (because, for example, the equipment has been
reported as stolen) the service to the mobile is denied. Signalling on this interface uses the
Mobile Application Part (MAP) as specified in 3GPP TS 29.002.
Interface between MSC/VLR and SGSN (Gs-interface)
The Gs is an optional interface that may be used between an SGSN and an MSC/VLR. With
this interface the SGSN may receive paging requests from the MSC/VLR, or it may send to
the MSC/VLR location information about a particular mobile. In addition, the MSC/VLR
may indicate to an SGSN that a mobile station is engaged in a service handled by the MSC.
The Gs interface uses the BSSAP1 protocol and it is specified in 3GPP TS 29.016 and 3GPP
TS 29.018.
Interface between HLR and AuC (H-Interface)
The H interface is used by the HLR when it needs to receive authentication data for a
Network Architecture 155
particular mobile station (e.g. because such data has to be forwarded to an MSC or SGSN).
The authentication data together with a secret key assigned to a subscriber during subscrip-
tion are maintained in the AuC. The AuC uses the secret key to derive the authentication data
for a subscriber and forwards this data to the HLR. The protocol used to transfer the data over
this interface is not standardised.
3.3.2 3GPP Release 4
3.3.2.1 Features of 3GPP Rel-4
The key features introduced in 3GPP Rel-4 are described below. Note that all of them apply
to later releases too.
Support of GSM/EDGE Radio Access Network (GERAN)
Apart from the legacy GSM radio access network and the UMTS terrestrial radio access

network (see section 3.4), 3GPP Rel-4 supports an evolved GSM radio access network, which
is termed as GERAN [54]. In Rel-4 GERAN is connected to the core network using an
evolved version of A and Gb interfaces, whilst in later releases GERAN uses in addition
the Iu interface. GERAN uses an EDGE (Enhanced Data rates for Global Evolution) radio
interface that is based on the TDMA technology of legacy GSM but introduces a set of
additional radio channels with different structure, different encoding and different modulation
from the typical GSM channels. These radio channels provide for increased capacity on the
radio interface. An overall description of GERAN architecture can be found in [54].
Support of heterogeneous bearer mechanisms
The 3GPP CN architecture is independent of the underlying transport mechanism. Ideally,
any transport technology could be used, such as STM, ATM or IP, with no impact on the
architecture and upper-layer protocols. This transport independency of the core network
allows a mobile operator to utilise its preferred transport mechanism or any combination
of transport mechanisms.
Standardized transport mechanisms
Although the transport mechanisms in Rel-4 and onwards may be freely chosen by the
operator, these transport mechanisms need to be standardised to allow interworking across
different operators. Therefore, the transport mechanisms for bearer control, call control, and
other signalling are based on standardised technologies, such as SS7 or SIGTRAN. The same
hold true for the transport mechanisms in the user plane.
Independence of access technology
The network design ensures that a common core network can be used with multiple wireless
and wireline access technologies, such as ADSL, WLAN, satellite access and any other
broadband radio access technology.
Support for a variety of mobile equipment
The network architecture supports a range of different terminal types ranging from simple
Broadband Wireless Mobile: 3G and Beyond156
speech only terminals to multimedia terminals and wireless IP clients (e.g. PDA or laptop).
However, not all terminals may be able to support end-to-end IP capabilities, e.g. terminals
that support CS voice calls only.

Core network functions are separated from radio access functions
The same network should support a variety of access choices, and access technologies may
evolve further. Therefore network functions such as call control, service control, etc. should
remain separate from access functions and ideally should be independent of choice of access.
This implies that the same CN should be able to interface with a variety of RANs.
High degree of decomposition
The overall functionality is decomposed into a number of independent functions. This way
the evolution of the overall architecture can be easily realised by evolving the individual
functional components. Those components need to be kept independent as far as possible.
Examples of major functions that may evolve independently include:
† security functions;
† bearer control in both access and network;
† multimedia control for multimedia sessions;
† switching and routing;
† mobility management, session control and access security functions in the PS domain;
† call control, mobility management and access security functions in the CS domain;
† location-based services;
† service capabilities;
† service features and applications.
Mobility management is decomposed to independent functions
Since mobility management has evolved to a quite complex function, it is split into several
individual components. These components are kept independent in order to facilitate the
mobility management and the deployment of different mechanisms. As a result, mobility
management is split to:
† Inter-domain mobility: location of the user in terms of the domain that is currently
serving the user.
† Change of Point of Attachment: location of the user in terms of the address at which the
user can be found. This point of attachment depends on the type of access network used
and it can be provided by a wireless or fixed network.
† Radio Access Mobility (or micro-mobility): location management and management of

the terminal associated with changes in RA/LA within a system, or associated with
changes in cell and RNC within RA/LA.
Improved speech support in the CS domain
Rel-4 features enhanced speech support, for example with Transcoder-Free Operation and
advanced AMR vocoders. Therefore, speech quality and transmission efficiency in the CS
Network Architecture 157
core network are improved. These improvements are applicable when a call is placed on both
Iu interface (UMTS) or A interface (GSM).
3.3.2.2 Basic Reference Architecture of 3GPP Rel-4
Figure 3.5 illustrates the reference architecture of 3GPP Rel-4. As mentioned in the previous
section, 3GPP Rel-4 supports an additional type of radio access network as compared to
3GPP R99 – the GSM/EDGE Radio Access Network (GERAN). Also, another important
difference from 3GPP R99 is that the MSC is split into two functional elements, one operating
in the control plane and another operating in the user plane. The first is referred to as MSC
Server and the latter is referred to as Media Gateway function (MGW).
In the basic reference architecture illustrated in Figure 3.5, all functional elements are
considered as implemented in different equipments. Therefore, all illustrated interfaces (or
reference points) are considered as external. Detailed information about interface A can be
found in specifications 3GPP TS 08.06 and 3GPP TS 08.08 and information about interfaces
Iu-ps and Iu-cs can be found in the 25.4xx-series of 3GPP technical specifications (see [10]).
Broadband Wireless Mobile: 3G and Beyond158
Figure 3.5 The basic reference architecture of 3GPP Rel-4.
Interfaces B, C, D, E, F and G use the Mobile Application Part (MAP – see [55]) to exchange
the data necessary to provide the mobile service. Also a general overview of all the GPRS-
specific interfaces (G-series) can be found in [4] v4.x.x. Interfaces Mc, Nb, and Nc are
defined in 3GPP TS 23.205 [56] and in the 29-series of 3GPP technical specifications.
Note that no protocols across the H-interface are standardised.
Below we briefly discuss the network elements and the interfaces that have been intro-
duced in Rel-4 (i.e. they do not exist in R99).
A Signalling Gateway (SGW) is an element that performs signalling translation at the

transport level between an SS7-based transport signalling and an IP-based transport signal-
ling (i.e. translation between Sigtran SCTP/IP transport [45,46] and SS7 MTP transport). The
SGW performs no signalling translation at the application layer (e.g. MAP, CAP, BICC,
ISUP) but may have to interpret the underlying SCCP [36] or SCTP layer to ensure proper
routing of the signalling.
The MSC Server is a signalling element that provides the call control (CC) and mobility
control functionality of the MSC. The MSC server sets up and manages the mobile originated
and mobile terminated calls over the CS Domain. It terminates the user-network signalling
and translates it into the relevant network-to-network signalling. The MSC Server also
contains a VLR, which (see section 3.3.1) maintains subscription data and CAMEL related
data.
The Gateway MSC Server (GMSC Server) is the element that comprises the call control
and mobility control parts of a GMSC (see section 3.3.1).
The Media Gateway Function (MGW) is a function in the user plane that handles the
interworking with the PSTN. The MGW typically terminates bearer channels from an exter-
nal circuit-switched network and media streams from a packet-switched network (e.g. RTP/
UDP/IP streams) and it bridges these bearer channels through media conversion, bearer
control and payload processing. In this context, the MGW interacts with MSC server and
GMSC server for resource control by using the H.248 protocol. The MGW includes the
necessary resources for supporting UMTS/GSM transport media.
The following interfaces have been introduced in Rel-4.
Interface between (G)MSC server and MGW (Mc-interface)
The Mc interface is defined between the MSC Server and the MGW, and between the GMSC
Server and the MGW. It is based on H.248/IETF Megaco standard mechanisms. The func-
tionality across the Mc reference point supports mobile-specific functions such as SRNS
relocation/handover (see section 3.4.9) and anchoring. In short the key features of Mc include
the following (see [3] for Rel-4):
† The Mc is fully compliance with the H.248 standard.
† The Mc supports flexible connection handling, which allows support of different call
models and different media processing purposes not restricted to H.323 usage.

† The Mc provides an open architecture and facilitates the definition of extensions.
† The Mc supports dynamic sharing of MGW physical node resources. A physical MGW
can be partitioned into logically separate virtual MGWs consisting of a set of statically
allocated terminations.
† The Mc supports dynamic sharing of transmission resources.
Network Architecture 159
Interface between MSC Server and GMSC Server (Nc-interface)
Across the Nc interface the network-to-network call control procedures are performed. Such
network-to-network call control procedures may include the traditional ISUP procedures
(which also support bearer control), or the Bearer Independent Call Control (BICC) proce-
dures. Different transport technologies can be used on Nc such as STM, ATM and IP. When
the network-to-network call control protocol employed internally in the 3GPP core network is
different from ISUP, which is used in PSTN, then a signalling gateway is required for
signalling translation and interworking with PSTN. This is illustrated in Figure 3.5.
Interface between MGW and MGW (Nb-interface)
The Nb interface is used to support the user plane traffic between MGWs. This user plane
traffic could be composed for instance of speech packets with specific encoding (e.g. the
classical GSM full-rate/half-rate, AMR, etc). The user plane traffic on Nc is typically trans-
ported with either RTP/UDP/IP or AAL2. In general, 3GPP Rel-4 supports different options
for user data transport and bearer control on Nb such as AAL2/Q.AAL2, STM/none, RTP/
H.245.
Interface between HLR and R-SGW (Mh-interface)
The Mh interface supports the exchange of mobility management and subscription data
information between the HLR and R99 or pre-R99 networks. This interface is required to
support network users of Rel-4 or above who are roaming in networks that implement
previous releases.
3.3.3 3GPP Release 5
3.3.3.1 Key Features of 3GPP Rel-5
The main characteristics of 3GPP Rel-5 are summarised below.
IP transport in the UTRAN

3GPP Rel-5 enables the usage of IP technology (as an alternative to ATM technology) for the
transport of signalling and user data over Iu, Iur and Iub in the UTRAN. IP transport in
UTRAN provides for efficient and cost-effective utilisation of UTRAN resources. Further
information on this feature can be found in 3GPP TR 25.933.
High Speed Downlink Packet Access (HSDPA)
In 3GPP Rel-5 several techniques are specified, which facilitate high-speed downlink packet
access in the UTRAN. These techniques include adaptive modulation and coding, hybrid
ARQ and other advanced features. An overall description of these techniques can be found in
3GPP TR 25.950 and in 3GPP TR 25.855.
Intra Domain Connection of RAN Nodes to Multiple CN Nodes
In 3GPP Rel-5 it is recognised that the requirement to have one RNC or BSC controlled by a
single MSC server or SGSN lead to certain limitations. For this reason, Rel-5 provides
support for allowing the BSCs and RNCs to be shared by a number of difference MSC servers
Broadband Wireless Mobile: 3G and Beyond160
or SGSNs. This support increases the network performance in terms of scalability, distribut-
ing the network load amongst the serving entities, and reducing the required signalling as the
user roams. Detailed information about this feature can be found in 3GPP TS 23.236.
GERAN Iu interface
In 3GPP Rel-5 architecture the GSM/EDGE Radio Access Network (see Figure 3.5) can be
connected to the core network over the standard Iu interface of UMTS. The Iu interface is
discussed in section 3.4.6.
End-to-End QoS for PS Domain
3GPP Rel-5 provides a framework for end-to-end Quality of Service, i.e. for IP bearers with
guaranteed QoS properties not only in the UMTS domain but also within the domain of
external IP networks. For this purpose, interworking between the UMTS QoS mechanisms
and the IP QoS mechanisms (defined by IETF – mainly DiffServ and IntServ) are required.
The architecture and the mechanism for the provision of end-to-end QoS are specified in
3GPP TS 23.207.
Provisioning of IP-based Multimedia Services
3GPP Rel-5 supports a special core network subsystem, which is called the IP Multimedia CN

Subsystem (IMS). IMS is the key characteristic of 3GPP Rel-5. It is virtually a signalling
system on top of PS domain (i.e. accessible over typical PS bearers) that enables the provision
of IP multimedia services. From the mobile point of view, IMS is a signalling application that
can be used to provide various services. Note that IMS implements the signalling procedures
for the provision of those services, however, it does not provide the services themselves. The
services are not specified in 3GPP specifications; only the interfaces towards the users and the
service platforms are specified. Therefore, IMS is as an open signalling system, based on
standard Internet technology, which supports the migration of Internet applications (for
example, voice-over-IP, multimedia messaging, video-conferencing, etc.) to the mobile
environment and offers enhanced service control capabilities.
Mobile users may access IMS through the bearer services provided by the PS domain. IMS
service mobility is maintained by exploiting the mobility management services of PS domain.
Note that IMS is independent from the CS domain although some network elements may be
shared with the CS domain. Note also that access to IMS is not necessarily provided over the
PS domain. In fact, any suitable access means can be used, such as wireless LANs, or wireline
access technology. In any case, the technology that provides access to IMS needs to handle
the user mobility and in particular to hide the mobility of the user when it roams within the
same mobile network. This is because IMS does not provide mobility management and
assumes that the user is always accessible through the same reference point (also called
anchor point). To achieve access independence and to maintain a smooth interoperation
with wireline terminals across the Internet, IMS needs to conform to standard IETF protocols.
For this reason, the Session Initiation Protocol (SIP) [49] has been selected as the IMS
signalling protocol to/from the users and to/from the service control platforms (see TS
23.218 [51]).
Network Architecture 161