IP Connectivity in Core Networks

IP Connectivity in Core Networks
dn0550898 # Nokia Corporation 1 (101)

Issue 3 en Nokia Proprietary and Confidential
The product described in this document is still under development by Nokia Networks. However,
in the interest of offering early possibility to our customers to evaluate the documentation, this
documentation is provided in draft form. Therefore the customer understands that the
information in this document is subject to change without notice and describes only the prototype
product defined in the introduction of this documentation in its current state of development.
Nokia Networks welcomes customer comments as part of the process of continuous
development and improvement of its products and the documentation.
This document is not a final customer document and Nokia Networks does not take
responsibility for any errors or omissions in this document. No part of it may be reproduced or
transmitted in any form or means without the prior written permission of Nokia Networks. The
document has been prepared to be used by professional and properly trained personnel, and the
customer assumes full responsibility when using it.
The information or statements given in this document concerning the suitability, capacity, or
performance of the mentioned hardware or software products cannot be considered binding but
shall be defined in the agreement made between Nokia Networks and the customer.
Nokia Networks WILL NOT BE RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS
DOCUMENT OR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING
MONETARY LOSSES), that might arise from the use of this document or the information in it.
UNDER NO CIRCUMSTANCES SHALL NOKIA BE RESPONSIBLE FOR ANY LOSS OF USE,
DATA, OR INCOME, COST OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES,
PROPERTY DAMAGE, PERSONAL INJURY OR ANY SPECIAL, INDIRECT, INCIDENTAL,
PUNITIVE OR CONSEQUENTIAL DAMAGES HOWSOEVER CAUSED.
THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIRED
BY APPLICABLE MANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESS
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT,
ARE MADE IN RELATION TO THE ACCURACY, RELIABILITY OR CONTENTS OF THIS
DOCUMENT. NOKIA RESERVES THE RIGHT TO REVISE THIS DOCUMENT OR
WITHDRAW IT AT ANY TIME WITHOUT PRIOR NOTICE.
This document and the product it describes are protected by copyright according to the
applicable laws.
NOKIA and Nokia Connecting People are registered trademarks of Nokia Corporation. Other
product names mentioned in this document may be trademarks of their respective companies,
and they are mentioned for identification purposes only.
Copyright © Nokia Corporation 2006. All rights reserved. Reproduction, transfer, distribution or
storage of part or all of the contents in this document in any form without the prior written
permission of Nokia is prohibited.
2 (101) # Nokia Corporation dn0550898

Nokia Proprietary and Confidential Issue 3 en
Contents
Contents
Contents 3
1 Changes in IP Connectivity in Core Networks 5
2 Backbone connectivity solution 7
3 Reference network for the packet backbone solution 11

3.1 Network evolution 11
3.2 Traffic mix 16
3.3 Network structure 17
4 IP connectivity 27
4.1 IP connectivity in a mobile network 28
4.2 Site connectivity solutions 30
4.3 Site interconnection (backbone) 31
4.4 Inter-operator connections 31
4.5 Fixed network access 31
5 Core network site solutions 33

5.1 Core network site functionality and design 33
5.2 GPRS and 3G packet core site solution 43
5.3 MSC Server System site solution 48
5.4 UMA site solution 54
5.5 IP Multimedia Subsystem site solution 54
5.6 Push to Talk over Cellular site solution 57
5.7 Products used in the core network site solution 59
6 WAP gateway and MMS site solution 61
7 Controller site solution 65

7.1 Controller site options 66
8 Backbone network implementation 73

8.1 Planning site interconnection (backbone) 73
8.2 IP/MPLS backbone 80
8.3 ATM backbone 82
8.4 Transmission layer 84
9 Quality of Service in the packet backbone 85
10 Backbone network security 89

10.1 Security in wide area network 90
10.2 Firewalls 91
10.3 IPSec infrastructure 93
10.4 IPSec VPN 94
11 Summary of IP connectivity for core networks 99

Related Topics 101

Changes in IP Connectivity in Core Networks
1 Changes in IP Connectivity in Core

Networks
The following changes have been made since the last documentation release. The
changes are detailed in the table below.
Table 1. Changes in IP Connectivity in Core Networks
Change See
Many 3G operators are planning the deployment of Reference network for the packet backbone solution
HSPA or some other high-speed radio technology.
The most suitable backbone transport solution
depends on the operator's network environment
and network evolution strategy. Operator starting
point is one important element to be considered.
Consolidating TDM and ATM traffic on an IP/MPLS
network is a future-proof solution as IP-based
versions of the key mobile network interfaces
become available within the next years.
For enhanced resilience and scalability, It is Connectivity to external networks in Core network site
recommended to build a separate Gp access functionality and design
network with redundant access to the GRX network
(or networks).
In the Gi network, the principles of the site solution GPRS and 3G packet core site solution
remain the same with the Nokia Flexi-ISN 2.0.
For connecting Unlicensed Mobile Access (UMA) - UMA site solution

capable devices to the Nokia Core network, the
MSC Server System is extended with UMA-specific
elements.

Table 1. Changes in IP Connectivity in Core Networks (cont.)
Change See
It is recommended to use IPv6 in large scale IMS IP Multimedia Subsystem site solution
deployments. Using IPv4 connectivity will be
problematic in the long run because inter-operator
connectivity, NAT traversal and the growing number
of IMS users bring challenges to IP addressing.
IMS services' need of user-to-user IP connectivity
causes new security concerns, such as risk for
denial of service and overbilling attacks as well as
spreading of worms and viruses. Introducing SIP-
aware firewalls or session border controllers will
help control from which sources traffic is sent to the
mobile terminals.
Support for multihoming signalling connections is Resilience in Planning site interconnection (backbone)
one of the basic requirements for the backbone.
Next Generation SDH has been added. Transmission layer

Backbone connectivity solution
2 Backbone connectivity solution

The main target of the backbone connectivity solution is to have a transport
network that efficiently fulfills the needs and requirements of the mobile network
applications running on top of it. Nokia and its partners can provide end-to-end
backbone solutions including all the required products.
The number of existing or planned core sites and the number of existing
backbone or transmission solutions is of key importance when planning the
backbone solution for a mobile network. For multisite cases, the cooperation
between Nokia and Cisco enables tailored IP and ATM backbone solutions. The
backbone solutions support the intra-site packet connectivity of GPRS, 3G packet
core, and MSC Server traffic. In all cases, the backbone architecture must support
the evolution of the mobile standards. 3GPP R99 adds the ATM-based Iu
interfaces to the TDM-based GSM architecture. 3GPP Rel-4 specifications allow
the separation of switching and call control in the CS core network using the MSC
Server System. 3GPP Rel-5 removes the imperative to use ATM transport at the Iu
interface. 3GPP Rel-5 also introduces the IP Multimedia Subsystem (IMS) and
Session Initiation Protocol (SIP) connectivity for IMS.

GRX
Core Site Server Site Core Site

MMSC, WAP GW,
MSC Server, MGW, HLR Download/streaming MSC, HLR, SGSN, GGSN
SGSN, GGSN, CPS, IMR... server... IP/LAN connectivity
IP/LAN connectivity IP/LAN connectivity
Backbone Transport
ISP
PSTN -IP/MPLS, ATM networks
-SDH/DWDM
Controller Site Controller Site

Corporate Corp.
BSC, RNC, MGW BSC
IP connectivity IP connectivity
Regional Transport
-TDM/ATM
-SDH
Access Transport
IP
TDM
Figure 1. The application area of the backbone solution in a mobile network
When moving from Circuit Switched (CS) to Packet Switched (PS) technology,
mobile operators need to implement IP connectivity between the mobile network
elements. In the transition process, there are three technical challenges. First of
all, the Quality of Service (QoS) scheme of the network has to support both real-
time and non-real-time traffic. Secondly, network resilience should be at least as
good as in the TDM-based systems. Finally, network security has to be ensured.
These challenges have to be met in a cost-effective way using architectural
solutions that can be expanded along with the increasing number of mobile
subscribers and use of mobile services.

In addition, network operators also need to develop operational procedures for the
IP networking equipment to make sure that the IP network is operated according
to telecom quality requirements.
Site connectivity
IP connectivity in mobile networks consists of site connectivity and site

interconnection. Site connectivity solution describes how the network elements
are connected to each other on a physical site. Site interconnection covers the
methods of connecting the sites to each other using backbone networks or direct
links. Nokia's IP connectivity solution is based on site connectivity solution.
There are only very few direct links between the network elements and backbone
network, and Nokia network elements do not rely on any specific backbone
technology for site interconnection. While IP/MPLS technology is recommended
for site interconnection, ATM networks and direct links between site routers are
equally supported. This allows a cost-efficient migration to packet-based
networks for any type of mobile operator.
For more information on LAN and IP connectivity of the CS core network

elements, see Site Connectivity Guidelines for CS Core Network provided in CS
Core System Documentation library.
Network operation and management
As part of a mobile system, Nokia also provides a network management solution

for the backbone transport network and its integration to the overall Nokia mobile
network operations support solution, the Nokia NetAct Framework. The Nokia
solution provides operators and service providers a complete set of tools to
support end-to-end processes of operating and developing the whole service
platform. For more information, see the section Nokia NetAct in CS Core System
Overview available in the CS Core System Documentation library.
CiscoWorks provides a standalone network management platform for Cisco LAN

and WAN components of Nokia IP backbone networks. This solution enables
network management and simplifies configuration, administration, monitoring
and troubleshooting of Cisco routers and LAN switches. For more information,
see Cisco web pages (www.cisco.com).
Firewalls
Firewalls (FWs) ensure that communication between the core network and the
Internet/inter-PLMN backbone conforms to a declared security policy. Security is
achieved by using the Stateful Inspection technology. This technology allows the
firewall to associate a network with an application once a session has started. In
other words, the firewall recognises individual packets as being associated with

certain applications. Applications that require the end user to contact a server
through a specific port find the association very useful when the server has
allocated a random port for the back connection. Applications like this present
difficulties for simple packet filters.
Domain name server
In an IP network, a Domain Name Server (DNS) is required for translating Fully

Qualified Domain Names (FQDNs) (such as www.nokia.com) into physical IP
addresses (such as 128.92.10.10). For reliability, each PLMN should include two
DNS servers, one primary and one secondary (backup).
In the CS core network, DNS is part of the MSC Server System. The Session
Initiation Protocol (SIP) requires the DNS to resolve IP addresses of the other
signalling end point. In the Nokia MSS and Gateway Control Server (GCS), SIP
can be used as an alternative call control protocol in IP-based networks, and in the
MSS, SIP is used as a tunnelling method for ISDN User Part (ISUP) messages.
The DNS can be used also for setting up H.248 connections in the Multimedia
Gateway (MGW) start-up or when new H.248 connections are created.
In the MSS system, DNS services are needed for converting FQDNs into physical
IP addresses. Reverse conversion from the IP address to the FQDN is needed if
the FQDN of the signalling unit's IP address has to be found out. These FQDNs
are used in SIP and in SIP for telephony (SIP-T). DNS servers are located in the
IP backbone together with the MSSs and the MGWs. On the IP level, the
backbone is independent of other external networks.
The IMS is based on IP networks and requires DNS support to map FQDNs into
physical IP addresses. The IMS also utilises DNS/ENUM functionality in
addition to basic DNS. ENUM is used to map E.164 numbers to SIP contacts.
For more information, see DNS in MSC Server System in M-releases' product
documentation library. The DNS server can be based on the Nokia DNS product.
For more information, see Nokia Domain Name Server product description.

Reference network for the packet backbone solution
3 Reference network for the packet

backbone solution
3.1 Network evolution

Mobile networks are built in very different network and business environments.
For many network operators, the starting point for 3G rollout is a 2G or 2.5G
network that has been operational for several years. Some operators start building
the 3G network from the very beginning while some are already deploying HSPA
or some other high-speed radio technologies.
In all cases the transport network architecture has to support the evolution of the
mobile standards. The 3GPP R99 specification adds the ATM-based Iu interfaces
to the TDM-based GSM architecture. In the later 3GPP releases, the use of ATM
transport is no longer obligatory. 3GPP Rel-4 allows the separation of switching
and call control in the circuit switched (CS) domain using the MSC Server
System. 3GPP Rel-5 introduces IP transport of the Iu interfaces, the IP
Multimedia Subsystem (IMS) and Session Initiation Protocol (SIP) connectivity
for IMS.
The transport network has to support the mobile network so that the performance
of the network is not compromised. In many cases the initial rollout of the 3G
network has been based on equipment compliant with the 3GPP R99
specifications. The network is then extended using 3GPP Rel-4 and Rel-5 -
compliant equipment. A smooth transition between the phases is necessary to
guarantee uncomplicated network evolution.
The transport network needs to provide the required connectivity, capacity and
resilience both in the backbone and the access network. Additionally it has to
contribute positively to:
. the overall end-to-end Quality of Service (QoS)

.
security
. service availability and manageability

The 3G backbone transport network usually utilises an existing network. A new

network can be built on top of an existing one, or using the physical facilities of
the existing transport network (fibers and sites, for example). Therefore, the
existing transport networks whether own or provided by other operators play
a significant role in the backbone transport solution.
A typical hierarchical structure of a transport network including the approximate

number of different sites is shown below. The backbone transport can be
considered to include one or two of topmost tiers. The solutions presented here
cover both.

Transport Corresponding mobile network sites

Sites
2G 3G High Speed
Networks
High capacity transport
backbone
Core sites MSC+SGSN MSC+SGSN Gateways
(2...8) sites, may include sites, includes Server farm
a number of a number of Routers/
BSCs RNCs switches
Other big Typical BSC Typical RNC Routers,

sites sites in a decent- sites for decent- Ethernet over
(15...60) ralised solution ralised RNCs fiber or SDH
Regional network
(medium capacity backbone,
fiber-based)
Small Sometimes used May be used Routers,
transport sites as a BSC site, as RNC site, Ethernet over
(50...500) typically only TDM more typically fiber
(SDH) connectivity only traffic conc.
(SDH ADMs in (in ATM or TDM
practice) plane)
Hub sites, Typically BTS Typically BTS L3 capable

often two sites (BTS sites (BTS Ethernet
'tier' sites embedded DXC) embedded AXC) Switches
(200...2000) or small or standalone
standalone DXC AXC
Access network BS sites BTS sites BTS sites BTS sites

