Functional Description for MGW

Functional Description for MGW

DN0497801Issue 8-2 en draft

# Nokia Siemens Networks 1 (143)

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 not an officialcustomer document and Nokia Siemens Networks does not take responsibility for any errors oromissions in this document. This document is intended for the use of Nokia Siemens Networkscustomers only for the purposes of the agreement under which the document is submitted. Nopart of this documentation may be used, reproduced, modified or transmitted in any form ormeans without the prior written permission of Nokia Siemens Networks. The documentation hasbeen prepared to be used by professional and properly trained personnel, and the customerassumes full responsibility when using it. Nokia Siemens Networks welcomes customercomments as part of the process of continuous development and improvement of thedocumentation.

The information or statements given in this documentation concerning the suitability, capacity orperformance of the mentioned hardware or software products are given “as is” and all liabilityarising in connection with such hardware or software products shall be defined conclusively andfinally in a separate agreement between Nokia Siemens Networks and the customer.

IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THISDOCUMENTATION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL,DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES SUCH AS BUTNOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESSOPPORTUNITY OR DATA, that might arise from the use of this document or the information in it.

THE CONTENTS OF THIS DOCUMENT ARE PROVIDED "AS IS". EXCEPT AS REQUIREDBY APPLICABLE MANDATORY LAW, NO WARRANTIES OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT,ARE MADE IN RELATION TO THE ACCURACY, RELIABILITY OR CONTENTS OF THISDOCUMENT. NOKIA SIEMENS NETWORKS RESERVES THE RIGHT TO REVISE THISDOCUMENT OR WITHDRAW IT AT ANY TIME WITHOUT PRIOR NOTICE.

This document and the product it describes are considered protected by copyrights and otherintellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark ofNokia Corporation. Siemens is a registered trademark of Siemens AG.

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

Copyright © Nokia Siemens Networks 2008. All rights reserved.

2 (143) # Nokia Siemens Networks DN0497801Issue 8-2 en draft


Contents

Contents 3

Summary of Changes 5

1 Requirements for using MGW 71.1 Requirements for a Radio Network Controller (RNC) connected to

MGW 71.2 Requirements for an MSC Server (MSS) controlling MGW 81.3 Requirements for a Base Station Controller (BSC) connected to MGW 91.4 Requirements for an ATM backbone connected to MGW 101.5 Requirements for an IP backbone connected to MGW 111.6 Requirements for a TDM backbone connected to MGW 141.7 Requirements for a PSTN/PLMN connected to MGW 141.8 Requirements for an IP Multimedia Subsystem (IMS) connected to

MGW 151.9 Requirements for an Unlicensed Mobile Access (UMA) 181.9.1 Requirements for UMA network controller (UNC) connected to MGW 191.9.2 MSC Server controlling MGW for UMA 201.9.3 MSC connected to MGW for UMA 20

2 Overview of MGW functionality 21

3 IP connectivity in MGW 25

4 ATM connectivity in MGW 31

5 TDM connectivity in MGW 37

6 MGW features 436.1 New chapter: Feature management in MGW 436.2 Resource configuration in MGW 446.3 Virtual MGW (VMGW) configuration 496.4 H.248 in MGW 526.5 Codecs and speech transcoding in MGW 576.6 Signalling Gateway (SGW) in MGW 626.7 In-band tones and continuity check in MGW 666.8 Announcements in MGW 706.9 Data calls in MGW 726.10 User plane monitoring in MGW 766.11 Test call in MGW 776.12 Performance management in MGW 796.13 Trace observation in MGW 836.14 Speech enhancements in MGW 846.14.1 Electric echo cancellation (EC) in MGW 866.14.2 Acoustic echo cancellation (AEC) in MGW 876.14.3 Automatic level control (ALC) in MGW 886.15 TFO in MGW 896.16 TrFO in MGW 95



Contents

6.17 Text telephony service for 3G calls in MGW 986.18 Nokia MGW in Nokia UMA solution for GSM 1026.19 Ater interface in MGW 1036.20 Multiple isolated IP networks 1056.21 IP connection admission control (IP CAC) 1056.22 MGW Connection and Port capacity 1066.23 Security functionalities in MGW 107

7 NEMU features 1117.1 NEMU in MGW 1117.2 Tools for handling MGW NEMU 1127.2.1 Windows Server 2003 for NEMU 1137.2.2 NEMU control panel 1137.2.3 NEMU configuration wizard 1137.2.4 Resilience improvements for NEMU 1137.3 Fault management in MGW via NEMU 1147.4 Performance management functionalities in NEMU 1157.5 Subscriber trace post-processing in MGW 1187.6 NetAct-related functionalities 119

8 Files in MGW 125

9 Databases in MGW 129

10 PRFILE parameters in MGW 131

11 Compliance of MGW 139

Related Topics 141



Summary of Changes

Changes between document issues are cumulative. Therefore, the latestdocument issue contains all changes made to previous issues.

Changes in issue 8-2

Feature management in MGW

This is a new chapter describing the licence-based feature managementsystem where both capacity-type and ON/OFF licences are supported.

Security functionalities in MGW

All security-related issues are now described in this chapter.

TFO in MGW

Section AMR TFO has been modified thoroughly.

PRFILE parameters in MGW

FIFILE parameters have been removed and the chapter has beenrenamed accordingly.



Summary of Changes

1 Requirements for using MGW

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

Network element Applicable in MGW

MGW inUNC(UMA) *)

MGW forMSS

RNC x

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

An RNC connected to an MGW has to support the open asynchronoustransfer mode (ATM) -based Iu-CS interface standardised by the 3rdGeneration Partnership Project (3GPP). MGW supports the open Iu-CSinterface.

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



Requirements for using MGW

Note

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

. capability to receive rate control requests from /through core networkand

. capability to receive Iu_UP re-initialisation requests from corenetwork at the termination side of a call

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

1.2 Requirements for an MSC Server (MSS) controllingMGW


MGW inUNC(UMA) *)

MGW forMSS

MSS x


In addition to controlling MGWs, MSC Server is responsible for call control.The MSC Server functionality is a combination of two distinctfunctionalities: Visited MSC Server and Gateway MSC Server. The VisitedMSC Server contains the VLR and controls the MGWs that are connectedto a radio network. The Gateway MSC Server is responsible for thesignalling interconnection towards external networks and it has no VLRfunctionality. So, the Gateway MSC Server controls those user planeresources in MGWs which provide the interconnection to PSTN/ISDNnetwork.



Also, an MSC Server to which an MGW for MSS is connected must becapable of handling IP-based signalling traffic. The SS7-based signallingtraffic (used in A-, Iu-CS and PSTN/PLMN interfaces) is transported fromMGW for MSS as IP-based signalling traffic towards MSC Server. This isdone by changing the TDM/ATM transport layer to SCTP/IP transporttowards MSC Server. The transportation is done on SS7 MTP3 -level byusing SIGTRAN protocols.

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

Interworking with IMS

MGW provides an IP Multimedia Media Gateway (IM-MGW) functionalitythat enables interworking between IP Multimedia Subsystem (IMS) andcircuit-switched core networks. An Mb interface conveys user plane traffictowards the packet core network domain, and an Mn interface conveyscontrol plane traffic towards MSS.

The Mn interface, specified by 3GPP, is a control interface between the IM-MGW and Media Gateway Control Function (MGCF) of MSC Server(MSS). The MSS (MGCF) has to support the new H.248 procedures of theMn interface for handling IM-MGW functionalities in IM CN-CS networkinterworking situations.

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


MGW inUNC(UMA) *)

MGW forMSS

BSS x





The A-interface user plane and control plane traffic sets certainrequirements for a BSC connected to an MGW. The user plane traffic(speech and data) is always routed via MGW, while the control plane traffic(BSSAP signalling) is routed either directly to MSC Server or transparentlyvia MGW to MSC Server.

The Ater interface traffic requires a Nokia BSC to be connected to anMGW. The BSS release must be updated to support the use of the Aterfunctionality.

When the A-interface is used between BSS and MGW, the utilisation of theTandem Free Operation (TFO) for EFR, FR, and AMR requires the TFO/AMR TFO support also in the transcoders located in the BSS. In addition,AMR TFO requires support from MSC Server (MSS).

When the Ater interface is used, the TFO-capable 2G transcoderfunctionality is located in MGW.

When the Ater interface is used, TFO is possible only for EFR, FR, and HRcodecs.

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

1.4 Requirements for an ATM backbone connected toMGW

Interface Applicable in MGW

MGW inUNC(UMA) *)

MGW forMSS

ATM backbone x




MGW does not set any particular requirements for an ATM backbonelocated between MGW and RNC (Iu-CS interface) or between MGWnetwork elements (Nb interface). Signalling and user plane traffic betweentwo MGWs (or between MGWand RNC) is transmitted via the Nb interfaceusing the ATM adaptation layers AAL type 2 and AAL type 5 overpermanent virtual channel (PVC) connections.

Within the ATM backbone, AAL type 2 is used on the user plane totransport compressed speech and data. If the ATM backbone supports theAAL type 2 switching (nodal function) capability, it is possible to re-routeuser plane AAL type 2 traffic from one MGW for MSS to another MGW forMSS without direct permanent virtual connections (PVC) between theMGWs. MGW uses AAL type 2 PVC connections, but inside the ATMbackbone switched virtual channels (SVC) may be used as well.

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

When IP connectivity is not provided at the remote site and the ATMbackbone, the control plane traffic can be routed via SWU (ESA24) unit toMSC Server. The user plane traffic is routed via NIS1/NPS1 or NIP1 unit toanother MGW. For more information, see Overview on IP over ATM andoptimising TDM transmission for remote MGW.

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

1.5 Requirements for an IP backbone connected toMGW


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 planetraffic. The Real-time Transport Control Protocol (RTCP) can be used tomonitor the RTP stream and to collect statistical data. RTP provides end-to-end delivery services for data with real-time characteristics (such asinteractive 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 andvariable site solutions, IP backbone must support at least one of thefollowing connections:

SW upgrade (IPFGE as interface unit):

. Fast Ethernet (100Mbit/s) for SWU and IPFGE

. Ethernet (1Gbit/s) for IPFGE

Figure 1. Default IP connectivity, SW upgrade (IPFGE as interface unit)

1G/100M

100Mb

Edge-router

100Mb

MGW

User plane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

IPFGE

NetAct

MSC Server

SWU

O&M

User plane inside MGW



New delivery (NPGEP as interface unit):

. Fast Ethernet (100Mbit/s) for SWU

. Ethernet (2 x 1Gbit/s) for NPGEP

Figure 2. Default IP connectivity, new delivery (NPGEP as interface unit)

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

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

Careful IP Network design, implementation, and QoS configuration isrequired to ensure stable speech quality and reliable functioning of theMSC Server System. For detailed IP backbone requirements, see SiteConnectivity Guidelines for CS Core Network.

2x1G

100Mb

Edge-router

100Mb

MGW

User plane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

NPGEP

NetAct

MSC Server

SWU

O&M





1.6 Requirements for a TDM backbone connected toMGW


MGW inUNC(UMA) *)

MGW forMSS

TDM backbone x


MGW does not set any particular requirements for a TDM backbonelocated between MGW network elements (Nb interface). However, theoperator needs to have a cost-efficient and high-capacity TDM-basedtransmission network in order to build a TDM backbone.

When IP connectivity is not provided at the remote site and the TDMbackbone, the control plane traffic can be routed via SWU (ESA24) unit toMSC Server. The user plane traffic is routed via NIWU or IWS1E/T unit toanother MGW. For more information, see Overview on IP over ATM andoptimising TDM transmission for remote 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 inUNC(UMA) *)

MGW forMSS

PSTN/PLMN x




Depending on the network, PSTN and other TDM-based networks (suchas PLMN) connected to MGW may support the following signallingprotocols based on the SS7 standard:

. ISDN User Part (ISUP)

Used for handling the ISDN bearer services (including Telephony)and supplementary services for voice and data applications. Themessage Transfer Part is used to carry the information of the ISUPMessage.

. Mobile Application Part (MAP)

Specifically designed for non-call transactions between the GSMswitching and database elements that support the roaming of mobilesubscribers.

. Telephone User Part (TUP)

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

. ISDN Q.921 User Adaptation Layer (IUA)

Used for transporting Q.921 protocol messages. In MGW, only ISDNswitches can be configured by using IUA.

The SS7-based control plane traffic is routed either directly to MSC Serveror via MGW to MSC Server.

The physical connection used in the PSTN/PLMN interface is STM-1/OC-3or E1/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 toconnect 63 E1 interfaces (or alternatively 84 T1 interfaces) over a singlefiber.

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





MGW inUNC(UMA) *)

MGW forMSS

IMS x


IP multimedia subsystem (IMS), located between MGW and SIP clients,must be able to handle large numbers of small IP packets with low end-to-end delay and low jitter. Mb interface requires the real-time transportprotocol (RTP) over user datagram protocol (UDP) to convey user planetraffic. The real-time transport control protocol (RTCP) can be used tomonitor the RTP stream and to collect statistical data. RTP provides end-to-end delivery services for data with real-time characteristics (such asinteractive audio transmission), thus making it an ideal protocol for real-time applications such as Voice over IP (VoIP). Compared to the Nbinterface, 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 andvariable site solutions, IMS must support at least one of the followingconnections:






Figure 3. IP connectivity, SW upgrade (IPFGE as interface unit)

New delivery (NPGEP as interface unit):


. Ethernet (2 x 1Gbit/s) for NPGEP

1G/100M

100Mb

Edge-router

100Mb

MGW

User plane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

IPFGE

NetAct

SWU

O&M

MGCF





Figure 4. IP connectivity, new delivery (NPGEP as interface unit)

When Ethernet connections are used for transporting IP traffic, theaddress resolution protocol (ARP) is required for IP address mapping. Asregards routing, IMS must support IPv4 or IPv6 routing. Routing is basedon static routing.

1.9 Requirements for an Unlicensed Mobile Access(UMA)

2x1G

100Mb

Edge-router

100Mb

MGW

User plane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

NPGEP

NetAct

SWU

O&M

MGCF





MGW inUNC(UMA) *)

MGW forMSS

UMA x x


MGW is able to provide the user plane connection towards UnlicensedMobile Access Network (UMAN) by using the Up-CS interface. Anotheralternative is that MGW is a part of UMA network controller (UNC)providing A-interface towards CS core.

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

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

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

