MGW Function

Multimedia Gateway (MGW)Functional Description

dn0497801Issue 6 en

# Nokia CorporationNokia Proprietary and Confidential

1 (111)

3GNDOCU3CNEDAC.10Nokia Multimedia Gateway, Rel. U3C, ProductDocumentation

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

The information or statements given in this document concerning the suitability, capacity, orperformance of the mentioned hardware or software products cannot be considered binding butshall be defined in the agreement made between Nokia and the customer. However, Nokia hasmade all reasonable efforts to ensure that the instructions contained in the document areadequate and free of material errors and omissions. Nokia will, if necessary, explain issueswhich 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 DOCUMENTOR FOR ANY DAMAGES, INCIDENTAL OR CONSEQUENTIAL (INCLUDING MONETARYLOSSES), 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 tothe applicable laws.

NOKIA logo is a registered trademark of Nokia Corporation.

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

Copyright © Nokia Corporation 2006. All rights reserved.

2 (111) # Nokia CorporationNokia Proprietary and Confidential

dn0497801Issue 6 en

Multimedia Gateway (MGW) Functional Description

Contents

Contents 3

1 Requirements for using MGW 51.1 Requirements for a Radio Network Controller (RNC) connected to MGW 51.2 Requirements for an MSC Server (MSS) controlling MGW 61.3 Requirements for a Base Station Controller (BSC) connected to MGW 71.4 Requirements for an ATM backbone connected to MGW 81.5 Requirements for an IP backbone connected to MGW 91.6 Requirements for a TDM backbone connected to MGW 101.7 Requirements for a PSTN/PLMN connected to MGW 111.8 Requirements for an IP Multimedia Subsystem (IMS) connected to

MGW 121.9 Requirements for an Unlicensed Mobile Access (UMA) 141.9.1 Requirements for UMA network controller (UNC) connected to MGW 141.9.2 MSC Server controlling MGW for UMA 151.9.3 MSC connected to MGW for UMA 151.10 Requirements for a Mobile Services Switching Centre (MSC) connected to

MGW for MSC 16

2 Functionality of MGW 172.1 Overview of MGW functionality 172.2 Resource configuration in MGW 202.3 Virtual MGW (VMGW) configuration 232.4 H.248 in MGW 272.5 IP connectivity in MGW 322.6 ATM connectivity in MGW 352.7 TDM connectivity in MGW 382.8 User plane monitoring in MGW 412.9 Codecs and speech transcoding in MGW 422.10 Speech enhancements in MGW 442.10.1 Electric echo cancellation (EC) in MGW 452.10.2 Acoustic echo cancellation (AEC) in MGW 462.10.3 Automatic level control (ALC) in MGW 472.11 2G TFO in MGW 472.12 TrFO in MGW 502.13 Signalling Gateway (SGW) in MGW 512.14 In-band tones and continuity check in MGW 552.15 Announcements in MGW 572.16 Nokia MGW in Nokia UMA solution for GSM 592.17 Ater interface in MGW 602.18 Data calls in MGW 622.19 Text Telephony service for 3G calls in MGW 662.20 Connection capacity licensing in MGW 702.21 Resource configuration in MGW for MSC 702.22 Interworking service (Iu - A' conversion) in MGW for MSC 712.23 Multicall in MGW 732.24 Performance management in MGW 742.25 Trace observation in MGW 78

dn0497801Issue 6 en


3 (111)

Contents

2.26 NEMU in MGW 802.27 Fault management in MGW via NEMU 812.28 Performance Management functionalities in NEMU 832.29 Subscriber Trace Post-processing in MGW 852.30 NetAct-related functionalities 862.31 Files in MGW 902.32 Databases in MGW 932.33 PRFILE and FIFILE parameters in MGW 942.34 Optional features in MGW 104

3 Compliance of MGW 107

Related Topics 109


dn0497801Issue 6 en


1 Requirements for using MGW

1.1 Requirements for a Radio Network Controller(RNC) connected to MGW

Network element Applicable in MGW

MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

RNC x x

*) MGW as part of the UMA for GSM solution. For more information, see NokiaMGW in Nokia UMA solution for GSM.

An RNC connected to an MGW has to support the open asynchronous transfermode (ATM) -based Iu-CS interface standardised by the 3rd GenerationPartnership Project (3GPP). MGW supports the open Iu-CS interface.

Also, an RNC connected to an MGW has to support ATM adaptation layer 2(AAL type 2) and ATM adaptation layer 5 (AAL type 5). AAL type 2 is requiredfor transferring speech and data, and AAL type 5 is required for transmittingsignalling information (such as RANAP) between endnodes.

Note

The utilisation of Transcoder Free Operation (TrFO) requires that the RAN isupgraded to the 3GPP release 4 level and that it has

. capability to receive rate control requests from /through core network and

. capability to receive Iu_UP re-initialisation requests from core network atthe termination side of a call

dn0497801Issue 6 en


5 (111)

Requirements for using MGW

The physical connection used in the Iu-CS interface is STM-1/OC-3. When IMAis used, physical connection can also be E1/T1/J1.

1.2 Requirements for an MSC Server (MSS) controllingMGW


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

MSS x


In addition to controlling MGWs, MSC Server is responsible for call control. TheMSC Server functionality is a combination of two distinct functionalities: VisitedMSC Server and Gateway MSC Server. The Visited MSC Server contains theVLR and controls the MGWs that are connected to a radio network. The GatewayMSC Server is responsible for the signalling interconnection towards externalnetworks and it has no VLR functionality. So, the Gateway MSC Server controlsthose user plane resources in MGWs which provide the interconnection to PSTN/ISDN network.

Also, an MSC Server to which an MGW for MSS is connected must be capableof handling IP-based signalling traffic. The SS7-based signalling traffic (used inA-, Iu-CS and PSTN/PLMN interfaces) is transported from MGW for MSS as IP-based signalling traffic towards MSC Server. This is done by changing the TDM/ATM transport layer to SCTP/IP transport towards MSC Server. Thetransportation is done on SS7 MTP3 -level by using SIGTRAN protocols.

In addition to IP-based signalling, the Mc interface between MSC Server andMGW for MSS has to support the IP-based H.248 user plane control protocol.The H.248 / MEGACO protocol is used by MSC Server to control the user planeterminations and contexts in MGW for MSS.


dn0497801Issue 6 en


Interworking with IMS

MGW provides an IP Multimedia Media Gateway (IM-MGW) functionality thatenables interworking between IP Multimedia Subsystem (IMS) and circuit-switched core networks. A new Mb interface conveys user plane traffic towardsthe packet core network domain, and a new Mn interface conveys control planetraffic towards MSS.

The Mn interface, specified by 3GPP, is a control interface between the IM-MGWand Media Gateway Control Function (MGCF) of MSC Server (MSS). The MSS(MGCF) has to support the new H.248 procedures of the Mn interface forhandling IM-MGW functionalities in IM CN-CS network interworkingsituations.

1.3 Requirements for a Base Station Controller (BSC)connected to MGW


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

BSS x


The A-interface user plane and control plane traffic sets certain requirements for aBSC connected to an MGW. The user plane traffic (speech and data) is alwaysrouted via MGW, while the control plane traffic (BSSAP signalling) is routedeither directly to MSC Server or transparently via MGW to MSC Server.

The Ater interface traffic requires a Nokia BSC to be connected to an MGW. TheBSS release must be updated to support the use of the Ater functionality.

In the TDM-based A-interface, the physical connection is STM-1/OC-3 or E1/T1/JT1. In the Ater interface, the physical connection is E1/T1/JT1.

dn0497801Issue 6 en


7 (111)


Note

When the A-interface is used between BSS and MGW, the utilisation of theTandem Free Operation (TFO) for 2G traffic requires the TFO support also in thetranscoders located in the BSS.

When the Ater interface is used, the TFO-capable 2G transcoder functionality islocated in MGW.

1.4 Requirements for an ATM backbone connected toMGW

Interface Applicable in MGW

MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

ATM backbone x


MGW does not set any particular requirements for an ATM backbone locatedbetween MGW and RNC (Iu-CS interface) or between MGW network elements(Nb interface). Signalling and user plane traffic between two MGWs (or betweenMGW and RNC) is transmitted via the Nb interface using the ATM adaptationlayers AAL type 2 and AAL type 5 over permanent virtual channel (PVC)connections.

Within the ATM backbone, AAL type 2 is used on the user plane to transportcompressed speech and data. If the ATM backbone supports the AAL type 2switching (nodal function) capability, it is possible to re-route user plane AALtype 2 traffic from one MGW for MSS to another MGW for MSS without directpermanent virtual connections (PVC) between the MGWs. MGW uses AAL type2 PVC connections, but inside the ATM backbone switched virtual channels(SVC) may be used as well.

AAL type 5 PVC is needed to carry signalling data (such as AAL type 2signalling).


dn0497801Issue 6 en


When IP connectivity is not provided at the remote site and the ATM backbone,the control plane traffic can be routed via ESA24 unit to MSC Server. The userplane traffic is routed via NIS1 or NIP1 unit to another MGW. For moreinformation, see Overview on IP over ATM and optimising TDM transmission forremote MGW.

The physical connection used with ATM backbone is STM-1/OC-3. When IMAis used, physical connection can also be E1/T1/J1.

1.5 Requirements for an IP backbone connected toMGW


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

IP backbone x


IP backbone, located between two MGW network elements (Nb interface)requires the Real-time Transport Protocol (RTP) to convey user plane traffic. TheReal-time Transport Control Protocol (RTCP) can be used to monitor the RTPstream and to collect statistical data. RTP provides end-to-end delivery servicesfor 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 variablesite solutions, IP backbone must support at least one of the followingconnections:

. Fast Ethernet (100Mbit/s)

. Ethernet (1Gbit/s)

dn0497801Issue 6 en


9 (111)


Figure 1. Default IP connectivity

When Ethernet connections are used for transporting IP traffic, the AddressResolution Protocol (ARP) is required for IP address mapping.

IP backbone must support IPv4 or IPv6 routing. Routing is based on staticrouting.

1.6 Requirements for a TDM backbone connected toMGW

1G/100M

100Mb

Edge-router

100Mb

MGW

UserPlane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

IPFGE

NetAct

MSC Server

ESA24

O&M


dn0497801Issue 6 en



MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

TDM backbone x


MGW does not set any particular requirements for a TDM backbone locatedbetween MGW network elements (Nb interface). However, the operator needs tohave a cost-efficient and high-capacity TDM-based transmission network in orderto build a TDM backbone.

When IP connectivity is not provided at the remote site and the TDM backbone,the control plane traffic can be routed via ESA24 unit to MSC Server. The userplane traffic is routed via NIWU or IWS1E/T unit to another MGW. For moreinformation, see Overview on IP over ATM and optimising TDM transmission forremote MGW.

The physical connection used in the TDM backbone is STM-1/OC-3 or E1/T1/JT1.

1.7 Requirements for a PSTN/PLMN connected to MGW


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

PSTN/PLMN x


dn0497801Issue 6 en


11 (111)


Depending on the network, PSTN and other TDM-based networks (such asPLMN) connected to MGWmay support the following signalling protocols basedon the SS7 standard:

. ISDN User Part (ISUP)

Used for handling the ISDN bearer services (including Telephony) andsupplementary services for voice and data applications. The messageTransfer Part is used to carry the information of the ISUP Message.

. Mobile Application Part (MAP)

Specifically designed for non-call transactions between the GSM switchingand database elements that support the roaming of mobile subscribers.

. Telephone User Part (TUP)

Used for handling telephone call control functions in national andinternational networks. The Message Transfer Part is used to carry theinformation of TUP messages.

The SS7-based control plane traffic is routed either directly to MSC Server or viaMGW to MSC Server.

The physical connection used in the PSTN/PLMN interface is STM-1/OC-3 orE1/T1/JT1.

STM-1 VC-12 (OC-3 VT1.5 SPE) is provided for environments where largeinterconnect points are needed. STM-1 VC-12 makes it possible to connect 63 E1interfaces (or alternatively 84 T1 interfaces) over a single fiber.

1.8 Requirements for an IP Multimedia Subsystem(IMS) connected to MGW


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

IMS x



dn0497801Issue 6 en


IP multimedia subsystem (IMS), located between MGW and SIP clients, must beable to handle large numbers of small IP packets with low end-to-end delay andlow jitter. Mb interface requires the real-time transport protocol (RTP) over userdatagram protocol (UDP) to convey user plane traffic. The real-time transportcontrol protocol (RTCP) can be used to monitor the RTP stream and to collectstatistical data. RTP provides end-to-end delivery services for data with real-timecharacteristics (such as interactive audio transmission), thus making it an idealprotocol for real-time applications such as Voice over IP (VoIP). Compared to theNb interface, Nb user plane framing protocol (Nb UP) is not used in the Mbinterface. The coded speech samples are transported on top of RTP.

Depending on the requirements of different network environments and variablesite solutions, IMS must support at least one of the following connections:



Figure 2. IP connectivity

1G

100Mb

Edge-router

100Mb

MGW

UserPlane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

IPFGE

NetAct

ESA24

O&M

MGCF

dn0497801Issue 6 en


13 (111)


When Ethernet connections are used for transporting IP traffic, the addressresolution protocol (ARP) is required for IP address mapping. As regardsrouting, IMS must support IPv4 or IPv6 routing. Routing is based on staticrouting.

1.9 Requirements for an Unlicensed Mobile Access(UMA)


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

UMA x x


MGW is able to provide the user plane connection towards Unlicensed MobileAccess Network (UMAN) by using the Up-CS interface. Another alternative isthat MGW is a part of UMA network controller (UNC) providing A-interfacetowards CS core.

FR AMR speech codec with octet-aligned mode is used in the Up-CS interface.Also Discontinuous Transmission (DTX) for FR AMR codec is supported.

Note that 3GPP handles UMA under the work item Generic Access to A/Gbinterfaces, with the name Generic Access Network (GAN).

1.9.1 Requirements for UMA network controller (UNC) connected to MGW

UMAN, connected to MGW, must be able to handle large numbers of small IPpackets with low end-to-end delay and low jitter. The Up-CS interface requiresthe real-time transport protocol (RTP) over user datagram protocol (UDP) toconvey user plane traffic. The real-time transport control protocol (RTCP) can beused 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 interactiveaudio transmission), thus making it an ideal protocol for real-time applicationssuch as Voice over IP (VoIP). In the Up-CS interface, no user plane framingprotocol is used. The coded speech samples are transported on top of RTP.


dn0497801Issue 6 en


Depending on the requirements of different network environments and variablesite solutions, UMAN must support at least one of the following connections:



When Ethernet connections are used for transporting IP traffic, the addressresolution protocol (ARP) is required for IP address mapping. Although MGWsupports both Internet Protocol versions, IPv4 and IPv6, currently only IPv4routing is required from UMAN. Routing is based on static routing.

1.9.2 MSC Server controlling MGW for UMA

MGW for UMA is controlled by MSS by H.248 similarly as in the MSS or IMSenvironments. There are no special requirements for MSC Server System.

1.9.3 MSC connected to MGW for UMA

The Nokia UMA system offers the standard A-interface with Nokia MGW sinceNokia MGW can serve the UMA network as part of UMA network controller(UNC). This functionality enables support for multivendor CS core cases. Inother words, operators are able to provide UMA access with Nokia UMAsolution also when Nokia MSS is not present.

MSC has to support the mobility management (MM) and connectionmanagement (CM) protocols of 3G specification 24.008. The MSC is alsorequired to support the base station subsystem application part (BSSAP) protocolof 3GPP specification 08.08.

The physical connection used in the standard A-interface is STM-1/OC-3 or E1/T1/JT1.

dn0497801Issue 6 en


15 (111)


1.10 Requirements for a Mobile Services SwitchingCentre (MSC) connected to MGW for MSC


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

MSC x


