99
© Nokia Networks Oy 1 (99) IPA 2800 MGW Protocols in MSS/MGW Training Document

04 Protocols Overview

Embed Size (px)

Citation preview

Page 1: 04 Protocols Overview

© Nokia Networks Oy

1 (99)

IPA 2800 MGW

Protocols in MSS/MGW

Training Document

Page 2: 04 Protocols Overview

Protocols in MSS/MGW

2 (99) © Nokia Networks Oy

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This document is intended for the use of Nokia's customers only for the purposes of the agreement under which the document is submitted, and no part of it may be reproduced or transmitted in any form or means without the prior written permission of Nokia. The document has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia welcomes customer comments as part of the process of continuous development and improvement of the documentation.

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 and the customer. However, Nokia has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia will, if necessary, explain issues which may not be covered by the document.

Nokia's liability for any errors in the document is limited to the documentary correction of errors. NOKIA 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.

This document and the product it describes are considered protected by copyright according to the applicable laws.

NOKIA logo is a registered trademark of Nokia Oyj.

Other product names mentioned in this document may be trademarks of their respective companies, and they are mentioned for identification purposes only.

Copyright © Nokia Oyj 2006. All rights reserved.

Page 3: 04 Protocols Overview

Contents

© Nokia Networks Oy

3 (99)

Contents

1 Objectives ................................................................................. 5

2 Introduction............................................................................... 6

3 Network Transfer Mode............................................................ 7 3.1 Comparison between Synchronous and Asynchronous

Multiplexing ................................................................................ 7 3.2 Asynchronous Transfer Mode (ATM) .......................................... 7

4 ATM cell..................................................................................... 9 4.1 Fields in the ATM cell header ................................................... 10

5 ATM connection...................................................................... 12 5.1 ATM virtual connections ........................................................... 12 5.2 Network elements involved in the transport of user plane

information................................................................................ 13

6 Statistical multiplexing........................................................... 16

7 ATM protocol .......................................................................... 17 7.1 Inverse Multiplexing for ATM (IMA) groups ............................... 20

8 ATM Adaptation Layer............................................................ 22

9 Switching in ATM network ..................................................... 27 9.1 Switching in ATM layer ............................................................. 27 9.2 AAL type 2 switching ................................................................ 28

10 Signalling in 3G network........................................................ 30 10.1 Signalling protocol layers.......................................................... 30 10.2 AAL type 2 signalling ................................................................ 31 10.3 General protocol model for UTRAN terrestrial interfaces .......... 33

11 ATM traffic management ........................................................ 35 11.1 Traffic management functions................................................... 35 11.2 Traffic contract and negotiation................................................. 39 11.3 ATM layer service categories.................................................... 41

12 Resource management in ATM network ............................... 43 12.1 Physical Layer Trail Termination Point (phyTTP) ...................... 44 12.2 ATM interface ........................................................................... 44 12.3 Access profile of ATM interface ................................................ 45 12.4 VP/VC Link termination point .................................................... 47

Page 4: 04 Protocols Overview

Protocols in MSS/MGW

4 (99) © Nokia Networks Oy

13 Routing and digit analysis ..................................................... 48 13.1 Digit analysis ............................................................................ 48 13.2 Routing ..................................................................................... 48 13.3 Routing objects in ATM network ............................................... 49

14 IP addressing in MSS system network elements ................. 51 14.1 Introduction to TCP/IP (optional topic) ...................................... 51 14.2 IP addresses for Release 4 Core network elements ................. 61 14.3 IP address and stack configuration for IPv4 .............................. 63 14.4 LAN architecture in MSC Server network configuration............. 65 14.5 Redundancy in MSC Server system ......................................... 68

15 IP connectivity in MGW Rel.4................................................. 69 15.1 IP connectivity configuration of Multimedia Gateway ................ 70 15.2 IP Backbone in Nokia MGW...................................................... 73

16 Configuring IP connection for IP backbone Nb user plane ........................................................................................ 76

17 TDM Backbone (optional topic) ............................................. 81 17.1 TDM backbone in Nokia MGW.................................................. 81

18 SIGTRAN ................................................................................. 82 18.1 Stream Control Transmission Protocol...................................... 83

19 Overview H.248 ....................................................................... 84 19.1 H.248........................................................................................ 84 19.2 BICC......................................................................................... 85 19.3 Applying protocol stacks ........................................................... 87

20 User plane routing .................................................................. 88 20.1 Control and user plane routing.................................................. 90 20.2 User Plane Analysis.................................................................. 91

21 Appendix (for reference only) ................................................ 95 21.1 Further note on the number and types of IP addresses

for network elements ................................................................ 95 21.2 Sub-networking principles in MSC Server ................................. 98

Page 5: 04 Protocols Overview

Protocols

© Nokia Networks Oy

5 (99)

1 Objectives

After completing this module, the student should be able to:

• List all the necessary internal and external IP addresses for relevant units

in MSS and MGW.

• Name the three planes in ATM protocol reference model and their

functions.

• List the three main protocol layers of ATM and describe their functions.

• Describe the main functions of AAL type 2 signalling protocol.

• Define the bandwidth of an ATM interface and its tube structure.

• Create Virtual Paths and Virtual Channels in an ATM interface.

• Define traffic descriptors, service class as well as Quality of Service

parameters of the channels.

• Describe the relation of BICC protocol with the device control protocol

H.248 with the help of a basic call case

• Define the protocol structure in MSS for device control protocol H.248

needed between MSS and MGW

Page 6: 04 Protocols Overview

Protocols in MSS/MGW

6 (99) © Nokia Networks Oy

2 Introduction

Signalling is the exchange of information specifically concerned with the

establishment and control of connections, and with management, in a

telecommunications network.

To work efficiently, signals must be understood. Therefore, signalling systems

must be standardised for all users.

Sometimes groups of users may have differing standards. In this case, the

translation system that operates between the standards must be compatible for

all systems.

The International Telecommunication Union (ITU) is an international

organisation within which governments and the private sector co-ordinate

global telecom networks and services.

Signalling standards are nowadays set by the Telecommunication

Standardisation Sector of the ITU (ITU-T) and Third Generation Partnership

Project (3GPP) organizations.

Page 7: 04 Protocols Overview

Protocols

© Nokia Networks Oy

7 (99)

3 Network Transfer Mode

3.1 Comparison between Synchronous and Asynchronous Multiplexing

Asynchronous multiplexing (which is used in ATM technology), is more

efficient than synchronous multiplexing technologies, such as Time Division

Multiplexing (TDM).

With TDM, each user is assigned to a time slot or time slots, and no other

station can send in that time slot or those time slots. If a station has a lot of data

to send, it can send only when its time slot comes up, even if all other time slots

are empty. If, however, a station has nothing to transmit when its time slot

comes up, the time slot is sent empty and is wasted. With asynchronous

multiplexing nature, 'bandwidth on demand' is offered, that is, the user traffic

can be sent at any available time slot according to the agreement between the

user and the network.

3.2 Asynchronous Transfer Mode (ATM)

The basic functioning of Asynchronous Transfer Mode (ATM) can be compared

to an inner city street with separate lanes for different traffic types. For example

there can be one or more lanes for normal traffic, maybe reserved lanes for bus

traffic and finally bicycle lanes all with different properties and resource needs.

ATM, also known as cell relay, is a fast packet switching and multiplexing

technology. ATM was developed as part of the work on broadband ISDN to

support a universe of services (for example, voice, data and video over public

network).

ATM is a connection-oriented, error-detecting protocol. ATM does not offer

error correction. Error correction is the responsibility of end user nodes.

Minimizing error correction in intermediate nodes provides the advantages of

increased speed of switching and elimination of associated delay.

ATM provides efficient support for transmission of bursty wideband services

and offers an integrated solution to voice (circuit mode as well as packet voice),

data, and video. ATM provides quality of service (QoS) guarantee and

reliability even when resources are shared and thus ATM provides the benefit of

sharing network resources and predictable network behaviour based on packet

switching technology.

ATM utilises statistical multiplexing to take advantage of the inherently bursty

nature of applications. For a group of bursty connections, less bandwidth can be

reserved than if bandwidth reservation would be based on the peak rate of the

connections. Achieved transmissions cost savings are considerable.

Page 8: 04 Protocols Overview

Protocols in MSS/MGW

8 (99) © Nokia Networks Oy

The fundamental strategy behind ATM is to split the information into small

fixed-size units, called 'cells', that are easy to handle. The fixed size of the cell

allows efficient switching. ATM networks allow statistical multiplexing (that is,

multiplexing of many connections with variable rate characteristics), which

altogether reduces the overall bandwidth requirements.

Figure 1. Asynchronous Transfer Mode (ATM)

Page 9: 04 Protocols Overview

Protocols

© Nokia Networks Oy

9 (99)

4 ATM cell

The user traffic is split and delivered in fixed length packets called ATM cells.

The size of the cell is 53 bytes, which is divided into a 5-byte header and a

48-byte payload field. The ATM cell is relayed based on a label in the header:

Virtual Channel Identifier (VCI) and Virtual Path Identifier (VPI).

Header5 bytes

Payload48 bytes

53 bytes

Figure 2. ATM cell structure

There are two formats of an ATM cell (depending on the type of the interface):

• ATM UNI (User-Network Interface) cell that is used for

communication between ATM endpoints and ATM switches.

• ATM NNI (Network-Node Interface) cell that is used for

communication between ATM switches.

For ATM interfaces in 3G networks, User-Network Interface (UNI) refers to the

interface between terminal equipment and a network termination where access

protocols apply. The interface between a RNC and a WCDMA BTS is seen as

an UNI interface.

Network-Node Interface (NNI) is the interface between two network nodes like

a RNC and an MGW.

Figure 3 shows the specified ATM interfaces between network elements in a 3G

network.

Page 10: 04 Protocols Overview

Protocols in MSS/MGW

10 (99) © Nokia Networks Oy

PSTNMGW MSCBSUE

A BIu-CSIubUu

UNI NNI

IP networkGGSN

Iu-PS

NNI

RNC

SGSN

RNCBS

BS

Iur

NNI

UNI

UNI

ATM is employed

Gn Gi

Figure 3. ATM interfaces in 3G network.

There is a slight difference between the first byte of the UNI and NNI header.

The NNI header does not include the Generic Flow Control (GFC) field.

Instead the NNI header has a Virtual Path Identifier (VPI) field that occupies

the first 12 bits, allowing larger trunks between public ATM switches.

GFC Generic Flow ControlVPI Virtual Path IdentifierVCI Virtual Channel Identifier

PT Payload TypeCLP Cell Loss PriorityHEC Header Error Control

VCI

GFC VPI

VPI

VCI

VCI PT CLP

HEC

123457 68

VCI

VPI

VPI

VCI

VCI PT CLP

HEC

123457 68

User Network Interface (UNI) Network Node Interface (NNI)

Payload Payload

Header(5 bytes)

Payload(48 bytes)

Figure 4. Basic ATM cell format

4.1 Fields in the ATM cell header

Generic Flow Control (GFC)

Provides local functions, such as identifying multiple stations that share a single

ATM interface. This field is typically not used and is set to its default value.

Page 11: 04 Protocols Overview

Protocols

© Nokia Networks Oy

11 (99)

Virtual Path Identifier (VPI)

In conjunction with the VCI, identifies the next destination of a cell as it passes

through a series of ATM switches on the way to its destination.

Virtual Channel Identifier (VCI)

In conjunction with the VPI, identifies the next destination of a cell as it passes

through a series of ATM switches on the way to its destination.

Payload Type (PT)

Indicates in the first bit whether the cell contains user data or control data. If the

cell contains user data, the second bit indicates congestion, and the third bit

indicates whether the cell is the last in a series of cells that represent a single

AAL5 frame.

Cell Loss Priority (CLP)

Indicates whether the cell should be discarded if there is congestion in the

network. If the CLP bit equals 1, the cell should be discarded in preference to

cells with the CLP bit equal to zero.

Header Error Control (HEC)

Calculates the checksum only on the header itself. The network instantly

discards any cell that fails the header error check.

Page 12: 04 Protocols Overview

Protocols in MSS/MGW

12 (99) © Nokia Networks Oy

5 ATM connection

ATM is a connection-oriented technique. The end-to-end route is defined

through the network at the beginning of the connection setup and the route

remains the same throughout the connection. ATM cells are routed on the same

route to both directions. This guarantees that the cells arrive in the receiving end

in the same order they where sent. Furthermore, cell delay variation is also

minimised and since routes are known it is possible to predict link behaviour.

5.1 ATM virtual connections

Virtual connections (VC) are used for providing connectivity between

communicating endpoints. There are two types of ATM connections:

• Virtual Channel Connection (VCC)

• Virtual Path Connection (VPC).

Each ATM cell contains a label in its header to explicitly identify the VC, to

which the cell belongs. This label consists of two parts: Virtual Channel

Identifier (VCI) and Virtual Path Identifier (VPI).

Virtual Channel Connection (VCC) is a logical connection in ATM.

Virtual Channel Identifier (VCI) identifies a particular VC link under a given

VPC. A specific value of a VCI is assigned each time a VC is switched in the

network. Hence, it has only local meaning.

Virtual Path Connection (VPC) is a logical grouping of VCCs having the

same endpoints. Thus, all the cells flowing in a single VPC are switched

together. Virtual paths are used for bundling a number of virtual channels into a

higher bandwidth stream routed through ATM switches. That is, cross-

connection and switching can be done on a higher level and not on individual

VCC level.

Virtual Path Identifier (VPI) identifies a group of VC links at a given

reference point that share the same VPC. A specific value of a VPI is assigned

each time a VP is switched in the network.

Transmission path is a bundle of VPs. The following figure shows the relation

among VCs, VPs and a transmission path.

VC

VC

VP

VP

Transmission path

Figure 5. Relation between a transmission path, VPs and VCs

Page 13: 04 Protocols Overview

Protocols

© Nokia Networks Oy

13 (99)

Virtual paths help to reduce the control cost by grouping connections that share

common paths through the network into a single unit. Network management

actions can then be applied to a small number of groups of connections instead

of a large number of individual VCC connections.

Virtual Path Connections (VPCs) have many advantages:

Simplified network architecture

Network transport functions can be separated into those related to individual

logical connections (VCC) and those related to a group of logical connections

(VPC).

Increased network performance and reliability

The network deals with fewer, aggregated entities.

Segregation of traffic

A form of priority control can be implemented by segregating traffic types

requiring different quality of service (QoS).

Reduced processing and short connection setup time

Much of the work is done when the VPC is set up. By reserving capacity on a

VPC in anticipation of later call arrivals, new VCCs can be established by

executing simple control functions at the end points of the VPC; no call

processing is required at transit nodes. Thus, the addition of new VCCs to an

existing VPC involves minimal processing which decreases the connection

setup delay.

Enhanced network services

The VPC is used internally in the network but is also visible to the end user.

Thus, the user may define closed user groups or closed networks of VC bundles.

5.2 Network elements involved in the transport of user plane information

The following are the definitions of the network elements involved in the

transport of user plane information (from ITU-T I.311):

VP cross-connect is a network element, which connects VP links. It translates

VPI (not VCI) values and is directed by management plane functions − not by

control plane functions.

Page 14: 04 Protocols Overview

Protocols in MSS/MGW

14 (99) © Nokia Networks Oy

VC cross-connect is a network element, which connects VC links. It terminates

VPCs and translates VCI values and is directed by management plane functions

− not by control plane functions.

VP-VC cross-connect is a network element that acts both as a VP cross-

connect and as a VC cross-connect. It is directed by management plane

functions − not by control plane functions.

VP switch is a network element that connects VP links. It translates VPI (not

VCI) values and is directed by control plane functions.

VC switch is a network element that connects VC links. It terminates VPCs and

translates VCI values and is directed by control plane functions.

VP-VC switch is a network element that acts both as a VP switch and as a VC

switch. It is directed by control plane functions.

Routing functions of virtual channels are done at a VC switch/cross-connect. This routing involves translation of the VCI values of the incoming

VC links into the VCI values of the outgoing VC links.

Figure 6 and Figure 7 show examples of VP and VC switching.

Figure 6. VC and VP switching

Page 15: 04 Protocols Overview

Protocols

© Nokia Networks Oy

15 (99)

Figure 7. VP switching

Page 16: 04 Protocols Overview

Protocols in MSS/MGW

16 (99) © Nokia Networks Oy

6 Statistical multiplexing

Statistical multiplexing is one of the main benefits of ATM. Operators can

utilise statistical multiplexing to take advantage of the inherently bursty nature

of applications. Users of ATM networks generate numbers of cells according to

the amount of information they want to transfer. The amount of network

resources required by users changes as a function of time. When these resources

are shared among users, like in ATM, it is very unlikely that all users send at

their peak cell rate simultaneously. This means that the network operator can

either reduce the amount of resources required for a fixed load or it can

accommodate more load with the same amount of resources. This phenomenon

is called statistical multiplexing. The network resources are shared among users

with either VCCs or VPCs.

Figure 8 shows an example of statistical multiplexing. The picture on the left-

hand side shows required amount of bandwidth when the capacity of each

connection is reserved according to the peak cell rate. The picture on the right

hand side shows the so-called statistical multiplexing gain, when principle of

statistical multiplexing is used in the bandwidth reservation.

Figure 8. Statistical multiplexing gain

When virtual paths are used, two levels of multiplexing exist: VC level and

VP level. At the VC level, VCs are statistically multiplexed on a VP. At the VP

level, VPs are either deterministically or statistically multiplexed on a physical

link.

If VPs are deterministically multiplexed, they do not share the bandwidth

reserved for them with the other VPs on the same link. The sum of the reserved

bandwidths of the VPs cannot exceed the bandwidth of the link. If VPs are

statistically multiplexed, they do share the bandwidth nominally reserved for

them with the other VPs on the same link. VPs do not have strictly reserved

bandwidths.

Page 17: 04 Protocols Overview

Protocols

© Nokia Networks Oy

17 (99)

7 ATM protocol

The ATM reference model includes three planes, which consist of all layers:

User plane is responsible for user information transfer and associated controls

(such as flow control and error control)

Control plane performs call and connection control functions

(such as signalling procedures).

Management plane contains two components:

• Layer management, which performs management functions relating to

layer's resources and parameters (for instance, OAM information flows).

• Plane management, which performs management functions related to the

system as a whole.

The ATM protocol reference model includes three functional layers:

• Physical layer

• ATM layer

• ATM adaptation layer (AAL)

ATM Layer

Physical Layer

ATM Layer

ATM Adaptation Layer

Physical Medium (PM)

Transmission Convergence (TC)

Segmentation And Reassembly (SAR)

Convergence Sublayer (CS)

Figure 9. ATM protocol layers

The physical layer defines the transmission medium, electrical characteristic,

network interfaces, and a signal-encoding scheme. The ATM physical layer is

divided into two parts:

• Physical medium dependent sublayer

• Transmission convergence sublayer

Physical Medium Dependent (PMD) sublayer

This layer is responsible for coding, decoding, scrambling, and adaptation to the

medium. PMD sublayer is dependent on the physical medium used. ATM can

Page 18: 04 Protocols Overview

Protocols in MSS/MGW

18 (99) © Nokia Networks Oy

use any physical medium capable of carrying ATM cells, such as SDH, SONET

and E1.

Transmission Convergence (TC) sublayer

The convergence sublayer handles all the processes involved in taking cells

to/from the ATM layer, and performs bit rate adaptation, header protection, cell