UMAN (unlicensed mobile access network), connected to MGW, must beable to handle large numbers of small IP packets with low end-to-enddelay and low jitter. The Up-CS interface requires the real-time transportprotocol (RTP) over user datagram protocol (UDP) to convey user planetraffic. RTP provides end-to-end delivery services for data with real-timecharacteristics (such as interactive audio transmission), thus making it anideal protocol for real-time applications such as Voice over IP (VoIP). In theUp-CS interface, no user plane framing protocol is used. The codedspeech samples are transported on top of RTP.

Depending on the requirements of different network environments andvariable site solutions, UMAN must support at least one of the followingconnections:







New delivery (NPGE as interface unit):


. Ethernet (2 x 1Gbit/s) for NPGE

When Ethernet connections are used for transporting IP traffic, theaddress resolution protocol (ARP) is required for IP address mapping.Although MGW supports both Internet Protocol versions, IPv4 and IPv6,currently only IPv4 routing is required from UMAN. Routing is based onstatic routing.

1.9.2 MSC Server controlling MGW for UMA

MGW for UMA is controlled by MSC Server (MSS) by H.248 similarly as inthe MSS or IMS environments. There are no special requirements for MSCServer System.

1.9.3 MSC connected to MGW for UMA

The Nokia UMA system offers the standard A-interface with Nokia MGWsince Nokia MGW can serve the UMA network as part of UMA networkcontroller (UNC). This functionality enables support for multivendor CScore cases. In other words, operators are able to provide UMA access withNokia UMA solution also when Nokia MSC Server (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)protocol of 3GPP specification 08.08.

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



2 Overview of MGW functionality

The table below presents the key functionalities of MGW in differentnetwork environments. Note that this is not a feature list, but a summary ofMGW functionalities.

The different MGW architectures and MGW's roles in them are describedin chapter Introduction to MGW U4.0 release in Release overview of MGWU4.0.

Table 1. Key functionalities of Multimedia Gateway

Key Functionality Applicable in MGW

MGW inUNC (UMA)*)

MGW forMSS

Resource configuration x x

VMGW configuration x

H.248 x

IP connectivity x x

ATM connectivity x

TDM connectivity x x

User plane monitoring x

Test call x

Codecs x x see tableCodecs

supported byMGW indifferentinterfaces

AAL2 codec modification x

Electric echo cancellation(EC)

x



Overview of MGW functionality

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


MGW inUNC (UMA)*)

MGW forMSS

Acoustic echo cancellation(AEC)

x

Automatic Level Control(ALC) and fixed gain

x

2G TFO x

AMR TFO x

TrFO x

SGW x x

In-band tones andcontinuity check

x

Announcements x

Interworking service forUMA access (A/A+conversion)

x x

DTMF over RTP x

Ater interface x

Data calls x

Text Telephony (TTY) x x

Multiple isolated IPnetworks

x x

ATM CAC x

IP CAC x

ATM-ATM semipermanentconnections

x x

TDM-TDM semipermanentconnections

x x

TDM-IP semipermanentconnections

x x

ISDN User Adaptation(IUA)

x

MGW connection capacity x Licence-based

Performance management x x

Trace observation x

NEMU x x



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


MGW inUNC (UMA)*)

MGW forMSS

Fault management x x

Performance managementfunctionalities in NEMU

x x

Subscriber trace post-processing

x

NetAct-relatedfunctionalities

x x

Security functionalities x x




Overview of MGW functionality

3 IP connectivity in MGW

Table 2. IP connectivity in different MGW network environments

Functionality Applicable in MGW

MGW in UNC(UMA) *)

MGW for MSS

IP connectivity x x


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



IP connectivity in MGW

Figure 5. MGW network interfaces and IP connectivity (IPFGE as interfaceunit)

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NIS1

NIP1

Multimedia Gateway

SWU

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

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

IP connectivity is used for- Control plane: H.248 control (Mc/Mn i/f), SIGTRAN, and IWF control- User plane: IP core (Nb i/f), Mb i/f, Fixed soft switch i/f and UMA i/f- Management interface (NetAct)



Figure 6. MGW network interfaces and IP connectivity (NPGEP as interfaceunit)

Depending on hardware, the operator can choose between the IPFGE andNPGEP interface units.

The new IP interface card, NPGEP, brings along modifications to the wayIP addresses are configured. For more indormation, refer to SiteConnectivity Configuration for CS Core Network, Two Multilayer Switchesper Site.

IP connectivity is used for the following protocols:

. RTP/RTCP

. H.248

. SIGTRAN

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NPS1P

NIP1

Multimedia Gateway

SWU

IP connectivity

STM-1 for IP over ATMNPS1P

NPGEP

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T



ATM


Ethernet





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

In the Nb interface, it is possible to use either a 3GPP-based Nb interfaceor, when user plane framing protocol is not used, a Nokia proprietaryinterface. In those cases, the RTP protocol is used partly based on theIETF standards with Nokia proprietary modifications and restrictions.

As regards the benefits, the IP backbone connectivity provides thefollowing:

. 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 networkdevelopment and transmission cost savings

Codec modification

Codec modification is needed to ensure proper functionality of thefollowing features:

. TrFO

. fax and modem detection

. supplementary services of the IMS and the Mb interface

Codec modification is possible between any compressed codec andG.711, and also between two compressed codecs.

Network functions, like handovers, or service interactions in the MSCServer System may lead to a situation where multiple transcodings takeplace in the speech path. This causes extra delay and degraded speechquality. Modification of the Nb interface codec ensures that the number oftranscodings is always minimised in a speech call.

Functionality

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



Figure 7. Default IP connectivity (IPFGE as interface unit)

1G/100M

100Mb

Edge-router

100Mb

MGW

User plane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

IPFGE

NetAct

MSC Server

SWU

O&M





Figure 8. Default IP connectivity (NPGEP as interface unit)

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

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

IP over ATM (IPoA) provides a mechanism to transport IP-based controltraffic (SIGTRAN and H.248) via the ATM network in those cases in whichIP connectivity is not provided at the site. For more information, seeOverview on IP over ATM and optimising TDM transmission for remoteMGW.

2x1G

100Mb

Edge-router

100Mb

MGW

User plane

H.248/Sigtran

LAN 1

LAN 2

LAN 3

TCU

OMU/NEMU

ISU

NPGEP

NetAct

MSC Server

SWU

O&M




4 ATM connectivity in MGW

Table 3. ATM connectivity in different MGW network environments


MGW inUNC(UMA) *)

MGW for MSS

ATM connectivity x


Asynchronous Transfer Mode (ATM) is a fast-packet, connection-orientedcell-switching technology for broadband signals. The information in ATM issplit and delivered in fixed-length packets called cells. The end-to-endroute is defined through the network in the beginning of the connection andremains the same throughout the connection. This is to make sure that thecells arrive in the order in which they were sent. ATM also minimises thedelay variation. ATM cells are generated continuously by an ATMmultiplexer or an ATM terminal and filled with data.



ATM connectivity in MGW

Figure 9. MGW network interfaces and ATM connectivity (NIS1 as interfaceunit)

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NIS1

NIP1

Multimedia Gateway

SWU

IP connectivity


IPFGE

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T



ATM


Ethernet




Figure 10. MGW network interfaces and ATM connectivity (NPS1P as interfaceunit)

Depending on hardware, the operator can choose between the NIS1 andNPS1P interface units.

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

. Iu-CS interface

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

. ATM-ATM semipermanent connections

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NPS1P

NIP1

Multimedia Gateway

SWU

IP connectivity


NPGEP

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T



ATM


Ethernet





A semipermanent cross-connection through an ATM networkelement can be used for leased-line type services needed in ATMnetworks. In MGW, it is possible to establish a backup connectionfrom RNC to NetAct router through 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 theresources in the network. This makes the implementation of thesignalling network easier and cheaper for the operator: the sameATM resources can be utilised for Iu, Iur, and Nb interfaces.

. Nb interface via ATM

The Nb interface is used between two MGWs to convey user planeand signalling traffic. AAL type 2 protocol is used for the user planeand AAL type 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 forlow bit rate and short-length packet applications that are delay-sensitive.AAL type 2 is used on the user plane to transport compressed speech anddata.

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

The AAL type 2 bearer modification enables codec modification and therelated AAL type 2 bearer modification for ATM terminations (Iu and ATMbackbone).

The AAL type 2 bearer modification enables better voice quality. Also,savings in bandwidth can be achieved. Furthermore, the usage of theMGW resources can be optimised in all call cases.

The AAL type 2 bearer modification is implemented according to the ITU-Tspecification Q.2630.2 AAL type 2 signalling protocol - Capability set 2.

AAL type 5

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



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

ATM CAC

ATM CAC provides an admission service for creating and modifying VP,VC and AAL type 2 connections. For more information, see ATM quality ofservice in ATM Resource Management for Multimedia Gateway.




5 TDM connectivity in MGW

Table 4. TDM connectivity in different MGW network environments


MGW inUNC (UMA)*)

MGW forMSS

TDM connectivity x x


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)



TDM connectivity in MGW

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

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

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

. TDM-TDM semipermanent connections

Semipermanent connections created between circuit-switchedbearer channels can be used, for example, for connecting a PBXinterface into the MSC Server system via MGW. The D-channel froma PBX can be connected through one or more MGWs to the MSCServer which handles the signalling of the PBX interface.

For more information, see Overview of creating semi-permanentcross-connections in MGWin Integration Extensions for MultimediaGateway.

. TDM-IP semipermanent connections

A semipermanent connection between the circuit switched bearerchannel and the backbone network termination makes it possible toshare TDM connections over the IP backbone. As sharing TDMconnections is possible, the Interworking Functionality (IWF) andLawful Interception connections, for instance, can be concentratedin one MGW. Semipermanent connections can also be used for PBXconnection from the MGW.

The possibility to use semipermanent connections through the MGWsaves configuration work and cabling, and removes the need ofhaving a TDM interface between sites.

For more information, see Overview of creating semi-permanentcross-connections in MGW in Integration Extensions for MultimediaGateway.



Figure 11. MGW network interfaces and TDM connectivity (IPFGE/NIS1 asinterface unit)

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NIS1

NIP1

Multimedia Gateway

SWU

IP connectivity


IPFGE

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T



ATM


Ethernet





Figure 12. MGW network interfaces and TDM connectivity (NPGEP/NPS1P asinterface unit)

Functionality

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

TDM is used in the A-interface for transporting speech, data, and SS7-based signalling between MGW/MSC Server and the BSS. The A-interface is connected either to MGW or to MSC Server depending on theneeds of the operator. The user plane traffic (speech and data) is alwaysrouted via MGW to the TDM/ATM/IP backbone, while the control planetraffic (BSSAP signalling) is routed either directly to MSC Server or

STM-1/OC-3

E1/T1/JT1

SwitchingFabricUnit

NPS1P

NIP1

Multimedia Gateway

SWU

IP connectivity


NPGEP

STM-1/OC-3

E1/T1/JT1

TDM

NIWU

IWS1E/T



ATM


Ethernet




transparently via MGW to MSC Server. In addition to transporting speech,data, and signalling, the A-interface also supports the services offered toGSM users and subscribers. In the interworking service for UMA access,the A-interface is used between MGW and MSC.

A characteristic behaviour of GSM and UMTS CS data calls is that theuser plane data format cannot be used towards legacy fixed networks.Thus the user plane data of CS data calls needs to be modified so that itcan be used in legacy fixed networks. The data conversion is done in afacility called Interworking Functionality (IWF). IWF can be located in MSCServer or it can act as a standalone element (CS Data Server). Free TDMresources are hunted in MSC Server and the CS data is routed throughIWF using TDM connections between MSC Server and MGW. The IWFuser plane connection can also be routed through another MGW usingsemipermanent TDM-TDM connections. The IWF control interfacebetween MGW and MSC Server enables IWF to be located basically inany MSC Server.




6 MGW features

6.1 New chapter: Feature management in MGW

Nokia Siemens Networks is moving from parameter-based featuremanagement to a more flexible, licence-based software model supportingboth capacity-type and ON/OFF features. Some features are still handledwith FIFILE parameters.

Capacity licence enables the use of a certain feature with limited level ofcapacity. ON/OFF licence is used for the activation of features if there is norelated capacity, or if there is no need for capacity limitation.

Typically, when the first capacity licence is installed, it includes the basiccapacity. However, not all functionalities have basic capacity.

Capacity licences

Capacity licences are always NE-specific and cannot be moved ortransferred between NEs. One licence file is used for controlling only onetype of capacity. Capacity licences are incremental, which means that thetotal available capacity is the sum of the capacities of all those licence filesthat are addressed to the capacity. This makes it possible to add capacitygradually. Each capacity licence has a minimum increment that isfunctionality-specific. The maximum increment is the maximum capacitythat the NE software or hardware allows for the specific functionality.

If licensed capacity is less than hardware capacity, the licence limits theuse of the functionality. If capacity provided by licences exceeds thehardware capacity, the maximum available capacity is the same as thecapacity provided by the hardware.



MGW features

The licensing system in NEs generates alarms when licence-basedcapacity limit is reached or exceeded. From functionality point of view,exceeding the hardware-limited capacity or licence-limited capacity havesimilar effects, that is, the existing data remains intact but it is not possibleto add new data into the system.

ON/OFF licences

ON/OFF licences activate a feature or functionality in one or several NEs.Compared to parameter-based activation, ON/OFF licence provides thepossibility to order and activate the feature only in those NEs where it isneeded. ON/OFF licence is used for replacing traditional parameter-controlled feature activation for new features and selected existingfeatures.

The licence-based features require the purchase and installation of a SWlicence. With the Licence and Feature Handling MML (W7), you can installand update licences in the NE, activate and deactivate licensed MGWfunctionalities, and check their activation status.

For more detailed information on feature management, see ConfigurationData Management in MGW.

6.2 Resource configuration in MGW

Table 5. Resource configuration in different MGW network environments


MGW in UNC(UMA) *)

MGW forMSS

Resource configuration x x


MGW is a border element between different kinds of signalling and userplane interfaces. In fact, with MGW, it is possible to use three differentinterfaces simultaneously, namely TDM, ATM and IP interface. For userplane traffic, it provides both a transport and conversion mechanism.



Network element address configuration

In the Media Gateway configuration, AAL2 Service endpoint address isdefined for the MGW network element. The Multimedia Gateway SpecificParameter Handling (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, usertraffic, IP over ATM connections). The ATM interface is an external logicalinterface under which the connections are built. The ATM interface is thebasis of the VP/VC termination point, which is the basis of the connection.

The following steps are taken when configuring the ATM interfaces:

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

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

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