The MSC has to support the mobility management (MM) and connectionmanagement (CM) protocols of 3G specification 24.008. The MSC is alsorequired to support the base station subsystem application part (BSSAP) protocolof 3GPP specification 08.08.

The MSC must also support the non-standard BSSAP. The non-standard BSSAPis called BSSAP' and it includes the procedures which are not included in 3GPPspecification 08.08. The interworking between the RNC and the MGW for MSCrequires the use of BSSAP'. BSSAP' is only used between the MSC and theMGW for MSC. This interface is an internal interface of the 3G MSC, and it iscalled A' interface.

The BSSAP can be divided into the base station subsystem managementapplication part (BSSMAP) and direct transfer application part (DTAP). TheBSSMAP supports the procedures related to a single call and to resourcemanagement. Non-standard BSSMAP procedures are referred to as BSSMAP'.The DTAP supports the MM and CM procedures.


dn0497801Issue 6 en


2 Functionality of MGW

2.1 Overview of MGW functionality

The table below presents the key functionalities of MGW in different networkenvironments. Note that this is not a feature list, but a summary of MGWfunctionalities.

The different MGW architectures and MGW's roles in them are described inIntroduction to MGW U3C release in Nokia Multimedia Gateway U3C ReleaseOverview.

Table 1. Key functionalities of Multimedia Gateway

Key Functionality Applicable in MGW

MGW forMSC

MGW inUNC (UMA)*)

MGW forMSS

Resource configuration x x x

VMGW configuration x

H.248 x

IP connectivity limited - usedfor O&M

connectionsonly

x x

ATM connectivity x x

TDM connectivity x x x

User plane monitoring x

dn0497801Issue 6 en


17 (111)

Functionality of MGW

Table 1. Key functionalities of Multimedia Gateway (cont.)


MGW forMSC

MGW inUNC (UMA)*)

MGW forMSS

Codecs x x x see tableCodecs

supported byMGW indifferentinterfaces

Electric echo cancellation(EC)

PSTN/PLMN Optional

Acoustic echocancellation (AEC)

Iu-CS Iu-CS, A, Ater Optional

Automatic Level Control(ALC) and fixed gain

x x

(Not in Nb)

2G TFO x Optional

TrFO x Optional

SGW x x

In-band tones andcontinuity check

x

Announcements x

Interworking service forUMA access (A/A+conversion)

x x

Ater interface x Optional

Data calls x x

Text Telephony (TTY) x x Optional

MGW connectioncapacity

x Optional,licence-based

Interworking service (Iu -A' conversion)

x

Multicall x


dn0497801Issue 6 en


Table 1. Key functionalities of Multimedia Gateway (cont.)


MGW forMSC

MGW inUNC (UMA)*)

MGW forMSS

Performancemanagement

x x x

Trace observation x x

NEMU x x x

Fault management x x x

Performancemanagementfunctionalities in NEMU

x x x

Subscriber trace post-processing

x

NetAct-relatedfunctionalities

x x x

Files x x x

Databases x x x

PRFILE and FIFILEparameters

x x x


Note

The subscriber trace feature is optional in Nokia NetAct.

dn0497801Issue 6 en


19 (111)


2.2 Resource configuration in MGW

Table 2. Resource configuration in different MGW networkenvironments

Functionality Applicable in MGW

MGW forMSC

MGW inUNC (UMA)*)

MGW forMSS

Resource configuration x x x


MGW is a border element between different kinds of signalling and user planeinterfaces. In fact, with MGW, it is possible to use three different interfacessimultaneously, namely TDM, ATM and IP interface. For user plane traffic, itprovides both a transport and conversion mechanism.

Network element address configuration

In the Media Gateway configuration, AAL2 Service endpoint address is definedfor the MGW network element. The Multimedia Gateway Specific ParameterHandling (WE) MML is used for configuring MGW.

ATM configuration

With the ATM interfaces, resource management is used for reserving theresources of an ATM exchange for different purposes (signalling, user traffic, IPover ATM connections). The ATM interface is an external logical interface underwhich the connections are built. The ATM interface is the basis of the VP/VCtermination point, which is the basis of the connection.

The following steps are taken when configuring the ATM interfaces:


dn0497801Issue 6 en


. create an ATM interface using the ATM Interface Handling (LA) MML

. create an Access Profile for the ATM interface using the ATM InterfaceHandling (LA) MML

. create a VP/VC Link termination point using the VP/VC Link TerminationPoint and VC Bundle Handling (LC) MML

External termination points are created both on VP level and VC level. They arethe terminating ends of the VP/VC connections. Virtual Path Link terminationpoints (VPLtp) must be created before any Virtual Channel Link terminationpoints (VCLtp) and VC-level connections can be created under the VPLtp. EachVPLtp is related to one ATM interface. The interface configuration defines thelimits to the total VPLtp capacity reservations. The number of VCLtps createdunder each VPLtp depends on the total VPLtp capacity. Therefore, whenreserving capacity for a VPLtp, you should plan how many VC-level connectionsare needed under that VPLtp.

In addition to the ATM interface configuration, the ATM resource managementrequires the configuration of the ATM routing. The primary purpose of routing isto locate free resources in an ATM network in order to direct user plane traffic(voice and data) to the desired destination.

The routing configuration in an ATM network must be done in the followingorder:

. create an external ATM route using the Route Handling (RR) MML

. create an Endpoint group using the ATM Endpoint Group Handling (LI)MML

. create an Endpoint using the ATM Endpoint Handling (LJ) MML

. unblock the AAL2 type 2 path using the AAL2 Signalling Handling (LS)MML

The external ATM route is used for directing the call to another network element.Under the ATM route routing selects an appropriate VCC endpoint group. Underthe VCC endpoint group, the routing selects an appropriate VCC endpoint andthus an appropriate virtual channel. Finally, AAL2 connection control selects afree AAL type 2 channel for making the connection.

The routing policy function makes it possible to utilise percentage calldistribution (also known as load sharing) and alternative routing. With percentagecall distribution, traffic to a destination can be distributed among two or moresubdestinations in predefined proportions.

dn0497801Issue 6 en


21 (111)


With alternative routing, another subdestination can be used if the subdestinationselected before is congested. For example, if there is an error in an ATM routebetween two MGWs, it is possible to re-route ATM traffic via a third MGW.

The analysis and routing of the ATM resources is carried out in MGW. Theanalysis tree selection is based on the analysis information which the operatormust configure by using the Digit Analysis Handling (RD) and Digit AnalysisInterrogation (RI) MMLs.

TDM configuration

The following steps are taken when configuring the TDM resources to MGW:

. create a circuit group using the Circuit Group Handling (RC) MML

. add circuits to circuit groups using the Circuit Group Handling (RC) MML

. change the state of the circuits using the Circuit State Handling (CE) MML

IP configuration

In MGW, the configuration of the IP connection for O&M is done as follows:

. create MMI user profiles and user IDs

. configure OMU/NEMU for DCN

. configure ESA12 / ESA24

. create O&M connection using Ethernet / IPoA virtual connection

The IP interface configuration includes the following configuration tasks:

. IP over Ethernet

The TCP/IP Stack Data Handling (QR) MML is used for maintaining MACaddresses in Ethernet interface configuration.

. IP routing

The IP Routing Data Handling (QK) MML is used for handling the IProuting data.

. IP addressing

Every IP interface has its own IP address. IP addresses are configuredeither manually or automatically.

. IP protocol stacks


dn0497801Issue 6 en


The TCP/IP Stack Data Handling (QR) (for IPv4) and the IPv6 TCP/IPStack Configuration Handling (Q6) (for IPv6) MMLs are used forconfiguring IP stacks.

The IP Routing Data Handling (QK) MML is used for handling the IP routingdata.

2.3 Virtual MGW (VMGW) configuration

Table 3. VMGW configuration in different MGW network environments


MGW forMSC

MGW inUNC (UMA)*)

MGW forMSS

VMGW configuration x


The overall control of MGW resources is in MSC Server, from which resourcesare allocated and released using the H.248 interface. MGW provides thepossibility to create Virtual Media Gateways (VMGW) in one physical gatewayelement, thus offering media resources to several controlling elements. Theresource configuration includes the interface configuration, routing and analysisconfiguration and VMGW configuration. The MGW startup includes theregistration, audit procedures and supervision procedures.

Only a small part of the configuration deals with the entire network element,whereas most configuration tasks concern only Virtual Media Gateways insidethe network element. In any case, at least one VMGW has to be configured. Notethat also the H.248 connections, routing and various interfaces, among others,must be configured. The TDM resources belong to one specific VMGW, and freeIP and ATM resources are shared among the servers controlling MGW. When aserver takes IP or ATM resources into use, the resources are reserved to thatparticular server for as long as it needs the resources. After that, they are freedinto common use again.

The following requirements must be met before the actual VMGW configuration:

dn0497801Issue 6 en


23 (111)


. it has been decided how many VMGWs are configured (maximum of 5)into one ISU unit

. the H.248-specific data is known

. the E.164/AESA address of MGW is known

. the IP address/domain name (for H.248 traffic) of each VMGW is known

. a circuit group has been created for each VMGW that uses TDM resources

. the primary and secondary addresses of MSC Server are known

. ATM AAL2 analysis tree has been created for each VMGW that uses ATMbackbone resources

. SCTP parameter set has been created (in case SCTP is used as transporttype for H.248)

The Virtual Media Gateway Handling (JV) MML is used for configuring theVMGWs.

TDM configuration

When configuring the TDM interfaces, each VMGW can be given a maximum of10 circuit groups that contain all the PCMs dedicated to that specific VMGW.The user type of the circuit groups is 'vmgw' and only this type of circuit groupcan be attached to a VMGW.

To optimise the usage of DSP resources, the TDM circuits attached to a VMGWcan be divided into different circuit groups according to their use. That is, it ispossible to define the exact purpose of TDM circuits so that there are specificcircuit groups for different use cases (for example, for PSTN, Nb and A-interfaces).

The following additional steps are taken when configuring the TDM resources toVMGWs:

. define the purpose of the circuit group (PSTN, Nb, A-interface) using theCircuit Group Handling (RC) MML

. link circuit groups to VMGWs using the Virtual Media Gateway Handling(JV) MML

Internal circuit groups are created for each VMGW. A circuit group contains theCRCTs which belong to the VMGW in question. The circuit group must becreated before adding the VMGW data (if the VMGW needs the TDM resources).MSC Server allocates the PCM/TSL circuit with termination_id. Thetermination_id is automatically generated based on the PCM/TSL value.


dn0497801Issue 6 en


The TDM hunting is in MSC Server.

User plane parameter configuration

The Signal Level Controlling (W4) MML is used for modifying parameters thataffect media processing on the user plane.

DSP service pooling

DSP services are used for, for example, terminations (e.g. Iu or A-interface) andsupplementary services (e.g. tone generation and DTMF detection). Earlier, allDSPs in MGW were used similarly for providing all signal processing services,but now the services have been grouped in service pools. Service pooling enablesthe DSP application and platform resource usage optimisation. With carefulselection of DSP services, the memory pool configuration is optimised so thatmemory resources are used more efficiently. Similarly, by defining that certainDSP devices provide only certain DSP services, a reasonable minimum capacitycan be ensured for services.

One DSP service may belong to multiple service pools and all services mustbelong to at least one service pool. At startup, each DSP device is dedicated toone service pool. This mapping is based on operator configuration (percentage ofDSP devices allocated to each DSP service pool) when a DSP device is startedup. It is also possible to modify DSP service pool balance in a live networkelement to reflect changes in call profile.

Services may be available from multiple service pools, but the priority of theservice is different in different service pools. For service reservations to a newcontext ('empty context'), DSP resource manager always tries first to allocate aresource from the service pool where the service has highest priority. Only if noresource is found in that service pool, it may select a resource from the secondaryservice pool. When adding DSP resources to an existing context, the originallyselected DSP device is preferred. If that device does not have free resources for anew DSP service, or it does not provide the requested service at all, a new DSPdevice is selected and a DSP-DSP connection is made between the services.

The following DSP service pools have been defined:

. Standard Narrowband Service Pool (pool ID 0) includes A, Iu, Mb/UMA, Nb, and PSTN interface types and all supplementary services. Onlynarrowband speech codecs are supported.

. Narrowband Ater/A Service Pool (pool ID 1) includes A, Ater, Nb, andPSTN interface types and all supplementary services. Only narrowbandspeech codecs are supported.

dn0497801Issue 6 en


25 (111)


. 3G Wideband Service Pool (pool ID 2) includes the functionalityrequired for providing AMR-WB service in a 3G-only MGW. Iu-Iu and Iu-Nb calls using the AMR-WB codec are supported, as well as tones andannouncements related to these calls, and interconnection to PSTN.Narrowband codecs are also supported in this pool but with lower priority.When narrowband codec is requested for the connections, this pool isutilised only after the actual Standard Narrowband Service Pool is full.

. 2G/3G Wideband Service Pool (pool ID 3) includes the functionalityrequired for providing AMR-WB service in a combined 3G/2G MGW.Although AMR-WB is not supported in the Ater interface, AMR-WB-capable DSP services for A/Ater are needed for inter-system handovers.

. Multi-Party Service Pool (pool ID 4) includes the functionality necessaryfor providing conference/multi-party call services. Having a separate multi-party service pool allows operators to limit the maximum TCU(transcoding unit) capacity used by multi-party services.

When same MGW is used for serving both 3G and 2G/Ater access withnarrowband codecs, then both Standard Narrowband Service Pool andNarrowband Ater/A Service Pool need to be configured. In call cases between 2Gand 3G, resources are reserved from both Standard Narrowband Service Pool andNarrowband Ater/A Service Pool. The Iu interface resource is reserved from theDSP belonging to the Standard Narrowband Service Pool and the A/Ater resourcefrom the DSP belonging to the Narrowband Ater/A Service Pool.

The Signal Processing Service Handling (WP) MML is used for configuringservice pools, removing services from service pools, and interrogating poolutilisation.

VMGW startup (registration and audit)

MGW starts the registration process by sending a ServiceChange Requestcommand to MSC Server. It is possible to define one primary and one secondaryMSC Server address (IP address or Domain name) to each VMGW. If the DNSfunctionality is used, it is possible to carry out the registration process by usingthe domain name instead of the IP address. The domain name to IP addresstranslation is performed during registration in the IP stack. The registration can bedone automatically at startup phase or manually by using the Virtual MediaGateway Handling (JV) MML. Each virtual VMGW sends a registration requestto the controlling (primary) MSC Server and each VMGW has its own MSCServer addresses.

After the registration, MSC Server may ask for the possible value properties of allthe terminations in the NULL context, which contains all the physicalterminations that have not been reserved by the MGW. MGW returns therequested information by sending a reply command. Also, MSC Server may ask


dn0497801Issue 6 en


the actual value properties of all the terminations in the NULL context. MGWreturns the requested information by sending a reply command. The TDMresources are audited with the AuditValue command. The ATM and IP resourcesare not audited because they are ephemeral.

IP QoS

PRFILE parameters DSCP_FOR_USER_PLANE (002:0817) andDSCP_FOR_SIGNALLING (053:0009) are used for handling the IP QoSconfiguration.

Resource supervision

In order to achieve a proper interaction between MGW and MSC Server /Gateway Control Server, the server must be aware of the MGW working statesand resources. Resource supervision is available for the MGW and MSC Server/Gateway Control Server network elements, calls, and idle TDM resources.

Network element supervision is performed interactively between MGWand MSCServer / Gateway Control Server. The time interval for network elementsupervision can be configured separately for each server by using the VirtualMedia Gateway Handling (JV) MML.

Call supervision is conducted by MSC Server / Gateway Control Server if it isneeded. The server can supervise the call-related connections by sending auditcommands to MGW. If the server does not send an audit command during a giventime frame, MGW checks the situation with a ServiceChange command. The timeinterval for sending the ServiceChange command can be configured separatelyfor each server. The sending of the ServiceChange command can be alsodeactivated.