(often MWR) (1000...8000)
Figure 2. Typical number of various sites in an average-size mobile network
In addition to 2G and 3G mobile traffic, the packet backbone can be used to carry
traffic from high-speed radio networks and other wireline sources. Especially I-
HSPA, WiMAX, WLAN and copper-based digital subscriber line (DSL) systems
are potential sources of traffic. These traffic sources are very important in
network design, as they can create traffic volumes that are considerably higher
than the mobile traffic itself.

It should be noted that the figure above does not include server sites or sites
related to multi-access, which may affect the core network structure. The location
of the RNCs and BSCs is also important. Depending on the available transport
network and sites, the equipment may be centralised on core sites or distributed to
specific controller sites. In the figure, the latter option is assumed.
Operator-specific starting points and strategies
Greenfield operator (no 2G network)
Greenfield operators are often using leased facilities, meaning that their network
is dependent on the existing networks and tariff structures of other operators.
Often greenfield operators want to deploy routers/switches on each site, that is,
use their own equipment for the connectivity and for multiplexing of traffic
flows. Transport capacity can be leased on different layers, depending which
functionality the operator is planning to implement by own equipment. The
alternatives are leasing dark fibers, TDM capacity, ATM connections, MPLS or
IP VPN. Depending on the chosen model, the sites may or may not have
equipment for the lower layers (such as SDH or WDM equipment).
Established mobile operator (existing 2G network)
Established mobile operators develop the transport network using the existing
sites and fibers as a starting point as the physical layer infrastructure is often
creating the highest cost while it is the slowest to change. Generally the same
SDH network is used to fulfil the new transport needs. Where leased facilities are
used, the new transport requirements are met using the existing links, if possible.
If the operator already has an ATM or IP backbone network, it is obviously the
preferred choice for all new traffic.
Established multi-service operator (existing 2G, PSTN and other service

networks)
Multi-service operators provide mobile and other types of services (such as fixed
line telephony and data services, including Internet access). Established multi-
service operators usually have their own high-capacity general-purpose transport
backbone network, which is typically built with SDH equipment on top of dark
fibers, with some DWDM equipment for the highest capacity routes. The
transport cost (per Mbit/s) for an established multi-service operator is typically
lower than for other types of operators. Often the mobile arm of the company is
obliged to use the in-house leased line or packet transport offering.
Technology and networking preferences of the operators
Existing own network

An existing network creates a very strong economic and operational push towards
using that network. This is often possible in case of existing ATM and IP
networks. Changing the structure or technology of an existing network is time-
consuming and very expensive. Naturally, the existing transport network needs to
be checked for capacity, feature and interface compatibility.
Existing competence
Competence within the operator's organisation may create a strong inclination to

prefer a certain technology. The utilisation of the existing competence, design
rules and operational practices speeds up the implementation of the backbone
network and gives clear benefits in running it. Training of the personnel for a new
technology and establishing new operational procedure is costly and takes a lot of
time. Transition periods are often characterised by service availability that is
below average.
Availability and tariffs of leased connections
There is great variation in the availability of leased connections in different

countries. In some areas, only digital leased lines are available. In many cases the
available speed range is narrow (only E1, E3 and STM-1, for example) and the
geographical scope limited. In other countries carriers are offering ATM- and IP-
based connections and virtual networks in addition to TDM.
Price differences between diverse services may be substantial enough to create a

strong push towards a certain type of technology or networking solution.
Operator transport network vision and strategy
Operators have different visions on the future of technologies and the speed at
which they will develop. Therefore, different strategies for network evolution are
employed. The selected backbone transport solution needs to support the
operator's intended network evolution path.
There is a desire to minimise the number of protocol layers used in the network.
Today the practical questions are related to the extent to which IP/MPLS can be
used as an alternative to TDM and ATM in the networks when considering
services, resilience and cost.
Generally IP/MPLS over SDH or Ethernet has become the most attractive option
for building new backbones.
Allocation of network level functionalities
There are different ways of grouping the basic network level functionalities,
partly because of the network implementation and evolution strategies mentioned
above.

The functionalities that typically require a general implementation policy (on the
individual network layers) include:
. Network/connection protection principles
What is the desired speed of protection and the amount of capacity that
may be consumed for it? In which network layer(s) and with which
mechanisms is it implemented? It is recommendable to have fast protection
in one layer only and provide some additional support functionality
(slower) in the other layers.
. Network synchronisation principles and implementation methods
This is typically a layer 1 issue, for which careful planning is needed
(especially when using leased lines or connections).
. Quality of Service (QoS)
QoS is a fundamental issue in packet-based networks.
Network operability involves similar considerations (such as provisioning and

modification of connections, connection and network performance monitoring,
and network maintenance). The role of the various layers and the interaction
between them has to be taken into account.
3.2 Traffic mix

The dimensioning of a packet-based communications network depends on the
types and mixture of traffic the network has to carry.
In the mobile community with improved radio technologies, the increased use of
Internet and intranet services as well as messaging, the amount of non-voice
traffic is growing faster than the traditional voice traffic.
The busy hours for the different services vary. It is likely that people will use
messaging services, entertainment and data access increasingly outside working
hours whereas the behaviour of voice traffic is not likely to change.
Voice traffic is primarily carried over the CS domain still for years. Real-time data
(such as streaming video) is carried over both CS and PS networks. The normal
packet data, picture messaging, and browsing will increase the usage of packet
networks.

The traffic forecasts indicate that the PS traffic will dominate the networks in the
long run. However, it is important to note that in the initial 3G deployment, the
traffic carried through the CS domain will substantially exceed the amount of PS
traffic. Considering that all CS traffic is real-time, proper dimensioning of the
traffic is of key importance.
3.3 Network structure

Deployment considerations
In most cases, the initial mobile network deployments are characterised by:
. consolidated 2G/3G infrastructure

. initially small but growing number of 3G subscribers.
Network sharing between operators is also an important issue in the 3G

deployment. Network sharing is not discussed here in detail, but the Nokia IP
connectivity solution provides the tools required for building shared networks
(such as virtual private networks and various routing options).
For the core network build-out, the mobile network functionality can be
consolidated into a small number of sites. The key reasons are:
. The core network products of today have significantly higher capacity than
the comparable 2G systems.
. In many cases, the split control and user planes allow the optimisation of
both planes separately.
.
A packet-based transport backbone with high-capacity reduces the need to
distribute the network elements geographically. The cost of transport
capacity in the fiber networks has gone down rapidly in recent years.
Considering the above, it is obvious that the new mobile networks require less
core network sites than the traditional networks.
When the transport solution is planned, the fast increase in the number of
subscribers and the amount of traffic per subscriber should be considered. As the
number of transport links in the access and regional networks is high, frequent
capacity upgrades result in significant operational efforts and cost.
Operators with existing GSM or other 2G cellular networks will have to resolve
the integration of the existing access transport and the new capacity required for
carrying 3G traffic. In many cases the deployment of a multi-service network to
the base station sites may be too complex and difficult to justify from cost

perspective because putting E1 on ATM increases the need for capacity

(frequency licenses for the radio link and replacement of the existing equipment,
for example). The potential benefits of a consolidated transport network are easier
to obtain in the backbone environment.
Initial 3G reference network
The initial reference network describes the build-out of a 3G network in a typical

European environment. The network architecture is based on 3GPP Rel-4. The
network rollout is characterised by:
. initially 500 000 subscribers, later several millions

.
fast build-out of coverage because of license requirements
. an existing GSM network and some wireline activities.
A typical scenario for building the backbone network includes:
. initially 2 or 3 major core sites for resilience, later 4 6 for capacity

. initially 5 - 15 controller (RNC) sites, later 20 - 30 (some with MGW).
Additionally a large number of hub sites is needed in the access network. The hub
sites are at the edge of the operators' fiber network and they typically connect
several radio link clusters of the access network (and also leased lines). At these
sites, traffic is concentrated with an ATM cross-connect. As the typical link speed
of the individual radio link stars/rings/chains at the hub is n x E1&E3, the
transport between the hub sites and the controller (RNC) site should preferably be
planned on STM-1 level, although the use of E3 may be justified for some years
for the 3G traffic alone. At first, the links between the hub sites and controller
sites will not be very loaded, but the amount of traffic will increase rapidly.
Note: In some networks, the majority of the radio network controllers is

collocated with the core network equipment. This deployment scenario naturally
simplifies the implementation of the interfaces between the controllers and the
core network equipment. However, grooming of the access network traffic
becomes even more important than when the controllers are distributed.
The logical structure of the initial 3G core network is outlined in the figure below.

IP (FE/GE/POS)
Core Site ATM
TDM
Integrated MSS MGW
HLR
3G
RNC
SGSN
Controller Site
BG Initial deployment
- up to n x 1000 BTS RNC RNC
- 15 RNC sites
FW - 2 core network sites
SDH/
ISN DWDM
Servers
SDH /
RNC RNC ADM
RNC
Hub Site RNC
RNC
RNC Inter-
SDH / RNC RNC connects
ADM RNC RNC
Core site
nx2M
STM-1 RNC
RNC STM-4
STM-16 STM-16
Core site
RNC RNC RNC
RNC
RNC
RNC RNC
STM-4, STM-1,
E3
Figure 3. Initial 3G core network structure
In the initial configuration, the individual RNCs handle Iu-CS/Iu-PS traffic in the
order of magnitude of one STM-1. The connections between the controller site
and core site are planned on STM-1 level. The connections between the controller
site and core site should be protected, as the geographical area served by an RNC
is initially very large. The loss of the connection between the controller site and
core site leads to a severe service outage.

Even in the initial configuration, the core sites handle several Gbit/s of user data.
Most of this traffic is not carried to another core site. Instead, it is carried back
either to the radio network, the PSTN or the 2G network, or to an external data
network. In the initial 3G network with two core sites, it can be assumed that less
than 20% of the traffic is carried between the core sites. This suggests that in
planning the transport between the core sites STM-1 - STM-4 level capacity is
initially sufficient. The physical network may still be built for higher capacity
from the start (STM-16 is typically the minimum capacity used in a long distance
network).
Considering the above, it is safe to assume that 3G deployment does not require
heavy DWDM and STM-64 investments unless there is enough other than 3G
traffic to justify the investment.
The figure above also shows a rough configuration outline of a core site. Most of
the network elements deployed (SGSN, GGSN, MSC Server, HLR, Multimedia
Gateways, Application Servers and so on) are connected to each other using high-
capacity multi-layer LAN switches. In most cases, the switches are duplicated for
enhanced resilience. The LAN switch provides the most cost-effective switching
capacity for the intra-site communications.
The network should be configured so that most of the traffic entering a core site
from the radio network will not traverse through the backbone to the other core
sites. The traffic flows can be controlled, for example, by making the most
frequently used access points available on all core sites and by carefully selecting
the area served by each site (covering a whole city and the surrounding area, for
example). The location of the interconnects also affects the volume of the
backbone traffic.
The figure below shows an exemplary map view of the logical network
architecture. It should be noted that even though it is useful to plan the backbone
network on STM-1/4 levels, the SDH network actually deployed is mainly based
on STM-16 (at least in the long distance network, as noted above).

Core and RNC site

RNC site
Distribution site
n*STM-16
STM-16
STM-1
Figure 4. Map view of the 3G backbone
The amount of local or regional communication should be considered when

calculating the traffic flows in the network. A rough diagram of one controller site
is displayed below. It is assumed that 50% of the connections originating in the
3G RAN served by a controller site are destined to other geographical areas. 25%
of the connections are to the 3G mobiles served by the same controller site and
25% to the local PSTN/2G networks or the local ISPs/corporate networks. The
figure displays the traffic flows for both 3GPP R99 and Rel-4 networks. In the
3GPP Rel-4 network, the local traffic does not have to be carried to the core site
at all if an MGW is present at the controller site.
In the example it is assumed that PSTN/2G interconnect and QoS-enabled ISP

peering is more cost-effective on regional level than on national level.

3GPP R99 Controller Core site

site
International
traffic, national
Radio access interconnects
network
To PSTN
networks, regional
ISPs and corporate
networks
3GPP Rel-4/Rel-5
Radio access
network
To PSTN
networks, regional International
ISPs and corporate traffic, national
networks interconnects
Figure 5. Traffic flows between controller (RNC) site and core site
3G network evolution
After the initial 3G build-out, the network will grow and evolve:
. several million subscribers

.
capacity expansion
. several new types of services.
The backbone network will grow to consist:
. 4 - 6 core sites
. 20 - 30 controller sites.
In the near future, the number of sites will presumably grow very moderately as
the 3G network elements are of high capacity.
ATM-based interfaces will be complemented by IP-based alternatives. In other

words, IP/MPLS will gradually replace ATM in the core networks. The existing
ATM equipment is used for grooming access traffic.

A cost-effective solution may be to connect the backbone routers or switches

between the core sites by using point-to-point fiber connections of 2.5 Gbit/s and
beyond without an underlying SDH network.
Network consolidation of the access and regional network
The presence of 2G or PSTN traffic in the network is not considered in the above
transport discussions. If the operator has a GSM network and a UMTS network
with UTRAN, it is likely that RNCs are deployed at the existing BSC and core
sites. The transport of UMTS and GSM traffic at these sites can be consolidated
on the SDH layer or the ATM layer. As a third alternative some operators already
use IP/MPLS for the transport of all traffic. The protocol options are shown in the
figure below. With the MSC Server (MSS) System, also GSM traffic can be
carried over the backbone using IP or ATM (AAL2).
Other Other Other

UMTS GSM UMTS GSM UMTS GSM
traffic traffic traffic
AAL2/5 AAL2/5 AAL1/5 AToM
ATM E1/STM-1 ATM IP/MPLS
SDH SDH SDH/Ethernet
Figure 6. Options for consolidating 2G and 3G traffic in the regional transport

network (other traffic may be TDM and/or IP)
Consolidating the traffic on the ATM layer requires investments in an ATM