delineation, and adaptation to the physical mediums structure.

Existing transmission networks are widely based on Plesiochronous Digital

Hierarchy (PDH). Although the Synchronous Digital Hierarchy (SDH) forms

the basis of transport of the ATM traffic, there is need to transport ATM cells

also using PDH transmission networks. PDH-based ATM interfaces are used for

providing low-speed link connections between the ATM network elements.

PDH interfaces are especially suitable for links between RNC and base station

(BS), where the bandwidth requirements are low and capacity and cost

optimisation are necessary. Interface types are E1, T1 and JT1.

In addition to traditional PDH order multiplexing levels (for example, between

E1 or E3 level), inverse multiplexing, which provides flexible transmission

capacity building according to the operator's needs, is also supported at the

ATM physical layer.

The user traffic is split and delivered in fixed length packets called ATM cells.

The size of the cell is 53 bytes, which is divided into a 5-byte header and a

48-byte payload field.

Header5 bytes

Payload48 bytes

53 bytes

Figure 10. ATM cell structure

The ATM layer adds the cell header to the 48-byte cell payload after it has

been assembled in the ATM adaptation layer (AAL), and extracts the header

before the cell is delivered to the AAL. The layer translates the values of the

VCI and VPI at the ATM switches or cross-connects. In addition, multiplexing

and switching of cells takes place at the ATM layer. The ATM layer provides

virtual connections between end points and maintains the contracted quality of

service (QoS) by applying a traffic contract procedure at a call setup time. It is

also used to "police" the agreed traffic contract while the connection is in

progress.

The ATM adaptation layer (AAL) provides data link services for upper layer

protocols. AAL is needed for adapting upper-layer protocol data units such as

TCP/IP and signalling to ATM layer. Furthermore voice codecs generate short

voice packets, which must be adapted to ATM layer services.

Page 19: 04 Protocols Overview

Protocols

© Nokia Networks Oy

19 (99)

The AAL maps user data from higher layer into standard ATM cells to be

transported over an ATM network. Then it collects information from the ATM

cells for delivery to higher layers. AAL layer includes two sublayers:

• Convergence sublayer (CS)

• Segmentation and assembly sublayer (SAR)

Convergence Sublayer (CS)

PayloadPayload HeaderHeader

48 bytes5 bytes

User data

AAL

Segmentation and Reassembly Sublayer (SAR)

ATM Layer

Transmission Convergence (TC)

48 bytes

Physical Medium Dependent(PMD)

SD

H O

/H

PayloadHeader

Scramble frame and adaptsthe signals to the optical orelectrical transmissionmedium

STM-1 Frame

PhysicalLayer

Figure 11. ATM adaptation layer functions

Convergence sublayer (CS) provides the AAL service to the higher layer

protocol. This sublayer is service dependent. It performs a variety of functions

that depend on the actual service being supported, including clock recovery,

compensating for cell delay variation and dealing with other problems

introduced by the network (e.g. cell loss).

Segmentation and reassembly sublayer (SAR) provides segmentation of the

users' information (together with any supporting information added by the

convergence sublayer) into 48-byte segments that form the payload field of an

ATM cell. It also reassembles the contents of the ATM cell information fields

into higher layer information formats.

Page 20: 04 Protocols Overview

Protocols in MSS/MGW

20 (99) © Nokia Networks Oy

7.1 Inverse Multiplexing for ATM (IMA) groups

The purpose of Inverse Multiplexing in ATM network (IMA) is that the

capacity of many low-bit-rate transmission lines can be combined into a group

that is seen as a single virtual link by the ATM layer of a network element. The

existing PDH transmission medium can be utilised as an IMA group:

• between WCDMA BTS and a Radio Network Controller (RNC)

• between two RNCs.

• between MGW and RNC

There can also be a SDH transmission medium between a WCDMA BTS and a

RNC , between two RNCs or between MGW and RNC.

How does the inverse multiplexing work?

When user traffic is transmitted across the IMA link, the ATM cell stream is

passed from the ATM layer to the IMA sublayer. In the IMA sublayer, the

ATM cell stream is split on a cell-by-cell basis, and the traffic is distributed

evenly onto the physical links, in which IMA frames carry the traffic to the

receiving end of the IMA link. At the receiving end of the IMA link, the

original ATM cell stream is recreated and passed back to the ATM layer. The

transmitting end (the near-end) must align the transmission of IMA frames to all

physical links, which allows the receiving end (the far-end) to adjust for

differential link delays by measuring the arrival times of the IMA frames on

each physical link.

How are the IMA groups created?

The IMA groups are created at both ends of the transmission lines, which are

seen as one virtual IMA link. The PDH exchange terminals at both ends of the

IMA virtual link have to be tied up to the same kind of functional units.

The maximum number of transmission lines at Iub interface, between Nokia

WCDMA BTS and a RNC, that can be grouped into one IMA group is 8 x E1

(2 Mbit/s) lines or 8 x T1/J1 (1,5 Mbit/s) lines. At Iur interface, between two

RNCs, the maximum number is 16 x E1 or T1/J1 lines. At Iu-Cs interface,

between MGW and RNC, the maximum number is 8 x E1 (2 Mbit/s) lines or 8

x T1/J1 (1,5 Mbit/s) lines.

When creating IMA groups, the transmission lines are identified with the PDH

Exchange Terminals (PETs) that they are connected to. All the PETs of one

IMA group have to belong to the same NIP1 functional unit. There can be

several IMA groups per one functional unit, but all the transmission lines of one

IMA group must go to the same direction.

A PET can only belong to one IMA group. However, a PET can be transferred

from one IMA group to another, provided that the groups share the same

functional unit. When transferring a PET from one group to another, the

operator may also have to make changes in the switching.

Note

When configuring IMA groups, the grouped transmission lines should all have

Page 21: 04 Protocols Overview

Protocols

© Nokia Networks Oy

21 (99)

the same physical route in order to keep the delays between the physical links as

small as possible. That is, the IMA frames from one link should not have to wait

for a long time for the IMA frames from other links before they are recombined

into an ATM cell stream at the receiving end of the IMA virtual link.

Note

One of the transmission lines in the IMA group is defined initially as a Timing

Reference Link (TRL). The transmission line defined as the TRL cannot be

removed from the IMA group and added to another IMA group.

Page 22: 04 Protocols Overview

Protocols in MSS/MGW

22 (99) © Nokia Networks Oy

8 ATM Adaptation Layer

Several AALs are currently specified to support different types of traffic. The

following figure shows the characteristics of user traffic supported by each

AAL.

ATM layer

Physical layer

Bit rate

Timing requiredbetween source & dest.

Connection mode

Example of traffic types

AAL

Constant Variable

Synchronised Not synchronised

Connection orientedor connectionless

Connection oriented

Voice,circuit

emulation

Video,voice with

silenceremoved

Data,SMDS

Data,FrameRelay,

IP

AAL1 AAL3/4AAL2 AAL5

Figure 12. ATM adaptation layers and supported traffic

AAL1

AAL1 is for constant bit rate (CBR) information, which requires timing

synchronisation between the source and destination. It is appropriate for

transporting telephone traffic, uncompressed video traffic and circuit emulation

service.

AAL2

AAL2 is for variable bit rate (VBR) information, which requires a strict

relationship between the transmission and reception clocks. It provides the

bandwidth efficient transmission of short, variable length packets in delay-

sensitive applications. AAL2 multiplexes short packets from multiple users into

one ATM connection. It has been mainly designed for transporting compressed

voice in mobile networks, but will also be used for compressed voice in wireline

applications. This AAL is aimed at compressed video, which will vary its bit

rate significantly.

AAL3/4

AAL3/4 is for data transmission in a connection oriented or connectionless

mode. This is aimed at variable bit rate information, which has no strict timing

Page 23: 04 Protocols Overview

Protocols

© Nokia Networks Oy

23 (99)

relationship between the transmitter and receiver. It is used to transmit Switched

Multimegabit Data Service (SMDS) packets over an ATM network.

AAL5

AAL5 supports connection oriented or connectionless variable bit rate data. No

timing relationship is required between the transmitter and receiver. It is used to

transfer most non-SMDS data, such as IP over ATM and Local Area Network

(LAN) emulation, signalling channels, and Frame Relay/ATM interworking.

AAL5 is also known as Simple and Efficient Adaptation Layer (SEAL). It

provides a similar data transport service to AAL3/4, but it provides the service

in a much simpler way and with significantly fewer overheads, and it does not

include a multiplexing capacity.

8.1.1 ATM adaptation layer 2 (AAL2)

The human speech contains significant periods of silence and requires low

network bandwidth for transmission. Compressed voice is inherently variable

bit rate (VBR) but delay sensitive. The AAL2 enables these low bit rate and

delay sensitive applications to share a single ATM VCC thus improving the

network bandwidth utilisation and reducing the call establishment time as

shown in Figure 13.

In order to meet the QoS requirements for real time applications ATM and

AAL2 has been selected as transport technology for the Iub Iur and Iu-cs in

UMTS Release 99 and Release 4. The AAL2 layer is multiplexing the transport

channels into ATM VCCs as individual AAL2 connections. AAL2 is able to

multiplex up to 248 connections into one ATM VCC.

Voice/user data is accumulated into a short packet having a 3-byte header.

These short packets are accumulated into a standard ATM cell. The packet

header consists of a channel identification number, packet length, user-to-user

indication, and a header error control code. Each cell's payload has a one-byte

start field to indicate the next packet's starting point, which maximises the

packet packing density in cell assembly for low bit rate voice. In addition, the

silence compression function on a codec works effectively using AAL2,

because in a silent period in a conversation, the short packets do not have to be

accumulated into a cell.

Page 24: 04 Protocols Overview

Protocols in MSS/MGW

24 (99) © Nokia Networks Oy

Low bit rate voice

ch#4

ch#3

ch#2

ch#1

Silence

. . . .

. . . .

Short packet hh ch#1ch#1 hh ch#2ch#2 hh ch#3ch#3 hh ch#4ch#4 hh ch#2ch#2 . . . .

StandardATM cell

HH

Start field

HH

CID in the header

Figure 13. AAL2 cell packing

AAL2 is especially suitable for carrying voice packets that are produced by

speech codecs. Also longer packet lengths up to 64 Kbytes are supported by

AAL2.

AAL2 is divided into two sublayers:

Service specific convergence layer (SSCS) performs the segmentation and

reassembly function for application packets longer than CPS packet size

(that is, 45 bytes by default), but also packet size of 64 bytes can be used.

Common part sublayer (CPS) enables variable-size packets (0 - 64 bytes)

from different users to be assembled in an ATM cell payload and transmitted on

the same ATM virtual connection. A packet (minicell) received from a user is

converted to a CPS packet with a 3-byte header that includes a single byte

Channel ID (CID) to distinguish AAL2 connections within a single ATM VCC.

Multiplexing and demultiplexing in the AAL2 occurs in the CPS. The Common

Part Sublayer

(CPS) encapsulates the segments created by the SSCS layer by adding a 3-byte

header. The encapsulated segments are called CPS Packets and their size is at

maximum 48 bytes (note that segmentation to 64 bytes is also allowed). The

AAL2 multiplexer assembles the CPS Packets into CPS PDUs (with 1 byte

header). The PDU:s are in fact the payload of the ATM cells and their

maximum size is 48 bytes.

In order to increase the multiplexing gain a timer is initialized whenever the

CPS PDU is smaller than 48 bytes i.e. the CPS Packets waiting in the assembly

buffer are not filling an ATM cell. The ATM cell is filled up with padding bits

and sent when the timer value expires and there is no new CPS Packet arriving

to the multiplexer. A longer timer value results in larger delay and higher

multiplexing gain, i.e., the load of ATM links is reduced. In order to reduce the

delay on the AAL2 layer the value of the timer is often set to zero. This way an

ATM cell is generated upon arrival of a CPS Packet into empty assembly buffer

regardless of its size.

Page 25: 04 Protocols Overview

Protocols

© Nokia Networks Oy

25 (99)

CPS Common Part SublayerSSCS Service Specific Convergence Sublayer

ATM layer

Higher layers

AAL2 CPS

AAL2 SSCS

CPS AAL2 channelmultiplexing anddemultiplexing

Segmentation andreassembly function

for application packets

AAL2

User data

Figure 14. ATM adaptation layer 2 sublayers

8.1.2 ATM adaptation layer 5 (AAL5)

AAL5 includes two main sublayers: Segmentation and Assembly Sublayer

(SAR) and Convergence Sublayer (CS). The CS is divided into the Common

Part Convergence Sublayer (CPCS) and the Service Specific Convergence

Sublayer (SSCS) as shown in Figure 15. The CPCS and the SAR sublayer are

called the Common Part of the AAL type 5. SAR and CPCS layers are common

for all AAL5 service users. Those AAL5 common part sublayers can be

implemented as the combination of a SAR chip and a device driver or as a pure

software implementation.

Different Service Specific Convergence Sublayer protocols (SSCSs) to support

specific AAL user services or groups of services are defined. The SSCS may

also be null, in the sense that it only provides for the mapping of application

protocol to the Common Part Convergence Sublayer (CPCS) and vice versa.

The Service Specific Connection Oriented Protocol (SSCOP) is, when active,

responsible for providing mechanisms for the establishment, release and

monitoring of signalling information exchanged between peer signalling

entities. In practice SSCOP provides for example: flow control and thus a

switch or end system can control the rate at which it receives signalling

messages. Each SSCOP PDU contains a sequence number, this allows SSCOP

to determine if one PDU has been lost and request retransmission. SSCOP can

also ensure sequential integrity by using these sequence numbers.

Connection establishment and resynchronization involves negotiation of buffer

sizes and other transfer characteristics and renegotiation of these parameters

Page 26: 04 Protocols Overview

Protocols in MSS/MGW

26 (99) © Nokia Networks Oy

should a connection fail. The health of a connection is monitored via exchange

of status messages and connections are maintained through use of keep alive

messages.

ATM layer

Higher layers

AAL5 CPS

AAL5 SSCS

CPCSTransparent transport of

SDUs

SSCFMaps Layer 3 to SSCOP

AAL5

SSCOPReliable data transfer

SARSDU segmentation and

reassembly SA

RC

S

CP

CS

SS

CS

Co

mm

on

part

Figure 15. ATM adaptation layer 5 sublayers

AAL5 can be used for IP over ATM traffic, signalling traffic bearer, and

FR/ATM interworking. Internal control connections of RNC/MGW (ATM

module) are based on ATM AAL5 connections between units. AAL5 capability

is available in all units having ATM connectivity (in some units only for system

internal use, e.g. message passing).

Page 27: 04 Protocols Overview

Protocols

© Nokia Networks Oy

27 (99)

9 Switching in ATM network

In ATM network, the user traffic can be switched in ATM layer or ATM

adaptation layer (AAL). The switching in ATM adaptation layer used in mobile

network is AAL type 2 switching.

9.1 Switching in ATM layer

The basic operation of an ATM switch is straightforward: The cell is received

across a link on a known VCI or VPI value. The switch looks up the connection

value in a local translation table to determine the outgoing port (or ports) of the

connection and the new VPI/VCI value of the connection on that link. Then, the

switch retransmits the cell on that outgoing link with the appropriate connection

identifiers. Because all VCIs and VPIs have only local significance across a

particular link, these values are remapped, as necessary, at each switch.

There are two levels of switching capability within an ATM switch (which

perform switching at ATM layer): Virtual Path (VP) switching and Virtual

Channel (VC) switching.

Virtual path (VP) switching

VP switching occurs when only the VPI field within the cell header is used to

describe the destination of the cells. This has the advantage that many VCIs

destined for the same network endpoint can be "bulk switched".

VP switches terminate VP links. A VP switch translates incoming VPIs to the

corresponding outgoing VPIs according to the destination of the VPC whereas

VCI values remain unchanged.

VP switching is shown in Figure 16.

Virtual channel (VC) switching

VC switching takes place when all cells on a physical interface are identified

and switched to their destination through the switch fabric based on a

combination of the VPI/VCI values. A table is maintained on each interface

identifying input and output ports associated with certain VPI/VCI.

The VCI values are changed in a VC switch and the VPI values are changed as

they pass through a VP switch. However, VCI values are not changed when

passing through a VP switch.

VC switching is shown in Figure 16.

Page 28: 04 Protocols Overview

Protocols in MSS/MGW

28 (99) © Nokia Networks Oy

VPI 3

VPI 8

VPI 36

VPI 23 VPI 9

VP switch

Port

VCI 9VCI 10

VCI 9VCI 10

VCI 15

VCI 26

VCI 9VCI 10

VC switch

Port

Port

Figure 16. Virtual channel and virtual path switching

9.2 AAL type 2 switching

AAL2 supports multiplexing of different sources on a single ATM virtual

connection. The Channel Identifier (CID) is used to distinguish AAL

connections within a single ATM VCC. An AAL2 switching system performs

AAL2 level switching, while an ATM node performs only ATM level

switching. The traditional VPI/VCI table used for ATM cell switching is

extended one more level by introducing CID entries to identify AAL type 2

connections. An ATM cell received at an AAL type 2 switch is first

demultiplexed into AAL type 2 connections (CIDs), then switched and

assembled into outgoing ATM cells according to the entries found in the

VPI/VCI/CID table.

If an AAL2 connection is routed through ATM switches that do not support

AAL2 switching, it is considered to be AAL2 trunking and those switches

support only ATM level switching.

In Figure 17, the traffic from the users is multiplexed by AAL2 in one ATM

cell. These kinds of connections are referred to as virtual AAL2 connections

inside the virtual ATM connection.

Page 29: 04 Protocols Overview

Protocols

© Nokia Networks Oy

29 (99)

VCC

User 1

User 2

User 3

PHY

ATM

AAL2

H #1 #2

Process

#3

ATM cell

Upper layer

PHY

ATM

AAL2 Process

H #1 #2 #3

ATM cell

Upper layer

H #5 #6 #7 ATM

AAL2

H #5 #6

Process

#7

ATM cell

Upper layer

BS RNC MGW

VCC

ATM connection

AAL2 connections

ATM connection

PHY

ATM cell

Figure 17. ATM virtual connections and AAL2 connections

Page 30: 04 Protocols Overview

Protocols in MSS/MGW

30 (99) © Nokia Networks Oy

10 Signalling in 3G network

10.1 Signalling protocol layers

Signalling protocol can be looked at as an application running on top of the

lower, physical, ATM and AAL layers.

Physical layer

ATM layer

SignallingAAL

AAL

Signalling protocol User data

C-Plane U-Plane

Figure 18. ATM protocol for signalling and user data

Signalling occurs over a Signalling ATM Adaptation Layer (SAAL) residing

between the ATM layer and the signalling protocol. The SAAL provides

reliable transport of signalling messages between two ATM systems to include

the recovery of multiple gaps within the data stream. The SAAL is composed of

two sublayers: Common Part and Service Specific Part.

The Common Part is based on AAL5, which consists of Segmentation and

Reassembly Sublayer (SAR) and Common Part Convergence Sublayer (CPCS)

functions. The common part ensures information transfer and detection of

corrupt service data units.

The Service Specific Part is divided into:

• Service Specific Co-ordination Function (SSCF)

• Service Specific Connection Oriented Protocol (SSCOP)

The SSCF maps signalling messages from the upper level in to SSCOP while

SSCOP provides mechanisms for establishing, releasing, and monitoring

signalling information exchange between signalling entities.

There are two types of SAAL:

• SAAL-NNI

Page 31: 04 Protocols Overview

Protocols

© Nokia Networks Oy

31 (99)

• SAAL-UNI

SAAL-NNI complies with ITU-T Q.2140 B-ISDN AAL - Service Specific

Co-ordination Function for Signalling at the Network-Node Interface (SSCF at

NNI), Q.2144 B-ISDN Signalling ATM Adaptation Layer (SAAL) – Layer

Management for the SAAL at the Network-Node Interface (NNI), Q.2110 B-

ISDN SAAL - Service Specific Connection Oriented Protocol (SSCOP).

SAAL-UNI complies with ITU-T Q.2110 B-ISDN AAL Service Specific

Connection Oriented Protocol (SSCOP) and Q.2130 B-ISDN AAL Service

Specific Co-ordination Function (SSCF) for signalling at the User-Network

Interface (UNI).

Note

AAL type 2 signalling protocol and Node B Application Protocol (NBAP)

application protocol use UNI SAAL in point-to-point signalling connections in

3G RAN Iub interface where there is no SS7 signalling network available.

10.2 AAL type 2 signalling

AAL2 signalling protocol is a separate new protocol − not an extension of any

existing ATM signalling protocols. This approach increases the speed of AAL2

connection establishment because intermediate "ATM-only" switches do not

delay the process by storing and forwarding AAL2 signalling protocol

messages. A further benefit is that switched AAL2 connections can be

established on top of any ATM network regardless of the protocol used for

establishing ATM level connections. The ATM level connections can be

established using any existing ATM signalling protocol, for example, ITU-T

Broadband ISDN User Part (B-ISUP), ATM Forum Private Network-Network

Interface (PNNI), ITU-T Q.2931, or ATM Forum User-Network Interface

(UNI).

RNSAP/RANAP AAL2 SIG

MTP3b

ATM

SSCF-NNI

SSCOP

AAL5

SSCF-UNI

STCSCCPNBAP

Physical

Figure 19. AAL 2 signalling protocol

Page 32: 04 Protocols Overview

Protocols in MSS/MGW

32 (99) © Nokia Networks Oy

The AAL type 2 signalling protocol provides functions to dynamically establish

and release AAL type 2 point-to-point connections as requested by AAL2

served users in a network comprised of AAL2 endpoints and AAL2 switches.

The AAL2 served user in 3G networks is the radio resource management and

handover control entity, which establishes/releases AAL2 connections when

new soft handover legs are established/released.

The AAL2 signalling protocol feature provides a clear and efficient interface to

the users of the AAL2 signalling protocol. The AAL2 signalling protocol is

used by higher layer functionalities for AAL2 connection establishment and

release of a connection.

AAL2 pathsAAL2 Switch

AAL2 Switch

Signaling channel

AAL2 ch = AAL2 path & CIDCID = 8-255

AAL Type 2 Signaling

Path = ATM VCC(Interface,VPI/VCI)

CID(x) CID(x)

SETUP

ATM Switch

Figure 20 AAL Type 2 signalling

The feature contains procedures to establish an AAL2 connection, release an

AAL2 connection and maintenance functions to align the status of the AAL2

resources within the two peer AAL2 nodes. It offers a reset mechanism, which

is used to return one or several AAL2 channels to idle condition. It is invoked

after an unrecognised status of connection, for example, if the signalling peer

entity does not respond to message. The feature also contains a mechanism for

blocking and unblocking resources during test procedures, before service-in or

modification of it bandwidth.

The Signalling Transport Converter (STC) provides the generic signalling

bearer service for exchanging AAL2 signalling messages between protocol

entities. It provides assured data transport and service availability indication

services independent of the underlying signalling bearer. Examples of signalling

bearers are MTP-3 and SAAL UNI.

Page 33: 04 Protocols Overview

Protocols

© Nokia Networks Oy

33 (99)

Note

The signalling bearer converters use AAL5 connections. These signalling

connections are configured as permanent ATM connections between AAL

type 2 switches.

AAL2 signalling complies with ITU-T Q.2630.1 AAL type 2 signalling

protocol (Capability Set 1).

10.3 General protocol model for UTRAN terrestrial interfaces

The protocol structures in UTRAN terrestrial interfaces (Iu, Iur, Iub) are

designed according to the same general protocol model as shown in Figure 21.

TransportNetworkLayer

RadioNetworkLayer

ALCAP(s)

SignallingBearer(s)

ApplicationProtocol

SignallingBearer(s)

DataStream(s)

DataBearer(s)

User PlaneControl Plane

TransportNetwork

Control Plane

TransportNetwork

User Plane

TransportNetwork

User Plane

Physical Transmission layer

Figure 21. General protocol model for UTRAN terrestrial interfaces

Horizontal layers

The protocol structure consists of two main layers:

• Radio network layer

• Transport network layer

All UTRAN-related issues are visible only in the radio network layer. The

transport network layer represents standard transport technology that is selected.

Vertical planes

There are four main planes in the protocol structure:

Page 34: 04 Protocols Overview

Protocols in MSS/MGW

34 (99) © Nokia Networks Oy

• Control plane

The control plane is used for all 3G specific control signalling. It includes

the application protocol (i.e. RANAP in Iu, RNSAP in Iur, NBAP in Iub)

and the signalling bearer for transporting the application protocol

messages.

The application protocol is used, among other things, for setting up

bearers to the UE (i.e. the radio access bearer in Iu and subsequently the

radio link in Iur and Iub). The signalling bearer for the application

protocol is always set up by O&M actions.

• User plane

All information sent and received by the user, such as coded voice in a

voice call or the packets in an Internet connection, are transported via the

user plane.

The user plane includes the data stream(s) and the data bearer(s).

• Transport network control plane

The transport network control plane is used for all control signalling

within the transport network layer. It includes the ALCAP protocol that is

needed to set up the transport bearers (data bearers) for the user plane. It

also includes the signalling bearers needed for the ALCAP.

ALCAP (Access Link Control Application Part) protocol is the generic

name for the transport signalling protocols used to set up and tear down

transport bearers.

When using the transport network control plane, the transport bearers for

the data bearer in the user plane are set up in the following fashion: First

there is a signalling transaction by the application protocol in the control

plane. This transaction triggers the setup of the data bearer by the

ALCAP protocol that is specific for the user plane technology.

It should be noted that ALCAP may not be used for all types of data

bearers. If there is no ALCAP signalling transaction, the transport

network control plane is not needed at all. This is the case when

preconfigured data bearers are used.

The signalling bearer for the ALCAP may not be of the same type as that

for the application protocol. The signalling bearer for ALCAP is always

set up by O&M actions.

• Transport network user plane

The data bearer(s) in the user plane and the signalling bearer(s) for the

application protocol also belong to the transport network user plane. The data

bearers in the transport network user plane are directly controlled by the

transport network control plane, but the control actions required for setting up

the signalling bearer(s) for the application protocol are considered O&M

actions.

Page 35: 04 Protocols Overview

Protocols

© Nokia Networks Oy

35 (99)

11 ATM traffic management

ATM provides a mechanism to ensure that the quality of service (QoS) remains

as high as possible while the operator is able to utilise the network capacity in

an efficient way. The actions taken to achieve the QoS targets in ATM networks

are called traffic management. The operator can use ATM traffic management

for providing QoS for ATM connections. Also fairness of resource allocation

between users can be guaranteed with traffic management functions. Bandwidth

of ATM connections can be allocated flexibly according to application needs.

11.1 Traffic management functions

There are different functions to manage and control the traffic in ATM

networks. The two basic control functions are Connection Admission Control

(CAC) and Usage/Network Parameter Control (UPC/NPC). On top of this two

basic control functions, the following ones may be used in appropriate

combinations to support and complement the actions of UPC/NPC and CAC:

traffic shaping, priority control, frame discard etc.

11.1.1 Connection Admission Control (CAC)

Connection Admission Control (CAC) is used for checking that there are

bandwidth and buffer resources for requested connections. CAC is defined as a

set of actions taken by the network at the connection establishment phase in

order to decide whether a virtual channel/path connection can be accepted or

rejected. Sophisticated CAC algorithms allow maximal utilisation of network

element internal resources and external links while guaranteeing agreed

bandwidth and quality of service for all existing connections. CAC verifies

whether network (or node) is able to offer requested QoS without risking the

QoS of the existing connections.

Figure 22. Connection Admission Control (CAC)

CACSetup

ATM Network

UseaA User BCACSetupSetup

ATM Network

User A User B

Page 36: 04 Protocols Overview

Protocols in MSS/MGW

36 (99) © Nokia Networks Oy

11.1.2 Usage / Network Parameter Control (UPC/NPC)

Usage/Network Parameter Control (UPC/NPC), also known as traffic policing,

is used for monitoring the compliance of ATM end systems to agreed traffic

contracts. Traffic contract defines traffic parameters (e.g. peak cell rate) for

each connection. UPC is applied in the User-Network Interface (UNI) and NPC

is performed in the Network-Node Interface (NNI).

Figure 2. Usage Parameter Control (UPC) and Network Parameter Control (NPC)

Traffic policing is defined as a set of actions taken by the network to monitor

and control the amount of incoming ATM traffic. The main purpose is to

protect resources from misbehaviour that can affect the QoS of other already

established connections. This is done by detecting violations of negotiated

parameters and taking appropriate actions. At the ATM cell level actions may

include cell passing, cell tagging (only for CLP=0 cell stream) and cell

discarding. UPC/NPC supports the QoS objectives for all compliant

connections.

Both UPC and NPC function can be enabled or disabled for all connections at

an interface.

11.1.3 Traffic shaping

Traffic shaping is a mechanism that alters the traffic characteristics of a stream

of cells on a connection to achieve better network efficiency whilst meeting the

QoS objectives, or to ensure conformance in a subsequent interface. Traffic

shaping is performed by delaying (buffering) cells until they can be transmitted

in accordance with the traffic parameters.

Traffic shaping capability is particularly important when connecting across a

public User-Network Interface (UNI) to a public network, since many such

networks are basing their tariffs to a particular aggregate bandwidth.

An ATM network does not need to guarantee QoS performance for non-

conforming cells and thus a user wanting guaranteed QoS must shape traffic to

ensure conformance to the traffic parameters in an agreed traffic contract. A

network may employ shaping when transferring a cell flow to another network

in order to meet the conditions of a network-to-network traffic contract, or in

order to ensure that the receiving user application operates in an acceptable

way.

UPC ATM Network

NPC

NPC

UPC

UNI UNINNI

ATM Network

User A User B

UPC ATM Network

NPC

NPC

UPC

UNI UNINNI

ATM Network

User A

UPC ATM Network

NPC

NPC

UPC

UNI UNINNI

ATM Network

User A User B

Page 37: 04 Protocols Overview

Protocols

© Nokia Networks Oy

37 (99)

Shaping Policing

Shaping

Shaping

Policing Shaping

User A

Policing

Shaping

Shaping

Policing

Network A Network B User B

Figure 5. Generic placement of policing and shaping functions

Note

Traffic shaping capability is implemented in each RNC/MGW computer or

signal processing (DMCU/TCU) unit terminating/originating traffic. Traffic

originating unit provides shaping of generated ATM traffic according to

configured traffic parameters. In addition Multiplexing unit (MXU) and NIS

units shape outgoing traffic per port.

11.1.4 Priority control

Cell loss priority bit in ATM cell header can be used to generate different

priority cell flows within a virtual path or channel connection. A network

element may selectively discard cells with low priority (CLP=1) before higher

priority cell (CLP=0) in congestion situation.

11.1.5 Frame Discard

If a congested network needs to discard cells, it may be better to drop all the

cells of one Protocol Data Unit (PDU) rather than to randomly drop cells

belonging to different PDUs. If a single cell is discarded, it may cause the

retransmission of the whole PDU, which in turn may cause more traffic when

congestion is already occurring. Discarding a packet may help to avoid

congestion in the ATM network and can increase throughput.

The two most common congestion control mechanisms implemented in ATM

are:

• Partial Packet Discard If a cell is dropped from a switch buffer, the subsequent cells in the

higher layer protocol datagram are also discarded.

• Early Packet Discard When the switch buffer queues reach a threshold level, the entire higher

level datagrams are dropped.

Cell loss priority bit in ATM cell header can be used to generate different

priority cell flows within a virtual path connection or virtual channel

connection. Selective cell discard buffer management method ensures that lower

priority (CLP=1) ATM cells are dropped before higher priority CLP=0 cells in

Page 38: 04 Protocols Overview

Protocols in MSS/MGW

38 (99) © Nokia Networks Oy

congestion situation. When buffer occupancy reaches pre-configured threshold

value, buffer management starts to discard incoming lower priority CLP=1

cells.

Early Packet Discard (EPD) and Partial Packet Discard (PPD) buffer

management methods can be taken into use for VCs carrying AAL5 traffic. The

EPD threshold is evaluated before a new AAL5 frame is admitted to the buffer.

If the buffer threshold is exceeded, all cells from the AAL5 frame are discarded.

PPD occurs if a user cell is discarded because of policing violations, a cell loss

priority (CLP1 or CLP0+1) threshold violation or if no free buffer space is

available. PPD discards all remaining user cells of the AAL5 frame except for

the last cell of the frame.

11.1.5.1 Partial Packet Discard (PPD)

This congestion control mechanism drops all subsequent cells from a PDU as

soon as one cell has been dropped. Once the switch drops a cell from a PDU,

the switch continues dropping cells from the same PDU until the end of the

PDU is indicated. The last cell is not discarded, as it is required to indicate the

end of the PDU and by implication indicate the start of the next PDU.

PPD offers limited improvement, because the switch begins to drop cells only

when the buffer overflows, the first cell dropped might belong to a packet in

which the majority of cells have already been forwarded. Also, when the switch

first drops a cell, the switch does not look in the buffer for earlier cells that

belong to the same packet. Therefore, cells from the corrupt packet may be

forwarded from the switch even though PPD is in effect.

Buffer positions

for cells

PPD discards cells

When the buffer reaches thecapacity, PPD discards the theremaining cells, except the lastone.

Figure 6. Partial Packet Discard (PPD)

11.1.5.2 Early Packet Discard (EPD)

Early Packet Discard (EPD) greatly reduces the number of corrupted PDUs

transmitted, offering significant improvement over PPD. Whenever the

proportion of the buffer in use exceeds a fixed threshold, the ATM switch will

begin dropping entire PDUs prior to buffer overflow. The switch drops the first

arriving cell and all subsequent cells of that particular PDU. This will continue

until the number of cells in the buffer drops below the set threshold.

Page 39: 04 Protocols Overview

Protocols

© Nokia Networks Oy

39 (99)

EPD only discards packets, which have already been buffered.

When the buffer level exceeds theEPD threshold, the cells areselectively discarded from the entireframes

EPD Discards

Frames

Buffer positions

for cells

EPDThreshold

Figure 7. Early Packet Discard (EPD)

11.2 Traffic contract and negotiation

Traffic contract negotiated during connection establishment consists of the

connection traffic descriptor, the requested QoS class and the definition of a

compliant connection. The values of the traffic contract parameters can be

specified either explicitly or implicitly. A parameter value is explicitly specified

in the initial call establishment message. This can be accomplished via

signalling for SVCs (Switched Virtual Connections) or via the Network

Management System (NMS) for PVCs (Permanent Virtual Connections). A

parameter value is implicitly specified when its value is assigned by the network

using default rules.

11.2.1 ATM quality of service (QoS)

One of the advantages of ATM is the QoS. The ATM supports QoS guarantees

for different types of traffic. The quality of service defines the performance to

be guaranteed. There are six QoS parameters. Three of these are negotiated

between the end system and the networks.

The QoS parameters that are negotiated:

• Cell Loss Ratio (CLR)

• Cell Transfer Delay (CTD)

• Cell Delay Variation (CDV)

The QoS parameters that are not negotiated:

Page 40: 04 Protocols Overview

Protocols in MSS/MGW

40 (99) © Nokia Networks Oy

• Cell Error Ratio (CER)

• Severely Errored Cell Block Ratio (SECBR)

• Cell Misinsertion Rate (CMR)

Propagation delay dominates the fixed delay component of CTD, while queuing

behaviour contributes to delay variations in heavily loaded networks. The

effects of queue service strategy and buffer sizes dominate loss and delay

variation performance in congested networks. Transmission link error

characteristics largely determine the CER, SECBR and CMR parameters.

11.2.2 Traffic descriptors

The traffic parameters describe traffic characteristics of a source. The traffic

descriptors are the generic list of traffic parameters, which describe the traffic

characteristics of an ATM connection.

The traffic descriptor consists of:

• Peak Cell Rate (PCR)

The PCR represents the maximum allowable cell rate. It is defined as the

inverse of the minimum inter-arrival time T between two consecutive

cells. T is called the peak emission interval of the connection.

• Sustained Cell Rate (SCR)

The SCR represents a theoretical average of the cell average rate ( cell )

transmission sustained over the duration of a transmission, for a VBR

connection.

• Burst Tolerance (BT)

The BT represents the maximum time in advance allowed to transmit a

cell compared to it’s nominal transmission time: TSCR = 1 / SCR.

• The Maximum Burst Size (MBS)

The MBS specifies the maximum number of cells that can be transmitted

at PCR while still being compliant to the negotiated SCR

• Minimum Cell Rate (MCR)

The MCR represents the minimum user's required bandwidth or the

minimum cell rate guaranteed for the user. It is the descriptor used for

ABR service.

• Cell Delay Variation Tolerance (CDVT)

The CDVT gives information on the maximum time in advance allowed

for a cell arrival. It can be used with PCR and SCR.

Page 41: 04 Protocols Overview

Protocols

© Nokia Networks Oy

41 (99)

11.2.3 Definition of a compliant connection

Once the connection has been accepted, the QoS requested is provided as long

as the connection is compliant with the traffic contract.

A connection is catalogued as compliant as long as the proportion of non-

conforming cells does not exceed a certain positive threshold, the value of

which has to be specified in the traffic contract by the network operator. For

non-compliant connections, the network does not need to respect the contracted

QoS, that is, the network could release the connection. For compliant

connections, the requested QoS has always to be supported by the network.

11.3 ATM layer service categories

The traffic in ATM networks has different demands regarding the QoS. One

idea how to fulfil these requirements is to create so-called traffic classes, also

known as service categories. One service category has same kind of QoS

requirements.

Service Classes

Traffic Parameters

QoS Parameters

Service classes divide connections into"main" classes (real time, non-real time,bursty, etc.)

Traffic parameters define mainly thebandwidth requirements

QoS parameters define finally the QoS of the

connection: delay, cell loss, etc.

Figure 23. Relation between service classes, traffic parameters and QoS

ATM service categories include:

Constant Bit Rate (CBR) is used by applications that request a static amount

of bandwidth that is continuously available during the connection lifetime. This

amount of bandwidth is characterised by a peak cell rate value. In the CBR

capability, the source can emit cells at the peak cell rate at any time and for any

duration and the QoS commitments still pertain.

Page 42: 04 Protocols Overview

Protocols in MSS/MGW

42 (99) © Nokia Networks Oy

Time

Bandwidth

Figure 24. Constant bit rate (CBR)

Time

Bandwidth

Figure 25. Unspecified but rate (UBR)

Unspecified Bit Rate (UBR) is meant for non-real time applications that do not

have strict requirements for delay and delay variance. UBR does not have

guaranteed QoS and is also known as 'best effort' traffic class.

Note