TDM resources supervision is performed by MGW on ET (WO/BL), TSL (WO/BL) and the physical connection.

2.4 H.248 in MGW

dn0497801Issue 6 en


27 (111)


Table 4. H.248 in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

H.248 x


The H.248 protocol is used in the Mc/Mn interface between MSC Server/Gateway Control Server (GCS) and MGW. MSC Server/GCS controls the userplane terminations and contexts in MGW through the Mc/Mn interface. The Mcand Mn interfaces utilise the same H.248 connection. Thus it is possible to haveboth IMS-specific terminations and CS terminations in the same context.

As regards the benefits, the H.248 protocol provides the following:

. standardised interface

. switching and signalling resources can be optimised independently

. communication is possible between different media terminations

By using the H.248 protocol, the controller (MSC Server or GCS) requests MGWto form a transmission connection. The connection is formed by using contextsand terminations. A context is an association between a collection ofterminations. A termination is an object that sources and sinks one or more mediastreams. A termination is either physical or ephemeral. A PCM timeslot is anexample of a physical termination and IP and ATM terminations are examples ofephemeral terminations.

The forming of a transmission connection begins with the controller using theH.248 protocol to request a termination from MGW. After this, MGW reserves acontext for the requested termination. MGW informs the controller of thereserved context and when the controller receives the context ID, it can requestanother termination for the same context ID, and the connection is established.There is a special context, null context, that contains all the physical terminationsthat have not been reserved by the MGW. A context can have more than twoterminations that are connected with each other. This functionality is needed,among other things, in supplementary services and handover.


dn0497801Issue 6 en


In the conference service, up to 6 subscribers can be connected in a conferencecall. Subscribers can be added to and removed from the conference servicedynamically. Subscribers are added/removed one by one to/from the conferencecall.

MGW supports TCP and SCTP as transport types. It is recommended to useSCTP multi-homing. If there are several MGWs in the network, the transport typeis configured for each VMGW.

Figure 3. H.248 connection model within MGW

H.248 message

The format of the H.248 message is either binary (ASN.1) or text (ABNF), andthe message header consists of authentication header, protocol version, andaddress of the message originator.

The H.248 message is a collection of transactions. A transaction (identified withtransactionID) is a collection of actions and an action (contextID) is a collectionof ActionRequests or ActionReplies for the context. Transactions in a messagecan be handled in any order or simultaneously and replied independently. TheH.248 protocol guarantees the order of commands (terminationID) in transaction.

Context

Context Null Context

Context

Termination

IP

Termination

Termination

IP

IP

Termination

Termination

Termination

Termination

ATM (SVC)

TDM

TDM

ATM (PVC)

dn0497801Issue 6 en


29 (111)


The maximum total size of a H.248 message is 32 kbytes. There can be amaximum of 15 transactions in one H.248 message, 15 actions in one transaction,and a basically unlimited number of commands in one action. The number ofcommands in one action is limited only by the overall size of a H.248 message(32 kbytes).


dn0497801Issue 6 en


Figure 4. Commands, contexts, actions and transactions in an H.248message

H.248 Message

Transaction1 (transactionID 1)

Command1 (terminationID 1)



Action1 (contextID 1)

Transaction2 (transactionID 2)






TCP / SCTP Header

IP Header

dn0497801Issue 6 en


31 (111)


There are default H.248 protocol timer values in MGW that can be used for allVMGWs. However, MGW also makes it possible to modify H.248 timer values(such as execution time and network delay). If there is a need to modify thedefault timer values, the modification of the value depends on the timer inquestion.

Some of the default timer values are stored in PRFILE (for more information seePRFILE parameters in MGW), and their values can be modified with theParameter Handling (WO) MML. It is also possible to use the Virtual MediaGateway Handling (JV) MML to define VMGW-specific H.248 timer values forcertain VMGWs, thus over-ruling the default timer values for the VMGW inquestion. And, if necessary, some of the timer values can also be modified byMSC Server/Gateway Control Server via the H.248 interfaces. With the timersthat can be controlled by the servers, the value set by the server overrules both thedefault PRFILE value and the VMGW-specific value.

H.248 Event Log

It is possible to use the Virtual Media Gateway Handling (JV) MML to outputH.248-related alarm and error information related to VMGW. This is usefulespecially if there are problems in the H.248 registration functionality.

2.5 IP connectivity in MGW

Table 5. IP connectivity in different MGW network environments


MGW forMSC

MGW in UNC(UMA) *)

MGW for MSS

IP connectivity x (limited - usedfor O&M

connectionsonly)

x x



dn0497801Issue 6 en


The IP connectivity feature provides Fast Ethernet (100Mbit/s) and 1Gbit/sEthernet connections for the IP backbone user plane traffic. For the control planetraffic, it provides connections for SIGTRAN and H.248 control.

Figure 5. MGW network interfaces and IP connectivity

IP connectivity is used for the following protocols:

. RTP/RTCP

. H.248

. SIGTRAN

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NIS1

NIP1

Multimedia Gateway

ESA24

IP connectivity

STM-1 for IP over ATMNIS1

IPFGE

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T

ATM over SDH/STM-1or E1/T1/JT1 (IMA) is used for:- Iu-CS- Nb

IP connectivity is used for:- H248 control (Mc/Mn interface)- IP core/user plane (Nb interface)- SIGTRAN- Mb interface- Fixed soft switch interface- UMA interface- NetAct interface- IWF control

TDM is used towards:- A-interface/BSS- A-interface/MSC (UMA)- Ater interface/Nokia BSS- PSTN- MSS- CDS- MGW

ATM

NIP1 E1/T1/JT1 for IP over ATM

Ethernet

dn0497801Issue 6 en


33 (111)


IP connection adds also the routing functionality to MGW. The routingfunctionality can be used for routing user plane (RTP), H.248 and SIGTRAN tocore network routers.

In the Nb interface, it is possible to use either a 3GPP-based Nb interface or,when user plane framing protocol is not used, a Nokia proprietary interface. Inthose cases, the RTP protocol is used partly based on the IETF standards withNokia proprietary modifications and restrictions.

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 todifferent network environments and to build variable solutions

. IP as a common network platform provides agile network development andtransmission cost savings

Functionality

By default, the control plane is routed through ISU/ESA24.


dn0497801Issue 6 en


Figure 6. Default IP connectivity

When Ethernet connections are used for transporting IP traffic, the AddressResolution Protocol (ARP) is used for IP address mapping.

As regards routing, MGW for MSS supports both IPv4 and IPv6 routing. Routingis based on static routing.

IP over ATM (IPoA) provides a mechanism to transport IP-based control traffic(SIGTRAN and H.248) via the ATM network in those cases in which IPconnectivity is not provided at the site. For more information, see Overview on IPover ATM and optimising TDM transmission for remote MGW.

2.6 ATM connectivity in MGW

1G/100M

100Mb

Edge-router

100Mb

MGW

UserPlane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

IPFGE

NetAct

MSC Server

ESA24

O&M

dn0497801Issue 6 en


35 (111)


Table 6. ATM connectivity in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW for MSS

ATM connectivity x x


Asynchronous Transfer Mode (ATM) is a fast-packet, connection-oriented cell-switching technology for broadband signals. The information in ATM is split anddelivered in fixed-length packets called cells. The end-to-end route is definedthrough the network in the beginning of the connection and remains the samethroughout the connection. This is to make sure that the cells arrive in the order inwhich they were sent. ATM also minimises the delay variation. ATM cells aregenerated continuously by an ATM multiplexer or an ATM terminal and filledwith data.


dn0497801Issue 6 en


Figure 7. MGW network interfaces and ATM connectivity

In MGW, the ATM connectivity is used for the following purposes:

. Iu-CS interface

This interface carries traffic between Radio Network Controller (RNC) andcircuit switched core network domain. This interface is ATM-based anduses ATM adaptation layer type 2 (AAL type 2). ATM adaptation layertype 5 (AAL type 5) is used for signalling data.

. ATM-ATM semipermanent connections

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NIS1

NIP1

Multimedia Gateway

ESA24

IP connectivity


IPFGE

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T




ATM


Ethernet

dn0497801Issue 6 en


37 (111)


A semipermanent cross-connection through an ATM network element canbe used for leased-line type services needed in ATM networks. In MGW, itis possible to establish a backup connection from RNC to NetAct routerthrough MGW.

. ATM AAL type 2 nodal function

With the ATM AAL type 2 nodal functionality, AAL type 2-basedconnections can be routed without MSC Server control from oneMultimedia Gateway to another, thus optimising the usage of the resourcesin the network. This makes the implementation of the signalling networkeasier and cheaper for the operator: the same ATM resources can beutilised for Iu, Iur, and Nb interfaces.

. Nb interface via ATM

The Nb interface is used between two MGWs to convey user plane andsignalling traffic. AAL type 2 protocol is used for the user plane and AALtype 5 is used for the signalling data.

ATM-based user plane and control plane protocols

AAL type 2

In ATM networks, AAL type 2 supports bandwidth-efficient transmission for lowbit rate and short-length packet applications that are delay-sensitive. AAL type 2is used on the user plane to transport compressed speech and data.

In MGW, AAL type 2 is used in the Iu-CS and Nb interfaces.

AAL type 5

AAL type 5 is a simple and efficient AAL layer: it has minimal overhead, no mis-sequencing protection and no multiplexing of connections.

In MGW, AAL type 5 is needed for carrying signalling data (such as RANAP /AAL type 2 signalling).

2.7 TDM connectivity in MGW


dn0497801Issue 6 en


Table 7. TDM connectivity in different MGW network environments


MGW forMSC

MGW inUNC (UMA)*)

MGW forMSS

TDM connectivity x x x


TDM interfaces in MGW for MSC

The A' interface is the Nokia version of the time division multiplexing (TDM) -based A interface between the mobile services switching centre (MSC) and anMGW for MSC. The A' interface is based on base station subsystem applicationpart (BSSAP) signalling complemented with non-standard BSSAP procedures.

TDM interfaces in MGW

With MGW, TDM interfaces are used for the following purposes:

. to connect MGW to existing TDM-based networks (PSTN/ISDN/PLMN)

. to connect MGW to BSS (A-interface)

. to connect MGW to Nokia BSS (Ater interface)

. to route CS data calls through the Interworking Functionality (IWF) inMSC or standalone CDS (CS Data Server)

. to direct user plane traffic from Integrated MSC Server to MGW

. between two MGWs (TDM backbone)

. to establish TDM-based semipermanent through connections (64kbit/s)

. interworking service for UMA access (A/A+ conversion)

dn0497801Issue 6 en


39 (111)


Figure 8. MGW network interfaces and TDM connectivity

Functionality

MGW provides an interconnection between legacy SS7 TDM networks andpacket/cell -based networks. Signalling from MGW towards TDM-basednetworks is handled using SS7 standards. The primary physical interfaces usedbetween legacy SS7 TDM networks and packet/cell -based networks are E1/T1/J1 and STM-1/OC-3.

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NIS1

NIP1

Multimedia Gateway

ESA24

IP connectivity


IPFGE

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T




ATM


Ethernet


dn0497801Issue 6 en


TDM is used in the A-interface for transporting speech, data, and SS7-basedsignalling between MGW/MSC Server and the BSS. The A-interface isconnected either to MGW or to MSC Server depending on the needs of theoperator. The user plane traffic (speech and data) is always routed via MGW tothe TDM/ATM/IP backbone, while the control plane traffic (BSSAP signalling) isrouted either directly to MSC Server or transparently via MGW to MSC Server.In addition to transporting speech, data, and signalling, the A-interface alsosupports the services offered to GSM users and subscribers. In the interworkingservice for UMA access, the A-interface is used between MGW and MSC.

A characteristic behaviour of GSM and UMTS CS data calls is that the user planedata format cannot be used towards legacy fixed networks. Thus the user planedata of CS data calls needs to be modified so that it can be used in legacy fixednetworks. The data conversion is done in a facility called InterworkingFunctionality (IWF). IWF can be located in MSC Server or it can act as astandalone element (CS Data Server). Free TDM resources are hunted in MSCServer and the CS data is routed through IWF using TDM connections betweenMSC Server and MGW. The IWF user plane connection can also be routedthrough another MGW using semipermanent TDM-TDM connections. The IWFcontrol interface between MGW and MSC Server enables IWF to be locatedbasically in any MSC Server.

2.8 User plane monitoring in MGW

Table 8. User plane monitoring in different MGW networkenvironments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

User plane monitoring x


dn0497801Issue 6 en


41 (111)


The possibility for user plane monitoring in MGW provides additional tools thatcan be used to facilitate testing and troubleshooting. The User Plane MonitoringHandling (JK) MML makes it possible to investigate the services and resourcesattached to a certain H.248 termination, and to monitor the physical andephemeral resources of a VMGW, the topology of H.248 terminations in a singlecontext, and active contexts in VMGWs.

User plane monitoring can be used for requesting information about reservedphysical (TDM) or ephemeral (ATM, IP) resources. Free resources, such asterminations (physical or ephemeral) in the NULL context, cannot be monitored.Also, the User Plane Monitoring Handling MML can only be used for temporarymonitoring of the reserved resources; it provides information on the prevailingstatus of the reserved resources at the moment when the command is entered.

The user plane monitoring functions require some amount of system resources,and thus it is recommended that they are not heavily used during the busy hourswhen MGW is handling an extensive number of simultaneous calls.

2.9 Codecs and speech transcoding in MGW

Codecs

The following table lists the codecs that MGW supports in different interfaces:

Table 9. Codecs supported by MGW in different interfaces

Codec Interface

Nb Iu Mb/Fss A/PSTN/Nb TDM

Ater Up_CS

G.711 A-law x x x

G.711 ¼-law x x x

GSM EFR x x x x

GSM FR x x x

FR AMR x x x x

HR AMR x x x

UMTS AMR x x x


dn0497801Issue 6 en


Table 9. Codecs supported by MGW in different interfaces(cont.)

Codec Interface

Nb Iu Mb/Fss A/PSTN/Nb TDM

Ater Up_CS

UMTS AMR2

x x x

UMTS AMR-WB

x x x

iLBC x

G.723.1 x

G.729 A/B x

Note

G.711 20ms in the Nb interface is a Nokia proprietary solution. This solution isalso referred to as Nb'.

For more detailed information on the supported codecs, see table Details of thesupported speech codecs in Codecs and transcoding in MGW.

Speech transcoding in MGW

In the 3G network, the transcoding function resides on the core network side ofthe Iu interface (whereas in the 2G networks, the transcoders are on the BSSside). MGW is able to transcode between mobile codecs and G.711.

MGW supports transcoding between any of the supported codecs, and need fortranscoding is determined in the MGW from codec information received fromMSS. If allocated codecs in different call parties are not compatible, thentranscoding via linear domain (PCM/G.711) is applied. When the speech signal isavailable in linear PCM format, the traditional linear domain, speechenhancements such as ALC, AEC, and EC can be applied. ALC is also applied tosignal in coded domain.

dn0497801Issue 6 en


43 (111)


2.10 Speech enhancements in MGW

Table 10. Speech enhancements in MGW


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Electric echo cancellation(EC)

PSTN/PLMN

Optional


Iu-CS Iu-CS, A,Ater

Optional

Automatic Level Control(ALC) and fixed gain

x x

(Not in Nb)



dn0497801Issue 6 en


Figure 9. Location of echo cancellers in the network

2.10.1 Electric echo cancellation (EC) in MGW

Speech calls from the 2G/3G mobile system to PSTN are terminated on localswitch line cards where the two-wire to four-wire conversion takes place. Thehybrid used to carry out this function is never perfect and echo is generated in thedownlink direction which degrades the speech call quality for the 2G/3G mobileuser. To overcome this situation, an echo cancellation functionality is used inMGW in calls between PSTN and mobile network. This echo cancellationfunctionality conforms to ITU-T G.168 recommendation.

