MSS Intro

got this nokia mss intro tutorial,but it has too much images of network,transmission and call control process which i cant upload.

Control and User Plane

The traditional Mobile Switching Center (MSC) is the most valuable equipment in the operator’s mobile network. With a footprint of dozens of square meters, it is also the largest. The Nokia MSC Server System comprises selected parts of the Nokia DX200 and IPA2800 switching platforms, providing a flexible, cost- and floor space-efficient solution for 2G and 3G operators.
This page describes the key interfaces used by the 2G MSC and Release ‘99 3G MSC. The traditional MSC terminates Time Division Multiplexed (TDM) physical connections from a GSM Base Station Subsystem (BSS) and other TDM based networks (such as PSTN).
The MSC also performs all control plane functions, such as call related/unrelated analyses, barring, routing, charging, etc.
The MSC functions for the WCDMA Radio Access Network (RAN) and the BSS are almost identical, except that the transmission in RAN is based on ATM and in BSS on TDM.
Therefore, Nokia 3G MSC incorporates two different platforms: firstly, the updated GSM switch for TDM switching and call control, and secondly, a new product called the Nokia Multimedia Gateway (MGW) for terminating ATM connections from RAN.
In other words, the Nokia 3G MSC enables a move from a GSM circuit core to a 3G-circuit core with minimal changes. This is achieved by implementing the majority of 3G-specific technology in the MGW-part and interconnecting the 2G MSC and the MGW with Nokia’s proprietary A’ interface - that is as close to the traditional GSM A-interface as technically possible.


The Third Generation Partnership Project (3GPP) standardized the split between control plane and user plane in the 3GPP Release 4 specification. The control plane is handled in the MSC and the user plane in the MGW. The Interface between both the MSC Server and the MGW is called the Mc interface and is specified in the 3GPP specification 29.232. The Mc interface is based on the ITU H.248 protocol and is used for controlling media gateways.
The concept of media gateways and the media gateway controllers is, however, much older. In the late 1990s, IETF designed a protocol to be used as a control protocol for H.323 and SIP media gateways. The RFC was 2075, and the protocol was called media gateway control protocol (MGCP).
IETF’s MEGACO work group continued the work in collaboration with ITU and created an enhanced Gateway Control protocol which is published as RFC 3525 by IETF and as H.248 by ITU.
3GPP Mc interface specification further specified how H.248 is to be transported and used in GSM and WCDMA environments. Nokia implements this interface with certain nuances of its own, thus improving the functionality between the Nokia MSC Server and the Nokia Multimedia Gateway.
In the traditional MSC architectures the switching and call control capacity was paired, locating in the same site. However, in the MSC Server system the bond between the MSC Server and the Multimedia Gateway is loose, allowing one MSC Server to control a number of media gateways remotely.
Furthermore, a single physical MGW can be divided into virtual MGWs. Each virtual MGW can be controlled by a different MSC server.


The MSC Server System dedicates the MSC Server for control plane functions and the Multimedia Gateway for transmission. Contrary to the MSC solution, the MSC Server solution also uses dedicated transmission equipment for terminating TDM trunks from the GSM BSS and the PSTN in the MGW.
This solution enables operators to use the common packet-switched backbone network based on ATM or IP between media gateways. This interface is called Nb.
In practice, this offers possibilities for considerable savings in transmission costs, both in 2G and 3G networks.

Let us next consider the evolution of GSM and 3G network architectures and briefly discuss the various interfaces and protocols needed in the modern Circuit Core.
The access networks carry the control plane messages encapsulated in the Base Station Subsystem Application Part (BSSAP) and Radio Access Network Application Part (RANAP) signalling messages.
Both of these well-known SS7 protocols are transparently carried through the Multimedia Gateway to the MSC Server. But because the media gateways are connected with the MSC Servers via the operators’ IP backbone, the SS7 signaling messages are encapsulated into IP packets and carried over local or remote connections to the correct MSC Server.
In order to “emulate” the MTP signalling links and routes when IP transport is used, IETF’s SS7 signalling transport protocol (Sigtran) suite has been developed. In brief, the mechanism used relies mainly on the use of two protocols: SCTP and M3UA, which provides for example the required transport when IP is used between the MGW and MSC Servers.
A similar conversion is needed for the ISDN User Part (ISUP) when it is carried over IP interfaces (again between MGW and MSC Server).
In Bearer independent core networks based on ATM or IP, ISUP cannot be used as call control protocol. ITU developed for this purpose the Bearer Independent Call Control protocol (BICC), which is based on ISUP and can be used between two MSC servers during the call setup for the bearer-independent circuit core.
As an alternative to BICC, SIP can be used as a call setup protocol for IP bearers and ISUP can be used for TDM bearers.


