<<

. 104
( 132 .)



>>

ATM Forum: LANE v2.0 LUNI Interface, af-lane-0084.000.
ATM Forum: Multi-protocol Over ATM Speci¬cation, Version 1.1, af-mpoa-0114.000.
ATM Forum: MPOA v1.1 Addendum on VPN Support, af-mpoa-0129.000.
ATM Forum: Private Network-Network Interface Speci¬cation v.1.1, af-pnni-0055.001.
ATM Forum: ATM User Network Interface (UNI) Signalling Speci¬cation version 4.1,
af-sig-0061.001.
ATM Forum: Utopia, af-phy-0017.000.
ATM Forum: Utopia Level 2, af-phy-0039.000.
ATM Forum: E-1 Physical Layer Interface Speci¬cation, af-phy-0064.000.
ATM Forum: Inverse ATM Mux Version 1.0, af-phy-0086.000.
ATM Forum: Inverse Multiplexing for ATM (IMA) Speci¬cation Version 1.1, af-phy-
0086.001.
ATM Forum: ATM on Fractional E1/T1, af-phy-0130.000.
ATM Forum: Utopia 3 Physical Layer Interface, af-phy-0136.000.
ATM Forum: UTOPIA Level 4, af-phy-0144.001.
ATM Forum: Private Network-Network Interface Speci¬cation V. 1.0, af-pnni-0055.000.
ATM Forum: ATM Forum Addressing: User Guide Version 1.0, af-ra-0105.000.
ATM Forum: Circuit Emulation, af-saa-0032.000.
ATM Forum: ATM Names Service, af-saa-0069.000.
ATM Forum: UNI Signalling 4.0, af-sig.0061.000.
ATM Forum: Traf¬c Management 4.0, af-tm-0056.000.
ATM Forum: Traf¬c Management 4.1, af-tm-0121.000.
ATM Forum: ATM User-Network Interface Speci¬cation V3.1, af-uni-0010.002.
G.803: ITU-T: Architecture of transport networks based on the synchronous digital hier-
archy (SDH).
G.804: ITU-T: ATM cell mapping into Plesiochronous Digital Hierarchy (PDH).
I.361: ITU-T: B-ISDN ATM layer speci¬cation.
I.363.1: ITU-T: B-ISDN ATM Adaptation Layer speci¬cation: Type 1 AAL.
I.363.2: ITU-T: B-ISDN ATM Adaptation Layer speci¬cation: Type 2 AAL.
I.363.3: ITU-T: Type 3/4 AAL.
I.363.5: ITU-T: Type 5 AAL.
I.366.1: ITU-T: Segmentation and Reassembly Service Speci¬c Convergence Sublayer
for the AAL type 2.
I.371: ITU-T: Traf¬c control and congestion control in B-ISDN.
I.371.1: ITU-T: Guaranteed frame rate ATM transfer capability.
I.432.1: ITU-T: General characteristics.
I.630: ITU-T: ATM protection switching.
Q.711: ITU-T: Functional description of the signalling connection control part.
Q.712: ITU-T: De¬nition and function of signalling connection control part messages.
Q.713: ITU-T: Signalling connection control part formats and codes.
Q.714: ITU-T: Signalling connection control part procedures.
Q.715: ITU-T: Signalling connection control part user guide.
FURTHER READING 507


Q.716: ITU-T: Signalling System No. 7“Signalling connection control part (SCCP) per-
formance.
Q.2100: ITU-T: B-ISDN signalling ATM adaptation layer (SAAL)“Overview description.
Q.2130: ITU-T: B-ISDN signalling ATM adaptation layer “ Service speci¬c coordination
function for support of signalling at the user“network interface (SSCF at UNI).
Q.2140: ITU-T: B-ISDN ATM adaptation layer “ Service speci¬c coordination function
for signalling at the network node interface (SSCF AT NNI).
Q.2150.1: ITU-T: Signalling Transport Converter on MTP3 and MTP3b.
Q.2150.2: ITU-T: Signalling Transport Converter on SSCOP and SSCOPMCE.
Q.2210: ITU-T: Message transfer part level 3 functions and messages using the services
of ITU-T Recommendation Q.2140.
Q.2630.1: ITU-T: AAL type 2 signalling protocol (Capability Set 1).
Q.2630.2: ITU-T: AAL type 2 signalling protocol “ Capability Set 2.
A list of the current versions of the speci¬cations can be found at http://www.3gpp.org/
specs/web-table specs-with-titles-and-latest-versions.htm, and the 3GPP ftp site for the
individual speci¬cation documents is http://www.3gpp.org/ftp/Specs/latest/
8
IP Telephony for UMTS
Release 4