External termination points are created both on VP level and VC level.They are the terminating ends of the VP/VC connections. Virtual Path Linktermination points (VPLtp) must be created before any Virtual ChannelLink termination points (VCLtp) and VC-level connections can be createdunder the VPLtp. Each VPLtp is related to one ATM interface. Theinterface configuration defines the limits to the total VPLtp capacityreservations. The number of VCLtps created under each VPLtp dependson the total VPLtp capacity. Therefore, when reserving capacity for aVPLtp, you should plan how many VC-level connections are needed underthat VPLtp.

In addition to the ATM interface configuration, the ATM resourcemanagement requires the configuration of the ATM routing. The primarypurpose of routing is to locate free resources in an ATM network in order todirect 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 using the ATM Endpoint Handling (LJ) MML

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



MGW features

The external ATM route is used for directing the call to another networkelement. The routing selects an appropriate VCC endpoint and thus anappropriate virtual channel. Finally, AAL2 connection control selects a freeAAL 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. Withpercentage call distribution, traffic to a destination can be distributedamong two or more subdestinations in predefined proportions.

With alternative routing, another subdestination can be used if thesubdestination selected before is congested. For example, if there is anerror in an ATM route between two MGWs, it is possible to re-route ATMtraffic 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 theoperator must configure by using the Digit Analysis Handling (RD) and DigitAnalysis Interrogation (RI) MMLs.

TDM configuration

The following steps are taken when configuring the TDM resources toMGW:

. 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 SWU

. 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 maintainingMAC addresses 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 areconfigured either manually or automatically.

. IP protocol stacks

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

. Priorisation of redundant LAN port

The TCP/IP Stack Data Handling (QR) MML is used for configuringpriorisation of redundant LAN port for both IPv4 and IPv6. For IPv6,also the IPv6 TCP/IP Stack Configuration Handling (Q6) MML can beused.

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

User plane parameter configuration

The DSP Parameter Handling (W4) MML is used for modifying parametersthat affect media processing on the user plane.

DSP service pooling

DSP services are used for, for example, terminations (e.g. Iu or A-interface) and supplementary services (e.g. tone generation and DTMFdetection). Earlier, all DSPs in MGW were used similarly for providing allsignal processing services, but now the services have been grouped inservice pools. Service pooling enables the DSP application and platformresource usage optimisation. With careful selection of DSP services, thememory pool configuration is optimised so that memory resources areused more efficiently. Similarly, by defining that certain DSP devicesprovide only certain DSP services, a reasonable minimum capacity can beensured for services.



MGW features

One DSP service may belong to multiple service pools and all servicesmust belong to at least one service pool. At startup, each DSP device isdedicated to one service pool. This mapping is based on operatorconfiguration (percentage of DSP devices allocated to each DSP servicepool) when a DSP device is started up. It is also possible to modify DSPservice pool balance in a live network element to reflect changes in callprofile.

Services may be available from multiple service pools, but the priority ofthe service is different in different service pools. For service reservations toa new context ('empty context'), DSP resource manager always tries firstto allocate a resource from the service pool where the service has highestpriority. Only if no resource is found in that service pool, it may select aresource from the secondary service pool. When adding DSP resources toan existing context, the originally selected DSP device is preferred. If thatdevice does not have free resources for a new DSP service, or it does notprovide the requested service at all, a new DSP device is selected and aDSP-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.Only narrowband speech codecs are supported.

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

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

. Multi-Party Service Pool (pool ID 4) includes the functionalitynecessary for providing conference/multi-party call services. Havinga separate multi-party service pool allows operators to limit themaximum TCU (transcoding unit) capacity used by multi-partyservices.

. VoIP Service Pool (pool ID 5) includes the functionality required forproviding VoIP codecs for the Mb interface. The followingfunctionalities are not included in this service pool: AMR-WB andGSM FR/EFR codecs, TTY, acoustic echo canceller, Iu interface,Ater interface, A-interface and 3G CS data capability.



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 casesbetween 2G and 3G, resources are reserved from both StandardNarrowband Service Pool and Narrowband Ater/A Service Pool. The Iuinterface resource is reserved from the DSP belonging to the StandardNarrowband Service Pool and the A/Ater resource from the DSP belongingto the Narrowband Ater/A Service Pool.

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

IP QoS

The Differential services codepoint for user plane (DSCP)parameter of the DSP Parameter Handling (W4) MML and PRFILEparameter DSCP_FOR_SIGNALLING (053:0009) are used for handlingthe IP QoS configuration.

6.3 Virtual MGW (VMGW) configuration

Table 6. VMGW configuration in different MGW network environments


MGW in UNC(UMA) *)

MGW forMSS

VMGW configuration x


The overall control of MGW resources is in MSC Server, from whichresources are allocated and released using the H.248 interface. MGWprovides the possibility to create Virtual Media Gateways (VMGW) in onephysical gateway element, thus offering media resources to several



MGW features

controlling elements. The resource configuration includes the interfaceconfiguration, routing and analysis configuration and VMGW configuration.The MGW startup includes the registration, audit procedures andsupervision procedures.

Only a small part of the configuration deals with the entire networkelement, whereas most configuration tasks concern only Virtual MediaGateways inside the network element. In any case, at least one VMGWhas to be configured. Note that also the H.248 connections, routing andvarious interfaces, among others, must be configured. The TDM resourcesbelong to one specific VMGW, and free IP and ATM resources are sharedamong the servers controlling MGW. When a server takes IP or ATMresources into use, the resources are reserved to that particular server foras long as it needs the resources. After that, they are freed into commonuse again.

The following requirements must be met before the actual VMGWconfiguration:

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

. the H.248-specific data is known

. H.248 profile is known

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

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

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

. the primary and secondary addresses of MSC Server are known

. ATM AAL2 analysis tree has been created for each VMGW that usesATM backbone resources

. SCTP parameter set has been created (in case SCTP is used astransport type 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 amaximum of 10 circuit groups that contain all the PCMs dedicated to thatspecific VMGW. The user type of the circuit groups is 'vmgw' and only thistype of circuit group can be attached to a VMGW.

To optimise the usage of DSP resources, the TDM circuits attached to aVMGW can be divided into different circuit groups according to their use.That is, it is possible to define the exact purpose of TDM circuits so thatthere are specific circuit groups for different use cases (for example, forPSTN, Nb and A-interfaces).

The following additional steps are taken when configuring the TDMresources to VMGWs:

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

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

Internal circuit groups are created for each VMGW. A circuit groupcontains the CRCTs which belong to the VMGW in question. The circuitgroup must be created before adding the VMGW data (if the VMGW needsthe TDM resources). MSC Server allocates the PCM/TSL circuit withtermination_id. The termination_id is automatically generated based onthe PCM/TSL value.

The TDM hunting is in MSC Server.

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 onesecondary MSC Server address (IP address or Domain name) to eachVMGW. If the DNS functionality is used, it is possible to carry out theregistration process by using the domain name instead of the IP address.The domain name to IP address translation is performed duringregistration in the IP stack. The registration can be done automatically atstartup phase or manually by using the Virtual Media Gateway Handling(JV) MML. Each virtual VMGW sends a registration request to thecontrolling (primary) MSC Server and each VMGW has its own MSCServer addresses.



MGW features

After the registration, MSC Server may ask for the possible valueproperties of all the terminations in the NULL context, which contains allthe physical terminations that have not been reserved by the MGW. MGWreturns the requested information by sending a reply command. Also, MSCServer may ask the actual value properties of all the terminations in theNULL context. MGW returns the requested information by sending a replycommand. The TDM resources are audited with the AuditValue command.The ATM and IP resources are not audited because they are ephemeral.

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 workingstates and resources. Resource supervision is available for the MGW andMSC Server/Gateway Control Server network elements, calls, and idleTDM resources.

Network element supervision is performed interactively between MGWand MSC Server / Gateway Control Server. The time interval for networkelement supervision can be configured separately for each server by usingthe Virtual Media Gateway Handling (JV) MML.

Call supervision is conducted by MSC Server / Gateway Control Server if itis needed. The server can supervise the call-related connections bysending audit commands to MGW. If the server does not send an auditcommand during a given time frame, MGW checks the situation with aServiceChange command. The time interval for sending theServiceChange command can be configured separately for each server.The sending of the ServiceChange command can be also deactivated.

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

6.4 H.248 in MGW

Table 7. H.248 in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS



Table 7. H.248 in different MGW network environments (cont.)


MGW inUNC(UMA) *)

MGW forMSS

H.248 x


In the MSC Server (MSS) environment, the MSS controls the MGW via theH.248-based Mc interface, whereas in the IMS environment (IMS-basedconvergence network), the MSS controls the MGW via the H.248-basedMn interface.

MGW supports the H.248 protocol to perform both call-independent andcall-related procedures according to the 3GPP. Call-independentprocedures handle, for example, MGW registration and unregistrationprocedures, and procedures for handling failure situations in the H.248connection. Call-related procedures handle reserving, connecting, andreleasing the resources. The Nokia MGW provides the possibility toconfigure the H.248 profile to be used where Nokiamgwprofile is thedefault profile.

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) requests MGW toform a transmission connection. The connection is formed by usingcontexts and terminations. A context is an association between acollection of terminations. A termination is an object that sources and sinksone or more media streams. A termination is either physical or ephemeral.A PCM timeslot is an example of a physical termination and IP and ATMterminations are examples of ephemeral terminations.



MGW features

The forming of a transmission connection begins with the controller usingthe H.248 protocol to request a termination from MGW. After this, MGWreserves a context for the requested termination. MGW informs thecontroller of the reserved context and when the controller receives thecontext ID, it can request another termination for the same context ID, andthe connection is established. There is a special context, null context, thatcontains all the physical terminations that have not been reserved by theMGW. A context can have more than two terminations that are connectedwith each other. This functionality is needed, among other things, insupplementary services and handover.

In the conference service, up to 6 subscribers can be connected in aconference call. Subscribers can be added to and removed from theconference service dynamically. Subscribers are added/removed one byone to/from the conference call.

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

Figure 13. H.248 connection model within MGW

Context

Context Null Context

Context

Termination

IP

Termination

Termination

IP

IP

Termination

Termination

Termination

Termination

ATM (SVC)

TDM

TDM

ATM (PVC)



H.248 message

The format of the H.248 message is either binary (ASN.1) or text (ABNF),and the message header consists of authentication header, protocolversion, and address of the message originator.

The H.248 message is a collection of transactions. A transaction (identifiedwith transactionID) is a collection of actions and an action (contextID) is acollection of ActionRequests or ActionReplies for the context. Transactionsin a message can be handled in any order or simultaneously and repliedindependently. The H.248 protocol guarantees the order of commands(terminationID) in transaction.

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 onetransaction, and a basically unlimited number of commands in one action.The number of commands in one action is limited only by the overall sizeof a H.248 message (32 kbytes).



MGW features

Figure 14. 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



There are default H.248 protocol timer values in MGW that can be used forall VMGWs. However, MGW also makes it possible to modify H.248 timervalues (such as execution time and network delay). If there is a need tomodify the default timer values, the modification of the value depends onthe timer in question.

Some of the default timer values are stored in PRFILE (for moreinformation see PRFILE parameters in MGW), and their values can bemodified with the Parameter Handling (WO) MML. It is also possible to usethe Virtual Media Gateway Handling (JV) MML to define VMGW-specificH.248 timer values for certain VMGWs, thus over-ruling the default timervalues for the VMGW in question. And, if necessary, some of the timervalues can also be modified by MSC Server via the H.248 interfaces. Withthe timers that can be controlled by the servers, the value set by the serveroverrules both the default PRFILE value and the VMGW-specific value.

H.248 Event Log

It is possible to use the Virtual Media Gateway Handling (JV) MML tooutput H.248-related alarm and error information related to VMGW. This isuseful especially if there are problems in the H.248 registrationfunctionality.

6.5 Codecs and speech transcoding in MGW

Codecs

The following table lists the codecs that MGW supports in differentinterfaces:

Table 8. Speech codecs and payload formats supported by MGW in differentinterfaces

Speechcodecs andpayloadformats inMGW

Applicable for 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



MGW features

Table 8. Speech codecs and payload formats supported by MGW in differentinterfaces (cont.)

Speechcodecs andpayloadformats inMGW

Applicable for interface

Nb Iu Mb/Fss

A/PSTN/Nb TDM

Ater Up_CS

GSM FR x x x

GSM HR x

FR AMR x x x x

HR AMR x x x

UMTS AMR x x x

UMTS AMR 2 x x x

UMTS AMR-WB

x x x

Internet LowBitrate codec(iLBC) (IETFRFC3952)

x

G.723.1 x1) x

G.729 A/B x1) x

Clearmode(IETFRFC4040)

x

Passthrough(Nokiaproprietary)

x

DTMFpseudo-codec(IETFRFC2833/RFC4733)

x

CN pseudo-codec (IETFRFC3389)

x

1) Requires MSC Server support



Note

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

The table below lists more details of the supported codecs.

Table 9. Details of the supported speech codecs

Codec Samplingfrequency(kHz)

Bit rate (kbit/s)

Frame size(ms)

DTX

G.711 A-law/μ-law

8 64 5, 20 Yes 1)

GSM EFR 8 12.2 20 Yes

GSM FR 8 13 20 Yes

GSM HR 8 5.6 20 Yes

FR AMR 8 12.2, 10.2,7.95, 7.4, 6.7,5.9, 5.15, 4.75

20 Yes

HR AMR 8 7.4, 6.7, 5.9,5.15, 4.75 2)

20 Yes

UMTS AMR 8 12.2, 10.2,7.95, 7.4, 6.7,5.9, 5.15, 4.75

20 Yes

UMTS AMR2 8 12.2, 10.2,7.95, 7.4, 6.7,5.9, 5.15, 4.75

20 Yes

UMTS AMR-WB

16 23.85, 23.05,19.85, 18.25,15.85, 14.25,12.65, 8.85,6.60 3)

20 Yes

Internet LowBitrate codec(iLBC) (IETFRFC3952)

8 15.22, 13.33 20, 30 Yes

G.723.1 8 5.3, 6.3 30 Yes

G.729 A/B 8 8 10 Yes

Clearmode(IETFRFC4040)

8 64 20 No



MGW features

Table 9. Details of the supported speech codecs (cont.)

Codec Samplingfrequency(kHz)

Bit rate (kbit/s)

Frame size(ms)

DTX

Passthrough(Nokiaproprietary)

8 64 20 No

DTMF pseudo-codec (IETFRFC2833/RFC4733)

N/A N/A N/A N/A

CN pseudo-codec (IETFRFC3389)

N/A N/A N/A N/A

1) Supported for 20ms G.711 only

2) 7.95 is not supported because it is not supported in 8 kbit TRAU frame.Nokia BSS does not support HR AMR in 16 kbit TRAU frame.