Let us next concentrate on the basics of GSM and 3G voice coders (vocoders).
Currently supported source coding methods in the MGW are:
ITU G.711 which defines the ”mother of all voice coding methods” as Pulse Code Modulation (PCM) of 8000 speech samples per second, resulting in a 64 kbits/s coded bit stream.
GSM 06.10 which is the so-called Full Rate (FR) vocoder using regular pulse excitation i.e. the long term prediction linear predictive coder (RPE-LTP) as a coding scheme. It encodes a 20 ms speech sample to a 260 bit sample, resulting in a 13 kbits/s coded bit stream.
GSM 06.60 defines the Enhanced Full Rate vocoder which is able to compress the 20 ms samples into a 244 bit sample using the algebraic code-excited linear prediction (ACELP) coding scheme and resulting in a 12,2 kbits/s coded bit stream.
GSM 06.90 or Adaptive Multirate (AMR) vocoder is actually a multi-rate extension to EFR providing the encoding of 20 ms speech samples to 95, 103, 118, 134, 148, 159, 204 and 244 bit samples and resulting in a 4.75 -12.2 kbits/s coded bit streams.

The speech encoding is used to enhance the efficiency of the air interface transmission. In the GSM system the transcoding to PCM is made in the separate transcoder (TC) unit before the transmission to the core network.
The transmission efficiency between the access network and the core can be enhanced if the transcoders are located in the core network. This is the default arrangement in the UMTS and can be implemented in GSM using the Ater interface.
However, the operator using the Nokia MSC Server system may take advantage of the encoding and compression provided in both UMTS and GSM - with or without Ater - by using the various transport efficiency improvement features that are available.
In the transmission module we will give an introduction to Tandem Free Operation, Transcoder Free operation and other enhancements that are introduced in order to improve the transmission efficiency over the IP and ATM transport bearers.

If the MSC Servers take care of all control plane activities, but the Multimedia Gateways are responsible for the actual switching and transcoding, then how do switching elements know where to route the user plane traffic and what coding schemes shall be used?
Naturally, the MSC Server needs to inform the MGWs about the user plane requirements. This information is given to the Multimedia Gateways using the media gateway control protocol H.248. This protocol enables the MSC Server to instruct the MGW to establish the bearer route to the correct destination and – if required – to perform all other user plane tasks (such as creating tones and announcements).
The 3GPP defines the interface between media gateway controllers and media gateways in the specification 29.232. The name of this interface is Mc.
Note that H.248 can be used to control IP, ATM and TDM resources terminated by the media gateways!

The MSC Server System is used in an IMS environment for interconnecting IMS and PSTN/PLMN networks. The role of the MSC Server is to take care of the traditional circuit-switched call functionalities, convert SIP signalling into ISUP messages and to control the Multimedia Gateway which provides the required user plane bearers.

The MSS implements the 3GPP defined Media Gateway Control Function (MGCF) controlling the Multimedia Gateway through the Mn interface. The Mn interface is specified in 3GPP TS 29.332.
The Mn interface differs substantially from the Mc interface, although both interfaces use the H.248 protocol. Since the Mc interface specifies H.248 for BICC networks, it is not applicable for the Mn interface for the terminations on the IMS side. The Mn interface must support the transport of AMR without the use of framing protocol.

The Multimedia Gateway provides the Mb interface that carries voice encapsulated in RTP frames without the user plane framing protocol.
The IMS consists of the Connection Processing Server (CPS) and the IP Multimedia Register (IMR). The CPS implements the 3GPP-defined Call State Control Functions (CSCF), which in turn implements IETF's SIP Proxy, SIP Server and SIP Registrar in the mobile environment. The IMR is basically an ‘HLR for SIP clients’ implementing IETF’s Location Registar. Naturally, the standard HLR is required for GPRS session control and CS call control.
As a pre-requisite for a SIP-based session the SIP clients are registered in CPS, which saves the current location of the subscriber to IMR (e.g. an IP address). The CPS is consequently aware of the location of every registered user and only registered users can be reached by the other party.