CBR is equivalent to DBR (Deterministic Bit Rate), whereas VBR is equivalent

with SBR (Statistical Bit Rate). The CBR and VBR are the terms used by ATM

Forum, while the DBR and SBR are used by ITU-T.

Page 43: 04 Protocols Overview

Protocols

© Nokia Networks Oy

43 (99)

12 Resource management in ATM network

The resource management is used for reserving resources of an ATM exchange

for different purposes such as signalling, routing and IP over ATM connections

as well as for permanent cross-connections through an ATM network element.

The resource management covers the following areas:

• Management of a Physical layer Trail Termination Point (phyTTP)

• Management of ATM interfaces, related to a Physical layer Trail

Termination Point (phyTTP)

• Management of the access profiles of ATM interfaces

• Management of VP Link termination points

• Management of VC Link termination points.

The following figures illustrate the resource creation order when building

connections on VC level.

Figure 26. ATM resource creation order

The ATM resources are created on the external interfaces of a network element

and they form the basis for VP and VC level connections to other network

elements.

VC connection creation order

ATM interface

Access profiles of ATM interfaces

VPL termination point (VPLtp)

VCL termination point (VCLtp)

VC connection

phyTTP

VC connection creation order

ATM interface

Access profiles of ATM interfaces

VPL termination point (VPLtp)

VCL termination point (VCLtp)

VC connection

phyTTP

Page 44: 04 Protocols Overview

Protocols in MSS/MGW

44 (99) © Nokia Networks Oy

Figure 27. Resource management in the ATM network

12.1 Physical Layer Trail Termination Point (phyTTP)

The phyTTP is used to hide the properties of the physical resources from the

upper protocol layers. It is configured between the physical layer and the ATM

Layer. The only interesting property from the upper layer point of view is the

capacity of the phyTTP that can be used to transport the protocol data units of

the upper layer, for example ATM cells. A Physical layer Trail Termination

Point (phyTTP) can consist of one of the following: a single PET, an IMA

group, a single SDH VC path or an SDH protection group.

12.2 ATM interface

The ATM interface is an external logical interface, under which the connections

are built. The ATM interface can work as:

• UNI (User Network Interface) or

• NNI (Network Node Interface).

UNI refers to the interface between terminal equipment and a network

termination where access protocols apply. In an ATM network, the interface

between a RNC and a WCDMA BTS is seen as an UNI interface.

The NNI interface is the interface between two network nodes like a RNC and

an MGW.

When an ATM interface is created, it is tied up to a Physical layer Trail

Termination Point (phyTTP).

PhyTTP

O&M traffic (UBR, IPOAM)

Signalling traffic (CBR, MTP3SL)

User traffic (CBR, AAL2UD)

ATMlogicalinterface

1

RNC MGWATMlogicalinterface

VPLtp,

VPLtp,

VPLtp,

3

2

Access profile ofATM interface- max bandwidth- max VPI/VCI bits

- VPI- VPL service level: VP/VC- usage e.g. MTP3SL, AAL2UD, IPOAM, AAL2SL, DNBAP, CNBAP- service category: CBR/UBR- traffic parameters: PCR, CDVT, SCR, Burst tolerance- QoS class

- VCI- service category- traffic and QoS parameters

- interface id- UNI / NNI- phyTTP id

VCLtp

VCLtp

VCLtp

4

VCLtp

VPLtp,

VPLt

p,

VPLtp,

VCLtp

VCLtp

VCLtp

VCLtp

PhyTTP

- phyTTP id- PET/IMA/ SET/

PROTGROUP

O&M traffic (UBR, IPOAM)

Signalling traffic (CBR, MTP3SL)

User traffic (CBR, AAL2UD)

O&M traffic (UBR, IPOAM)

Signalling traffic (CBR, MTP3SL)

User traffic (CBR, AAL2UD)

ATMlogicalinterface

1

Ph

yT

TP

AT

M lo

gic

al in

terfa

ce

1

RNCRNC MGWMGW

VPLtp,

VPLtp,

VPLtp,

3

VPLtp,

VPLtp,

VPLtp,

VPLtp,

VPLtp,

VPLtp,

3

2

Access profile ofATM interface- max bandwidth- max VPI/VCI bits

2

Access profile ofATM interface- max bandwidth- max VPI/VCI bits

- VPI- VPL service level: VP/VC- usage e.g. MTP3SL, AAL2UD, IPOAM, AAL2SL, DNBAP, CNBAP- service category: CBR/UBR- traffic parameters: PCR, CDVT, SCR, Burst tolerance- QoS class

- VPI- VPL service level: VP/VC- usage e.g. MTP3SL, AAL2UD, IPOAM, AAL2SL, DNBAP, CNBAP- service category: CBR/UBR- traffic parameters: PCR, CDVT, SCR, Burst tolerance- QoS class

- VCI- service category- traffic and QoS parameters

- VCI- service category- traffic and QoS parameters

- interface id- UNI / NNI- phyTTP id

- interface id- UNI / NNI- phyTTP id

VCLtp

VCLtp

VCLtp

4

VCLtp

VCLtp

VCLtp

VCLtp

4

VCLtp

VPLtp,

VPLt

p,

VPLtp,

VPLtp,

VPLt

p,

VPLtp,

VCLtp

VCLtp

VCLtp

VCLtp

VCLtp

VCLtp

VCLtp

VCLtp

AT

M lo

gic

al in

terfa

ce

Ph

yT

TP

- phyTTP id- PET/IMA/ SET/

PROTGROUP

--phyTTP idPET/IMA/ SET/PROTGROUP

Page 45: 04 Protocols Overview

Protocols

© Nokia Networks Oy

45 (99)

The capacity of an ATM interface must be smaller than the capacity of the

object it is tied up to.

For further information on ATM Interface creation, refer to refer to Nokia on-

line document.

12.3 Access profile of ATM interface

The access profile created for an ATM interface defines the connection

structure built under that ATM interface. The following parameters have

to be specified :

• interface id

• the maximum ingress and egress transmission bandwidth

• the maximum ingress and egress bandwidth unit

• the maximum number of VPI bits

• the maximum number of VCI bits

Interface id

This parameter identifies the ATM interface whose access profile

you want to create. The parameter value is a decimal number

ranging from 1 to 320.The parameter is obligatory.

The maximum bandwidth values

This parameter identifies the numerical value of the maximum ingress

transmission bandwidth at the ATM interface. The parameter value is a decimal

number ranging from 10 to 9999.

The maximum allowed ingress and egress transmission bandwidth value given

for the access profile of a STM-1 interface is 149760 kbit/s, that is 353 207 c/s

(= the payload). The remaining resource (5760 kbit/s) is available only for the

physical layer overhead.

In case of an ATM interface connected to an E1 transmission link, the

maximum allowed bandwidth is 4528 c/s. In case of an ATM interface

connected to a T1 transmission link, the maximum value is 3622 c/s.

When an ATM interface is connected to an IMA group, IMA frames use a part

of the payload, as the IMA frame length is not currently modifiable. Therefore,

you can calculate the maximum allowed bandwidth for an ATM interface with

an IMA group with the following formula:

0.99 x <number of E1/T1 links> x <maximum allowed bandwidth for E1/T1>.

Page 46: 04 Protocols Overview

Protocols in MSS/MGW

46 (99) © Nokia Networks Oy

For example, if the ATM interface is tied up to an IMA group with 3*2 Mbit/s

lines, the maximum bandwidth is 0.99*3*4528 c/s = 13448 c/s.

For further information on calculating bandwidth, refer to Inverse Multiplexing

for ATM (IMA) Specification Version 1.1, ATM Forum.

The maximum ingress and egress bandwidth unit

This parameter identifies the unit of the maximum ingress/egress transmission

bandwidth at the ATM interface. The parameter can have the following values:

CPS Cells per second

KCPS Kilo-cells per second

MCPS Mega-cells per second

Note

The egress bandwidth (for outgoing traffic) cannot be defined larger than the

capacity of the neighbouring ATM exchange; otherwise ATM cells are lost.

VPI bits and VCI bits

The maximum number of VPI bits defines the space (number of bits) available

for specifying the VPLtp's under the interface. This defines the maximum

number of Virtual Paths (VPs). For example, if the space reserved for VPI is 4

bits, it means that the maximum number of VPLtp's that can be created under

the ATM interface is 16 (= 24). This parameter identifies the maximum number

of allocated bits of the VPI sub field for the defined ATM interface. The

parameter is used by the system to select the appropriate VPI values when

establishing ATM connections. The parameter value can range from 1 to 8 for a

UNI interface and from 1 to 12 for an NNI interface.

The maximum number of VCI bits defines the space (number of bits) available

for specifying VCLtp's under the interface. This defines the maximum number

of Virtual Channels (VCs) that can be created inside each virtual path. For

example, if the space reserved for VCI is 8 bits, the maximum number of

VCLtp's that can be created under a VPLtp is (= 28) - 1 = 255 (VCI with value 0

is not allowed). This parameter identifies the maximum number of allocated bits

of the VCI sub field per VPLtp of the defined ATM interface. This parameter is

used by the system to select the appropriate VCI values when establishing ATM

connections.

The parameter value can range from 1 to 14 for both UNI and NNI

interface. You should select the lowest possible value.

The VCI values 1 - 31 are reserved for specific purposes. For example, VCI 3

and VCI 4 are reserved for O&M (operation and maintenance). For this reason,

you must use VCI number 32 or bigger for an external VC connection. When

creating an access profile, you should reserve at least 6 VCI bits (= 26 different

VCI values).

Page 47: 04 Protocols Overview

Protocols

© Nokia Networks Oy

47 (99)

It depends on the network level planning how the ATM interface and its access

profile, and thus the connections, should be created. For example, there can be

many Virtual Paths with a few Virtual Channels inside each path, or only a few

large VPs with numerous VCs inside each path.

12.4 VP/VC Link termination point

External termination points are created both on VP level and VC level. They are

the terminating ends of the VP/VC connections. Virtual Path Link termination