3) 3GPP specification may support only limited node sets (bitrates)

VAD/DTX

Codecs standardised for mobile environment automatically include voiceactivity detection (VAD) and discontinuous transmission (DTX) capabilitiestogether with comfort noise (CN) generation during silent periods. Thisway the need for bandwidth can be adjusted according to voice activity,and transmission savings can be achieved both for the core network andradio interface.

MGW supports DTX also for:

. G.711 codec (on the Mb with 20ms interface)

. iLBC codec (on the Mb interface)

. G.723.1 and G.729A (on Mb, Nb, and Nb’ interfaces)

The VAD/comfort noise for VoIP codecs and G.711 is controlled by MGWonly. MSC Server (MSS) participates in the negotiations about the use ofthe codecs, otherwise it is not involved.



The implementation of the VAD algorithm is Nokia-specific. DTX isenabled for iLBC and G.711 codecs in standard way according to the IETFRFC3389.

Speech transcoding in MGW

In the 3G network, the transcoding function resides on the core networkside of the Iu interface (whereas in the 2G networks, the transcoders areon the BSS side, with the exception of the Nokia proprietary Ater-interface,where the 2G transcoder functions resides in MGW).

MGW supports transcoding between any of the supported codecs, andneed for transcoding is determined in the MGW from codec informationreceived from MSS. If allocated codecs in different call parties are notcompatible, then transcoding via linear domain (PCM/G.711) is applied.When the speech signal is available in linear PCM format, the traditionallinear domain, speech enhancements such as ALC, AEC, and EC can beapplied. ALC is also applied to signal in coded domain.

Forced payload compression

The forced payload compression enables compressed codec (GSM FR,EFR, UMTS AMR2) usage in the IP/ATM backbone as a default codec. Itprovides IP/ATM bandwidth savings compared to G.711 usage, butdecreases the speech quality because of compressed codec andadditional transcodings in MGW. The forced payload compression isuseful if bandwidth saving is more important than high speech quality, as itworks where TFO is not supported.

Figure 15. Forced payload compression

BSCBSCMGW

A

Possible Transcoding(with FR/EFR/AMR)

IP/ATMBackboneTC TC

MGW

AMRAMR

IuIu

A

RNC RNC

AMR AMR

G.711 G.711

GSM FR,EFR, AMR

GSMTranscoding

GSMTranscoding



MGW features

6.6 Signalling Gateway (SGW) in MGW

Table 10. SGW in different MGW network environments


MGW inUNC (UMA)*)

MGW forMSS

SGW x x


With the Signalling Gateway (SGW) functionality, SS7-based signallingtraffic from MGW is transported to IP-based traffic towards MSC Server(MSS) or vice versa. This is done by changing the TDM/ATM transportlayer to SCTP/IP transport for Iu-CS, A-, Ater, and PSTN/PLMN interfaces.Transporting is done on the SS7 MTP3 -level by using SIGTRANprotocols.

A Signalling Point Code (SPC) uniquely identifies a signalling point in asignalling network. It indicates the destination network element ofsignalling messages. Signalling Transfer Point (STP) acts as a linkbetween two signalling points through which signalling traffic can be routedto destination.

Signalling Point Management Cluster (SPMC) is an entity that consists ofthe SGW and an application node, but is visible to other network elementsas one SPC only, that of the application node. In the MSC Server System,SPMC makes it possible to combine both MGW and MSS under the sameSPC towards BSC, RNC or a PSTN exchange. Only the SPC of the SPMCis visible to the opposite end, and MGW acts as STP for MTP traffic. It isalso possible to make the configuration so that two or more MGWs form anSPMC, which is useful in building network element -level resilience.



SPMC is useful when a signalling point becomes an application node thatis connected to a SGW, and therefore stripped of its MTP level 2connections to network elements other than the SGW. In that case, othernetwork elements need no configuration changes as they see nothing fromthe management cluster but the same old signalling point code.

It is generally recommended that network element -specific SPCs are usedthroughout the network because their use provides the best option formanaging the states of network connections. But whenever it is moreimportant to combine both MSS and MGW under the same SPC, SPMC isrecommended.

Figure 16. SGW interfaces and protocols

BICC / SIP

MSC Server

signalling

MGW MGW

IP/ATM/TDM

BSSAP

A/Ater

MSC Server

GSM BSS

WCDMA RAN

RANAP

Iu-CS

NbSS7 (MTP3)

H.248 control

user plane

SS7 (SCCP)

Nb

(BSSAP)

SGW SGW PSTN/PLMN

PBX (30B+D)

Q931



MGW features

Functionality

The functional model for SGW in the bearer independent circuit-switchedcore network is based on SIGTRAN principles of architecture frameworkfor transport of message-based signalling protocols over IP networks. Formore information, see RFC 2719: Framework Architecture for SignalingTransport.

In MGW , the signalling transport is done for the Iu-CS, A, and PSTN/PLMN interfaces by changing the TDM/ATM transport layer (SS7 MTP L3signalling) to SCTP/IP transport. The used SCTP type may be eithermultihoming or single homing. The supported transporting technologiesare:

. ATM <-> IP

. TDM <-> IP

. ATM <-> IP/ATM

. TDM <-> IP/ATM

. ATM <-> TDM

The signalling transport protocols are:

. RANAP (SS7): ATM <-> IP

MSS receives RANAP messages by using the SIGTRAN as anunderlying protocol stack to provide reliable and SS7-compatiblelayer for IP transport. In the Iu-CS interface, RANAP signallingmessages are carried over broadband SS7 protocol stack.

. BSSAP (SS7): TDM <-> IP

MSS 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 MSS.

MSS receives BSSAP messages from MGW by using the SIGTRANas 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 theSCCP-layer's services (MAP/CAP/INAP), signalling transportingbetween PSTN/PLMN network and MSS over IP is made by usingSIGTRAN M3UA/SCTP (SS7 MTP3 - User Adaptation Layer /stream control transmission protocol) protocols.



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

For transporting SS7 signalling which needs the MTP-layer'sservices (ISUP/TUP/IUP), signalling transporting between PSTN/PLMN network and MSS over IP is made by using SIGTRAN M3UA/SCTP (SS7 MTP3 - User Adaptation Layer / stream controltransmission protocol) protocols.

. ISDN Q.921 (IUA): TDM <-> IP

The IUA (ISDN Q.921 - User Adaptation Layer) protocol enablesMGW to transport Q.931/DSS1 messages to MSS on top of IP usingthe stream control transmission protocol (SCTP). For moreinfomation, see sectionISDN User Adaptation (IUA).

ISDN User Adaptation (IUA)

The IUA support for MGW functionality enables private branch exchanges(PBXs) to be connected to the MSC Server System via MGW. In thissolution, MGW terminates TDM-based LAPD signalling (Q.921) from aPBX and transfers DSS1 (Q.931) signalling to MSS over SCTP/IP with theIUA protocol.

With IUA, it is possible to build a primary rate access (PRA) solution with astandalone MSS using IP interfaces only. Earlier, devices with a PRAinterface, such as a PBX for example, were connected to MGW, and theQ.931 messages were transported between MGW and the MSS usingdedicated TDM lines and with semipermanent connections. With IUA, IPtransport can be used instead of TDM lines.



MGW features

Figure 17. IUA interfaces and protocols

6.7 In-band tones and continuity check in MGW

Table 11. In-band tones and continuity check in different MGW networkenvironments


MGW inUNC(UMA) *)

MGW forMSS

In-band tones andcontinuity check

x


ATM/IPbackbone

PBXPBXPBX

MGW

DSS1(D-channel)

MSS

Q.931IUASCTPIP

IUA is used on top ofSCTP/IP to transportQ.931 protocol messages

MGW



Because the user plane goes through MGW, there needs to be afunctionality for generating and detecting in-band tones. The continuitycheck functionality is required when PSTN connections are terminated toMGW.

In MGW, tones, Dual Tone Multi-Frequency (DTMF) and continuity checkare provided by Digital Signal Processing (DSP), located in the TCUfunctional unit. MSC Server controls the MGW tones, DTMF, andcontinuity check functionalities through the H.248 MEGACO interface.

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

The tones in the MGW are made according to the MSC specifications. Youcan check the PRFILE tone parameter 043:0009 value by using the WOIcommand and modify it by using the WOC command.

With the National Tones Handling MML (commands of the W5 commandgroup), you can interrogate, distribute, modify, and reload tones and DTMFsignals in MGW.

Functionality

Tone Generation

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

Depending on the tone type, the tone generation can be stopped by MGWitself, or it is stopped by MSC Server.

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

DTMF Generation/Detection

MSC Server requests MGW to generate DTMF using the Basic DTMFGenerator package. MGW then makes DTMF resource reservations andgenerates the requested DTMF tones into the bearer. MGW sends a replyto MSC Server after the DTMF tones are generated.

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



MGW features

MSC Server requests MGW to start DTMF detection by an H.248command using DTMF detection package (which extends tone detectionpackage). MGW then makes DTMF resource reservations and starts theDTMF detection. Finally, MGW notifies all detected DTMFs to MSC Server.

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

DTMF delivery in RTP payload

The usage of the RTP payload format (IETF RFC2833 / RFC4733) forDTMF digits delivered from IMS towards the CS network and from the CSnetwork towards IMS is supported. In this mechanism, DTMF tone eventsare sent as separate RTP packets instead of in-band audio signals in theRTP stream. MGW differentiates these packets by the RTP payload typeand extracts the necessary information (such as DTMF digit type andduration) from the RTP packet payload. When DTMF digits are senttowards CS network they are reproduced as in-band audio signals, orindicated to MSC Server for out-band signalling.

In order to transfer DTMF digits in a speech call as specified in IETFRFC2833 / RFC4733, MSC Server reserves the speech and DTMFcodecs via H.248 Mn interface in MGW. This can be done in call setupphase or during ongoing call.

The functionality for delivering DTMF digits towards the IMS is needed, forexample, when a user with a multiradio terminal is roaming in a CSnetwork and makes a call to configure his/her voice mail located in the IMSdomain. Also services offered by the Business Communication Server, forexample, are accessible for the user roaming in the CS domain with amultiradio terminal.

The operator can activate and deactivate the DTMF delivery functionalitywhen the feature is available. When the feature is available, and it isactivated, MGW is able to

. detect the DTMF digits received from the Mb/Fss interface, andfurther send the digits towards CS or PS network by using either in-band method (DTMF tone – G.711) or out-of-band method (H.248indication)

. detect the DTMF digits/tone received either in-band from CS or PSnetwork or out-of-band from the H.248 interface, and further sendthe digits towards Mb/Fss interface by using the RFC2833 /RFC4733 method



Figure 18. DTMF delivery alternatives

Continuity check in MGW

Continuity check can be used for checking the condition of an externalcircuit. In the TDM interfaces, the test tones are used for checking that theloopbacked tone is similar to to the sent test tone. MGW has twopossibilities for participating in the continuity check:

. 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 torelease the loopback connection and MGW releases the loopbackconnection and sends a reply to MSC Server.

Loopback is supported in the TDM interface only.

. Signal sending and detection

PSTN / TDM

Mb / Fss

2) H.248indication

MSS

Mb / Fss

5) H.248notification

MGW

3) DTMF digitssignalled withinRTP (RFC2833/

RFC4733)

4) G.711DTMF tone

3) DTMF digitssignalled withinRTP (RFC2833/

RFC4733)

1) G.711DTMF tone

PSTN / TDM



MGW features

MSC Server requests the transceiver functionality for continuitycheck from MGW. MGW then reserves the DTMF detection and toneresources for continuity check and starts the continuity test tonesending and detection. MGW sends a reply to MSC Server after theresources are reserved. Finally, MGW informs MSC Server of theresult when the continuity check has been performed and releasesthe reserved resources.

Continuity check for Israeli ISUP T904 is also supported.

6.8 Announcements in MGW

Table 12. Announcements in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

Announcements x


The same announcement functionalities are provided in MGW as in MSCServer.

Announcement files are loaded from and administered in OMU with theMedia Gateway Announcement File Handling (JA) MML. Language tagsare configured using Context Manager Settings Handling (JL) MML.

Functionality

Announcement speech format is 64 kbit/s coded with the A-law/μ-lawcodec. The network operator is responsible for storing speech recordingsin the right format. Announcements are generated from MGW in the formatthey are needed for the subscriber (for example, AMR-coded).Announcement sample files are stored in VANU.



The functional unit TCU is used for inserting an announcement from agiven termination point to the user connection. The speech recordings aretranscoded with a suitable codec when needed.

MSC Server's call control requests announcements in different callphases. When the user plane is in MGW, MSC Server requestsannouncement connections from MGW using the H.248 protocol(MEGACO). References to announcement parts such as speechrecordings and variable parts are transferred with the 'H.248.9 AdvancedMedia Server Package' and 'H.248.7 Generic Announcement Package' toMGW, 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 internallyto the user plane termination (TDM, ATM, IP) and replies. MGW ends theannouncement with a MEGACO request received from MSC Server.

Figure 19. MGW announcement environment

The MGW announcements service provides the following:

. possibility to transfer multilingual variable announcements

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

Multimedia Gateway

AnnouncementService

TDM,ATM,IP

TDM,ATM,IP

C1

H.248 commandsfrom MSC Server

X

VANU



MGW features

. announcements generated near a user plane resource gaintransmission savings compared to a pcm circuit -connected mediaresource function

. a solution suitable for further IP 'announcements' as packet filesending (for example, graphic and video).

6.9 Data calls in MGW

Table 13. Data calls in different MGW network environments


MGW inUNC (UMA)*)

MGW forMSS

Data calls x


Data calls in MGW for MSS