adaptation kit for the existing 2G traffic and other TDM traffic. The benefit is that
all traffic can be managed using one technology only. However, transport
capacity for the 2G environment still needs to be provisioned at 2Mbit/s level as
the 2G equipment deployed is generally not aware of higher order interfaces. The
transport network itself can be designed using a more granular approach (STM-
4). The multiplexing gains achieved with transport network consolidation are
small as 2G traffic is of CBR type. The gains from statistical multiplexing
become significant if there are high volumes of data traffic in the access network
(DSL or BWA subscribers, for example). The impacts of multi-access are
discussed in the section below.
It should be noted that in 3G networks, the RNC performs WCDMA

macrodiversity combining. Because of the tight delay requirements of the
macrodiversity combining, all traffic between base stations and the RNC (also
non-real-time) has to be treated with high priority. Therefore, no QoS
differentiation of 3G traffic is possible in the access network.

Consolidating TDM and ATM traffic on a IP/MPLS network is future-proof as

IP-based versions of the key mobile network interfaces become available within
the next years. It should however be noted that Any Transport over MPLS
(AToM) requires high capacity state of the art router equipment and causes
significant protocol overhead. Operators may also face additional issues, e.g. a
revision of the clock distribution scheme in the network.
Consolidating the traffic on the SDH network does not require investments in
ATM adapters for the installed 2G network. The potential drawback is that
duplication of functionality in both ATM and SDH may result in higher operating
cost unless the design of the layers is coordinated.
High-speed radio and multi-access
Many 3G operators are planning to deploy high-speed radio technologies (such as

HSPA and I-HSPA) or alternative access technologies for providing broadband
services. In many cases, the existing base station sites and the same distribution
network can be used for multi-access.
The key impacts of broadband access to the distribution network include:
.
Significantly increased bandwidth demand as broadband systems produce
n x 10Mbit/s traffic, which requires more backbone capacity.
.
Potential need for local interconnects to service providers (ISP) at regional
level. ATM or router equipment may be needed at the transport hub sites or
controller sites.
. Increased potential for statistical multiplexing gains in the distribution/
access network due to the large volume of non-real time traffic in the
broadband domain. These advantages may be offset by more unpredictable
traffic patterns, as the bandwidth to individual broadband subscribers is
much higher than for mobiles.
Network engineering
The backbone has to provide sufficient capacity to carry 3G traffic efficiently. For
temporary traffic peaks, outages and for prioritising real-time traffic, a robust QoS
scheme needs to be implemented. The backbone QoS scheme has to interwork
with the UMTS traffic classes to achieve the set QoS targets. In the Nokia
solution, interworking is implemented by using the Differentiated Services
(DiffServ) codepoints and mapping them into the backbone QoS scheme at the
edge routers of a site. For ATM, the real-time and non-real-time traffic can be
mapped to different Virtual Channels (VCs).

When GSM or WCDMA traffic is carried over the packet network, an adequate
clock signal has to be available for the base stations. The clock can be either
distributed using the transmission network or, if this is not possible, generated
using a very accurate local clock (based on a GPS receiver, for example) for the
individual base station or a chain of base stations.
As the individual backbone links serve a large amount of user connections and
the control of network elements, a robust protection scheme is vital to meet the
service availability targets. Today, SDH is typically the most straightforward
method to implement protection. When switches are connected to each other
without an underlying SDH, it is possible to implement the protection also by
using the fast restoration features of the router/switch products.


IP connectivity
4 IP connectivity
In the Nokia core network elements, the most commonly used packet interface
types are Fast Ethernet (FE) and Gigabit Ethernet (GE). Ethernet is the most cost-
effective and easiest to use link layer technology for IP networking.
The IP connectivity in mobile networks consists of site connectivity and site

interconnection. The site connectivity solution describes how the mobile network
elements are connected to each other within a physical site. Site interconnection
covers the methods of connecting the sites to each other with backbone networks
or direct links. The scope of the solutions and the technologies required are
outlined in the figure below.
Backbone transport
Nokia
Nokia MSC Nokia Nokia
HLR Server IP/MPLS backbone GGSN SGSN
ADM
TDM(PPP) ADM
Nokia
GGSN
ATM Backbone
Nokia 3G Nokia 3G
RNC SGSN TDM(plain or ATM) RNC SGSN
Core Nokia Core Nokia

MGW MGW
Site Site
LAN + routing LAN + routing
Figure 7. Site connectivity and backbone transport

The Nokia IP connectivity solution is based on site connectivity. There are very
few direct interfaces between the Nokia mobile network elements and the
backbone network. The Nokia products do not rely on any specific backbone
implementation.
As Nokia prefers to build the mobile core networks using IP, the chosen backbone
technology is IP/MPLS. MPLS is used for traffic engineering, Virtual Private
Network (VPN) and IPv6 migration. Some operators (especially those with small
networks) may prefer to use plain IP routing instead. This is fully supported by
the Nokia backbone solution. The existing ATM networks can also be used for
site interconnection.
4.1 IP connectivity in a mobile network

For GPRS and 3G deployment, IP connectivity between the packet core network
elements is required. In the Nokia solution, IP connectivity is implemented using
multilayer Local Area Network (LAN) switches on the core sites and an IP or IP/
MPLS backbone providing connectivity between the sites. IP connectivity is also
needed for the sites that host the new multimedia services (such as MMS and IP
multimedia) and for network operation and maintenance (O&M).
The 3GPP Rel-4 with the MSC Server System makes it possible to implement
Circuit Switched (CS) services using the IP network. This brings along real-time
traffic, strict reliability requirements and a significant increase in IP traffic
volumes. The Nokia IP connectivity solution for the 3GPP Rel-4 and Rel-5
networks is outlined in the figure below.

IP connectivity
Core Site Server Site

MMSC DB servers
Nokia
GGSN
/ISN
GRX MMSC relay WAPGW
Nokia
Core Site
Nokia
MSS IMR
Nokia Nokia
Nokia
GGSN 3G
Nokia SGSN
/ISN SGSN
MGW
Nokia Nokia
CPS HLR
Controller
IP/MPLS connectivity Site
PSTN -QoS
-Security
-Resilience
-IPv4 and IPv6 ISP
networks
Controller Site Controller Site
Nokia BSC
Nokia Corporate
MGW Corporate
Nokia BSC
Nokia
RNC
Figure 8. 3G IP connectivity in a 3GPP Rel-4/Rel-5 network
In addition to the core and server sites, IP connectivity is increasingly needed in

the regional networks, especially at the controller sites hosting BSC, RNC and
potentially also MGW equipment.

In the early 3G network deployment the Iu traffic from the RNC is ATM-based.
RNC connections to the 3G core sites can be arranged using the SDH network.
The Nokia MGW can be used for concentrating the traffic from several ATM-
based interfaces.
Currently the GSM/WCDMA access networks are built using the TDM and ATM
technologies. Low-capacity IP connectivity may be needed for network
management purposes. For more information on access network design, see the
Nokia WCDMA RAN System Information Set.
In the Nokia IP connectivity solution, a layered security concept is applied.

Firewalls are primarily deployed at the network edges and for layered defences
between different parts of the operator network. Traffic separation and access
control are widely used within the network.
4.2 Site connectivity solutions

Nokia gives recommendations on the design principles of the LAN and IP
connectivity for the key service subsystems of the mobile core network. These
cover the mobile-specific and Nokia-specific aspects of IP connectivity. Issues to
be considered are resilience and security, for example. The implementation of
routing, QoS schemes, load balancing and such may include mobile-specific
aspects.
Currently the Nokia site solutions cover:
.
packet core, Border Gateway and Intelligent Content Delivery (ICD)
. CS core
.
Push to Talk over Cellular (PoC)
. IP Multimedia Subsystem (IMS)
.
multimedia messaging (MMS) and browsing
. controller sites.
In addition, as part of the core network site design, Nokia provides application
guides for the implementation of IPSec VPN or tunnelling of frame relay -based
Gb traffic over IP, for example.

IP connectivity
4.3 Site interconnection (backbone)

IP is the main protocol carried in the backbone network. The IP/MPLS backbone
carries the traffic between the core sites and also the traffic to the public Internet
and corporate intranets. MPLS bridges the benefits of IP in terms of flexibility,
and those of ATM in terms of QoS and privacy. IP/MPLS is a multi-service
platform not only for 3G but for all operator services.
The key motivation for deploying an IP/MPLS-based 3G backbone is the desire

to build a fully IP compatible network from the onset. Initially, the IP/MPLS
network covers the 3G core sites. Later, along with the introduction of the 3GPP
Rel-4/Rel-5 architecture, the IP/MPLS network will grow to include the
controller (RNC) sites.
While the routed IP/MPLS networks can handle link and device failures with
routing protocols, the resulting delay is too long for some applications. The
introduction of IP telephony will demand extremely fast protection times. The
recommended solution in the initial 3G deployment is to use SDH protection
schemes. If MPLS switches are connected to each other directly (using DWDM,
for example), MPLS fast reroute can be used as well.
4.4 Inter-operator connections

Currently inter-operator connections are characterised by:
. TDM-based interconnects of the circuit switched core

.
GPRS roaming exchange (GRX) connectivity for packet core roaming
traffic.
While packet-based inter-operator connections in the CS core network are still

rare, MMS, PoC and other IP multimedia traffic appears in the GRX networks.
Although establishing IP connectivity between the different networks is quite

straightforward, the mobile operators will face new issues related to IP addressing
and security.
4.5 Fixed network access

Developments in IP technology have allowed the traditional Public Switched
Telephone Network (PSTN) to evolve from a circuit switched network to a packet
switched (IP) network, with an eventual goal of a converged network. The
evolution of the Digital Subscriber Line Access Multiplexer (DSLAM) into a full

service access node with direct support of native 2 wire telephony connections
from customers, allow a common access network infrastructure for multiple
services. At the same time, advances in DSL access network technology enable
increased end user coverage for broadband services and wider bandwidth
availability. The benets for a fixed network operator are:
.
the opportunity to provide new value added services
. increased average revenue per user
.
a reduction in operational costs.
The new services will complement the existing PSTN services while providing a
growing customer base with exibility and choice. Mobility will become an
accepted step in the evolution path. The xed network, with its superior quality
and bandwidth capability, has a vital part to play in this scenario.
To remain competitive, fixed network operators need to develop a Voice over IP

(VoIP) service offering for consumers and small to medium size businesses, to
ensure that they are able to capitalise on the technological changes and retain
market share.
The Nokia end-to-end system solutions provide fixed network operators with the
ability to evolve their networks and deploy a wide range of revenue enhancing
services and applications.
Nokia D500 Multi-Service Access Node
The Nokia D500 is a multi-service access platform that supports a wide range of
services from the central office to remote environments; from fast Internet access
to the various services such as legacy voice (POTS), Video on Demand (VoD),
digital broadcast and interactive TV.
For more information on Nokia D500, see the product documentation provided in
Nokia Online Services (NOLS).

Core network site solutions
5 Core network site solutions
5.1 Core network site functionality and design

Site functionality
The functionality of a core network site is likely to include:
. Circuit switched (CS) core network elements

.
GPRS and 3G packet switched (PS) core network elements
. IP Multimedia Subsystem (IMS) and Push to Talk over Cellular (PoC)
.
RNCs and BSCs
. Various service platforms (both CS and PS)
. Interconnects to TDM networks (2G, PSTN)
. Interconnects to IP networks (ISPs and roaming partners, for example)
. IP connectivity to the operation and maintenance center
. Additional functionality (related to GSM/PSTN/ISP/BWA, for example)
Many server-based service subsystems are physically located at the core network
site. For more information, see WAP gateway and MMS site solution and
Controller site solution.
The core network site and its LAN/WAN connectivity in an IP/MPLS backbone
environment is outlined in the figure below. The figure includes the key products
used in the Nokia IP connectivity solution, which are described in Products used
in the core network site solution.

Core Site
MSS DNS CPS IMR MGW
HLR -HP server

-BIND SW
multilayer
site
switch
GRX/
Roaming
partners BG
3G RNC
SGSN
ISP peering/
backbone RNC
Internet
router sites
exchange FW
PLMN
SDH/ backbone
GGSN DWDM (IP/MPLS)
Servers Core
sites
Security
-Nokia Firewall routers
-Checkpoint FW Backbone Transport
-Checkpoint VPN -Edge router functionality of site switch
-Cisco 12000 for large networks
FE/GE
Site Connectivity
ATM (STM-1)
-Modular site switch (Cisco 7600)
POS/ATM -Small LAN switches for special applications
Figure 9. Core network site solution
The Nokia core network elements are connected to a high-performance multi-

layer LAN switch/edge router (Cisco 7600 series), which acts as a MPLS
Provider Edge (PE) device. The site switch/routers as well as the backbone
routers are duplicated for redundancy.
In the figure above, site connectivity is implemented using IP/MPLS. In case of

an ATM backbone, ATM line cards are used in the site switch.
At the core site there are initially several ATM-based interfaces:
.
Iu-CS between the RNC and the MGW
. Iu-PS between the RNC and the SGSN
.
Iur between neighbouring RNCs

Both Iu-CS and Iu-PS traffic from an RNC can be carried in one STM-1 to the
MGW, where Iu-CS is terminated and Iu-PS is carried over a second STM-1
interface to the SGSN. Also Iur traffic can be carried on the same STM-1 with Iu-
CS and Iu-PS and switched to another STM-1 towards the second RNC.
Connections via the MGW can be set up using AAL2-signalling (AAL2 nodal
function).
In 3GPP Rel-4 networks, ATM traffic coming to the core site can be greatly
reduced or even completely eliminated by distributing the MGWs to the
controller (RNC) sites and handling Iu-CS locally. The MGW Nb traffic can be
carried over the IP/MPLS backbone. Also Iu-PS traffic can be carried over the IP/
MPLS network. IP-based Iu-PS is part of the 3GPP Rel-4 specifications.
Note
Nokia SGSN supports Iu-PS over IP. While the user plane traffic can be
converted from ATM to IP by terminating the AAL5 protocol at the ATM
interface of any router, a signalling converter is needed for the control plane.
For more information on site connectivity of the CS core network elements, see
Site Connectivity Guidelines available in CS Core system documentation library.
Design principles
Use of VLAN and VPN
The IP traffic in a mobile network consists of several independent domains:
. GTP traffic between the SGSN and GGSN (Gn interface)

.
traffic between the GGSN and external networks/servers (Gi)
. traffic between the MGWs (Nb)
.
network management and signalling traffic
All of these traffic types can be separated. Separating the traffic leads to increased
security and manageability of the network.