BSCBSC

MSC Server /Gateway ControlServer (GCS)

MSCServer

A

Ater

H.248

BICC CS-2,SIP-T

RNCMGW

ATM /IP/ TDMbackbone

MGW

Iu-CS

Nb

HLR

WCDMA

H.248

PSTN/ISDNTDM

AEC

TDM

GSM

EC

PSTN/ISDN

AEC

AEC

AEC

EC

Ater

TC A

AEC

dn0497801Issue 6 en


45 (111)


Speech calls from the 2G/3G mobile system to the PLMN (for example, GSM) donot require the electric echo cancellation functionality in MGW. It is desirable toprevent multiple echo cancellers in the connection. Therefore, the echocancellation functionality in MGW is enabled/disabled by the signallinginformation.

See figure Location of echo cancellers in the network for places of echocancellers.

Functionality

To deal with the echo generated in the downlink direction, that is, the PSTNelectrical echo generated in a hybrid, there is an echo canceller in MGW. Theecho canceller memorises the voice samples sent to the PSTN and then comparesthe samples to the voice samples received back from the PSTN. These speechsamples (containing the echo) are modified by the echo canceller to prevent theecho effect from being passed back to the mobile.

In the uplink direction, the PSTN phone user hears an acoustic echo as his/hervoice is transmitted back from the mobile phone and he/she experiences delaygenerated both in core network and radio network. To deal with this echo, themobile phone is equipped with a built-in acoustic echo canceller and an AECfunctionality is provided on the network side by MGW.

MSC Server controls the use of electric echo cancellation in MGW dynamicallyon a per-call basis based on EC control information conveyed in network-levelsignalling.

MGW can deactivate the EC also autonomously when fax/modem-related signalis detected inside the user plane.

2.10.2 Acoustic echo cancellation (AEC) in MGW

Acoustic echo is generated in the uplink direction due to the acoustic couplingfrom the ear-piece to the microphone of the User Equipment (UE). Acoustic echois removed by a built-in acoustic echo control device of the UE/MS (Mobilestation). Sometimes this is not sufficient, and therefore an AEC functionality isprovided on the network side by MGW. The use of AEC is controlled byinterface-specific parameters for Iu, A, and Ater in MGW. MSC Server does notcontrol the use of AEC.

See figure Location of echo cancellers in the network for places of acoustic echocancellers.


dn0497801Issue 6 en


2.10.3 Automatic level control (ALC) in MGW

The performance of the different equipment in the speech path varies dependingupon the signal levels. Each active device, such as an amplifier or speech codec,has a certain dynamic range over which it functions to specification. Outside thisrange the performance may degrade rapidly, leading to noise and distortion ofvarious types. For this reason, it is important to maintain speech levels within thedynamic range specified for the equipment.

Automatic Level Control (ALC) is a useful solution to this problem. It providesan effective, non-obtrusive means of improving the perceived speech quality of acall by automatically optimising active speech levels. Varying speech levels arereacted to by software, adjusting the appropriate parameters in real time to anoptimal operating level. In ALC, gain is adjusted towards the given target activespeech level and in fixed gain, the gain is given by fixed dB levels.

In MGW, noise compensation provides an additional ALC enhancement. ALCuses noise compensation to adjust the signal level according to the opposite pathnoise level. Egress direction ALC performed in MGW is controlled by the noiselevel measured in the ingress direction of the same termination. That is, noisecompensation adjusts the target level of the opposite path depending on the noiselevel. When the noise level exceeds a certain threshold, the target level starts toincrease. Noise compensation improves intelligibility when the user is in a noiseenvironment.

In addition to linear PCM gain adjustment, ALC can also be applied straight tocoded speech parameters. This is called Coded Domain ALC (CDALC). Codeddomain processing is supported for EFR, FR, AMR and AMR-WB coded speech.The benefit of the CDALC is that TrFO or TFO can be used simultaneously withALC. However, CDALC cannot be applied to the following transparent TFOconnections:

. A-A

. PSTN-PSTN

. Mb-Mb

2.11 2G TFO in MGW

dn0497801Issue 6 en


47 (111)


Table 11. 2G TFO in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

2G TFO x Optional


Tandem free operation (TFO) is a mechanism which can be used in-band todetermine the speech codecs used on the transcoders in a call. If compatiblecodecs are used, the transcoders start embedding the encoded speech parametersin the least-significant bits of 64 kbit/s link. Nokia MGW supports TFO for GSMFR and GSM EFR speech codecs, thus providing optimised inter-operability withlegacy GSM networks. TFO is not supported in MGW for UMAwhere the onlysupported codec is FR AMR.

MGW also uses TFO for optimising the bandwidth needed per call. The basicintention is to relay the access side codec unchanged through the IP or ATMbackbone towards another MGW.

MGW responds to TFO negotiation autonomously. With the commands of the JVcommand group, you can configure whether MGW initiates the TFO negotiationautonomously or whether MSC Server requests MGW to initiate the TFOnegotiation by H.248 control.


dn0497801Issue 6 en


Figure 10. 2G Tandem Free Operation

Functionality

TFO with the payload optimisation functionality in MGW includes

. acting as a peer TFO towards A-/PSTN interface

. operating in a codec relay mode (passing speech samples transparentlywithout transcoding)

Pure TFO is a mechanism performed by the transcoders using in-band signalling.The peer transcoders communicate with each other using bit-robbing signallinginside a 64 kbit/s channel. If the transcoders realise that a common codec isavailable, they override the part of the 64 kbit/s channel with a compressed codec,which is eventually used by both ends.

As regards the benefits, TFO provides optimised speech quality. Traditionally, acompressed speech codec used in radio interface is transcoded to the G.711 codecwhen connected to core network, which decreases speech quality. With IP/ATMTrunk, the intention is to agree on a common codec for all the call legs, anddisable/bypass the transcoding stages from the speech path. The transcoding isneeded when the call is routed to the PSTN.

MGW STRIPSTHE 'UNNECESSARY'

BITS AWAY

MSS MSS

IP/ATM network

BSC BSC

MGW MGW

TC TC

CODEC NEGOTIATION

TRANSPARENT COMPRESSED SPEECH CONNECTION

TFOPEER

A A

CODEC

TFOPEER

TFO ENABLEDBY FIFILE

CODECCODEC INTFO FRAMING

CODEC ONLYOVER IP/ATM

INBAND TFONEGOTIATION

INBAND TFONEGOTIATION

TRANSMISSION SAVINGSDUE TO COMPRESSED CODEC

dn0497801Issue 6 en


49 (111)


2.12 TrFO in MGW

Table 12. TrFO in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

TrFO x Optional


The purpose of transcoder-free operation (TrFO) is to completely remove theunnecessary transcoding from the speech path. This is achieved with an out-of-band signalling which performs the codec negotiation and selection throughoutthe network. Optimally, this means that speech transcoding is only performed inthe peer UEs (User Equipment, 3G terminal).

TrFO is standardised for 3G calls only (that is, calls via UTRAN). A standardway of utilising TrFO in IMS-CS interworking cases has also been specified by3GPP. It provides optimised speech quality and enables substantial savings intransmission capacity in the core network. Only compressed speech samples aretransmitted over the ATM/IP networks and the default codec for 3G networksrequires less than 16 kbit/s capacity (in comparison to the 64 kbit/s for transcodedspeech). This results in savings in both network transmission and MGW capacity.

TrFO is based on 3GPP specifications for bearer-independent circuit switchedcore network where the control plane is handled by the MSS, and the user planeby MGW. Thus, in 3GPP bearer-independent network architecture, MSSperforms the negotiation and selection of the codec used in the user plane, whileMGW handles the user plane protocols and provides a speech connection withouttranscoding, when possible.

With TrFO, the used speech codec is negotiated throughout the network,involving both the user terminals and all the MSC Servers controlling the callsetup. MSS indicates the user plane parameters and the selected codec to MGW.When two terminations have a common codec and codec mode, thetranscoderless transmission is done.


dn0497801Issue 6 en


Figure 11. 3G Transcoder-free Operation

The decision on the use of TrFO is made according to the result of thisnegotiation: either the transcoding is left out completely or it is performed at theedge of the PLMN/3G network, that is, at the 2G or PSTN interconnection.

TrFO is applicable in the MSC Server environment and in IMS/UMAinterworking cases.

2.13 Signalling Gateway (SGW) in MGW

Table 13. SGW in different MGW network environments


MGW forMSC

MGW inUNC (UMA)*)

MGW forMSS

SGW x x

MSS MSSCODEC NEGOTIATION

CODECLIST

MGW MGW RNCRNC

Iu cs Iu cs

COMPRESSED SPEECH CONNECTION WITHOUT TRANSCODING

IP/ATM networkTC TCNb

CODECLIST

AMR AMR AMR AMR

TRASCODERS NOTIN SPEECH PATH

dn0497801Issue 6 en


51 (111)



With the Signalling Gateway (SGW) functionality, SS7-based signalling trafficfrom MGW is transported to IP-based traffic towards MSC Server or vice versa.This is done by changing the TDM/ATM transport layer to SCTP/IP transport forIu-CS, A-, Ater, and PSTN/PLMN interfaces. Transporting is done on the SS7MTP3 -level by using SIGTRAN protocols.

A Signalling Point Code (SPC) uniquely identifies a signalling point in asignalling network. It indicates the destination network element of signallingmessages. Signalling Transfer Point (STP) acts as a link between two signallingpoints through which signalling traffic can be routed to destination.

Signalling Point Management Cluster (SPMC) is an entity that consists of theSGW and an application node, but is visible to other network elements as oneSPC only, that of the application node. In the MSC Server system, SPMC makesit possible to combine both MGW and MSS under the same SPC towards BSC,RNC or a PSTN exchange. Only the SPC of the SPMC is visible to the oppositeend, and MGW acts as STP for MTP traffic.

SPMC is useful when a signalling point becomes an application node that isconnected to a SGW, and therefore stripped of its MTP level 2 connections tonetwork elements other than the SGW. In that case, other network elements needno configuration changes as they see nothing from the management cluster butthe same old signalling point code. Thus, transition from signalling points toSPMCs is especially useful when migrating from MSCs to MSC Server system.

It is generally recommended that network element -specific SPCs are usedthroughout the network because their use provides the best option for managingthe states of network connections. But whenever it is more important to combineboth MSS and MGW under the same SPC, SPMC is recommended.


dn0497801Issue 6 en


Figure 12. SGW interfaces and protocols

Functionality

The functional model for SGW in the bearer independent circuit-switched corenetwork is based on SIGTRAN principles of architecture framework for transportof message-based signalling protocols over IP networks. For more information,see RFC 2719: Framework Architecture for Signaling Transport.

BICC / SIP

MSC Server

signalling

user plane

MGW MGW

IP/ATM/TDM

BSSAP

A/Ater

MSC Server

GSM BSS

WCDMA RAN

RANAP

Iu-CS

Nb

SS7 (MTP3)

H.248 control

SS7 (SCCP)

Nb

(BSSAP)

SGW SGW PSTN/PLMN

dn0497801Issue 6 en


53 (111)


In MGW , the signalling transport is done for the Iu-CS, A, and PSTN/PLMNinterfaces by changing the TDM/ATM transport layer (SS7 MTP L3 signalling)to SCTP/IP transport. The used SCTP type may be either multihoming or singlehoming. The supported transporting technologies are:

. ATM <-> IP

. TDM <-> IP

. ATM <-> IP/ATM

. TDM <-> IP/ATM

. ATM <-> TDM

The signalling transport protocols are:

. RANAP (SS7): ATM <-> IP

MSC Server receives RANAP messages by using the SIGTRAN as anunderlying protocol stack to provide reliable and SS7-compatible layer forIP transport. In the Iu-CS interface, RANAP signalling messages arecarried over broadband SS7 protocol stack.

. BSSAP (SS7): TDM <-> IP

MSC Server has to provide the BSSAP protocol in order to support legacyGSM MS. It is possible that the A-/Ater interfaces (where the BSSAPprotocol is used) terminate either to MGW or directly to MSC Server.

MSC Server receives BSSAP messages from MGW by using theSIGTRAN as an underlying protocol stack to provide reliable and SS7-compatible layer for IP transport.

. MAP/CAP/INAP (SS7 SCCP): TDM <-> IP

For transporting transparently SS7 signalling which needs the SCCP-layer's services (MAP/CAP/INAP), signalling transporting between PSTN/PLMN network and MSC Server over IP is made by using SIGTRANM3UA/SCTP (SS7 MTP3-User Adaptation Layer / stream controltransmission protocol) protocols.

. ISUP/TUP/IUP (SS7 MTP3): TDM <-> IP

For transporting SS7 signalling which needs the MTP-layer's services(ISUP/TUP/IUP), signalling transporting between PSTN/PLMN networkand MSC Server over IP is made by using SIGTRAN M3UA/SCTP (SS7MTP3-User Adaptation Layer / stream control transmission protocol)protocols.


dn0497801Issue 6 en


2.14 In-band tones and continuity check in MGW

Table 14. In-band tones and continuity check in differentMGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

In-band tones andcontinuity check

x


Because the user plane goes through MGW, there needs to be a functionality forgenerating and detecting in-band tones. The continuity check functionality isrequired when PSTN connections are terminated to MGW.

In MGW, tones, Dual Tone Multi-Frequency (DTMF) and continuity check areprovided by Digital Signal Processing (DSP), located in the TCU functional unit.MSC Server controls the MGW tones, DTMF, and continuity checkfunctionalities through the H.248 MEGACO interface.

The same tones that are available in the MSC are also available and grouped intotone sets into MGW. One tone set is selected from the group.

The tones in the MGW are made according to the MSC specifications. You cancheck the PRFILE tone parameter 043:0009 value by using the WOI commandand modify it by using the WOC command.

With the National Tones Handling MML (commands of the W5 command group),you can interrogate, distribute, modify, and reload tones and DTMF signals inMGW.

Functionality

Tone Generation

dn0497801Issue 6 en


55 (111)


MSC Server requests MGW to generate a tone by an H.248 command. MGWthen reserves tone resources and generates a tone into the bearer. Finally, the tonerequest is acknowledged to MSC Server.

The tone generation on a termination in MGW can stop by itself or it is stoppedwhen MSC Server requests it.

MGW informs MSC Server about the tone completion if the tone type is time-out.

DTMF Generation/Detection

MSC Server requests MGW to generate DTMF using the Basic DTMF Generatorpackage. MGW then makes DTMF resource reservations and generates therequested DTMF tones into the bearer. MGW sends a reply to MSC Server afterthe DTMF tones are generated.

MSC Server may request MGW to stop the DTMF generation. MGW thenreleases DTMF-related resources and acknowledges MSC Server.

MSC Server requests MGW to start DTMF detection by an H.248 commandusing DTMF detection package (which extends tone detection package). MGWthen makes DTMF resource reservations and starts the DTMF detection. Finally,MGW indicates all detected DTMF tones.

MSC Server requests MGW to stop DTMF detection. MGW then releasesDTMF-related resources and informs MSC Server about stopping the DTMFdetection.

The usage of the RTP payload format for DTMF digits from IMS towards the CSnetwork is supported. In this mechanism, DTMF tone events are sent as separateRTP packets instead of in-band audio signals in the RTP stream. MGWdifferentiates these packets by the RTP payload type and extracts the necessaryinformation (such as DTMF digit type and duration) from the RTP packetpayload. DTMF digits can be reproduced as in-band audio signals or indicated toMSC server for out-band signalling.

Continuity check in MGW

Continuity check can be used for checking the condition of an external circuit. Inthe TDM interfaces, the test tones are used for checking that the loopbacked toneis similar to to the sent test tone. MGW has two possibilities for participating inthe continuity check:


dn0497801Issue 6 en


. Loopback

MSC Server requests a loopback from MGW. MGW then makes theloopback connection and sends a reply to MSC Server. When thecontinuity check has been performed, MSC Server requests to release theloopback connection and MGW releases the loopback connection andsends a reply to MSC Server.

Loopback is supported in the TDM interface only.

. Signal sending and detection

MSC Server requests the transceiver functionality for continuity checkfrom MGW. MGW then reserves the DTMF detection and tone resourcesfor continuity check and starts the continuity test tone sending anddetection. MGW sends a reply to MSC Server after the resources arereserved. Finally, MGW informs MSC Server of the result when thecontinuity check has been performed and releases the reserved resources.

Continuity check for Israeli ISUP T904 is also supported.

2.15 Announcements in MGW

Table 15. Announcements in different MGW networkenvironments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Announcements x


The same announcement functionalities are provided in MGW as in MSC Server.

Announcement files are loaded from and administered in OMU with the MediaGateway Announcement File Handling (JA) MML. Language tags areconfigured using Context Manager Settings Handling (JL) MML.

dn0497801Issue 6 en


57 (111)


Functionality

Announcement speech format is 64 kbit/s coded with the A-law/¼-law codec. Thenetwork operator is responsible for storing speech recordings in the right format.Announcements are generated from MGW in the format they are needed for thesubscriber (for example, AMR-coded). Announcement sample files are stored inVANU.

The functional unit TCU is used for inserting an announcement from a giventermination point to the user connection. The speech recordings are transcodedwith a suitable codec when needed.

MSC Server's call control requests announcements in different call phases. Whenthe user plane is in MGW, MSC Server requests announcement connections fromMGW using the H.248 protocol (MEGACO). References to announcement partssuch as speech recordings and variable parts are transferred with the 'H.248.9Advanced Media Server Package' and 'H.248.7 Generic Announcement Package'to MGW, where the announcement is built up and added to the user plane incorrect format (64 kbit/s coded with the A-law/¼-law codec). The MGWannouncement service selects VANU, connects announcements internally to theuser plane termination (TDM, ATM, IP) and replies. MGW ends theannouncement with a MEGACO request received from MSC Server.

Figure 13. MGW announcement environment

Multimedia Gateway

AnnouncementService

TDM,ATM,IP

TDM,ATM,IP

C1

H.248 commandsfrom MSC Server

X

VANU


dn0497801Issue 6 en


The MGW announcements service provides the following:

. possibility to transfer multilingual variable announcements

. G.711 format pcm 64kbit/s channel speech quality

. announcements generated near a user plane resource gain transmissionsavings compared to a pcm circuit -connected media resource function

. a solution suitable for further IP 'announcements' as packet file sending (forexample, graphic and video).

2.16 Nokia MGW in Nokia UMA solution for GSM

Table 16. Nokia MGW in Nokia UMA for GSM solution in different MGWnetwork environments


MGW forMSC

MGW inUNC(UMA) *)

MGWfor MSS

Interworking servicefor UMA access (A/A+conversion)

x x Optional

*) MGW as part of the UMA for GSM solution.

Nokia MGW enables UMA also in multivendor environments with Nokia UMAsolution for GSM by providing signalling conversion between the A+ interfaceand the standard A-interface by MGW, and by connecting the user plane (TDM)in the A-interface and RTP/IP in the A+ interface.

The A/A+ conversion functionality is co-located in MGW. This solution does notrequire any external control interface from, for example, MSC Server (H.248).Nokia MGW user plane resources are controlled by the A+/A conversionfunctionality via an internal control interface.

Nokia MGW handles transcoding between FR AMR and G.711. In addition,Nokia MGW acts as a signalling gateway between the INC (IP networkcontroller) and MSC. Text Telephony (TTY) is supported with UMA in MGW.TTY is delivered as AMR-coded CTM (cellular text telephone modem ).

dn0497801Issue 6 en


59 (111)


The MGW for Nokia UMA solution for GSM is distributed into the sites whereMSCs are located. It is also possible to use Nokia MGW simultaneously forUMA traffic in Nokia UMA solution for GSM and as MGW for MSS/MGW forIMS/MGW for UMA (MGW cannot be used for UMA traffic in Nokia UMAsolution for GSM and as MGW for MSC simultaneously).

The interworking service for UMA access (A/A+ conversion) is an optionalfunctionality.

Signalling network configuration

To be able to have transparency between UMA network controllers (UNC) andMSCs, MGW must have additional signalling point codes which are dedicated tothe UNC-MSC connection. In this case a dedicated MGW signalling point isconfigured to MSC to point a UNC (and vice versa).

When dedicated signalling point codes are used, it means that even though the A-interface terminates to MGW, the MGW functionality is transparent to MSC, andMSC sees the UNC behind MGW.

After the signalling configurations for the A+ interface (UNC) and A-interface(MSC) have been defined in MGW, the additional signalling point codes areconfigured using the Network Element signalling Connection Handling (W8)MML commands. See also Overview of configuring UMA solution for GSM inMGW.

2.17 Ater interface in MGW

Table 17. Ater interface in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Ater interface x Optional



dn0497801Issue 6 en


In GSM networks, transcoding is part of the Base Station Subsystem (BSS).Typically, transcoding is performed in a separate standalone network element andthe interface between the Base Station Controller (BSC) and the transcoder (TC)is called Ater. In the Nokia BSS solution, the standalone transcoder is calledTranscoder Submultiplexer (TCSM).

In the WCDMA architecture, the transcoding functionality is specified to be partof the core network. In the Nokia WCDMA solution, transcoding is located inMGW.

As MGW includes the transcoders for WCDMA, the same investment can beused also for GSM, as MGW supports the GSM transcoding functionality and theMSS system is applicable for both WCDMA and GSM. Therefore, this solution isoffered as an alternative to the current standalone 2G transcoder product forNokia system customers.

All critical TC functions currently provided by Nokia 2G standalone transcoderare supported. The functionalities include for example:

. TRAU-framing, synchronisation, handovers, time alignment for data andspeech

. Multi-rate functionality and support for in-band call type/codecmodification

. CS data rate adaption (ATRAU, ETRAU, V.110) and HSCSD functionality

Ater in MGW supports the following Voice and Data Services:

. GSM transcoding (FR, EFR, AMR) and sub-multiplexing (16/32/64 kbit/s)

. Speech enhancement features, for example Acoustic Echo Cancellation(AEC), Automatic Level Control (ALC)

. Tandem Free Operation (TFO) for FR and EFR codecs

. Special functions, for example Text Telephony (TTY)

The Ater interface is provided via E1/T1/JT1. MGW supports the circuit pooltypes used in BSC and MSS (MSC Server) in order to avoid changes in the BSCand MSS.

GSM transcoder resources in MGW are grouped into a single DSP pool used forall MGWAter connections, and all codecs and DSP services are provided fromthis same pool. With this principle, it is possible to use the GSM transcodingservice without affecting the call processing capacity of MGW for other services.The allocation of transcoding resources to Narrowband Ater/A Service Pool and�non-Ater� pool is done via management commands.

dn0497801Issue 6 en


61 (111)


Ater in MGW is an optional feature.

STM-1 support and HR codec for Ater is planned for later MGW releases.

2.18 Data calls in MGW

Table 18. Data calls in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Data calls x x


Data calls in MGW for MSC

Circuit-switched data adaptation is needed when narrowband circuit-switcheddata service is used in conjunction with the UTRAN (UMTS terrestrial radioaccess network). In MGW for MSC, data is converted from the GSM form to theIu interface form.

The data rates supported in the Iu interface with the transparent service are 28.8,32, and 64 kbit/s. In the transparent circuit-switched service, the Iu user plane isused in transparent mode which means that the Iu user plane has no framingspecified for the mode.

In case of transparent calls, the rate adaptation between 32 kbit/s and 64 kbit/s ismade in MGW for MSC.

In the non-transparent circuit-switched service, the Iu user plane is used insupport mode which means that Iu user plane has framing specified for the mode(including both control and data frames). In the Iu interface, the data rates can bedifferent in uplink/downlink directions (that is, asymmetric configuration).


dn0497801Issue 6 en


Data calls in MGW for MSS

Generally, the user plane data format used in either A or Iu-CS interfaces cannotbe used towards a legacy fixed network in GSM and UMTS circuit-switched datacalls as such. This is because the user data terminal in legacy fixed network doesnot usually understand the data format used in GSM and UMTS circuit-switcheddata calls. The conversion between these data formats is made in a facility calledInterworking Functionality (IWF). IWF is located in MSC Server or in CDS.Circuit-switched data is routed through IWF using interconnecting TDMconnections between MSS and MGW.

Depending on the call case, the IWF is controlled either by MSC Server internallyor by MGWover IP connection using a proprietary protocol. MGW supports TCPand SCTP as transport types. The IWF control interface between MGWand MSCServer enables IWF to be located basically in any MSC Server. It also enablesIWF to be separated from MSC Server to a standalone element.

With the Media Gateway Element Handling MML (JC), you can add, modify,and delete IWF entries, interrogate IWF priority list and network element, selecthunt method, and modify the IWF connection status.

Data call in the A/Ater interface

ATRAU or V.110' user plane protocol is used in the A/Ater interface. Thisprotocol as well as Radio Link Protocol (in case of non-transparent call) isterminated to IWF.

Data traffic channel towards BSC is hunted from free resources allocated for datacall use.

Interconnecting TDM resources between MSC Server and MGW are used forconnecting user plane of data calls between MGW and IWF located in MSCServer. Free TDM resources are hunted in MSC Server.

dn0497801Issue 6 en


63 (111)


Figure 14. Data call in A-interface - Integrated MSS

Figure 15. Data call in A/Ater interface - Standalone MSS

Data call in the Iu-CS interface

The Iu-UP protocol is used in the Iu-CS interface. Iu-UP is packed inside AAL2SDU. This framing allows either transparent or non-transparent data services. Inthe transparent case in which the IWF is not involved, Iu-UP is in 'transparentmode'. The data rates supported in the Iu-CS interface with the transparent service

MGW

C1T1 T4

C2T2

T3ATM

BSS

PSTN/ISDN

BSSAP BICCIP

ATRAUor

V.110'(+RLP)

MSS-A

MGW AAL2

H.248 Interconnecting TDM

MSS-B

H.248

ISUP

V.110/V.120or

V.x Modem

Data

Control

IWF

BICC

C1T1 T4

C2T2T3

BSS

IPMSS-A MSS-B

MGW MGW

H.248Interconnecting TDM

IWF ctrl

AAL2ATM

H.248

ISUP

V.110/V.120or

V.x Modem

PSTN/ISDN

Data

Control

ATRAUor

V.110'(+RLP)

IWF

BSSAP


dn0497801Issue 6 en


are 28.8, 32, and 64 kbit/s. In case of transparent calls of 64 kbit/s, no rateadaptation is needed. In case of transparent calls of 32 kbit/s, the rate adaptationbetween 32 kbit/s and 64 kbit/s is made in MGW for MSS. In case of transparentcalls of 28.8 kbit/s, the rate adaptation is made in IWF.

Conversion from Iu-UP to ATRAU' is done by the TCU functional unit in MGW.This conversion has to be done when data traffic is received from MSC Server orsent towards MSC Server.

The Iu interface is connected to MGW, and IWF control parameters are sent fromMSC Server to MGW when data call terminations are created. MGW builds theIWF leg and controls the IWF.

Figure 16. Data call in Iu interface

Fax and modem detection

In PSTN-originated calls, the control plane signalling (for example, ISUP) doesnot always carry the necessary information for differentiating between the speech,fax and modem data calls. Thus, if a compressed codec, echo canceller, or otherspeech enhancement is used, the fax and CS data calls fail. Fax and modemdetection makes it possible to optimise the use of backbone transmission resourceso that compressed speech codec is used for speech calls and G.711 is used forfax and modem data calls. After MGW has notified the detection of fax or modemtone signal, MSC Server initiates a codec modification procedure to change thebackbone codec to G.711.

Fax and modem detection is supported in the PSTN, Mb and Nb interfaces.

BICC

C1T1 T4

C2T2T3

RAN

IPMSS-A MSS-B

MGW MGW

H.248

InterconnectingTDM

AAL2ATM

H.248

ISUP

V.110/V.120/V.34

PSTN/ISDN

Data

Control

lu_up(+RLP)

IWF

CDSP

RANAP

IWF ctrl

dn0497801Issue 6 en


65 (111)


Fax/Modem over IP by using passthrough and clearmode codecs in MGW

The modem passthrough over VoIP (voice over IP) is used in the existing VoIPsolutions in order to provide the transport of modem signals through a packetnetwork by using the passthrough channel. Fax/modem data transported inpassthrough channel is encoded according to the G.711 A-law or ¼-law,depending on the configuration. The operator can also configure the RTP payloadvalue used for passthrough channel data. Also the interface (Mb/Nb) in which thepassthrough mechanism is used, can be configured by the operator.

When MGW detects a fax or modem negotiation -related signal, it performspassthrough switchover without MSS control and starts to use the preconfiguredpassthrough channel for sending and receiving fax/modem data. In this situation,MGW disables those speech processing functions that may be harmful for fax/modem data, such as Echo Canceller (EC) and Adaptive speech Level Control(ALC), for example.

This feature also supports the use of the clearmode pseudo-codec. The clearmodepseudo-codec is specified to carry 64 kbit/s channel data transparently in RTPpackets through VoIP networks (Mb/Fss). The clearmode pseudo-codecfunctionality can be used with or without the passthrough mechanism. Togetherwith the passthrough functionality, the clearmode pseudo-codec enables supportfor fax/modem data calls in most IMS-CS interworking situations.

When a standardised clearmode mechanism is supported by both MSS andMGW, the MSS system always tries to use it in the Mb/Fss interface for fax/modem data calls. However, also the passthrough mechanism is needed in orderto handle cases where the use of clearmode is not possible (for example, when theSIP client does not support clearmode).

Passthrough and clearmode methods can be used together with the fax/modemdetection functionality. This gives the operator a possibility to further optimisethe core network�s transmission capacity for IMS-CS interworking speech calls.

2.19 Text Telephony service for 3G calls in MGW


dn0497801Issue 6 en


Table 19. Text Telephony service for 3G calls in differentMGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Text Telephony servicefor 3G calls

x x Optional


TTY is a functionality that enables text-based communication over a speechbearer. It is mainly intended for people with impaired hearing or speech. Thefeature is specified by ITU-T, and it is a regulatory requirement in the USA foremergency calls. However, TTY is not only for US emergency calls, as it can beused worldwide for ordinary calls between persons who require the use of texttelephony.

Figure 17. Text Telephony between a mobile and fixed terminal

Mobile TTYterminal

FixedTTY

terminal

w r

Hello Mary!

Hello Brian! How... Hello Mary!

Hello Brian! How are...

TELEPHONENETWORK

a

dn0497801Issue 6 en


67 (111)


TTY support requires special functionalities from mobile networks. In 2Gnetworks the feature is implemented in the transcoder submultiplexer (TCSM)and in MGW when the Ater interface/2G TC in MGW is deployed. To enable thesame level of support in 3G as well, the functionality is implemented in MGW.

When using TTY, text is transmitted through ordinary speech traffic channels. Ina fixed network the text is transmitted using ITU-T V.18 signalling. In cellularnetworks text cannot be transmitted reliably using ITU-T V.18 signalling, becausecellular systems are optimised for speech (speech codecs) and radio interfacesmay cause relatively high error rates. Instead, TTY signalling in cellular systemsis transmitted reliably using cellular text telephone modem (CTM) signallingspecified by the 3GPP.