The Nokia VoIP Server (NVS) is a solution within the Nokia MSS System and provides a vast scale of existing GSM supplementary services to SIP users.
The NVS provides a SIP-based IMS Service Control (ISC) interface to the Nokia CPS.
The ISC interface also allows the operator to re-use existing GSM IN services for SIP voice calls.
For instance, the operator may use existing CAMEL prepaid services for subscribers who are registered in IMS, or provide number portability or emergency services using the same facilities that are today used for GSM/3G.


The Nokia VoIP Server (NVS) provides telephony services to VoIP clients, without recourse to the IMS.
The NVS implements a SIP server, proxy and registrar functionalities in the MSC Server; however, NVS is not an “IP Multimedia Subsystem” in a single plug-in unit! On the contrary, the NVS is designed to provide mobile circuit-switched services (such as voice and text messages) to external SIP users such as ADSL subscribers using IETF SIP terminals or, for example, IP centrex.
The SIP users registries to the Nokia Voice Server integrated into the MSC Server, and the mapping table between MSISDNs/ IMSIs/ SIP addresses and their current locations are stored in a separate LDAP directory. The ”LDAP directory” essentially does the same as HSS (IMR+HLR) does in the IMS, i.e. provides mapping between SIP addresses, MSISDN, IMSI and the current IP Address. In IETF terminology, the LDAP Directory fulfills the requirements set for the Location Server.
The use of NVS also provides an extensive set of GSM supplementary services to VoIP users.

The Nokia Unlicensed Mobile Access Network (UMAN) can be used to provide secure and seamless connectivity to the cellular networks for WLAN and Bluetooth users.
The role of the Nokia MSC Server and the Multimedia Gateway is to connect UMAN with the CS core and voice services.
In Nokia’s Unlicensed Mobile Access Network, the counterparts of MSS and Multimedia Gateway are IP Network Controller (INC) for control plane and Security Gateway (SeGW) for secure transport plane providing VPN through the unlicensed radio interface. Together, these two elements comprise the UMA Network Controller (UNC) functionality. This functionality is sometimes called the Generic Access Network Controller (GANC).

In addition, an AAA server and remote connection to HLR are required for SIM-based authentication, authorization and accounting.
Somewhat similarly to the IMS solution, UMA MS also needs to register in order to be reachable via UMAN. In contrast to IMS, UMA MS is identified using IMSI – and not a SIP address which is mapped with a used IP address and access point during the registration.
A fundamental difference is also that UNC performs normal Location Update to the core network after registration; therefore the access via UMAN is very similar to access via BSS.
The voice solution for UMA is heavily based on the standard GSM voice services. A request for an UMA call is carried over UMARR in a very similar format to BSS/RAN.
The connection between the access network and core network uses the SS7 signaling protocol BSSAP. BSSAP, however, is used in a slightly modified fashion and carried over M3UA in UMA.

Transmission
The MSC server system simultaneously supports both GSM and WCDMA access networks. A single MSC Server can simultaneously serve both access networks, and subscribers can dynamically share the resources, such as VLR capacity.
The MSC Server can be concentrated on a few sites at the most convenient location thus reducing the number of sites needed. The Multimedia Gateways support local switching and PSTN connectivity, and can be located at existing BSC and RNC sites close to traffic hotspots.

The MSC Server can be used for multiple PLMNs even if the PLMNs are located in different countries. This concept brings obvious cost efficiencies and provides the ultimate of centralised network architecture by placing the core site elements (such as MSC Servers and HLRs) in one country while access network sites (including MGWs) may reside in multiple countries or PLMNs.

The Nokia MSC M13 encompasses additional topological advantages. Firstly, the Multipoint Iu or A (or Flex-Iu or A) is a 3GPP release 5-specified feature allowing a single BSC or RNC to connect with multiple MSCs or MSC Servers. This has a number of benefits, such as improved redundancy (if one MSC is down another MSC can take its place), more flexible scalability due to the RAN routing and load balancing, a reduction of HLR signalling traffic and fewer MSC relocations because the terminal may roam within an operator-definable pool of RNCs without the need for changing the MSC or MSC Server, and the fact that Multipoint Iu enables RAN sharing.

The MSC Server System offers all GSM and 3G circuit-switched services but is not limited to circuit-switched transmission.
On the contrary, the MSC Server system uses IP transport exclusively between Multimedia Gateways and MSC Servers, between different MSC Servers and even as an option for transporting voice signals between Multimedia Gateways.
The Nokia MSS and MGW offer LAN interfaces. The WAN connectivity is implemented using the third party site switches.
The transmission in the circuit core can be handled using the same packet-switched backbone network as GPRS, or - if the switched line capacity exists - the standard circuit-switched transmission links (E1/T1/JT1).
However, the use of packet-switched transmission provides multiple advances - for instance, in terms of transmission efficiency and operational costs.