The easiest way to separate traffic at the core site is to use virtual LANs
(VLANs). Some of the Nokia elements provide VLAN support so that many
logical interfaces can be carried over a single physical interface. This is
particularly useful for those networks that change over time (such as corporate
access points at the GGSN). For network elements that do not support VLAN,
dedicated cables are used. The traffic coming from these interfaces can be VLA-
tagged in the LAN switch.
The use of VLANs at the core site is outlined in the figure below.

*) can be integrated to CS Core control plane network

*) optional
Nokia Nokia
HLR MSS Nokia 3G 2G
Traffica MGW NEMU SGSN SGSN
CS core user plane
Gn/intra-PLMN network
Gi network
O&M network
CS Core control plane
Radio network Control*
BDCU network*
STU network**
Charging network
GN Gi
Gi
DNS DNS ISN CG
BG FW
CS core user plane
Gn/intra-PLMN network
Gi network
O&M network
CS Core control plane
Radio network Control*
BDCU network*
STU network**
Charging network
Figure 10. Use of VLAN at the core site (basic PS and CS core)

In the figure above, the Operation and Maintenance (O&M) network is carried
using the same site switch and physical links as all the other traffic. This is the
easiest way to build the network. However, some operators may prefer using
separate switches and routers for the network management traffic for security
reasons.
MPLS Virtual Private Networks (VPNs) can be used for carrying the different
types of traffic separated across the IP/MPLS backbone. Different VLANs are
connected to different MPLS VPN in the Provider Edge (PE) device. The
mapping of VLAN to MPLS VPN on the core site is outlined in the figure below.
ip vrf GnNetwork Site security WAN security

rd 1:101
route-target export 1:101 VLAN & Access Lists MPLS VPN
route-target import 1:101
VPN Gateways IPsec VPN
multilayer multilayer
site site
switch switch MSC MSC
GGSN
GGSN GGSN
MSC MSC MSC MSC
interface Ethernet1/1.2
ip vrf forwarding GnNetwork GGSN GGSN
Figure 11. Mapping of site security to WAN security
The mapping of a VLAN to a layer 3 MPLS VPN is very straightforward. A

VLAN interface (Ethernet 1/1.2 in the figure above) is mapped to a VPN routing/
forwarding instance (VRF). That VRF is given a route distinguisher (101 in the
example). The route distinguisher guarantees that VPN addresses are unique even
when overlapping address spaces are used in the different VPNs. Finally the use
of routing information for the given route distinguisher is enabled. As an
alternative to the above solution it is possible to implement the PE functionality
in dedicated routers.

The mapping of VLANs to MPLS VPN keeps the different logical networks
separated also in the Wide Area Network (WAN). This solution may not be
secure enough for some types of traffic requiring additional secure VPNs. This
can be done using VPN gateways at each of the core sites. The VPN gateways
and the use of IPSec is described in more detail in Backbone network security.
In the ATM backbone, ATM Virtual Channels (VCs) can be used instead of
MPLS VPNs. In routed networks, layer 3 VPNs can also be used.
Connectivity to external networks
Core sites are the natural place for connecting roaming partners and service
providers (ISPs). IP connectivity to external networks brings along important
security and resilience considerations.
The connections to roaming partners can be handled directly or using a GPRS

Roaming exchange (GRX) service. In most cases, international roaming is
handled using the GRX. Direct connections between operators may be feasible in
national roaming when traffic volumes between the networks are high.
Because of roaming, public IP addresses have to be used at Gn/Gp as the SGSNs

and GGSNs have to be addressed from the roaming partners' networks. Domain
name server (DNS) queries from the partner networks have to be enabled.
GTP-aware firewall software should be used at Gp for enhanced security. At the

Gn interface, the OSPF routing is used. Border Gateway Protocol (BGP) is
typically used for routing information exchange in the GRX network. The Gn/Gp
network is outlined in the figure below.

IMS, PoC, MMSC

SGSN, GGSN MGW
INC
Messaging/
Messaging / SIP-aware Gn network Gi SIP-aware
Firewalls Firewall Firewalls
SBC SEG
Gp network BG Firewalls Access

network
Internet FW
BG Routers or router
with access
control lists
GRX ISP/
Network Internet
Figure 12. Interfacing external networks (GRX/Internet)
While in early GPRS deployments firewall routers often acted as border

gateways, it is today recommended to build a separate Gp access network with
redundant access to the GRX network (or networks). In addition to enhanced
resilience, this solution also scales better to support the different types of new
traffic carried over GRX networks (for example, MMS and IMS interworking).
Peering with ISPs and connections to the national Internet exchange and
corporate customers are implemented using the same principles as the GRX
connectivity. Distributed access network provides additional flexibility and
resilience when interfacing with the external networks.
Scalability
The current Nokia 3G backbone is implemented using Cisco 12000 GSR

backbone routers and 7600 site switch/router. The configuration on each site
consists of a redundant configuration of two site switches and two backbone
routers.

The traffic handling capacity of the IP connectivity elements used is scalable to

meet the estimated needs of the mobile networks. In the GSR, 375 Mpps IP
forwarding capacity is available. Using the 7600, up to 400 Mpps IP forwarding
capacity is available. The maximum switching capacity of the Cisco 7600 is 720
Gbit/s.
Probably the most scarce resource is the number of LAN interfaces. In practical
7609/6509 configurations, the number of Fast Ethernet (FE) interfaces is 240
336. Smaller LAN switches can be used as access concentrators to increase the
number of interfaces and to simplify the cabling at the core site.
Resilience
As almost all traffic in the 3G network is carried over the multilayer LAN
switches several times, the site solution and the WAN connectivity have to be
extremely resilient. Redundant node and link configurations eliminate single
points of failure. The resilience in the Nokia 3G backbone is outlined in the figure
below.

Several DNS
servers in
different subnets
Nokia Nokia
HLR MSS Nokia 2G CPS IMR
Traffica MGW NEMU SGSN DNS CG
Host-based products
- duplicated LAN (FE/GE) interfaces in key elements
- key elements connected to two site switches
- HSRP or GLBP in the site switch
Firewall/VPN GW resilience
GGSN/ 3G - clustering
ISN SGSN BG Gi FW - VRRP
Site switch resilience

Router-based products - non-stop forwarding
- two IP interfaces - stateful switchover
- dynamic routing (OSPF) - two parallel site switches
- link aggregation
- WAN connectivity in both
switches
Figure 13. Resilience in Nokia 3G backbone, intra-site and inter-site traffic

protected against node and link failures

5.2 GPRS and 3G packet core site solution

The core network site solution for GPRS and 3G packet core covers the
implementation of the Gn and Gi networks, Domain Name Server (DNS) services
and the Border Gateway (BG) as well as Gi firewall. Separate Local Area
Network (LAN) switches and site routers have been used in the early GPRS
deployments. These have since been replaced by the resilient site switch
configuration that acts a LAN switch, site router and edge router.
Gn network
In the Nokia 3G networks, both the GGSN/ISN and the 3G SGSN are
implemented on router platforms. In the recommended site configuration the
SGSN/GGSN applications use loopback interfaces. IP connectivity for each GSN
is available using two interfaces (different VLAN and subnet). The Open Shortest
Path First (OSPF) protocol is used for rerouting in failure cases. The resilience
concept of the router-based elements is shown in the figure below.
DNS
-Dual VLAN used for resilience
-Separate VLANs allow load sharing
-Loopback interface used as GTP tunnel endpoint, allows
routing protocol to reroute in case of (interface) failure
Gn VLAN A
GGSN GGSN site switch site switch
802.1Q
3G
SGSN
Gn VLAN B
GSR GSR
DNS PLMN
Backbone
Figure 14. Gn network for router-based elements

In the Nokia GPRS networks, the SGSN has IP host capabilities (DX 200). The
resilience of the GPRS Gn interfaces is implemented using duplicated Fast
Ethernet (FE) interfaces in the SGSN packet processing units (PAPU). Only one
of the interfaces is active at any time. During the switchover the IP address is
moved from the failed interface to the new active interface. The new active MAC
address is advertised using a gratuitous Address Resolution Protocol (ARP)
message (Unsolicited Neighbour Advertisement with IPv6).
The site switch acts as the default gateway in the recommended configuration.
AHSRP pair is configured between the two site switches for resilience. The
configuration is outlined in the figure below.
DNS -Multilayer site switch is the default gateway

for 2G SGSN, for example
-HSRP between site switches for resilience
-2G SGSN - GGSN traffic routed by OSR
Gn VLAN 1
HSRP
site 802.1Q site
2G 2G
switch switch
SGSN SGSN
Gn VLAN 2
GSR GSR
DNS PLMN
Backbone
Stand-by interface
Active interface
Figure 15. Gn network for host-based elements
Two DNS servers are shown in the figures above. When implementing the
domain name service, alternative servers should be located in different subnets
and physical locations.

Gi network
In early Gi network deployments, site switches are used only for LAN switching.
Static routing from the GGSN/ISN to the Gi firewall is used. In that case, the
resilient Gi firewall configuration consists of two Nokia firewall routers running
Virtual Router Redundancy Protocol (VRRP) pairs for each access point.
In large networks where an access point name and Gi firewalls are available at
several locations, it is advisable to use dynamic routing. In that case, the resilient
firewall configuration consists of two Nokia firewall routers running in parallel.
It is possible to set up multiple VLANs to support several Gi networks at a site.

This is advisable when corporate access point names are established, for example.
The Gi network and the role of the Gi firewall is outlined in the figure below.

GGSN GGSN
multi- multi-
layer layer
site site
switch switch
OSPF 802.1Q
Gi VLANs
MSC MSC
MSC MSC MSC MSC

FW FW
GGSN
VRRP/
OSPF
GGSN GGSN
ISP/
Internet
Gi-Firewall (and Gi-WAP Firewall)

-Protects the GGSN and mobile terminals from Internet
-Multilayer site switch acts as a switch between GGSNs and Gi-FWs
-Inter-switch resilience by using 802.1Q
-FW resilience by using VRRP or OSPF
- VRRP: AP's default route points to Gi-FW VRRP address
- OSPF: AP may use OSPF with Gi-FW
Figure 16. Traditional Gi network and Gi Firewalls
With the Nokia ISN, the principles of the site solution remain the same. The site
connectivity for Flexi-ISN 2.0 is illustrated below.
When the Nokia packet core is enhanced with Intelligent Content Delivery (ICD)
for enhanced traffic handling and charging, a Traffic Analyser (TA) and Content
Analyser (CA) are added to the data path. The resilience of the enhanced Gi
network is outlined in the figure below.

2G 3G DMZ/GRX
SGSN SGSN
DNS
BG / Firewall
Gn1/2
GGSN
FlexiISN
TA
Ga/Ro/ICD Gn1/2
DCN
Gi Firewall
CG OSC NPS
Prepaid SCP
NetAct/ Corporate/
IPN Manager Internet
Business
Support
Systems
Figure 17. Flexi-ISN site connectivity
The enhanced Gi network has to offer connectivity to server sites unless all the
service systems (such as WAP gateway and multimedia messaging service centre)
are collocated with the mobile packet core. The server sites typically need
Internet connectivity. It is possible to set up Demilitarised Zones (DMZ) that are
parallel to the Gi network to provide the connectivity.

5.3 MSC Server System site solution

In the 3GPP Rel-4 Circuit Switched (CS) core network, MSC Server (MSS)
handles call control while the user plane traffic is carried from the radio network
to the packet backbone through Multimedia Gateway (MGW). An outline of the
Nokia MSS and the key protocols used is drawn in the figure below.
IMR HLR
Other IMS MAP

Services
networks
SIP
IP DIAMETER
CPS Cx MAP CAP
Mm
SIP SIP MSS SIP/BICC MSS
3GPP Packet IP IP IP
Core Gm Mj/Mg/ISC Nc
lu-PS SIP H.248 H.248

M3UA M3UA
IP IP IP
Gm IP IP
Mc/Mn Mc
RTP
Broadband UDP AAL2/AAL5/ATM
access network IP RTP/IP Nb SS7
PSTN
RANAP TDM TDM
lu-CS Mb
AAL5/ATM
BSSAP MGW MGW
A NPI
AAL2
TDM IP TDM
ATM
RNC
BSC CDS
Figure 18. MSC Server System
The user plane connectivity can be either IP-, TDM- or ATM-based. IP

connectivity is needed for Mc (H.248) connections, O&M and typically also for
signalling links.
Logically there are several separate networks. Separate Virtual Local Area
Networks (VLANs) are established for the user traffic, Operation and
Maintenance (O&M), traffic, statistics, charging, SMS and traffic analysis.
Separate VLANs are also used for the core network control traffic and radio
network control traffic.

Note
Nokia CS Core documentation includes instructions for configuring IPv6, but

Nokia does not currently support or recommend the use of IPv6 for commercial
CS Core traffic in live networks. Interworking with site IP infrastructure will be
finalised and verified in a later MSS System release.
Note
In Nokia MSC Server System Release 2.0 the integrated IPSec functionality in
MSS network element is restricted to management plane traffic, charging and
OCLM reports. In MGW network element the IPSec is provided in an external
IPSec security gateway.
Integrated IPSec for control plane traffic (NNI signalling such as BICC, H.248,
MAP) will be implemented in a later MSS System release.
Available site connectivity solutions
Nokia has productised a standard site connectivity solution for sites hosting the
MSC Server and MGW. Additionally a cost-optimised MGW site connectivity
solution and an even more cost-efficient site connectivity solution for SIGTRAN
and IP-based control plane traffic is available. The latter also applies to a MSC
environment in addition to the MSC Server System.
In addition to the IP-based site connectivity solutions, it is possible to carry

control plane and signalling traffic between MGWs using ATM over VC-4, VC-3
or n x E1 IMA links. For more information, see Site Connectivity Guidelines in
CS Core System Documentation library.
LAN connectivity of the MSS and MGW
The physical LAN connectivity of the MSS and MGW is shown in the figure
below. Both are connected to the two site switches. For resilience, Hot Standby
Router Protocol (HSRP) pairs are established for each VLAN. The ESA and ESB
units in the figure are LAN switches.