8.1 INTRODUCTION

With UMTS Release (R4), the architecture of the core network circuit switched domain is
revised radically. The circuit traf¬c is delivered over an internal packet switched Internet
protocol (IP) network with connections to external networks handled via media gateways
(MGW). Figure 8.1 shows the architecture of an R4 network.
The architecture of the CS core is described by TS 23.205 ˜Bearer-independent cir-
cuit switched core network™, termed bearer-independent since the core network can be
asynchronous transfer mode (ATM) or IP, with many different Layer 2 options.
In this case traf¬c entering or exiting the circuit switch domain is controlled by the
MGW. This is responsible for switching the traf¬c within the core network domain and
performing data translation between the packet-based format used within the core network
and the circuit switched data transmitted on the PSTN or ISDN external network. The
MGW is controlled by the mobile switching centre (MSC) server, which sends the MGW
control commands, for example to establish bearers to carry calls across the core network.
The user data (i.e. voice traf¬c) within the CS-CN domain can be carried within ATM
cells (ATM adaptation layer 2; AAL2) or IP packets. Note that from R99 to R4 the only
part of the network to change is the CS domain; the PS domain and the radio access
network (RAN) remain the same as before. For the user equipment (UE), circuit switched
traf¬c will still be seen as a stream of bits, even though these bits are split into separate
packets or cells as they are forwarded over the UMTS terrestrial RAN (UTRAN) and
core network.


Convergence Technologies for 3G Networks: IP, UMTS, EGPRS and ATM J. Bannister, P. Mather and S. Coope
™ 2004 John Wiley & Sons, Ltd ISBN: 0-470-86091-X
510 IP TELEPHONY FOR UMTS RELEASE 4


Circuit Core



MSC Server/VLR
PSTN/ISDN/
RAN CSPDN

MGW
MGW



UE HLR AuC EIR
RNC
WBTS
Data Network
IP
e.g. Internet
Backbone
Uu Iu
SGSN GGSN
Packet Core


Figure 8.1 Release 4 UMTS architecture


8.2 R4 SOFTSWITCH ARCHITECTURE

In R4 the separation of the switching and call control functions within the core network
is commonly referred to as a softswitch architecture. The call control component, i.e. the
MSC server, is the softswitch in this case. This separation of functions makes it easier to
scale the network as the traf¬c demand increases. If the network planners require more
switching capacity they can add MGWs; if they require more call control capacity they
then add more MSC servers. This is a clear distinction from the UMTS Release 99 and
GSM networks, in which the call control and switching functions are all carried out within
the MSC and gateway MSC (GMSC).
For R4 the GSM MSC functionality is split into two components, the MSC server and
the MGW.



8.2.1 MSC server

This performs functions such as call control for mobile-originated and mobile-terminated
calls, and mobility management in terms of maintenance of the registry of mobiles within
its area of control. The MSC server integrates with the visitor location register (VLR)
component, which holds location information as well as CAMEL (customized applications
for mobile network enhanced logic) data for subscribers. Functions carried out by the MSC
server include:

• controlling the registration of mobiles to provide mobility management;
• providing authentication functions;
• routing mobile-originated calls to their destination;
• routing mobile-terminated calls by using paging to individual mobiles.
8.2 R4 SOFTSWITCH ARCHITECTURE 511


The MSC server terminates signalling from the mobile network over the Iu interface to
the radio network controller (RNC). It also controls the establishment of bearers across
its core by the use of MGWs under its control.


8.2.2 Media gateway (MGW)
This translates media traf¬c between different types of network. Functionality carried out
by the MGW includes:

• termination of bearer channels from the circuit switched and packet switched networks;
• echo cancellation for circuit switched circuits;
• translation of media from one CODEC form to another, e.g. G.711 to G.729;
• optional support of conferencing bridge function.

Each MGW is controlled by one or more MSC servers.


8.2.3 Gateway MSC server (GMSC server)
The GMSC server provides the same call control functionality that is provided by the
GMSC in GSM. It works in conjunction with the home location register (HLR) to allow:

• calls from outside the operator™s network to be routed to the appropriate MSC server.
• calls from within the operator™s network to be forwarded on the PSTN.

The GMSC server uses the services of MGWs to control the establishment of bearer
channels across the circuit core network and to terminate circuit switched bearers originat-
ing from the PSTN. Figure 8.2 shows the internal connections within the CS core network.

Applications
HLR
& Services

CAP C
CAP D


MSC GMSC
signalling Server Server
Nc
UTRAN Iu Mc Mc
Nb
MGW MGW
data
transfer
Circuit Core

Figure 8.2 Core network CS domain release 4
512 IP TELEPHONY FOR UMTS RELEASE 4


Within the core network three separate interface are de¬ned; Mc, Nc and Nb. The
Mc interface carries control instructions and signals between the MSC servers (MSC and
GMSC) and a MGW. Apart from control commands from the MSC server to the MGW
this channel also allows the MGW to signal events back to the MSC server. For example,
if the MGW receives dual tone multi-frequency (DTMF) signals from the phone connected
in the PSTN domain these can be relayed back to the MSC server. The protocol that is
used over this interface is called MEGACO (MEdia GAteway COntrol) and is de¬ned in
ITU recommendation H.248. Its functionality is described in Section 8.7.
The Nc interface carries signalling between two MSC servers. This allows the MSC
server that is handling the incoming call MGW to signal its requirements to the other
MSC server that controls the outgoing call MGW. The protocol that handles this signalling
function is called bearer-independent call control (BICC). BICC is an ITU-T signalling
protocol which provides the equivalent services to the ISDN call control protocol ISUP,
regardless of both the underlying bearer used to transport the messages, and the media,
hence the term bearer-independent. Its functionality is described in Section 8.8.
The Nb interface carries the user data between the MGWs. The protocol used to trans-
port the data over the Nb interface is the user plane (UP) protocol as speci¬ed in 29.415
and 25.415. The interface offers both transparent and support mode for prede¬ned SDU
sizes and is identical to the Iu user plane protocol as described in Chapter 5. In support
mode it allows strict control of the timing of the ¬‚ow of media between MGWs and
from MGW to the UTRAN (RNC). There are two transport protocol options available
over this interface, IP and ATM. For the IP transport option user traf¬c will be carried in
real-time transport protocol (RTP) packets, which are delivered over UDP/IP, and for the
ATM option, traf¬c transport is AAL2 as it is in UTRAN.
Even though 3GPP does not require IP to be used for transport within the CN-CS
domain there may be a number of bene¬ts to be gained by doing so. This simpli¬es the
call signalling for voice over IP (VoIP) calls. Also, the use of IP allows the operator to
choose more freely from a range of network technologies at layer 2, including 10-gigabit
Ethernet and IP over ATM. This allows the most appropriate choice to be made depending
on bandwidth, quality of service (QoS) and budgetary requirements.



8.2.4 CS domain external interfaces

Apart from the interfaces to the RAN and the PSTN, the CS domain also needs to
interface to a number of data sources including the HLR and other servers supporting
user applications. Two traditional interfaces are de¬ned between the CS core network and
the HLR. The D interface is between the VLR and the HLR and allows the VLR to send
updates about a mobile™s location information to the HLR. The C interface is used by the
GMSC when it needs to route a mobile-terminated call and must ¬nd out to which MSC
server the call is to be routed. In both these cases the protocol used over these interfaces
is the mobile application part (MAP), i.e. the mobility management application protocol
for signalling system 7 (SS7).
8.3 VOICE OVER IP (VoIP) 513


8.2.5 CAMEL
CAMEL allows users to obtain the full range of services usually offered by their home
network provider when roaming to a visited operator™s network. Services such as pre-
paid calling, caller ID and call forwarding on busy were traditionally provided within
GSM networks using the intelligent network (IN). Unfortunately, the IN service could
not be provided between operators since each IN service was proprietary and no standard
protocol was developed so that operators could signal service capabilities for individuals
roaming in a visited network. The CAMEL application part (CAP) provides a standardized
protocol that can be used between operators. This protocol allows service descriptions and
information such as pre-paid subscription details to be retrieved even when the user is
roaming. The ability to provide pre-paid roaming is only a small part of the CAMEL
service capability.



8.3 VOICE OVER IP (VoIP)

In UMTS from R4 onwards the use of Voice over IP (VoIP) becomes one of the dominant

<<

. 104
( 132 .)



>>