The MSC Server can be connected with a number of Multimedia Gateways using local or remote (backhauling) SCTP connections.
In practice, the Multimedia Gateways can be located on the unmanned BSC or RNC sites while the MSC Servers are typically located under continuous surveillance - as with the traditional MSC.
As a result, the transmission capacity can be scaled very efficiently by adding a new MGW of the traffic 'hot spots' - potentially, on the low rental cost remote sites.

If we look at the call setup process strictly from the call control's point of view, it can be said that the essentials have not changed with the MSC Server. The goal is still to establish, maintain and terminate voice calls.
However, a fundamental difference exists due to the use of a bearer-independent core. With the bearer-independent core, the call setup phase should result in the connection via the optimal transmission route -through the Multimedia Gateways that may reside in various geographically distributed locations - and with the best possible speech quality and transmission efficiency.
In other words, we need new measures to indicate which bearer and what characteristics are optimal for a particular call.
Secondly, the use of IP as local and remote transport technology causes certain changes in the signalling transport.

The MSC Server uses 'Sigtran' to carry SS7 signalling, i.e. RANAP, BSSAP, MAP and ISUP over IP.
In fact, Sigtran (signalling transport) is the name of the IETF's working group defining frameworks and protocols for signalling transport over IP. The scope of this working group is to design transport protocols and adaptation layers for the different signalling needs of mobile and fixed telephony.
Despite this minor terminological hazard, Sigtran will be used in this course as an umbrella concept to include protocols used to transport PLMN/PSTN signalling over IP networks.
The key building blocks of Nokia's current Sigtran solution are Stream Control Transmission Protocol (RFC 2960) and SS7 MTP3-User Adaptation Layer (M3UA) (RFC 3332).
The figure on this page illustrates the key contents of each layer in the original SS7 stack and in the 'Sigtran' stack.
In Nokia's current solution, the SS7 signalling transport over IP network is taken care of by IP and SCTP layers. The SCTP provides connection-oriented signalling streams for carrying SS7 signalling information. The M3UA adaptation layer provides SS7 routing information (similar to MTP3) and encapsulation of higher layer SS7 application parts into the SCTP frames.

Let us briefly compare the original Nokia SS7 interface with the Nokia Sigtran interface from the configuration point of view.
The figure here illustrates the logical connections that are created for the signalling links in the MTP2 and, alternatively, in the SCTP.
As the SS7 link set represents a group of links that connect two adjacent network elements, the association set is a group of SCTP associations created between two elements connected with 'Sigtran' - such as MSS and MGW.
The association defines the actual port and destination IP address(s) that are used for the transport of data to a signalling unit.
The redundancy for associations can be provided for the signalling units that have redundant ethernet ports by allocating primary and secondary destination IP addresses. This feature is called SCTP multihoming.
Let us next present an example of what happens when a signalling message arrives at the signalling gateway from the SS7 link. Note that the MGW acts as the signalling gateway.

Let us assume that a BSC sends a BSSAP message to the MGW that is destined to the MSS. The message is sent over the original SS7 link.
When the MGW receives the message, its M3UA routing function first determines the association set; this is based on the routing information in the message in a provisioned Routing Key. The routing information contains the destination point code (DPC) and the network indicator (NI).
Inside the association set an association is selected, based on the Signalling Link Set value, and the signalling message is forwarded to the signalling unit where the association exists.
The signalling unit finally forwards the BSSAP message to the signalling unit in the MSS.

The Bearer Independent Call Control (BICC) protocol is used between two MSC Servers - in principle, to carry ISUP and optional 'bearer control information'. To be accurate, BICC does not carry ISUP but 'modified application protocol' that supports modified ISUP call control messages such as Initial Address Message (IAM) or Answer Message (ANM). It also carries new messages such as Application Transport Mechanism (APM) allowing MSC Servers to interchange required bearer information regarding the call.
For example, APM may include the address of the virtual MGW (BNC-ID), a Global Title of the MGW (BIWF), codec info for achieving TrFO and even the IP bearer characteristics such as destination IP addresses and port numbers in the optional Session Description Protocol (SDP) part of the message (in a tunnelled bearer establishment case).
In the Nokia MSC Server solution the BICC messages are typically carried over M3UA and SCTP, but theoretically BICC can also be carried over UDP, TCP, ATM or TDM connections.