External
IP network
connections
3G
SGSN RNC RNC
ATM
STM-1
Signalling
ESB Signalling
User plane Switch IP NIU
ESB Signalling
matrix
User plane IP NIU
Signalling
Power1 Power
Signalling
NEMU
O&M ESB O&M

ESA
O&M ESB
Signalling ESA
Power Power NEMU

Signalling O&M
Nokia MGW Multilayer Site Switch Nokia MSC Server
Figure 19. MSC Server and MGW LAN connectivity
The MSC Server Site solution is implemented with a duplicated modular site
switch. It is used:
. to interconnect the MSC Servers and MGWs

.
to connect the MSC Server to the operator's IP network
. the modular site switch is a Cisco 7609.

SIGTRAN and control plane site solution
For network environments where user plane traffic is carried over ATM or TDM a
cost-efficient low capacity IP connectivity solution is available. The solution
applies to MSC Server deployments as well as to MSC environments where
SIGTRAN is used.
The SIGTRAN and control plane site connectivity solution consists of two
stackable Cisco Catalyst 3750 switches. For wide area connectivity, a pair of
Cisco 7206 routers is used.
Cost-optimised MGW site solution
In networks where the MGWs are distributed to remote sites not housing any
other core network infrastructure, the standard MSS/MGW site connectivity
solution may be considered as too expensive.
As a cost-optimised alternative Nokia proposes the use of a single-chassis Cisco

7600 site switch configuration as shown in the figure below. The site switch is
equipped with resilient power supply and supervisor units. Duplication of the
interface cards is also strongly recommended. This configuation is not covered in
the NOLS documentation but the recommended configurations can be obtained
from Nokia upon request.

IP/MPLS
backbone
SDH*
User plane Switch IP NIU

*) Alternatively
matrix GE connectivity
User plane IP NIU
for metropolitan
areas or n x E1
NEMU
O&M
ESA
O&M
Signalling ESA
Power Power
Signalling
Nokia MGW Multilayer Site Switch
Figure 20. Cost-optimised MGW site solution
The cost-optimised MGW site solution can be connected to:
.
A central MSS/MGW with the standard site connectivity solution
. An ATM backbone
Chaining of the cost-optimised single-chassis switches is not recommended.

It is recommended to connect the cost-optimised MGW site solution to a central

site with a direct protected SDH link. Currently the use of MPLS PE functionality
in the cost-optimised switch configuration is not recommended as the tested fail-
over times do not meet the Nokia requirements.
MGW chaining
In case of a remote standalone MGW, it is not necessary to build a separate data

network for the control of the remote MGW. The H.248 traffic can be carried
using the same ATM transport (VC4, VC3, E1/T1/J1 IMA grups) as for the user
plane.
The purpose of Inverse Multiplexing for ATM (IMA) is to combine the capacity
of many lower bit rate transmission lines into a group that is seen as a single
virtual link by the ATM layer of a network element.
The IMA provides modular bandwidth for user access to ATM networks and for
connections between ATM network elements at rates between traditional order
multiplex levels, for example between E1 or E3 levels. The IMA involves inverse
multiplexing and de-multiplexing of ATM cells in a cyclical fashion among links
grouped to form a higher bandwidth logical link referred to as an IMA group. The
rate of the IMA group is approximately the sum of the link rates.
SCTP multihoming
The IP connectivity of the MSC Server has some special requirements that affect
the core site design. As the user traffic is almost exclusively voice, the real-time
requirements are very strict. The signalling traffic uses signalling common
transport protocol (SCTP) with multihoming capabilities.
To provide faster link failure recovery, SCTP will switch to the alternative IP
interface with a sub-second failure time. This has to be considered in the IP
connectivity design. The alternative signalling connections should use different
paths across the site to allow the SCTP multi-homing to operate properly. The
preferred operation is outlined in the figure below.

S S
C C.2 A.2 C
T IP network T
D.2 B.2
P P
Primary Path, C.2 - A.2

Secondary Path, D.2 - B.2
Figure 21. Operation of SCTP multihoming
5.4 UMA site solution

MSC Server (MSS) System is extended with Unlicensed Mobile Access (UMA)
-specific elements to connect UMA-capable devices to the Nokia core network.
As UMA requires access from the Internet to the mobile core, special attention
has to be paid to the security arrangements of the UMA access.
Layered defences should be applied. For more information on layered defences,

see the section Core network site functionality and design. All UMA traffic
coming from the Internet is directed to the UMA-specific Security Gateway and
only needs access to the INC and MGW elements.
For resilient connectivity, the IP network controller as well as the duplicated

Security Gateway and Authentication Server configurations are connected to both
site switches.
5.5 IP Multimedia Subsystem site solution

The IP Multimedia Subsystem (IMS) is defined in the 3GPP Rel-5 and Rel-6
standards. The key IMS functionality is implemented in the Nokia Connection
Processing Server (CPS) and Nokia IP Multimedia Register (IMR).
The principles for the IMS site solution are the same as for packet core and circuit
switched core.

It is recommended to use IPv6 in large scale IMS deployments. This requires the
implementation of IPv6 access points in selected GGSNs and IPv6 connectivity
from the GGSNs to the service elements. The connectivity solution presented
below is based on IPv6. However, the network operators of today tend to launch
the IMS using IPv4 connectivity. This will be problematic in the long run because
inter-operator connectivity, NAT traversal and the growing number of IMS users
bring challenges to IP addressing. To resolve these issues, application-specific
session border controllers can be introduced to the network.
IMS services also need user-to-user IP connectivity, which has to be separately

enabled in the Nokia GGSN/ISN. This causes new security concerns. The risk for
denial of service and overbilling attacks as well as spreading of worms and
viruses can be minimised by controlling from which sources traffic is sent to the
mobile terminals. This can be done by using SIP-aware firewalls or session
border controllers.
IP Multimedia Subsystem site solution is outlined in the figure below.

GE optic
IPD
IPD
Nokia IMR
GE optic
IPD
IPD
Nokia CPS
FE/GE
optic/
copper
ESB26 Power Power

ESB26
ESB26
ESB26
Nokia MSS
FE
ESA24
ESA24
Power Power
IPFGE (WO)
IPFGE (SP) 8xFE/GE optic/copper
Nokia MGW Site Switch
Figure 22. Combined IP Multimedia Subsystem and MSS LAN connectivity
On the IMS site, the IPv6 Gi networks can be treated like all the other VLANs.
The IPv6 traffic can be routed in the site switch (Cisco 7609) if it is equipped
with Supervisor 720.

For wide area connectivity, the MPLS Provider Edge (PE) functionality for IPv6
(6PE) can be used. With 6PE, the IPv6 traffic is carried over an IPv4-based
MPLS network essentially as a Virtual Private Network (VPN). IPv6 routing
information is carried in the multiprotocol extensions of the Border Gateway
Protocol (BGP4). With 6PE, IPv6 can be carried over an existing MPLS
backbone without upgrades in the backbone routers.
The Domain Name Server (DNS) services for the IPv6 access point are available
from the same DNS server as for the IPv4 access points. For the CPS, ENUM
service is needed. ENUM allows the use of the DNS for storage and mapping of
E.164 numbers to alias addresses.
5.6 Push to Talk over Cellular site solution

Push to Talk over Cellular (PoC) is an IP-based open standard that allows real-
time one-to-one and one-to-many voice communication service for mobile users.
The Nokia PoC site solution is implemented using a two-chassis switch/router
configuration (cabinet switch) for connecting the Nokia PoC elements to each
other and to the Gi network. The solution is shown in the figure below.

External
network
connections
Push to Talk
Call Processors
Cabinet Switch Push to Talk Register

CPU SWSE
1...n
CPU SWSE
supervisor
supervisor
CPU SWSE
1...n
CPU SWSE
DC- DC-
Power1 Power2
CPU SWSE
1...n
supervisor
supervisor
CPU SWSE
CPU SWSE
1...n DC- DC-

CPU SWSE
Power1 Power2
Figure 23. PoC site solution
The PoC site solution is implemented with a cabinet switch (modular site switch).
It is used:
. to interconnect the four chassis LANs of each Push to Talk call processor
to one cluster LAN (L2)
. to connect Push to Talk call processors and Push to Talk register (located
on the same site) to each other (L3)
. to connect Push to Talk call processors and Push to Talk register to the
operator's IP network.

5.7 Products used in the core network site solution

The packet connectivity equipment required for the site solution are:
. Multimedia Gateway (MGW)

.
Firewalls (FWs) and Border Gateway (BG)
. Domain Name Server (DNS)
.
Cisco site switch
For more information on the Nokia MGW, see the section Multimedia Gateway in
CS Core System Overview available in the CS core system documentation
library.
Border gateway and firewall in the Nokia solution
The border gateway provides the packet core roaming interface towards the
GPRS roaming exchange (GRX) networks and other mobile operators. The exact
architecture of the BG is not defined in the 3GPP specifications; instead, the
operators agree on the architecture in the roaming agreements. In the Nokia
solution, the border gateway is combined with firewall functionality.
Nokia firewall routers running Check Point FireWall-1 are used as Gp firewalls.
GPRS Tunneling Protocol (GTP) -aware firewall software is also available for the
BG solution to supplement the standard firewall functionality.
The GTP-aware FireWall-1 GX software inspects the GTP traffic for GTP anti-
spoofing. It performs intra-tunnel Access Point Name (APN) domain
enforcement as well as MS-to-MS policy enforcement. It also blocks GTP in
GTP. In addition, the software has many GTP logging options.
Nokia firewall routers running the Check Point FireWall-1 are used at the Gi
interface to protect the mobile network from threats from the public Internet.
For more information on Nokia firewall routers and the FireWall-1 GX, see the
section Backbone Network Security.
Nokia Security Gateway
The Nokia Security Gateway provides a secure connection between the network
security domains. It comprises of Nokia IP series router platform running the
Check Point Technologies' VPN-1 and Firewall-1 software. For more information
on Nokia firewall routers, see the section Backbone Network Security.

Nokia Domain Name Server
A Domain Name Server (DNS) is a network service that enables the clients to
name resources or objects and share this information with other objects in the
network. DNS functionality is provided by The Berkeley Internet Name Domain
(BIND) implementation. BIND provides a reference implementation of the DNS
protocols. The current BIND version is 9.2.0.
The Nokia DNS platform is based on a standard HP server running HP-UX 11i.
Cisco 7609 (Catalyst 6509)
At controller sites with MGWs and large amounts of real-time IP traffic, the
Cisco 7609 multilayer LAN switches/edge routers can be used to provide in-site
connectivity and the WAN interface for core routers. Core site devices, such as
the SGSN, 3G SGSN, GGSN, DNS and gateways, are connected using Fast
Ethernet (FE) or Gigabit Ethernet (GE).
The Cisco 7600 devices use the same hardware as the Catalyst 6500 multilayer
LAN switches.
The Cisco 7609 offers aggregate switching capacity up to 720 Gbit/s and multi-
layer switching up to 400 Mpps IPv4 and 200 Mpps IPv6. It supports a wide
range of interface types and densities to include support for up to 384 10/100
Ethernet and 130 Gigabit Ethernet ports.
The Cisco 7609 provides:
. Resilient switched site connectivity (FE/GE) using VLAN where needed

. Resilient routed intra-site connectivity (FE/GE interfaces)
. Resilient routed inter-site connectivity (typically across MPLS backbones)
In the recommended architecture the 7609 performs the MPLS Provider Edge
(PE) functions.
If the site switch is connected directly to the SDH transmission equipment,

single-mode fiber interfaces should be used. Typically SDH products do not
support multimode fiber.
For more information, see the Cisco web pages at http://www.cisco.com.

WAP gateway and MMS site solution
6 WAP gateway and MMS site solution

Site connectivity of server-based systems are discussed below. The detailed
discussion focuses on the solution for the Nokia Multimedia Messaging Service
Centre (MMSC). However, the same principles apply also to streaming and
download servers, general-purpose WAP gateways (GWs) and other service
systems.
The servers used for the end user services delivered over the mobile packet core
can be co-sited with the core network equipment. Here it is assumed that the
servers are on a separate site.
MMS and WAP Gateway
The Multimedia Messaging Service (MMS) site solution provides security, load
balancing and LAN/IP connectivity for the servers. The solution is shown in the
figure below.

Operator Service Operator Core site,

Internet
Network (Gi) GGSN
Terminal
Management
Server
192.168.1.0 /24
active standby
192.168.1.0 /24 192.168.1.0 /24 192.168.1.0 /24 192.168.1.0 /24
MMSC Application WAP

Front End Profiler Gateway Gateway
192.168.1.0 /24
Storage Area Network

MMSC
Figure 24. MMS Site Solution, detailed view
The Nokia MMS Solution is connected to the network operators Gi network. A

set of firewalls separates the Gi network from the public Internet and a second
firewall set is used between the MMS site solution and the Gi network.
The firewall frontier is implemented using a resilient configuration of two

clustered firewalls.

The nodes are synchronised by using dedicated ports and IP subnets, which are
not routed. When only two firewalls are used, the synchronisation can be
implemented using cross-connection cables.
Static routing is used for the site solution. The default route is to the routed Gi
network.
Currently one set of load balancers is used for all front-end servers. In the future it
will be possible to separate or distribute the load balancing services so that
dedicated load balancing units are used for MMSC Relays. The Universal
Inspection Engine of the BIG-IP load balancer can be used to look as deep as it is
needed inside of the message/packet. Synchronisation between the load balancers
is implemented using a dedicated serial cable and LAN connectivity.
Layer 2 connectivity between the units is configured through trunking.
Communication needs for the individual servers are listed below:
. MMSC
A cluster, load balancing, visibility through virtual IP address, load

balancing towards the WAP GW.
.
WAP gateway
A cluster, load balancing for virtual IP address, load balancing towards the
MMSC Relay, connectivity towards the GGSN.
. Application gateway
Initially: load balancing towards the MMSC Relay, connectivity from the
public Internet, connectivity to the SMSC.
. Nokia Profile Server (NPS)
Profile fetch (queries from the MMSC), Self-Administration Interface
(SAIF) connectivity to the NPS Web platform, Operator Administration
Interface (OAIF) connectivity, Customer Care and Billing (CCB).
. Terminal Management
Connectivity to NPS through FTP (at least once a day)
A dedicated WAP gateway is used as part of the MMS solution for connectivity
and security.
The Storage Area Network (SAN) displayed in the figure is not described here. It
should be noted that the SAN will need to handle a considerable amount of data
when the MMS usage grows.