points (VPLtp's) must be created before any Virtual Channel Link termination

points (VCLtp's) and VC level connections can be created under the VPLtp.

Each VPLtp is related to one ATM interface. The interface configuration

defines the limits to the total VPLtp capacity reservations.

The number of VCLtps created under each VPLtp depends on the total VPLtp

capacity. Therefore, when reserving capacity for a VPLtp, you should plan how

many VC level connections are needed under that VPLtp.

Termination points are reserved for:

• Signalling links on VC level

• VCC endpoints and thus for allowing the creation of AAL type 2

connections for user traffic

• IP over ATM connections on VC level

• Permanent Virtual Connections (PVCs) on VP and VC level inside an

ATM network element.

When creating a VPLtp with VC service level, you define the purpose, for

which the VPLtp and the underlying VCLtps will be used.

For further information on VP/VC link termination point, refer to Nokia on-line

document.

Service category and conformance definition

In the current ATM network, the service category CBR (Constant Bit Rate) is

applied for user plane and signalling traffic, and the service category UBR1

(Unspecified Bit Rate) is applied for IP over ATM connections. The

conformance definition must comply with the service category used. The

VCLtp's created under a certain VPLtp of UBR1 type must have the same

service category and conformance definition as that VPLtp. However, you can

create VCLtp's of UBR1 type under a VPLtp of CBR type.

Page 48: 04 Protocols Overview

Protocols in MSS/MGW

48 (99) © Nokia Networks Oy

13 Routing and digit analysis

Analysis and routing are needed in the network element for directing user plane

traffic, voice, or data connections to the desired destination and for finding free

resources for the connection. Analysis and routing also offer functions to

configure and manage the routing and analysis -related objects.

Digit analysis and routing are closely connected to each other. They function in

a call setup phase.

13.1 Digit analysis

The purpose of the digit analysis is to find a destination for the call and to select

a route to the destination.

Digit analysis analyses the digit sequences that it receives. Typically the

received sequence is an address of the receiving end, but digit analysis may be

used to analyse any number sequence that can be analysed hierarchically digit

by digit. The received digits are analysed in an analysis tree to locate the

destination for the connection. An analysis tree is a chain of records in an

analysis file beginning from the first digit of the analysed number sequence.

Each unique set of digits is associated with a destination.

Destination is comprised of one or more routing alternatives. A Subdestination

determines which ATM route is selected. A Subdestination is always mapped to

one route.

When the result of digit analysis is the route, it is the starting point of routing.

Digit analysis is used in the RNC for finding a route to a Backbone MGW or an

RNC (in Iur interface). The digit is analysed when a new connection at Nb is

needed; for example, a new call establishment or soft handover branch to the

existing call is going to be added.

Digit analysis gets the address of other network element and finds the route for

the destination by analysing the address. The address to be analysed in MGW is

the AAL2 Service Endpoint Address (A2EA) which uses AESA format. The

address points to a certain AAL2 or ATM termination point in the neighbouring

node.

13.2 Routing

Routing is used for finding free resources under a given route for connections

going to another network element.

A route can be seen as a common concept in ATM/TDM environment.

In ATM, concept of circuit groups/circuits, used in TDM, are replaced by new

concepts:

− Virtual Channel Connection Endpoint Group (VCCEG)

Page 49: 04 Protocols Overview

Protocols

© Nokia Networks Oy

49 (99)

− Virtual Channel Connection Endpoint (VCCE)

Routing manages these objects and provides selection of VPCs/VCCs according

to needed quality of service (QoS) and traffic parameters.

The VCCE identifies the VC Link termination point (VCLtp), under which the

AAL2 connection (CID) is created.

In RNC and MGW, where AAL2 level signalled connections are used, only

AAL2 level routing is used for user traffic. Routing is used for finding a

suitable Virtual Channel Connection (VCC) candidate under a given route

having free resources and providing desired properties for the connection.

Under this selected VCC an AAL type 2 connection may be created. AAL type

2 is finally the level where all user traffic is carried between the ATM network

elements.

13.3 Routing objects in ATM network

In ATM network element, where AAL type 2 level routing is used as in RNC

and MGW, the routing objects are destination, subdestination, ATM route, VCC

endpoint groups and VCC endpoints.

Destination is the result of digit analysis and it is obtained on the basis of the

call origin and received address. Destination symbolises the end node where the

connection is routed.

Subdestination is a routing alternative and it always belongs to some

destination. Subdestination provides necessary routing data that is needed in the

connection establishment phase.

Routes in this context mean external ATM routes that consist of one or more

hunted Virtual Paths (VPs) or Virtual Channels (VCs), which connect two ATM

network elements and are using the same signalling protocol.

In RNC and MGW, only AAL type 2 level routing is used for all user traffic.

The AAL type 2 connections are built inside an AAL type 2 path (VCC). VCC

extends between two Virtual Channel Connection endpoints and it is identified

with an AAL type path identifier. Therefore, ATM routes consist always of

VCC endpoints.

VCC endpoint group is a group of individual VCC endpoints having similar

properties. Under one ATM route there may be one or several endpoint groups.

When routing starts selecting a VCC for the connection, it first finds a suitable

VCC endpoint group and then selects one VCC endpoint from that group

according to the routing algorithm.

After a suitable VCC has been selected by routing, AAL type 2 connection

control selects a free AAL type 2 channel for the AAL2 type 2 connection under

this VCC.

Operations related to the AAL type 2 connections are managed by AAL type 2

connection control, which also automatically allocates a Channel Connection

Identifier (CID) value for each AAL type 2 connection.

In ATM, routing has a close relationship to Connection Admission Control

(CAC). It is different from the TDM world. In TDM, when a free circuit is

Page 50: 04 Protocols Overview

Protocols in MSS/MGW

50 (99) © Nokia Networks Oy

hunted, the resource is found for the connection. In ATM, CAC is needed after

selection of VPC/VCC. CAC decides finally if the new connection can be

accepted without violating the guaranteed quality of service for existing

connections.

The following steps show the function of the digit analysis and routing:

1. Digits are directed into digit analysis.

2. Digit analysis goes through the received digit sequence and the

information about the origin of the call in digit analysis tree in order to

find a destination for the call.

3. The destination provides the subdestination. In the Iub and Iur interfaces

each destination currently provides only one subdestination.

4. The subdestination determines which external ATM route is used for the

connection.

5. The external ATM route is used for directing the call to another

exchange. Under the ATM route the routing selects an appropriate VCC

endpoint group.

6. Under the VCC endpoint group the routing selects an appropriate VCC

endpoint and thus an appropriate virtual channel.

7. Finally, AAL2 connection control selects a free AAL type 2 channel for

making the connection.

The number of ATM routes to be created depends on the number of

neighbouring network elements and the capacity of the exchange.

Under each ATM route there can be up to 16 endpoint groups, which have the

ingress and egress service categories as characteristics. These must fit with the

values of the Virtual Channel Link termination points (VCLtp's) that will

become endpoints. Each endpoint group can include max. 50 endpoints

Page 51: 04 Protocols Overview

Protocols

© Nokia Networks Oy

51 (99)

14 IP addressing in MSS system network elements

14.1 Introduction to TCP/IP (optional topic)

Data communications involve the transmission and reception of data between

entities across different networks. An entity has the capacity to transmit and

receive data. In order for an entity to function correctly, all entities must agree

upon a protocol for successful communications.

A protocol is a set of rules defining data communications between entities.

A protocol can define many aspects of communications including what is the

nature of communications, how will the entities communicate, and when will

the communications take place. Most protocols can be represented in a layered

architecture or layered model.

Each layer performs a distinct function. It receives a Protocol Data Unit (PDU)

from the layer above it, performs some processing on it, adds a header to the

PDU, and sends the resulting PDU to the layer below it. The process of adding

headers to the PDU is called encapsulation. Sometimes if the PDU is larger

than an acceptable maximum due to technological limitations, the PDU may be

broken into smaller PDUs. This process is referred to as fragmentation.

Physical Layer

(Data) Link Layer

Network Layer

Transport Layer

Session Layer

Presentation Layer

Application Layer

2

1

3

4

5

6

7

Network Interface(layer 1 and 2 are

not specified withinthe Internet protocol suite)

Internet ProtocolARP, RARP

ICMP, IGMP

Transport (TCP, UDP)

Application

ISO OSI Model TCP/IP Protocol StackLayer

Figure 28. OSI-model vs. TCP/IP

Page 52: 04 Protocols Overview

Protocols in MSS/MGW

52 (99) © Nokia Networks Oy

The OSI model contains seven layers: Application, Presentation, Session,

Transport, Network (or Inter-network), Data link, and Physical layers. Each

layer performs a distinct function.

Because of its widespread use and relatively easy implementation, the usage of

TCP/IP protocols is, in practice, supported by every WAN and LAN technology

used today.

Today TCP/IP protocols are developed and standardised by the Internet

Engineering Task Force (www.ietf.org). IETF membership is free and there is

no subscription fee for documents.

Although TCP/IP can be mapped and explained with the classical layered OSI-

protocol model, there are some differences. There are, for example, no session

or presentation layers defined, but the functionality of these is built directly into

application layer protocols.

Most data communication uses the client - server model. In this model, a client

sends a request to a server that maybe located on another network somewhere

on the Internet. The server processes the client’s request and sends a reply to the

client. In order for the requests and replies to be understood, the client and the

server must speak the same language.

CommunicationNetwork

CommunicationNetwork

ClientClient

ServerServer

Figure 29. Client - server model interaction

14.1.1 Internet Protocol

Internet Protocol (IP) is a layer-3 protocol that is used to carry data over

different types of network. IP works in connectionless packet mode; that is, data

is transported to the destination without the establishment of a connection

between the source and the destination similar to a postal system. Each packet

will have an address for both sender and receiver, which is referred to as an IP

address. There are two types of IP address: private IP addresses and public IP

addresses. Public IP addresses are globally unique in that all IP packets in a

public network will have unique IP sender and receiver addresses.

Page 53: 04 Protocols Overview

Protocols

© Nokia Networks Oy

53 (99)

New Street Old Street

House 1 House 2 House 1 House 3

Network 1 Network 2

Host 1 Host 2 Host 1 Host 2 Host 3

Router A

Crossing A

IP Address logic

Figure 30 IP can be compared to street addressing

IP is used as the interconnection protocol in the Internet. The use of unique

addresses means that every machine connected to the Internet can send packets

to any other machine connected to the Internet, assuming this has not been

denied for security reasons. Each packet will have an address for the sender and

the receiver. Large deliveries may be divided or fragmented into several smaller

packets to help transportation. The network does not guarantee when and how

the packets will arrive. It is referred to as a best effort network.

The figure shows four different IP networks interconnected together. If Router 1

has packets that need to go to the Internet, it can send packets via Router 3 in IP

Network A or through Router 4 in IP Network B.

Router 2

Router 3

Router 1

IP Network B

Internet

IP Network A

IP Network C

Figure 31. IP network example

Page 54: 04 Protocols Overview

Protocols in MSS/MGW

54 (99) © Nokia Networks Oy

14.1.2 Internet Protocol Version 4

An IP address identifies a host on a network. The current version of IP is

IP version 4 (IPv4). The length of the IPv4 address is 32 bits. Because humans

find it difficult to write 32 binary bits, IP address are written in a dotted decimal

notation as A.B.C.D. Each number in this notation corresponds to an octet or 8

bits. Each octet has the decimal range of 0 (00000000) to 255 (11111111). For

example, the IP address for Nokia’s global web site (http://www.nokia.com) is

193.65.100.105. In this address 193 represents the most significant octet of the

IP address.

Since the range of each octet has been specified, the question now is how many

addresses are available. At the beginning of this section it was mentioned that

an IP address consists of 32 bits, and each bit has a binary representation of 0 or

1. Therefore, 232

results in 4295 million addresses (approximately). However,

not all IP addresses are available, since some are reserved for special purposes.

For instance, the IP addresses 0.0.0.0 and 255.255.255.255 are used for special

purposes. The IP address 255.255.255.255 is used for local broadcasting to all

hosts across a network.

Net ID Host ID

Figure 32 IPv4 address structure

An IP address is composed of two parts: the Network ID (Net ID) and the Host

ID. The Net ID represents the network to which the host or gateway belongs to

and the Host ID identifies the specific host within that particular network. The

Net ID always precedes the Host ID. The number of bits used to represent the

Net ID and the Host ID varies depending if class or classless IP addressing is

used. All routing functions are based on the Net ID portion of the IP address.

14.1.3 Class based IP addressing

Class based IP addressing was the original mode of allocating addresses and a

detailed description of it can be found in RFC 791. Five classes of IP addressing

were defined:

• Class A addresses were designed for very large organisations, which will

have a substantial amount of computers attached to their network.

• Class B addresses were designed for mid-size organisations having a

large amount of computers attached to their network.

• Class C addresses were designed for small size organisations, which will

have a small number of computers attached to their network.

• Class D addresses were designed for multicasting purposes.

Page 55: 04 Protocols Overview

Protocols

© Nokia Networks Oy

55 (99)

• Class E addresses are reserved by the Internet for special use. Similarly,

class E type addresses have no Net ID or Host ID.

The figure below summarises the characteristics of each class of IP addresses.

11000000 01111010 01100010 01010000

Oktet 1 Oktet 2 Oktet 3 Oktet 4

32 bits

binary format dotted decimal format

192.122.98.

0

10

110

1110

Net ID

Net ID

Net ID

Multicast

0 1 7 8 31

31

31

31

15 160 1

0 1

0 1 2

2

2

3

3 4

23 24

Class A

Class B

Class C

Class D

16777214 users/net0.0.0.1 to 126.255.255.254

65534 users/net128.0.0.1 to 191.255.255.254

254 users/net192.0.0.1 to 223.255.255.254

268435454 groups224.0.0.1 to 239.255.255.255

1111 Reserved for special use

310 1 2 3 4

Class E

Figure 33. Characteristics of class based IP addresses

Furthermore, these bits can be used to compute the number of networks

supported by each class as well as the number of hosts per network supported

by each class. This is also illustrated above. Additionally, the number of bits

can be specified for Net ID and Host ID depending on the class.

14.1.4 Classless based IP addressing

The second type of addressing is known as classless addressing. Classless

addressing was developed as one of many solutions to address the shortage of

IP addresses in the earlier class based addressing. In this scheme the Net ID is

not confined to 7, 14, or 21 bits. The Net ID can be between 2 and 31 bits and

hence there is a need to indicate the boundary between the Net ID and Host ID.

A classless IP address is represented as a.b.c.d / x. The ‘/x’ says that first x bits

of the IP address is a Net ID. In this addressing scheme, a netmask is used to

distinguish between the Net ID and Host ID bits of the IP address. A netmask

contains a series of 1s corresponding to the Net ID followed by a series of 0s

corresponding to the host ID. Examples of netmask are given below:

If IP address = a.b.c.d/24

Then netmask = 11111111.11111111.11111111.0000000 = 255.255.255.0

If IP address = a.b.c.d/23

Then netmask = 11111111.11111111.11111110.0000000 = 255.255.254.0

Page 56: 04 Protocols Overview

Protocols in MSS/MGW

56 (99) © Nokia Networks Oy

If IP address = a.b.c.d/22

Then netmask = 11111111.11111111.11111100.0000000 = 255.255.252.0

192.168.0.0192.168.0.0

255.255.255.0255.255.255.0

192.168.0.1192.168.0.1

11000000.101010000.0000000.0000000011000000.1010100.000000000.00000000

11111111.11111111.11111111.0000000011111111.11111111.11111111.00000000

11000000.10101000.00000000.0000000111000000.10101000.00000000.00000001IP Address

Netmask

Decimal Representation

Bitwise ANDing

Binary Representation

NetworkAddress

Figure 34. Bit-wise Anding of IP address and netmask

The IP address and netmask are ANDed together bit wise resulting in the binary

representation of the network address

14.1.5 Internet Protocol version 6

IPv6 is the latest version of the Internet Protocol developed by IETF. One of the

main reasons for the introduction of IPv6 is that the number of IP addresses

available with the current IPv4 is running short. The address size of IPv6 is 128

bits, which is estimated to last a lot longer than the 32 bits in IPv4.

There are also other reasons for introducing IPv6 as highlighted in RFC1883:

Expanded addressing capabilities

The increased address space of 128 bits will allow IPv6 to support more levels

of addressing hierarchy, as well as more addressable nodes and simple auto-

configuration of addresses. IPv6 also includes a new type of address, anycast

address, which is used to send a packet to any one group of nodes in a network.

Header format simplification

In contrast to the header format of IPv4, some of the header fields of IPv6 have

been discarded or made optional. This change was invoked so that the common-

case processing cost of packet handling can be reduced and limit the bandwidth

cost of IPv6 header.

Page 57: 04 Protocols Overview

Protocols

© Nokia Networks Oy

57 (99)

Improved support for extensions and options

The changes implemented in IPv6 for header options permit more efficient

forwarding. Additionally there are less stringent limits on the length of options,

this adds flexibility of further options that can be implemented in the future.

Flow labelling capability

This is a new capability feature, which allows the labelling of packets belonging

to a particular traffic flow, for which the user requests special handling. This

includes non-default quality of service or ‘real time’ service.

Authentication and privacy capabilities

IPv4 did not have any authentication and privacy capabilities. This was

compensated by the development of IPsec. IPv6 contains many features of IPsec

as well as other features to support authentication, data integrity, and data

confidentiality.

14.1.6 IP routing and routers

Any IP device that can forward IP packets (which have a destination address

other than its own) to other IP devices is called a router. The process of

selecting the best data link and next hop on the route to the right destination

network is called routing.

L1

IP

TCP/ UDP

Appli-cation

L2

L1

IP

L2

L1‘

IP

L2‘

Relay

Router

Routing is the process of selecting the next destination using a routing table.

Router• Layer 3 „switch“• decides were to transmit the IP packet next after analysis of the IP header informationdepending on data link and physical link layer, segmentation or reassembly may necessary

Figure 35. A router and its tasks

Routing can be either static or dynamic. In static routing the router will have a

fixed routing table, which includes the destination IP networks and

corresponding next hops. In dynamic routing, the routers exchange information

on the destination IP networks and corresponding next hops. This dynamic

information is exchanged via routing protocols like the OSPF (Open Shortest

Page 58: 04 Protocols Overview

Protocols in MSS/MGW

58 (99) © Nokia Networks Oy

Path First), the RIP (Routing Information Protocol), the IGRP (Interior Gateway

Routing Protocol) and the BGP (Border Gateway Protocol).

In real life it is impossible and impractical to know the route to every IP-

network in the world, so the routers and the hosts use a default gateway or

default route. If more accurate information is not known of a destination IP-

network, then the packet will be sent to the default gateway. The default

gateway/default route is typically marked with the address 0.0.0.0 / mask

0.0.0.0 -notation. A typical routing table for Router 1 is shown below.

Destination Mask Next hop Interface

192.168.0.0 255.255.255.0 Ethernet 0

192.168.1.0 255.255.255.0 Ethernet 1

192.168.2.0 255.255.255.0 192.168.0.5 Ethernet 0

0.0.0.0 0.0.0.0 192.168.1.5 Ethernet 1

192.168.1.0/24192.168.0.0/24

192.168.2.0/24

192.168.0.5/24

192.168.2.3/24192.168.1.1/24

192.168.1.5/24

Internet

192.168.0.1/24

Router 2

Router 1

Router 3

192.168.0.7/24

Ethernet 0 Ethernet 1

Figure 36. IP routers and routing table

Let us assume that a malfunction occurs in Router 3. Therefore, Router 1 has to

find an alternative path to route its packets to the Internet.

IP is a connectionless protocol and routing will be done individually for each

and every packet even if they belong to the same data transfer. Every router

between the sender and the receiver performs the routing function.

Routers are needed in IP based LAN/WAN networks to interconnect IP network

that employ similar or dissimilar lower layer (data link) protocols. An IP packet

arriving from a network using one type of data link can be easily forwarded to

the next hop network based on another type of data link. A router is needed

even if both the sender and the receiver are connected to the same physical data

link network, that is, an Ethernet segment, but they are using IP addresses from

different IP subnetworks. In this case, packets from one subnetwork to the other

will have to be sent to a router, which has an interface to both subnetworks. The

router then forwards packets between the two IP subnetworks.

Page 59: 04 Protocols Overview

Protocols

© Nokia Networks Oy

59 (99)

14.1.7 Transport protocols

Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and

SCTP are all layer-4 transport protocols. They are used to help in the end-to-end

transport of data over IP networks.

Figure 37. Peer-to-peer communication in the transport layer

Both TCP and UDP can help, for example, in segmenting user data to variable-

length IP packets and adding a sequence number to each packet. From the

sequence number the receiver knows how to reassemble the user data even if

the actual IP packets arrive in different order to that transmitted.

correct loss or corruption of data.

EthernetEthernet IPIP TCPSCTP FTP (Data)H.248 (Data) EthernetEthernet IPIP TCP FTP (Data)H.248 (Data)

FTP (Data)H.248 (Data)

Packet 1. Packet 2.

SCTP

Figure 38. IP data flow

TCP

The Transmission Control Protocol is used to provide reliable data transfer

between two IP end points. Its functionality includes sequence numbering, flow

control, packet acknowledgements, and checksum for data corruption

supervision.

IP

TCP/UDP

SCTP

Appli - cation

L1

L2

L1

IP

L2

L1‘

IP

L2‘

Relay

Router

L1

IP

L2

L1‘

IP

L2‘

Relay

Router

Router Router

IP

TCP/UDP/

SCTP

Appli -cation

L1

L2

virtual connection

Communication

Page 60: 04 Protocols Overview

Protocols in MSS/MGW

60 (99) © Nokia Networks Oy

UDP

The User Datagram Protocol is used to provide fast data transfer between two

IP endpoints. Data corruption can be checked with the use of checksum, but this

is optional. This protocol is used instead of TCP when speed is more important

than reliability, and/or upper or lower layer protocols already support reliable

data transfer functionality.

SCTP

SCTP is a reliable transport protocol operating on top of a potentially unreliable

connectionless packet service such as IP. It offers acknowledged error-free non-

duplicated transfer of datagrams (messages). Detection of data corruption, loss

of data and duplication of data is achieved by using checksums and sequence

numbers. A selective retransmission mechanism is applied to correct loss or

corruption of data.

The main difference to TCP is multi-homing and the concept of several streams

within a connection. Where in TCP a stream is referred to as a sequence of

bytes, an SCTP stream represents a sequence of messages.

SCTP can be used as the transport protocol for applications where monitoring

and detection of loss of session is required. For such applications, the SCTP

path/session failure detection mechanisms, especially the heartbeat, will actively

monitor the connectivity of the session.

14.1.8 Application protocols

There is a wide range of application layer protocols. Some of them are listed in

this section.

Telnet

This application layer protocol is used for providing virtual terminal (VT)

sessions between IP capable equipment.

HTTP

HyperText Transport Protocol is an application layer protocol used to define

web contents and its transfer.

H.248

Megaco/H.248, the Media Gateway Control Protocol, is for control of elements

in a physically decomposed multimedia gateway, which enables separation of

call control from media conversion.

SNMP

Simple Network Management Protocol is an application layer protocol used for

network management in TCP/IP networks.

FTP

File Transfer Protocol is an application layer protocol used for file transfers.

Page 61: 04 Protocols Overview

Protocols

© Nokia Networks Oy

61 (99)

ICMP

Internet Control Message Protocol is a layer 3 control protocol used to carry

error and control messages between IP nodes.

Real Time Protocol and Real Time Control Protocol

RTP provides end-to-end network transport functions suitable for applications

transmitting real-time data, such as audio, video or simulation data, over

multicast or unicast network services. RTP does not address resource

reservation and does not guarantee quality-of-service for real-time services.

The data transport is augmented by a control protocol (RTCP) to allow

monitoring of the data delivery in a manner scalable to large multicast

networks, and to provide minimal control and identification functionality. RTP

and RTCP are designed to be independent of the underlying transport and

network layers. The protocol supports the use of RTP-level translators and

mixers.

14.2 IP addresses for Release 4 Core network elements

This section gives some guidelines about how addresses are configured, and

what kind of addresses and network masks are needed in the IP backbone.

Both IP address allocation and subnets formation should be planned carefully

beforehand. A plan should cover at least the main principles for assigning

private and public IPv4 and IPv6 addresses and network masks, and the

interoperability of subnets and VLANs. It should also allow for the possible

need for subnet expansion to the maximum configuration, meaning that each

VLAN should have large enough IP address space.

Various types of traffic are transported between network elements in an MSS

site. The three main types that are relevant from the addressing point of view

are:

• O&M traffic

• Control plane traffic

• User plane traffic

O&M traffic:

O&M traffic exists in every network element. The O&M traffic is IPv4 based,

and private IP addresses can be used for the O&M related units. O&M traffic

may also include charging and statistics related information, even though

charging traffic, for example, can be separated from O&M. The O&M units are

mainly OMUs and NEMUs, but there can also be CHUs and STUs.

Control plane traffic:

The control plane is used for controlling communication between network

elements. Control plane traffic is either IPv4 or IPv6 based. Most commonly

Page 62: 04 Protocols Overview

Protocols in MSS/MGW

62 (99) © Nokia Networks Oy

public addresses are used. Examples of control plane units are the ISU in the

MGW, and the CCSU/SIGU in the MSS.

User plane traffic:

The user plane is used for carrying the actual user data. IP addresses must be

configured in TCUs and IP NIU.

Note: The decision of whether to use private or public addresses depends on the

site and backbone solution. If there are no external connections from the

backbone, all addresses can be private.

Standalone MSC Server

A standalone MSC Server has a maximum of 38 signalling units (*SU). The

unit types that may be used are CCSU, BSU and SIGU. These units are N+1

redundant.

The number of IP addresses required depends on how many of each unit are

used. Each unit has one IP address (IPv4). In cases when they are

communicating with MGW, they can also have IPv6 addresses. Additionally,

there are OMU (2N), (2N), CHU (2N) and BDCU (N+1) computer units that

need an IP address.

• The number of IP addresses needed for a standalone MSS can be large

including addresses for a public control plane containing the signalling

Units. In cases where the units are communicating with MGW, they can

also have IPv6 addresses.

Standalone Gateway Control Server

A standalone Gateway Control Server (GCS) has a maximum of 30 signalling

units (*SU). The unit type that can be used is CCSU or SIGU. The units are

N+1 redundant. The number of IP addresses required depends on how many

pieces of each unit are used. Each unit has one IP address (IPv4). In cases when

the units are communicating with MGW, they can have also IPv6 addresses.

• Additionally, there are OMU, STU, CHU (2N) and BDCU (N+1)

computer units that need an IP address.

Integrated MSC Server

• An integrated MSC Server has a maximum of 14 signalling units (*SU),

and 16 BSUs. In cases when the units are communicating with MGW,

they can also have IPv6 addresses. In addition, there are OMU (2N), STU

(2N), CHU (2N) and BDCU (N+1) computer units that need an IP

address.

Integrated Gateway Control Server

• An integrated GCS has a maximum of 33 signalling units (*SU). In cases

when the units are communicating with MGW, they can also have IPv6

addresses. In addition, there are OMU (2N), STU (2N), CHU (2N) and

BDCU (N+1) computer units that need an IP address.

Page 63: 04 Protocols Overview

Protocols

© Nokia Networks Oy

63 (99)

Multimedia Gateway for MSC Server

In a Multimedia Gateway, units that require IP addresses are TCUs, ISUs, IP-

NIU pairs, OMUs, the NEMU and LAN switches. Each TCU has four

Transcoder Processor Groups which all need separate addresses.

In total, the number of IP addresses needed for an MGW is:

• 312 public user plane IPv6/IPv4 addresses for TCUs

• 11 public control plane IPv6/IPv4 addresses for ISUs

• 2 public user plane IPv6/IPv4 addresses for IPGE/O pairs or 16 public

user plane IPv6/IPv4 addresses for IPFE pairs

• 3 IPv4 addresses for management purposes for LAN switches

• 1 private O&M IPv4 address for OMUs

• 1 private O&M IPv4 address for NEMU

Circuit Switched Data Server

In a Circuit Switched Data Server, IP addresses are required for GSU (N+1),

OMU (2N) and LAN switches. In cases when the GSU units are communicating

with MGW, they can also have IPv6 addresses.

* For more details on IP connectivity refer to the Appendix of this module

and to Nokia Site connectivity documents and courses.

14.3 IP address and stack configuration for IPv4

The IP addresses and IP stacks needed for MSC Server system network

elements are configured using network element specific MML commands. The

following sections present the parameters that need to be configured in each

network element.

14.3.1 Network interface configurations for IPv4

When configuring network interfaces for network elements, you need to specify

the following:

Unit type The type of computer unit in which you want to configure a network interface.

The program provides a list of computer units for you to choose from. This

parameter is obligatory.

Unit group The unit group number of the computer unit in which you want to configure a

network interface. The maximum value of the parameter is determined by the

number of computer unit groups (or stages). This parameter is asked for only

when it is needed, in which case it is obligatory.

Unit index The index of the computer unit in which you want to configure a network

interface. The maximum value of this parameter is determined by the number of

units. This parameter is obligatory if you want to assign a physical IP address to

Page 64: 04 Protocols Overview

Protocols in MSS/MGW

64 (99) © Nokia Networks Oy

the network interface or if you are configuring a network interface in an N+1

redundant unit. You can use && mark to specify a group of indexes to be

configured.

Interface name The name of the network interface that you want to configure. The name is from

3 to 8 characters long and must start with 'AA' (external ATM point to point

interface), 'AI' (internal ATM point to point interface), 'EL' (Ethernet interface

in DMX units), 'IFETH' and 'IFFGE' (Etherent interfaces in Chorus units), 'PPP'

(POS interface in IP-NIU units) or 'LO' (Loopback interface). You can use &&

mark to specify a group of interfaces to be configured. This parameter is

obligatory.

IP address IP address for the network interface or for the interface pair of 2N redundant

unit. The address is specified in conventional dot notation (#.#.#.#).

The range of parameters for each part of the address is from zero to 255. If you

give several computer units with && mark, then the IP address you give is the

one to start with. It is assigned to the first unit you gave. The next IP address is

created by incrementing the previous address.

IP address type The logical or physical IP address for the network interface.

Possible values are:

L = Logical IP address. This address belongs to the specified interface of the

specified functional unit. The logical IP address follows the active unit. The

logical IP address can be given to 2N and N+1 units. In N+1 units you have to

identify the unit type and unit index. In 2N units you only have to identify the

unit type of the 2N unit; the unit index is not needed.

P = Physical IP address.

This address is assigned to the specified computer unit permanently. Note that

with the physical IP address you have to identify both unit type and unit index.

Physical IP address is not allowed in IP-NIU type units.

netmask length The length of the numerical part of the IP address (in bits). The value you enter

for this parameter must be a whole number between 4 and 30. The default

length of the netmask is determined by the IP address: 8 for class A address, 16

for class B address, and 24 for class C address.

The following parameters can have the default values:

Destination IP The IP address of point-to-point link. Check that the interface really is point-to-

point type with MML command.

MTU The maximum transmittable size of a single, complete IP data unit. You can

only give MTU for some interfaces. For Ethernet interfaces the default MTU is

1500, for IP over ATM interfaces it is 9180.

State This parameter indicates the initial administrative state of the interface

immediately after configuration. If the interface is configured for the first time,

the default value is UP. If state is omitted and the network interface has been

configured before, its state does not change.

The possible values of the parameter are:

UP = the interface is in use. This is the default value.

DOWN= the interface is blocked. This is the default for point-to-point (PPP)

Page 65: 04 Protocols Overview

Protocols

© Nokia Networks Oy

65 (99)

14.4 LAN architecture in MSC Server network configuration

The basic building blocks for LAN connections are:

ESB20/ESB26: ESB26 is a 26 port 10/100BaseT/Tx Ethernet LAN switch plug-

in unit integrated into the MSCi, MSC Server, GCS and CDS mechanics.

ESA24: ESA24 is a 24 port 10/100BaseT/Tx Ethernet LAN switch plug-in unit

integrated into the MGW mechanics.

IP-NIU: IP-NIU is an IP network interface unit in the MGW. The IP-NIU for

Ethernet connectivity is implemented with IPFGE plug-in unit which offers

either 1 x 1000Base-LX/LH Ethernet + 1000Base-T Ethernet interface or 8 x

100Base-T Ethernet interfaces.

OSR 7609:OSR 7609 is a multilayer LAN switch/edge router, which is used in

the example configurations for providing in-site connectivity and the WAN

interface.

The Hot Standby Routing Protocol (HSRP) is required for redundancy purposes.

It allows a redundant router to automatically assume the function of an active

router in case the active router fails. HSRP is particularly useful when the users

on one subnet need continuous access to resources in the network.

14.4.1 MSC Server LAN

Integrated MSS control LAN

For the integrated MSS control LAN topology with duplicated multilayer LAN

switch / edge routers (OSR) and duplicated DNS servers there are several

alternative control cabinet configurations:

Each cabinet has a redundant ESB20/ESB26 pair for the control LAN. Each

signalling unit is connected to the ESB20/ESB26 pair of the same cabinet.

In the maximum configuration, the control LAN reserves 2 x 4 x 10/100Base-T

Ethernet ports in the OSR7609. If one OSR is used, redundant ESB20/ESB26

LAN switches are connected to different Ethernet line cards in the OSR. In two-

OSR configurations the redundant ESB20 LAN switches are connected to

different OSRs.

If a redundant DNS pair is used on the site, both DNS units reserve 2 ports from

each OSR7609, or 2 ports from two different Ethernet line cards in one OSR

configuration. The other port is used for DNS queries and the other one is for

O&M. The same DNS is used for the MSS, GCS, CDS and MGW.

Standalone MSS control LAN

The following figure presents the standalone MSS control LAN topology with

duplicated OSRs and DNS servers:

Page 66: 04 Protocols Overview

Protocols in MSS/MGW

66 (99) © Nokia Networks Oy

Figure 39 Control LAN topology for standalone MSC Server

Each cabinet has a redundant ESB20/ESB26 pair for the control LAN.

In the minimum configuration there is only IPCF and one IPCG0 cabinet,

whereas IPCG1, IPCG2 and IPCH cabinets are optional.

In the maximum configuration the control LAN reserves 2 x 5 x 10/100Base-T

Ethernet ports in an OSR7609. If one OSR is used, redundant ESB20 are

connected to different Ethernet line cards in the OSR. In two-OSR

configurations the redundant ESB20 are connected to different OSRs.

If a redundant DNS pair is used on the site, the both DNS units reserve 2 ports

from each OSR7609, or 2 ports from two different Ethernet line cards in a one-

OSR-configuration. One port is used for DNS queries and the other is for O&M.

The same DNS is used for the MSS, GCS, CDS and MGW. See Domain name

system in MSC Server system for more information about the recommended

DNS solutions.

14.4.2 MSC Server virtual LANs

In the OSR the control and O&M LANs can be separated into different VLANs

based on the port that the traffic comes from. The O&M LAN traffic can be

further divided into three separate VLANs in the ESB20 on a per port basis:

• O&M VLAN

• Charging VLAN

• BDCU VLAN

In the integrated MSC Server the radio network control traffic can be separated

into its own VLANs on a per port basis in the ESB20.

If necessary, some of the control plane signallings can be separated in the OSR

with help of the access lists. This separation can be done on the basis of an IP

address, TCP/UDP port number or protocol (SCTP, TCP, UDP).

Page 67: 04 Protocols Overview

Protocols

© Nokia Networks Oy

67 (99)

If the core network control plane signallings are the only user of the DNS

services, the DNS can be included in the control VLAN.

The following figure presents an example of traffic separation in MSS by using

virtual LANs:

Figure 40 MSC Server VLANs

The VLAN access lists (VACL) on the OSR are configured so that they apply

to all packets that are either routed into or out of a VLAN, or are bridged within

a VLAN.

The VACLs are only restricted for security packet filtering and redirecting

traffic to specific physical switch ports in OSR. The configuration principles are

as follows:

• The MSS/GCS control VLAN packets are either bridged or routed to the

GCS and MGW control VLANs

• The MSS/GCS O&M VLAN packets are routed to the OSS

• The charging VLAN packets are either routed to the Charging Gateway

(CG) or customer care and billing centre (CCBS)

• The BDCU VLAN packets are routed to the short message service centre

(SMSC) or to the NetAct" Traffica

• The O&M port of the DNS belongs to the O&M VLAN

If charging traffic is separated into its own VLAN in the O&M LAN, a VLAN

trunk has to be defined between the ESB20 and the OSR, since both the

charging and O&M VLANs are using the same physical interface.

Page 68: 04 Protocols Overview

Protocols in MSS/MGW

68 (99) © Nokia Networks Oy

14.5 Redundancy in MSC Server system

The MSC Server system network elements support the conventional DX200 and

IPA2800 redundancy schemes (such as 2N, N+1) in their functional units.

MGW supports MSP 1+1 protection system in its STM-1/OC-3c network

interfaces. Redundancy in the intra-site LAN is implemented as illustrated in the

following figure. MSS is shown as an example of a general way to connect a

single Ethernet interface of a network element to the OSR.

14.5.1 MSC Server LAN redundancy principles

Redundancy in CPU and ESB20

Each computer unit having a LAN interface (BDCU, BSU, CCSU, CHU, OMU,

SIGU, STU) has two functionally independent LAN interfaces. Thus each

computer unit has two separate connections to the LAN infrastructure. At any

given time, only one of the interfaces is used to carry traffic whereas the other

one is idle. Each computer unit independently makes the decision on which of

the two interfaces is active and which one is idle. The CPU LAN interfaces are

connected to different ESB20 switches. Thus, when selecting the LAN interface

the CPU simultaneously selects the ESB20 LAN switch, which it uses.

So, if the LAN cable or the LAN port in the CPU or ESB20 fails, the CPU can

perform switchover to the other interface and, at the same time, to the other

ESB20. During the switchover the IP address is retained and then the new MAC

address is advertised using a gratuitous ARP message with IPv4, and Neighbour

Discovery protocol with IPv6, after the interface switchover.

Figure 41 Redundancy in CPU LAN interfaces and ESB20

The physical layer supervision of the LAN interfaces in the CPU can only

detect failures in the link between the CPU and the ESB. Therefore the CPU

cannot make an interface changeover in cases when the link between ESB and

OSR fails. For this reason the redundant ESB20 pair can be interconnected in

order to supply a backup route to the OSR via the other ESB20. This

interconnection can be removed later if the CPU software is updated with higher

layer supervision, which can detect link failure behind an ESB.

Page 69: 04 Protocols Overview

Protocols

© Nokia Networks Oy

69 (99)

15 IP connectivity in MGW Rel.4

The IP connectivity feature provides Fast Ethernet (100Mbit/s) and 1Gbit/s

Ethernet connections for the IP backbone and IP Trunk user plane traffic. For

the control plane traffic, it provides connections for SIGTRAN and H.248

control.

IP connectivity is used for the following protocols:

• RTP/RTCP

• H.248

• SIGTRAN

IP connection also adds the routing functionality to MGW Rel.4. The routing

functionality can be used for routing user plane (RTP), H.248 and SIGTRAN to

core network routers.

As regards the benefits, the IP backbone, connectivity provides the following:

• Evolution path to All-IP Core protects the operator's investments

• Ethernet and STM-1 interfaces give flexibility to connect MGW Rel.4 to

different network environments and to build variable solutions

• IP as a common network platform provides agile network development

• Transmission cost savings

Functionality

By default (1Gbit/s Ethernet) both control plane (SIGTRAN and H.248

signalling) and user plane traffic is routed through the same unit (IP-NIU).

However, if there is a need to increase the security of the control plane traffic, it

can be isolated from the user plane traffic by using the 100Mbit/s Fast Ethernet

(FE) connection from ISU or IP-NIU.

Figure 42 Isolating control plane from IP user plane

Page 70: 04 Protocols Overview

Protocols in MSS/MGW

70 (99) © Nokia Networks Oy

When Ethernet connections are used for transporting IP traffic, the Address

Resolution Protocol (ARP) is used for IP address mapping. As regards routing,

MGW supports both IPv4 and IPv6 routing. Routing in both IPv4 and IPv6 is

based on static routing.

15.1 IP connectivity configuration of Multimedia Gateway

The MGW has various types of interfaces to ensure its connectivity in different

environments. This section describes the functionality of the following

interfaces:

• Ethernet

• STM-1 for Packet over SDH/SONET (POS)

• STM-1 for IP over ATM traffic (IPoA)

The traffic types listed above are connected from different types of IP-NIU

units. All units are configured using MML commands, but the configuration

parameters and values differ. Ethernet connections cannot be configured via

IP4S1 units.

One IP4S1 in the MGW has four STM-1 ports with VC3/VC4 mapping offering

an interface speed of 155 Mbit/s each. Note that at the moment VC3 can only be

used for IPoA, but not for POS.

Selection of the used interface is based on available backbone devices. Ethernet

connections are commonly connected to an OSR, and IPoA connections to an

MGX.

Cisco MGX switch is used as an example of an ATM switch. Cisco OSR LAN

switch / IP router is used as an example for providing the local IP connectivity.

POS connections can be connected to an OSR or an MGX.

The values of the parameters can be modified, but it is recommended that the

default values for the OSR, for example, are used.

Ethernet interface

• Gigabit Ethernet

Gigabit Ethernet interface from MGW for MSS (3GPP Rel-4) is possible with

IPGE/O type of IP-NIU.

The IP configuration is made using MML commands as described earlier in IP

address and stack configuration for IPv4 and IPv6 .

The Gigabit Ethernet interface is mainly used for user plane traffic and it is

connected directly to an OSR. With Gigabit Ethernet two types of physical

interfaces are possible: optical IPGO and electrical IPGE. The interfaces are of

the type 1000 Base-T, RJ-45 category 5, or 1000 Base-LX/LH SMF, LC

connector, MTU default 1500, No VLAN support, Encapsulation according

IEEE 802.3, Dual Stack.

• 100 Megabit Ethernet

Page 71: 04 Protocols Overview

Protocols

© Nokia Networks Oy

71 (99)

100 Megabit Ethernet interfaces can be used in two ways: there can either be

separate IP-NIU with 100Mb interfaces or internal LAN switches with 100Mb

uplinks. In case of IP-NIUs, IPFE is used. An IPFE has eight interfaces to be

used for control plane and user plane traffic.

The IPFE units are of the type 100 Base-TX, RJ-45 category 5. The rest of the

configuration parameters are the same as with the Gigabit Ethernet interface

above.

Integrated LAN switches are used when control plane traffic is taken from the

ISU-units. These LAN switches are also used for O&M traffic. The ESA12

units used for integrated ESA 12 LAN switches are 12-port 10/ 100BaseT full

duplex Ethernet switches that comply with the IEEE standards 802.3, 802.1D,

802.3X, 802.1q and 802.1p.

Their functions include full/half duplex selection, auto negotiation

(enable/disable), back pressure support in HDX mode and flow control in FDX

mode. One or two trunks can be defined (1 - 6 ports per trunk).

IP over ATM interface (IPoA)

The MGW must support some suitable connection to the operators' existing

ATM networks. The uplink traffic from the MGW is connected to the MGX

using STM-1 link(s). The IPoA functionality connects the MGW's internal units

to the external devices via IP over ATM.

Packet over SDH/SONET interface (POS)

The Packet over SDH interface of the MGW is used for transmitting user plane

traffic to an IP backbone but can also be used for transmitting signalling

protocols

(RANAP, BSSAP) and Media Control Protocol (H.248) between a MGW and a

MSC Server. The IP over SDH/SONET requires some point-to-point link layer

protocol between IP and SDH, and the point-to-point protocol (PPP) is specified

for that.

The MGW can open PPP links for example to another MGW (over the Nb

interface) and to a core network router.

The PPP over SDH/SONET uses a high-level data link control protocol

(HDLC) such as standard framing.

Packet over SDH/SONET interface is a standard interface based on RFC2615

and RFC2472 (IPv6) specifications.

15.1.1 Configuring the physical layer

The physical layer is configured with a network element specific MML

command. The same MML is used for both IPoA and POS configurations.

You need to configure the following:

SDH exchange This parameter identifies the SDH exchange terminal with a unique Numeric

Page 72: 04 Protocols Overview

Protocols in MSS/MGW

72 (99) © Nokia Networks Oy

SES BIP threshold This parameter identifies the numeric value of the SES (Severely Errored

Second) BIP (Bit Interleaved Parity check) threshold in the SDH interface.

This parameter is optional and the value can range from 1 to 8000 SDH

frames per second.

SD BER threshold This parameter identifies the numeric value of the SD (Signal Degrade) BER

(Bit Errors Ratio) threshold in the SDH interface.

SF BER threshold This parameter identifies the numeric value of the SF (Signal Fail) BER (Bit

Errors Ratio) threshold in the SDH interface.

diagnostic This parameter identifies the status of the diagnostic loopback and is used for

testing purposes. It can be used for testing internal connections.

line loopback This parameter identifies the status of the line loopback and is used for testing

purposes.

laser status This parameter is used to switch the laser power on or off. The Off option can

be used for testing purposes, or to take SET out of use.

VC mapping This parameter specifies the Virtual Container mapping on the SDH interface.

This parameter can have the following values:

VC3 = VC-3 mapping for STM-0 or 3xVC-3 mapping for STM-1

VC4 = VC-4 mapping for STM-1

SDH protocol The parameter specifies which SDH protocol is used in the SDH interface.

This parameter can have the following values:

ITU = SDH standardised by ITU

ATMML = SDH specified by NTT ATM Mega Link Service

Physical layer configuration also includes configuring SDH protection group

and defining Physical Layer Trail Termination Point configuration. These are

configured using different MMLs.

Configuring Layer 2

Layer 2 is configured using MML commands. There are different MML

commands for IPoA and POS.

For IPoA, you need to configure the following parameters (LCC/SNAP or VCMux):

interface ID This parameter identifies the ATM interface with a unique numerical value. The

value can range from 1 to 320. As a default a free ID is selected by the system.

interface type This parameter describes the type of the ATM interface. The parameter can

have the following values:

UNI = User-Network Interface is interface between the terminal equipment and

a network termination where the access protocols apply.

NNI = Network-Node Interface is the interface at a network node which is used

to interconnect with another network node. The parameter is obligatory.

PhyTTP This parameter identifies the physical resource that the interface is based on. It

Page 73: 04 Protocols Overview

Protocols

© Nokia Networks Oy

73 (99)

can range from 0 to 320. The parameter is obligatory.

administrative state This parameter describes the administrative state of the ATM interface. The

parameter can have the following values:

Locked = The resource is administratively prohibited from performing services

for its users.

Unlocked = The resource is administratively permitted to perform services for

its users. The default value is unlocked.

For POS, you need to configure the following parameters (Point-to-point protocol (PPP) configuration):

unit type This parameter identifies the computer unit type. There are two possible values:

IPS1 and IPSP.

unit index This parameter identifies the unit index for the computer unit. For IPS1, the

range of unit index is from 0 to 3.

physical trail layer The physical trail layer termination point parameter identifies a phyTTP with a

unique numerical value. It can range from 1 to 320. This parameter is unique

within the network element.

network interface This interface parameter identifies a network interface with a unique name. The

value of the parameter is PPPxx, where xx is a decimal number from 0 to 99.

This parameter is unique within the network element.

supervision interval This parameter defines the supervision interval of the PPP link. If set to 0

supervision is not used. It can range from 0 to 3600 seconds. Default value is 10

seconds.

maximum receive This parameter indicates the packet size that the peer can handle. It can range

from 128 to 16384 bytes. Default value is 1500 bytes.

PPP interface This parameter identifies the management state of the PPP interface. Allowed

values are UP and DOWN (default).

15.2 IP Backbone in Nokia MGW

Nokia Multimedia Gateway provides the possibility to use IP backbone

networks as such for transporting media for circuit-switched connections

between gateways

(Nb reference point). In All-IP mobility core networks, the IP backbone is used

to transport speech traffic between the GGSN and Multimedia Gateway

(Gi reference point). The natural choice for transmitting media over IP in

backbone connections is the IP over SDH/Sonet.

Page 74: 04 Protocols Overview

Protocols in MSS/MGW

74 (99) © Nokia Networks Oy

Media over the IP backbone is transferred using the real time protocol (RTP).

RTP provides end-to-end delivery services for data with real-time

characteristics, such as interactive audio. These services include payload type

identification, sequence numbering, time stamping and delivery monitoring.

This makes RTP an ideal protocol for real-time applications such as voice over

IP (VoIP).

The network interface unit in the Nokia Multimedia Gateway provides the

following options for transmitting media over IP:

• 1 Gigabit Ethernet interface (1000 Base-T, 1000 Base-LX; Full duplex,

auto-negotiation, flow control, MTU>1500 bytes)

• 8 Fast Ethernet interfaces (100 Base-TX; Full duplex, auto-negotiation, flow control, MTU>1500 bytes)

• STM-1 Packet over SDH/Sonet (VC-4, PPP support according RFC 1661,1662, 1669, 2615 and 2472)

• STM-1 IP over ATM (VC-4, OC-3c, according RFC 2684 LLC/SNAP)

Separating signalling from user plane

By default, both signalling (containing SIGTRAN traffic and H.248 traffic) and

user traffic are routed via the IP-NIU unit using either fast Ethernet (FE) or 1G

interfaces.

If FE interfaces are used, Multimedia Gateway provides the possibility of

assigning separate physical interfaces for signalling traffic and user plane

traffic. This is to provide better security for signalling against external attacks.

If 1G interface is used for the user plane, then there is no possibility to isolate

signalling traffic into a separate physical Ethernet interface via IP-NIU. In such

cases, the signalling can be routed directly from ISU units to layer 2 switches

located at the Multimedia Gateway cabinet, and from those switches then onto

the router and MSC Server or gateway control server.

New hardware in Nokia MGW

All hardware units from the U1.5 release are applicable as such in the same

network element. They can be utilised in another network element, as well.

The following new hardware items are provided:

• Interface unit IP-NIU for IP user plane connectivity. If IP interface for the

user plane is not needed, then this unit is not needed.

• Voice Announcement Unit (VANU). Voice announcement samples are

located and controlled via the VANU unit.

• New signalling unit type CCP10. This signalling unit is a new

manufacture with a more powerful processor compared to the previous

CCPC2-A unit in the earlier releases. CCP10 also provides a redundant

Ethernet interface and integrated IPsec support. This unit is used for all

signalling units in new deliveries. The existing CCPC2-A units in ISU

use need to be upgraded to CCP10.

Page 75: 04 Protocols Overview

Protocols

© Nokia Networks Oy

75 (99)

15.2.1 Requirements for an IP backbone connected to a MGW Rel.4

IP backbone, located between two MGW Rel.4 network elements (Nb

interface), requires the Real-time Transport Protocol (RTP) to convey user

plane traffic. The Real-time Transport Control Protocol (RTCP) can be used to

monitor the RTP stream and to collect statistical data. RTP provides end-to-end

delivery services for data with real-time characteristics (such as interactive

audio transmission), thus making it an ideal protocol for real-time applications

such as Voice over IP (VoIP).

Depending on the requirements of different network environments and variable

site solutions, IP backbone must support at least one of the following

connections:

• Fast Ethernet (100Mbit/s)

• Ethernet (1Gbit/s)

When Ethernet connections are used for transporting IP traffic, the Address

Resolution Protocol (ARP) is required for IP address mapping.

As regards routing, IP backbone must either support IPv4 or IPv6 routing. This

is because routing daemons implement different routing protocols for IPv4 and

IPv6 (IPv4 and IPv6 must also be given separate routing tables). Routing in

both IPv4 and IPv6 is based on static routing.

Page 76: 04 Protocols Overview

Protocols in MSS/MGW

76 (99) © Nokia Networks Oy

16 Configuring IP connection for IP backbone Nb user plane

The user plane traffic within the IP backbone (Nb interface) is conveyed by

using the Real-time Transport Protocol (RTP). RTP provides end-to-end

delivery services for data with real-time characteristics, such as interactive

audio. These services include payload type identification; sequence numbering,

time stamping and delivery monitoring. This makes RTP an ideal protocol for

real-time applications such as voice over IP (VoIP).

When the IP backbone is used to connect two MGW Rel.4 network elements,

there are several options available for the operator to establish the connection.

However, all of the options require a new IP network interface unit (IP-NIU).

The table below lists the available IP-NIU options.

Table 1 IP-NIU options in IP backbone

Physical interface Functional unit Physical unit

Gigabit Ethernet IPGE (electr.)

IPGEP (electr.)

IPGO (optic.)

IPGOP (optic)

IPFGE

Fast Ethernet IPFE

IPFEP

IPFGE

The key factor determining which IP backbone solution will be used is whether

the operator wants to separate the control plane traffic from the user plane

traffic.

In an IP backbone RTP and RTCP protocols are used. In each sent RTP packet,

there is 5 ms or 20 ms of coded voice as a payload, depending on the used

interface and codec. This means that 400 or 100 RTP packets with voice as

payload are sent per each RTP session (call with 2 participants) every second,

respectively. In the Nb interface with G.711 codec, the RTP packet contains 5

ms of voice. In the Multi- Access VoIP interfaces and Nb interface with some

other codec than G.711 (for example, UMTS AMR), the RTP packet contains

20 ms of voice. Every 5 seconds, two RTCP packets (one for each way) are sent

per active session for control purposes.

Page 77: 04 Protocols Overview

Protocols

© Nokia Networks Oy

77 (99)

Figure 43 User plane IP stack

IP backbone with control plane and user plane separated

If the operator decides to use control plane isolation (for security or capacity

reasons), there are two options, which enable the encryption of the control plane

traffic with a separate device.

1. When the Gigabit Ethernet physical interface is used for the user plane

traffic, IP-NIU (IPGE/IPGO) cannot be used to separate the control plane

traffic from the user plane traffic. However, it is still possible to isolate

control plane traffic by routing it directly from the ISU units into ESA12

(L2 switch). The new signalling unit CCP10 provides redundant LAN

interface for this purpose. The figure below illustrates the ESA12

solution.

Figure 44 IP backbone with Gigabit Ethernet (control plane and user plane separated)

Page 78: 04 Protocols Overview

Protocols in MSS/MGW

78 (99) © Nokia Networks Oy

2. When the Fast Ethernet physical interface is used, IP-NIU can be used to

separate the control plane traffic from the user plane traffic. The 2N

redundant IP-NIU has 8 Fast Ethernet interfaces, of which one or several

interfaces can be exclusively dedicated to the control plane, thus

providing a separate LAN for control plane traffic. The remaining

interfaces can be dedicated to user plane traffic.

Note

The Nb interface can be created using ATM backbone, IP backbone or TDM

backbone. However, it is also possible to utilise more than one backbone

solution simultaneously.

16.1.1 IP connection with IP backbone for Nb user plane configuration steps in MGW Rel.4

The IP connection for Nb user plane traffic between MGW Rel.4 and the IP

backbone must be configured during integration. User plane traffic is

transported through the IPFE/IPFEP/IPGE/IPGEP/IPGO/IPGOP unit.

1. Configure the IP stack of the TCU unit

Configure the IP stack of the TPG units in TCU. Assign physical IP address for

the IP interface AI0 of the TPG units and give the IP address of the IFETH0

interface of the IP-NIU as the destination IP address. Then create the default

static route between the TPG units and the IP-NIU.

2. Configure internal connections for IP-NIU

Configure the IPFE/IPFEP/IPGE/IPGEP/IPGO/IPGOP unit.

3. Configure the external connection

Configure external connection through IP-NIU.

The following figure shows how to configure internal IP interfaces between

TCU units and IPFEP units, and how to connect the IPFE unit to an external

router via Ethernet connections. The AI interfaces of the IPFGE unit have the

same IP address as the Ethernet interface, only the type of the interface is

unnumbered.

The example shows how to configure internal IP over ATM interfaces

between TCU (TPG) units and the IPFEP unit.

The IPFEP-1 unit is the spare unit for the IPFEP-0 unit. In switchover the spare

unit inherits the logical IP addresses from the active unit, so the addresses are

only configured in the active unit. After configuring the internal IP interfaces,

you need to configure the external connections.

Configure a logical IP address for the Ethernet interface of IPFEP.

1. ZQRN:IPFEP,0:IFETH0:192.160.1.5;

Note

Before attempting to configure an IP address to the interface, the external

Ethernet cables should be attached to a router unit. If there is failure to the

connection, it will cause a 2-star recovery initiating alarm on the IPFGE unit.

Page 79: 04 Protocols Overview

Protocols

© Nokia Networks Oy

79 (99)

Configure the same logical IP address for the ATM interfaces of IPFEP. Note

that you do not need to specify the destination address, because Inverse ATM

Address Resolution Protocol (InATMARP) is used in the IP over ATM

interfaces between TPG and IPFEP.

2. ZQRN:IPFEP,0:AI0&&AI7,U:192.160.1.5;

Note

The external IP interface addresses must be configured in different subnets.

Configure physical IP addresses for the ATM interfaces of TPG units. The

destination IP address is the logical IP address of IPFEP.

3. ZQRN:TPG,0&&7:AI0:196.160.2.1,P,::192.160.1.5;

Create the default routes from TPG units to the IPFEP unit.

4. ZQKC:TPG,0&&7::192.160.1.5;

Example: Configuring Ethernet interfaces between IPFEP units and an

external router

Interrogate the state of the units.

5. ZUSI:IPFEP;

Create the Ethernet interfaces for the IPFEP unit.

6. ZQRN:IPFEP,0:IFFGE0:10.0.0.2:29;

ZQRN:IPFEP,0:IFFGE1:10.0.0.10:29;

ZQRN:IPFEP,0:IFFGE2:10.0.0.18:29;

Create static routes from IPFEP to the external router.

7. ZQKC:IPFEP,0::10.0.0.1:LOG;

ZQKC:IPFEP,0::10.0.0.9:LOG;

ZQKC:IPFEP,0::10.0.0.17:LOG;

Page 80: 04 Protocols Overview

Protocols in MSS/MGW

80 (99) © Nokia Networks Oy

Figure 45 Nb over IP in MGW

Page 81: 04 Protocols Overview

Protocols

© Nokia Networks Oy

81 (99)

17 TDM Backbone (optional topic)

The Nokia MGW provides an interconnection between legacy SS7 TDM

networks and packet/cell -based networks. Signalling from MGW towards

TDM-based networks is handled using SS7 standards. The primary physical

interfaces used between legacy SS7 TDM networks and packet/cell -based

networks are E1/T1/J1 and STM-1/OC3.

TDM is used in the A-interface for transporting speech, data and SS7-based

signalling between MGW/MSC Server and the BSS. The A-interface is

connected either to MGW or to MSC Server depending on the needs of the

operator. The user plane traffic (speech and data) is always routed via MGW to

the TDM/ATM/IP backbone, while the control plane traffic (BSSAP signalling)

is routed either directly to MSC Server or transparently via MGW to MSC

Server.

17.1 TDM backbone in Nokia MGW

The Nokia Multimedia Gateway can be easily adapted to the existing mobile

environment by using the existing TDM-based transmission network also in the

Nb interface. If the existing transmission network is cost-effective, and if there

are no other reasons (such as need for more capacity) for changing the

transmission network type, it does not hinder taking the bearer independent

network architecture into use.

Upgrading to the MSS system inevitably requires changes in the network

because the control plane and user plane traffic are separated. The TDM

backbone enables reducing the number of simultaneous changes when

upgrading the network. In this way the MSS system deployment can be divided

into several easily controllable phases, thus lowering, for example, schedule risk

in the network installation phase.

Changing the backbone to a packet-based one for reaching all benefits from

bearer independent network architecture can then be scheduled to a later phase

according to operator-specific plans.

The physical interface towards other TDM networks is E1/T1/JT1.

Alternatively, STM-1 VC-12 (OC-3 V51.5 SPE) is provided for environments

where large interconnect points are desired. STM-1 VC-12 allows connecting of

63 E1 interfaces (or alternatively 84 T1 interfaces) over a single fiber.

To create the Nb over TDM routing objects for TDM resources controlled by

MSC server must be created in the MSS. In the MGW the procedure necessary

is to create a CGR.

1. Create a special circuit group (SPE CGR) with the USE parameter (ZRCC)

2. Add TDM circuits to the SPE CGR (ZRCA)

3. Change the state of the circuit group to WO-EX (ZCIM)

4. Change the state of the circuits to WO-EX (ZCIM)

Page 82: 04 Protocols Overview

Protocols in MSS/MGW

82 (99) © Nokia Networks Oy

18 SIGTRAN

Signaling Transport SIGTRAN is a Working Group in IETF, primary purpose

of this working group is to address the transport of packet-based PSTN

signaling over IP Networks, taking into account functional and performance

requirements of the PSTN signaling. SIGTRAN defines a framework how

different existing signalling protocols can be transferred over IP, like Q.921

(PBX) , ISUP and SCCP.

IETF has standardized various ways for adapting SS7 signalling messages on

the IP network. They include M3UA (SS7 MTP3-User Adaptation Layer) and

SUA (SS7 SCCP-User Adaptation Layer). Nokia implements the MTP layer 3

of the M3UA adaptation with feature 50035 and SCTP ((Stream Control

Transmission Protocol) protocol used for adapting SS7 messages to the IP

connections by the feature 50037.

Figure 46 SIGTRAN protocol stack options

The SIGTRAN M3UA (SS7 MTP3-User Adaptation Layer) provides the

applications with the same services as the MTP3 in the SCN (Switched Circuit

Network). It routes the MTP layer 3 messages from the applications to the

correct IP resources (SCTP associations). The M3UA supports the transfer of

the messages of any protocol layer that is identified to the MTP Level 3 layer as

a user part . The list of these protocols include for example the following: ISUP

(ISDN User Part), TUP (Telephone User Part), and SCCP (Signalling

Connection Control Part). The TCAP or RANAP messages are transferred

transparently by the M3UA as SCCP payload, as they are SCCP-User

protocols.)

The M3UA signalling channels always lead to a SEP (Signalling End Point)

network element. The STP (Signalling Transfer Point) function between SCN-

IP and IP-IP networks is supported when both networks share a SPC (Signalling

Point Code). Most of the SS7 signalling functionality remains identical to the

existing SCN (Switched Circuit Network) signalling. The SIGTRAN feature

affects only the transport layer of the SS7 signalling: It provides a new

adaptation layer designed to fit the MTP layer 3 messages on the IP network.

For this reason some of the existing concepts have been redefined. When the IP

IP IP

SCTP SCTP

M3UA SUA

SCCP TCAP

TCAP MAP

MAPSS7 MTP3 – User Adaption layer

SS7 SCCP – User Adaption layer

Page 83: 04 Protocols Overview

Protocols

© Nokia Networks Oy

83 (99)

is used as transport media, the concept signalling channel refers to a logical

resource instead of a physical resource (PCM-TSL). The SIGTRAN M3UA

signalling channel acts as a link to the logical SCTP association set which leads

to the next network element. An SCTP association set consists of a group of

SCTP associations, each of which is an IP resource allocation. The concepts

signalling link set and signalling route set remain as defined by the ITU-T.

SIGTRAN can be used between a Signalling Gateway (SG) and a Media

Gateway Controller (MGC) or between any other exchanges like an MSC and a

HLR.

DX200

Association Set (up to 16 associations)

SCTP Association

Signalling point B

IP

Signalling point A

MSC (Server) HLR (Client)

CCSU_0

CCSU_1

CCSU_2

CM

SPC_1

CCSU_0

CCSU_1

CCSU_2

CM

IP Addresses SPC_2

Addressing based on SPCs!

Figure 47 Associations

18.1 Stream Control Transmission Protocol

SCTP is a reliable transport protocol operating on top of a potentially unreliable

connectionless packet service such as IP. It offers acknowledged error-free non-

duplicated transfer of datagrams (messages). Detection of data corruption, loss

of data and duplication of data is achieved by using checksums and sequence

numbers. A selective retransmission mechanism is applied to correct loss or

corruption of data.

The decisive difference to TCP is multhoming and the concept of several

streams within a connection which are referred to as associations. Where in

TCP a stream is referred to as a sequence of bytes, an SCTP stream represents a

sequence of messages.

Page 84: 04 Protocols Overview

Protocols in MSS/MGW

84 (99) © Nokia Networks Oy

19 Overview H.248

Megaco is a new protocol developed by IETF Megaco Working Group together

with ITU-T Study Group 16 to be the standard for physically decomposed

multimedia gateway structures. References for Megaco are available in RFC

2805 (requirements) and RFC 3015, which have been replaced by RFC3525 in

June, 2003. The protocol is specified by IETF as Megaco and by ITU-T as

H.248, the latest one is H.248.1, version 2, in May, 2002.

Megaco addresses the relationship between Media Gateways (MG) and Media

Gateway Controllers (MGC). (See Figure1) This relationship has a master/slave

structure, where masters are MGCs and slave devices are MGs, which execute

commands sent by master devices.

Megaco is a one to one protocol, where each MG is controlled by only one

MGC.

Media Gateway (MG): The media gateway converts media provided in one type

of network to the format required in another type of network. For example, a

MG could terminate bearer channels from a switched circuit network and media

streams from a packet network.

Media Gateway Controller (MGC): Controls the parts of the call state that

pertain to connection control for media channels in a MG.

19.1 H.248

Megaco/H.248 addresses the relationship between the Media Gateway, which

converts circuit-switched voice to packet-based traffic, and the Media Gateway

Controller which dictates the service logic of that traffic. Megaco/H.248

instructs a MGW to connect streams coming from outside a packet or cell data

network onto a packet or cell stream such as the Real-Time Transport Protocol

(RTP).

There are two basic components in Megaco/H.248: terminations and contexts.

Terminations represent streams entering or leaving the MGW (for example,

analogue telephone lines, RTP streams, or MP3 streams). Terminations have

properties, such as the maximum size of a jitter buffer, which can be inspected

and modified by the MSS.

Terminations may be placed into contexts, which are defined as when two or

more termination streams are mixed and connected together. Contexts are

created and released by the MGW under command of the MSS. A context is

created by adding the first termination, and it is released by removing

(subtracting) the last termination.

A termination may have more than one stream, and therefore a context may be a

multi-stream context. Audio, video, and data streams may exist in a context

among several terminations

For transport of the protocol over IP, MSS and MGW shall implement both

TCP and UDP. For pure IP connections, H.248/SCTP/IP should be used. The

MGW is provisioned with a name or address (such as DNS name or IP address)

Page 85: 04 Protocols Overview

Protocols

© Nokia Networks Oy

85 (99)

of a primary and zero or more secondary MSS that is the address the MGW uses

to send messages to the MSS.

Ta Tb

terminations

MGW

context C

User data

User dataSCTP TCP

IPv4 or IPv6

H.248

L1

Protocol stack

Figure 48 H.248

19.1.1 Message structure

Megaco commands sent to the media gateway are grouped into an entity called

transaction. A transaction on the other hand contains actions, and actions

contain a list of commands. Each action applies only to one context. The reason

to have transactions is that transactions guarantee ordered command processing.

All commands within the same actions will be executed sequentially in the

order described in the transaction. Transaction on the other hand can be

executed in any order. Several transactions can be later concatenated into a

message. Such transactions remain independent though and no order is implied

by such a concatenation. A message is essentially a transport mechanism

19.2 BICC

The Bearer Independent Call Control Protocol (BICC, ITU-T Q.1902) is a call

control protocol designed to be able to transport call control signalling

information, independent of the used bearer technology and signalling message

transport technology. BICC accomplishes this by defining a set of procedures

separately for call control signalling and bearer control signalling. The actual

call control level signalling uses BICC, which is based on ISUP, and allows

different protocols, such as AAL2 signalling, to be used for bearer control

signalling. Signalling message transport independence means that BICC

signalling can be transported over several different signalling transports such as

MTP3, SSCOPMCE or SIGTRAN. Bearer independence means that the actual

used media can thus be ATM, IP/Ethernet or something else. Since BICC is

based on ISUP it provides natural interworking with ISUP and BICC networks

and allows the existing supplementary services to be used without

modifications.

The BICC protocol is an adaptation of the ISUP protocol definition, but it is not

peer-to-peer compatible with ISUP (see ITU-T Q.1912.1).

Page 86: 04 Protocols Overview

Protocols in MSS/MGW

86 (99) © Nokia Networks Oy

In the MSS concept the User Plane (bearer) and the Control Plane (signalling

and call control) have been separated. There is a new Network Element (NE),

Media Gateway (MGW), which takes care of the User Plane and the MSS

controls it. MGW is the based on ATM HW and IPA2800 platform. It brings

new media and functions which must be taken into account in call control

signalling. For that reason Bearer Association Transport Application Service

Element/Application Transport Mechanism (APM/BAT ASE) has been

introduced in BICC. Its main task is to transfer the bearer-specific information

between the two MSSs on a Control Plane level.

Nokia implements BICC with feature 1330. This feature implements the BICC

CS2 signalling through the IP network between the two MSSs according to

ITU-T Draft Recommendations Q.1902.X /1/, /2/, /3/, /4/ specifications. This

includes the following:

• Call and bearer establishment over ATM AAL1, AAL2 and IP

• Codec negotiation procedure

• Codec modify procedure

• Out of band transport of DTMFs

• APM/BAT ASE functionality

The vertical interface MGW-MSS (Mc in 3GPP) uses H.248 to convey the

bearer-related information. The needed bearer-information is transferred

between MSSs in BICC through APM-mechanism.

MSC ServerMSC ServerMSC ServerMSC Server

MGWMGWMGWMGW

IAMIAM

Bearer cntr Bearer cntr

MGW addressMGW address

Figure 49 BICC IAM

Nb interface is backbone interface. It can be IP or ATM. For both IP and ATM

backbone interface, BICC can be used on Nc interface.

Depending up on backbone, different bearer establishment methods are possible

between MGWs. For IP backbone, bearer control signalling is encapsulated

(tunneled) in BICC. Following methods are used for IP backbone.

• Fast Forward setup

• Delayed Forward setup

• Backward setup

Page 87: 04 Protocols Overview

Protocols

© Nokia Networks Oy

87 (99)

In case of ATM backbone, bearer control signalling is AAL type 2 signalling

between MGWs. For ATM backbone, following bearer establishment methods

are used.

• Forward bearer set up

• Backward bearer set up

Origination node always selects the bearer establishment method as well as used

bearer network connection characteristics

19.3 Applying protocol stacks

The various interfaces can be configured in many ways. An example is provided

below.

BackboneBackboneBackboneBackbone

MSC ServerMSC ServerMSC ServerMSC Server

RNCRNCRNCRNCMGWMGWMGWMGW

MGWMGWMGWMGW

RANAPRANAPRANAPRANAP

SCCP

AAL5

ATM

Phy

BSSAPBSSAPBSSAPBSSAP

SCCPBSCBSCBSCBSC

MTP

MSC ServerMSC ServerMSC ServerMSC Server

PSTNPSTNPSTNPSTN

MTP3b

RANAPRANAPRANAPRANAP

SCCP

BSSAPBSSAPBSSAPBSSAP

M3UA

SCTP

IP

AAL5

ATM

Phy

MTP3b

M3UA

SCTP

IPSCCP

MTP

ISUPISUPISUPISUPH.248H.248H.248H.248

M3UA

SCTP

IP

H.248H.248H.248H.248

SCTP

IP

BICCBICCBICCBICC

M3UA

BICCBICCBICCBICC

MTP

MGWMGWMGWMGW

Figure 50 Creating protocols stacks

Page 88: 04 Protocols Overview

Protocols in MSS/MGW

88 (99) © Nokia Networks Oy

20 User plane routing

MSC Server (MSS) can be deployed in an operator's 2G network by integrating

the MSS functionality into an existing MSCi, or as a standalone network

element. The MSC functionality is split into two distinct logical entities. The

MSS handles call control and controls Multimedia Gateways (MGW). The

MGW, on the other hand, handles user plane traffic.

The following figure illustrates the network architecture. Separating the control

plane from the user plane makes it easier for the operator to configure the

network in one MSC server area.

Figure 51 MSS Routing in Rel’99 & Rel4

The MSS handles the following types of resources:

• Time Division Multiplex (TDM) resources. There are two types of

TDMs, that is, Local TDMs, connected to the MSS and Quasi TDMs,

connected to the MGW.

• Asynchronous Transfer Mode (ATM) resources

• Internet Protocol (IP) resources

MSCi MSCi MSCi MSCi MSCi MSCi MSCi MSCi

Rel’99Rel’99

A'A'

Iu-CSIu-CS

MSS MSS MSS MSS MSS MSS MSS MSS

Rel 4Rel 4

Packet basedBackbone (IP/ATM)& TDM based PSTN

Packet basedBackbone (IP/ATM)& TDM based PSTN

TDM basedBackbone & PSTNTDM basedBackbone & PSTN

AA

A & IuA & IuA & IuA & Iu----CSCSCSCSA & IuA & IuA & IuA & Iu----CSCSCSCS

H.248/MegacoSigtran

Page 89: 04 Protocols Overview
Page 90: 04 Protocols Overview

Protocols in MSS/MGW

90 (99) © Nokia Networks Oy

20.1 Control and user plane routing

In UMTS Rel.4, the control plane and user plane routing functions have been

separated. The control plane routing closely corresponds to the traditional NSS

routing and analysis functions.

A new attribute (BNC characteristic) is introduced which can be used to affect

the control plane analysis with the help of routing, charging and EOS attribute

analyses, and extended pre-analysis. A new result parameter in the control plane

routing, User Plane Destination Reference (UPDR) is added to provide input to

the user plane routing functions and analyses. UPDR is defined on the circuit

group or route level.User Plane Routing Structure

MGW selection functionality in MSC Server must be able to make user plane

routing decisions for many different call scenarios. To enable the user plane

control there are defined six different phases of user plane analysis and two

databases.

UPD: Refers to one or more MGW sharing a common interconnection type

IP/ATMBackbone

MSS B MSS B MSS AMSS A

GSM

WCDMA

Mc Mc

MGWMGW MGW

BSCBSC

A

RNCRNC

BICC CGR

ROUTE

MSS BA Circuit Group is related to

incoming traffic. A PUPD indicatesPreceding User Plane Destination(PUPD)

BSCBSC

A

RNCRNC

Iu-CS

UPD 10 UPD 20

MSS AA route is related to outgoing traffic. A SUPDR indicatesSucceeding User Plane Destination(SUPD)

Iu-CS

Topology database•UPD:s•Interconnections

UPD: Refers to one or more MGW sharing a common interconnection type

Figure 52 Overview of user plane entities

Page 91: 04 Protocols Overview

Error! Reference source not found.

© Nokia Networks Oy

91 (99)

The user plane routing and analysis consists of several entities connecting user

plane and control plane. The ultimate purpose of user plane routing and analysis

is to select MGWs and route user plane traffic.

The Multimedia Gateway (MGW) database is a common storage place in the

MSC Server (MSS) for MGW-specific parameters that are used for user plane

routing purposes. The user plane topology database contains user plane

topology information. The user plane control application uses topology data to

route the user plane to the proper destination.

A User Plane Destination (UPD) defines one or several MGWs controlled by

one MSS. In a UPD the MGWs share the same kind of interconnection type.

In the MSS routes are related to Succeeding User Plane References (SUPDR)

and BICC/SIP circuit groups to Preceding User Plane Destination References.

This creates a logical chain where analysis can be used to determine a route for

an outgoing call; this will lead to a SUPDR, which in turn is related to SUPD

ultimately leading to MGW selection. The same kind of logical chain can be

described for incoming calls where the analysis determines a circuit group,

which is related to PUPDR, which leads to a PUPD finally resulting in MGW

selection.

20.2 User Plane Analysis

One part of the user plane routing configuration is User Plane Analysis. It

consists several analysis chains, which are itemized by phase names. The

operator can define the relationship of parameters (call's and network's) and

analysis phases by User Plane Analysis' MML.

User Plane Analysis and its components are created by using UANHAN MML.

The analysis consists several sub analysis, which can be linked to chains and the

different kind of results.

20.2.1 Phases

The different phase of User Plane Analysis have relationship to each other. The

result of an analysis can be the input parameter for the next phase. All phases

are not executed for each call case. The analysis chain is variable depending on

the call setup case.

Page 92: 04 Protocols Overview

Protocols in MSS/MGW

92 (99) © Nokia Networks Oy

4. Succeeding UPD determination

1. Preceeding UPD determination

2. Succeeding BNC Characteristicsdetermination

3. CMN determination

5. Succeeding Action indicatordetermination

6. Inter-Connecting BNC

Characteristics determination

Figure 53 User Plane Analysis’s' relationship

The different analysis types are executed in certain combinations depending on

the call case. In some cases only one analysis may be needed and in other

several. An example is the case of 3G call to 3G call under the same MSS but

two different MGW where only analysis number 6. Inter-connecting BNC

characteristics would be executed to determine the backbone type. More

complex cases can be constructed based on the analysis table.

1,2,3,4,6*1,2,4,5,6*1,6*1,6*1,6*SIP

1,2,4,6*1,2,3,4,5,6*1,6*1,6*1,6*BICC

2,4,6*2,4,5,6*6*6*6*TRUNK

2,4,6*2,4,5,6*6*6*6*MS

2,4,6*2,4,5,6*6*6*6*UE

SIPBICCTRUNKMSUE

Outgoing SignalingIn

com

ing S

ignalin

g

Figure 54 Analysis combination table

1. Preceding UPD determination (incoming side)

2. Succeeding BNC characteristics determination (outgoing side)

3. CMN determination (general)

4. Succeeding UPD determination (outgoing side)

Page 93: 04 Protocols Overview

Error! Reference source not found.

© Nokia Networks Oy

93 (99)

5. Succeeding Action Indicator determination (outgoing side)

6. Interconnecting BNC characteristics determination (general) (*executed

only if more than one MGW is involved in the call in the same MSS area)

• Phase Preceding UPD determination

This Phase is needed only for BICC and SIP signallings. RANAP signalling

is able to determine the appropriate UPD for a call.

• Phase Succeeding BNC Characteristics determination

This Phase is needed to determine the bearer technology used towards

succeeding MGW. This Phase is valid with BICC and SIP signalling.

• Phase CMN determination

This Phase is used to detect whether a MSC Server should act as a CMN node.

Pre-condition for this analysis execution is that Phase Succeeding BNC

Characteristics determination has been executed.

• Phase Succeeding UPD determination

This Phase is needed only for BICC and SIP signallings. RANAP signalling is

able to determine the appropriate UPD for a call.

• Phase Succeeding Action indicator determination

• Phase Inter-Connecting BNC Characteristics determination

Page 94: 04 Protocols Overview

Protocols in MSS/MGW

94 (99) © Nokia Networks Oy

Page 95: 04 Protocols Overview

Error! Reference source not found.

© Nokia Networks Oy

95 (99)

21 Appendix (for reference only)

21.1 Further note on the number and types of IP addresses for network elements

This section concentrates on network element specific information, such as how

many addresses are needed in each element. Note that in the case of 2N

redundant units logical IP addresses are used and only one address per CPU pair

is needed.

Note

The numbers given in this section are indicative whereas the actual address

allocation should always be based on the latest information on the number of

units in each network element. The latest details can be checked from the

network element engineering descriptions that are included in network element

specific documentation.

Standalone MSC Server

A standalone MSC Server has a maximum of 38 signalling units (*SU). The

unit types that may be used are CCSU, BSU and SIGU. These units are N+1

redundant.

The number of IP addresses required depends on how many of each unit are

used. Each unit has one IP address (IPv4). In cases when they are

communicating with MGW, they can also have IPv6 addresses. Additionally,

there are 1+1 x OMU (2N), 1+1 x STU (2N), 3+3 x CHU (2N) and 3 x BDCU

(N+1) computer units that need an IP address.

The maximum number of LAN switches is 12.

In total, the number of IP addresses needed for a standalone MSS is:

• 38 public control plane IPv4 addresses for the *SUs

In cases where the units are communicating with MGW, they can also have

IPv6 addresses.

• 7 private O&M IPv4 addresses for CPUs

• 12 IPv4 addresses for management purposes for LAN switches.

Standalone Gateway Control Server

A standalone Gateway Control Server (GCS) has a maximum of 30 signalling

units (*SU). The unit type that can be used is CCSU or SIGU. The units are

Page 96: 04 Protocols Overview

Protocols in MSS/MGW

96 (99) © Nokia Networks Oy

N+1 redundant. The number of IP addresses required depends on how many

pieces of each unit are used. Each unit has one IP address (IPv4). In cases when

the units are communicating with MGW, they can have also IPv6 addresses.

Additionally, there are 1+1 x OMU, 1+1 x STU, 3+3 x CHU (2N) and 3 x

BDCU (N+1) computer units that need an IP address.

The maximum number of LAN switches is 10.

In total, the number of IP addresses needed for a standalone GCS is:

• 30 public control plane IPv4 addresses for the *SUs

• 7 private O&M IPv4 addresses for CPUs

• 10 IPv4 addresses for management purposes for LAN switches

Integrated MSC Server

An integrated MSC Server has a maximum of 14 signalling units (*SU), and 16

BSUs. In cases when the units are communicating with MGW, they can also

have IPv6 addresses.

In addition, there are 1+1 x OMU (2N), 1+1 x STU (2N), 3+3 x CHU (2N) and

3 x BDCU (N+1) computer units that need an IP address.

The maximum number of LAN switches is 10.

In total, the number of IP addresses needed for an integrated MSS is:

• 30 public control plane IPv4 addresses for the *SUs

• 7 private O&M IPv4 addresses for CPUs

• 10 IPv4 addresses for management purposes for LAN switches.

If the integrated MSC Server includes the IP Trunk functionality, additional

addresses are needed for the IPET units and additional LAN switches. Each

IPET unit requires one IP address. The theoretical maximum number of IPET

units is 456, but in practice the maximum number is 304. The maximum

number of LAN switches is 44.

In total, the number of additional IP addresses needed for an integrated MSS

with IP Trunk functionality is:

• 304 public IP addresses for IPETs

• 44 IPv4 addresses for management purposes for LAN switches.

Integrated Gateway Control Server

An integrated GCS has a maximum of 33 signalling units (*SU). In cases when

the units are communicating with MGW, they can also have IPv6 addresses. In

addition, there are 1+1 x OMU (2N), 1+1 x STU (2N), 3+3 x CHU (2N) and 5 x

BDCU (N+1) computer units that need an IP address. The maximum number of

LAN switches is 10.

In total, the number of IP addresses needed for an integrated GCS is:

Page 97: 04 Protocols Overview

Error! Reference source not found.

© Nokia Networks Oy

97 (99)

• 33 public control plane IPv4 addresses for the *SUs

• 10 private O&M IPv4 addresses for CPUs

If the integrated GCS includes the IP Trunk functionality, additional addresses

are needed for the IPET units and additional LAN switches. Each IPET unit

requires one IP address. The theoretical maximum number of IPET units is 456,

but in practice the maximum number is 304. The maximum number of LAN

switches is 44.

In total, the number of additional IP addresses needed for an integrated GCS

with IP Trunk functionality is:

• 304 public IP addresses for IPETs

• 44 IPv4 addresses for management purposes for LAN switches.

Multimedia Gateway for MSC Server

In a Multimedia Gateway, units that require IP addresses are TCUs, ISUs, IP-

NIU pairs, OMUs, the NEMU and LAN switches. Each TCU has four PQ2

processors which all need separate addresses.

In total, the number of IP addresses needed for an MGW is:

• 312 public user plane IPv6/IPv4 addresses for TCUs

• 11 public control plane IPv6/IPv4 addresses for ISUs

• 2 public user plane IPv6/IPv4 addresses for IPGE/O pairs or 16 public

user plane IPv6/IPv4 addresses for IPFE pairs

• 3 IPv4 addresses for management purposes for LAN switches

• 1 private O&M IPv4 address for OMUs

• 1 private O&M IPv4 address for NEMU

Circuit Switched Data Server

In a Circuit Switched Data Server, IP addresses are required for 3 x GSU (N+1),

1 +1 OMU (2N) and LAN switches. In cases when the GSU units are

communicating with MGW, they can also have IPv6 addresses.

In total, the number of IP addresses needed for a CDS is:

• 3 public control plane IPv4 addresses for the GSUs

• 1 private O&M IPv4 address for OMU

• 2 IPv4 addresses for management purposes for LAN switches

Total number of IP addresses

The table below sums up the number of IP addresses required for each MSC

Server system element. Allocation of these addresses into their own subnets and

VLANs is described in the next chapter Subnetworking principles in MSC

server.

Page 98: 04 Protocols Overview

Protocols in MSS/MGW

98 (99) © Nokia Networks Oy

Note

The numbers given in this table are indicative whereas the actual address

allocation should always be based on the latest information about the number of

units in each network element. The latest details can be checked from the

network element engineering descriptions, which are included in network

element specific documentation.

21.2 Sub-networking principles in MSC Server

The address allocation principles described here can be used in cases where

every different type of traffic is segmented to its own subnet. Address spaces

are shared between network elements. Note that the subnet examples given

below are only rough examples. Normally address allocation is a much more

complex issue that must be carefully considered case by case.

MSS's internal communication addresses between IPETs and TGSUs

MSS Priv VLAN10 10.10.0.0/23

Control Plane Ipv4 addresses for units that require control plane addresses:

CP Publ VLAN20 195.148.0/24

Control Plane Ipv4 addresses for units that require control plane addresses:

CP Publ VLAN20 xxxx:xxxx:::xxx/64

User plane Ipv4 address:

UP Publ VLAN30 130.12.0.0/22

User plane Ipv4 address:

UP Publ VLAN30 xxxx:xxxx:::xxx/64

Addresses for O&M traffic

O&M Priv VLAN40 10.10.2.0/25

Management addresses for LAN switches

MGMNT Priv VLAN1 10.10.2.128/25

Addresses for DNS

DNS Publ VLAN2 10.10.3.0/28

Since the IP-NIU interfaces in the MGW are configured as router interfaces, subnets must be created

between the IP-NIU and the OSR router. A Gigabit Ethernet requires two /29 subnets, and a Fast

Ethernet, sixteen /29 subnets. These subnets also include addresses that are configured in the OSR's

router interfaces. OSR is the multilayer LAN switch/edge router used in the example configurations

for providing in-site connectivity and the WAN interface.

Page 99: 04 Protocols Overview

Error! Reference source not found.

© Nokia Networks Oy

99 (99)

Figure 55 Example of addressing in MSC Server system network elements