Generally, the user plane data format used in either A or Iu-CS interfacescannot be used towards a legacy fixed network in GSM and UMTS circuit-switched data calls as such. This is because the user data terminal inlegacy fixed network does not usually understand the data format used inGSM and UMTS circuit-switched data calls. The conversion betweenthese data formats is made in a facility called Interworking Functionality(IWF). IWF is located in MSC Server (MSS) or in CS data server (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 MSS internallyor by MGW over IP connection using a proprietary protocol. MGWsupports TCP and SCTP as transport types. The IWF control interfacebetween MGW and MSS enables IWF to be located basically in any MSS.It also enables IWF to be separated from MSS 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 networkelement, select hunt 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 allocatedfor data call use.

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

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

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



MGW features

Figure 21. 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 insideAAL2 SDU. This framing allows either transparent or non-transparent dataservices. In the transparent case in which the IWF is not involved, Iu-UP isin 'transparent mode'. The data rates supported in the Iu-CS interface withthe transparent service are 28.8, 32, and 64 kbit/s. In case of transparentcalls of 64 kbit/s, no rate adaptation is needed. In case of transparent callsof 32 kbit/s, the rate adaptation between 32 kbit/s and 64 kbit/s is made inMGW for MSS. In case of transparent calls of 28.8 kbit/s, the rateadaptation is made in IWF.

Conversion from Iu-UP to ATRAU' is done by the TCU functional unit inMGW. This conversion has to be done when data traffic is received fromMSS or sent towards MSS.

The Iu interface is connected to MGW, and IWF control parameters aresent from MSS to MGW when data call terminations are created. MGWbuilds the IWF leg and controls the 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



Figure 22. Data call in Iu interface

Fax and modem detection

In PSTN-originated calls, the control plane signalling (for example, ISUP)does not always carry the necessary information for differentiatingbetween the speech, fax and modem data calls. Thus, if a compressedcodec, echo canceller, or other speech enhancement is used, the fax andCS data calls fail. Fax and modem detection makes it possible to optimisethe use of backbone transmission resource so that compressed speechcodec is used for speech calls and G.711 is used for fax and modem datacalls. After MGW has notified the detection of fax or modem tone signal,MSS initiates a codec modification procedure to change the backbonecodec to G.711.

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

Fax/Modem over IP by using passthrough codecs in MGW

The modem passthrough over VoIP (voice over IP) is used in the existingVoIP solutions in order to provide the transport of modem signals throughan IP network by using the passthrough channel. Fax/modem datatransported in passthrough channel is encoded according to the G.711 A-law or μ-law, depending on the configuration. The operator can alsoconfigure the RTP payload value used for passthrough channel data. Alsothe interface (Mb/Nb) in which the passthrough mechanism is used, can beconfigured by the operator.

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



MGW features

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

Fax/Modem over IP by using clearmode codecs in MGW

The clearmode pseudo-codec is specified to carry 64 kbit/s channel datatransparently in RTP packets through VoIP networks (Mb/Fss). Theclearmode pseudo-codec functionality can be used with or without thepassthrough mechanism. Together with the passthrough functionality, theclearmode pseudo-codec enables support for fax/modem data calls inmost IMS-CS and SIP access interworking situations.

When a standardised clearmode mechanism is supported by both MSSand MGW, the MSS System always tries to use it in the Mb/Fss interfacefor fax/modem data calls. However, also the passthrough mechanism isneeded in order to handle cases where the use of clearmode is notpossible (for example, when the SIP client does not support clearmode).

Passthrough and clearmode methods can be used together with the fax/modem detection functionality. This gives the operator a possibility tofurther optimise the core network’s transmission capacity for IMS-CSinterworking speech calls.

6.10 User plane monitoring in MGW

Table 14. User plane monitoring in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

User plane monitoring x




The possibility for user plane monitoring in MGW provides additional toolsthat can be used to facilitate testing and troubleshooting. The User PlaneMonitoring Handling (JK) MML makes it possible to:

. investigate the services and resources attached to a certain H.248termination

. monitor the physical and ephemeral resources of a VMGW

. monitor the topology of H.248 terminations in a single context

. monitor active contexts in VMGWs

. monitor all test terminations

User plane monitoring can be used for requesting information aboutreserved physical (TDM) or ephemeral (ATM, IP) resources. Freeresources, such as terminations (physical or ephemeral) in the NULLcontext, cannot be monitored. Also, the User Plane Monitoring HandlingMML can only be used for temporary monitoring of the reserved resources;it provides information on the prevailing status of the reserved resources atthe moment when the command is entered.

The user plane monitoring functions require some amount of systemresources, and thus it is recommended that they are not heavily usedduring the busy hours when MGW is handling an extensive number ofsimultaneous calls.

6.11 Test call in MGW

Table 15. Test calls in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

Test calls x




MGW features

The test call functionality enables better fault traceability in MGW inoperator's network environment for Nokia Siemens Networks personnel.The test call functionality can be used in the MSC Server products forrouting a call through the network element in a controlled manner, forexample by using specific dedicated resources such as the GSM/UMTSradio cell/service area/TDM circuit or TCU unit/IP subnetwork in the MGWside. MGW uses the test call information for storing detailed data (such aslog writings, monitorings, and file writings, for example) about test calls.This data can then be used by Nokia Siemens Networks personnel fortroubleshooting purposes.

The test call functionality can be activated for TDM, ATM, and IPconnections in MGW in different ways:

. by MSC Server (MSS) via the H.248 control

. directly in MGW with a service terminal command with severalmethods by Nokia Siemens Networks personnel

It is also possible to interact with trace observation. This means that MGWactivates an IMSI/IMEI number as a test call by using a service terminalcommand while the same IMSI/IMEI number is set as traced in the MSSside.

The test call functionality can be used, for example, when problems havebeen detected in certain types of calls in the MSC Server System. Eachunit can be tested one by one to find out the faulty unit. Test calls can alsobe used for testing new TCU/TPG units before adding/replacing them to/inMGW.

By combining and comparing the data in test call logs and the informationfrom other testing equipment or network elements (for example, tracereport from NetAct or CDR from MSS), it may be easier to find out wherethe actual problem lies.

A test call can be executed in a network that has high traffic load, becausetest calls can use a predefined resource. If using blocked transcodingprocessor group (TPG) unit(s) in the test call, the user must wait that thereis no more traffic in those units. The TCU/TPG that is dedicated for test callpurpose must have the DSP service types used for the call. If theresources in one TCU are not enough, then the next TCU must bededicated for test calls. DSP service pools can be examined by using theSignal Processing Service Handling (WP) MML.



6.12 Performance management in MGW

Table 16. Performance management in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

Performance management x x


As MGW is an independent network element, it has to offer resourcemanagement capabilities to support operators since they need MGWperformance data to support network (element) dimensioning. Byfunctionality, MGW performance management can be divided intomeasurements and trace observation. Measurements count events, data,or volume of the measured object(s). The measurement report isgenerated at the end of each result accumulation 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 differentinterfaces. Since MGW can be controlled by several MSC Servers, it isessential that the dedicated resources are optimally utilised.

The operator can define a certain statistical measurement to startimmediately or at a certain point of time (date and time). The measurementis active until the operator stops it or when the predefined end time isreached (on condition that the end time has been defined when startingthe measurement). The operator can define a period of time (from 15 up to60 minutes) for the measurement reports, that is, how frequentlymeasurement reports are generated. The recommended measurementinterval is 60 minutes.



MGW features

The statistical measurements in MGW can be controlled by using theMeasurement Handling (T2) MML and/or the NE Measurement ExplorerGUI in NEMU. Also SS7 and PDH measurements and their reports can beviewed in NetAct in the same way as all other measurements.

MGW performance management consists of the following measurements:

Table 17. MGW measurements

Measurement MeasurementID (MID)

Applicable in MGW

MGW inUNC(UMA) *)

MGW forMSS

PDH statistics 145/91H x

MTP signalling linkavailability report

208/D0H x

MTP signalling linkperformance report

209/D1H x

MTP signalling linkutilization report

210/D2H x

MTP signalling point statusreport

211/D3H x

MTP signalling link set androute set availability report

212/D4H x

MTP signalling traffic reportof signalling points

213/D5H x

MTP signalling traffic reportof user parts

214/D6H x

MTP matrix signalling trafficreport

215/D7H x

SCCP signalling pointreport

216/D8H x

SCCP subsystem report 217/D9H x

SCCP local subsystemavailability report

218/DAH x

SCCP single meters report 219/DBH x

STM-1 interfacemeasurement

513/201H x x

IMA logical interfacemeasurement

514/202H x



Table 17. MGW measurements (cont.)


Applicable in MGW

MGW inUNC(UMA) *)

MGW forMSS

SONET/SDH protectiongroup measurement

516/204H x

ATM layer performancemeasurement

528/210H x

ATM virtual path connectionmeasurement

529/211H x

ATM virtual channelconnection measurement

530/212H x

ATM route loadmeasurement

531/213H x

ATM interfacemeasurement

532/214H x

AAL5 protocolmeasurement in DMX

547/223H x

AAL5 protocolmeasurement in Chorus

549/225H x

AAL2 Path CAC resourcemeasurement

550/226H x

AAL2 signalling at NNImeasurement

552/228H x

Ethernet interfacemeasurement

561/231H x x

TCP/IP protocolmeasurement

563/233H x x

IP measurement on IPinterface

565/235H x

UDP measurement on IPinterface

566/236H x

Unit load measurement 592/250H x x

Overload control with WACperformance measurement

594/252H x x

Availability performancemeasurement

608/260H x x

DSP state changesmeasurement

612/264H x



MGW features

Table 17. MGW measurements (cont.)


Applicable in MGW

MGW inUNC(UMA) *)

MGW forMSS

DSP resource utilisationmeasurement on NE level

615/267H x

DSP load measurement 617/269H x

Signalling transcodingmeasurement

643/283H x

Multi-party callmeasurement

644/284H x

Connection measurement 645/285H x

TrFO and TFOmeasurement

648/288H x

Data call measurement 649/289H x

Announcementmeasurement

656/290H x

H.248 measurement 658/292H x

Acoustic Echo Cancellationmeasurement

660/294H x

M3UA association setmeasurement

661/295H x

User Plane initialisationmeasurement

662/296H x

Echo Cancellationmeasurement

663/297H x

IP CAC measurement 768/300H x

RTP/RTCP protocolmeasurement in MGW

848/350H x x

Text Telephonemeasurement

849/351H x

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



MGW offers long-term performance data rather than single call -relateddata. One physical MGW can be divided up to several virtual MGWs(VMGW).

The system produces a measurement report at the end of each resultaccumulation period. There are two ways to examine the measurementreports:

. By using NEMU's NE Measurement Explorer. For instructions, seeBrowsing measurement data with NE Measurement Explorer .

. By using Nokia NetAct. At the end of each result accumulationperiod, the measurements reports are transferred to NEMU, fromwhere they are delivered to Nokia NetAct. The performancemanagement post-processing for the reports is done in NEMU. Formore information on performance management post-processing,see Performance Management Functionalities in NEMU.

6.13 Trace observation in MGW

Table 18. Trace observation in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

IMSI / IMEI traceobservation

x


As MGW is an independent network element, it has to offer resourcemanagement capabilities to support both operators and vendors.Operators need MGW performance data to support network (element)dimensioning, and vendors need data on network element performance(such as possible fault situations). By functionality, MGW performance canbe divided into measurements and trace observation. For more informationon measurements, see Performance management in MGW.



MGW features

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 tracecases in one MGW is limited and if the number of trace cases reaches thelimit, MGW discards the trace activation and sends a notification to MSCServer if the notification event has been armed.

MSC Server also sends an H.248 modify command to activate trace. Theuse of H.248 modify commands enables trace activation also in MGWlocated on the other end of the ATM/IP/TDM backbone even though itstermination is already reserved. Thus it is possible to get trace reports in allcall 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 reportsto Nokia NetAct by using the Nokia proprietary NWI3 interface.

Trace observation can be used by subscriber administration and networkmanagement for subscriber observation (for example, following acustomer complaint, or when the network operator suspects that anequipment malfunction has taken place). MSC Server includes an IMSI/IMEI type indication in the trace activation that it sends to MGW, whichmakes it possible to monitor active subscriber traces via the NetAct TraceViewer. By utilising IMSI/IMEI type indications, the NetAct Trace Viewercan be used to trace multiple subscribers (SIM cards) simultaneously.

Enhanced MGW trace database provides a logical database structure andplenty of space for traced terminations.

For more information, see chapter IMEI/IMSI trace observation in MGW forMSS in Measurement and Trace Management in MGW.

6.14 Speech enhancements in MGW



Table 19. Speech enhancements in MGW


MGW inUNC(UMA) *)

MGW forMSS

Electric echo cancellation(EC)

PSTN/PLMN

Acoustic echo cancellation(AEC)

Iu-CS, A,Ater

Automatic Level Control(ALC) and fixed gain

x

(Not in Nb)




MGW features

Figure 23. Location of echo cancellers in the network

6.14.1 Electric echo cancellation (EC) in MGW

Speech calls from the 2G/3G mobile system to PSTN are terminated onlocal switch line cards where the two-wire to four-wire conversion takesplace. The hybrid used to carry out this function is never perfect and echois generated in the downlink direction which degrades the speech callquality for the 2G/3G mobile user. To overcome this situation, an echocancellation functionality is used in MGW in calls between PSTN andmobile network. This echo cancellation functionality conforms to ITU-TG.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



Speech calls from the 2G/3G mobile system to the PLMN (for example,GSM) do not require the electric echo cancellation functionality in MGW. Itis desirable to prevent multiple echo cancellers in the connection.Therefore, the echo cancellation functionality in MGW is enabled/disabledby the signalling information.

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, thePSTN electrical echo generated in a hybrid, there is an echo canceller inMGW. The echo canceller memorises the voice samples sent to the PSTNand then compares the samples to the voice samples received back fromthe PSTN. These speech samples (containing the echo) are modified bythe echo canceller to prevent the echo effect from being passed back tothe mobile.

In the uplink direction, the PSTN phone user hears an acoustic echo ashis/her voice is transmitted back from the mobile phone and he/sheexperiences delay generated both in core network and radio network. Todeal with this echo, the mobile phone is equipped with a built-in acousticecho canceller and an AEC functionality is provided on the network side byMGW.

MSC Server controls the use of electric echo cancellation in MGWdynamically on a per-call basis based on EC control information conveyedin network-level signalling.

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

6.14.2 Acoustic echo cancellation (AEC) in MGW

Acoustic echo is generated in the uplink direction due to the acousticcoupling from the ear-piece to the microphone of the User Equipment(UE). Acoustic echo is removed by a built-in acoustic echo control deviceof the UE/MS (Mobile station). Sometimes this is not sufficient, andtherefore an AEC functionality is provided on the network side by MGW.The use of AEC is controlled by interface-specific parameters for Iu, A, andAter in MGW. MSC Server does not control the use of AEC.

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



MGW features

6.14.3 Automatic level control (ALC) in MGW

The performance of the different equipment in the speech path variesdepending upon the signal levels. Each active device, such as an amplifieror speech codec, has a certain dynamic range over which it functions tospecification. Outside this range the performance may degrade rapidly,leading to noise and distortion of various types. For this reason, it isimportant to maintain speech levels within the dynamic range specified forthe equipment.