All the application platforms can be logically viewed as separate IP entities for
design purposes (load balancing and relevant security issues).
Products used in the MMS site solution
The products used in the MMS site solution have been selected to allow for
scalability both in functionality and capacity. Additionally, maximum synergy
with the Nokia backbone solution for mobile networks has been considered.
The Firewall frontier consists of two Nokia IP routers. These use Check Point
FW-1 NG Firewall software. The Nokia Firewall/VPN appliance offers an
unbeatable combination: market-leading Check Point firewall/VPN technology
on a purpose-built, hardened Nokia platform with a security specific IPSO
operating system. The firewall functionality is explained in more detail in CS
Core System Overview.
The load balancing solution consists of two BIG-IP 6400 application switches.
The BIG-IP application switch is a flexible and fast IP-centric Internet Traffic
Management (ITM) device capable of securing Internet traffic. The products
provide all-in-one ITM, combining load-balancing, content switching, traffic
management, Secure Socket Layer (SSL) acceleration and management, as well
as Ethernet switching.

Controller site solution
7 Controller site solution

The functionality of a controller site in a bearer-independent CS core network can
include:
. one or several RNCs

. one or several BSCs (in combined 2G/3G operations)
. Multimedia Gateway
. interconnects to TDM networks (2G, PSTN)
. interconnects to IP networks (ISPs)
.
additional functionality related to PSTN/ISP/BWA, for example.
In a 3GPP R99 3G network, the MGW is not present at the controller site and the
connectivity between the RNC and the core site MGW is typically implemented
by using STM-1/ATM links. The connectivity of 3GPP Rel-4 controller sites (or
sites hosting BSCs that are upgraded to IP connectivity) require careful planning.
Here the focus is on these more challenging cases.
The figure below outlines the typical location of the controller sites in the
physical network and the additional protocols that have to be carried from or
across the controller sites. It should be noted that the BSC sites are on lower level
in the network topology than the RNC sites. Often Iub traffic is concentrated at
the BSC sites. Concentration can be done with the Nokia S-AXC ATM cross-
connect, for example.
Many of the protocols listed are initially not IP-based. They are, however, IP-
enabled in the 3GPP Rel-4 and later specifications. Gb and Iu-PS are the first of
this kind.

High capacity
Core
transport
Site
backbone
Controller RANAP: AAL5/ATM

Site
lur: AAL2/ATM
lu-CS: AAL2/ATM
Regional RNC
network lu-PS: AAL5/ATM lu-PS over IP
(medium
capacity
Controller lub: AAL2/ATM
backbone,
fiber based) Site
Gb: Frame Relay Gb over IP
Ater: TDM 16k, signalling
S-AXC
BSC Lb: IP, BSC - BSC: IP
Access network (often MWR)
Transport network architecture
Figure 25. Controller sites and protocols in a combined 2G/3G network
7.1 Controller site options

BSC site
IP connectivity is initially needed at the BSC sites for the following applications:
. Lb interface: location services

.
BSC-BSC interface: SIGTRAN-based link between the Nokia BSCs
. Gb over IP: the frame relay -based Gb can be tunnelled over IP or MPLS
until the native Gb over IP is available
For the Lb, BSC-BSC and Gb over IP interfaces, the Nokia BSC is connected to
the site routers as outlined in the figure below.

The switching units of the Nokia BSC3i are integrated LAN switching units.
Rapid Spanning Tree Protocol (RSTP) is used to break the loop in the LAN.
Multigroup High Speed Routing Protocol (HSRP) can be configured to the site
routers for resilience and load sharing.
As the volume of IP traffic from the BSC sites is initially rather low, the most
cost-effictive alternative for the wide area transport is the utilisation of the 2 Mbit/
s TDM connectivity that is already being used. When the traffic volumes grow or
when traffic is groomed from several BSC sites, 34 Mbit/s or STM-1 connections
may become attractive.
BSC3i
IP/MPLS
Backbone
BCSU 0 BCSU 6 MCMU 0 MCMU 1 OMU
CPU CPU CPU CPU CPU
1 Gbps optical
uplinks (s11.5)
or 100 Mbps
uplinks
MCMU 0 MCMU 1
VRRP/ 2x100
SWU Mbps
SWU
HSRP
2x100
SWU SWU
Mbps
Gb over IP
100 Mbps traffic
L2/Le
switch PCU PCU PCU PCU
BCSU 0 BCSU 0
EMC Interface
Connector panel
Figure 26. BSC 3i Ethernet connectivity
Currently Gb traffic is typically carried over n x 64 kbit/s TDM links or using an

external frame relay network. The alternative is to tunnel the Gb frame relay
traffic over IP or MPLS layer 2 Virtual Private Networks (VPNs). By
consolidating the frame relay traffic to the IP network the links can be groomed
between the BSC Packet Control Units (PCUs) and SGSN Packet Processing
Units (PAPUs). This saves transmission costs.

Gb over IP can be used as an alternative of the frame relay Gb interface. Gb over

IP is carried over Fast Ethernet (FE) interfaces from both BSC and SGSN.
The configuration of the Gb over IP and the tunnelling of frame relay -based Gb
over IP is shown in the figure below. The same site routers can be used for early
Gb over IP and the other IP traffic.
BSC Site
FE links: Lb, BSC-BSC;

Gb over IP
Switch
If NG SDH is
available the
L2/L3 can be
directly
connected to Core Site
the SDH node
router using FE 2G-SGSN
E1/
T1 E1/
T1
Nokia BSC2i
E1/T1 with Gb Ater
SDH
SDH
node
node
E1 link
Fast Ethernet link
Figure 27. IP connectivity between BSC sites and core sites
The BSC site solution is implemented using a site router (or a small site switch
with the BSC2i). The solution is used for:
.
Grooming of FE for BSC2i
. IP connectivity for:

- Lb (SIGTRAN)
- BSC-BSC (SIGTRAN)
- Gb over IP
.
Tunneling of frame relay -based Gb over IP
. The equipment on the BSC site:
- Switch: Cisco Catalyst 3750
- Router: Cisco 7200 series
.
The equipment on the core site:
- Cisco 7609
- FlexWAN in 7609 or separate Cisco 7200 for 2Mbit/s connections
RNC site
In the 3GPP R99 3G network, controller sites only host one or more RNCs and
the MGWs are located at core sites.
The easiest way to connect RNCs to the core network is to use direct STM-1
ATM links between the RNC and the MGW. No additional switching or routing
equipment is needed.
In a 3GPP Rel-4/Rel-5 environment MGW can be placed on the controller sites.
Combined 2G and 3G controller site
In the 3GPP Rel-4 and Rel-5 architecture both RNC and MGW interfaces towards
the core site can be implemented using IP (Iu-CS, Iu-PS, Iur, Nb).
The reasons for placing the MGW at the controller site are:
.
Cost savings in the interconnection tariffs when the peering is implemented
on a regional level.
.
Savings in transmission costs as the local 2G and 3G traffic does not have
to be carried to the core site.
.
Better perceived service quality because of the lower propagation delay of
the voice traffic. This improvement is significant only in large networks.
When there is a significant amount of local traffic at the controller site, the site
connectivity and the edge router functionality can be implemented in the same
way as the core site connectivity using one or two site switches. The connectivity
of such a site is outlined in the figure below.

The wide area connectivity from a large controller site requires n x STM-1 or
even higher connection speeds. These connections can utilise the existing SDH
networks, dedicated fibers or Dense Wavelength Division Multiplexing
(DWDM).
Core Site
BSC
2GSGSN
2GBTS BSC-BSC
IP Controller Site
2GMS 2GBTS Nb, Mc,
Abis Lb, Gb
TDM Ater Iu_ps SMLC
2GBTS TDM
Nokia
BSC3i
TCSM
Nokia A SDH
3GBTS RNC node 3GSGSN
Iub
ATM Nokia
MGW
3GMS 3GBTS
MGW
3GBTS Iur
ATM SS7/TDM
TDM MSS
Iu-cs
RNC ATM
PSTN - Nb is IP or ATM (or TDM)
operator choice
- Iu-PS is initially ATM but
IP connectivity can be moved to IP
ATM connectivity - Mc is IP-based
TDM connectivity - Controller site switch/
router is Cisco 7609
Figure 28. The connectivity of a large 2G/3G controller site
Products used at the controller sites
Cisco 7609 router can be used at the controller sites that have MGWs and large
amounts of real-time IP traffic.

For the BSC sites, the recommended site switch is Cisco Catalyst 3550. The site
router used for wide area connectiviy is Cisco 7200. It provides the latest IP/
MPLS functionality and native support for 2 Mbit/s and channelised 2 Mbit/s
interfaces. In case NG SDH is available and Ethernet can be used for connecting
the site switch to the SDH node, the site router is normally not needed.
For more information, see Products used in the core network site solution or
Cisco web pages (www.cisco.com).


Backbone network implementation
8 Backbone network implementation
8.1 Planning site interconnection (backbone)

IP connectivity of the Nokia network elements does not require any specific
technology for the implementation of the backbone. However, three alternatives
are commonly used in the current mobile environment. These are outlined in the
figure below.
Backbone transport
Core IP/MPLS backbone Core

Site Site
Packet over SDH
ATM Backbone
LAN routing
IP
TDM
Figure 29. The options for site interconnection
In network environments where the number of sites stays small, the most
straightforward way to build a backbone is to connect the site routers directly to
each other using Packet Over SDH (POS) or Gigabit Ethernet (GE) links.
Resilience is achieved with a ring or a mesh structure. In larger networks a routed
or switched backbone is needed.

An existing ATM network can be used for site interconnection. The network
should support real-time traffic and preferably Quality of Service (QoS)
differentiation.
Nokia recommends a high-speed IP/MPLS backbone for large networks without

an existing packet backbone. This network may be built and operated by the
mobile operator. Alternatively, the IP/MPLS connectivity can be bought as a
service from wireline service providers.
For more information, see the network planning overview in CS core system
documentation library.
Backbone services
Site interconnection sets some requirements on the backbone implementation.

These requirements are discussed here in a technology-independent but
somewhat IP-biased way.
The basic requirements for the backbone used are:
.
Support for real-time voice traffic
. Support for multihomed signalling connections
.
Resilience
. Security and Virtual Private Network (VPN) capabilities
. Scalability
There are also additional features that contribute significantly to the cost-
effectiveness of the backbone transport, such as QoS differentiation, traffic
engineering capabilities and the ease of operation.
Support of real-time voice traffic
Real-time Voice Over IP (VoIP) traffic consists of small packets (typically 80

octets) that form rather constant streams. The delay caused by the backbone
network should be kept as small as possible (preferably less than 5 ms) as most of
the delay reserve is consumed by the radio access. Delay variation affects the
delay experienced by the end user and it needs to be compensated for at the
receiving end.
The amount of real-time traffic in the MSC Server (MSS) System suggests the
use of hardware-based packet processing throughout the network.

Table 2. Voice codec bitrates in IP backbone
Codec AMR AMR AMR AMR G.711, G.711,

4.75 4.75 12.2 12.2 20ms 5ms
VAD
60% 100% 60% 100% 100% 100%
Headers
(bytes)
NbUP 4 4 4 4 4 4
RTP 12 12 12 12 12 12
UDP 8 8 8 8 8 8
IP v4 20 20 20 20 20 20
Ethernet 38 38 38 38 38 38
II
Total 82 82 82 82 82 82
(bytes)
Voice
Codec 4750 4750 12200 12200 64000 64000

bitrate
(bps)
Packeti- 20 20 20 20 20 5
sation
interval
(ms)
Payload 12 12 31 31 160 40
size
(bytes)
Total 94 94 113 113 242 122

voice
packet
size
(bytes)

Table 2. Voice codec bitrates in IP backbone (cont.)
Codec AMR AMR AMR AMR G.711, G.711,

4.75 4.75 12.2 12.2 20ms 5ms
VAD
60% 100% 60% 100% 100% 100%
Total 22.56 37.60 27.12 45.20 96.80 195.20

voice
bitrate
(kbps)
VAD
VAD 5 5 5 5 5 5
payload
size
(bytes)
Packeti- 160 160 160 160 160 160

sation
interval
(ms)
Total 87 87 87 87 87 87
VAD
packet
size
(bytes)
Total 1.74 0.00 1.74 0.00 0.00 0.00

VAD
bitrate
(kbps)
Total 24.30 37.60 28.86 45.20 96.80 195.20

bitrate
(kbps)
For IP bandwidth requirement calculation examples for various signallings and

user plane, see CS Core Network Planning in CS Core System Documentation
library.
Support for signalling and control plane connections

Signalling connections are essential for the operation of the telecom network. A
cut in signalling connections affects charging and eventually leads to dropped
calls and lost revenue. H.248 control connections are equally critical, as a MGW
cannot operate without control from the MSC Server.
Signalling connections utilise the Stream Control Transmission Protocol (SCTP).

SCTP resilience is based on multihoming. The end-points have two independent
IP connections to their peers. This is outlined in the figure below.
S S
C C.2 A.2 C
T IP network T
D.2 B.2
P P
Primary Path, C.2 - A.2

Secondary Path, D.2 - B.2
Figure 30. SCTP resilience
Resilience
The target is to have sub-second fail-over times across the network. At the sites
resilience is achieved by using duplicated multilayer LAN switches that also act
as edge routers.
In the wide area network SDH resilience schemes can be used for protection
against link failures. Alternatively, MPLS and ATM provide fail-over
mechanisms of their own.
The edge router connected to the MPLS or ATM backbone is the most critical
component for the resilience of the IP connectivity. A failure of the edge router
has to be communicated across the network so that packets are not sent to the
malfunctional node. Because this causes delay, the resilience of the edge router
should be assured.
For SCTP-multihomed connections, it should be possible to either arrange

independent paths across the backbone or to make sure that failover times are in
sub-second range. In an IP/MPLS environment both methods are available using
MPLS traffic engineering.
Security and VPN capabilities