Reliability is achieved by an improved modulation technique, including errorprotection, interleaving and synchronisation. MGW has interfaces to both fixedand cellular networks, and it is able to make conversions between the two TTYsignalling types. Towards interfaces where G.711 is not used, MGW uses CTMsignalling. Towards interfaces where G.711 is used, MGW uses traditional ITU-TV.18 signalling.

Note

MGW supports only baudot code protocol 45.45 of the ITU-T V.18 standard.


dn0497801Issue 6 en


Figure 18. Text Telephony signallings supported by MGW

Call-based Global Text Telephony enables call-based control of the functionality.In MGW, CTM can be activated in three alternative ways:

. on a call-by-call basis under MSS�s control

. for every call without MSS�s control

. only for emergency calls and without MSS�s control.

The Nokia MSC Server supports the call-based Global Text Telephony.

CTM Adaptor

CTM TTY signalling

Traditional ITU-TV.18 TTY signalling

HLR

MGW

BSC&TC

RNC MGW

BICC CS-2, SIP-T,ISUP

Iu-CS

MSCServer

H.248

Other PLMN

PSTN/ISDNH.248

A

A

IP/ATM/TDMBackbone

WCDMA

GSMMobile TTYterminal

FixedTTY

terminal

GatewayControlServer

BSC

IMS

Ater

dn0497801Issue 6 en


69 (111)


2.20 Connection capacity licensing in MGW

Table 20. MGW connection capacity licensing functionality in different MGWnetwork environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

MGW connectioncapacity licensing

x Optionallicence-basedfunctionality


The MGW connection capacity licensing means a possibility to purchase theMGW call throughput capacity according to operator needs. The MGWconnection capacity licensing is based on the cumulative maximum number ofavailable H.248 contexts in the MGW element.

The H.248 contexts are allocated in the ISU functional unit when making theconnection through incoming and outgoing MGW interface. One context is usedper one connection, but some special cases (such as multi-party and lawfulinterception) reserve an additional context. The purchased MGW HW capacitymust enable more capacity than the purchased MGW connection capacity licence(one ISU is able to handle a maximum of 3000 contexts) in order for the operatorto be able to use all licensed MGW-level connection capacity.

With the Licence and Feature Handling MML (W7), it is possible to install,activate and deactivate the MGW connection capacity licences. This MML alsoenables the checking of actual capacity usage level (number of used H.248contexts) in MGW. If licences are missing or they have not been activated, a basiccapacity of 100 contexts is provided.

2.21 Resource configuration in MGW for MSC

You can create, delete, modify, and interrogate the MGW for MSC -specificdefault parameters with the commands of the WE command group.


dn0497801Issue 6 en


The MGW for MSC -specific default parameters are:

. the destination point code of the MGW for MSC

. the destination point code of MSC

For more information, see Handling MGW for MSC -specific default parameters.

In MGW for MSC, you can add, delete, modify, and output both radio networkcontroller (RNC) -specific and location area code (LAC) -specific parameterswith the Radio Network Parameter Handling (E1) MML. You can also restart theRNC or mobile services switching centre (MSC) connected to the MGW forMSC with a command of this MML.

For more information, see Handling RNC-specific parameters in MGW for MSCand Handling LAC-specific default parameters in MGW for MSC.

You can interrogate and modify the cause code conversion parameters with theCause Code Handling (W2) MML