Automatic Level Control (ALC) is a useful solution to this problem. Itprovides an effective, non-obtrusive means of improving the perceivedspeech quality of a call by automatically optimising active speech levels.Varying speech levels are reacted to by software, adjusting the appropriateparameters in real time to an optimal operating level. In ALC, gain isadjusted towards the given target active speech level, and in fixed gain,the gain is given by fixed dB levels. ALC is also supported in multipartycalls to incoming call branches.

In MGW, noise compensation provides an additional ALC enhancement.ALC uses noise compensation to adjust the signal level according to theopposite path noise level. Egress direction ALC performed in MGW iscontrolled by the noise level measured in the ingress direction of the sametermination. That is, noise compensation adjusts the target level of theopposite path depending on the noise level. When the noise level exceedsa certain threshold, the target level starts to increase. Noise compensationimproves intelligibility when the user is in a noise environment.

In addition to linear PCM gain adjustment, ALC can also be appliedstraight to coded speech parameters. This is called Coded Domain ALC(CD-ALC). Coded domain processing is supported for GSM HR, EFR, FR,AMR and AMR-WB coded speech. The benefit of the CD-ALC is that TrFOor TFO can be used simultaneously with ALC. However, CD-ALC cannotbe applied to the following transparent TFO connections:

. A-A

. PSTN-PSTN

. Mb-Mb



6.15 TFO in MGW

Table 20. TFO in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

2G TFO x

AMR TFO x


Normally, a compressed speech codec used in GSM radio interface istranscoded into a G.711 codec when connecting a call via the A-interfaceto MGW in CS core network, which decreases speech quality. In tandemfree operation (TFO), the transcoding functions are bypassed, whichenables transparent speech connection for GSM calls, resulting inenhanced speech quality. A TFO connection is established by using in-band TFO negotiation between transcoders (TFO peers). In-band TFOnegotiation leads to the TFO connection if TFO-compatible codecs areused beyond both TFO peers. After TFO is successfully established, theTFO peers start to communicate between each other by using the TFOframes that carry the access side compressed codec embedded in theleast-significant bits of 64kbit/s PCM channel.

When TFO connection is established between 2G transcoders located inBSS, the TFO frames are passed transparently through MGW(s) andTDM/IP/ATM backbone.



MGW features

Figure 24. TFO with G.711 in backbone

With Ater interface in MGW, the 2G transcoders are located in MGW whenMGW operates as a TFO peer. The TFO based on 2G transcoders locatedin BSS with a G.711 codec in backbone is a BSS feature. In case of Aterinterface integrated to MGW, the TFO is an MGW feature.

The standard G.711 / 5 ms or NSN proprietary G.711 / 20 ms can be usedfor TFO when G.711 is used in the IP backbone. The G.711 / 20 msprovides the same functionality and quality, but requires less IP bandwidth.

In addition to establishing TFO between 2G transcoders, MGW supportstwo enhanced TFO alternatives:

. 2G TFO with Payload optimisation mode for FR and EFR

. AMR TFO

2G TFO with Payload optimisation mode

2G TFO with Payload optimisation mode makes it possible to transmit onlythe compressed codec over the IP/ATM backbone instead of G.711,enabling bandwidth savings without decrease in speech quality. Thecompressed codec is extracted from TFO frames in MGW, transmittedover IP/ATM backbone, and included back in TFO frames in theterminating side MGW. The TFO with Payload optimisation mode is anMGW functionality without any effect on the TFO functionality in BSS sideTCs.

BSCBSC MGW MGW

TFO Framing =G.711+codec

TDM or IP/ATMwith G.711

TFO Negotiation

TCTC

A A

CodecG.711

Codec

G.711

Codec



CodecG.711

Codec

No transcoding...



Figure 25. 2G TFO with Payload optimisation mode

The 2G TFO with Payload optimisation mode for GSM FR and EFRcodecs functionality in MGW supports both A and Ater interfaces.

### The following section updated according to U4.1 FUD:

AMR TFO

The AMR TFO feature enables a wider variety of use cases for the AMR-WB codec in mobile networks. MGW provides AMR TFO supportespecially for AMR-WB and also for AMR codecs under the control of theMSS. In addition, AMR TFO can be used for other TFO-capable codecs.

AMR TFO enables better speech quality with AMR-WB speech codec inthe following cases, for example:

. 3G calls through TDM/G.711 backbone (for example, inter-operatorcalls)

. basic 2G calls

. 2G-3G interworking calls

The AMR TFO functionality is compliant with 3GPP TFO specifications.Thus it is a standard functionality, extended by Nokia Siemens Networks -specific enhancements. With these proprietary enhancements, also 2GAter calls can utilise AMR TFO.

BSCBSC MGW MGW


IP/ATM Backbone

TFO Negotiation

TC

A A

CodecG.711

Codec

GSM FR, EFR TFO Framing =G.711+codec

CodecG.711

Codec

MSS MSS

TC

Codec



MGW features

In 2G Ater calls, it is possible to achieve optimal speech quality as well assavings in the transmission capacity, as the compressed codec can beused in the Ater and Nb/Mb backbone interfaces instead of G.711 (that is,the '2G TFO/TrFO' -like solution, see figure AMR TFO in Ater calls – '2GTFO/TrFO' -like situation below).

The AMR TFO functionality increases the number of use cases in whichthe AMR-WB -level speech quality can be achieved, for example:

. 3G

. 2G (A -interface)

. 2G (Ater interface, including the '2G TFO/TrFO' -like functionality;see figure AMR TFO in Ater calls – '2G TFO/TrFO' -like situation

. 2G - 3G (TFO - TrFO interworking)

. PLMN interconnect

. IMS-CS interworking call cases

To summarise, AMR TFO can be used for extending the usage of theAMR-WB codec. In addition, AMR TFO increases the probability toachieve TFO for AMR-NB, EFR, FR and HR codec types.

With AMR TFO, the MSS can control TFO in MGW by using the standardH.248 Mc/Mn interface procedures. When TFO is negotiated under thecontrol of the MSS, the codec(s) used beyond the TFO peer(s) can bemodified so that the possible codec mismatch situations can be resolvedand most optimal speech quality can be achieved.

In 2G calls, AMR TFO first of all introduces the possibility to use the AMR-WB codec. This requires support for the AMR-WB and TFO also in theBSS.

In 'standard A-interface' cases, MGW acts as a TFO peer towards the 2Gtranscoder that is located in BSS. Based on the information received aboutthe TFO negotiation from the 2G transcoder, the BSC handles codecoptimisation that takes place in the BSS.



Figure 26. AMR TFO: TFO-TrFO interworking example

In Nokia Siemens Networks -specific Ater interface cases, MGW enableswhat can be called a '2G TFO/TrFO' -like situation. If enabling is notpossible, MGW acts as a TFO peer towards the distant transcoder.

Figure 27. AMR TFO in Ater calls – '2G TFO/TrFO' -like situation

BTSBSC2GTC

2G BSS

MSS MSS

MGWMGW IP/ATM3G RAN

AMR-WB AMR-WBAMR-WB AMR-WBG.711

H.248

TFO(G.711 + AMR-WB)

TFO (AMR-WB)

InbandTFO negotiation

Out-of-bandTrFO negotiation

MSS

TFO(G.711 + AMR-WB) AMR-WBAMR-WB

MGW

AterAter, Iu,Nb, Mb



MGW features

Figure 28. AMR TFO in Ater calls – TFO between MGW and distant TFO peer

The operator can control the AMR TFO feature with MMLs.

TFO compatible codecs

The following table provides a detailed list of the TFO compatible codecsand codec configurations:

Table 21. TFO compatible codecs and codec configurations

Codec typeandcompatibility

Codec isTFOcompatiblewith itself

UMTS AMR2 UMTS AMR FR AMR HR AMR

UMTS AMR22)

x x 1) x x

UMTS AMR 2) x x 1)

FR AMR 2) x x x

HR AMR 2) x x

UMTS AMRWB 2)

x

EFR x

FR x

HR x

MSS

TFO (G.711 + AMR-WB) AMR-WBAMR-WB

MGW

Ater

A, Nb, Mb(G.711)

DistantTC



1) UMTS AMR2 and UMTS AMR codec types are TFO compatible only insingle mode configurations

2) To enable TFO for multi-rate speech codecs (AMR and AMR WB), thecodec modes/mode sets must be either exactly the same in both sides ofthe TFO peers, or the use of codec modes must be restricted to a commonsubset of the ACSs (i.e. mode sets) by means of maximum rate control (i.e. common subset of ACSs from the lowest mode)

6.16 TrFO in MGW

Table 22. TrFO in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

TrFO x


The purpose of transcoder-free operation (TrFO) is to completely removethe unnecessary transcoding from the speech path. This is achieved withan out-of-band signalling which performs the codec negotiation andselection throughout the network. Optimally, this means that speechtranscoding is only performed in the peer UEs (User Equipment, 3Gterminal).

TrFO is originally standardised for 3G calls only (that is, calls via UTRAN).A standard way of utilising TrFO with AMR in IMS-CS interworking caseshas also been specified by 3GPP. Nokia MGW also supports TrFO withVoIP codecs in SIP-CS interworking cases. TrFO provides optimisedspeech quality and enables substantial savings in transmission capacity inthe core network. Only compressed speech samples are transmitted over



MGW features

the ATM/IP networks and the default codec for 3G networks requires lessthan 16 kbit/s capacity (in comparison to the 64 kbit/s for transcodedspeech). This results in savings in both network transmission and MGWcapacity.

TrFO is based on 3GPP specifications for bearer-independent circuitswitched core network where the control plane is handled by MSC Server(MSS), and the user plane by MGW. Thus, in 3GPP bearer-independentnetwork architecture, MSS performs the negotiation and selection of thecodec used in the user plane, while MGW handles the user planeprotocols and provides a speech connection without transcoding, whenpossible.

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

The following table provides a detailed list of the TrFO compatible codecsand codec configurations:

Table 23. TrFO compatible codecs and codec configurations


Codec isTrFOcompatiblewith itself

UMTSAMR2

UMTS AMR FR AMR HR AMR

UMTS AMR2 2) x x 1) x x

UMTS AMR 2) x x 1)

FR AMR 2) x x x

HR AMR 2) x x x

UMTS AMR WB2)

x

EFR x

FR x

G.711 x

G.711 + CN(dtx) 3) 4)

x

G.723.1 x

G.723.1 +Annex A (dtx) 3)

x



Table 23. TrFO compatible codecs and codec configurations (cont.)


Codec isTrFOcompatiblewith itself

UMTSAMR2

UMTS AMR FR AMR HR AMR

G.729A x

G.729A +Annex B (dtx) 3)

x

iLBC (mode:20ms) 3)

x

iLBC (mode:30ms)

x

iLBC (mode:30ms) + CN(dtx) 3)

x

1) UMTS AMR2 and UMTS AMR codec types are TrFO compatible only insingle mode configurations

2) To enable the TrFO for multi-rate speech codecs (AMR and AMR WBcodec types), the codec modes/mode sets must be exactly the same inboth sides of the MGW

3) Usage of DTX affects the codecs' TrFO compatibility

4) CN = Comfort Noise Pseudo-codec



MGW features

Figure 29. 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 performedat the edge of the PLMN/3G network, that is, at the 2G or PSTNinterconnection.

TrFO is applicable in the MSS environment and in IMS/UMA interworkingcases.

6.17 Text telephony service for 3G calls in MGW

Table 24. Text telephony service for 3G calls in different MGW networkenvironments


MGW inUNC(UMA) *)

MGW forMSS

Text telephony service for3G calls

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




TTY is a functionality that enables text-based communication over aspeech bearer. It is mainly intended for people with impaired hearing orspeech. The feature is specified by ITU-T, and it is a regulatoryrequirement in the USA for emergency calls. However, TTY is not only forUS emergency calls, as it can be used worldwide for ordinary callsbetween persons who require the use of text telephony.

Figure 30. Text telephony between a mobile and fixed terminal

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 the same level of support in 3G as well, the functionality isimplemented in MGW.

When using TTY, text is transmitted through ordinary speech trafficchannels. In a fixed network the text is transmitted using ITU-T V.18signalling. In cellular networks text cannot be transmitted reliably usingITU-T V.18 signalling, because cellular systems are optimised for speech(speech codecs) and radio interfaces may cause relatively high error rates.Instead, TTY signalling in cellular systems is transmitted reliably usingcellular text telephone modem (CTM) signalling specified by the 3GPP.

Mobile TTYterminal

FixedTTY

terminal

w r

Hello Mary!

Hello Brian! How... Hello Mary!

Hello Brian! How are...

TELEPHONENETWORK

a



MGW features

Reliability is achieved by an improved modulation technique, includingerror protection, interleaving and synchronisation. MGW has interfaces toboth fixed and cellular networks, and it is able to make conversionsbetween the two TTY signalling types. Towards interfaces where G.711 isnot used, MGW uses CTM signalling. Towards interfaces where G.711 isused, MGW uses traditional ITU-T V.18 signalling.

TTY is not supported towards IMS and SIP access with a VoIP codec(G.723, G.729 or iLBC), because CTM is specified only for 3GPP codecs.

Note

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



Figure 31. Text telephony signallings supported by MGW

Call-based global text telephony enables call-based control of thefunctionality. In MGW, TTY can be activated in three alternative ways:

. on a call-by-call basis under MSC Server's (MSS) control

. for every call without MSS’s control

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

Nokia MSC Server supports the call-based global text telephony.

TTY-CTM Adaptor

CTM 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



MGW features

6.18 Nokia MGW in Nokia UMA solution for GSM

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


MGW inUNC(UMA) *)

MGW forMSS

Interworking service forUMA access (A/A+conversion)

x x

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

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

The A/A+ conversion functionality is co-located in MGW. This solutiondoes not require any external control interface from, for example, MSCServer (H.248). Nokia MGW user plane resources are controlled by the A+/A conversion functionality via an internal control interface. Whenconfiguring the TDM interfaces, the user plane PCMs have to be of typeCCS unlike for VMGW.

Nokia MGW handles transcoding between FR AMR and G.711. Inaddition, Nokia MGW acts as a signalling gateway between the INC (IPnetwork controller) and MSC. Text Telephony (TTY) is supported with UMAin MGW. TTY is delivered as AMR-coded CTM (cellular text telephonemodem).

The MGW for Nokia UMA solution for GSM is distributed into the siteswhere MSCs are located. It is also possible to use Nokia MGWsimultaneously for UMA traffic in Nokia UMA solution for GSM and asMGW for MSS.



Signalling network configuration

To be able to have transparency between UMA network controllers (UNC)and MSCs, MGW must have additional signalling point codes which arededicated to the UNC-MSC connection. In this case a dedicated MGWsignalling point is configured to MSC to point a UNC (and vice versa).