There are many different logical networks within the operator backbone, such as
Gn, Gi services, Gi corporate, charging and O&M. For enhanced security and
because of potential address overlaps, it should be possible to carry the different
networks in VPNs across the backbone. The default solution is to use MPLS L3
VPNs, but also Layer 2 Tunneling Protocol (L2TP), Generic Routing
Encapsulation (GRE) or Internet Protocol Security (IPSec) can be used for many
of the special applications. These layer 3 tunneling mechanisms may be sufficient
for small networks, but they cannot be easily expanded to large networks.
Network dimensioning
Voice traffic requires special attention in the dimensioning of the backbone

network. Voice traffic tolerates only a small delay and delay variation,
particularly because most of the delay reserve is consumed by the radio access. A
voice connection consists of a rather constant stream of very small packets. The
figure below illustrates the large relative portion of the overhead. Also the link
layer protocol has to be accounted for when calculating the required bandwidth.
Voice sample 40 bytes
RTP 12 bytes
UDP 8 bytes
IP 20 bytes
AAL5
ATM PPP
26 bytes 4 bytes Ethernet
26 bytes
SDH/PDH
Figure 31. Voice packet structure
The small size and large number of the voice packets leads to a traffic profile that
is different from traditional IP networks. The packet processing capacity of the
networking equipment has to be dimensioned for the small packet size.

The resilience of the backbone should also be considered in dimensioning. As

voice traffic is generally carried using the highest priority group (EF PHB), links
should not be loaded with more than 50% of the voice traffic, as the failure of one
link would lead to an overload situation on the remaining link. The UDP-based
vice traffic cannot be scaled down in such an overload situation. Instead, all voice
connections will suffer and traffic with lower priority will be starved to the extent
allowed by the scheduler in the routers.
An example of IP layer voice traffic dimensioning is presented below.
Packet frequencies and sizes:
.
20 ms packetisation interval (AMR and GSM): 40 bytes payload
. 5 ms packetisation interval (G.711): 40 bytes payload
. RTP, IP and UDP overheads: 40 bytes
. Total message size: 80 bytes
Voice calls, 6000 simultaneous connections:
.
AMR codec: 6000 x 50 pps = 300 kpps => 192 Mbit/s
. G.711 codec: 6000 x 200 pps = 1.2 Mpps => 768 Mbit/s
The example does not contain link layer overheads. They have to be calculated
separately for PPP, ATM, Ethernet or any other protocol used.
Scalability
The backbone solution should be scalable with the network. For example, a
switchover from ATM to IP/MPLS may become very complex when there are
millions of active users in the network.
The same applies to backbone products themselves. Modular products that can
handle real-time traffic should be deployed already now. The backbone should
already be operational when the MSC Servers or 3GPP Rel-6 IMS systems are
taken into use.

8.2 IP/MPLS backbone

IP/MPLS is the recommended backbone technology. It is fully IP-compatible and
less costly to deploy than ATM. In the Nokia solution, the Multi-Protocol Label
Switching (MPLS) Provider Edge (PE) functionality is implemented in the Cisco
7609 router at the core sites. Nokia recommends a resilient PE configuration. The
core routers (Cisco 12000 Series) are acting as MPLS Provider (P) devices as
outlined in the figure below.
Core Site Core Site

P
PE P P PE
IP/MPLS backbone
PE P P PE
P
Figure 32. MPLS provider and provider edge functionality in the network
MPLS traffic engineering capabilities are used to provide carrier-class availability

and management. MPLS traffic engineering utilising constrain-based routing
enables the provisioning of reserved bandwidth between the sites, with the
benefits of a connectionless network.
An alternative to SDH protection is the MPLS Fast Reroute, which provides fast
(50 ms) traffic restoration in the core, protecting time-sensitive applications. The
MPLS Fast Reroute allows to build IP/MPLS backbones with high availability
without an underlaying SDH network. The differences between MPLS Fast
Reroute and SDH protection are outlined in the figure below.

SDH protection MPLS FRR
Multilayer site switch

GSR
SDH/ADM
Figure 33. SDH protection and MPLS Fast Reroute
Today, SDH is used for fast restoration (Multiplex Section Protection, MSP;
Mobile Station Special Routing, MS-SPRing). Its drawbacks include:
. the need for extra Add-Drop Multiplexers (ADMs) in the packet networks
.
inefficient capacity utilisation.
Benefits of SDH are:
.
easy multiservice support
. default clock distribution mechanism.
MPLS Fast Reroute functionality:
. eliminates the need for additional SDH equipment

. allows less than 50 ms restoration time
.
provides flexibility on what traffic to protect.
Separation of customer traffic at the IP layer using MPLS Virtual Private Network
(VPN) provides the same level of security as a layer 2 network, without resorting
to a costly overlay model. MPLS is the optimal platform for VPN
implementations allowing simple point-to-multipoint provisioning. ATM
overhead is about 10-20%, while MPLS overhead is only about 1-2%.

MPLS 6PE is the recommended way for carrying IPv6 traffic over an existing
MPLS network. With 6PE the IPv6 traffic is carried over an IPv4-based MPLS
network essentially like a VPN. IPv6 routing information is carried in the multi-
protocol extensions of Border Gateway Protocol version 4 (BGP4). 6PE allows
the IPv6to be carried over an existing MPLS backbone without upgrading the
backbone routers to IPv6.
MPLS-enabled IP VPNs are used for both the operators internal purposes (e.g.
network management) and as a sellable service. MPLS-enabled IP VPN networks
are easier to integrate with IP-based customer networks when compared to
traditional ATM or frame relay -based VPN. Subscribers can seamlessly
interconnect with a provider service without changing their intranet applications,
because these networks have application awareness, privacy, QoS, and any-to-
any networking built in.
8.3 ATM backbone

The general architecture of the 3G network with an ATM backbone is shown in
the figure below. The ATM multi-service network covers the 3G core sites and
the controller sites and some of the transport hub sites (not shown in the figure).
At the controller sites, the type of the ATM equipment required depends on the
access network structure. If the access network is built using direct leased lines
from the base stations to the controllers, a large number of low-speed interfaces
have to be groomed at the controller site. If grooming is done in the access
network, a small number of high-speed interfaces is used.
On the transport hub sites and the BTS sites, the ATM cross-connect functionality
can be deployed. In practice, the ATM network is often built in parallel with the
existing 2G transport solution utilising the same SDH network.

Server Site
MMSC DB servers ATM(STM-1)
FE/GE
GRX MMSC relay WAPGW

Core Site
GGSN site switch Core Site

Nokia
site switch
ISN
ATM network
Nokia -QoS
MGW -Security
-Resilience GGSN Nokia Nokia
-IPv4 and IPv6 Nokia 3G 2G
Nokia Nokia Nokia Nokia ISN SGSN SGSN
MSS CPS HLR IMR
Controller
PSTN Site
BSC Controller ISP
Site networks
Nokia BSC
Nokia Corporate
MGW Corporate
Nokia
RNC SDH
Controller Site
Figure 34. 3G R99 deployment using ATM backbone

The evolution to a 3GPP Rel-4/Rel-5 network does not change the scope or
structure of the ATM backbone. MGWs can be added to the controller and core
sites and connected to the backbone the same way as RNCs. Both the MGW and
RNC are built on the Nokia IPA2800 platform.
8.4 Transmission layer

The layer 1 network is often a multi-service network because it carries traffic
from multiple sources (such as the mobile network, the existing PSTN network
and possibly several data networks). Therefore its capacity is dimensioned
accordingly it is often much higher than the mobile network needs would
suggest.
In recent years, SDH has been developed to suit the datacom environment better.
Virtual concatenation allows the mapping of the data interfaces to the SDH
payload in fragments. In addition to the more efficient mapping schemes, the
Next Generation SDH equipment supports Ethernet and ATM interfaces. They
also implement the Link Capacity Adjustment Scheme (LCAS, ITU-T G.7042),
which allows the change of virtually concatenated capacity in the increments of
its fragments.
When Next Generation SDH is available, it is advisable to use the possibility to

connect site switches using Ethernet interfaces to the SDH nodes. These are much
more cost-effictive than the traditional wide area network interfaces.

Quality of Service in the packet backbone
9 Quality of Service in the packet

backbone
For efficient network utilisation the mobile operator should apply Quality of
Service (QoS) differentiation in the packet network. Voice packets should not
experience queuing delay and delayed voice packets should be dropped as they
are of no use for the application. On the other hand, data packets can be delayed
but should not be dropped, as the application will eventually need to ask for a
retransmission of the lost data.
Meeting the requirements of all services with uniform best effort service and
heavy overprovisioning may be possible in small networks. However, rapid
traffic increase or certain exceptional situations (such as loss of transmission or
routing capacity because of a failure) may cause the best effort network to fail, as
even the mission-critical applications experience extensive loss and delay. In
QoS-enabled networks, prioritised packets survive while the less important traffic
is dropped.
Quality of service is an end-to-end issue in the mobile environment. For data

services, the round-trip delay and the protocol stack determine the perceived QoS.
For Voice over IP (VoIP), the mouth-to-ear delay and total packet loss are the
factors that determine the acceptability of the service. The problem space of
providing end-to-end QoS is outlined in the figure below.

Different QoS schemes (UMTS, DiffServ, MPLS GB...)
End-to-end Operator 1 Gate-

QoS QoS way
budget budget
MPLS
RAN
delay
jitter
+
loss
Operator 2 SLA between
QoS ATM operators
= budget
+
Gate-
Operator 3 way
QoS
IP
budget RAN
Figure 35. QoS is an end-to-end issue
In the figure there are three operators involved in the connection (an UMTS
operator in Europe and another in Asia with a global carrier between them). Each
of the operators may have networks utilising different technology and a
technology-dependent QoS scheme.
UMTS operators themselves have two QoS schemes in use, as the mechanisms
specified by the 3GPP only apply from the user equipment to the GGSN. The
Nokia 3G implementation supports QoS interworking with all major packet-
based backbone technologies.
The mapping of the applications and traffic classes to DiffServ Per-Hop

Behaviours is outlined in the tables below.