2.22 Interworking service (Iu - A' conversion) in MGW forMSC

Table 21. Interworking service (Iu-A' conversion) in differentMGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Interworking service x


dn0497801Issue 6 en


71 (111)


Signalling conversion between Iu and A' interfaces

Conversions of BSSAP' and RANAP procedures, signalling messages, andparameters in the MGW for MSC are needed because A' interface signalling fromthe MSC is not directly applicable at the Iu interface towards the radio networkcontroller (RNC) and vice versa.

The conversion function of the MGW for MSC can be divided as follows:

. direct conversion between BSSAP and RANAP

Procedures have equivalents at both interfaces but messages andparameters differ to some extent and need converting.

. conversion BSSAP' and RANAP

BSSAP' procedures are not included in GSM specification 08.08 but theyare needed to fulfill Iu interface signalling requirements. To functioncorrectly towards the RNC, the MGW for MSC needs information from theMSC which it does not get in standard BSSAP signalling.

. A' interface procedures which cause action at Iu interface

Procedures are not converted directly to equivalent Iu interface proceduresbut they cause other procedures at the Iu interface.

. Iu interface procedures which cause action at A' interface

Procedures are not converted directly to equivalent A' interface proceduresbut they cause other procedures at the A' interface.

. MGW for MSC -originated actions which cause signalling to either one orboth interfaces

. A' interface procedures which have no equivalents at Iu interface

Procedures terminate at the BSSAP'.

. Iu interface procedures which have no equivalents at A' interface

Procedures terminate at the RANAP.

Protocols and signalling

. SS7 and broadband SS7

Both the signalling system No.7 (SS7) and broadband SS7 protocol stacksare needed in the MGW for MSC.

For more information about SS7, see SS7 signalling.


dn0497801Issue 6 en


. AAL type 2 signalling protocol

The AAL type 2 signalling protocol provides signalling services forestablishing, maintaining, and releasing the AAL type 2 point-to-pointconnection between the MGW for MSC and RNC.

For more information about AAL type 2 signalling, see AAL type 2signalling protocol and ITU-T Recommendation Q.2630.1 AAL type 2Signalling Protocol (Capability Set 1).

. RANAP

The RANAP protocol is used at the Iu interface between the RNC andMGW for MSC. The RANAP protocol is described in 3G specification25.413 UTRAN Iu Interface RANAP Signalling (release 1999).

. BSSAP'

The BSSAP' protocol is used on the A' interface between the MSC andMGW for MSC. The standard BSSAP protocol is described in GSMspecification 08.08 (release 1999). However, all needed procedures are notincluded in the specification and therefore the modified non-standardBSSAP is used between the MSC and MGW for MSC. The non-standardBSSAP provides all information the MGW for MSC needs to functioncorrectly towards the RNC and to fulfill Iu interface signallingrequirements.

2.23 Multicall in MGW

Table 22. Multicall in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Multicall x


dn0497801Issue 6 en


73 (111)


The MGW for MSC supports the Multicall supplementary service. In Multicall, amobile subscriber can have several simultaneous CS calls, each using a dedicatedbearer.

In the MGW for MSS / MGW for IMS / MGW for UMA environments, MSCServer handles the multicall service.

2.24 Performance management in MGW

Table 23. Performance management in different MGWnetwork environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Performancemanagement

x x x


As MGW is an independent network element, it has to offer resourcemanagement capabilities to support operators since they need MGW performancedata to support network (element) dimensioning. By functionality, MGWperformance management can be divided into measurements and traceobservation. Measurements count events, data, or volume of the measuredobject(s). The measurement report is generated at the end of each resultaccumulation period.

For description of trace observation, see Trace observation in MGW.

In order to help the operator to optimal use of the network, MGW providesdetailed statistical reports on the resource usage related to different interfaces.Since MGW can be controlled by several MSC Servers, it is essential that thededicated resources are optimally utilised.


dn0497801Issue 6 en


The operator can define a certain statistical measurement to start immediately orat a certain point of time (date and time). The measurement is active until theoperator stops it or when the predefined end time is reached (on condition that theend time has been defined when starting the measurement). The operator candefine a period of time (from 15 up to 60 minutes) for the measurement reports,that is, how frequently measurement reports are generated. The recommendedmeasurement interval is 60 minutes.

The statistical measurements in MGW can be controlled by using theMeasurement Handling (T2) MML and/or the NE Measurement Explorer GUI inNEMU. However, there are two exceptions to controlling the measurements withthe T2 MML, namely, PDH an SS7 measurements. Their measurement structureis not the same as that of the other measurements, and their reports can be seen inMGW with an MML command or with NEMU's www browser.

MGW performance management consists of the following measurements:

Table 24. MGW measurements

Measurement MeasurementID (MID)

Applicable in MGW

MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Interface-specific TCmeasurement

512/200H x x

STM-1 interfacemeasurement

513/201H x x x

IMA logical interfacemeasurement

514/202H x x

SONET/SDH protectiongroup measurement

516/204H x x

ATM layer performancemeasurement

528/210H x x

ATM virtual pathconnection measurement

529/211H x x

ATM virtual channelconnection measurement

530/212H x x

AAL5 protocolmeasurement in DMX

547/223H x x

dn0497801Issue 6 en


75 (111)


Table 24. MGW measurements (cont.)


Applicable in MGW

MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

AAL5 protocolmeasurement in Chorus

549/225H x x

AAL2 Path CAC resourcemeasurement

550/226H x x

AAL2 signalling at NNImeasurement

552/228H x x

Ethernet interfacemeasurement

561/231H x x x

TCP/IP protocolmeasurement

563/233H x x x

Unit load measurement 592/250H x x x

Overload control with WACperformancemeasurement

594/252H x x x

Availability performancemeasurement

608/260H x x x

DSP performancemeasurement in MGW

614/266H x x x

RANAP protocolmeasurement

640/280H x

BSSAP protocolmeasurement

641/281H x

BID protocol measurement 642/282H x

Signalling transcodingmeasurement

643/283H x

Multi-party callmeasurement

644/284H x

Connection measurement 645/285H x


dn0497801Issue 6 en


Table 24. MGW measurements (cont.)


Applicable in MGW

MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

RTP/RTCP protocolmeasurement

646/286H x x

TrFO and TFOmeasurement

648/288H x

Data call measurement 649/289H x

Announcementmeasurement

656/290H x

H.248 measurement 658/292H x

Acoustic EchoCancellation measurement

660/294H x

User Plane initialisationmeasurement

662/296H x


MGWoffers long-term performance data rather than single call -related data. Onephysical MGW can be divided up to several virtual MGWs (VMGW).

The system produces a measurement report at the end of each result accumulationperiod. There are two ways to examine the measurement reports:

. By using NEMU's NE Measurement Explorer. For instructions, see UsingNE Measurement Explorer.

. By using Nokia NetAct. At the end of each result accumulation period, themeasurements reports are transferred to NEMU, from where they aredelivered to Nokia NetAct. The performance management post-processingfor the reports is done in NEMU. For more information on performancemanagement post-processing, see Performance ManagementFunctionalities in NEMU.

dn0497801Issue 6 en


77 (111)


2.25 Trace observation in MGW

Table 25. Trace observation in different MGW networkenvironments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

RANAP trace x

IMSI trace x

Monitoring erroneous Iuand A' interfacemessages

x

IMSI / IMEI traceobservation

x


As MGW is an independent network element, it has to offer resourcemanagement capabilities to support both operators and vendors. Operators needMGW performance data to support network (element) dimensioning, and vendorsneed data on network element performance (such as possible fault situations). Byfunctionality, MGW performance can be divided into measurements and traceobservation. For more information on measurements, see Performancemanagement in MGW.

RANAP trace in MGW for MSC

MGW for MSC uses RANAP trace for monitoring the conversion process fortesting and fault tracing purposes. When tracing, it is possible to get either themessage identity or full content of the message. You can also select whichmessages are monitored.


dn0497801Issue 6 en


RANAP trace can be started in two ways. First, it can be started by the mobileservices switching centre (MSC) by sending the msc_invoke_trace message toMGW for MSC. Trace can be invoked either in MGW for MSC or in both MGWfor MSC and radio network controller (RNC). Secondly, RANAP trace can bestarted locally via an MML command in MGW for MSC. In this case, trace canbe invoked only in MGW for MSC. The trace reports are stored on the OMUdisk.

IMSI trace in MGW for MSC

The IMSI trace in MGW for MSC is used for testing and fault solving. It providesinformation on the RANAP/BSSMAP messages and error codes for selectedIMSIs.

Monitoring erroneous Iu and A' interface messages

For internal fault solving, there is a cyclic buffer for erroneous messages. When aprogram block receives an erroneous message, the message is stored in the cyclicbuffer. The cyclic buffer can contain up to 200 erroneous messages and additionalinformation about the failure (for example, time of the failure).

Cyclic buffer is also used for storing error codes of user plane applications. Thecontents of the buffer can be output with MML commands.

IMSI / IMEI trace observation in MGW for MSS

MSC Server sends a trace activation (H.248 add command) to MGW viaMEGACO in a Nokia-specific package when the termination reservation isrequested by MSC Server. The maximum number of simultaneous trace cases inone MGW is limited and if the number of trace cases reaches the limit, MGWdiscards the trace activation and sends a notification to MSC Server if thenotification event has been armed.

MSC Server also sends an H.248 modify command to activate trace. The use ofH.248 modify commands enables trace activation also in MGW located on theother end of the ATM/IP/TDM backbone even though its termination is alreadyreserved. Thus it is possible to get trace reports in all call cases.

MSC Server can also deactivate IMSI/IMEI trace with the H.248 modifycommand.

The trace records generated in MGW are sent to the Nokia NetAct throughNEMU. The trace results are stored in MGW and the full report files aretransferred to NEMU after the trace event is finished. NEMU sends reports toNokia NetAct by using the Nokia proprietary NWI3 interface.

dn0497801Issue 6 en


79 (111)


Trace observation can be used by subscriber administration and networkmanagement for subscriber observation (for example, following a customercomplaint, or when the network operator suspects that an equipment malfunctionhas taken place). MSC Server includes an IMSI/IMEI type indication in the traceactivation that it sends to MGW, which makes it possible to monitor activesubscriber traces via the NetAct Trace Viewer. By utilising IMSI/IMEI typeindications, the NetAct Trace Viewer can be used to trace multiple subscribers(SIM cards) simultaneously.

Enhanced MGW trace database provides a logical database structure and plentyof space for traced terminations.

2.26 NEMU in MGW

Table 26. NEMU in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

NEMU x x x


NEMU (Network Element Management Unit) in MGW is composed of four plug-in units: Computer unit MCPC2A / MCP18, Ethernet switch unit ESA24 andduplicated hard disk units located in separate subracks. The NEMU solution forMGW is an integrated NEMU (MGW NEMU), located in the equipment cabinetsimilarly as the other MGW units. Note that OMU and NEMU plug-in units areconnected to the same hard disks.

MGW NEMU includes the following interfaces:

. printer (USB interface or serial interface)

. monitor (SVGA connector interface)

. keyboard (KB connector or USB interface)


dn0497801Issue 6 en


. mouse (mouse-connector [serial] or USB interface)

. external HD or MO-device (SCSI-interface)

. LAN (24 ports for 10/100 Mbit Ethernet).

In addition to providing an interface towards Nokia NetAct, NEMU provides,among others, the following functions related to external O&M interfaces:

. post-processing of fault management data

. post-processing of performance data

. post-processing of trace data

Communication between MGW NEMU, MGW, and other network elements iscarried out via Ethernet. NEMU uses the Windows 2000 server operating system.

For more information, see MGW Operability.

2.27 Fault management in MGW via NEMU

Table 27. Fault management via NEMU in different MGWnetwork environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Fault management inMGW via NEMU

x x x


dn0497801Issue 6 en


81 (111)


Fault management

The fault locationing procedure in MGW can be started by using MMLcommands. Alternatively, the fault locationing procedure in MGW can becontrolled with MGW Element Manager (EM) via the Fault Management (FM)Graphical User Interface (GUI).

The Fault Management GUI of MGW Element Manager allows the user tomonitor alarm situations (that is, viewing and cancelling active alarms, viewingalarm history, modifying alarm settings and controlling external alarms and alarmoutputs). The co-operation between different operating functions can be arrangedmore efficiently with the GUI applications than by using the traditional MMLs.The MGW EM user is able to change quickly from the configuration view to thealarm view. This reduces the time spent on finding and correcting the faultsituation in MGW.

External alarms control provides a way of making external, environment-triggered alarms. The easy-to-use GUI can be used for defining texts anddescriptions for alarms from external devices, and the Virtual lamp panel in FaultManagement GUI provides visual indication of alarm situations.

Fault locationing

The fault locationing procedure in MGW can be started by using MMLcommands. With the diagnostic history command, the user can poll the latestdiagnostic reports from the MGW. Alternatively, the fault locationing procedurein the MGW can be controlled with the MGW Element Manager (EM) via theDiagnostics and State Handling GUIs.

The Diagnostics GUI is used for executing hardware diagnostics tests for all unitsand subunits in MGW. Tests can be started at once, or as timed operations that areexecuted later according to a specified time. The Diagnostics GUI makes itpossible to perform history searches on individual test(s), or for reports that aremade on executed tests. If the automatic state handling is turned on, theDiagnostics GUI tries to change the state of selected unit to test executing state(TE-EX), if it is not already in that state. This feature enables easy-to-usegraphical diagnostics handling, thus reducing the effort needed to managediagnostics. The results of the procedure are automatically transferred to the EMas events, without manually polling the history file. The Diagnostics GUI islaunched via the Application Launcher.

The State Handling GUI implements Working State and Restarting HandlingMML commands, as well as I/O Unit Operating State Handling MMLcommands. The main operations that can be executed with the State HandlingGUI are:


dn0497801Issue 6 en


. unit state and info inquiry

. unit state change

. unit status change

. unit restart

. system restart

. I/O device state & info inquiry

. I/O device state change.

2.28 Performance Management functionalities in NEMU

Table 28. Performance Management functionalities in NEMUin different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

PerformanceManagementfunctionalities in NEMU

x x x


Performance Management (PM) post-processing is a Network ElementManagement Unit (NEMU) functionality which is used to transfer performancemeasurement result files from MGW to NEMU database. The operator can use anapplication called NE Measurement Explorer (GUI) to view and control all themeasurements and counters transferred to the NEMU database in textual form.

NE Measurement Explorer

The main components of the NE Measurement Explorer are the Explorer view,Measurement Management view and Browser starting dialogue.

Explorer view:

dn0497801Issue 6 en


83 (111)


The Explorer view of the NE Measurement Explorer is used for viewingmeasurement data stored to the NEMU database. The view contains the followingparts:

. measurement type list (for selecting a measurement)

. object list (for selecting the target object of the measurement)

. save time list (for selecting the save time of the measurement)

. counter list (shows all the counters of the selected measurement type)

. KPI list (shows all user-defined KPIs of the selected measurement type)

In NE Measurement Explorer, there are two ways to get the counter values of aparticular measurement. When the measurement type is selected, the user cansearch all measurement objects of the selected measurement type and then searchall the save times of the selected measurement object. Alternatively, the user canselect the measurement type first, then search for all the save times of themeasurement and finally search for all the measurement objects of the selectedsave time. In both cases, the user selects the measurement type, target object andthe save time. When all of these parameters are known, the user is able to obtainthe counter and KPI values. The KPIs can be created using the NE ThresholdManagement application.

Measurement Management view:

The Measurement Management functionality is integrated into the NEMeasurement Explorer GUI. It provides a tool for easy-to-use graphicalmeasurement handling (that is, starting and stopping of the measurements) thatcan be used alongside with the Measurement Handling (T2) MML interface.

Browser starting dialogue:

Browser starting dialogue is used for opening the default web browser to a www-page in the NEMU web server containing the SS7 and PDH measurement reportsin textual form.

NE threshold management

The Element Manager GUI can be used for setting, removing and modifyingthreshold monitoring parameters. An operator can use predefined keyperformance indicators (KPI) or define customized KPI formulas. KPIs includeeither an individual counter or a combination of several counters, which arecollected in the network.


dn0497801Issue 6 en


Note

In MGW NEMU, it is possible to create KPIs. However, if you wish to usepredefined KPIs, NetAct provides an optional MGW Reporting Suite thatconsists of predefined MGW reports and KPIs.

See Threshold-based notifications for more information on thresholds, and Keyperformance indicators for KPI information.

2.29 Subscriber Trace Post-processing in MGW

Table 29. Subscriber Trace Post-processing in different MGWnetwork environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Subscriber Trace Post-processing

x


MSC Server sends a trace activation message to MGW which generates thesubscriber-specific trace records. The maximum number of simultaneous tracecases in one MGW is limited and if the number of trace cases reaches the limit,MGW discards the trace activation and sends a notification to MSC Server if thenotification has been requested.

The trace records generated in MGW are sent to Nokia NetAct through NEMU.MGW gathers trace data during trace events and generates a trace report after atrace event for a specific subscriber has finished. A full report is transferred toNEMU. The trace reports can be stored in NEMU and they can be viewed with anordinary text formatting tool. NEMU also sends the trace reports to Nokia NetActby using the Nokia proprietary NWI3 interface.

dn0497801Issue 6 en


85 (111)


Functionality

The generated subscriber-specific trace reports are sent to NEMU via ExternalMessage Transfer (EMT). NEMU receives the subscriber-specific trace reportsand sends them to Nokia NetAct by using NWI3 notification. After this, NokiaNetAct sends a DATA RECEIVED OK acknowledgement and NEMU removesthe reports from its trace buffer. If NEMU does not receive the DATARECEIVED OK acknowledgement from Nokia NetAct in time (that is, NEMU�stimer expires), the subscriber-specific trace reports are sent again. Trace reportsare also sent again if NEMU receives a DATA RECEIVED NOKacknowledgement from Nokia NetAct. NEMU keeps sending the subscriber-specific trace reports until its trace report sending buffer is full. After that, thetrace reports are lost if trace report saving to NEMU disk is not enabled.

Note

If the Nokia proprietary NWI3 interface is broken between NEMU and NokiaNetAct, all trace reports are lost after the trace report sending buffer in NEMU isfull if trace report saving to NEMU disk is not enabled.

For more information on subscriber trace post-processing, please refer to NokiaNetAct (OSS) product documentation.

The subscriber trace feature is optional in Nokia NetAct.

2.30 NetAct-related functionalities

Table 30. NetAct-related functionalities in different MGWnetwork environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

NetAct relatedfunctionalities

x x x


dn0497801Issue 6 en



These operability functions in Nokia MGW are carried out by the Nokia NetActnetwork management system utilising the network element management unit(NEMU) that is integrated to Multimedia Gateway.

Centralised Event Logging (Remote User Event Log Management)

Centralised Event Logging, also known as Remote User Event Log Management,enables centralised aggregation of user event logs (such as GUI command log)from network elements (NEs) into Nokia NetAct. The operator is able to tracechanges in the network based on user or NE information. The upload is triggeredfrom NetAct. NetAct is also able to produce the data in the user event collectionin XML format (XML coding is available for 3rd party applications). File TransferProtocol (FTP) is used for log file collection from the NEs. NetAct provides thetools for processing the collected log files.

With Centralised Event Logging, the operator can collect user event data from allNEs. With NetAct applications, the operator can create reports from the datacollection, based on a user or an NE, for example. It enables fast tracking ofsuspected illegal user actions and therefore enables fast tools to start correctiveactions and prevent additional damage.

Figure 19. User event collection from network elements

This is an optional functionality in Nokia NetAct.

OSS

User eventcollection

NE NE

Log file transfer

NE

dn0497801Issue 6 en


87 (111)


Centralised User Management (Remote User Information Management)

NEs have different ways of handling user profiles, and therefore a singlecentralised profile for all NEs is not determinate. Centralised User Management,also referred to as Remote User Information Management (RUIM), shows whichprofiles the user uses in the NE. This requires that both the user and the hosts areidentified for access to Nokia NetAct to fulfill the security requirements. Thisoffers the operator the possibility to manage the user accounts in a centralisedmanner. The minimum management requirements for user information are:

. creation of a new user

. password change

. deletion of a user

With Centralised User Management, the user can manage the maintenancepersonnel's access to the O&M network for each group or individual separately,and define different access classes for different user groups and NEs. All changescan be rapidly downloaded, either manually or automatically, and simultaneouslyto a number of elements. MML sessions for each separate NE are no longernecessary.

The RUIM feature enables centralised user management and authorising viaNetAct. There are two main groups of users: local users and remote users.Centralised user management can be used only for remote users.

Local users are defined locally in one network element. The user can only log into a network element where a local account is defined. Local user accounts mustbe defined separately in all network elements.

Automatic notification to NetAct of a changed HW configuration

Automatic HW Configuration Change Notification enables network elements toreport automatically to Nokia NetAct about changes in their HW configuration.The HW configuration is either configured manually or detected automatically bythe system in MGW. The list of the HW items and related parameters is stored inthe NE. When the NE detects changes in its HW inventory, an update message issent to the NetAct to inform it about the changed situation. The changed data inthe NE�s HW inventory is either included in the update message or the NetActcan automatically start a HW information upload procedure. According to thenotification or data upload, the NetAct stores the new information to the NetworkHW inventory.


dn0497801Issue 6 en


Figure 20. Automatic HW Configuration Change Notification

The information in the network level HW inventory database is automaticallyupdated every time a change is detected in any NE HW inventory. No user-triggered upload procedure is needed. Automatic HW Configuration ChangeNotification decreases the need for O&M transmission for HW informationpurposes since no massive network level HW information upload operations areneeded. The transmission load is divided more evenly and there is no need totransfer information that is already known to NetAct.

SW activation event to NetAct

Nokia NetAct collects and keeps up-to-date information of the MGW's SWversions in the network. For maintaining the SW configuration data correct, theNetAct must be informed about the changes in MGW SW configuration. When anew software is activated in the MGW, notifications are sent to the NetAct via anNWI3 interface. With this functionality, the NetAct SW inventory alwaysincludes the latest SW information of MGW.

NetAct is also informed about changes in NEMU's SW versions.

For information on the NetAct - MGW interface, see MGW Operability SolutionDescription.

Automatic HWconfiguration detection

Manual HWconfiguration

OSS

HWinventory

NE

dn0497801Issue 6 en


89 (111)


2.31 Files in MGW

Table 31. Files in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Files x x x


Table 32. Files that are important in controlling the MGW functionality

File Description

CF1FIL - RANAP andBSSAP counter file

The file contains RANAP and BSSMAPmeasurement counters.

MGW for MSC only

H24LOG - H.248 EventLog workfile

The file is used for storing H.248 alarm- anderror-specific information as variable lengthtext format.

NOT in MGW for MSC

H48FIL - File to collectstatistical data in MGW

The file collects statistical data in MGW. Itincludes statistical counters for the H.248measurement.

NOT in MGW for MSC

ID1FIL - MultimediaGateway -SpecificParameter File

The file contains Multimedia Gateway -specific parameters (such as the E.164address of the network element) and theinformation is controlled with the MultimediaGateway -specific Parameter Handling (WE)MML commands.

ID3FIL - Cause codeconversion parameter file

The file contains the cause codes' conversionparameters. The parameters can be modifiedlocally via MML commands.

MGW for MSC only


dn0497801Issue 6 en


Table 32. Files that are important in controlling the MGW functionality(cont.)

File Description

ID4FIL - RNC-specificparameter file

The file contains RNC-specific addressinformation. The parameters in the file can bemodified locally via MML commands.

MGW for MSC only

ID5FIL - LAC-specificdefault parameter file

The file contains default parameters forlocation area codes. The parameters in the filecan be modified locally via MML commands.

MGW for MSC only

ID6FIL - Node state file The file contains the states of nodes, that is,the states of the mobile services switchingcentre (MSC) and radio network controller(RNC).

MGW for MSC only

IWQFIL - Media GatewayInterworking FunctionalityFile

The file contains the IWF hunt method and alist of IWF addresses in order of priority. Thehunt method and addresses are controlledwith the Media Gateway Element Handling(JC) MML commands

NOT in MGW for MSC

LTGFIL - AnnouncementLanguage Tags File

The file stores the language tags in ABNF(text) format. A similar file is present in bothMSS and in MGW for MSS. In MGW for MSSthe LTGFIL is located in CM, and distributed toVANU. The file is directly read by VA2PRB,and thus VA2PRB can format H.248messages using the ABNF format languagetags. The LTGFIL is handled with the ContextManager Settings Handling (JL) MML.

NOT in MGW for MSC

SD0FIL - File to CollectStatistical Data inMultimedia Gateway

The file includes statistical counters for thefollowing measurements in MGW for MSS:. Signalling Transcoding measurement

(Measurement ID:283). Multi Party Call measurement (MID:284). Connection measurement (MID:285). TrFO and TFO measurement (MID:288). Data Call measurement (MID:289). Acoustic Echo Cancellation measurement

(MID:294). User Plane Initialisation measurement

(MID: 296)

NOT in MGW for MSC

dn0497801Issue 6 en


91 (111)



File Description

TN3FIL - TechnicalParameters of 3G File

The file contains the in-band tone parameters,that is, parameters for national tones andDTMF signals used in a specific country by aspecific operator. The country/operator-specific tones and DTMF signals arecontrolled with the National Tones Handling(W5) MML commands.

NOT in MGW for MSS

TO3FIL - TechnicalParameters Over World of3G File

The file contains the default technicalparameters of national tones for variouscountries and operators of the world. TO3FILis a readable disk file, which is located in theCentral Memory (CM) of MGW for MSS.

NOT in MGW for MSC

TR2FIL - Trace ReportFile in MultimediaGateway

The file contains information on MGW for MSStrace observation. The file includes traceheader fields, MGW for MSS additionalheader fields, termination common sub-header fields and termination specific sub-report fields. The TR2FIL is located in everyISU unit.

NOT in MGW for MSC

UTPFIL - Unit-type-associated Parameter File

The file contains changes to parameters'default values at the program block level. Theparameters can be modified locally.

VADYNA - DynamicNumber ElementAdministration File

The file contains the announcement samplefiles (such as VAT00001, VAT00002,&) for thevariable parts of announcements. The validnumbers for VAD files are 1 to 3999. Theinformation in this file is controlled with theMedia Gateway Announcement File Handling(JA) MML.

NOT in MGW for MSC

VAITXT - VoiceAnnouncement Text File

The file contains the announcements in textformat.

NOT in MGW for MSC

VAMANA - SpeechSample FilesManagement File

The file is used in VA2PRB to find the start ofthe sample file.

NOT in MGW for MSC

VATALK - VoiceAnnouncements SpeechSample File

The file contains the announcement samplefiles (such as VAT00001, VAT00002,&) for thefixed parts of the announcements. The validnumbers for VAT files are 1 to 3999. Theinformation in this file is controlled with theMedia Gateway Announcement File Handling(JA) MML.

NOT in MGW for MSC


dn0497801Issue 6 en



File Description

VAVALK - Internal VoiceAnnouncements SpeechSample File

The fixed sample element file size of 1kBincludes a PCM coded sample and a checkblock.

NOT in MGW for MSC

VAXLAN - VoiceAnnouncement LanguageStructure File

The file contains the language structure filesfor the language specific structure of eachlanguage identifier used in the network. Thevariable speech sample file is found byVA2PRB using language identifier, variablepart type and the value of the embeddedvariable. The information in this file iscontrolled with the Media GatewayAnnouncement File Handling (JA) MML.

NOT in MGW for MSC

2.32 Databases in MGW

Table 33. Databases in different MGW network environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

Databases x x x


The databases related to MGW for MSS functionality are:

. Virtual Media Gateway Database � MGDATA

This database contains Virtual Media Gateway data. The data is managedvia the Virtual Media Gateway Handling (JV) MML.

. Context Database � CXDATA

dn0497801Issue 6 en


93 (111)


This database contains the termination information for contexts.

In addition to the above mentioned databases, MGW also contains otherdatabases related to the basic services.

2.33 PRFILE and FIFILE parameters in MGW

Table 34. PRFILE and FIFILE parameters in different MGWnetwork environments


MGW forMSC

MGW inUNC(UMA) *)

MGW forMSS

PRFILE and FIFILEparameters

x x x


The most essential PRFILE and FIFILE parameters used in MGWare listed in thetable below.

Table 35. PRFILE and FIFILE parameters in MGW

PRFILE/FIFILEparameter

Description Applicable in MGW

MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

FREE_CIC_-NUMBERING(002:0115)

This parameter defineswhether the circuitidentification code (CIC) canbe given as free numbering.

x


dn0497801Issue 6 en


Table 35. PRFILE and FIFILE parameters in MGW (cont.)



MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

ANALYSIS_-MAX_COUNT(002:0266)

This parameter defines themaximum number of digitanalysis requests in one call.The allowed values are 40D -200D, and the default value is100D.

x

MAX_N-BR_OF_VMG-W_IN_UNIT(002:0727)

This parameter defines themaximum number of VirtualMedia Gateways per one ISUunit. The allowed values are1D - 5D, and the default valueis 5D.

x

UP_IP_VER_-IN_MGW(002:0736)

The parameter defines the IPversion used for User Plane inMGW for MSS. The allowedvalues are 0D (IPv4 is used),1D (IPv6 is used) and 2D (bothIPv4 and IPv6 are used).

x

USE_OF_TTY(002:0757)

This parameter defines the callcases in which TTY is used.The allowed values are 0H,1H, 2H and 3H, and the defaultvalue is 0H.

x x

TTY_IN_USE(002:0758)

This parameter determines thestatus of the optional TextTelephony functionality. Theallowed values are OFF (thefunctionality is deactivated)and ON (the functionality isactivated). The default value isOFF.

x x

dn0497801Issue 6 en


95 (111)





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

TRFO_I-N_USE(002:0773)

This parameter determines thestatus of the optional TrFOfunctionality. The possiblevalues are OFF (thefunctionality is deactivated)and ON (the functionality isactivated). The default value isOFF.

x

TFO_IN_USE(002:0774)

This parameter determines thestatus of the optional TFOfunctionality. The possiblevalues are OFF (thefunctionality is deactivated)and ON (the functionality isactivated). The default value isOFF.

x

PCM_ENCO-DING_LAW(002:0775)

This parameter determineswhether the DSP applicationsuse the encoding A law or theencoding µ law with the G.711codec. The possible values are00H (A law) and 01H (µ law),and the default value is 00H.

x x

IP_TUNNEL_-SETUP_TIME(002:0778)

This parameter defines thewaiting time (in seconds)necessary for IP tunneling. Theallowed values are 1D - 30D,and the default value is 5D.

x

ECHO_CAN-CELLER(002:0808)

This parameter determines thestatus of the optional echocancellation functionality. Thepossible values are OFF (thefunctionality is deactivated)and ON (the functionality isactivated). The default value isOFF.

x


dn0497801Issue 6 en





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

DSCP_FOR_-USER_PLANE(002:0817)

This parameter is used by theuser plane applications to setthe Differentiated Servicescodepoint carried in the Typeof Service or Traffic Class fieldin IPv4 and IPv6 headers,respectively. IP forwardingfunctions use this value for thetreatment of high priority traffic.The allowed values are 0H -03FH, and the default value is02EH (Expedited Forwarding).

Note

For definitions of thediffServ codepoints andrespective values, seeRFC2474, RFC2597,and RFC2598.

x x

TIMER_ERQ(002:0840)

This parameter sets value forAAL2 establish timer in AAL2signalling services. Theallowed values are 5D - 30D,and the default value is 30D.

x

TIMER_REL(002:0841)

This parameter sets value forrelease timer in AAL2signalling services. Theallowed values are 2D - 60D,and the default value is 60D.

x

dn0497801Issue 6 en


97 (111)





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

RTCP_FOR_-UP_MONI-TORING(002:0950)

This parameter is used tocontrol the use of RTCPprotocol and user planemonitoring. The allowed valuesare 0x01 (RTCP_off,UP_monitoring_off), 0x02(RTCP_on,UP_monitoring_off) and 0x03(RTCP_on,UP_monitoring_on). Thedefault value is 03H.

x

H248_MAX_-WAIT_DELAY(002:1008)

MGW for MSS has anavalanche preventionmechanism, and thisparameter defines a timervalue for the mechanism whichis used during restart. MGW forMSS initialises a randomrestart timer, where the time isdistributed evenly between 0and the maximum waitingdelay time. When the time isout, MGW for MSS sends aServiceChange message forregistration. The default valueis 10 seconds.

x

DEF_NOR-MAL_MG_EX-EC_T(002:1014)

The parameter defines thetime interval within whichMGW for MSS processes arequest and sends a response.The default value is onesecond.

x

DEF_NOR-MAL_-MGC_EX-EC_T(002:1015)

The parameter defines thetime interval within which MSCServer processes a requestfrom MGW and sends aresponse. The default value isone second.

x


dn0497801Issue 6 en





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

DEF_NET-WORK_DE-LAY_T(002:1016)

This parameter defines thedefault delay for all networkconnection delays (back andforth) between the MSC Serverand the controlled MGW. Thedefault value is 50milliseconds.

x

MGC_ORIG_-PEND_LIMIT(002:1017)

This parameter defines thenumber of transactionpendings that can be receivedfrom MSC Server. Once thislimit is exceeded, MSC Servershould issue a transactionreply with error 506 (Number oftransaction pendingsexceeded), otherwise MGWcan assume that thetransaction is erroneous. Thedefault value is 4 attempts.

x

MG_ORIG_-PEND_LIMIT(002:1018)

This parameter defines thenumber of transactionpendings that can be receivedfrom MGW. Once this limit isexceeded, MGW should issuea transaction reply with error506 (Number of transactionpendings exceeded),otherwise MSC Server canassume that the transaction iserroneous. The default value is4 attempts.

x

AEC_IN_USE(002:1086)

This parameter determines thestatus of the optional AECfunctionality in Iu interfacecalls. The possible values areOFF (the functionality isdeactivated) and ON (thefunctionality is activated). Thedefault value is OFF.

x x

dn0497801Issue 6 en


99 (111)





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

MGW_LIS_-CON_CA-PA_W_LIM(002:1144)

This parameter indicates howmany percent of the licencedMGW connection capacity isused before alarm 3294licence_capacity_warning_a isset in MGW. If the value of thisparameter is 0, alarm 3294 isnot set in any case. Theallowed values are 0D - 100D,and the default value is 80D.

x

ATER_I-N_USE(002:1148)

This parameter controls theoptionality and activationstatus of the Ater interfacefunctionality.

x

ATER_AEC_I-N_USE(002:1153)

This parameter controls theoptionality and activationstatus of the AEC feature inAter interface.

x

AMR_WB_I-N_USE(002:1154)

This parameter controls theoptionality and activationstatus of the AMRWB codec inMGW.

x

AE-SA_ADDR_-CONF_I-N_USE(002:1179)

This parameter determines theoptionality of ATM addresstype E.191 AESA for MGW.

x

MIN_RTP_PORT(002:1188)

This parameter defines theminimum value for the RTPport numbering that is used bythe RTP application whenhunting a free IP port.

x


dn0497801Issue 6 en





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

CLEARMO-DE_IN_USE(002:1198)

This parameter controls theusage of 64k/bits channel datatransparently in RTP packetsthrough VoIP networks. The64k/bits Unrestricted DigitalInformation is supportedtowards Mb (Fss) interface.

x

PASS_THR_-MB_IN_USE(002:1199)

This parameter controls theusage of pre-configured RTPpayload type as pass throughchannel in the Mb interface.

x

PASS_THR_-NB_IN_USE(002:1200)

This parameter controls theusage of pre-configured RTPpayload type as pass throughchannel in the Nb interface.

x

FAX_MO-DEM_DET_I-N_USE(002:1201)

Usage of Fax and CS data calldetection in MGW enables theMGW to differentiate betweenspeech, fax and modem datacalls by monitoring the userplane and detecting the faxand modem negotiation-related signals.

x

PASS_THR_-CH_MB(002:1202)

This parameter is used fordefining the value of the pre-configured RTP payload typein the Mb interface.

x

PASS_THR_-CH_NB_PRI-ME (002:1203)

This parameter is used fordefining the value of the pre-configured RTP payload typein the Nb interface.

x

UMA_CONV_-SUP-P_IN_MGW(002:1210)

This parameter controls theoptionality and activation of theUMA converter functionality.

x x

dn0497801Issue 6 en


101 (111)





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

A_AEC_I-N_USE(002:1231)

This parameter controls theoptionality and activationstatus of the AEC feature in theA-interface.

x

AEC_WITH_T-TY (002:1238)

This parameter is used forcontrolling the use of the AECfunctionality together with theTTY functionality.

x

AAL2_ANALY-SIS_TREE(007:0127)

This parameter determines thedigit analysis tree in which theB address is analysed. Theparameter is used in MGW.The Nodal function uses thisparameter when searching foran outgoing route to theadjacent node (RNC oranother MGW). The allowedvalues are 1D - 1023D, and thedefault is 1D.

x x

IWF_RFR_TI-ME_SUPERV(009:0117)

This parameter is used forsetting the refreshing timer to 1- 600 seconds. This timer isused for sending data callrefreshing messages in cyclesof [timer] from MGW for MSSto an external IWF equipment.The allowed values are 01H -0258H, and the default value is0AH.

x

ATM_MODU-LE_OL-C_USED(012:0077)

This parameter is used forcontrolling the overload controlmechanism in MultimediaGateway for MSC (MGW forMSC). The possible values areT (overload control in use) andF (overload control not in use).

x x


dn0497801Issue 6 en





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

AAL2_OL-C_ENABLED(012:0081)

This parameter determineswhether the AAL2 overloadcontrol mechanism is in use ornot. The allowed values are0FFH (AAL2 overload controlis in use) and 00H (AAL2overload control is not in use),and the default value is 0FFH.

x x

H248_OL-C_USED(012:0096)

This parameter determineswhether the H.248 overloadcontrol mechanism is in use ornot. The allowed values are0FFH (H.248 overload controlis in use) and 00H (H.248overload control is not in use),and the default value is 0FFH.

x

MGW_TRA-CE_MAX(012:0109)

This parameter controls howmany trace events can beactivated in MGW for MSS.With this parameter theoperator can limit themaximum number of activetrace events to reduce thecapacity need. The parameterhas a computer unit (ISU) -based limitation. Thus thecomplete limitation of traceevents in MGW is multipliedwith the number of computerunits (ISU). The allowed valuesare 0D - 20D, and the defaultvalue is 20D.

x

USED_TO-NE_SET(043:0009)

This parameter determines theused tone set in MGW. Theparameter is adjusted for thecustomer by Nokia.

x

dn0497801Issue 6 en


103 (111)





MGWfor MSC

MGW inUNC(UMA)

MGWfor MSS

DSCP_FOR_-SIGNALLING(053:0009)

Signalling applications can usethis parameter to set theDifferentiated Servicescodepoint carried in the Typeof Service or Traffic Class fieldin IPv4 and IPv6 headers,respectively. The allowedvalues are 0H - 03FH, and thedefault value is 030H (AssuredForwarding).

Note

For definitions of thediffServ codepoints andrespective values, seeRFC2474, RFC2597,and RFC2598.

x

2.34 Optional features in MGW

Some of the MGW functionalities are optional. You are allowed to activate anduse the optional functionalities only if you have purchased them.

Nokia is moving from parameter-based option management to a more flexible,licence-based software model supporting both ON/OFF and capacity-typefeatures. The software licensing model is introduced in MGW with the firstlicensed feature, MGW connection capacity.

The parameter (FIFILE) -based optional MGW features are:

. 2G TFO

. TrFO


dn0497801Issue 6 en


. Echo cancellation

. Acoustic echo cancellation (AEC) in the Iu interface

. AEC in the Ater interface

. AEC in the A-interface

. Text Telephony (TTY)

. Fax and CS data call detection

. AESA addressing

. Ater interface

. interworking service for UMA access (A/A+ conversion)

. AMR-WB

Note

Simultaneous use of AEC (on the Iu interface) and TrFO in MGW is not currentlysupported. The implementation of AEC includes transcoding operations and asTrFO has been given a higher internal priority, AEC would always be omitted ifboth functionalities were activated simultaneously.

You can check the activation status of the FIFILE-based optional MGWfunctionalities with the WOS command, and you can activate/deactivate anoptional MGW functionality with the WOA command.

Licence-based optional MGW features are:

. MGW connection capacity licensing

. iLBC

. G.723.1

. G.729 A/B

The licence-based features require the purchase and installation of a SW licence.With the Licence and Feature Handling MML (W7), you can install and updatelicences in the network element, activate and deactivate licensed optional MGWfunctionalities and check their activation status.

The table below explains the MGW environments where each optional feature isapplicable:

dn0497801Issue 6 en


105 (111)


Table 36. Applicability of optional features in MGW


MGW forMSC

MGW inUNC

(UMA) *)