When dedicated signalling point codes are used, it means that eventhough the A-interface terminates to MGW, the MGW functionality istransparent to MSC, and MSC 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 pointcodes are configured using the Network Element signalling ConnectionHandling (W8) MML commands. See also Overview of configuring UMAsolution for GSM in MGW.

6.19 Ater interface in MGW

Table 26. Ater interface in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

Ater interface x


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

In the WCDMA architecture, the transcoding functionality is specified to bepart of the core network. In the Nokia WCDMA solution, transcoding islocated in MGW.



MGW features

As MGW includes the transcoders for WCDMA, the same investment canbe used also for GSM, as MGW supports the GSM transcodingfunctionality and the MSC Server System is applicable for both WCDMAand GSM. Therefore, this solution is offered as an alternative to the currentstandalone 2G transcoder product for Nokia system customers.

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

. TRAU-framing, synchronisation, handovers, time alignment for dataand speech

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

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

Ater in MGW supports the following Voice and Data Services:

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

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

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

. Special functions, for example Text Telephony (TTY)

The Ater interface is provided via E1/T1/JT1 or STM-1/OC-3. MGWsupports circuit pool types which are common with both BSC and MSCServer (MSS).

GSM transcoder resources in MGW are grouped into a single DSP poolused for all MGW Ater connections, and all codecs and DSP services areprovided from this same pool. With this principle, it is possible to use theGSM transcoding service without affecting the call processing capacity ofMGW for other services. The allocation of transcoding resources toNarrowband Ater/A Service Pool and ‘non-Ater’ pool is done viamanagement commands.



6.20 Multiple isolated IP networks

Table 27. Multiple isolated IP networks in different MGW networkenvironments


MGW inUNC(UMA) *)

MGW forMSS

Multiple isolated IPnetworks

x x


The multiple isolated IP networks functionality makes it possible to dividethe user plane traffic to different logical IP-based routes with specificconfiguration, such as QoS and used speech enhancements. Terminationsto different IP-based routes are allocated according to MSS control viaH.248. Separating different traffic types increases both the security andmanageability of the network. When integrating corporate networks toMGW, the networks can be separated by mapping the MGW interfaces/subnets to different VPN tunnels.

For configuration instructions, see chapter Modifying IP-based routes inMGW in Configuration Data Management in MGW.

6.21 IP connection admission control (IP CAC)

TDM networks provide fixed capacity (TDM channels) and constantspeech quality, but IP network can be overloaded, thus possiblydecreasing the speech quality. The IP CAC functionality enables to limitthe IP traffic load from MGW to external IP network. IP CAC is afunctionality for operators who wish to avoid IP network overloading andensure stable VoIP quality. The statistical information of realised IP trafficand possible traffic limitation by IP CAC provides useful information for theMSC Server System and IP network planning, dimensioning andmaintenance.

The IP CAC functionality includes:



MGW features

. configurable maximum limit for the number of simultaneous IPterminations

. a configurable warning limit

. warning limit and maximum capacity alarms

. statistics of IP traffic and possible traffic limitation

In case of reaching the maximum IP CAC limit, MGW rejects new IPtermination requests when MSC Server (MSS) can reject the call or utilisethe re-routing functionality via another user plane media (ATM or TDM), oranother MGW element.

For instructions on modifying the IP CAC, see Configuring IP CAC inIntegration Extensions for Multimedia Gateway.

6.22 MGW Connection and Port capacity

Table 28. MGW Connection and Port capacity licensing functionality indifferent MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

MGW Connection andPort capacity licensing

x Licence-basedfunctionality


SW licence -based MGW Connection and Port capacity means apossibility to purchase MGW call throughput (connection) and interface(port) capacity according to operator needs independently of the HWcapacity. This enables to minimise the HW delivery and implementationcosts, because the HW capacity can be purchased in bigger steps, andcall throughput and interface capacity by required size of the SW licence.All interfaces do not have a SW licence. A SW licence key is required for



MGW connection capacity, Ater interface, Iu-CS (3G) interface, IPbackbone (Nb) interface, and IP access (Mb) interface. A basic capacityfor a hundred calls is provided without SW licence with MGW connectioncapacity. The interface capacity always needs a SW licence key.

With the Licence and Feature Handling MML (W7), it is possible to install,activate and deactivate capacity licences, and to interrogate the actuallyused MGW connection capacity leveI. A configurable warning limit andalarm indication are supported for MGW connection capacity.

The actual capacity interrogation and warning limit configuration for portcapacity are supported in a later MGW release when the capacity-basedport control is taken into use by the CD update.

6.23 Security functionalities in MGW

### Generic and optional security functionalities have been combined inthis chapter.

Table 29. Security functionalities in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

Security functionalities x


Login delays to all session types

The login delay functionality protects the user interface from what is calleddictionary attack. In the dictionary attack, automata are used forgenerating either user ID and password trials or, when the attacker alreadyknows a user ID, only the password trials.

This functionality implements an increasing delay between theunsuccessful user authentication attempts, thus rendering dictionaryattacks unfeasible.



MGW features

So far, only MMI interface sessions have been protected, but thisfunctionality has been enhanced to protect interfaces of other sessiontypes also. In other words, also FTP, Service Terminal, and HTTP areprotected against dictionary attacks. Similar functionality has earlier beenimplemented also in the MML interface.

NEMU security improvements

The major NEMU security improvement is to separate the NEMU Systemaccount (NEMU software is run on the System account) from theAdministrator and other NEMU user accounts. The unnecessary defaultuser accounts and groups have been removed from the system.

Basic security hardening has been performed for OEM software, that is,Windows Server, SQL Server and NetOp Remote Control.

The improvements also include, for example:

. configuration rules for the simple network management protocol(SNMP) community strings

. Internet Explorer/Internet Information Services related hardening

. indication of security log failures with an alarm.

The firewall for NEMU software has a local software firewall for NEMUservers. It can be used for restricting the incoming traffic, and formonitoring unauthorised connection requests to restricted TCP/IP ports.

Integrated IPSec

The control plane (signalling) and the O&M traffic can be protected usingthe IPSec integrated in the network element. Support for public keyinfrastructure (PKI) is also included.

The integrated IPSec secures sensitive O&M traffic, such as user IDs andpasswords. This way, it ensures the confidentiality of signalling, that is,control plane traffic.

The supported IPSec functionalities in both IPv4 and IPv6 are:

. internet key exchange (IKE) v1

. X.509 certificates for authentication

. pre-shared keys for authentication

. IP encapsulating security payload (ESP)



. IP authentication header (AH)

. transport mode

. tunnel mode

In addition, advanced encryption standard (AES) and certificatemanagement protocol (CMP) support for PKI management are supported.

Password policy

The password policy feature increases the security of the networkelements. When the password policy functionality is in use, you can definecertain rules that prevent the O&M personnel from using too simplepasswords, or from using the same passwords consecutively whenlogging into MMI sessions. Simple passwords are a security risk becausethey can be easily found out and misused.

You can configure up to 20 password policies attached to user profiles,including legitimacy criterias for passwords by specifying:

. the minimum password length (6-15)

. the minimum number of alphabetic characters in the password (1-15)

. the minimum number of numeric digits in the password (0-15)

. the minimum number of special characters in the password (0-15)

. the maximum number of repeated characters (0-15)

. the maximum number of consecutive ascending characters inalphabetic order (0-16)

. the maximum number of consecutive ascending characters innumeric order (0-15)

. whether the user ID or its backward written from is allowed as asubstring in the password or not

and checking password history when:

. a new user ID is created

. the administrator changes the user's password

. the user changes his own password

. when the service terminal password is changed



MGW features

Password legitimacy and history checking can be configuredindependently from each other.

User account policy

The user account policy feature implements the following functionalities:

. inactive user accounts are disabled

. disabled user accounts can be listed and enabled

. last login time is displayed to user in login phase and with MMLcommand

. local users who have open sessions can be listed

. profiles can be defined to be administrative profiles

. login of user attached to administrative profile will raise an alarm

This feature affects only local users, that is, users whose user account isstored in current network element.

If the user account is not used at all for a period of time, it will be locked.After this, the account cannot be used for login. The length of the inactivityperiod can be defined by the operator.

At the beginning of the MML session, the date and time of the user’s lastsuccessful access, and the number of unsuccessful attempts are printedout. The user can also print out this information by an MML command.

This feature also provides a possibility to list all users who are currentlylogged into the network element.

A local O&M user profile can be defined as administrator profile. Whenuser attached to administrator profile logs in to the network element, analarm is raised. This alarm shows the user’s name and login time.



7 NEMU features

7.1 NEMU in MGW

Table 30. NEMU in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

NEMU x x


NEMU (Network Element Management Unit) in MGW is composed of fourplug-in units: Computer unit MCPC2A / MCP18-B, Ethernet switch unitESA24 and duplicated hard disk units located in separate subracks. TheNEMU solution for MGW is an integrated NEMU (MGW NEMU), located inthe equipment cabinet similarly as the other MGW units. Note that OMUand NEMU plug-in units are connected 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)

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



NEMU features

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

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

In addition to providing an interface towards Nokia NetAct, NEMUprovides, among others, the following functions related to external O&Minterfaces:

. post-processing of fault management data

. post-processing of performance data

. post-processing of trace data

Communication between MGW NEMU, MGW, and other networkelements is carried out via Ethernet. NEMU uses the Windows Server2003 operating system.

For more information, see MGW Operability.

7.2 Tools for handling MGW NEMU

Table 31. Tools for handling MGW NEMU in different MGW networkenvironments


MGW inUNC(UMA) *)

MGW forMSS

Tools for handling MGWNEMU

x x




7.2.1 Windows Server 2003 for NEMU

The Windows Server 2003 for NEMU functionality provides a secureoperating environment for the Network Element Management Unit(NEMU). Support from the original equipment manufacturers (OEM) isensured also in the future by using the latest OEM software components.The modified areas include installation for the new operating environment,compliancy with latest hardware versions, and customer documentation.

7.2.2 NEMU control panel

The NEMU control panel functionality provides a combined set of toolsassisting in commissioning, administration, and troubleshooting for NEMU.The previous user interface for Platform Manager has also been replacedwith an improved application.

With the NEMU control panel, it is possible to reduce commissioning andtroubleshooting times and therefore lower operator OPEX.

The implemented functionalities include the troubleshooting manager andthe platform manager.

7.2.3 NEMU configuration wizard

The NEMU configuration wizard functionality provides a new tool for themanagement of NEMU configuration. The configuration wizard can beused for giving the NEMU configuration either in the commissioning (newdelivery) phase or after the NEMU set-up has been run. The main dialogueof the configuration wizard can be used for checking and altering theconfiguration of the NEMU server and application.

7.2.4 Resilience improvements for NEMU

The resilience improvements for NEMU include, for example, the following:

. instructions for running an integrity check in the NEMU databases

. NEMU disk cleaning tool

. improved supervision for NEMU auditing and logging system

. security logs have been separated from application and error logs.



NEMU features

7.3 Fault management in MGW via NEMU

Table 32. Fault management via NEMU in different MGW networkenvironments


MGW inUNC(UMA) *)

MGW forMSS

Fault management inMGW via NEMU

x x


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,viewing alarm history, modifying alarm settings and controlling externalalarms and alarm outputs). The co-operation between different operatingfunctions can be arranged more efficiently with the GUI applications thanby using the traditional MMLs. The MGW EM user is able to changequickly from the configuration view to the alarm view. This reduces the timespent on finding and correcting the fault situation 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 inFault Management 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 thelatest diagnostic reports from the MGW. Alternatively, the fault locationingprocedure in the MGW can be controlled with the MGW Element Manager(EM) via the Diagnostics and State Handling GUIs.

The Diagnostics GUI is used for executing hardware diagnostics tests forall units and subunits in MGW. Tests can be started at once, or as timedoperations that are executed later according to a specified time. TheDiagnostics GUI makes it possible to perform history searches onindividual test(s), or for reports that are made on executed tests. If theautomatic state handling is turned on, the Diagnostics GUI tries to changethe state of selected unit to test executing state (TE-EX), if it is not alreadyin that state. This feature enables easy-to-use graphical diagnosticshandling, thus reducing the effort needed to manage diagnostics. Theresults of the procedure are automatically transferred to the EM as events,without manually polling the history file. The Diagnostics GUI is launchedvia the Application Launcher.

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

. 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.

7.4 Performance management functionalities in NEMU



NEMU features

Table 33. Performance management functionalities in NEMU in different MGWnetwork environments


MGW inUNC(UMA) *)

MGW forMSS

Performance managementfunctionalities in NEMU

x x


Performance management (PM) post-processing is a network elementmanagement unit (NEMU) functionality which is used for transferringperformance measurement result files from MGW to NEMU database. Theoperator can use an application called NE measurement explorer (GUI) toview and control all the measurements and counters transferred to theNEMU database in textual form.

NE measurement explorer

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

Explorer view:

The Explorer view of the NE measurement explorer is used for viewingmeasurement data stored to the NEMU database. The view contains thefollowing parts:

. 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 measurementtype)

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



In NE measurement explorer, there are two ways to get the counter valuesof a particular measurement. When the measurement type is selected, theuser can search all measurement objects of the selected measurementtype and then search all the save times of the selected measurementobject. Alternatively, the user can select the measurement type first, thensearch for all the save times of the measurement and finally search for allthe measurement objects of the selected save time. In both cases, theuser selects the measurement type, target object and the save time. Whenall of these parameters are known, the user is able to obtain the counterand 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 themeasurements) that can be used alongside with the MeasurementHandling (T2) MML interface.

Browser starting dialogue:

Browser starting dialogue is used for opening the default web browser to awww-page in the NEMU web server containing the SS7 and PDHmeasurement reports in textual form. SS7 and PDH measurements aresent to NetAct, and they can be handled with NetAct tools in the same wayas other measurements.

NE threshold management

The element manager GUI can be used for setting, removing andmodifying threshold monitoring parameters. An operator can usepredefined key performance indicators (KPI) or define customized KPIformulas. KPIs include either an individual counter or a combination ofseveral counters, which are collected in the network.

Note

In MGW NEMU, it is possible to create KPIs. However, if you wish touse predefined KPIs, NetAct provides an optional MGW reporting suitethat consists of predefined MGW reports and KPIs.

See Threshold-based notifications for more information on thresholds, andKey performance indicators for KPI information.



NEMU features

7.5 Subscriber trace post-processing in MGW

Table 34. Subscriber trace post-processing in different MGW networkenvironments


MGW inUNC(UMA) *)

MGW forMSS

Subscriber trace post-processing

x


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

