cs core system overview

7/22/2019 CS Core System Overview

http://slidepdf.com/reader/full/cs-core-system-overview 1/149



The figure below illustrates Multimedia Gateway in IP Multimedia

Subsystem and MSS environments

Figure 6. Multimedia Gateway in IP Multimedia Subsystem and MSSenvironments

MGW

3GPPSIP

IETFSIPGSM

WCDMA

BSC

RNC

MSS

HLR

IN

IP/ATM/TDM

backbone

MGW

IP MultimediaCore Network

PSTN/ISDN

IPbackbone

PSTN/ISDN

Other PLMN

WCDMARAN

GSM BSS

Broadbandaccess

PublicInternet

A

TC

ApplicationServers

Iu-PS

GbIu-CSNb/Nb’

Nb/Nb’

GGSN SGSN

Fss

Mb

SIP-I(Profile C)

Fixed SoftSwitch

BICC CS-2, SIP-I,SIP-T, ISUP

MSS

CSCF HSS

Firewall

A

Ater

DN0562859Issue 5-0 en

# Nokia Siemens Networks 35 (149)

CS core network elements



IMS-CS interworking

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

The Mn interface, specified by 3GPP, is a control interface between the IM-MGW and Media Gateway Control Function (MGCF) of the GCS. TheGCS (MGCF) has to support the new H.248 procedures of the Mninterface for handling IM-MGW functionalities in IM CN-CS networkinterworking situations. IMS-CS network interworking is supported for speech calls.

4.3.3 MGW in convergence networks

In the Nokia Siemens Networks' convergence solution, the MSC Server System and IP Multimedia Subsystem can be utilised as the main buildingblocks that create one complete network serving both fixed and mobileaccess methods.

The role of MGW in the Nokia Siemens Networks' convergence solution is

to perform user plane processing. Nokia Siemens Networks' convergencesolution offers one network that serves all access methods and providesCS capabilities for SIP subscribers. MGW offers an interface for the RTPstreams containing the user plane as in the IMS-CS interworking casedescribed above. For more information, see the U-release productdocumentation library.

For more information on the Nokia Siemens Networks' convergencesolution for the CS core network, see CS Core Voice Convergence .

4.4 Evolution of MSC and MGW

The hardware of the MSC is based on i-series cartridge (MSCi) mechanicswhich is much more compact and requires less space for installation thanthe former subrack mechanics. Only the exchanges based on the cartridgemechanics (MSCi) can be updated to meet the requirements of futurereleases. Subrack MSCs can be used to serve GSM traffic, as shown inthe following diagram:

36 (149) # Nokia Siemens Networks DN0562859Issue 5-0 en

CS Core System Overview



Figure 7. Evolution of MSC and MGW

The MSCs based on the i-series cartridge mechanics (MSCi) can beevolved into Integrated MSC Servers (MSS) by performing a SW and HWupgrade, whereas those based on the subrack mechanics can continue toserve GSM customers.

MSCi

MSSstandalone

MSSu

MSSintegrated

MGWfor MSS

MGWfor MSC

MSC MGWfor MSC

MSCi

MSC

SIParchitecture

UMTS +

GSM

GSM

IPA 2800

DX 200






MSC Server upgraded (MSSu)

MSSu is a product variant of MSS that includes all the MSS functionalities.The difference between the MSS and the MSSu is that the MSSu is alwaysan upgrade from the MSCi in existing GSM networks. When an operator deploys an MSC Server System to their existing network, they may want totransfer all user plane traffic of an MSCi to MGWs and to upgrade theMSCi to a standalone MSSu. The difference between the MSSu and anIntegrated MSS is that the MSSu is a standalone server product dedicatedonly to control plane handling, whereas an Integrated MSS also supportsTDM-based control and user plane traffic.

MGW evolution

MGW for MSC was updated into MGW for MSS to perform all user planeprocessing required in the MSC Server environment by utilising most of the hardware, and by installing new software. MGW for MSC functionalityis no longer supported as of MGW release U4.0.

MGW for MSS is also able to provide the user plane connection towards IPMultimedia Subsystem network and it can be used as a border elementbetween different kinds of networks. For more information, see Multimedia Gateway Product Description in U-release product documentation.

4.5 Circuit Switched Data Server

The Circuit Switched Data Server (CDS) is responsible for the interworkingfunction (IWF) in the MSC Server System. The standalone MSC Server does not have any connections towards the TDM-based networks and, asa result, the CDS is always needed for CS data calls requiring IWFfunctionality. Together with the integrated MSS, the CDS can be used toprovide more IWF resources if the integrated resources are fully exploited.Note, however, that the CDS is always connected to the MultimediaGateway (MGW) and that the CDS can only be used for the calls whose A/ Iu interface is connected to the MGW. The network operator can share theuse of the CDS by several MGWs in order to optimise the IWF resources.The figure below illustrates the CDS in the standalone MSS System:





Figure 8. CDS in the standalone MSS

The CDS is connected to the MGW and is controlled by the MSC Server via the MGW by using the device control protocol Megaco/H.248 betweenthe MSC Server and the MGW, and the NPI protocol between the MGWand the CDS. With the CDS the operator can effectively optimise therequired CS data call resources, because with the CDS the capacity canbe easily expanded according to operator's needs. CDS hardware isbased on the i-series DX 200 platform and it uses Intel Pentium embeddedprocessors.

For more information on the CDS, see Circuit Switched Data Server (CDS) Product Description in M-release product documentation.

4.6 Home Location Register

The Home Location Register (HLRi) consists of Home Location Register (HLR), Authentication Centre (AUC), and Equipment Identity Register (EIR), based on the DX 200 hardware.

The HLRi stores the subscribers' GSM/GPRS/UMTS subscription relateddata. It offers services for both Circuit Switched (CS) and Packet Switched

(PS) networks.

IP / ATM

backbone

RNC

BSC

A

Iu-CS

MGW site area

H.248/Megaco

MSC Server

user planecontrol planeCDS

MGWNPI






With the 2G/3G common core network, the HLRi maintains mobility

information, Intelligent Network (IN) service triggers, and standardisedsupplementary service data. The HLRi stores subscriber data permanentlyand provides subscriber data to the MSC/VLR and/or the SGSN of thearea where the mobile is currently located (the MSC/VLR or the SGSNwhere the mobile is registered). The HLRi also stores the address of theMSC/VLR and the SGSN where the mobile is registered and provides therouting information to the requesting entities, for example, to the GatewayMSC (GMSC).

In the Nokia Siemens Networks' solution, the same HLRi is used for GSMincluding GPRS, UMTS, and GSM/UMTS dual-band users. The benefit of the one-HLR solution is obvious, as a centralised subscriber databasedefinitely facilitates the management of subscriber data. The samesubscription covers both 2G and 3G access.

HLRi provides database storage and modification of:

. subscriber profile data

. authentication data

. equipment identity data specifying white, grey or black-listed mobileequipment identities.

Subscriber data is stored in the HLRi in the same way as in the Visitor Location Register (VLR), but the HLRi is a permanent database. The HLRisupports the Mobile Application Part (MAP) protocol over SS7 or IPtowards the MSC/MSS and SGSN. In addition, it participates, for example,in the following call processing functions:

. routing inquiries for mobile-terminated calls and short messages

. supplementary service activation/deactivation from mobile terminals

. support for incoming call barring services, unconditional callforwarding services, etc.

The HLRi is based on the same DX 200 hardware that is used in other network elements (for example MSCi) as well. Some of the elements of theHLRi are the fast MB (Message Bus) connecting the dedicated processor units, the GSW (Group Switch) for switching the signalling channels to thesignalling links, and the ETs (Exchange Terminals) to interface with thetransmission systems.





The new DX 200 HLRi is delivered with two alternative hardware

architectures: TDM and IP connectivity based variants. The IP connectivitybased architecture is optimised to utilise the Internet Protocol based LANinterfaces and it does not offer the TDM based connectivity.

Exact specifications for the interfaces between the modules make itpossible to add new functions without changing the system architecture,and enable the system to remain up-to-date throughout its long operationallife. The following figures show the architecture of the HLRi in different HWvariants.

Figure 9. DX 200 HLRi IP (datafull) architecture

Reg

O&MManagement

SIGU BDCU

HLRU

DBDU

ACU

Sign

EMB

Register LAN

CLS

Ext.Sync.input

Signaling LAN

O&M andManagement

LANInternal LANs

External LANs

STU

OMU

CMM

EMU

EIRU






Figure 10. DX 200 HLRi TDM (datafull) architecture

The functional units of the DX 200 HLRi are listed in alphabetical order inthe table below:

Table 4. DX 200 HLRi functional units

Functional unit Description Authentication Centre Unit (ACU) The ACU is responsible for the storage of the

authentication data.

Reg

O&MManagement

SIGU

STU

BDCU

HLRU

DBDU

ACU

Sign

EMB

Register LAN

STM

CLS

ET

Ext.Sync.input

Signaling LAN

GSWB2K

CCSU

O&M andManagement

LANInternal LANs

External LANs

OMU

CMM

EMU

EIRU





Table 4. DX 200 HLRi functional units (cont.)

Functional unit DescriptionBasic Data Communication Unit (BDCU) The BDCU contains all communication links to the

O&M network (analogue and/or digital), to the BillingCenter and to the IMEI database interface.

Central Memory & Marker (CMM) The CMM handles the functions of two separatefunctional entities, the Central Memory and theMarker.

Clock System (CLS) The CLS consists of two standard units, the ClockSystem Unit (CLSU) and the Clock and Alarm Buffer Unit (CLBU), and the optional Synchronization Signal

Interface (SSIF-S) unit.Clock System Unit (CLSU) The CLSUs generate the clock signals necessary for

synchronizing the functions of the HLRi and transmitthem further to the CLBU units in the other cabinets.

Clock and Alarm Buffer Unit (CLBU) The duplicated CLBUs distribute the clock signals(generated by the CLSUs) to the units in the samecabinet.

Synchronization Signal Interface, SSIF-S The optional SSIF-S units are used for generatingadditional synchronization signals to be fed from theexchange to partner equipment.

Common Channel Signalling Unit (CCSU) The CCSU handles CCS7 signalling and controls the

PCM connections of the exchange and the ETsallocated to the BDCU.

Database Distributor Unit (DBDU) The DBDU distributes HLR/AUC subscriber relateddata to the correct unit (HLRU/ACU).

Equipment Identity Register (EIR) The EIR consists of the Equipment Identity Register Unit (EIRU) and the Equipment Main Unit (EMU).

Equipment Main Unit (EMU) The EMU contains the main database of the EIR.

Equipment Identity Register Unit (EIRU) The EIRU performs the verification of equipmentidentities, that is, IMEI checks.

Exchange Terminal (ET) The ET performs the electrical synchronization andadaptation of an external PCM line.

Group Switch 512 (GSW 512) The GSW is the switching fabric of the HLRicontrolled by the CMM.

Home Location Register Unit (HLRU) The HLRU contains a fragment of the HLR databaseand application logic.

IP interfaces IP interfaces are represented by the Switching Unit(SWU) for Control LAN, SWU for O&M LAN, andSWU for LAN Management

SWU for Control LAN The SWU collects SIGTRAN signalling data from theCCSUs and sends it further to the IP network viaexternal SWUs for LAN and routers with a 100 Mbit/suplink connection.






Table 4. DX 200 HLRi functional units (cont.)

Functional unit DescriptionSWU for O&M LAN The SWU for O&M LAN collects O&M signalling data

from the computer units and sends it further toexternal routers and IP network via a 100 Mbit/suplink connection.

SWU for LAN Management The SWU for LAN Management makes it possible tocontrol the LAN network and the ESB switches in thenetwork element.

Message Bus (MB) The MB is the physical connection between thecomputer units.

Operation and Maintenance Unit (OMU) The OMU handles all centralized supervision, alarmand recovery functions, and the connections towardsuser interface (MMI-System).

Power Distribution Fuse Unit (PDFU) The PDFU distributes the -48V/-60V power from therectifier or batteries to the cartridges through thedistribution cables. The PDFU also contains the fusesfor these cables, along with alarm circuits for theincoming voltages and its own fuses.

Statistical Unit (STU) The STU collects performance and measurementdata from the network.

Storage Device Cartridges (SD3C and SD4C) These are the HLRi computer units (ACU, DBDU,

EMU, HLRU, OMU, and STU) that manage largedatabases are equipped with dedicated storagedevice units.

Signalling Unit (SIGU) Handles the signalling functions towards the networkelements in the NSS. The SIGU handles SIGTRANsignalling over IP.

STM-1 Performs the electrical synchronization andadaptation of an external PCM line. The STM-1requires the optional cabinet.

For a more detailed description of the DX 200 HLRi architecture and thefunctional units, see Home Location Register (HLRi) Engineering Description in M-release product documentation.

Authentication centre

The Authentication Centre (AuC) handles the management of securitydata for the authentication of subscribers. AuC is integrated into HLRi.

In GSM/UMTS networks, special attention is paid to security aspects:security against forgery and thefts, security of identity transmission, andsecurity of speech and data transmission. The high level of security isachieved with the Authentication Centre (AUC).





The AUC handles the management of security data for the authentication

of subscribers. It encrypts and stores the encrypted individual secret keys(K/Ki) of the home network subscribers in the AUC databases. The AUCgenerates authentication vectors requested by the MSC/VLR or theSGSN, using authentication algorithms. The authentication procedure isperformed to validate the correctness of the mobile user's USIM/SIM cardand to prevent accessing the network with a fake card.

For GSM subscribers the AUC generates authentication vectors, triplets,using A3 and A8 cryptographic algorithms that can be customer-specific.

In the UMTS system the authentication is mutual, that is, the networkauthenticates the subscriber and the subscriber authenticates the network.The AUC generates the authentication quintets using f1-f5 algorithmscustomised by operator-specific parameters. To support roaming from theUMTS to the GSM, quintets can be converted into triplets in the AUC.

Additional security with SECMO

The importance of protecting subscriber information has been taken careof in the AUC with superior security standards and encryption techniques.To further increase the safety of the AUC, it is possible to add additionalSECMO (Security Module) plug-in units to the AUC. The SECMO isprotected both physically and logically, thus the plug-in unit is especially