The BICC defines the following two alternatives for bearer establishment that are used for carrying IP bearer information piggybacked on the call control messages: Tunnelled Fast Forward Setup (for calls not involving codec negotiation) and Delayed Forward Setup (for calls involving codec negotiation)
The following bearer establishment alternatives are available for ATM bearers: Non-tunnelled per-call bearer setup in forward direction and Non-tunnelled per-call bearer setup in a backward direction.
In the ATM case, the actual bearer signalling takes place between MGWs, for example in the form of an AAL2 signalling.

As stated earlier, the MSC Server terminates the signalling connections and selects the resources to be used for the user plane. In order to select the MGW, the MSC Server needs certain information about the MGWs and their bearer characteristics.
In short, the MSC Server maintains the topology database including all the Multimedia Gateways it controls. In that database, the Multimedia Gateways are typically grouped based on their bearer characteristics. For instance, there might be a group for MGWs that terminate AAL2/ATM connections and another group for MGWs offering IP bearers. The MSC Server selects a group that fits the requirements of the call and dispatches the traffic to one of the MGWs in that group by establishing the user plane 'terminations' by means of H.248 mediagateway control operations.

The initial MGW selection takes place in both MSC Servers. One of the parties (depending on the backward/forward Setup mode) will be able to select the most optimal set of MGWs to be used for the User Plane connection. After the MGWs are selected, the bearer establishment takes place.
The MSC Server uses H.248/MEGACO over SCTP, or in some cases, over TCP to control the resources of the Multimedia Gateways. One physical MGW can be connected with multiple MSC Servers. In this case, each MSC Server controls its own 'Virtual MGW' using a separate H.248 connection.
As an example, the MSC Server sends an H.248 'add request' to create a termination in the MGW, 'context request' to connect two terminations inside the MGW, or a 'modify request' to send the 'ringing-tone' from an MGW to a terminal.

In the CS core site, the central elements are the MSC Server, MGWs and the multilayer Layer 2/Layer 3 site switches. The MSC Server plays a central role where its purpose is to process the control plane of the call. MGWs take care of user plane data, and Layer 2/Layer 3 switches enable an intra-site Ethernet LAN between elements. The connections are based on layer 2 switching and IP routing. To ensure reliability all links and site elements are normally duplicated.

The MSC Server includes a number of plug-in units for aggregating signalling and other control traffic for the Ethernet links. The generic name for the units is a switching unit (SWU). Each MSC Server cabinet has a redundant SWU pair where both units are connected to two different L2/L3 switches, or - when using a one-switch configuration - at least to different Ethernet line cards. The connections between SWUs and switches are normally 100Base-T Ethernet-based. A standalone MSC Server can have up to 12 100Base-T Ethernet connections, and an integrated MSS can include up to 16 100Base-T Ethernet ports. Site routers, within the limits of their performance, may also be used for routing user plane traffic if the user plane uses an IP-based backbone.

The links are virtual LAN links (VLAN) that are created when physical LAN links are split. On the MGW site there can be different VLAN's configured for O&M traffic, control traffic and user plane traffic. Different types of control plane traffic are marked in the SWU and separated in the MGW Ethernet switching unit, ESA24, but still using the same physical interface in the L2/L3 switch.

The matter of resiliency is important when planning the site connectivity. All functionalities are duplicated and they use either Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP) on the Ethernet interfaces, and Hot Standby Router Protocol and Virtual Router Redundancy Protocol between redundant site routers. Note that in this example the same router is used for both control and user plane traffic.

The requirement for recovering from link failure is 800 ms for signalling applications. When planning site connectivity, the aim for recovery will be therefore less than 800 ms for most failure cases.
In the example, the MGW and the standby router both notice that the active router is not responding due to the link failure. The MGW changes the traffic to a precalculated alternate path and the standby router begins to advertise itself as an active router.

The network in the site is dedicated or strictly operator-managed, so privacy reduces the number of security risks. Furthermore, additional ways of increasing security of the site connectivity are traffic separation into different VLANs, using access lists in the switches, and using IPSec within the operator's backbone for traffic to the public Internet.