The trace records generated in MGW are sent to Nokia NetAct throughNEMU. MGW gathers trace data during trace events and generates atrace report after a trace event for a specific subscriber has finished. A fullreport is transferred to NEMU. The trace reports can be stored in NEMUand they can be viewed with an ordinary text formatting tool. NEMU alsosends the trace reports to Nokia NetAct by using the Nokia proprietaryNWI3 interface.

Functionality

The generated subscriber-specific trace reports are sent to NEMU viaexternal message transfer (EMT). NEMU receives the subscriber-specifictrace reports and sends them to Nokia NetAct by using NWI3 notification.After this, Nokia NetAct sends a DATA RECEIVED OK acknowledgementand NEMU removes the reports from its trace buffer. If NEMU does notreceive the DATA RECEIVED OK acknowledgement from Nokia NetAct intime (that is, NEMU’s timer expires), the subscriber-specific trace reportsare sent again. Trace reports are also sent again if NEMU receives a DATA



RECEIVED NOK acknowledgement from Nokia NetAct. NEMU keepssending the subscriber-specific trace reports until its trace report sendingbuffer is full. After that, the trace reports are lost if trace report saving toNEMU disk is not enabled.

Note

If the Nokia proprietary NWI3 interface is broken between NEMU andNokia NetAct, all trace reports are lost after the trace report sendingbuffer in NEMU is full if trace report saving to NEMU disk is not enabled.

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

7.6 NetAct-related functionalities

Table 35. NetAct-related functionalities in different MGW networkenvironments


MGW inUNC(UMA) *)

MGW forMSS

NetAct relatedfunctionalities

x x


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



NEMU features

Centralised Event Logging (Remote User Event Log Management)

Centralised Event Logging, also known as Remote User Event LogManagement, enables centralised aggregation of user event logs (such asGUI command log) from network elements (NEs) into Nokia NetAct. Theoperator is able to trace changes in the network based on user or NEinformation. The upload is triggered from NetAct. NetAct is also able toproduce the data in the user event collection in XML format (XML coding isavailable for 3rd party applications). File Transfer Protocol (FTP) is used forlog file collection from the NEs. NetAct provides the tools for processingthe collected log files.

With Centralised Event Logging, the operator can collect user event datafrom all NEs. With NetAct applications, the operator can create reportsfrom the data collection, based on a user or an NE, for example. It enablesfast tracking of suspected illegal user actions and therefore enables fasttools to start corrective actions and prevent additional damage.

Figure 32. User event collection from network elements

Centralised User Management (Remote User InformationManagement)

NEs have different ways of handling user profiles, and therefore a singlecentralised profile for all NEs is not determinate. Centralised UserManagement, also referred to as Remote User Information Management(RUIM), shows which profiles the user uses in the NE. This requires thatboth the user and the hosts are identified for access to Nokia NetAct tofulfill the security requirements. This offers the operator the possibility tomanage the user accounts in a centralised manner. The minimummanagement requirements for user information are:

OSS

User eventcollection

NE NE

Log file transfer

NE



. creation of a new user

. password change

. deletion of a user

With Centralised User Management, the user can manage themaintenance personnel's access to the O&M network for each group orindividual separately, and define different access classes for different usergroups and NEs. All changes can be rapidly downloaded, either manuallyor automatically, and simultaneously to a number of elements. MMLsessions for each separate NE are no longer necessary.

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

Local users are defined locally in one network element. The user can onlylog in to a network element where a local account is defined. Local useraccounts must be defined separately in all network elements.

Automatic notification to NetAct of a changed HW configuration

Automatic HW Configuration Change Notification enables networkelements to report automatically to Nokia NetAct about changes in theirHW configuration. The HW configuration is either configured manually ordetected automatically by the system in MGW. The list of the HW itemsand related parameters is stored in the NE. When the NE detects changesin its HW inventory, an update message is sent to the NetAct to inform itabout the changed situation. The changed data in the NE’s HW inventoryis either included in the update message or the NetAct can automaticallystart a HW information upload procedure. According to the notification ordata upload, the NetAct stores the new information to the Network HWinventory.



NEMU features

Figure 33. Automatic HW Configuration Change Notification

The information in the network level HW inventory database isautomatically updated every time a change is detected in any NE HWinventory. No user-triggered upload procedure is needed. Automatic HWConfiguration Change Notification decreases the need for O&Mtransmission for HW information purposes since no massive network levelHW information upload operations are needed. The transmission load isdivided more evenly and there is no need to transfer information that isalready 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,the NetAct must be informed about the changes in MGW SWconfiguration. When a new software is activated in the MGW, notificationsare sent to the NetAct via an NWI3 interface. With this functionality, theNetAct SW inventory always includes the latest SW information of MGW.

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

MGW topology upload to NetAct

The MGW topology upload functionality provides the following benefits:

Automatic HWconfiguration detection

Manual HWconfiguration

OSS

HWinventory

NE



. automatic inclusion of new MGW objects and unit objects in NetActtopology

. ability to distinguish between alarming/faulty MGW HW units.

The possibility to upload the MGW topology to NetAct is important as thevolume of MGW units integrated with NetAct in operator environments isincreasing. Currently, all MGW topology objects must be created manuallyin NetAct. This is cumbersome for operators now and will only becomemore so in the future as the number of MGWs will increase. The MGWhardware units are not visible in the NetAct topology and if they were,maintaining them manually would be an overwhelming task. Due to this,fault management alarms are all presented on MGW level.

Remote backup for MGW in NetAct

The remote backup for MGW is handled so that the NetAct requests theOperation and Maintenance Unit to make a ZIP file of the current softwarebuild. The NetAct copies the ZIP file using FTP.

For information on the NetAct - MGW interface, see MGW OperabilitySolution Description.



NEMU features

8 Files in MGW

Table 36. Files in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

Files x x


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

File Description

EIKFIL - External IP CACconfiguration file

This file includes information of the external IPCAC related parameters. EIKFIL is handledwith the External IP CAC Handling (W9) MMLcommands.

H24LOG - H.248 EventLog workfile

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

H48FIL - File to collectstatistical data in MGW

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



Files in MGW

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

File Description

ID1FIL - MultimediaGateway -SpecificParameter File

The file contains Multimedia Gateway -specificparameters (such as the E.164 address of thenetwork element) and the information iscontrolled with the Multimedia Gateway -specific Parameter Handling (WE) MMLcommands.

IP2FIL - Logical IP BasedRoute Identifier Set File

This is a file to store MGW’s IP networkreference identifier, IP-based route identifierinformation, and DSP pool id. The IP2FIL ishandled with DSP Parameter Handling (W4)MML commands.

IP4FIL - Default IP BasedRoute Identifier Set File

This is a file to store MGW’s IP interface typespecific IP-based route information and DSPpool id, as well as default IP-based routevalues. The IP4FIL is handled with DSPParameter Handling (W4) MML commands.

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

LEKFIL - User PlaneParameters File

User plane parameters are stored in this file.LEKFIL is handled with the DSP parameterhandling (W4) MML commands.

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 distributedto VANU. 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.




File Description

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). Echo Cancellation measurement (MID: 297). Text Telephone measurement (MID: 351)

SD4FIL - File to Collect IP-related Statistical CounterData in MGW

The file gathers IP-related statistical counterdata for the IP CAC measurement (MID: 300)in MGW for MSS:

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.

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.

TR2FIL - Trace Report Filein Multimedia Gateway

The file contains information on MGW forMSS trace observation. The file includes traceheader fields, MGW for MSS additionalheader fields, termination common sub-headerfields and termination specific sub-reportfields. The TR2FIL is located in every ISUunit.

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,…) forthe variable parts of announcements. Thevalid numbers for VAD files are 1 to 3999.The information in this file is controlled withthe Media Gateway Announcement FileHandling (JA) MML.



Files in MGW


File Description

VAITXT - VoiceAnnouncement Text File

The file contains the announcements in textformat.

VAMANA - Speech SampleFiles Management File

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

VATALK - VoiceAnnouncements SpeechSample File

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

VAVALK - Internal VoiceAnnouncements SpeechSample File

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

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.



9 Databases in MGW

Table 38. Databases in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

Databases 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 ismanaged via the Virtual Media Gateway Handling (JV) MML.

. Context Database – CXDATA

This database contains the termination information for contexts.

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



Databases in MGW

10 PRFILE parameters in MGW

### FIFILE parameters have been removed

Table 39. PRFILE parameters in different MGW network environments


MGW inUNC(UMA) *)

MGW forMSS

PRFILE parameters x x


The most essential PRFILE parameters used in MGW are listed in thefollowing table.

Table 40. PRFILE parameters in MGW

PRFILEparameter

Description Applicable in MGW

MGW inUNC(UMA)

MGW forMSS

FREE_CIC_NUMBERING(002:0115)

This parameter defines whetherthe circuit identification code(CIC) can be given as freenumbering.

x




Table 40. PRFILE parameters in MGW (cont.)

PRFILEparameter


MGW inUNC(UMA)

MGW forMSS

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_NBR_OF_VMGW_IN_UNIT (002:0727)

This parameter defines themaximum number of VirtualMedia Gateways per one ISUunit. The allowed values are 1D- 5D, and the default value is5D.

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

PCM_ENCODING_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




PRFILEparameter


MGW inUNC(UMA)

MGW forMSS

DSCP_FOR_USER_PLANE(002:0817)

This parameter is used by theuser plane applications to setthe Differentiated Servicescodepoint carried in the Type ofService or Traffic Class field inIPv4 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 the diffServcodepoints and respectivevalues, see RFC2474,RFC2597, and RFC2598.

x x

TIMER_ERQ(002:0840)

This parameter sets value forAAL2 establish timer in AAL2signalling services. The allowedvalues are 5D - 30D, and thedefault value is 30D.

x

TIMER_REL(002:0841)

This parameter sets value forrelease timer in AAL2 signallingservices. The allowed valuesare 2D - 60D, and the defaultvalue is 60D.

x

TIMER_MOD(002:0842)

This parameter sets the valuefor the modification timer inAAL2 signalling services.

x





PRFILEparameter


MGW inUNC(UMA)

MGW forMSS

H248_MAX_WAIT_DELAY(002:1008)

MGW for MSS has anavalanche preventionmechanism, and this parameterdefines a timer value for themechanism which is usedduring restart. MGW for MSSinitialises a random restarttimer, where the time isdistributed evenly between 0and the maximum waiting delaytime. When the time is out,MGW for MSS sends aServiceChange message forregistration. The default valueis 10 seconds.

x

DEF_NORMAL_MG_EXEC_T(002:1014)

The parameter defines the timeinterval within which MGW forMSS processes a request andsends a response. The defaultvalue is one second.

x

DEF_NORMAL_MGC_EXEC_T (002:1015)

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

x

DEF_NETWORK_DELAY_T(002:1016)

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

x

MGC_ORIG_PEND_LIMIT(002:1017)

This parameter defines thenumber of transaction pendingsthat can be received from MSCServer. Once this limit isexceeded, MSC Server shouldissue a transaction reply witherror 506 (Number oftransaction pendingsexceeded), otherwise MGWcan assume that thetransaction is erroneous. Thedefault value is 4 attempts.

x




PRFILEparameter


MGW inUNC(UMA)

MGW forMSS

MG_ORIG_PEND_LIMIT(002:1018)

This parameter defines thenumber of transaction pendingsthat can be received fromMGW. Once this limit isexceeded, MGW should issuea transaction reply with error506 (Number of transactionpendings exceeded), otherwiseMSC Server can assume thatthe transaction is erroneous.The default value is 4 attempts.

x

MGW_LIS_CON_CAPA_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

PASS_THR_CH_MB(002:1202)

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

x

PASS_THR_CH_NB_PRIME(002:1203)

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

x

AEC_WITH_TTY (002:1238)

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

x

DSCP_FOR_SEMIPER_TDM_IP (002:1287)

User plane applications canuse this parameter to set theDifferentiated Servicescodepoint carried in the Type ofService or Traffic Class field inIPv4 and IPv6 headers,respectively. IP forwardingfunctions use this value for thetreatment of high priority traffic.

x





PRFILEparameter


MGW inUNC(UMA)

MGW forMSS

PHB_FOR_SEMIPER_TDM_IP (002:1288)

RFC3246, RFC2597, RFC2475 x

PORTS_FOR_SEMIPER(002:1289)

This parameter defines thenumber of UDP ports reservedfor semipermanentconnections.

x

AAL2_ANALYSIS_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 or anotherMGW). The allowed values are1D - 1023D, and the default is1D.

x

IWF_RFR_TIME_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 MSS toan external IWF equipment.The allowed values are 01H -0258H, and the default value is0AH.

x

ATM_MODULE_OLC_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

AAL2_OLC_ENABLED(012:0081)

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

x




PRFILEparameter


MGW inUNC(UMA)

MGW forMSS

H248_OLC_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_TRACE_MAX (012:0109)

This parameter controls howmany trace events can beactivated in MGW for MSS.With this parameter theoperator can limit the maximumnumber of active trace eventsto reduce the capacity need.The parameter has a computerunit (ISU) -based limitation.Thus the complete limitation oftrace events in MGW ismultiplied with the number ofcomputer units (ISU). Theallowed values are 0D - 20D,and the default value is 20D.

x

USED_TONE_SET (043:0009)

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

x

DSCP_FOR_SIGNALLING(053:0009)

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

Note

For definitions of the diffServcodepoints and respectivevalues, see RFC2474,RFC2597, and RFC2598.

x




11 Compliance of MGW

A certain MGW product release is mainly based on a specified 3GPPspecification release (for example, U3C is a release mainly based on3GPP Rel-5 level specifications, but IMS-related issues in U3C are basedon 3GPP Rel-6 level specifications). The word "mainly" refers here to thefact that some features are not supported at all, some partially, and someare implemented in a later product release. Some features are evenimplemented earlier than a 3GPP specification would impose. In addition,Nokia has implemented some proprietary extension features to meetcustomer requirements in a timely manner.

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



Compliance of MGW

Related Topics


Speech enhancements 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

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

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



Related Topics

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

IMEI/IMSI trace observation in MGW for MSS

Speech enhancements in MGW


NEMU in MGW

Descriptions

Subscriber Trace Post-processing in MGW

Performance management functionalities in NEMU

Tools for handling MGW NEMU

Descriptions

Subscriber Trace Post-processing

Performance Management functionalities in NEMU



Performance management functionalities in NEMU

Descriptions

NEMU in MGW

Subscriber trace post-processing in MGW

Descriptions

NEMU in MGW



Related Topics

Functional Description for MGW

Documents

Transcript of Functional Description for MGW