suitable for protecting sensitive data in the AUC. With SECMOs it isensured that the subscriber authentication keys (K i's) are handled in clear form in a specially protected environment only.

When SECMOs are used, the confidentiality and integrity of the subscriber authentication keys (K i's) are protected using state-of-the-art dataencryption techniques.

Equipment identity register

The Equipment Identity Register (EIR) contains the databases andmaintains the database records of International Mobile EquipmentIdentification (IMEI) numbers. These IMEI numbers are stored on threelists. The lists, white, grey, and black, indicate the current status of themobile equipment: the white list indicates approved mobile equipment ingood standing, while the grey list indicates mobiles under observation,such as for suspected malfunction. The black list includes equipment with,for example denied access to the network, such as stolen or missingmobile phones. IMEI checking is executed to find out if the mobileequipment can be found on some of the lists or if it is completely unknownin the EIR. Depending on the IMEI check result, the requesting party candecide on further actions.






When the EIR receives a request from the MSC/VLR (or the SGSN), it

searches its databases to determine on which list a mobile phone's IMEI islocated. It then sends the information back to the MSC/VLR, which acts onthe information accordingly; for example, the MSC/VLR may terminate thecall if the mobile phone's IMEI is found on the black list.

In GSM/UMTS networks, special attention is paid to security aspects. TheEIR provides security on two different levels:

1. The EIR can be used to protect the operator's network from theaccess of unwanted mobile equipment. These are usually mobilephones that cannot behave according to GSM specifications andtherefore their access into the network is a potential security risk.

As the EIR white list is meant for the complete IMEI series of all type-approved equipment, each IMEI that cannot be found in the EIRdatabase is a possible security risk that needs to be checked beforepermitting the mobile phone into the network.

2. The EIR can be used in enhancing the security of the subscribers'mobile equipment. Black-listing the IMEIs of all stolen mobile phonesand blocking their use in all VLRs is a very effective way of reducingmobile phone thefts, or at least making the thefts quite useless.

The EIR can take care of this very efficiently on the network level.Furthermore, the IMEI database interface of the EIR can be used toexpand the coverage on the inter-network level as well asinternationally. Of course, this cannot be achieved by one EIR or network alone, but the global coverage will be better the more thereare operators using the IMEI database interface of the GSM MoU Association.

For more information on the DX 200 HLRi, see Home Location Register (HLRi) Product Description in M-release product documentation.





4.7 Evolution of HLRi

Evolution towards Complete Subscriber and Service ManagementSystem (CSMS)

The DX 200 HLRi offers a smooth and easy evolution path to the CompleteSubscriber and Service Management System (CSMS). The CSMS is aNokia Siemens Networks solution, which offers a centralised, commonback end repository called NSR (Nokia Siemens Networks Subscriber Repository) storing all different subscriber data to be updated andaccessed by different applications and front ends (FE). The DX 200 HLRiis such an FE that can be connected to the NSR.

Figure 11. Complete Subscriber and Service Management System (CSMS)

For more information on the CSMS, see Nokia Siemens NetworksSubscriber Repository product documentation in NOLS.

Evolution steps of DX 200 HLRi

As the first step of evolution the existing datafull DX 200 HLRi is connectedto the Nokia Siemens Subscriber Data Repository (NSR) to achievemultiple useful features. Such features are, for example, N+X HLRredundancy, HLR cleaning and pre-provisioning. The usage of HLRitogether with NSR offers also additional capacity, because the HLRcleaning and pre-provisioning features guarantee that the HLR stores onlythe data of active subscribers while the inactive and pre-provisioned

subscriber data is stored only in the NSR.

HLR HSS AAA NP Others

Front Ends

Provisioning and mediation

NSR






As the second step of evolution the new dataless DX 200 HLR FE is

deployed. It is possible to upgrade the existing DX 200 HLRi SW and HWto DX 200 HLR FE and thus protect the current investments. The existingDX 200 HLR functionalities are supported by the dataless DX 200 HLR FEand the hardware configuration of the DX 200 HLR FE is optimised to offer the same performance with smaller floor space. With the dataless HLR FEthe CSMS enables more resilient MAP routing making the network morerobust.

For more information on DX 200 HLRi features and HLRi evolution, seeHome Location Register (HLRi) Product Description and Home Location Register (HLRi) Engineering Description , in M-release productdocumentation.

4.8 MSC Server products

MSC Server

The 3GPP specifications define call control and mobility control server products in the Circuit Switched (CS) core: MSC server and GMSC server.These servers control the parts of the call state model which relate toconnection control for media channels in a MGW. In the Nokia Siemens

Networks' solution the MSC Server is a product that includes thefunctionality of the MSS and the Gateway MSC Server.

The MSS mainly comprises the call control and mobility control parts of atraditional MSC. It is responsible for the control of mobile-originated andmobile-terminated circuit switched calls and it terminates the user-networksignalling and translates it into relevant network-network signalling. TheMSS also contains a Visitor Location Register (VLR) to hold the mobilesubscriber's service data and CAMEL-related data. In addition, the ServiceSwitching Point (SSP) is embedded in the MSS. For more information onVLR and SSP, see the respective descriptions in the section MobileSwitching Centre .

The MSS and GCS support GSM and 3G services and subscribers in thesame network element, ensuring the continuity of the existing GSMservices. They also facilitate an easy migration of the subscribers fromGSM to 3G, as no changes to network topology or network elementconfigurations are needed.

The MSS can be deployed either as integrated with the MSCi or as astandalone element. The difference between these configurations is thatthe standalone MSS does not have any TDM-based user plane interfaces(but they are optional).





The functionality of the MSS can be divided in two roles: Pure MSS and

Gateway Control Server (GCS). The GCS includes the functionality of theGMSC Server. It also has the Media Gateway Control Function (MGCF)functionality needed for interworking between IP Multimedia Subsystem(IMS) and CS core. For more information on the MSC Server and MSSproduct configurations, see MSC Server Product Description in M-releaseproduct documentation.

Integrated MSC Server

For operators who already have an operational PLMN, there is a possibilityto integrate the MSC Server functionality into an existing MSCi by asoftware upgrade and in some cases, by minor hardware changes or upgrades. The Integrated MSS is an MSCi that was upgraded to an MSCServer. The Integrated MSS has all the functionalities that are in the MSSplus IWF function and TDM connectivity. A TDM-based network cancoexist with the IP/ATM Backbone and the Integrated MSS can utilise bothnetworks. The operator can define the type and amount of traffictransported through the IP/ATM backbone and the TDM network. TheTDM lines from the GSM/EDGE Radio Access Network (GERAN) can beconnected into either the Integrated MSS or the MGW.

The figure below illustrates the HW architecture of an Integrated MSS. For a description on the other functional units, see Mobile Switching Centre

(MSC).






Figure 12. Architecture of Integrated MSS (the architecture is the same in MSC

and MSC Server)

Standalone MSC Server

The MSC Server is a product that includes the functionality of the MSS andthe Gateway MSC Server. The MSS terminates the user-networksignalling and translates it into the signalling over the Nc interface. It alsoterminates the signalling over the Mc interface with the multimediagateway thus acting as a media gateway controller. The MSS is integratedwith a VLR to store the mobile subscribers' service data. The Gateway

CDSU

TGFP

BDCUPAUMCCSUBSUMFSUCASU

CHU OMUSTUVLRUCMCMU

PSTN

PBX

NSS

LAN LAN LAN

VDU and LPT

X.25

BSS

ET

GSW

CCMU

MESSAGE BUS

ET

ET

ECET

CLSEXTSYNC

VANG

SWU

LANSWUIP for

Control LAN

DN98616796

IP for

O&M LAN





MSC Server terminates the signalling over the Nc interface and the call

control interfaces to the external networks. It also terminates the signallingover the Mc interface towards the Multimedia Gateway thus acting as amedia gateway controller.

In addition, the MSS also includes the Media Gateway Control Function(MGCF), used to control the MGWs in the IP Multimedia Subsystem (IMS).The MSS offers the functionality where control plane is destined to theMSS and the user plane transportation and user plane processing is donein the MGW. The MSS is a network element dedicated to control planeprocessing.

The figure below illustrates the MSS network environment:

Figure 13. Network environment of standalone MSS/GCS

MSS GCS

IP/ATM/TDMBackboneUTRAN

lu-CS

A-if

E1, T1, JT1, ATM IMA, STM-1 (STS-3) VC-4, STM-1 (STS-3) VC-3Ethernet 100 BaseT, Ethernet 1000BaseT, 1000BaseLX, STM-1 (STS-3) VC-4, STM-1 (STS-3) VC3

E1, T1, JT1, STM-1 VC-12, STS-3/OC3 VC-11Ethernet 100 BaseT

E1, T1, JT1

PSTN /ISDN

MGWMGW

BSS/GERAN

CDS

PBX






The MSS does not have a Group Switch for switching 64 kbit/s TDM

channels but an optional small Group Switch (GSW) can be included in theconfiguration if required for TDM-based SS7 and Private AutomaticBranch Exchange (PBX) signalling. The following figure shows thehardware architecture of the MSS, NVS and MSSu and how the units arebacked up to ensure reliability. The optional elements are shown on greybackground:

* SU = BSU, SIGU or SCPU

Figure 14. Architecture of MSS, NVS, and MSSu

IP for Control LAN

E1 or T1

Ext. Sync.

X.25

IP for O&MLAN

Optional in MSS(not in MSSu)dn0247335

optional

VDU and LPT

CCSU

*SU

*SU

VLRU

CHU

STU

SWU

SWU

BDCU

CMM

GSWET

CLS

OMU

M E S S A G E B U S

CMU





One of the Charging Units (CHU) except for CHU0 can be replaced with

the optional Indirect Access Unit (INDU).

The Central Memory and Marker (CMM) contains the functionalities of central memory and marker in same functional unit and it is included onlyin the standalone MSS. Another unit used in the standalone MSS but not inthe Integrated MSS, is the signalling unit (SIGU). It has the functionalitiesof CCSU except that SIGU can utilise only IP-based SS7 network whereasCCSU can use either IP or TDM -based SS7 network. The SIP callprocessing unit (SCPU) is responsible for the SIP access function andNokia VoIP Server (NVS). It handles SIP protocol, call control, LDAPconnection, and the subscriber data that is not included in the VLR. Other functional units are the same as in the Mobile Switching Centre (MSC). For more information, see the section Mobile Switching Centre .

Gateway Control Server

The GCS is a functionality in the MSS. The HW and SW are same as thestandalone MSS, but pure GCS does not have VLRUs and BSUs and thusit does not include mobility management functionality.

The Gateway Control Server (GCS) is a modern GSM (2G), 3G, and All-IPfunctionality of the MSS. Its versatile signalling features and sophisticated,distributed system architecture make it easily adaptable to a wide scope of

applications and system solutions.

The GCS incorporates some of the GMSC Server functionality, allowingoperators to use it as part of the MSS system to control the MGWs thatprovide interworking between the PSTN/ISDN and bearer-independentcircuit-switched IP, or the ATM based PLMN network. In addition to theGMSC, the GCS has the MGCF fucntionality, The GCS is the MSSfunctionality dedicated to control plane processing.

The GCS has all the properties that enable its use in a bearer-independentcircuit-switched core network. The real benefit of the GCS is that it canalso be used for controlling the MGWs used for interworking between thePSTN/ISDN and the IP Multimedia Subsystem (IMS). The GCS alsocontains the Session Initiation Protocol (SIP) protocol, used as a sessioncontrol protocol in All-IP networks.

For more information on GCS in the MSC Server System, see MSC Server Product Description in M-release product documentation.






MSC Server upgraded (MSSu)

The MSSu is an MSC that was first upgraded to an MSC Server, iMSS,and then further modified into a standalone MSS by removing the IWFfunction and TDM connectivity. The MSSu has all the functionalities thatare in the MSS. The difference between the MSSu and an Integrated MSSis that the MSSu is a standalone server product dedicated only to controlplane handling, whereas the Integrated MSS can also have TDM-basedcontrol and user plane traffic. See also Evolution of MSC and MGW .

Nokia VoIP Server

Nokia VoIP Server (NVS) provides GSM-like services to VoIP clients. Suchservices are, for example, supplementary services, network services, andregulatory services. NVS is based on the MSS software. Thus, it canprovide the same services the MSC Server offers. NVS is available either as a standalone version with SIP access interface or as an ApplicationServer for IMS.

4.9 Backbone connectivity solution

The main target of the backbone connectivity solution is to have a

transport network that efficiently fulfils the needs and requirements of themobile network applications running on top of it. Nokia Siemens Networksand its partners can provide end-to-end backbone solutions including allthe required products.

The number of existing or planned core sites and the number of existingbackbone or transmission solutions is of key importance when planningthe backbone solution for a mobile network. The backbone solutionssupport the intra-site packet connectivity of GPRS, 3G packet core, andMSC Server traffic. In all cases, the backbone architecture must supportthe evolution of the mobile standards. 3GPP Rel-4 specifications allow theseparation of switching and call control in the CS core network using theMSC Server System . 3GPP Rel-5 removes the imperative to use ATMtransport at the Iu interface. 3GPP Rel-5 also introduces the IP MultimediaSubsystem (IMS) and Session Initiation Protocol (SIP) connectivity for IMS.





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

Backbone technology selection

The backbone for the mobile network can be based on TDM, ATM, IP,Ethernet or a combination of these technologies. The operator needs toconsider at least the following aspects when selecting the backbonetechnology and planning technology transitions:

. strategy

. available transmission network

Backbone Transport-IP/MPLS, ATM-SDH/DWDM

Corporate

Core SiteMSC Server, MGW, HLRSGSN, GGSN, CSCF,HSS...IP/LAN connectivity

Server SiteMMSC, WAP GW,Download/streamingserver...IP/LAN connectivity

Core Site

MSC, HLR, SGSN, ISN...IP/LAN connectivity

Controller Site

BSC, RNC, MGWIP connectivity

Controller Site

BSCIP connectivity

PSTN

GRX

ISPnetworks

Regional Transport-TDM/ATM/IP-SDH

IPTDM

Access Transport

Corporate






. cost

. skills

. regulatory requirements

When moving from Circuit Switched (CS) to Packet Switched (PS)technology, mobile operators need to implement IP connectivity betweenthe mobile network elements. In the transition process, there are threetechnical challenges. First of all, the Quality of Service (QoS) scheme of the network has to support both real-time and non-real-time traffic.Secondly, network resilience should be at least as good as in the TDM-based systems. Finally, network security has to be ensured. These

challenges have to be met in a cost-effective way using architecturalsolutions that can be expanded along with the increasing number of mobile subscribers and their increasing use of bandwidth and services.

In addition, network operators also need to develop operationalprocedures for the IP networking equipment to make sure that the IPnetwork is operated according to telecom quality requirements.

Site connectivity

IP connectivity in mobile networks consists of site connectivity and siteinterconnection. Site connectivity solution describes how the networkelements are connected to each other on a physical site. Siteinterconnection covers the methods of connecting the sites to each other using backbone networks or direct links. Nokia Siemens Networks' IPconnectivity solution is based on site connectivity solution. There are onlyvery few direct links between the network elements and backbonenetwork, and Nokia Siemens Networks network elements do not rely onany specific backbone technology for site interconnection. While IP/MPLStechnology is recommended for site interconnection, ATM networks anddirect links between site routers are equally supported. This allows a cost-efficient migration to packet-based networks for any type of mobileoperator.

For an overview on LAN and IP connectivity of the CS core networkelements, see section Site connectivity solution overview in Site Connectivity Guidelines for CS Core Network provided in CS Core SystemDocumentation library.

Network operation and management

As part of a mobile system, Nokia Siemens Networks also provides anetwork management solution for the backbone transport network and itsintegration to the overall Nokia Siemens Networks mobile networkoperations support solution, the Nokia NetAct Framework. The Nokia





Siemens Networks solution provides operators and service providers a

complete set of tools to support end-to-end processes of operating anddeveloping the whole service platform. For more information, see sectionNokia NetAct in CS Core System Overview provided in CS Core SystemDocumentation library.

Active Network Abstraction (ANA) provides a mediation layer between theoperation and network layers. It offers management integration for multivendor, multi-technology networks. To help operators, Nokia SiemensNetworks and Cisco are jointly developing a single, open, extensible, andvendor-neutral OSS platform based on IT industry standards and bestpractices. The OSS collaboration is based on sharing components andinnovative modelling technology within Cisco ANA and embedding that tothe NetAct system. The OSS collaboration includes the commitment tosupport multiple standard Nokia Siemens Networks APIs, developer community with SDKs, documentation, testing, and support from bothcompanies. This collaboration will enable streamlined Network OperationsCenters for operators with real end-to-end management for Rel-4 and IP/ MPLS networks.

CiscoWorks provides a standalone network management platform for Cisco LAN and WAN components of IP backbone networks. This solutionenables network management and simplifies configuration, administration,monitoring, and troubleshooting of Cisco routers and LAN switches. For

more information, see Cisco web pages (www.cisco.com).

In addition, LAN Device Integration feature for DX200-based networkelements integrates the SWUs in the element. This feature makes itpossible to have a unified user interface (MMI) for managing the internalLAN switches (SWUs). For more information, see section LAN management in Site Connectivity Guidelines for CS Core Network provided in CS Core System Documentation library.

Firewalls

Firewalls (FWs) ensure that communication between the core network andthe Internet/inter-PLMN backbone conforms to a declared security policy.Security is achieved by using the Stateful Inspection technology. Thistechnology allows the firewall to associate a network with an applicationonce a session has started. In other words, the firewall recognisesindividual packets as being associated with certain applications. Applications that require the end user to contact a server through aspecific port find the association very useful when the server has allocateda random port for the back connection. Applications like this presentdifficulties for simple packet filters.






For more information, see section Backbone network security in IP

Connectivity in Core Networks and Site Connectivity Guidelines for CS Core Network provided in CS Core System Documentation library.

Domain Name Server (DNS)

In an IP network, a Domain Name Server (DNS) is required for translatingFully Qualified Domain Names (FQDNs) (such as www.nokia.com) into IPaddresses (such as 128.92.10.10). For reliability, each PLMN shouldinclude two DNS servers, one primary and one secondary (backup).

In the CS core network, DNS is part of the MSC Server System. TheSession Initiation Protocol (SIP) requires the DNS to resolve IP addressesof the other signalling end point. In the MSS, SIP can be used as analternative call control protocol in IP-based networks, and in the MSS, SIPis used as a tunnelling method for ISDN User Part (ISUP) messages. TheDNS can be used also for setting up H.248 connections in the MultimediaGateway (MGW) start-up or when new H.248 connections are created.

In the MSS system, DNS services are needed for converting FQDNs intoIP addresses. Reverse conversion from the IP address to the FQDN isneeded if the FQDN of the signalling unit's IP address has to be found out.These FQDNs are used in SIP and in SIP for telephony (SIP-T). DNSservers are located in the IP backbone together with the MSSs and the

MGWs. On the IP level, the backbone is independent of other externalnetworks.

The IMS is based on IP networks and requires DNS support to mapFQDNs into IP addresses. The IMS also utilises DNS/ENUM functionalityin addition to basic DNS. ENUM is used to map E.164 numbers to SIPcontacts.

For more information, see DNS in MSC Server System in M-releases'product documentation library. The DNS server can be based on the NokiaDNS product. For more information, see Nokia Domain Name Server product description available in NOLS.

Session Border Controller (SBC)

IPv4 is still the dominant addressing version and as there is a multitude of security threats, the need arises for different “middle-boxes ” such asNetwork Address Translators (NATs) and firewalls. Their presencerequires the introduction of intelligent devices that enable both SIPsignalling and media to pass through. The Session Border Controller (SBC) is such a device. SBC enables interactive communication across





the borders or boundaries of disparate IP networks. In addition, SBC can

hide the network structure from the outside world, including the internal IPaddressing. The operator can also utilise SBC in load sharing betweendistributed hosts.

For more information, see section Session Border Controller (SBC) in Site Connectivity Guidelines for CS Core Networks provided in CS CoreSystem Documentation library.

4.10 Lightweight Directory Access Protocol (LDAP)

Lightweight Directory Access Protocol (LDAP) is a protocol for accessingdirectory information. LDAP is a standard Internet protocol that enablesdiverse directories to communicate with each other in a commonlanguage.

If the operator acquires the Light Directory Access Protocol database(LDAP) product from Nokia Siemens Networks, the LDAP is a SunoneDirectory product. The Nokia VoIP Server (NVS) is the LDAP client. TheLDAP is a centralised directory and its content is recommended to bemirrored.

LDAP uses the same PRFILE DiffServ code point value as the other control plane protocols. The operator may also set DiffServ code pointsbased on the port number, independent of the protocol.

Intra-operator calls (calling party domain name equals to the called partydomain name): For the NVS use, the LDAP must contain SIP URIs of allsubscribers of the particular PLMN. If the called party URI is not found, thecall fails. For the inter-operator calls (the domain names of the calling andcalled party are different) the LDAP must contain default routing numberstowards the target operator network.

LDAP also contains user name and password for the HTTP-digestauthentication purposes (SIP access case). Also other information isstored in the schema needed by the NVS to simulate GSM/3G behaviour.

For more information on the LDAP in NVS use, see CS Core Voice Convergence . See also LDAP Server for NVS , in M-release productdocumentation.






4.11 Nokia Siemens Networks Subscriber Repository(NSR)

Nokia Siemens Networks Subscriber Repository (NSR) is a highlyscalable, high-performance real-time subscription repository and backupstorage capable of storing subscription profiles of DX 200 HLRi. In additionto the data storage function, NSR provides pre-provisioning and cleaningfunctionalities to save HLR capacity. Only the the active, revenue-producing subscribers are consuming register capacity. Other subscriber profiles (pre-paid and relatively inactive subscribers) are stored in NSRuntil the subscriber becomes active and starts producing revenue. This isuseful especially to operators with a large number of pre-paid and/or relatively inactive subscribers.

NSR acts as a centralised repository and a real-time backup storage for the cleaned HLR subscribers. It stores the cleaned and pre-provisionedsubscriptions that can be loaded to the HLR on demand. Main copy of thesubscription data is located in HLR and updates to the subscription dataare replicated to NSR. Data can be loaded from NSR to a redundant HLR if the active HLR fails.

Nokia Siemens Subscriber Repository (NSR) is part of the CompleteSubscriber and Service Management System (CSMS) solution.

NSR is connected to HLRs with a proprietary protocol that is run on top of TCP/IP. This is an existing interface in HLR. Also, NSR provides an openLDAP interface, which can be used to integrate operator ’s ownapplications. The required database schema can be defined in NSR andsubscriptions can be managed via provisioning interface. The LDAPinterface can be used also for reading HLR data from NSR.

For more information, see NSR Functional Description in Nokia SiemensNetworks Subscriber Repository documentation.





5 Interfaces in CS core network

5.1 Overview of the CS core network interfacesNokia Siemens Networks' CS core network elements provide interfaces toboth GSM/EDGE and WCDMA radio networks. In this context theinterfaces are described on a general level. For more information, see therespective Interface Specifications which are provided as part of therelevant network element product documentation libraries.

3GPP Rel-4 introduces the bearer-independent CS core networkarchitecture referred to as the MSC Server (MSS) System in the NSNsolution. The Multimedia Gateway (MGW) may serve the MSC Server as a

multi-functional element having several interfaces in the same hardware.On the other hand, operators may have a few dedicated gatewayelements, such as PSTN connections, and other gateways for routingmedia between radio access interfaces and core interfaces. 3GPP Rel-5and later specifications introduce IP Multimedia Subsystem (IMS). Thelogical interface from CSCF is to MSS/GCS, but the user plane goes viaMGW.



Interfaces in CS core network



Figure 16. Interfaces of CS core network including MSC Server System

For the circuit switched domain, the table below lists the interfacesbetween the major elements:

Table 5. Interfaces between the major elements

Interface Protocol Transport Physical IF

MSC/MSS - RNC - (all traffic throughMGW)

- -

MSC - BSC BSSAP IP (SIGTRAN) LAN

Gs

(H.248)

A/Ater

Iu

BSC CSCF

MAP MAP

CAP /

INAPMAP

CAP /INAP

(H.248)

(SIP, BICC CS-2ISUP)

Nc

Mc

Mc

Nb Nb

3G SGSN GGSNexternal IPnetworks

RNC IP / ATM / TDMbackbone

PSTN/ISDN

MSS

HSS

Gi

MAP-D

Gi(Gm)

Cx

MGW

ISUP

(SIP)

Mn

Mj/Mg/

SCP

MAP

ISC

MSS

2G SGSN

MGW

PBX

IP

DSLAM

LDAP

firewall

firewall

Mb

Mb

HLR





Table 5. Interfaces between the major elements (cont.)


MGW - BSC User plane TDM STM-1 (VC11/VC12)

E1/T1

MGW - RNC RANAP ATM STM-1

E1/T1

MSC - HLR MAP TDM

IP (SIGTRAN)

E1/T1

LAN

MSC - SCP INAP,

CAP, MAP

TDM

IP (SIGTRAN)

E1/T1

LAN

MSC - NetAct Q3, FTAM, VTERM,XML over HTTP / FTP,Telnet

TCP/IP (OSI)

TCP/IP

LAN

MSC - PSTN/ISDN ISUP/TUP/R2 TDM E1/T1

MSC - SMSC MAP

SMRSE

TDM

IP (SIGTRAN)

X.25, TCP/IP

E1/T1

LAN

X.21, LAN

MSC - CCBS FTAMFTP, GTP'

ISO-IP (OSI), X.25TCP/IP

X.21, LANLAN

HLR - CCBS FTAM, VTERM, PAD

FTP, Telnet

ISO-IP (OSI), X.25

TCP/IP

X.21, LAN

LAN

MSS - GCS BICC CS2

SIP

ISUP/TUP/R2

IP (SIGTRAN),TDM,MTP3/MTP2

UDP/IP

TCP

LAN

E1/T1

GCS - CSCF SIP UDP/IP

TCP

LAN

MSS - MSS

(See the note below)

BICC CS2

SIP

ISUP/TUP/R2

IP (SIGTRAN),TDM,MTP3/MTP2

UDP/IP

TCP

LAN

E1/T1

MSS - MGW H.248 (Megaco) SCTP over IP LAN

MSS - MGW IWF control protocol(NPI)

SCTP over IP LAN

Integrated MSS - MGW User plane TDM E1/T1






Table 5. Interfaces between the major elements (cont.)


MSS - STP MAP M3UA/SCTP/IP

MTP3/MTP2

LAN

E1/T1

MGW - MGW Nb RTP, RTCP/UDP

AAL2

-

IP

ATM

TDM

LAN

STM-1

E1/T1

Standalone MSS -NetAct

Q3, FTAM, VTERM,XML over HTTP, FTP,Telnet

TCP/IP (OSI)

TCP/IP

LAN

Integrated MSS -NetAct

Q3, FTAM,VTERM, XMLover HTTP, FTP, Telnet

TCP/IP (OSI)

TCP/IP

LAN

CDS - MGW IWF control protocol(NPI)

TCP/IP

SCTP

LAN

CDS - MGW User plane TDM E1/T1

CDS - NetAct XML over HTTP TCP/IP LAN

MGW - NetAct CORBA, IIOP, Telnet,FTP

TCP/IP LAN

NPM ( Profile Manager)- HLR

EMT (External MessageTransfer)

TCP/IP LAN

NPM - NPS (ProfileServer)

XML/RMI TCP/IP LAN

MSS/NVS - NPS openLDAPv2 TCP/IP LAN

HLR - NetAct Q3, FTAM,VTERM, XMLover HTTP, FTP, Telnet

TCP/IP (OSI)

TCP/IP

LAN

GCS-NetAct Q3, FTAM,VTERM, XMLover HTTP, FTP, Telnet

TCP/IP (OSI)

TCP/IP

LAN

SGSN - IP network RTP, RTCP/UDP IP LAN

IP network - MGW RTP, RTCP/UDP IP LAN

Tip

SS7 protocol can be transported over IP between MSS and MGW.





Tip

Signalling transport protocol uses BICC CS2 over IP SIGTRAN/TDM.The user plane is transported over ATM or IP. ISUP is required if theuser plane is TDM.

Tip

Nokia Siemens Networks documentation includes instructions for configuring IPv6. Check the detailed IPv6 availability in MSS and MGWproducts from Nokia Siemens Networks.

The table below lists the interfaces between PS core network elementsand CS core network:

Table 6. PS core NE - CS core interfaces

Logical IF IF towards Protocol Type Physical/ network IF

Gr HLR MAP Signalling SS7 (E1)

SS7 over IP

Gf EIR MAP Signalling SS7 (E1)

SS7 over IP

Gs MSS/VLR BSSAP+ Signalling SS7 (E1)

SS7 over IP

The table below lists the interfaces between CS core network elementsand IP Multimedia Subsystem (IMS):

Table 7. IMS-CS interfaces


MAP-D HSS-HLR MAP Signalling SS7

Mj/Mg CSCF-MSS SIP UDP/IP LAN

Mn MGCF-MGW H.248 Signalling SCTP/TCP

over IP






Table 7. IMS-CS interfaces (cont.)


Rf MGCF-CDF Diameter Charging data LAN

5.2 Access network interfaces

The access network interfaces connect the circuit switched (CS) corenetwork to:

1. radio access networks: the GSM/EDGE Base Station Subsystem(BSS) and 3G WCDMA RAN

2. IP-based access networks.

5.2.1 A-interface

The A-interface between the MSC/MSS and the GSM/EDGE BSS is used

by layer 3 applications such as radio resource management, mobilitymanagement, and connection management.

The protocol used is known as Base Station System Management Application Part (BSSMAP) and it is specified in the TS 08.08 and TS48.008. The A-interface is TDM-based.

When the A-interface is connected to the MGW for MSS, BSSAPsignalling is routed from MGW to MSS using SIGTRAN. As a result, theMGW acts as a signalling gateway.

Multipoint A (A_flex)

In cases where Multipoint A-interface functionality is used in the PLMN, themobility management and call control activities of 2G mobile stations(MSs) are always handled by the same dedicated MSC/MSS belonging toa pool area. This means that the MSC/MSS does not change when the MSmoves within the pool area. If the MS moves outside the pool area, theninter-MSC/MSS relocation will be done in order to move the control to anew MSC/MSS.





Within the MSC Server System architecture, the A-interface's E1/T1

resources are configured for certain virtual MGWs controlled by the MSCServer (or for the sake of redundancy, several MSC Servers in the pool). Ineither case, the use of the virtual MGW feature allows one physical MGWnetwork element to be used by an MSS pool, thereby reducing the number of connections between physical network elements (Transcoding and Rate Adaption Units, TRAUs, and MGWs).

The MSC and MSC Server supports Multipoint A interface functionality.For more information about Multipoint A and its benefits to the operator,see CS Core Multipoint Configuration Guidelines in the CS Core Systemdocumentation library.

Ater interface

Standardised GSM architecture defines that transcoding is part of theBSS. This functionality is typically provided by a separate standalonenetwork element. In such cases the interface between the BSC andtranscoder is called Ater. In new deliveries for Nokia system customers, Ater in MGW is an alternative to the transcoder in Nokia BSS areas. For more information, see MGW Functional Description provided in U-releaseproduct documentation.

In WCDMA architecture, transcoding functionality is specified to be part of

the core network and in the Nokia Siemens Networks' WCDMA solutiontranscoding is located in the Multimedia Gateway.

5.2.2 Iu interface

The 3G radio access network (WCDMA RAN) is connected to the corenetwork via the Iu interface. The interface is designed to separate thecomplexity in the core and radio access networks. The Nokia SiemensNetworks implementation is done according to standards. The protocolused is a control plane protocol called Radio Access Network ApplicationPart (RANAP) and it is specified in the TS 25.413. The Iu interface is ATMor IP -based and designed to be fully open to ensure interoperabilitybetween different vendors' networks.

The Iu interface facilitates the provision of existing GSM core networkservices over the UMTS radio interface. It provides the capability toallocate bearer services for the core network and UTRAN. It is the task of the core network to map its services to the Iu interface bearer requests.The Iu interface also provides the means for controlling the radioresources in UTRAN, as well as the Iu interface link resources. The figuresbelow illustrates the Iu interface protocol structure with both ATM and IPtransport alternatives towards the circuit switched domain:






Figure 17. Iu interface protocol structure towards CS core network (Iu over ATM)

Transport

networklayer

Radionetworklayer

Control plane

Transport networkuser plane

SCCP

MTP3b

SSCF-NNI

SSCOP

AAL5

User plane

Transport network

user plane

AAL2

Transport networkcontrol plane

Q.2630.1

Q.2150.1

MTP3b

SSCF-NNI

SSCOP

AAL5

ATM

Physical layer

RANAP Iu UP protocollayer





Figure 18. Iu interface protocol structure towards CS core network (Iu over IP)

Tip

Nokia Siemens Networks documentation includes instructions for configuring IPv6. Check the detailed IPv6 availability in MSS and MGWproducts from Nokia Siemens Networks.

TransportNetwork

Layer

RadioNetworkLayer

Q.2630.2

Q.2150.1

MTP3b

SSCF-NNI

SSCOP

AAL5

RANAPLayer

Physical Layer

Control Plane User Plane

lu UP Protocol

Transport NetworkControl Plane

TransportUser

NetworkPlane

TransportUser

NetworkPlane

SCCP

MTP3b

SSCF-NNI

SSCOP

AAL5

M3UA

SCTP

IP

ATMData Link ATM

AAL2RTP/RTCP

UDP/IP

ATM Data Link






An important feature of the Iu interface is that it provides logical separation

between circuit switched and packet switched signalling. This means thatit is possible to physically separate the interfaces into the Iu-CS interfacefor circuit switched traffic, based on the ATM or IP transport protocol, andthe Iu-PS interface for packet switched traffic, based on IP or ATM.

The MSC Server has to support the mobility management and connectionmanagement protocols of TS 24.008. The MSS is also required to supportthe base station system application part (BSSAP) protocol of TS 08.08/ 48.008 and the radio access network application part (RANAP) protocol asdefined in TS 25.413.

In the MSC Server System, the MSS handles the control plane traffic of WCDMA RAN. The Iu-CS control plane traffic is routed from the RNC tothe MGW where it is relayed to the MSS by using SIGTRAN.

Multipoint Iu (Iu_flex)

When Multipoint Iu functionality is used in the Public Land Mobile Network(PLMN), the mobility management and call control activities of 3G user equipment (UE) are always served by the same dedicated MSC Server belonging to a pool area. This means that the MSC Server does notchange when the UE moves within the pool area. In cases where the UEmoves outside the pool area, inter-MSC/MSC Server relocation will be

performed to move control to the new MSC Server.

The Multipoint Iu interface functionality is supported by MSC Server. For more information about Multipoint Iu and its benefits to the operator, seeCS Core Multipoint Configuration Guidelines available in the CS CoreSystem documentation library.

5.2.3 SIP access interface

When SIP access interface is used from the MSC Server together with the3GPP-defined MSC Server -functionality, it is possible to introduce Voiceover IP (VoIP), and messaging interworking between short messageservice and SIP messaging. It is also possible to provide services for bothfixed and mobile networks smoothly through a single convergedarchitecture. In addition, some end-to-end SIP services such as instantmessaging and file sharing can be offered.

In this deployment scenario, MSC Server provides SIP registrar and SIPproxy functionalities together with the integrated VoIP feature server functionality (Nokia VoIP Server in standalone mode). The main purposeof the integrated feature server is to offer the functionalities available in theexisting 2G/3G network also in the SIP domain. However, in the future





convergence can also be brought to the mobile and fixed networks by

introducing a complete SIP Execution Environment, by deploying the IPMultimedia Subsystem (IMS). This way not only voice services but alsoother SIP services such as instant messaging, conferencing, contentsharing and online multi-user gaming can be introduced together with theoverall SIP framework. It should be noted that even though the MSCServer is able to provide support for end-to-end SIP services, it does notutilise the intelligent service configurator (ISC) interface towards the thirdparty application servers such as PoC server or Presence server.

For more information on the SIP access interface and Nokia VoIP Server in standalone mode, see CS Core Voice Convergence in CS core systemdocumentation library.

5.3 Core and service interfaces

The following sections describe the interfaces of the CS core network.

SCP interfaces (CAP / INAP / MAP)

The CAMEL uses CAMEL Application Part (CAP) protocol between theService Control Point (SCP) and the MSC/MSS. CAMEL uses MAP

between SCP and HLR & MSC/MSS/VLR. Also Intelligent Network Application Protocol (INAP) can be used between these two networkelements. CAP is defined by 3GPP, whereas INAP is defined by ETSI.

The network elements support Nokia INAP protocol towards the IN/SCP.Siemens INAP (SINAP) support is planned to be available in MSS SR3.0A(M14.1) timeframe.

CS core interfaces

SMSC interface

The link between the MSC and the SMSC is implemented with MAP or X.25 OSI communications services and the Short Message Relay ServiceElement (SMRSE) application protocol on top of it.

Gf interface






The interface connecting the SGSN to the Equipment Identity Register

(EIR) is referred to as the Gf interface. It supports terminal authentication(not subscriber or SIM authentication). First, the SGSN may request theidentity check procedure from the MS using L3-SMM signalling. The MSthen sends its IMEI to the SGSN, and finally the Gf interface provides aprocedure, with which the SGSN can check whether the IMEI is valid. TheGf interface is based on MAP.

Gr interface

The interface between the SGSN and the Home Location Register (HLR)is called the Gr interface. Its main purpose is to provide the SGSN withaccess to the subscription information on the HLR. The Gr interface alsosupports mobility management in the sense that the new SGSN isindicated to the HLR during inter-SGSN routing area updates. The Gr interface is based on MAP.

Gs interface

The Gs interface links the SGSN's visiting subscriber database to the VLRin the MSS. The Gs enables optimised use of signalling in the radiointerface because it is possible to combine mobility management signallingfor the CS and the GPRS side. The benefits are inevitable when using aClass B mobile terminal which can be attached to the GPRS network andthe circuit switched network.

CS paging can be sent on GPRS paging or traffic channel. This makespossible that a mobile terminal needs to monitor only one channel.

IMSI attach/detach and GPRS attach/detach can be combined in the sameoperation.

The location area update and routing area update can be combined. Thelocation update is done to the SGSN and from there location information isconveyed to the MSS/VLR using the Gs interface.

The Gs uses the BSSAP+ protocol.

MAP-D interface

The MAP-D interface is between the HSS and the HLR. It providesauthentication vectors from the HLR to the HSS for subscribers usingUSIM (3GPP Rel-5 IMS subscription).

Interfaces of the MSC Server System

Nb reference point





The Nb reference point refers to the interface between two Multimedia

Gateways (MGWs) in the MSC Server environment, which can be basedon ATM, IP, or TDM technology.

In the case of ATM, the MGW for MSS utilises the AAL2 adaption layer for compressed speech and real-time data transport, and AAL5 for controldata transports.

If IP is chosen as the backbone technology, media over the IP backbone istransferred using the Real-Time Protocol (RTP). RTP provides end-to-enddelivery services for data with real-time characteristics, such as interactiveaudio.

The Multimedia Gateway provides the following options for transmittingmedia over the Nb reference point:

. Gigabit Ethernet (1G) interface

. Fast Ethernet (FE) interfaces

. STM-1 for AAL2 and AAL5 ATM traffic

. E1/T1/JT1 interface for TDM connections.

Nc reference point

Network-to-Network-based call control signalling is performed over the Ncinterface between the MSC Server and the GMSC Server.

The MSC Server supports BICC CS-2 as call control protocol. The use of BICC CS-2 is defined in 3GPP Rel-4. BICC is a call control protocoldesigned to transport call control signalling information, independent of theused bearer technology and signalling message transport technology.BICC accomplishes this by defining a set of procedures separately for callcontrol signalling and bearer control signalling. The actual call control levelsignalling uses BICC, which is based on ISUP, and allows different

protocols, such as AAL2 signalling, to be used for bearer control signalling.Since BICC is based on ISUP, it provides flexible interworking with ISUPand BICC networks and allows the existing supplementary services to beused without modifications.

In the MSS/GCS, Session Initiation Protocol (SIP) can be used as analternative call control protocol in IP-based networks. In the MSC Server,SIP is used as a tunnelling method for ISUP messages. The use of SIP isnot defined in 3GPP Rel-4 but the NSS implementation is done accordingto IETF specifications.






The main functionality of SIP is session initiation, including multiparty,

multimedia or gaming sessions. It can also be used for different purposes,such as instant Internet multimedia conferences, Internet telephone calls,and multimedia distribution. Its text-based nature provides flexibility byallowing the extension of the messages with additional header fields. SIPis supported between MSS and GCS if the core network is based on IPtransport. SIP for telephone (SIP-T) can also be used between MSCServers and it enables the use of, for example, the supplementary servicesoffered by today's ISDN networks.

Mc/Mn reference point

The Mc and Mn reference point in the 3GPP model describes the interfacebetween the MSS/GCS and the MGW.

The H.248/MEGACO protocol has been jointly developed within the ITU-Tand the IETF, and it supports a separation of call control entities frombearer control entities, and a separation of bearer control entities fromtransport entities. It is fully compliant with the H.248 standard work carriedout by the IETF MEGACO workgroup.

Currently, MSS System supports the Mc interface defined by the 3GPP. Also, the Call Bearer Control (ITU-T Q.1950) protocol is supported.

Mg/Mj reference point

The Mg and Mj reference point in the 3GPP model describes the interfacesthat are implemented between the MSS/kirslaikirGCS and the CSCF. Thisinterface allows signalling between MSS/GCS and the CSCF for thepurpose of interworking with PSTN networks. The protocol used in thisinterface is SIP.

ISC reference point

ISC reference point is the interface between Nokia VoIP Server (NVS) and

application servers for access to IMS services.

Mb reference point

Mb reference point defines the interface from IP Multimedia Gateway(MGW for IMS) towards the IMS, packet core and broadband accessnetworks. MGW for IMS carries the user plane in IMS. The functionality isimplemented in the MGW. Note that the same MGW can also serve asMGW for MSS.





In the Mb interface, the Internet Protocol (IP) is used as the network layer

protocol, and the connectionless User Datagram Protocol (UDP) as thetransport layer protocol. The encoded voice information (VoIP) is carried inRTP packets on top of the UDP/IP.

PSTN / ISDN interface

Signalling system No.7 (SS7) is a common channel signalling systemlinking the MSC to a PSTN or to an ISDN network. It uses a single channelto carry the signalling of multiple speech circuits. Channel AssociatedSignalling (CAS) is a digital signalling system used between exchanges.The traffic channel signalling is contained within the channel itself, or within another permanently associated signalling channel.

Specifications for SS7 and CAS signalling are often complemented byadditional requirements specific to different countries or operators. TheMSC supports several national versions of both SS7 and CAS.

5.4 Administrative interfaces

Network management system interfaces

The network management system has interfaces towards the MSC/MSSand the Home Location Register (HLR). IP Data Communication Network(DCN) is used for remote Operation and Maintenance (O&M) connectionsto an administrative computer or to Nokia NetAct network managementsystem. TCP/IP-based management, Telnet for remote access and FTPfor file transfer are used. OSI protocols can also be used; the MSC/ integrated MSS has a full implementation of the OSI stack. In addition,management applications in Network Element Management Unit (NEMU)communicate via Nokia RPC Solution Suite (NR2S) as interface of faultmanagement with the network management system. Note that NR2Sapplies to MSC/HLR NEMU only.

NetAct also has an interface towards the Multimedia Gateway (MGW) viaMGW NEMU. The most common management areas for elements includefault management, performance management and configurationmanagement. Both MSC/HLR NEMU and MGW NEMU use CORBA/IIOP,FTP and Telnet application layer protocols over TCP/IP networks.

IP-based management interfaces are available for all the networkelements. XML over HTTP -based interface is available. XML over HTTP -based interface supports XML format measurement reports only. Alsoother TCP/IP -based protocols can beused for management purposes. If the IP-based management interface is taken into use, also the data






communications network (DCN) for O&M must support IP protocols. As of

M12 release, all new measurement reports are in XML format, and fromM14 release onwards, the binary measurement reports are removed. CDSsupports XML over HTTP interface only.

Customer care and billing system (CCBS) interfaces

The Customer Care and Billing System (CCBS) has two interfaces: the BCinterface in the MSC and the AdC interface in the HLR.

The BC interface in the MSC uses FTAM, FTP and GTP' protocols for transferring charging data. The AdC interface in the HLR, on the other hand, uses Telnet, PAD and VTERM protocols/services.

IMS offline charging (Rf) interface

The Diameter interface (Rf interface) provides support for offline chargingin IMS. The offline charging transactions are sent using the Diameter Rf protocol. In case Nokia VoIP Server works as AS/MGCF for IMS, MSS hasCDF role and CDRs are generated in Charging Gateway (CGF). With thisinterface, charging information is transferred from the MGCF and NVS tothe Billing Center (or Charging Collection Function, CCF) for postprocessing.

Network Element Management Unit (NEMU) interface

The Network Element Management Unit (NEMU) is a computer unit thatprovides functions related to external O&M interfaces. The functionsinclude both generic interfacing to the data communications network andapplication-specific functions, for example, processing of fault andperformance management data of the MGW, and implementation of user interfaces and support for configuration management for all. This wayNEMU provides easy and flexible interfacing to the MSC, MSS, HLR andMGW. NEMU is an integrated part of the MGW. With the other networkelements it is optional.

NEMU uses TCP/IP and Ethernet to communicate with other units. Withthe MGW, for example, information on available statistic reports andalarms can be sent to the network management system through theCORBA interface. FTP is used to upload bulk data files.

For more information, see the section NEMU .





6 CS core network services andfunctionalities

6.1 Service capability in mobile networks

The 3G Circuit Switched (CS) core network supports the same basicfunctions as GSM. These functions are, for example, international roamingand mobility management, speech calls, short message services, data andtelefax calls. In addition, 3G provides higher data rates and enables moreapplications and services like multimedia calls and video streaming.

Some general service principles include:

. UMTS standardises service capabilities but not the servicesthemselves

. Virtual Home Environment (VHE): UMTS aims to provide the user with a set of services, features and tools, which have the same "lookand feel" whether they are used at home or abroad

. roaming between UMTS and GSM is supported as well ashandovers from one system to another.

Future 3G business will be centered around services and applications that

are trusted, location-aware, personalised, and always available and up-to-date. It is important to understand the end user needs and segments tocreate successful services that will generate new subscriber revenue.Nokia's leadership in terminals creates good ground for achieving thisgoal.

Today's evolution in mobile communication is towards rich content andsophisticated applications. By introducing service-aware enhancements tothe existing packet core networks, operators can charge differentiatedprices for data services - whether content to person, person to person, or for business connectivity.



CS core network services and functionalities



For more information on service continuity with roaming and handovers,

see Roaming and handovers in CS core network in CS core systemdocumentation library.

6.2 Licensing of features and functionalities

A licence is an agreement from the owner of a product that givespermission to use or produce the product according to the agreedconditions. The information key that enables the use of licenced softwareis called a licence key. Nokia Siemens Networks implements licence keysas Nokia Siemens Networks -specific licence files. Each licence file givesthe permission to use one or several features or functionalities in thespecified network elements. A licence file contains the information to whichnetwork element the licence is targeted. This is done using each networkelement's unique identifier which is called a target identifier. A licence filemay also define restrictions concerning the use of the licensed featuresand functionalities.

There are two types of licences: on/off and capacity.

. An on/off licence does not set any limit for the feature or functionality,the feature is simply either enabled or disabled.

. A capacity licence specifies the capacity value up to which thefunctionality is permitted. When you need to increase capacity, youcan order more capacity licences and install them in the networkelement. The total capacity available is summed up from theinstalled capacity licences and the possible basic capacity.

The capacity licence files for the same feature are called capacityincrements. In the figure below, there are two capacity increments for the example element, one increment having capacity value 20, andthe other with capacity value 30. Some basic capacity may existeven without a licence. In the example below, the element has basic

capacity value 10.





Figure 19. Increasing capacity with licence files

In addition, licence files may also be time-limited, which means that theycan have an expiration date. In practice, only licences meant for temporaryuse (for example, trial licences) are time-limited. Time-limited licenceshave predefined expiration date that cannot be changed.

Emergency licence is a special type of licence file which is reachable in

case of problems with licences or restructuring NW. The main differencebetween emergency licence (EME) and commercial licence file is that theEME licence does not contain NE specific targetID (C-number). It dependson the application whether the EME capacity licence contains unlimited or maximal capacity value reachable for the feature. It is a time-limitedlicence and has a very short validity, which is 10 days.

Licences can be added to live systems at any time when new features areneeded or more capacity is needed for existing features. Delivery of licence keys is independent of normal software delivery. This means thatlicence keys can be ordered and installed independently from releasesoftware or change delivery schedules as long as the base release thatmakes feature activation possible is installed. Adding licences does notinterfere with the normal operation of the NE. Licence files are generallyNE specific. This means that it is not possible to use licence files belongingto a certain NE in other NEs.

Capacity

Maximum capacity

Current capacity value 60

NetAct Cluster

20

30

Basic capacity

Current licensed capacity 50






6.2.1 SW licencing in MSC/MSS/HLR

In the early phases of licensing deployment, only selected capacities andsome of the optional features have licence control, but gradually thenumber of licence controlled features will increase. The licence keys areintroduced in the MSC, HLR, and MSC Server NEs as of the M13.1software release, where VLR subscriber capacity and HLR subscriber capacity are controlled by licence keys.

There are two main types of licences: capacity licences and ON/OFFlicences:

.

Capacity licence enables the use of certain feature with limited levelof capacity, for example, with VLR capacity for 100k subscribers.

Base capacity is a small capacity that is available in a NetworkElement (NE) for licence-controlled capacity features before anylicence keys are installed. Base capacity provides an easy testingand trialling possibility for new NEs when only very small capacitiesare needed and/or licence keys are not yet available. The amount of basic capacity depends on the functionality. Typically, when the firstcapacity licence is installed, it includes the basic capacity. However,not all functionalities have basic capacity.

Capacity licences are always NE specific and cannot be moved or transferred between NEs. One licence file is used for controlling onlyone type of capacity, for example, HLR and VLR subscriber capacity.Capacity licences are incremental, which means that the totalavailable capacity is the sum of the capacities of all those licencefiles that are addressed to the capacity. This makes it possible to addcapacity gradually. Each capacity licence has a minimum incrementthat is functionality-specific. The maximum increment is themaximum capacity that the NE software or hardware allows for thespecific functionality.

. ON/OFF licence is used for the activation of features or functionalities if there is no related capacity or there is no need for capacity limitation. ON/OFF licences activate a feature or functionality in one or several NEs. Compared to parameter-basedactivation, ON/OFF licence provides the possibility to order andactivate the feature only in those NEs where it is needed. ON/OFFlicence is used to replace the traditional parameter-controlled featureactivation for new features and selected existing features.





The DX200 licence management platform provides an MML user interface

for licence and feature handling. You can install and update licences in thenetwork element, activate and deactivate licensed functionalities andcheck their activation status by using MML commands. For moreinformation on the licencing of features and licence management, see M-release product and feature documentation.

6.2.2 SW licencing in MGW

Some of the MGW functionalities are optional. The licence-based featuresrequire the purchase and installation of a SW licence. You can install andupdate licences in the network element, activate and deactivate licensedoptional MGW functionalities and check their activation status by usingMML commands.

There are two main types of licences: capacity licences and ON/OFFlicences:

. SW licence -based MGW Connection and Port capacity means apossibility to purchase MGW call throughput (connection) andinterface (port) capacity according to operator needs independentlyof the HW capacity. This enables to minimise the HW delivery andimplementation costs, because the HW capacity can be purchased

in bigger steps, and call throughput and interface capacity byrequired size of the SW licence. All interfaces do not have a SWlicence. A SW licence key is required for MGW connection capacity, Ater interface, Iu-CS (3G) interface, IP backbone (Nb) interface, andIP access (Mb) interface. A basic capacity for a hundred calls isprovided without SW licence with MGW connection capacity. Theinterface capacity always needs a SW licence key.

. ON/OFF licence is used for the activation of features or functionalities if there is no related capacity or there is no need for capacity limitation. ON/OFF licences activate a feature or functionality in one or several NEs. Compared to parameter-basedactivation, ON/OFF licence provides the possibility to order andactivate the feature only in those NEs where it is needed. ON/OFFlicence is used to replace the traditional parameter-controlled featureactivation for new features and selected existing features.

For more information on the licensed optional MGW features and MGWconnection and port capacity licencing, see MGW Functional Description and MGW Configuration Data Management in the U-release productdocumentation.






6.2.3 Licence management tools

There are three applications involved in licensing: Nokia LicenceGenerator, Network Licence Manager, and element managers of networkelements:

. Nokia Licence Generator is used for retrieving the licences fromNokia Siemens Networks.

You can order licences from Nokia Siemens Networks as any other functionality. In the customer order, you can define the functionality(feature) and the needed capacity. After the order has been placed,

you can retrieve the licences from the Nokia Licence Generator. TheNokia Licence Generator also takes part in the pool licencesubstitute process by generating a Substitute permission file basedon the approved or rejected licence substitute requests.

You can access the Nokia Licence Generator in Nokia OnlineServices (NOLS) at http://www.online.nokia.com.

. Network Licence Manager and element managers are used tomanage licences and run reports in the network.

Network Licence Manager helps you to deliver correct licences tovarious network elements. Network Licence Manager can be usedfor importing licences to NetAct, distributing licences to networkelements, setting feature state, synchronising licence and featureinformation in NetAct database, deleting licences and substitutingpool licences.

Network Licence Manager supports the following CS core networkelements: MSC, MSS, HLR and MGW.

6.3 Circuit switched data services

In MSC Server network, circuit switched (CS) data will play an importantrole even though the use of the GSM-based CS data is anticipated todecrease as the GPRS-based data services start to gain more importance.MSC Server (MSS) network supports CS data by providing theinterworking functionality (IWF) either integrated in the MSS or in aseparate Circuit Switched Data Server ( CDS ). In the Integrated MSS,which is upgraded from an existing MSCi, it is customary to use the IWFthat is available in the upgraded network element. In a standalone MSS it





is possible to use the CDS to provide the IWF via the MGW. The CDS

provides the same interworking functionality as the integrated IWF. It islogically a part of the MGW user plane even though it is a separatenetwork element.

The functions of the CDS depend on the services and the type of the fixednetwork. The CDS is required to convert the protocols used in the PLMN tothose used in the appropriate fixed network. The CDS is not used whenthe service implementation in the PLMN is directly compatible with that inthe fixed network (for example, 56/64 kbit/s transparent data services).The typical services requiring the use of interworking functionality are:

. Non-transparent asynchronous bearer services

. Transparent synchronous bearer services requiring rate adaptation

. Transparent facsimile group 3 teleservice

. High Speed Circuit Switched (HSCSD) data services

. 14.4 kbit/s data traffic channel

. V.42bis data compression and compression on V.120

. Asymmetric data connection

. H.324/M multimedia modem calls

. Data call handovers between 3G and 2G

The Interworking functionality is not used with the following services:

. 32kbit/s transparent data service (rate adaptation in MGW)

. 56/64 kbit/s transparent data services

. H.324/M multimedia UDI/RDI calls

For more information on the Circuit Switched Data Server, see the M-release product documentation library.

3G CS Multimedia Solution

CS video telephony is one of the new 3G services that can be definedmore broadly as 3G CS multimedia. As a service, 3G CS video telephonyprovides a direct continuation to mobile voice telephony as the video call ismade by dialling the other user ’s phone number. 3G CS video telephonycomplies with the 3GPP R99 technical specification for 3G-324M which isbased on ITU H.324/M standard. 3G-324M video telephony relies on thegeneric UMTS circuit switched synchronous, transparent data service.






In the currently available WCDMA terminals, person-to-person video

telephony, if supported, is based on circuit switched 3G-324M standard.The SIP-based IP Multimedia Subsystem (IMS) realises similar videotelephony (conversational IMS) in the packet switched domain.

During the WCDMA introduction phase, the number of 3G-324M users willbe relatively small while there are already hundreds of millions of H.323and SIP clients in PCs and dedicated IP videophones in the public Internetand private intranets. In the 3G CS Multimedia Solution, the interworkingbetween 3G-324M, H.323, SIP, H.320 and IMS is implemented by thirdparty gateway products which gives 3G-324M users immediateconnectivity to numerous IP/ISDN multimedia users. Streaming over 3G-324M enables streaming to those 3G terminals that do not have a PSstreaming agent, but support 3G-324M.

In 3G-324M and SIP (RTP) based video interworking, the MSS/GCS/NVSonly identifies the call type based on Session Description Protocol (SDP)content included in the SIP message, goes to the CMN mode and routesthe call to 3rd party video gateway. For more information, see NVS in Application Server mode in CS Core Voice Convergence provided in CSCore System Documentation library.

3G CS multimedia enables a range of visual real-time applicationsincluding broadcasting, remote learning and surveillance by using 3G-

324M phones or web cams connected to PCs. Time-to-market of a newservice is a critical factor for 3G operators in the highly competitive market.The benefits of 3G CS multimedia are that it is real-time by nature, it isalready available, and a large number of users and services already existsin the Internet, intranets and ISDN to which both business and private 3Gusers need to connect.

Functionality of 3G CS Multimedia

Video telephony requires constant bit rate, small delay variation andcontinuous bit flow. Therefore, a synchronous transparent data bearer hasto be used. The 3G CS Multimedia solution uses transparent bearer service BS30 with a parameter indicating that the application ismultimedia. In UMTS access, Nokia MSC and MSC Server (MSS) provideUDI 64 kbit/s and RDI 56 kbit/s for 3G-324M multimedia calls for whichIWF resources are not required in the MSC or MSS. Currently most 3G-324M terminals use the 64 kb/s bearer.

Interworking between 3G CS multimedia and H.324/I is supported so thatno video gateway is needed when using these protocols.

The figure below presents UE-to-UE and UE to and from ISDN (H.324/I)3G CS video calls.





Figure 20. 3G-324M call in 3G and to/from ISDN (H.324/I)

3G-324M interworking with IMS and non-3GPP networks is currently beingspecified by 3GPP. The 3G CS Multimedia Solution supports them byusing an external video gateway.

6.4 Voice services

Voice services for circuit switched networks provide features enabling theend user to control calls in several new ways that have not been possible

before. The value of voice telephony to end users is increased bypersonalisation (Selective ringback tone), improved reachability (MultiSIM,SMS forwarding) and improved awareness (Missed calls log). It aims atmaximising achievable market through interoperability with the existingphones and provides new revenue for operators and service providers byincreasing the usage of voice and SMS services.

Voice services include the following end user services:

RAN RAN

MSC MSC

ISDNswitch

Circuit switchedmobile core

network

IWF notneeded

H.324/Ivideophone

3G-324M3G-324M

3G-324M over 64 kbit/s synchronous, transparent bearer






. Selective Ringback Tone (SRBT) is a called party service/feature

that allows the calling party to hear a customised ringback tone whilethe called party is alerting. That is, instead of the standard ringbacktone, the calling party will hear a melody or a greeting specified bythe called party while waiting for the called party to answer. Thecalled party can select a melody or a greeting based on the callingparty's identity (for example, Calling Line Identity, CLI).

. Missed Calls Log (MCL) stores information on all those calls thatcannot be delivered to the subscriber, for example, in a case whenthe user is not reachable or calls are being forwarded, and thendeliver that information to the user later as a log file. The Missedcalls log contains information on the calling party and time of call and

notifies when the call was forwarded to the voice mail.. MultiSIM service provides the possibility to have more than one SIM

card (max. five) to be addressed with a single MSISDN. This featureis very useful for those users who use two or more terminals daily asit removes the need to change SIM cards from one equipment toanother.

. SMS forwarding enables the end user to forward short messagesfrom one mobile to another. Earlier forwarding has been possible for voice calls only.

Speech transcodecs

MGW supports a wide range of speech transcodecs. For both NVS andPS-CS interworking scenarios, they include AMR-WB, VoIP codecsG.729a/b, G.723.1, and iLBC. For more information about speech codecsand payload formats supported by MGW in different interfaces, seeFunctional Description for MGW , available in U-release productdocumentation.

6.5 Location based services

Location based services (LCS) do not form a separate applicationcategory of their own. Instead, location-awareness is a capability that willbe made available to any application. Applications like games, mobile chatand mCommerce, among others, can be location-dependent. Operatorscan earn location-specific advertising revenue because they know theuser's location, personal profile information or segmented channel. Pushadvertisements can be subscription-based so that the mobile user canindicate to the operator the information he is interested in - a personalprofile, that is. The operator can thus send location-relevant messagesbased on user search or advertising.





Subscriber's location information enables the operator or service provider

to offer services based on the position information. These services areindependent of the network type used (GSM, GPRS or 3G). Therefore theNokia Siemens Networks' solution supports location-based GSM servicesin both GSM and 3G. Location-based services are supported in bothaccess networks, GSM/EDGE BSS and WCDMA RAN, and there is avariety of services available, stretching from navigation applications,safety and emergency applications (emergency calls), trackingapplications, and information service applications, to operator and trafficapplications. For more information on the location methods and locationbased services, see, for example, M-release product documentation,GSM/EDGE BSS System Documentation or WCDMA RAN SystemDocumentation.

6.6 IN services

For operation in the IN environment the MSCi and MSS include theService Switching Point (SSP) function. The openness of the IN concept isensured by implementing the SSP - SCP (Service Control Point) interfaceusing guidelines stated in core INAP and CAMEL protocols. The use of theBasic Call State Models provides the operators with an efficient way of offering IN services for call-associated transactions.

The IN concept is applied also to the non-call associated transactions. TheState Models defined for these transactions provide the operator triggeringpoints where the control has been moved from the MSCi/MSS to the SCP.Based on this, operator-specific services can be generated in the SCP.This non-call associated IN is applied to location registration, mobilitymanagement and supplementary service invocation procedures, and tothe short message handling.

The SSP supports CAMEL phase 4 (and all previous CAMEL phases) andcore INAP CS-1.

Siemens INAP (SINAP) support is planned to be available in MSS SR3.0A(M14.1) timeframe.

6.7 Text telephony service for 3G calls in MGW






TTY is a functionality that enables text-based communication over a

speech bearer. It is mainly intended for people with impaired hearing or speech. The feature is specified by ITU-T, and it is a regulatoryrequirement in the USA for emergency calls. However, TTY is not only for US emergency calls, as it can be used worldwide for ordinary callsbetween persons who require the use of text telephony.

Figure 21. 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! Ho Hello Mary!

Hello Brian! How are...

TELEPHONENETWORK

a





Reliability is achieved by an improved modulation technique, including

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

CTM Adaptor

CTM TTY signalling

Traditional ITU-TV.18 TTY signalling

HLR

MGW

BSC&TC

RNC MGW

BICC CS-2, SIP-T,ISUP

Iu-CS

MSCServer

H.248

Other PLMN

PSTN/ISDNH.248

A

A

IP/ATM/TDMBackbone

WCDMA

GSMMobile TTYterminal

FixedTTY

terminal

GatewayControlServer

BSC

IMS

Ater





6.8 TrFO in MGW

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

switched 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 8. TrFO compatible codecs and codec configurations

Codec typeandcompatibility

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

HR x

G.711 x

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

G.723.1 x

G.723.1 +

Annex A (dtx) 3)

x

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

Figure 23. 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 interworking cases.

6.9 2G TFO in MGW

Tandem free operation (TFO) is a mechanism which can be used in-bandto determine the speech codecs used on the transcoders in a call. If compatible codecs are used, the transcoders start embedding theencoded speech parameters in the least-significant bits of 64 kbit/s link.Nokia MGW supports TFO for GSM FR and GSM EFR speech codecs,thus providing optimised inter-operability with legacy GSM networks.

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






MGW also uses TFO for optimising the bandwidth needed per call. The

basic intention is to relay the access side codec unchanged through the IPor ATM backbone towards another MGW.

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

Figure 24. 2G Tandem Free Operation

Functionality

TFO with the payload optimisation functionality in MGW includes

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

. operating in a codec relay mode (passing speech samplestransparently without transcoding)

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

MGW STRIPSTHE ’UNNECESSARY’BITS AWAY

MSS MSS

IP/ATM networkBSC BSC

MGW MGW

TC TC

CODEC NEGOTIATION

TRANSPARENT COMPRESSED SPEECH CONNECTION

TFOPEER

A A

CODEC

TFOPEER

TFO ENABLEDBY FIFILE

CODECCODEC INTFO FRAMING

CODEC ONLYOVER IP/ATM

INBAND TFONEGOTIATION

INBAND TFONEGOTIATION

TRANSMISSION SAVINGSDUE TO COMPRESSED CODEC





As regards the benefits, TFO provides optimised speech quality.

Traditionally, a compressed speech codec used in radio interface istranscoded to the G.711 codec when connected to core network, whichdecreases speech quality. With IP/ATM Trunk, the intention is to agree ona common codec for all the call legs, and disable/bypass the transcodingstages from the speech path. The transcoding is needed when the call isrouted to the PSTN.

6.10 Performance management in CS core network

Performance Management (PM) is part of the network data managementprocess defined in the Telecom Operations Map (TOM). The purpose of this process is to provide sufficient and relevant information to verifycompliance and noncompliance to Service Level Agreements (SLA) andQuality of Service (QoS) levels. Monitoring specifications must translateservice requirements into what needs to be monitored in the network. Theaim of the process is to ensure that the network performance goals aretracked and that notification is provided when the goals are not met. Thisincludes thresholds and specific requirements for usage collection or recording. This also includes monitoring for capacity, utilisation, traffic, andusage collection.

The figure below shows the network data management process inputs andoutputs.






Figure 25. Network data management process (by TOM)

For more information, see Telecom Operations Map, GB910 ApprovedVersion 2.1, TeleManagement Forum 2000.

TOM offers a framework for Nokia Siemens Networks ’ PM tooldevelopment. Nokia Siemens Networks does not follow the TOM modeldirectly, but some NetAct tools support it.

PM gives information on and supports the following:

. system stability and troubleshooting

. network balancing, planning and optimising

INPUTS OUTPUTS

Network Data Management Process

Performance UsageData Requests

Performance Goals

Start/StopMonitoringNetwork

provisioning

NetworkInventoryManagement

Performance/ UsageData Requests

Usage/ Performance

Data

Network Performance andConfirmation Data

Usage informationService QualityManagement

NetworkPlanning andDevelopment

Start/StopMonitoring

ElementManagement

Customer QoSManagement

Network Usage/Performance Trends

Network Usage/

Performance Trends

Other Provider(s)

Rating andDiscounting

Other Provider(s)

Service QualityManagement

NetworkMaintenanceand Restoration

NetworkPlanning andDevelopment

Networkprovisioning

ElementManagement

Performance Degradation

Capacity/ Performance Data

Network Changes

Performance/Usage DataRequests

Network DataManagement

- Collect, correlate, and format of usagedata/events

- Determine performance in terms of capacity, utilization, and traffic

- Provide notification of performance degradation

- Initiate traffic control functions





. service usage

. SLA reporting

With PM the network operator can take the cost factor into account. Thenetwork operator needs to balance costs and performance goals.

Performance Management terminology

The main concept in Performance Management (PM) is the PerformanceIndicator (PI). Information from PIs can be distilled into Key PerformanceIndicators (KPIs). KPIs are the most important indicators of networkperformance. The KPIs created and implemented at Nokia Siemens

Networks get their requirements from various sources such astelecommunication standards, network operators or Nokia SiemensNetworks' network planning personnel.

There are also measurements, observations and supervisions for monitoring the network operations. The network operators can select anddefine the PIs, KPIs, measurements, observations and supervisions thatthey want to use. The definitions of the central PM concepts are presentedbelow.

Performance Indicator (PI)

Metric that gives information on the performance of anetwork element, process, or function, on networkelement or network subsystem level.

Key Performance Indicator (KPI)Selected performance indicator that is a crucial

performance metric. KPIs provide information on theavailability of service, volume of service, and qualityof service, for example. The KPIs give informationabout the performance status on many levels, for example, interface, network element, domain(subsystem), or system-wide.

Measurement The system collects information on the traffic andnetwork events in the exchange and then processesthis information. The system produces reports on thebasis of the information. A measurement gives aresult in agreed units, for example in erlangs.

Observation The system either collects information on certainevents or directly produces information on singleevents in the system. It is possible to set certainobjects under observation on a detailed level, and toset conditions which must be fulfilled before thesystem produces reports or alarms related to the

events of objects under observation.






Supervision The system collects information on call traffic or

certain events in the exchange and then processesthis information (equal to the concept of measurement). In addition to this, it is possible to setconditions which must be fulfilled before the systemproduces reports or alarms.

File Transfer, Access and Management (FTAM)Service element of the Open Systems

Interconnection (OSI) model application layer thatoffers services for file transfer, access andmanagement independent of the system.

File Transfer Protocol (FTP)

Application protocol, part of the TCP/IP protocolsuite, used for transferring files between networknodes.

Hypertext Transfer Protocol (HTTP)Protocol utilising the TCP/IP which enables the

transfer of HTML files. HTTP is used in web services.Simple Network Management Protocol (SNMP)

Network management protocol which primarilydefines the functions of network managementsoftware and describes the way in which a report hasbeen defined and sent.

XML over HTTP (XoH)Network management interface protocol, used with

NSS/MSS NEs and Nokia NetAct when the datacommunication network (DCN) is IP-based.

6.10.1 PM data handling in circuit switched core

Nokia Siemens Networks' core network elements are designed to collectstatistical information actively. This means that once the data collectiondetails have been defined in the network element, the network elementtakes care of collecting and storing data. The data is then transferred fromthe network elements into the Nokia NetAct. The automation of the basicfunctions enables the network operator to concentrate on the data analysiswork.

Statistical reports of Mobile Switching Centre (MSC)/MSC Server (MSS)/ Home Location Register (HLR) measurements, observations andsupervisions can be produced in XML or ASCII output formats. Reports of Circuit Switched Data Server (CDS) measurements can be produced inXML or ASCII formats.





ASCII reports are intended to be printed out on a printer or displayed on

screen. XML reports are typically transferred for post-processing in theNokia NetAct.

Separate logical files are provided within the MSC/MSS/HLR and CDS for the different report types and output formats. Logical files are records inthe memory of the computer used to route reading and writing tasks to I/Odevices. Logical files for reports must be redirected, which means thateach logical file must be connected to a defined printing or storing device.The output of XML, using OMeS (Open Measurement Standard), can berouted towards the Nokia NetAct for external post-processing. To do this,data communication network (DCN) integration has to be completed.

Multimedia Gateway (MGW) provides statistical data related to the usageof external interfaces, in other words, Time-Division Multiplexing (TDM), Asynchronous Transfer Mode (ATM) and IP resources. It also providesstatistical data related to the usage of MGW internal resources. Single call-related statistical data is collected in the MSS. MGW measurement reportsare transferred to the Nokia NetAct for post-processing. Data is also keptin the Network Element Management Unit (NEMU) database for sometime and it can be browsed using the NE Measurement Explorer.

For more information, see:

. The NSS Statistics, Advanced Guide document describes MSC/ MSS/HLR statistical functions, measurements and observations inrelation to network functionality and gives details on data providedby statistics. Moreover, the examples illustrate what the reports looklike when a certain operation takes place in the network. Detaileddescription of the content of the reports can be found in the NSS Statistics, Reports documents. Detailed instructions on themanagement of the functions (start, stop and interrogatemeasurements, handle object lists, for example) are provided in theNSS Statistics document. See M-release product documentation.

. Detailed instructions on the management of the functions (handlingmeasurements and object lists, for example) are provided in theMGW performance management and measurement managementdocumentation. Detailed descriptions of the content of MGW reportscan be found in the MGW counter documentation. See U-releaseproduct documentation.

. The main sources of counter information are the performancemonitoring documents available in the network element productdocumentation library. However, these documents cannot beupdated immediately after each counter improvement action. The






purpose of the Reference Information Service (RISE) is to bring the

latest counter information immediately available to the customers.RISE can be found under Nokia Online Services → Documentation→ Reference Information.

6.10.2 Nokia Siemens Networks Performance Management Classes

Nokia Siemens Networks Performance Management Classes is a detailedsystem for grouping Performance Management (PM) reports under functionalities, for example mobility, resource and charging. The purposeof the PM classification is to help the network operators in the dataanalysis phase of PM. The PM classification is used throughout the datacollection and analysis process: the PM classes are applied to singlePerformance Indicators (PI) and Key Performance Indicators (KPI), whichare then connected to reporting tools that use the PM classes in thereports. Quality aspect is part of all individual classes.

The main benefits of the Nokia Siemens Networks PM classification arethe following:

. It is easy to identify a KPI for a certain problem area.

. It is easy to understand the meaning of a KPI.

The Nokia Siemens Networks PM classification is briefly described in tablebelow:

Table 9. Nokia Siemens Networks Performance Management Classes andexamples of measured performance

Nokia Siemens Networks PM class Examples of measuredperformance

Mobility Handovers, roaming, paging, attach/

detach and location updates.Traffic Connection, throughput of calls and

packet data.

Resource Availability and usage rate of the networkresources.

Security Ciphering.

Services Circuit switched (CS) and packet switched(PS) bearer services, teleservices andsupplementary services; IP MultimediaSubsystem SIP services.





Table 9. Nokia Siemens Networks Performance Management Classes andexamples of measured performance (cont.)

Nokia Siemens Networks PM class Examples of measuredperformance

System Stability General system and network elementstability issues.

Charging Charging data generation, transfer, hotbilling.

Subscriber Registration, subscriber-related volumes,subscription, provisioning, withdrawal.

6.11 QoS in the MSS System

The term Circuit Switched (CS) core has been used to cover “traditional ”

circuit switched (TDM-based) services such as CS voice and data calls.Today the term, however, includes a versatile combination of circuitswitched (TDM) and packet switched (IP/ATM) technologies whenproviding end-to-end services.

The TDM-based PSTN network provides high and constant service quality.In mobile networks the Quality of Service (QoS) can vary because of morecomplex call handling procedures and the radio interface. In the radiointerface, QoS refers to the optimisation of coverage, radio capacity andservice quality.

In the rapidly increasing IP-based networks the QoS can vary a lotespecially with real-time services (such as voice and multimedia calls)because IP transmission was originally designed for non-real timeservices. Different IP QoS mechanisms have been developed andstandardised to guarantee the required service quality in IP networks.

The packet-based ATM also provides varying QoS. Its QoS mechanisms,however, make sure that an acceptable service quality can be providedalso for real-time services. In some cases CS services are transmitted withan IP over ATM solution, which requires both IP and ATM QoSmechanisms.

In addition, the convergence of the traditional CS networks and new IP-based packet network such as IP Multimedia Subsystem (IMS) will presentnew challenges to end-to-end QoS.






There are some standard end-to-end QoS requirements for delay and

packet loss, but no end-to-end mechanism for the CS core services exists.Neither is there a QoS solution for the converged CS and PS networks.The 3GPP end-to-end Quality of Service concept and architecturespecified in TS 23.107 and 23.207 focuses on PS services only.

The ITU-T G.114 and 3GPP TS 22.105 specifications state the end-to-enddelay as preferred below 150 ms and at maximum 400 ms. Based onNokia Siemens Networks' QoS verification, the 150 ms that requirement isnot realistic with mobile-mobile calls, because the GSM and 3G radioaccess itself take about 80-100 ms delay per access, meaning that about160-200 ms delay with mobile-mobile calls comes from the radiointerface. The CS core delay comes from MGW processing delay, IP/ATMtransmission delay and IP/ATM Jitter buffering delay that depends on IP/ ATM network implementation by operator. MGW default Jitter buffer sizefor IP is 30 ms and 15 ms for ATM.

The 3GPP TS 22.105 state the maximum end-to-end packet loss 3% for audio and 1 % for video call. The packet loss can happen in GSM access(FER), in 3G access (BLER), in ATM transmission (Cell loss) and in IPtransmission (packet loss). Nokia Siemens Networks' recomendation is atmaximum 1% FER/BLER in radio access and at maximum 1 % packetloss/cell loss in IP/ATM backbone.

Furthermore, there is no universal definition for the term Quality of Service(QoS). Different QoS functionalities, parameters and requirements arerelated to non-real-time services (messaging, for example) and real-timeservices (such as voice calls). The QoS Forum has proposed the followinggeneral definition of QoS: "Quality of Service is a mechanism that providesa level of assurance ensuring that a service or application can be deliveredto the end-user in a satisfactory time frame and way".

From network point of view, the easiest way to provide good service qualityis to ensure that the required bandwidth and network resources areavailable to users at all times. However, this is not possible because each

network has a maximum capacity. Naturally, additional bandwidth can becreated through additional investments, but the real challenge is tomanage the available network bandwidth and resources in such a way thata required service quality can be provided with minimised networkinvestments. A specific challenge is the optimised usage of the ATM or IPbackbone, especially when different traffic types are routed via the sameIP network. QoS mechanisms do not create additional bandwidth but allowthe existing bandwidth to be managed and utilised efficiently to transportspeech and data packets through the network with required service quality(that is, with predictable delay, jitter and packet loss rates).





The CS core network provides two basic services: CS voice and CS data.

They can be routed via one MGW or two MGWs over TDM/ATM/IPbackbone.

CS Voice

CS voice service refers to normal voice connections such as:

. 3G - 3G call

. 3G - GSM call

. 3G - PSTN call

. GSM - GSM call

. GSM - PSTN call

. PSTN - PSTN call

Furthermore, the PSTN, GSM and 3G interworking with IMS SIP terminals,UMA terminals and LAN/xDSL PC clients is possible with the MSS.

CS Data

CS data service can be used for different applications such as:

. 3G - 3G multimedia call

. 3G - Video Gateway call (SIP endpoint, Video mailbox, Netmeeting/ H.324M)

. 2G/3G - Access Server/IP/FTP Server

. GSM Fax - PSTN Fax (via IWF)

. 3G Fax - PSTN Fax (Store and Forward Fax)

. 3G - Access Server/IP/Mail (FAX retrieval, for example)

. GSM - PSTN UDI/modem call

. 3G - PSTN UDI/modem call

QoS Parameters

The area of Quality of Service (QoS) comes very close to systemperformance and vice versa. The parameters listed below may be relevantwhen handling, measuring and evaluating the end-to-end CS core QoS:






. Call setup time

. Call success rate

. Speech quality

. Video quality

. Latency (delay)

. Data transmission quality

. Handover quality

. Packet loss

. Jitter

Factors affecting QoS

There are several factors affecting the end-to-end QoS:

Factors affecting call setup time

. network response delay

. ciphering

. authentication

. paging

. HLR request

. signalling delay

. network resource allocation (radio and core networks)

. network throughput capacity

. radio and backbone capacity and QoS configuration

. end user terminal

. 3G Signalling Bearer Bitrate (SBR).

Factors affecting call success rate

. signalling success/errors

. coverage

. Radio Access Network (RAN), core and backbone reliability

.

handover success/errors





. traffic load

. network throughput capacity

. radio and IP/ATM backbone capacity and QoS configuration.

Factors affecting speech quality

. coding quality (the speech codec being used)

. transcoding needs (from one codec to another)

. Base Station Subsystem (BSS) configuration (TFO, DTX, TC)

.

RAN QoS configuration (TrFO, DTX). bad speech frames from the air interface

. echo and echo cancellers

. speech level and distortion due to possible saturation clipping

. network throughput capacity (network configuration/planning/ routing)

. radio and IP/ATM backbone capacity and QoS configuration

. speech latency (delay)

. jitter (delay variation)

. jitter buffer size

. packet sequency errors

. packet/cell loss

. end user terminal.

Sources of end-to-end speech delay

. codec delay (encoding/decoding)

. transcoding delay

. radio access delay

. packetisation delay

. buffering delay

. network transmission delay

. network throughput capacity.






Features affecting end-to-end QoS

. Codecs and speech transcoding

. Discontinuous Transmission (DTX)

. Frequency Hopping (FH)

. Tandem Free Operation (TFO)

. Transcoder Free Operation (TrFO)

. Echo Cancellation (EC)

. Automatic Level Control (ALC)

. Acoustic Echo Cancellation (AEC)

. Noise Suppression (NS)

. Handovers

ATM QoS

ATM technology is used with the MGW Iu-CS interface and ATM-basedbackbone. The ATM has well-established mechanisms for QoSprovisioning.

The PVCs are used in the Multimedia Gateway (MGW) enabling therequired QoS for real-time voice and data calls.

MGW supports the following ATM service categories:

. Constant Bit Rate (CBR)

. Unspecified Bit Rate (UBR)

The CBR service category specifies a fixed bit rate. In the Nokia SiemensNetworks' MSS System, the CBR is used in the MGW for the control planeand signalling traffic that require high service quality.

The Unspecified Bit Rate (UBR) service category provides Best Effort (BE)service. UBR is planned for non-real time Operation and Maintenance(O&M) traffic when O&M actions need to be performed with an IP over ATM connection. O&M traffic can also use a CBR configuration, if necessary.

The user plane traffic between the RNC and MGW over ATM backboneuses AAL2 adaptation. The related VC connections are CBR connections.Signalling traffic uses AAL5 adaptation.





MGW provides a dynamic jitter buffer with a configurable target fill level for

the elimination of possible jitter in ATM transmission.IP QoS

Primarily the IP network provides best effort service in which the traffic isprocessed as quickly as possible with minimal performance guaranteeswith regard to timelines or actual delivery.

The Nokia Siemens Networks' MSS System uses DiffServ to prioritise theCircuit Switched (CS) traffic routed over the IP backbone. However, thefinal throughput and quality of the IP transmission depends on the trafficload, IP network capacity and QoS configuration because DiffServ doesnot provide any reservation messages and there are no guaranteed end-to-end flows.

The MSS has a freely configurable DSCP parameter for signalling (H.248and SIGTRAN) and user plane (RTP) traffic. The Best Effort (BE) DSCP isused with O&M traffic.

MGW provides a dynamic jitter buffer for user plane traffic (RTP) with aconfigurable target fill for the elimination of possible jitter in the IPbackbone.

Versatile RTP and IP traffic statistics such as sent, received and lostpackets, are provided in the MGW with configurable metering periods.

In the IP backbone, routers can utilise DSCP in traditional trafficprioritisation or in MPLS path connections if MPLS is supported and used.

The IP Connection Admission Control (IP CAC) optional functionality inMGW helps to avoid IP network overload and ensure stable speech qualityby enabling to set a maximum limit for IP traffic load from MGW to theexternal IP network. The maximum number of the allowed IP terminationscan be freely configured by the operator in each MGW.

QoS in converged networks

MSC Server (MSS) System Release 3.0 includes the following mainconvergence solutions:

. Nokia VoIP Server (NVS) in standalone mode

. MSC Server interworking with IP multimedia.






The requirements for end-to-end delay (400 ms at the most) and packet

loss (3% for audio at the most) specified in the ITU-T G.114 and 3GPP TS22.105 are also considered when implementing the converged networks.

There are no standardised requirements for setup times, delay or speech/ video quality.

For more information on QoS in CS core network , see the description inCS core system documentation library.

It is not possible to measure QoS performance of CS core networkseparately. QoS performance can be measured on end-to-end levelincluding also GSM, 3G, PSTN and SIP accesses. Nokia SiemensNetworks is measuring end-to-end QoS performance for different callcases and codec combinations of the Set-up time, Latency (Delay) andObjective speech quality parameters based on Nokia Siemens Networks'CS core laboratory network with NSN BSS, RAN, PSTN and SIPaccesses. The Objective speech quality is measured according to ITU-TP.862.1 PESQ-LQO standard.

6.12 Roaming and handovers in CS core network

The evolution of GSM networks towards 3G networks has brought about alarge variety of roaming and handover scenarios. A seamless integrationbetween GSM and 3G needs to be ensured so that the end user experiences no disruption in service. The Nokia Siemens Networkssolution maximises the operator ’s end-to-end Quality of Service (QoS) byproviding seamless service, regardless of the network or technology. Thisis achieved by providing standardised open interfaces and solutions for multivendor environments in GSM and 3G. In addition, Nokia SiemensNetworks is actively driving interoperability testing with all major networkvendors in the Interoperability Testing (IOT) Forum and in various operator networks.

Traffic balancing between GSM and 3G is an important issue for mostoperators. To optimise the existing GSM investments while facilitating asmooth 3G roll-out, it is essential that the operator can control which radioaccess network the subscribers can use. This includes the possibility torestrict subscribers' access between GSM and 3G systems as well asprovisioning individual rights for national and international roaming.





Network convergence

The range of roaming and handover scenarios is further diversified bynetwork convergence that introduces new access methods, eventuallyconverging the existing circuit and packet switched core networks into asingle unified network.

For example, Nokia Siemens Networks offers the possibility to integrate aSession Initiation Protocol (SIP) access interface into the MSC Server.With SIP access, the operators can introduce Voice over IP (VoIP) andalso provide messaging interworking between the SIP and GSM/3G shortmessage service smoothly through a single converged architecture.

The Nokia MSC Server (MSS) can be upgraded to a Nokia VoIP Server (NVS) that enables the provision of GSM-like services for fixed and mobileVoIP end-users. Both SIP access and NVS are designed to provide CircuitSwitched (CS) capabilities for SIP subscribers that have been registeredeither to the integrated SIP registrar of the MSC Server directly or throughthe IP Multimedia Subsystem (IMS) machinery. For more information onthe effects of SIP access and NVS on roaming, see Roaming in converged network .

For more information on voice convergence in CS core network , see CS Core Voice Convergence in CS core system documentation library.

Roaming in CS core network

Roaming means that the subscriber can make and receive calls on other operators' networks when outside their Home Public Land Mobile Network(HPLMN) coverage area. Nokia Siemens Networks' CS core networksupports both national and international roaming as defined in 3GPPspecifications. Therefore, GSM and 3G subscribers from other networkscan roam to the operator ’s network when appropriate roamingconfigurations between the networks have been made.

While roaming within a 3G coverage area, all GSM and 3G services areavailable to the subscriber. When the subscriber roams from a 3G to aGSM coverage area, the services available are the ones that the GSMradio access can support.

The NVS eliminates the need for roaming configurations for VoIPcustomers.

For more information on controlling network access, see section Roaming .






Handovers in CS core network

Handover (HO) means the procedure in which, for example, the trafficchannel carrying the call has to be switched to another selected by theBSC or the RNC. The purpose of a handover is to determine the mostsuitable radio path allocation throughout the duration of a transaction,taking into account the various factors affecting the radio path quality andrequired service. The Nokia Siemens Networks' 3G circuit switched corenetwork supports the following handover scenarios:

. Inter-system handover (ISHO)

GSM and 3G enable ISHOs to increase coverage and to balancenetwork load. The user equipment (UE) must support ISHOs beforethey can be performed.

Inter-system handovers are network-evaluated handovers (NEHO).The 3G RNC recognises ISHO availability on the basis of theconfiguration of the radio network. The RNC orders the UE to startperiodic reporting of inter-system measurements. On the basis of thecontrol parameters and measurement results (inter- and intra-system) reported by the UE, the RNC then makes the decision tohand over from 3G to GSM. From the BSC's viewpoint, an ISHOfrom 3G to GSM is similar to an inter-BSC handover.

The decision on a GSM to 3G handover is made by the GSM BSC.From the RNC's viewpoint, an ISHO from GSM to 3G is similar to aninter-RNC handover.

. Inter-MSC/MSS handover

The inter-MSC/MSS HO is performed in the CS core network byfollowing methods similar to the ones in 2G. This applies to both thehandovers within 3G coverage and those between 3G and 2Gcoverage. However, there are differences between the 2G and 3Ginter-MSC/MSS HOs because of the different location of the user

plane, for example. In handovers that occur between MSSs thatconnect different Multimedia Gateways (MGWs), the MGW acts asan anchor MGW.

. Inter-vendor handover

The Nokia Siemens Networks CS core network is fully compliantwith GSM and 3GPP handover requirements. Interoperation issupported with any vendor's equipment that is compliant with the3GPP specifications. 3G to GSM handovers are also supportedtowards older releases.

. Inter-operator handover





The Nokia Siemens Networks CS core network supports inter-

operator handover occurring between the 3G, GSM and 3G/GSMPLMNs. The inter-PLMN (inter-operator) handover is not explicitlydefined in the 3GPP stage 2 and 3 specifications. The assumption isthat handover will be performed as a normal inter-MSC handover or an inter-SGSN routing area update. Nokia Siemens Networks'network elements have been designed to handle these handovers.

For more information, see section Handover cases .

6.13 Security in CS core network

The move towards a mobile information society means increasedemphasis on transactions and services that are delivered using the mobileenvironment. Ensuring the security of the Circuit Switched (CS) corenetwork solution is imperative in gaining the trust of the end users. Alsoauthorities and legislation place requirements for system level security.

3G provides significant benefits and allows the end users to enjoy newmobile services. Some services are already familiar from the Internet andthere is a possibility to create completely new services that fully utilise thepossibilities of mobile environment.

At the same time, the introduction of IP protocol and connectivity with theexternal networks, such as the Internet, introduces several new securitythreats. It is vital that the operators have a sensible security policydeployed in their networks. Along with the new services, the number of theservice users increases. Also the information carried in the mobilenetworks, for example subscriber location information, becomes moresensitive. All this increases the number of attack attempts directed towardsthe mobile networks.

Nokia Siemens Networks' CS core system security is based on perimeter

security and security built into the core network elements. This wayoperators can choose a security policy that meets the topology andsecurity needs of their networks.

Perimeter security protects any part of the network. Operators ’ wholenetwork can be seen as one security domain or the network can be dividedinto several security domains. Perimeter security equipment enforce thesecurity policy within the security domain and between security domains.Tools for perimeter security are:






. Traffic separation

This is achieved within CS core sites by using Virtual Local AreaNetwork (VLAN) technology and between the core sites using Multi-Protocol Label Switching (MPLS) -based Virtual Private Network(VPN) in the backbone.

. Traffic filtering

This is achieved by deploying suitable Firewalls from Nokia SiemensNetworks' product portfolio.

. Traffic authentication and encryption

In addtion to VPN capable FWs, integrated IPSec offers thepossibility to build secure connections between core sites withinoperators ’ networks and to connect the networks of differentoperators.

. Access authentication

Nokia Siemens Networks' CS Core products can handle both 2Gand 3G -based mobile subscriber authentication. In the 2G network,the mobile subscriber is authenticated by the network. In 3G, thesubscriber can also authenticate the network and vice versa. Themechanism for mutual authentication in 3G is called UMTS Authentication and Key Agreement (UMTS AKA). It is a challenge-response protocol combined with a sequence number-basedmechanism. The AuC in the home network derives allauthentication-related data. An authentication vector called Quintetcontaining the challenge is sent from the home network to the VLR inthe serving network. The Quintet constitutes of challenge (RAND),expected response (XRES), ciphering key (CK), Integrity Key (IK)and authentication token (AUTN). As in the GSM network, the RANDand the XRES are used for authenticating the subscriber and the CKis the ciphering key for encrypting payload in the air interface. The

Authentication Token is used when the subscriber authenticates thenetwork and the Integrity Key is used for ensuring the integrity of thesignalling messages in the air interface.

The MSC Server (MSS) System introduces the possibility to use IP or ATM-based core backbone for carrying real-time traffic. Basically this meansthat the same backbone is used to carry both circuit switched and packetswitched traffic.

The IP Multimedia Subsystem (IMS) implements person-to-personservices through Session Initiation Protocol (SIP) functionality.





In security built into the core network elements, the most important issue is

to prevent security violations by using proper authentication andauthorisation methods for O&M users and effective protection againstdifferent Denial of Service attacks. IPSec integrated in the networkelement provides authentication and helps to cope with DoS attacks. If IPSec is not integrated in the network element to protect control planetraffic, then external IPSec can be provided in the IPSec Virtual PrivateNetwork Gateway. Also, firewalls can be used to prevent unauthorisedaccess.

On the radio interface site security is ensured with ciphering and integrityprotection. For more information, see WCDMA RAN System Library .

Core network security threats

Security must be considered on all levels of the core network. Operatorsneed to protect the network against attacks coming from externalnetworks, as well as to ensure that their network cannot be used for attacking other operators ’ networks. Also there is a need to protect thenetwork against internal threat, which is the case when someone hasaccess to the network with an intention to cause damage to the system.

The various threats to the core system can be listed as follows:

.

Unauthorised access to sensitive data (violation of confidentiality),such as eavesdropping and inference.

. Unauthorised manipulation of sensitive data (violation of integrity),such as manipulation of messages.

. Disturbing or misusing network services (leading to denial of serviceor reduced availability), such as intervention and resourceexhaustion.

. Repudiation. A user or network denies actions that have taken place.

. Unauthorised access to services.

The security threats can be targeted to the radio interface, networkelements, user equipment and subscriber identity.

Core network security attacks

Security attacks may come from outside or within the mobile environment.In both cases the most common forms of attacks are the following:






. Network packet decoding (packet snooping)

An attacker monitors the network traffic in order to get information onpasswords, user names and network configuration.

. Password attacks

An attacker attempts to gain access to network elements, servers or user equipment by determining valid user names and passwordsthrough repeated trial and error user login attempts. These attackscan be automated and based on information from dictionaries.Therefore this type of attack is also called a dictionary attack.

. IP spoofing (packet hijack)

An attacker uses a trusted IP address to access the target network.For example, an IP address from the mobile core network addressrange could be assumed by the attacker and used to attempt toaccess the network from the Internet.

. Man-in-the-middle attack

This type of attack takes the packet hijack one step further, as oncethe IP packets are intercepted then the information can be corruptedor otherwise modified and sent to the original recipient.

. Denial of service (DoS)

This type of attack reduces availability of a service (by for examplecreating slow response to web access, e-mail retrieval) by exposingsome processing limitation within the system or application.

. Protocol fuzzing attack

Anomalous or semi-valid inputs are provided to an application withmalicious intent. Injection vectors are typically built in an automatedfashion. This type of attack might expose possible implementationlevel vulnerabilities and exploitation of discovered flaws may lead toa failure of software component.

. Viruses and Trojan horses

These types of attacks can be used as part of the attacks above.Viruses can cause denial of service if servers or user equipment areaffected. Trojan horses can provide backdoor access to networks or aid password attacks, for example.

Core network security requirements

Security requirements for the core system can be categorised as follows:





. Confidentiality and privacy

Information cannot be intercepted by unauthorised parties.

. Integrity

Information is not altered during transmission.

. Authentication and identification

The person or the system is who they claim to be.

. Non-repudiation

Messages, once sent, cannot be denied by the sender.

. Access control

Access to a system is restricted to parties who have been grantedpermission.

The Nokia Siemens Networks' core network security solution covers thesecurity of backbone elements, perimeter security and the security of thecore network elements.

6.13.1 Security in Nokia Siemens Networks' core network

Secure sites are the basis of Nokia Siemens Networks' core networksecurity. A site usually has network elements of different systems such aspacket switched domain (SGSN, GGSN and so on), circuit switcheddomain (MSC Server, Multimedia Gateway MGW), the IP MultimediaSubsystem (IMS), and possibly a set of application servers providingdifferent services to mobile subscribers. The core site can be protected byusing the following methods, for example:

. VLAN for separating and isolating different traffic flows within sites

. Firewall for preventing the access of unwanted packets to core site

. Intrusion Detection System (IDS) for detecting attacks against coresite

For more information, see section Security on site in Site Connectivity Guidelines for CS Core Network , available in CS core systemdocumentation library.






6.13.2 Security in CS core network elements

Security features in the Nokia Siemens Networks' CS core networkelements can be categorised as follows:

. Network element user access

Possibility to authenticate and authorise the O&M users of thenetwork element. In Nokia Siemens Networks' CS core thepassword/user identification method is used. For access toresources, the system allows security administrator to specifyauthorisation requirements

. Security monitoring and reporting

Possibility to monitor the usage of the network element. It is possibleto trace back who have accessed the network element and what wasdone. It is possible also to set alarms for security related events.

. Traffic encryption

IP traffic can be authenticated and encrypted using IPSec. In theNokia Siemens Networks' CS core, IPSec is integrated in the MSCServer, HLRi and MGW. With IPSec it is possible to encrypt controlplane traffic, billing traffic and management plane traffic.

IPSec usage in CS core

In Nokia Siemens Networks MSC Server System Release 3.0 theintegrated IPSec functionality in MSS network element is available tomanagement plane traffic, charging and OLCM reports as already in theprevious MSS system release, and now also for control plane traffic as aseparate license. In MGW network element from U4.0 onwards theIntegrated IPSec is available as an optional feature (both for managementand control planes). The user plane can be encrypted using external VPNGWs if desired.

Sensitive traffic in the backbone can be protected by using VPN GW at thecore site. It is also possible to use IPSec integrated in the networkelement. The following figure shows an example of IPSec configurationwith IPSec protected O&M between MGW OMU and Virtual PrivateNetwork Gateway (VPN GW) in the network management (NetAct) site,using Internet Key Exchange (IKE) pre-shared key in IPSec VPNauthentication.





Figure 26. Example of Integrated IPSec usage

Management plane signalling (O&M, Charging, OLCM) between networkelements (MSCi, HLRi) and network management systems (NetAct, BillingCenter, OLCM Center, for example) can be protected from end to endusing integrated IPSec in these network elements. As of MSS SR3.0Integrated IPSec can be used for protecting remote O&M connections inMGW.

6.14 Charging in CS core networkThis section gives an overview of the distribution of the chargingfunctionality in the Nokia Siemens Networks' solution for circuit switched(CS) core network. Therefore only the core network elements are included,while the operator ’s Customer Care and Billing System (CCBS), networkelements provided by other vendors, and content servers of third partyservice providers are not covered. However, the Nokia Siemens Networks'solution can be integrated with any elements within the operator ’senvironment.

In NetAct site ESP tunnels (IPSec VPNs)are terminated to VPN GW cluster.

Network management(NetAct) servers

10.0.0.8/24VPN GW cluster:192.168.8.1/24

VPN GW / Firewall

Control plane andO&M secure evenwithin remote site.

Site B

MSS A1:net 192.168.2.0/24net 192.168.3.0/24

Site A MSS A1 edge addr:10.0.0.2/2410.0.0.3/24

MGW C1:net 192.168.9.0/24net 192.168.10.0/24

Site C

PublicTCP/IP network

IP Backbone(10.0.0.0/24)

MSS C2:net 192.168.11.0/24net 192.168.12.0/24

MSS B1:net 192.168.4.0/24net 192.168.5.0/24

MGW B2:net 192.168.6.0/24net 192.168.7.0/24

Site B edge addr:10.0.0.4/2410.0.0.5/2410.0.0.6/2410.0.0.7/24

Site C edge addr:10.0.0.9/2410.0.0.10/2410.0.0.11/2410.0.0.12/24






The charging functions in the CS core network elements include the

following:. collecting and generating charging data for billing purposes from

post-paid calls, sessions and services

. generating and collecting data or applying online mechanisms for charging for prepaid services

. collecting and generating call traffic sum data for accountingpurposes

. storing charging and accounting data

.

consolidating Charging Records (CDRs) (done by the CCBS). transferring charging and accounting data from the network

elements to the CDR post-processing system; third party CCBS.

Charging functions are separate from the operator ’s CCBS. The networkelements produce charging data and send it to the CCBS for analysis andgeneration of the final subscriber bills.

The CCBS has to contain:

. software to handle the structures and contents of the CDRs

. capacity to store and process the charging data received from thenetwork elements

. capacity to transfer charging data from the network elements.

The following figure presents a general view of the network elementsinvolved in charging:





Figure 27. Network elements involved in charging in the 3G network

The abbreviations used in the figure are the following:

HLR CG

SGSN

ISN/GGSN

Circuit SwitchedCore Network

Packet SwitchedCore Network

MSC or MSS

InternetServices(ContentServers)Messaging

Gateway

MMSC

SMSC

USSDC

DeliveryServer

WAPGateway

IP MultimediaNetwork

ApplicationServers

CSCF

SS7Network

GMLC IN

CDRPost-processing

system(CCBS)






CCBS Customer Care and Billing SystemCSCF Call State Control FunctionCG Nokia Charging GatewayGMLC Gateway Mobile Location CentreHLRi Home Location Register IN Intelligent NetworkISN/GGSN Nokia Intelligent Service Node (including GGSN

function)MMSC Nokia Multimedia Message Service CentreMSCi Mobile Switching CentreMSS MSC Server

Multimedia Gateway (MGW) is also required when MSS is used. However,since MGW is not involved in charging processes, it has not been includedin the figure.

SGSN Serving GPRS Support NodeSMSC Nokia Short Message Service CentreUSSDC Nokia Unstructured Supplementary Service Data

Centre

6.14.1 Charging principles in circuit switched core network

The network elements that are involved in charging in the CS core networkare:

. Mobile Switching Centre (MSCi)

. Home Location Register (HLRi)

. MSC Server (MSS)

. The operator ’s Customer Care and Billing System (CCBS).

The CCBS is not strictly part of the core network, but it is essential inpresenting the overall view of the charging system.

In the CS core network, subscriber charging and billing is based on call/ event-specific information collected in Charging Records (CDRs) in theMSCi, MSS and HLRi. CDRs are normally generated in all the exchangesthat are involved in the call/event, or at least in those exchanges in which





the subscribers to be charged for the call or event are. The operator can

decide for which call types and events CDRs are generated. By default,CDRs are generated only for answered calls. CDRs are transferred fromeach MSCi or MSS to the CCBS. Charging can also be prepaid-based.

The MSCis, MSSs or HLRis do not provide the prices of calls or events for billing purposes. They generate charging information which is then used inthe CCBS to calculate the final call prices. Call duration is often the maininformation used in the billing process to form the final call price. Countersare used for collecting accounting data in the MSCi and MSS. Counter readings are mainly used for accounting purposes, such as balancing theaccounts between network operators, although it is also possible to useCDRs for that purpose. The counter files can be transferred to the CCBS inthe same way as CDRs.

A CDR can be generated either in the MSCi, MSS or HLRi, depending onthe call type or event in question. CDR generation parameters allow theoperator to define which CDRs are generated, but it must also be ensuredthat the CCBS can handle all the CDR types that are defined in theoperator ’s charging format (pre-defined operator-specific combination of CDR types and their structures).

6.14.2 Network elements generating charging data in the core network

Charging data generation in the MSCi, MSS and HLRi

Network operators may have different principles in call price formulation.The final call price is usually based on the following charging information:

. call duration

. day and time of the day

. subscriber category

. destination of the call

. services used

. origin of the call.

At the end of a call, the charging system has calculated both call duration(in seconds and/or in tens of milliseconds) and the number of pulsesgenerated during the call (if pulses are in use). This information can bestored in both CDRs and different counters. CDRs and counters can alsoinclude a lot of other data. CDRs can contain information on the servicesused, the called numbers, and detailed call information. The counters may






include the number of calls, for example. The operator's CCBS determines

how charging data is used when the final phone bill is calculated. For moreinformation on the available CDR fields, see the document CDR FieldDescription available in NOLS.

The operator can also define special tariffs for different days, such asholidays. The tariff may vary during one call. The number of pulsesgenerated for the call will vary depending on the tariff. The chargingsystem can generate charging pulses (for example, to be used in Advice of Charge processes) according to the current rate defined, by the call casein question and the current time of the day. The tariff and pulse informationcan then be used in the CCBS for billing purposes.

Detailed charging in the MSCi/MSS and HLRi

The MSCi/MSS and HLRi can generate one or more CDRs for calls or other chargeable events. This is called detailed charging.

CDRs are the only possible way to store call/event-specific charging data. A CDR is a data package that contains the identification and charginginformation for one call or event. It consists of defined data fieldscontaining all the information required for the billing of a call, excluding theactual price information.

The data contained in the CDRs may be used by the CCBS for thefollowing purposes:

. subscriber billing

. billing between network operators

. traffic statistics between operators

. statistics based on subscriber numbers area codes, subscriber categories, duration of calls, price of calls, and so on

. checking call information (for example, a subscriber query).

The information content of the CDRs is pre-defined on an operator-specificbasis, according to the requirements of the operator ’s CCBS.

The information stored in a CDR depends on the call type or the event inquestion. The data fields to be included in a CDR of a certain call type or event have been defined in a customer form.

Planning CDR data consists of the following steps:





1. defining the type of charging data needed for billing processes (the

operator must know the different call cases and their effects on theCDR data).

2. planning and defining the CDR structure for each CDR typeaccording to the billing requirements in the whole network

3. modifying the CCBS software to handle and process the CDR dataand to produce the final billing data.

The CDR types that can be generated in MSCi/MSS are the following:

Table 10. CDR types in MSCi/MSS

CDR Description

MOC Mobile-originated call

MTC Mobile-terminated call

FORW Forwarded call

ROAM Call to a roaming subscriber

SUPS Supplementary service

HLRI HLR interrogation

LOCA Location update

LCS Location services

SMMO Mobile-originated short message service

SMMT Mobile-terminated short message service

SMMF Short message service with forwarding

POC PSTN-originated call

PTC PSTN-terminated call

PBXO PBX-originated call

PBXT PBX-terminated call

HW Use of hardware

IN1 Intelligent Network data 1 (for Core INAP)



IN4 Intelligent Network data 4 (for Camel)

IN5 Intelligent Network data 5 (for Camel)

UCA Unsuccessful call attempt

DOC Device-originated call






Table 10. CDR types in MSCi/MSS (cont.)

CDR Description

RCC Remote charging control

HEA Block header

TRA Block trailer

COC CAMEL-originated call

CTC CAMEL-terminated call

USSD Unstructured supplementary service data

SOC SIP-originated call (NVS)

STC SIP-terminated call (NVS)

SOM SIP-originated message (NVS)

STM SIP-terminated message (NVS)

SIPR SIP-registration (NVS)

The CDR types available in the HLRi are the following:

Table 11. CDR types in the HLRi

CDR Description

HLRI HLR interrogation

LOCA Location update

SUPS Supplementary service

Combining CDRs

Multiple CDRs may be generated during one call or event. The CCBS isexpected to perform the CDR combination. The CDRs of one call/eventgenerated in a certain network element always have unique identifierscalled call_reference . A call may involve several network elements withdifferent call_reference identifiers, which are displayed in the generatedCDRs. There are call cases, such as inter-MSC/MSS handovers andtransit calls, in which the billing systems have difficulties to tell whichCDRs belong to a certain call.





The feature Global Call Reference allows to share the same identifier

between separate network elements. The feature presents a MSCi/MSSmechanism for combining CDRs from different network elements or nodesby defining a unique identifier (Global Call Reference) for the call. Thisreference is shared among all network elements and call legs that provideCDRs for the call.

Global Call Reference is not currently standardised.

Storing and transferring CDRs in MSCi/MSS

In MSCi/MSS, the process of storing and transferring CDRs includes thefollowing phases:

1. The CDRs are first generated in a buffer file in the RAM memory of the Charging Unit (CHU) or the Statistical Unit (STU) of theexchange. STU is used if there is no separate CHU.

2. The CDRs are stored from the RAM memory to a storing device.

Tip

In case of DX 200 HLRi, CDRs are stored in OMU WDUs.

3. The CDRs are transferred to an external CCBS for post-processingvia OSI/LAN, X.25, TCP/IP or UDP/IP. The Hot Billing featureenables sending the CDRs to the CCBS immediately after they havebeen generated for a certain subscriber.

4. The charging data stored on the disks of the CHU/STU can becopied to removable media (RM) when needed.

Immediate CDR Transfer for All Subscribers

The feature Immediate CDR Transfer for All Subscribers feature makes itpossible to transfer all CDRs (not just the ones generated for Hot Billingsubscribers) immediately to the post-processing system. Immediate CDRtransfer is based on the standard GTP ’ protocol, which provides a methodfor fast and reliable data transfer between the MSCi and the post-processing system. With GTP ’, CDRs can be immediately sent to the post-processing system.

With this feature it is not possible to store the CDRs on disks at the sametime. If there is no connection to any post-processing system, the CDRsare stored on a hard disk or removable media.






Immediate CDR transfer makes it possible to have an up-to-date account

balance almost in real time. This feature does not offer prepaid service.

Accounting counters in the MSCi/MSS

The MSCi/MSS has several types of accounting counters. These are usedfor accounting purposes between operators and not for subscriber billing.The main features of the accounting counters are:

. The counters are data records in the RAM memory of the exchange.

. A limited range of different types of numeric information of calls canbe stored on different counters.

. The update of the counters must be activated by defining theaccounting zones in the analyses.

. Only calls can be registered in counters. (Short messages, for example, are not included).

. A counter reading is always the sum data of several calls.

. Counters do not offer detailed, call-specific charging data for thepost-processing system.

. Counters are updated and stored in the exchange.

. The counter readings (the values of the data records) are copiedregularly to disk as backups.

. The counter reading data must be transferred from the exchange tothe post-processing system.

The counters are only used in the MSCi/VLR, not in the HLRi.

The main types of information to be stored in the counters are thefollowing:

. call duration (in seconds)

. the number of charging pulses

. the number of answered calls.

The counter data can be transferred to the operator ’s CCBS via datacommunications network, if necessary.





Accounting data generation in the MSS

Subscriber charging of calls in the MSS is handled in the same way as inthe MSCi. In principle, the same CDRs are created for calls or other chargeable events.

However, accounting in the MSS is different from the MSCi. Theaccounting principles of inter-switch traffic of calls using the IP or ATMtransport are divided into two different levels:

. user plane accounting

. control plane accounting.

Accounting data is collected by using dynamic accounting counters, whichfunction as a parallel counter architecture to the normal accountingcounters in the exchange.

Accounting on the user plane is based on User Plane Destination (UPD)indices. The UPD defines connections to and from MGWs controlled bythe MSS. The accounting data collected by the dynamic counters throughthe ATM and IP networks includes the number of incoming/outgoing callsand the call duration of those calls.

Accounting on the control plane is based on User Plane DestinationReference (UPDR) indices. The UPDR defines the connections towardsthe succeeding MSS and the preceding MSS. The accounting datacollected by the dynamic counters through the Session Initiation Protocol(SIP) and Bearer Independent Call Control (BICC) signalling contains thenumber of incoming/outgoing calls and the call duration of those calls.

Charging data generation in NVS

Nokia VoIP Server (NVS) charging can be generated from Media GatewayControl Function (MGCF) or Nokia VoIP Server (NVS) functionality. In theNokia Siemens Networks' solution, new CDRs are used in both cases.

SIP-originated call (SOC) CDR is generated in the following cases when acall is coming to NVS through SIP signalling:

. SIP access subscriber in standalone mode

. ISC interface for originating services

. ISC interface for terminating services

. MGCF case






SIP-terminated call (STC) CDR is generated in the following cases when a

call is going from NVS through SIP signalling:. SIP access subscriber in standalone mode

. ISC interface for originating services

. ISC interface for terminating services

. MGCF case

SIP-originated message (SOM) CDR is generated when NVS receives aninstant message to be converted to a short message and delivered to theSMSC.

SIP-terminated message (STM) CDR is generated when the SMSC sendsa short message to NVS to be converted to an instant message anddelivered to the IMS network.

SIP registration (SIPR) CDR is generated when an IMS networksubscriber makes a registration (similar to a location update).

NVS can generate one originating CDR and one terminating CDR for thesame call. However, all these CDRs have their own generation parametersso that unnecessary CDRs can be avoided.

IMS offline charging (Rf) interface

The Rf interface provides support for offline charging in IMS. The offlinecharging transactions are sent using the Diameter Rf protocol. In caseNokia VoIP Server works as AS/MGCF for IMS, MSS has CDF role andCDRs are generated in Charging Gateway (CGF). For more information,see Nokia NVS-CDF Diameter Rf, Interface Specification. in the M-releaseproduct documentation library.

6.14.3 Prepaid

The method of charging in which the subscriber pays a certain sum inadvance and the account is charged in real time is known as prepaid.

Implementing prepaid in the CS core network

The possibilities for implementing prepaid in the CS core network include:





. IN-based prepaid (Nokia INAP or CAMEL)

Siemens INAP (SINAP) support is planned to be available in MSSSR3.0A (M14.1) timeframe.

. hot billing-based prepaid.

CAMEL-based prepaid in the CS core network

In the prepaid implementation using CAMEL in the Intelligent Network (IN),the Service Control Point (SCP) sends a time threshold to the MSCi/MSS/ SSP, which can then control whether there still is prepaid speech time leftfor the call to continue. However, the SCP decides which services aresupported.

IN provides real-time prepaid account for circuit switched connections bymeans of a CAMEL interface. Calls are triggered using the CAMELinterface from the MSCi/MSS to IN which holds the subscribers ’ prepaidaccount information. When the account balance reaches zero (or someother predefined limit), IN may instruct the MSCi/MSS to redirect all further calls to a recharging system or bar them, until the account has beenrecharged. The CAMEL interface also allows prepaid roaming to other networks as well as interworking with other vendors' IN systems.






Figure 28. Prepaid solution for circuit switched voice and data

MSC/MSS/SSP

Circuit SwitchedCore Network

Circuit-switched

voice and data

MessagingPacket-

switcheddata

WapGateway

CCBS

Service Providers

SMSC USSDC MMSC

Packet SwitchedCore Network

CG

SGSNISN/

GGSN

Top-UpSystem

BalanceNotification

System

Accountsynchronisation

BarringHLR

IN/SCP

Master account balance

Charginginformation

Mobile messagingSystems





If CAMEL functionality is not needed, the prepaid solution can also be

integrated with third party service node-based prepaid systems. In thisscenario, the circuit switched connections are routed from the MSCi/MSSto the prepaid service node for deducting the user ’s prepaid accountbalance. When the account reaches zero or some other predefined level of balance, the prepaid system bars future calls until the account has beenrecharged.

Hot billing-based prepaid in the CS core network

It should be noted that this is not a real prepaid method, as it works nearlyin real time. This is a method where all CDRs for the prepaid (hot billing)subscriber are sent immediately to the CCBS for postprocessing.

If the prepaid limit has been exceeded, the CCBS can set barrings for thatsubscriber until the subscriber has bought and paid more speech time for the subscription. Note, however, that using this method of prepaid enablesthe subscriber to make a long call even if the subscriber ’s limit is about tobe reached soon; the system cannot disconnect the call if it has beenstarted when there still was some speech time left.

The benefit of using hot billing as the prepaid method is that there are nolimits on supplementary services and calls; anything that can be chargedwith CDRs is supported.

6.14.4 Charging functionalities

Handovers and charging in the CS core network

The following table lists the CDRs that can be generated in handover cases in the CS core network.

Table 12. CDRs that can be generated in handover cases in the CS network

Handover type Anchor MSC/ MSS normalCDRs

Anchor MSC/ MSSintermediateCDRs

Anchor MSC/ MSS HOCDRs

Target MSC/MSS HOCDRs

Intra-MSC/ MSS

Intra-PLMN

Intra-system

MOC MTC

Inter-PLMN

Inter-system

MOC MTC MOC MTC






Table 12. CDRs that can be generated in handover cases in the CS network(cont.)

Handover type Anchor MSC/ MSS normalCDRs

Anchor MSC/ MSSintermediateCDRs

Anchor MSC/ MSS HOCDRs

Target MSC/MSS HOCDRs

Inter-MSC/ MSS

Intra-PLMN

Intra-system

MOC MTC MOC MTC PTC POC MTC

Inter-system


Inter-PLMN

Intra-system


Inter-system


The table above applies to handover cases where the MSCs/MSSs areNokia MSCis/MSSs.

In inter-vendor handovers (inter-MSC/MSS handovers in which the other MSC/MSS is not a Nokia network element), the following CDR generationrules apply in the Nokia MSCi/MSS:

. An MTC CDR can be generated in the anchor MSC/MSS for thecalled subscriber who makes a handover during the call.

. An MTC CDR can be generated in the target MSC/MSS for thecalled subscriber who makes a handover during the call. The CDR isgenerated for the time that the subscriber is under that MSC/MSS.

. A POC CDR can be generated in the target MSC/MSS when asubscriber makes an inter-vendor handover. The POC CDR isgenerated for the time that the subscriber is under that MSC/MSS.

Roaming and charging in the CS core network

When the subscriber roams in the CS network, ROAM and MTC CDRscan be generated for the subscriber.

A ROAM CDR is produced in the gateway MSC/MSS. The operator candefine whether ROAM CDRs are produced:





. for subscribers roaming in own/other PLMN

. when SCP informs the MSC/MSS to generate a ROAM CDR for anIN call

. for number portability call cases.

All cases can be activated at the same time.

An MTC CDR can also be generated for those roaming subscribers whouse call forwarding. The operator can define whether an MTC is generatedfor only to the visiting subscriber ’s forwarding calls.

Example Roaming and Inter-PLMN-inter-MSC/MSS handover

A handover is required for a roaming subscriber from PLMN B to PLMN A.

. A ROAM CDR is generated in MSC/MSS A/gateway MSC/MSS B.This MSC/MSS collects data throughout the call.

. MSC/MSS B collects charging data to a MTC CDR during the call.

. When the subscriber performs a handover to network A, MSC/MSSB generates a PTC CDR from the moment the handover occurs untilthe call is released or the subscriber performs a handover back to

MSC/MSS B.. Target MSC/MSS will generate a POC CDR and an MTC CDR from

the moment the handover occurs from PLMN B until the call isreleased or the subscriber performs a handover back to PLMN B.

Prepaid roaming

Seamless prepaid roaming requires CAMEL support in both the home andnon-HPLMN networks. In practice, CS voice and data require CAMELphase 2 functionality. In prepaid roaming, the MSC/MSS of the visitedaccess network uses CAMEL interface to connect to the home network ’sIN/SCP for checking and deducting the user ’s prepaid account balance inreal time.

Prepaid roaming for CS services can also be achieved with IN via other online mechanisms such as CAMEL phase 1 redirection to the homenetwork, overlay IN or USSD call-back according to the customer'srequirements.

Charging in shared networks

Charging and the network sharing concept






In the shared network concept, several operators use the same network to

serve subscribers. This section details various possibilities for implementing charging in shared networks.

Different network sharing methods include:

. site sharing

. multi-Operator RAN (RAN sharing)

. RAN sharing with gateway core network

. geographical network sharing (that is, national roaming)

. separate network operator.

Depending on the implementation, a mediation device may be needed toseparate different operators ’ CDRs generated by the MSC/MSS in thecommon core CS network. The mediation device can provide options for filtering, matching, converting and distributing the CDRs, as well asauditing and error management functions.

CDRs generated in the common core network for third party roamingsubscribers and for PSTN-terminated calls can be distributed to theoperators ’ CCBSs by using intelligent functions of the mediation device.

The CCBSs convert the roaming CDRs to TAP3 format and forward themto a clearing house.

Charging and the mobile virtual network operator (MVNO) concept

A mobile virtual network operator is an organisation that appears to thesubscriber as a full-fledged mobile operator in all significant respects, butdoes not have a network or licence of its own. Instead, the MVNO pays for access to one or more of the existing operators ’ networks. There are threeMVNO model options:

. Light model: the MVNO depends entirely on the host network.

. Medium model: the MVNO has its own billing, but uses the hostnetwork infrastructure.

. Heavy model: the MVNO has its own exchanges and the host offersthe access network only.

Charging for MVNO is done by collecting charging data from differentnetwork elements, depending on the MVNO model being used and whichMVNO network elements and host network elements are used for charging.





CDRs generated by a VMSC in the host network can be sent to the CCBS

of the MVNO through a mediation device, which may require someadjustments.

Advanced charging control, such as prepaid for MVNO subscribers, is alsopossible by using IN/CAMEL capabilities.






7 CS core network management

7.1 Nokia NetActThe fast development of telecommunication networks has led to a situationwhere networks are becoming large and complicated to manage andanalyse. In many cases the networks also consist of different technologies,such as GSM, GPRS and 3G. Nokia has developed solutions to helpoperators manage their networks.

The Nokia NetAct operations support system provides a future-proof andscalable framework for managing the network and services. The existingNokia NetAct will evolve to support a wider range of the operator's needs

as introduced by new network technologies.

Nokia NetAct consists of functional areas such as Monitor, Reporter, and aUnified Mediation and Adaption layer (UMA). The UMA interfaces with themanaged network, performing adaptations to different network elementsand technologies. This allows the collection and central storage of all fault,performance and configuration data received from all core networkelements. The cornerstones of the Nokia NetAct management solutionare:

. Nokia NetAct can manage different network technologies while

protecting existing investments and ensuring a growth path. All Nokia NetAct tools can be accessed from a single screen. Also,

the element managers of network elements can be launched fromNokia NetAct for performing element-level tasks remotely

. Interworking tools and automated mass operations

. Open interfaces to enable seamless information flow.



CS core network management



The NetAct hardware solution is built of one or more server cluster and

operator seats (clients). Regional clusters manage a specific region, whileglobal clusters are intended for centralised, network-wide managementtasks. The Oracle 8 relational database is used.

NetAct in configuration management

For the GSM network, Radio Access Configurator offers tools for managing the BSS radio network parameters. The available tools andexamples of tasks that can be performed with each tool include:

. Uploading of the supported managed objects and parameters to theNetAct Database (Configuration Documentation).

. Support for configuration parameters related to functionalities suchas Multipoint A.

. Downloading (provisioning) object creations and objectmodifications to the MSC/MSS.

. 3GPP N interface support for the managed objects of MSS, includingBulk CM and Basic CM.

. Consistency checking between Nokia Radio Access configurationdata and Nokia MSC/MSS configuration data.

. Possibility for 3-5 pre-defined consintency checks related toMultipoint A interface.

. An open XML, CSV interface to import/export configuration data(Planning tools, Reporting, … ).

. Basic functionality and tools provided by CM Editor & CM Analyser for viewing, modifying, searching, mass modifying, and analyzingconfiguration data.

. Functional support for 2G BTS re-hosting across BSCs.

. 3G BTS re-hosting across RNCs.

. Procedural support for BSC re-hosting across MSCs, for example.

Centralised monitoring of network and services

Nokia NetAct Monitor is used to pre-process, store and display real-timealarms from the core network. All fault management data is collected inreal time, meaning that each event is inserted in the Nokia NetActdatabase immediately. Monitor provides the operators with the mostimportant fault information, allowing them to see and resolve the root of theproblem quickly.





Nokia NetAct Traffica allows the operator to monitor the traffic real-time, all

the way down to the individual, end user level. For 2G/3G circuit switchednetworks, Traffica displays the following real-time reports, for example:

. Successful calls

. Clear codes

. Data calls

Traffica supports NSS network elements only, MGW is not supported.

Management of network and service performance

Nokia NetAct Reporter offers the means to collect, process and visualisethe performance information received from the core network and services.Reporter provides both regional and global performance managementdatabases, as well as reporting tools for the creation of ad-hoc and on-demand reports at regional and global level.

The MGW and NSS Reporting Suites (optional software of the NetAct)provide detailed reports, for example, of the IP Multimedia Subsystem(IMS) performance, for analysis and planning purposes. The reports cover the following areas:

. Mobility (registration, detached registration, roaming)

. Traffic (connection attempt, success, failure, duration, error codes)

. Resources (connection resources, SIP performance of ConnectionProcessing Server, CPS)

. Authentication (IMS subscriptions, SIP service subscriptions,location management)

. Services

. Quality of Service.

Network Licence Management in NetAct

Network Licence Manager and element managers are used to managelicences and run reports in the network.

Network Licence Manager helps you to deliver correct licences to variousnetwork elements. Network Licence Manager can be used for importinglicences to NetAct, distributing licences to network elements, settingfeature state, synchronising licence and feature information in NetActdatabase, deleting licences and substituting pool licences.






Network Licence Manager supports the following CS core network

elements: MSC, MSS, HLR and MGW.

See section Licensing of features and functionalities for information onsoftware licensing in CS core network elements.

Nokia NetAct in security management

Nokia NetAct acts as a security centre while providing powerful access tonetwork and instant access to network status. This way NetAct providesearly warnings of possible security problems and thus enables earlyreaction to the warnings. The NetAct system also performs network widefunctions such as access to logs to maintain and improve overall security.

Nokia NetAct provides methods to distribute administration and control theusage of administrative privileges. By providing such capabilities it ispossible to design an effective and secure administrative network as wellas enhance all security features by placing security control on top of thenetwork.

Nokia NetAct controls and provides secure access to network elements.By providing Single-Sign-On for network elements it is possible to enhancethe daily administration work and control access to network elements. WithSingle-Sign-On the user needs to log in to the system only once, after

which all network elements are accessible during the same session.Password data is securely stored and maintained to provide the necessarylevel of security.

The data communications network (DCN) security follows the NokiaNetAct security policy. Security solutions are based on open andstandardised technologies, such as DES algorithm, Internet protocolsecurity (IPSec) and Secure Shell (SSH). Virtual Private Network (VPN)can be used when connecting to other NetAct clusters and IP-basednetwork elements.

Subscriber trace

Nokia NetAct Tracing consists of a TraceViewer application. TraceViewer offers efficient and real-time means of tracing mobile equipment or subscribers in GSM, GPRS and 3G networks. TraceViewer supports theSystem Level Trace functionality that is implemented in various Nokianetwork elements. With Nokia NetAct Tracing operators can improve boththeir network planning, monitoring and optimisation tasks. The MGW tracereports are transferred via NEMU to NetAct, and from MSS directly to theNetAct. MGW Trace reports can also be viewed in NEMU.





System management

Nokia NetAct System Management consists of Time Management, SWManagement and HW/Inventory Management. Time Management offerscentralised time management for all network elements. SW managementconsists of SW Register that offers a centralised SW configuration register and an SW Archive that is used as a centralised SW archive to browse,copy to, remove from and download SW simultaneously to a number of network elements. HW/Inventory management keeps an up-to-datedatabase with Hardware Register that is synchronised with HW uploadsfrom the network elements. Network elements can also use HW changenotifications to inform about their changed HW.

NetAct Northbound Interfaces

Nokia NetAct Northbound Interfaces provides interfaces for data exchangefor upper level management systems. The Northbound Interfaces consistof:

. HW Data Export

. Measurement Data Export

. 3GPP CORBA Basic Configuration Management NorthboundInterface (for topology data)

. 3GPP CORBA Fault Management Northbound Interface.

. 3GPP Northbound PM export interface

7.2 NEMU

Network element management in CS core is achieved by using theNetwork Element Management Unit (NEMU). The NEMU is a computer unit based on the Windows Server 2003 operating system and industrial

server technology.

NEMU provides a complete set of applications for managing networkelement data and interfaces independent of the type of network element. Itincreases network reliability, decreases operational and maintenancecosts and provides powerful and open interfaces. Examples of suchapplications include HLR N+X Redundancy, Network Element BackupServer and HLR Workstation. NEMU also provides basic elementmanagement (EM) functions and intelligent NetAct interfaces for Multimedia Gateway (MGW).






NEMU is available for Mobile Services Switching Centre (MSC), MSC

Server (MSS) and Home Location Register (HLR). In Multimedia Gateway(MGW) it is included automatically. Located in these elements, the NEMUcan be connected to Nokia NetAct and the CCBS with CORBA and/or FTPover LAN.

The DX 200 NEMU server is called MSC/HLR NEMU. It is based on a 3rdparty commercial HW server to provide adjunct services as well asmediation services.

In IPA 2800-based MGW network element, NEMU is called MGW NEMU.It is an integrated plug-in unit included in every IPA 2800 -based networkelement.

Security in Network Element Management Unit

NEMU provides a complete set of applications for managing networkelement data. It provides common management applications andinterfaces independent of the type of network element. NEMU offers aplatform for a wide variety of different solutions such as open subscriber management interface, automated real-time backup of the 2G and 3Gnetwork elements, and support for network element redundancy.

Information security is of primary importance when transferring data

between the client and NEMU. Information security issues cover bothplatform security and the security of subscriber data, which must beprotected at all times. To raise the security level, the IPSec security systemcan be installed in the routers. To be able to use the services provided byNEMU, user privileges are needed. These are defined by user roles.

The O&M personnel can be divided into different user roles according totheir tasks, and each role has different privileges. The NEMU user management is used for creating, modifying and deleting the user roles.During the installation and configuration of NEMU, information about theuser roles is entered into the NEMU authority system. There areusername/password mechanisms for application level connections toNEMU. For more information on the security in NEMU, see M and Urelease product documentation.

7.2.1 MSC/HLR NEMU

Examples of NEMU applications used with the Mobile Services SwitchingCentre (MSC), MSC server (MSS), Home Location Register (HLR) includeNetwork Element Backup Server, HLR redundancy features, HLRWorkstation and Fast Subscriber Management.





Network Element Backup Server

The primary function of the NE Backup Server (NEBS) is to automate thedaily routines in taking backups of a network element (HLR, HLRi, MSC,MSCi, MSS). The system also supports transferring backups to a remotelocation such as the main operation centre or, for example, a backup HLR.The NE Backup Server also makes it easier to carry out database analysison the platform. For example, it is possible to connect a HLR workstation(SQL Base) directly to the backup system.

When the NE Backup Server is used, there is no need for DAT tapebackups. Also, the NE Backup Server provides automatic backups duringlow traffic, and reduces the need for visits to unmanned sites. The NEBackup Server guarantees that the latest network element backup isavailable even during unexpected situations like natural catastrophes. Automated backups save costs and increase productivity, and provideadditional time for the staff to concentrate on other, more valuable tasks.The NE Backup Server offers real-time backup control from a single point,and thus visits to unmanned sites can be reduced significantly.

The NEBS also supports the N+1 and 2N Redundant HLR. In the case of N+1 redundancy, one HLR can back up all the live HLRs in the network,and the Redundant HLR can be activated in less than 30 minutes. Thus, N+1 redundancy provides a good redundancy level with optimised

operational costs and investments.

HLR Workstation

HLR Workstation is a feature containing two functions: investigation of databases and finding possible errors from databases. With HLRWorkstation it is easy to find out information on statistical figures such ashow the use of supplementary services has developed during the past sixmonths or how many subscribers use the data services at a givenmoment. With ready-made reports, the information is automaticallydelivered to the user's desktop. HLR Workstation also provides apossibility to convert the HLR database to ASCII format.

Subscriber Management Mediator is a part of the HLR Workstationfunctionality. It is a process that replicates the network element data to theSQL database according to user-defined periods and provides an openinterface for subscriber data mass queries. The data is located in arelational database, the SQL Server, which enables easy data adaptation.






The NEBS supports the HLR Workstation feature. The interaction between

these features enables transferring the subscriber databases to the HLRWorkstation so that the databases can be studied more thoroughly. TheNEBS updates data every 24 hours. As a result, DDS tapes are notnecessary anymore, although DDS tapes and MO disks can be usedlocally as removable media.

HLR redundancy features

The HLR reundancy features include N+X HLR redundancy, Multivendor HLR redundancy

N+X HLR redundancy

The N+X HLR Redundancy feature offers real-time subscriber datareplication from active HLRs to the N+X HLR Redundancy server. After theapplication has been configured, the user can start the replication. First,the data of all the subscribers is fetched from the active HLR and stored inthe server. Whenever the subscriber data in the active HLR changes, it isautomatically updated by the N+X HLR Redundancy server. The user canmonitor the subscriber data replication status via a GUI. The user can alsoadd new active HLRs to the replication group or remove currently activeHLRs from the replication group.

In case an active HLR is damaged and can no longer be used, theredundant HLR is activated. Signalling is re-routed to the redundant HLRand the N+X HLR Redundancy application simultaneously creates thesubscribers to the redundant HLR so that the HLR switchover is not visibleto the mobile subscriber.

N+X HLR Redundancy supports the Hostel (including QoS/Fraud profiles), Acrare, Vihdat, and Engine databases. The SAM14 version of N+X iscompatible with legacy systems, and supports both M13 and M14 softwarelevel HLRs.

Waste basket, as part of N+X functionality, provides protection againstaccidental subscriber deletion. Deleted subscribers are saved in a wastebasket buffer, from where the user can select subscribers, based oninternational mobile subscriber identity (IMSI) range or time factor, andrestore them back to the HLR.

For more information on the functionality of the N+X HLR redundancyfeature, see Network Element Management Unit Product Description in M-release product documentation.

Redundant HLR signalling activation macro





The redundant HLR signalling activation macro is needed in a situation

where one of the active HLRs has failed and a redundant HLR is going tobe taken into use by switching the traffic with the GT result modification.This macro can be used, if the signalling point code (SPC) of theredundant HLR and the links from every gateway MSC (GMSC) are usedin the network topology.

The benefit for the operator is faster signalling activation in the N+X and N+1 concepts. Especially in the N+X concept the benefit is clear; after signalling activation, subscribers are created to the redundant HLR basedon network transactions. There is no need for manual MML commands inGMSC, as the macro automates the work.

Multivendor HLR redundancy

Multivendor HLR Redundancy (MVR) is a solution that provides disaster recovery in a multivendor environment. It creates backup copies of theessential subscriber information from the vendor's HLR to the redundantHLR , and updates the data when information on the CCBS changes. Incase one or several vendors' HLRs fail, the redundant HLR is activatedand the traffic is routed to the redundant HLR. With the subscriber dataintact, the redundant HLR replaces the failed HLR in the network andenables the operational network despite the HLR failure.

Multivendor HLR Redundancy is a simple, concentrated solution wherebackup data is updated when a subscriber is added to or removed from thenetwork. After the subscriber data has been initialised for the first time, thedata is updated continuously with CCBS log files. The initialisation can bedone with the terminal window of the vendor network element, or usingsubscriber databases in ASCII format. Only essential subscriber data,such as IMSIs, MSISDN, Ki, basic profile and activation status, istransferred to the Remote Backup Server (Remote BS).

For more information on the Multivendor HLR redundancy feature, seeNetwork Element Management Unit Product Description in M-release

product documentation.Fast subscriber management

Fast Subscriber Management (FSM) offers an open and fast machine-to-machine interface for handling the data of one subscriber at a time in a DXnetwork element. This gives operators the possibility to have applicationsthat can manage subscriber data faster than applications operating via theexisting man-machine interfaces (MMI). FSM also supports asynchronousoperations and mass operations for some of the services. FSM offers a






CORBA interface, operated through the client-side user interfaces. This

provides easier access to 3rd party products with different subscriber management applications. The traditional subscriber managementinterface via MML is still working and updated.

For more information on the Fast Subscriber Management feature, seeNetwork Element Management Unit Product Description in M-releaseproduct documentation.

7.2.2 MGW NEMU

The main purpose of MGW NEMU is to offer the NWI3 interface towardsNetAct. NEMU also provides post-processing functions for performanceand trace data. NEMU acts as a mediation function between MGW andNetAct, that is, forwards alarms, performance measurements and tracerecords from MGW to NetAct.

Configuration Management

Nokia Siemens Networks provides a man-machine-interface (MMI) for configuration management of the MGW. MML commands can be givenlocally or by using remote connections from NetAct over Telnet protocol.MMLs can also be used via MMI Window offered by MGW NEMU.

Fault Management

Alarms generated by fault management are carried to NetAct via NWI3interface offered by MGW NEMU. MGW NEMU also provides a GraphicalUser Interface (GUI) available for handling alarms via NEMU. FM GUI alsosupports external alarms.

Performance Management

There are two ways of handling of measurements: local GUI of ElementManager and MMLs. In MGW NEMU measurements can be viewed andmanaged locally with Element Manager by using NE MeasurementExplorer GUI.

Statistic information is accessible locally or remotely via MGW NEMU GUI,or remotely in the NetAct. Statistic reports (measurements andobservations) can be transferred to Nokia NetAct in XML format, after which NetAct processes the XML-formatted files.

Subscriber trace





Nokia NetAct Tracing consists of TraceViewer application. TraceViewer

offers efficient means to trace mobile equipment or subscribers in GSM,GPRS and 3G networks. TraceViewer supports System Level Tracefunctionality that is implemented in various Nokia network elements. WithNokia NetAct Tracing, operators can improve their network planning,monitoring and optimisation tasks.

MGW trace reports can be transferred via NEMU to NetAct where they canbe viewed in NetAct TraceViewer. MGW Trace reports can also be viewedin NEMU. For more information on Nokia NetAct Trace Viewer, seeSubscriber Trace in section Nokia NetAct.

MGW NEMU also offers several other value added services, mostly GUIsfor different purposes, such as Diagnostics and State Handling GUIs, areintroduced. For more information, see MGW Operability Solution Description in U-release product documentation.






Related Topics

Backbone connectivity solutionReference network for packet backbone solution

Core network site functionality and design

IP connectivity

GPRS and 3G packet core site solution

MSC Server System site solution

Push to Talk over Cellular site solution

Products used in the core network site solution

MMS and browsing site solution

Controller site solution

Site interconnection (backbone)

IP/MPLS backbone

Related Topics

cs core system overview

Documents