Transmission efficiency in the GSM environment can be enhanced with the Tandem Free Operation (TFO). The TFO is a mechanism which can be used in-band to determine the speech codecs used on the transcoders in a call. If compatible codecs are used, the transcoders start embedding the encoded speech parameters in the least significant bits of a 64 kbit/s link. The Nokia MGW for MSS supports TFO for GSM FR and GSM EFR speech codecs, thus providing optimised inter-operability (e.g. in terms of speech quality and transport efficiency) with the legacy GSM networks.
Traditionally the transcoding from end-to-end demands two encoding/decoding pairs. Instead, pure TFO is a mechanism performed by the transcoders using in-band signalling.
The peer transcoders communicate with each other using bit-robbing signalling inside a 64 kbit/s channel. If MSS's are used, the codec negotiation may be made between them; the same applies to 3G TrFO.
If a TDM backbone is used, the TFO benefits are restricted to better voice quality. Using ATM or IP backbone also reduces the transmission capacity.

In 3G networks, the transcoders reside in the Multimedia Gateways. Therefore, the used codecs can be negotiated during call setup. If both ends support the same codec, no transcoding is needed and the same coding method can be used end-to-end. Naturally, this leads to better voice quality and provides optimal transport efficiency.

Migration to MSS

In 3G networks, the transcoders reside in the Multimedia Gateways. Therefore, the used codecs can be negotiated during call setup. If both ends support the same codec, no transcoding is needed and the same coding method can be used end-to-end. Naturally, this leads to better voice quality and provides optimal transport efficiency.

During the migration process, the operator can gradually increase the number of BSS connections, PSTN connections and PBX connections all of which terminate in the MGW by using IWS1E or T SDH interface units.
In the hybrid solution, the TDM interconnection capacity between the MGW and the MSC Server needs to have enough capacity for calls that are to be routed via the MGW to the MSC Server.
Moreover, if the operator implements the multipoint Iu or A interface by creating overlapping logical 'pool areas' defining which MSC servers control the particular RNCs or BSCs, the required transmission capacity needs to be in place at all connections.

The support for circuit-switched data connections (e.g from HSCSD modems) requires an interworking function (IWF) in the MSC. In the MSS System, the IWF functionality can also be hosted by a separate physical network element called Circuit switched Data Server (CDS).
The use of a CDS enables the use of a stand-alone MSC Server (without E1/T1 connections) and a clean separation of control plane and user plane data (including circuit-switched user data), as illustrated in the figure below.

The migration to MSC Server concept requires hardware changes for the M12 MSCi. Due to the use of IP transport for SS7 signalling messages, the MSC Server requires redundant LAN Switches. Note that the O&M and charging units use their own LAN.
Furthermore, the units responsible for SS7 Signalling, such as the BSS Signalling Unit (BSU) and the Common Channel Signalling Unit (CCSU), require duplicated access ports to LAN switches.
This is achieved using Pentium III or Pentium M-series CPUs. The required signalling unit types are: CP550-B or CP710-A (the latter applicable only for forced ventilation cabinets).
The minimum capacity for the message bus, MBIF-B, is 32MBytes/s, providing a capacity of 600,000 busy hour call attempts. Higher capacities can be achieved by using the MBIF-C message bus alternative.
Additionally, memory updates are required for Central Memory (CM), CCSU, Channel Associated Signalling Unit (CASU) and PBX Access Unit (PAU, if a PBX interface is provided).

The Nokia Multimedia Gateway is a user plane product which may terminate connections from BSS and RAN as well as provide trunk interfaces for PSTN and PBX.
The migration to the MSC Server system requires a new plug-in unit, VANU, for voice announcements.
The signalling units in the MGW require similar kinds of changes to the corresponding units in the MSC, i.e. increased processing power and redundancy of LAN ports per each signalling unit.
The CCP10 plug-in unit provides the required functionality and readiness for IPSec encryption/decryption (note: on the MSC side, the IPSec requires a CP710-A CPU for integrated IPSec encryption/decryption).
The MGW requires redundant ESA24 LAN switches and an external cabling cabinet for CAMB.

In order to use the Nokia MSC as an MSC server, the minimum software level requirement is the M12 release. The migration from the MSCi to the MSC Server concept requires normal M-release upgrade procedures and the activation of the MSC Server functionality.
The Nokia MGW requires the U2 software level, which can be upgraded using normal U-release upgrade procedures.
In addition, migration requires the following key steps:
Voice announcements and tones to be created for the MGW
Required SS7 network changes
Creation of interconnection between MSS and MGW
BSC interconnection swap from MSCi or Integrated MSS
RNC interconnection swap from Release 99 to Release 4 both in MGW and MSS
PSTN and PBX interconnection swap from MSCi or Integrated MSS to MGW