MGW forMSS

2G TFO x

TrFO x

Electric echo cancellation PSTN/PLMN


Iu-CS Iu-CS, A,Ater

Text Telephony (TTY) x x

ConfigurationManagement DataMediator

x

Fax and CS data calldetection

x

AESA addressing Iu-CS, Nb

Ater interface x

Interworking service forUMA access (A/A+conversion)

x x

AMR-WB Nb, Iu, Mb

iLBC Mb

G.723.1 Mb

G.729 A/B Mb

MGW connectioncapacity

x



dn0497801Issue 6 en


3 Compliance of MGW

A certain MGW product release is mainly based on a specified 3GPPspecification release (for example, U3C is a release mainly based on 3GPP Rel-5level specifications, but IMS-related issues in U3C are based on 3GPP Rel-6 levelspecifications). The word "mainly" refers here to the fact that some features arenot supported at all, some partially, and some are implemented in a later productrelease. Some features are even implemented earlier than a 3GPP specificationwould impose. In addition, Nokia has implemented some proprietary extensionfeatures to meet customer requirements in a timely manner.

Statement of compliance -documents against relevant 3GPP (and other)specifications are delivered upon request.

dn0497801Issue 6 en


107 (111)

Compliance of MGW


dn0497801Issue 6 en


Related Topics

TDM connectivity in MGW

Echo cancellation in MGW

Speech enhancements in MGW

TDM interfaces in MGW

In-band tones and continuity check in MGW

Instructions

Selecting tone sets in MGW

Modifying national tones in MGW for MSS

Modifying DTMF signals in MGW for MSS

Reloading national tones and DTMF signals in MGW for MSS

Announcements in MGW

Instructions

Configuring voice announcement unit (VANU) in MGW for MSS

Constructing announcement files in MGW for MSS

Loading modified speech sample files in MGW for MSS

Updating language structure files in MGW for MSS

Creating new language tags in MGW for MSS

dn0497801Issue 6 en


109 (111)

Related Topics

Restoring old speech sample files in MGW for MSS

Removing announcement speech sample files from MGW for MSS

Announcements cannot be heard

Announcements are played in a wrong language

Descriptions

Announcement types in MGW for MSS

Overview of speech sample and language structure files in MGW for MSS

Announcement measurement in MGW for MSS

Trace observation in MGW

Descriptions

RANAP trace in MGW for MSC

IMEI/IMSI trace observation in MGW for MSS

Instructions

Monitoring erroneous Iu and A' interface messages in MGW for MSC

Handling IMSI trace in MGW for MSC

NEMU in MGW

Descriptions

Subscriber Trace Post-processing in MGW


dn0497801Issue 6 en


Performance management functionalities in NEMU

Performance Management functionalities in NEMU

Descriptions

NEMU in MGW

Subscriber Trace Post-processing in MGW

Descriptions

NEMU in MGW

Optional features in MGW

Descriptions

2G TFO in MGW

Echo cancellation in MGW

Instructions

Activating TFO in MGW (optional)

Activating echo cancellation in MGW (optional)

dn0497801Issue 6 en


111 (111)

Related Topics

MGW Function

Documents

Transcript of MGW Function