Quality of Service in the packet backbone
Table 3. DiffServ mapping for circuit switched core traffic types
Traffic type Per-hop behaviour
Voice (conversational user plane Expedited Forwarding
3GPP control protocols Assured Forwarding class 4, Low Drop

Precedence
Urgent operation and maintenance traffic Assured Forwarding class 4, Low Drop
Precedence
Non-urgent O&M traffic Assured Forwarding class 1, Low Drop

Precedence
The present mapping for the 3G traffic types is shown below.
Table 4. Mapping between packet core QoS attributes and DiffServ
Traffic class Per-hop behaviour (PHB)
Conversational Expedited Forwarding
Streaming Assured Forwarding class 4, Low Drop

Precedence
Interactive, Traffic Handling Priority 1 Assured Forwarding class 3, Low Drop

Precedence

Precedence

Precedence
Background Best Effort
For more information on Quality of Service mechanisms, see IP QoS mechanisms

and ATM QoS mechanisms.
For more information on Quality of Service in the circuit switched core network,
see QoS in CS core network in the CS core system documentation library.


Backbone network security
10 Backbone network security

Security is a fundamental issue for any commercial network operator. In the
mobile environment the security requirements are set not only by the operator but
also authorities, inter-operator agreements and end users, who set their own
standards for different parts of the operator network. This is outlined in the figure
below.
Charging network
GRX networks
Signalling network
Intra-PLMN backbone - GPRS/3G roaming
- IP-based interconnects
- Global reach
O&M network - Reasonable security
- NE - OSS secure connections

- Resilience Inter-operator
- Ease of provisioning
- Covers all NE sites
- Security requirements:
traditionally physical separation Encryption likely
Operator
Legal Interception
Corporate VPN
- GSM 02.33 & 03.33, TS 33.107...
- Mobile terminals access corporate
- Regulative requirement
network
- Authorities to get access to
- End-to-end operator-to-corporate
selected NEs
- Security requirements variable
- Security requirements high
End-user services Regulatory
Figure 36. Framework for network security

The basic security mechanisms for the IP connectivity include traffic separation,
encryption and layered firewall defences. Transport network security can be
arranged on the physical layer with simple traffic separation. Also link layer
(MPLS, ATM, VLAN) or IP layer Virtual Private Network (VPN) technologies
are used. On the core sites Ethernet Virtual Local Area Networks (VLANs) are
used to separate Gn, Gi and other traffic streams. For more information on traffic
separation using VLAN and MPLS VPN, see the guidelines for planning site
connectivity provided in CS core system documentation.
10.1 Security in wide area network

MPLS VPNs have a high degree of privacy. MPLS VPNs label each packet with
destination information; they can achieve the same level of privacy as ATM or
frame relay networks. Various mechanisms are used to provide security:
. In MPLS VPN services, routing information is kept private for separate

VPNs.
. Spoofing attacks (an attacker attempts to access a network using a trusted
IP address) are virtually impossible because the provider's edge router
applies MPLS labels.
. Denial-of-service attacks can be limited using QoS mechanisms.
The backbone Domain Name System (DNS) servers do not accept database
updates from anywhere else than the NMS (NetAct/NameSurfer). Zone transfers
are sent from the NMS using the Dynamic DNS (DDNS) protocol.
The backbone is isolated from the outside networks with firewalls. The
particularly sensitive parts of the network, like network management and billing
systems, are further isolated from the backbone. Inside the NMS network, IPSec,
SSL/TLS or SSH are used for maximum security.
It is also possible to use IPSec AH in all packets in the backbone. This will stop
all attacks that use GTP tunneling because the outside sender cannot generate a
proper AH for the backbone. AH is easier to calculate than ESP and thus has less
impact on the performance of the network.
Security Gateway
The Nokia Security Gateway (SEG) is a network element that provides a secure
connection between network security domains that are managed by a single
administrative authority.

The border between the security domains is protected by security gateways. In the
3GPP security model, all secure communication between the security domains
takes place through SEGs. The Nokia SEG is fully compliant with the 3GPP
Network Security Domain specification (3GPP TS 33.210).
The Nokia Security Gateway comprises of Nokia IP series router platform

running Check Point VPN-1 and Firewall-1 software.
Interworking at Border Gateway
Trust management with other operators is an important issue. IPSec AH is a

simple solution for the packets that are exchanged with other operators requiring
only mutual prior agreement.
The Border Gateway (BG) is a network element where IP spoofing can be

detected, because the other party is known. The BG can also drop packets that are
sent to nodes that do not have inbound traffic (like the DNS servers).
Interworking at the Gi interface
The Intranet connection is more complex than the BG because there are many
existing networks to which the Gi interface must adapt. Often network address
translation (NAT) is required. In many cases only mobile-originated connections
are allowed. Also, application layer gateways are increasingly required to secure
the operator service infrastructure.
10.2 Firewalls
Firewalls provide the most effective means for controlling the flow of IP traffic
between two networks or servers. The principle of firewall operation is that all
traffic across an interface is examined in the firewall. It is allowed to pass only if
the explicitly defined security policy for that interface permits. The firewall can
apply different security rules for inbound and outbound traffic.
Firewalls are generally used at the boundaries of a network. They can also be
used to implement network islands and security domains within a wider network.
This is the case in the server site solution, for example. The network islands do
not have to be in one place as they can be interconnected securely using VPN
tunnels encrypted with IPSec.
In addition to the basic firewall functionality, Nokia Firewall products can be

configured to follow the state of the connections. The forwarding decisions for
the IP packets can be made dynamically based on the current state of each
connection.

The Nokia Firewall includes a spoofing filter against forged IP addresses. This is
a useful feature since many attacks use IP spoofing to hide the true identity of the
attacker. A spoofing filter will stop such attacks before they reach their target.
Implementation is simple when the underlying network topology is known. For
example, an inbound message outside a security island cannot have a sending
address that is inside the island.
Nokia's firewall products also provide auditing and authentication services. A

real-time log can be used for monitoring and accounting information for all
connections. Standard authentication servers, such as RADIUS, are supported.
Authentication can be done on the basis of the user, name and password through a
HTTP interface. Nokia's firewall products offer excellent security features
combined with easy-to-use interfaces and management tools. They help to
prevent the security problems that arise when a security method is too difficult to
use, tempting the personnel and end users to bypass it.
GTP firewalls
Nokia recommends the use of GTP-aware firewall software at the Gp interface.

Check Point FireWall-1 GX combines stateful inspection technology with full
GTP-awareness. It inspects all GTP tunnel fields in the context of both the packet
and the tunnel. This enables granular security policies that deliver the highest
level of security for the wireless infrastructures. FireWall-1 GX is used as a
border gateway in the Nokia solution, as illustrated in the figure below.
Internet
FW-1/VPN-1
Gi
GGSN/ISN
Backbone
BG
SGSN
Gp
GPRS Network FW-1 GX GPRS Roaming
Exchange
Figure 37. The GX firewall functionality added to the border gateway

IPv6 firewalls
For the IP Multimedia Subsystem (IMS), IPv6 firewall capabilities are required.
IPv6 firewall protection is needed for the following applications:
. Protection of mobile users from other mobile users as peer-to-peer traffic

has to be generally allowed. In a later phase, protection of the mobiles from
the public Internet is also needed. The initial functionality can consist of
filtering of unwanted services.
.
Protection of the IMS elements from the mobile users. Generally only SIP
signalling should be allowed.
.
Protection of the IMS elements at the interconnects to other networks.
Currently the Check Point Fire Wall-1 AI supports dual IP stack IPv4 and IPv6
firewall functionality with IPv6 and IPv4 policy-based access control. IPv6
extension headers and IPv6 in IPv4 tunnels are also supported. Additionally a
number of services (such as HTTP, SMTP, Telnet) are available.
10.3 IPSec infrastructure

IPSec protocols
Internet protocol security (IPSec) provides security for the transmission of

sensitive information over unsecure networks.
IPSec operates in one of two modes:
. Transport mode places the IPSec header after the original outer IP header
and before the upper layer protocol.
. Tunnel mode encapsulates the entire IP header and datagram with an
Authentication Header (AH) or Encapsulating Security Payload (ESP)
header and an additional IP header.
AH protects a packet against modification during transit. AH functions in the

transport mode by inserting an AH header into the datagram after the IP header
which increases the packet size. In the tunnel mode an AH header is placed in
front of the entire original datagram and another IP header on the outside is
added.
ESP is the encryption part of IPSec. In the transport mode ESP encrypts only the
payload leaving the header unmodified. In the tunnel mode the whole packet is
encrypted and encapsulated in another IP packet.

PKI
Public Key Infrastructure (PKI) is a framework that uses asymmetric encryption

(public-key cryptography) and digital certificates to achieve secure services
across insecure networks.
PKI systems provide a scalable and policy-based method to provide

authentication and non-repudiation. Large-scale secure VPNs need centralised
PKI systems to maintain all authentication keys. PKI infrastructures have become
the cornerstone of practically all e-commerce and enterprise security designs.
Nokia's view is that these infrastructures provide a cornerstone for the security
solutions of all IP-based 3rd generation mobile networks.
Nokia VPN Gateway
The Nokia VPN Gateway (GW) is based on the Nokia IP series HW platform
running the IPSO operating system. As encryption is a resource-intensive
function, it is recommended that a separate hardware accelerator card is used to
enhance capacity. This is what the IPSO platform does. The actual VPN
functionality is provided by Check Point's VPN-1/FireWall-1 software. VPN
software is available for all IP series platforms.
10.4 IPSec VPN

IPSec VPNs for inter-site connectivity
In the operator's backbone network, some applications may require enhanced

security in addition to the basic traffic separation provided by the backbone itself
(MPLS VPNs or other layer 2 technologies). For example signalling and charging
may require encryption because of local regulations or the security policy of the
operator.
In the Nokia solution, IPSec can be used between the network elements if needed.
In many cases the most straightforward way to provide IPSec to the installed
systems is an inter-site IPSec VPN implemented with dedicated VPN gateways.
An inter-site VPN and the SIGTRAN-based signalling between two MSCs on

different core sites is outlined in the figure below.

3G
MGW SGSN
PLMN
Backbone
1 2 3 4
MSS GGSN/ MSS

ISN
Core Site C
GGSN/ MSS IP Sec

GGSN/ SGSN
ISN tunnel
ISN
Core Site A Core Site B
Figure 38. Inter-site IPSec VPN, MSC signalling use case
The steps in the figure are as follows:
1. The MSC sends signalling traffic (intra-site and inter-site on the same
interface).
2. Routing is based on OSR access list trigger policy (source/destination
address, the port number used). The packet is routed to the VPN gateway
(GW).
3. Security association is selected on the basis of the destination address
(IPSec tunnel mode used). The packet is encrypted and routed to the VPN
GW across the wide area network. Note that the traffic between the MSC
and VPN GW and VPN GW towards WAN are in different VLANs.
4. The packet is decrypted and routed to the destination address.
The resilience of the inter-site VPN can be enhanced using clustered VPN nodes.
If clustering is not available, two synchronised VPN gateways running VRRP on
the interfaces to the site switches can be set up on each site. (VRRP is also needed
on the VLAN that carries the encrypted traffic.)

IPSec VPN connectivity to corporate networks
One of the key services of the GPRS and 3G packet switched networks is to
connect mobile users to corporate networks. Corporate connectivity can be
implemented by an end-to-end VPN service or an access service where only the
section between the mobile operator core site and the corporate network is a
secure VPN. These two options are shown in the figure below.
VPN with terminal client (end-to-end)

-IPSec VPN between mobile device (or PC) and corporate site
-Service can be used over all access networks (mobile, DSL, WLAN...)
VPN VPN GW
Services
Client
Corporate
GGSN/ISN VPN GW
Services ISP Network

Corporate
Services
VPN GW
VPN without ternimal client (Gi VPN)

-IPSec VPN between mobile operator and corporate
-In the mobile network basic GSM/3G Security
-Service has look and feel of dial-up-access
Figure 39. End-to-end corporate VPN
For the end-to-end VPN a client software is needed in the end-user device. In
addition, a VPN gateway is installed at the corporate site. This does not require
significant involvement of the mobile operator. In theory the mobile network is
only a bit-pipe between the VPN client and the corporate network. It may be used
in parallel with other bit-pipes (such as DSL). In practice the corporate network
has to be tuned for enabling a meaningful service set.
A wide variety of end user devices (such as laptops with different operating
systems, smart phones, PDAs) creates a challenge for the IPSec end-to-end VPN
implementation. Therefore, the solution described here suits those large
companies best that have uniform terminal infrastructure and strong in-house IT
competence.

It should be noted that currently IPSec is used for the end-to-end VPN. The
emerging Transport Layer Security (TSL) VPN solutions make end-to-end VPNs
available for terminals with standard web browsers.
When an end-to-end VPN is not available but secure connectivity from the
mobile terminals to the corporate intranet is needed, VPN gateways are used at
the mobile operator and the corporate site. In a typical use case the operator
provisions corporate access points at the GGSN. For security reasons and also to
enable overlapping IP addresses in the different VPNs, the corporate traffic is
tunnelled from the GGSN to the VPN gateway (using VLAN or L2TP). The
actual IPSec VPN is established between the VPN Gateway and the corporate
network. This service model does not require special clients in the end user
equipment. The service closely resembles dial-up connectivity.


Summary of IP connectivity for core networks
11 Summary of IP connectivity for core

networks
The Nokia IP connectivity solution allows smooth evolution from the TDM-
based 2G networks to packet-based 3GPP R99, Rel-4 and Rel-5 network
architectures. It covers the reference network design and evolution aspects. The
focus is on site connectivity solutions. Core network sites, server sites and
controller sites all need IP connectivity now or in the near future. The site
connectivity is implemented using the best-of-breed multilayer LAN switches,
load balancers and firewalls. Resilience, security and scalability as well as QoS
are part of the site connectivity design.
Nokia proposes the implementation of an integrated IP/MPLS network serving

both the circuit switched (CS) and packet switched (PS) core of the GSM/3G
network. In the Nokia solution, the IP connectivity extends to the controller
(BNC/RNC) sites. Transport in the radio access is still TDM/ATM.
The key elements in the Nokia IP connectivity and security solution are Cisco
7609 multilayer LAN switches which also act as edge routers on the core sites
and Cisco 12000 series routers for the IP/MPLS backbone. Nokia IP series
firewall routers with Check Point software is used for securing the network.
PS core, CS core and IP Multimedia Subsystem (IMS) are connected to the

common IP/MPLS network. At each core site, connectivity between the mobile
network elements is provided using multilayer LAN switches. Nokia uses the
Cisco 7609 for three purposes:
. LAN connectivity between the mobile network elements

.
Routing between the mobile network elements (including access lists,
policy-based routing and so on)
.
WAN interfaces (with MPLS PE functionality in the IP/MPLS backbone).
For enhanced resilience Nokia recommends to use two Cisco 7609s per site.

A major additional benefit of the site connectivity focus is that the Nokia mobile
network elements do not mandate the use of any specific backbone technology
for site interconnection. While IP/MPLS is the recommended site interconnection
technology, ATM networks and direct links between the site routers are equally
supported. This allows a cost-effictive migration to packet-based networks for
any type of mobile operator.

Related Topics
Related Topics

Reference network for packet backbone solution
Core network site functionality and design
IP connectivity
GPRS and 3G packet core site solution
Circuit switched core site solution
Push to Talk over Cellular site solution
IP Multimedia Subsystem site solution
UMA site solution
Products used in the core network site solution
Site interconnection (backbone)
IP/MPLS backbone
ATM backbone
Transmission layer
Quality of Service in packet backbone


IP Connectivity in Core Networks

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IP Connectivity in Core Networks

Uploaded by

Copyright:

Available Formats

IP Connectivity in Core Networks

dn0550898 # Nokia Corporation 1 (101)

2 (101) # Nokia Corporation dn0550898

1 Changes in IP Connectivity in Core Networks 5

2 Backbone connectivity solution 7

3 Reference network for the packet backbone solution 11

5 Core network site solutions 33

6 WAP gateway and MMS site solution 61

7 Controller site solution 65

8 Backbone network implementation 73

9 Quality of Service in the packet backbone 85

10 Backbone network security 89

11 Summary of IP connectivity for core networks 99

dn0550898 # Nokia Corporation 3 (101)

Related Topics 101

4 (101) # Nokia Corporation dn0550898

1 Changes in IP Connectivity in Core

Table 1. Changes in IP Connectivity in Core Networks

For connecting Unlicensed Mobile Access (UMA) - UMA site solution

dn0550898 # Nokia Corporation 5 (101)

Table 1. Changes in IP Connectivity in Core Networks (cont.)

Next Generation SDH has been added. Transmission layer

6 (101) # Nokia Corporation dn0550898

2 Backbone connectivity solution

dn0550898 # Nokia Corporation 7 (101)

Core Site Server Site Core Site

Controller Site Controller Site

Figure 1. The application area of the backbone solution in a mobile network

8 (101) # Nokia Corporation dn0550898

IP connectivity in mobile networks consists of site connectivity and site

For more information on LAN and IP connectivity of the CS core network

Network operation and management

As part of a mobile system, Nokia also provides a network management solution

CiscoWorks provides a standalone network management platform for Cisco LAN

dn0550898 # Nokia Corporation 9 (101)

Domain name server

In an IP network, a Domain Name Server (DNS) is required for translating Fully

10 (101) # Nokia Corporation dn0550898

3 Reference network for the packet

3.1 Network evolution

. the overall end-to-end Quality of Service (QoS)

dn0550898 # Nokia Corporation 11 (101)

The 3G backbone transport network usually utilises an existing network. A new

A typical hierarchical structure of a transport network including the approximate

12 (101) # Nokia Corporation dn0550898

Transport Corresponding mobile network sites

Other big Typical BSC Typical RNC Routers,

Hub sites, Typically BTS Typically BTS L3 capable

Access network BS sites BTS sites BTS sites BTS sites

Figure 2. Typical number of various sites in an average-size mobile network

dn0550898 # Nokia Corporation 13 (101)

Operator-specific starting points and strategies

Greenfield operator (no 2G network)

Established mobile operator (existing 2G network)

Established multi-service operator (existing 2G, PSTN and other service

Technology and networking preferences of the operators

Existing own network

14 (101) # Nokia Corporation dn0550898

Competence within the operator's organisation may create a strong inclination to

Availability and tariffs of leased connections

There is great variation in the availability of leased connections in different

Price differences between diverse services may be substantial enough to create a

Operator transport network vision and strategy

Allocation of network level functionalities

. initially 2 or 3 major core sites for resilience, later 4 6 for capacity