hlr /m2m/mnp/auc fe on blade hw, node description

PRELIMIN

ARY

HLR /M2M/MNP/AUC FE on Blade HW,Node Description

DESCRIPTION

1551-CSA 121 02/3 Uen PA3

PRELIMIN

ARY

Copyright

© Ericsson AB 2012. All rights reserved. No part of this document may bereproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due tocontinued progress in methodology, design and manufacturing. Ericsson shallhave no liability for any error or damage of any kind resulting from the useof this document.

1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Contents

Contents

1 General Information 1

1.1 Revision Information 1

1.2 Purpose and Scope 1

2 Introduction 3

2.1 Network Level Introduction 3

2.2 Node Level Introduction 6

3 System Architecture 9

3.1 Hardware Architecture 9

3.2 Software Architecture 11

4 Functions 17

4.1 Basic Features 17

4.2 Optional Features 21

5 Operation and Maintenance 29

5.1 Equipment (Hardware) Management 32

5.2 Configuration Management 33

5.3 Software Management 35

5.4 Performance Management 36

5.5 Fault Management 38

5.6 Security Management 39

5.7 Accounting 41

5.8 Access to HLR FE on Ericsson Blade 41

6 Characteristics 43

6.1 Traffic Profile 43

6.2 Subscriber Profile 43

6.3 Capacity 43

7 Interfaces and Protocols 47

7.1 HLR FE Interfaces 47

7.2 M2M FE Interfaces 49

7.3 AUC FE Interfaces 52

7.4 MNP FE Interfaces 52

1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

HLR /M2M/MNP/AUC FE on Blade HW, Node Description

7.5 Common O&M and Provisioning 54

Glossary 55

Reference List 59

1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

General Information

1 General Information

1.1 Revision Information

This is new document.

1.2 Purpose and Scope

This document provides a technical overview of Home Location Register (HLR)Front End, Machine-to-Machine (M2M) Front End, Authentication Centre (AUC)Front End and Mobile Number Portability (MNP) Front End on Blade HWincluding their functions, architecture, characteristics, operation & maintenanceand external interfaces. The document also serves as an entry point to HLR FEdocumentation and provides references to more detailed documents.

For simplicity of reading, in the following chapters when referring to HLR FE onBlade HW that will imply HLR FE, M2M FE, AUC FE and MNP FE otherwiseclearly stated.

This document is intended primarily for Ericsson and Ericsson customers.

11551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


2 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Introduction

2 Introduction

2.1 Network Level Introduction

The WCDMA Core Network Architecture is based on an evolved GSMcore network. A Logical view of HLR, M2M, AUC and MNP FE nodes in aGSM/WCDMA network is shown in Figure 1 to Figure 4.

Figure 1 Logical View of HLR Node in a GSM/WCDMA Network

31551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Figure 2 Logical View of a M2M FE Node in a GSM/WCDMA Network

4 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Introduction

Figure 3 Logical View of AUC FE Node in a GSM/WCDMA Network

51551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Figure 4 Logical View of MNP FE Node in a GSM/WCDMA Network

2.2 Node Level Introduction

2.2.1 User Data Consolidation (UDC)

User Data Consolidation (UDC) is the Ericsson Subscriber Data Managementsolution for every service and every access enabling centralization based onData Layered Architecture (DLA). It provides a centralized subscriber datarepository to different applications while the business logic runs on Front Endentities.

User Data Consolidation is a solution that allows the separation of traffic logic(HLR, AUC, MNP and M2M FE, for example) and data storage (CUDB) intodifferent components.

Logically, UDC consists of:

• HLR, AUC, MNP and M2M FE and the signalling interfaces to the CircuitSwitch and Packet Switch domains.

• Centralized User Database (CUDB), storing the complete user profile andthe operator’s data model. CUDB data model is user centric.

6 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Introduction

• Provisioning Gateway (PG), which provides a single point of provisioningfor the UDC solution.

User data is consolidated in CUDB providing a consistent view of the data,harmonized across the network into one logical layer.

2.2.2 Home Location Register (HLR) Front End

The HLR FE node plays a central role in the operation of a GSM/WCDMAnetwork, since it takes a fundamental part in the set up of calls in the network,location services as well as controls the roaming of the subscribers, based onthe subscriber data downloaded from CUDB.

HLR FE implements a mechanism to download from CUDB the subscriptiondata for service execution and operation completion purposes, also updatingthe CUDB with the induced changes on the subscriber data due to traffic.

HLR FE is deployed to process subscriber location, activity, and supplementaryservice information and acts as the front-end interface between the CUDBand the core network infrastructure.

HLR FE validates the provisioning data before PG updates CUDB.

HLR FE is available as stand alone or can optionally be collocated with AUC,MNP and M2M FE.

2.2.3 Machine to Machine (M2M) Front End

The M2M FE node provides mechanisms to allow the operator to administerand handle Machine-to-Machine subscriptions. It allows configuring theM2M devices without end user intervention.

It also controls the roaming of the M2M subscribers and it takes a fundamentalpart in the handling of short messages services and in handling of GPRS-relatedservices. To be able to do it, M2M subscriber data are downloaded from CUDB.

M2M is deployed to process M2M subscriber location, activity, andsupplementary service information considering M2M and acts as the front-endinterface between the CUDB and core network infrastructure.

M2M FE validates the provisioning data before PG updates CUDB.

M2M FE is available as stand alone or can optionally be collocated with HLR,AUC and MNP FE.

2.2.4 Authentication Centre (AUC) Front End

The AUC generates authentication and ciphering data according to the 3GPPspecifications. The purpose of the authentication security feature is to protect

71551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


the network against unauthorized use. It also enables protecting subscribers bydenying the possibility for intruders to impersonate authorized users.

The authentication data is used to ensure that the subscribers accessingthe system are the ones they claim to be, and not others using the sameInternational Mobile Subscriber Identity (IMSI). And also to ensure that thenetwork accessed by the subscriber is the one it claims to be.

AUC FE validates the provisioning data before PG updates CUDB.

AUC FE is available as stand alone or can optionally be collocated with HLR,MNP and M2M FE.

2.2.5 Mobile Number Portability (MNP) Front End

MNP FE node plays a key and central role in the operation of a GSM/WCDMAnetwork considering a number portability environment, since it takes afundamental part in the routing of call and non-call related messages in thenetwork, based on the subscriber data downloaded from CUDB.

The main function of the MNP FE, as part of Ericsson UDC offering, is toprovide Mobile Number Portability functionality that makes it possible forsubscribers to change GSM or WCDMA operator without changing theirtelephone number. The MNP FE follows the all relevant specifications appliedfor number portability on different markets.

Individual Mobile Number Portability subscriber data are stored in CUDB andfetched by MNP FE on traffic basis.

The MNP FE provides one kind of routing service. It gives the possibility toimport and export E.164 numbers to or from other networks.

It can handle call related messages that use the E.164 for routing.

It can handle non-call related messages that use the E.164, E.212 or E.214for routing.

MNP FE validates the provisioning data before PG updates CUDB.

MNP FE is available as stand alone or can optionally be collocated with HLR,AUC and M2M FE.

8 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

System Architecture

3 System Architecture

3.1 Hardware Architecture

The HLR FE Blade HW is built up with HLR blades, Signaling Proxy (SPX) andnetwork interfaces for IP (TDM interfaces are optional). SIS and IO is partof the system for connection to OSS.

The high-level architecture of the HLR FE on Blade HW is shown in figure5 below.

Figure 5 HLR FE Blade HW Overview

The HLR FE on Blade HW consists of the following components:

• HLR blades

• HLR FE Blade HW Middleware

• SPX (including Regional Processor (RP) equipment and Switch ControlBoard (SCB))

• APG Input / Output (APG-IO), Statistics And Traffic Measurement System(STS) and APG-Charging Handler Subsystem (APG-CHS) including SCB

• IS (including Integrated Site Edge Router (ISER), Site InfrastructureSupport (SIS) and Extension Switch Board (EXB)) and Switch ControlExtension Board (SCXB)

91551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


3.1.1 HLR Blades

The HLR blades use n+1 redundancy and the lowest step is 3 HLR bladeswhere after the scalability is per blade up to maximum capacity.

3.1.2 HLR-FE Blade HW Middleware

The Blade HW Middleware is responsible for the administration and supervisionof the HLR-FE Blade and enables traffic execution on processors with highavailability and load balancing. The Blade Middleware also comprises theVirtual Machine.

3.1.3 Signalling Proxy (SPX)

The Signaling Proxy is traditional 1+1 protected AXE CP HW equipment.It converts and routes SS7 signaling traffic (Optional TDM based signalingrequires a separate subrack). The HLR-FE Blade HW is always equipped with1 SPX. IP network connection is through ISER in the Blades subrack.

3.1.4 IO System

The first Blades subrack always includes a pair of Site Infrastructure Support(SIS) blades, used for Operation and Maintenance Support. It holds theconfiguration and current status information of the Blades infrastructure.

HLR-FE Blade HW is always equipped with 1 APG43, with 1+1 redundancy(used for regular IO activities and statistics).

IP network connection is through ISER.

3.1.5 IS Infrastructure

The first Blades subrack is equipped with two Integrated Site Edge Router(ISER) Blade Systems that work in a mated pair redundancy configuration andprovides L3 interfaces towards the external network(s). There are four GigabitEthernet ports per blade, with the following physical transceivers media types(blade variants):

• 1000Base-LX: Single Mode Optical Interface

• 1000Base-SX: Multi Mode Optical Interface

• 1000Base-T: Electrical Interface

10 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

System Architecture

3.1.6 Optional HW

Options can add functionality or add capacity to a node based on thedimensioning. The following options can be added to the Base Configuration.

3.1.6.1 HLR Blades

If additional capacity is required more HLR blades can be added

3.1.6.2 HLR Middleware

Middleware always needs to be added to the base configuration

3.1.6.3 TDM Signaling

C7/S7 over TDM signaling is supported for narrow-band and/or high speed(HSL) and is carried over SDH/STM-1 or SONET/OC-3. These options allowthe connection of TDM based signaling The GS is included in all TDM options.

• STM-1/OC-3 Interface - ET155-1 use MSP 1+1 protection and carriesthe narrow band or high speed signaling in the network. One ET155corresponds to 63 E1s or 84 T1s.

• C7/S7 link - Signaling capacity is dimensioned as approximately 0.3 Erlangper C7 link (ETSI) or 0.4 Erlang per S7 link (ANSI). One STEB boardsupports a maximum of 128 C7/S7 links. The boards are always deliveredin steps of 2 to provide redundancy.

• High Speed Signaling Link, HSL - HSL occupies a 2 Mbps (ETSI) link or1.544 Mbps (ANSI) link. Redundancy on network level is achieved bydeploying HSL in pairs. In normal mode, a single HSL have a load of 40%(0.4 Erlang). If the transmission link fails, traffic will switch to the alternativeHSL, which will then carry 80% load (0.8 Erlang). One STEB boardsupports a maximum of 4 HSL links. The boards are always delivered insteps of 2 to provide redundancy.

3.1.6.4 Plenum Coating (ANSI)

Plenum type inter-cabinet cables are not included in the base configuration forANSI. They are available as an option (per cabinet) for ANSI markets.

3.2 Software Architecture

The Figure 6 shows the AM-based structure of the AXE node, which consists ofthe following System Module (SM) types:

• Application Modules (AMs)

• Resource Module Platform (RMP)

111551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


• Control system (APZ)

Implemented SM and Specified System Module (SSM) are applicable for AMsand RMP.

The following common interfaces are used for communication among differentSMs:

• Application Platform Service Interface (APSI)

• Non-standardized interfaces towards APZ

AM AM

RMP

APZ

… AMs

Figure 6 AM-based Node Structure

Below some specific functions are relevant to software architecture.

Recovery

The Forlopp function provides the capability of recovering a software error witha Forlopp Release instead of a System Restart. From a system point of view aForlopp Release is one type of recovery action among several other possiblerecovery actions, which is illustrated in Figure 7.

12 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

System Architecture

G000019A

ForloppRelease

Recovery DecisionMatrix in APZ

SmallRestart

LargeRestart

AXE Normal State

ReloadUntil OK

Several

generations

Figure 7 Levels of Recovery

A Forlopp Release can be triggered by an APZ-detected program error, by afunction that hangs or by an order from the operator. But if the forlopp releasewith long delay time between request and completion or high frequency or higherror intensity of APZ-detected errors may escalate to an immediate systemrestart.

For more information, see document:Reference [1]

The selective restart function raises the threshold for restarts at particularerror types. It reduces the amount of failures disturbance that could not berecovered by a forlopp release. The selective restart can be used to keep thesystem in service by avoiding restarts during critical time periods. The detectedsoftware error (APZ-detected program error) decides if a recovery action mustbe performed and what type of recovery action is to be executed.

For more information, see document:Reference [2]

If a blade is down, all ongoing traffic operations this blade was handling are lost,but the new traffic operations will be redistributed among the remaining blades.

When traffic isolation is initiated, no new traffic is distributed to the blade that isunder traffic isolation. Only one blade can be isolated at a time.

Detailed information about Traffic Isolation is given in the Traffic Isolation ForHLR Front End Blade, please refer to Reference [3].

HLR FE on Blade HW is configurable to be globally blocked and traffic networkdisconnected when node available capacity is under a configured threshold.

Detailed information about the recovery mechanisms in HLR FE on Blade HW isgiven in the Recovery In HLR FE on Blade HW, please refer to:Reference [4] .

131551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


SAE Handling

Size Alteration Event (SAE) specifies the SAE number. The SAE Type canbe local or global. SAE number range is from 0 to 8192. The SAE numberrange of local type is from 500 to 899, and others are used for global type.The parameter Block is applicable for local SAE type not for global SAE type.The parameter Number of Individuals Expansion Size (NIE) is the file sizeexpansion for the SAE, which is dependent on the maximum data file sizedefined in an SAE participant block and the highest usable pointer value definedin the Operating System Area (OSA).

In principle, a typical SAE, such as the extension of the number of devices of acertain type in the applications system, is handled as follows:

• New extension modules with hardware units of the type in question aremounted and connected.

• Storage allocation for corresponding data records in the CP is initiated bymeans of a command, and executed automatically.

• The extension modules and hardware units in question are defined bymeans of commands.

Automatic size alteration is an extended functionality of the manual sizealteration of data files sub function. It can request size alteration of data filesat runtime, which allows the detection of under dimensioned SAEs and theninitiating size increase with minimum operator intervention.

Redundancy

The HLR blades use n+1 redundancy

There are a number of specific functions implemented by middleware in theHLR FE on Blade that provides redundancy:

• Any blade can serve any subscriber transaction, each one is isolated andcompleted in a single blade.

• SW mechanism for traffic/blade isolation: a blade can be taken in/out ofservice in a controlled way without traffic disturbance.

3.2.1 Cluster Handler

The Cluster Handler is a distributed function over all blades. It has clusterawareness and it provides applications on each blade with information aboutthe entire cluster.

The Cluster Handler is used to:

• Initialize a cluster

14 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

System Architecture

• To monitor the health of the cluster

• To recognize blade failure if it occurs

• To regulate the re-formation of the cluster when a blade joins or leavesthe cluster

• To present a consistent view of the cluster state to the applications

The Cluster handler function, all related command handling, the CP clusterstates and substates are described in the APZ Cluster Handler FunctionSpecification, please refer to Reference [5].

3.2.2 HLR Blade

3.2.2.1 Introduction

Blade is a single sided, IS-adapted element, configured to offer the followinglogical functionality:

• HLR FE

• AUC FE

• MNP FE

• M2M FE

151551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


16 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Functions

4 Functions

4.1 Basic Features

4.1.1 AUC FE

AUC FE provides communication towards HLR FE (collocated or external HLRFE) using the Ericsson variant of MAP version 1.

AUC FE is able to support this protocol on top of one of the following TCAPs:

• ITU TCAP

• An adapted ITU TCAP that resides on top of the ANSI SCCPConnectionless Service

• ITU TCAP version for China

• ITU TCAP version for Japan

Main basic AUC FE functions:

• Authentication vector generation generates the authentication vectorsrequested to AUC FE by HLR FE or HSS nodes. Authentication vectors canbe either triplets (for 2G authentication) or quintets (for 3G authentication).

• LDAP Subscriber Data Access Support in AUC FE, allowscommunication with the external database.

The AUC Front End makes provisioning data validation.

4.1.2 HLR FE

Main basic services handled by HLR FE are:

• HLR FE handles authentication processes for GSM and WCDMA mobilesubscribers.

• The HLR FE handles not only telephony, but also other GSM/3GPPdefined Teleservices and Bearer Services, as well.

• It provides full implementation of the latest standards in GSM for highcapacity data transmission (supports up to 64 Kbps data rates usingHigh-Speed Datacom Services) offering support for Data Communicationsadvanced services.

• GPRS support is also implemented with a set of GSM Phase 2+ BearerServices that allows subscribers to send and receive data in an end-to-end

171551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


packet transfer mode and enables efficient use of network resources forpacket mode data applications. A MAP based interface is supported inorder to connect HLR FE node with Serving GPRS Support Node (SGSN).

� GPRS offers support for packet data communications up to 115 Kbps.

� Full support of EDGE capabilities is provided in the HLR with speedsup to 384 Kbps.

• WCDMA capabilities provide support for sending and receivingcircuit-switched multimedia, which use any combination of voice, video anddata simultaneously, such as real-time video telephony, video show or stillimage while talking. The third generation HLR FE features provide speedsup to 384 Kbps (wide-area coverage) and 2 Mbps (local-area coverage).

• Short messages handling, allows sending and receiving alphanumericmessages from and to mobile stations over GSM or GPRS networks.

• LDAP Subscriber Data Access Support in HLR FE, allowscommunication with the external database.

The HLR FE makes provisioning data validation.

Multiple Classic HLR Node Redundancy Support in HLR Front End allowsprimary HLRs failures to be invisible to the cellular network by introducing astandby HLR FE that performs Redundancy functions for all primary HLRsfrom Redundancy Group.

HLR FE provides communication towards entities of the mobile network andthe Service Control Point (SCP), and it supports the following protocol versions:

MAP V3 Both Standard and proprietary additions to MAP version 3.



HLR FE provides communication towards AUC (collocated or external AUC)using the Ericsson variant MAP V1.

HLR FE is able to support these protocols on top of one of the following TCAPs:

• An adapted White CCITT TCAP that will reside on top of a connection�lessANSI SCCP

• A TC�generic interface used for the signalling systems ITU, JapaneseTTC and Chinese ITU

IP, ATM and STM are included as possible transport layers for signalling HLRFE supports the following signalling combinations:

• STM

18 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Functions

• ATM

• IP

• STM and IP

• STM and ATM

The signalling capacity is enhanced with the support of High Speed signallingLinks for GSM 850 / 900 / 1800 / 1900 and WCDMA nodes (up to 2 Mbit/s perlink). The ET155 device also provides a connection to SDH transport networkequipment with speeds up to 155 Mbit/s.

In addition, HLR FE also interworks with Home Subscriber Server (HSS), inorder to provide it with roaming, support on LTE authentication process as wellas with Sh interface related subscriber data.

4.1.3 M2M FE

Main basic services handled by M2M FE are:

• M2M FE handles authentication processes for GSM and WCDMA mobileequipments.

• GPRS support is implemented with a set of GSM Phase 2+ BearerServices that allows subscribers to send and receive data in an end-to-endpacket transfer mode and enables efficient use of network resources forpacket mode data applications. A MAP based interface is supported inorder to connect M2M FE node with Serving GPRS Support Node (SGSN).

� GPRS offers support for packet data communications up to 115 Kbps.

� Full support of EDGE capabilities is provided in the M2M FE withspeeds up to 384 Kbps.

• WCDMA capabilities provide support for sending and receivingcircuit-switched multimedia, which use any combination of voice, video anddata simultaneously, such as real-time video telephony, video show or stillimage while talking. The third generation HLR FE features provide speedsup to 384 Kbps (wide-area coverage) and 2 Mbps (local-area coverage).

• Short messages handling, allows sending and receiving alphanumericmessages from and to mobile stations over GSM or GPRS networks.

• Automatic Device Configuration support is also included and allows thenetwork to configure automatically the M2M devices for use of data servicesby identifying unconfigured M2M devices and sending out configurationSMS messages to them.

• LDAP Subscriber Data Access Support in M2M FE, allowscommunication with the external database.

191551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


The M2M FEmakes provisioning data validation.

Multiple Classic HLR Node Redundancy Support in HLR Front End forM2M allows primary M2Ms failures to be invisible to the cellular network byintroducing a standby M2M FE that performs Redundancy functions for allprimary M2Ms from Redundancy Group.

M2M FE provides communication towards entities of the mobile network andthe Service Control Point (SCP), and it supports the following protocol versions:




M2M FE provides communication towards AUC (collocated or external AUC)using the Ericsson variant MAP V1.

M2M FE is able to support these protocols on top of one of the following TCAPs:

• An adapted White CCITT TCAP that will reside on top of a connection�lessANSI SCCP

• A TC�generic interface used for the signalling systems ITU, JapaneseTTC and Chinese ITU

IP, ATM and STM are included as possible transport layers for signalling M2MFE supports the following signalling combinations:

• STM

• ATM

• IP

• STM and IP

• STM and ATM

In addition, M2M FE also interworks with Home Subscriber Server (HSS), inorder to provide it with roaming, support on LTE authentication process as wellas with Sh interface related subscriber data.

4.1.4 MNP FE

Mobile Number Portability for GSM and WCDMA networks enables a mobilesubscriber to retain his/her subscriber number when changing networkoperator. This feature supports routing of incoming and outgoing Call and NonCall related messages when E.164 numbering plan is used for addressing.

20 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Functions

Additionally, the LDAP Subscriber Data Access Support in MNP FE featureassociated to Mobile Number Portability is included. LDAP Subscriber DataAccess Support in MNP FE feature allows communication with the externaldatabase.

4.2 Optional Features

On the top of the basic GSM specified services, a number of Ericssoninnovative services are implemented in the HLR FE. These innovative servicesgive operating companies a unique ability to offer even more advanced controland end-user services.

HLR FE offer a great selection of optional features, which allow the mobileoperator to extend and enhance the functionality compared to what is providedwith the basic package. These features can be ordered feature per feature.This chapter shows the available Optional Features per functional area.

4.2.1 Access to Intelligent Network Services

The following optional features are available within the ‘‘Access to IntelligentNetwork (IN) Services’’.

Table 1 Optional Features for Access to IN Services, HLR

Feature Name

Retrieve Information to SCP from HLR and MSC/VLR in HLR (SDF)

Mobility Related Triggers in HLR

Any Time Interrogation in HLR

Access to Mobile IN Services in HLR

4.2.2 Advanced End-user Services

The following optional features are available within the ‘‘Advanced End-userServices’’ valid for HLR.

Table 2 Optional Features for Advanced End-user Services

Price Object Name

Explicit Call Transfer in HLR

Immediate Call Itemization subscription

Dual Numbering in HLR

Anonymous Call Rejection in HLR

Automatic Device Detection

211551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Price Object Name

Missed Call Alert in HLR

Collect Call Dialling Automatic (CCDA) in HLR (Brazil only)

4.2.3 AUC optional features

The following optional features are available within the ‘‘AUC’’.

Table 3 Optional Features for AUC

Feature Name

Domain dependant authentication vector generation in AuC

AUC (AXE) Additional Milenage function sets

AUC (AXE) Additional G-Milenage algorithms

AUC (AXE) A4 key Management

AUC (AXE) Customized A3/A8 Algorithm (GSM only)

AUC (AXE) Customized WCDMA Algorithm

AUC (AXE) Signalling Control Support

4.2.4 CAMEL Procedures

The following optional features are available within the ‘‘CAMEL Procedures’’.

Table 4 Optional Features for CAMEL Procedures, HLR

Feature Name

Home Network Services and Control for MT-SMS (MT- SMS CSI, CAMELPh4) in HLR

CAMEL Support in HLR for CS Mobility Management

CAMEL Support in HLR for Conditional Triggering Criteria

Home Network Dialing when Roaming

(D-CSI, CAMEL Ph3), in HLR

Home Network Initiated Calls (gsmSCF initiated calls, CAMEL Ph4) in HLR

Extended CAMEL Support

Camel Support for CS Call Control in HLR

CAMEL Support in HLR for GPRS interworking

CAMEL Support in HLR for MO-SMS

22 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Functions

4.2.5 HLR specific Ericsson features

The following optional features are available within the ‘‘HLR specific Ericssonfeatures’’.

Table 5 Optional Features for HLR specific Ericsson features

Feature Name

Multiple Subscription Support in HLR

Multiple classic HLR node redundancy

4.2.6 M2M FE Optional features

The following optional features are available within the ‘‘M2M FE’’.

Table 6 Optional Features for M2M FE

Feature Name

Encryption of LI sensitive data for M2M

MAP based interface HLR-AUC for M2M

IMS Centralized Services indicator support

Immediate Call Itemization subscription

Automatic Device Detection

Inter-zonal calls Operator Determined Barring for M2M

Roaming Service Restrictions for M2M

Extended Roaming Service Control for M2M

2G/3G Roaming Restriction for M2M (according to 3GPP R6)

Preferred Roaming Partner for M2M

SMS Spam Control for M2M

Remote Control Equipment for M2M

Unstructured SS Data (USSD) to External Node for M2M

Mobile Subscriber priority level in Channel Allocation for M2M

Real Time Charging for All (RTCfA) for M2M

High Speed DownLink Packet Access (HSDPA) for M2M

High Speed Uplink Packet Access (HSUPA) for M2M

Multi-Region for M2M

Logical-HLR for M2M

Unstructured SS Data (USSD) transparent transfer to gsmSCF

231551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


SMS Home Routing for M2M

Signalling Transport over IP for M2M

SCCP Policing for M2M

MAP Policing for M2M

MTP Policing for M2M

Retrieve Information to SCP and MSC/VLR for M2M

Mobility Related Triggers in HLR

Any Time Interrogation in HLR

Access to Mobile IN Services in HLR

GPRS interworking CAMEL Support for M2M

MO-SMS CAMEL Support for M2M

CS Mobility Management CAMEL Support for M2M

MT-SMS (MT-SMS CSI, CAMEL Ph4) Home Network Services and Controlfor M2M

CS Positioning for M2M

PS Positioning for M2M

Spatial Triggers Support for M2M

Multiple classic HLR node redundancy

4.2.7 MNP FE optional features

The following optional features are available within the ‘‘MNP FE’’.

Table 7 Optional Features for MNP FE

Feature Name

Prevention of SMS Fraud

Mobile Number Portability, SRF solution

Mobile Number Portability for Japanese Networks

IN-Based Solution for Number Portability

Mobile Number Portability Data Access

4.2.8 Network Optimization and Efficient Resource Management

The following optional features which are available within the ‘‘NetworkOptimization and Efficient Resource Management’’.

24 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Functions

Table 8 Optional Features for Network Optimization and Efficient ResourceManagement

Feature Name

Closed User Group in HLR

Support for Subscription Type Dependent Analysis in HLR

Remote Subscriber Procedure Mechanism

Enhanced Multi-level Precedence and Pre-emption Service in HLR

Unstructured SS Data (USSD) to External Node

3G .324M Multimedia support in HLR

Home controlled Optimal Routing at Late Call Forwarding

Mobile Subscriber priority level in Channel Allocation in HLR

Monitoring of Call Forwarding Registrations

Real Time Charging for All (RTCfA) in HLR

High Speed DownLink Packet Access (HSDPA) in HLR

High Speed Uplink Packet Access (HSUPA) in HLR

Multi-Region HLR

Logical-HLR

Unstructured SS Data (USSD) transparent transfer to gsmSCF

SMS Home Routing

4.2.9 Positioning

The following optional features are available within the ‘‘Positioning’’.

Table 9 Optional Features for Positioning

Price Object Name

Positioning in HLR for PS

Spatial Triggers Support in HLR

Positioning in HLR for CS

SAE Mobility Management in HLR

4.2.10 Regulatory Requirement

The following optional features are available within the ‘‘RegulatoryRequirement’’.

251551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Table 10 Optional Features for Regulatory Requirement

Price Object Name

Encryption of LI sensitive data in HLR

Global Equal Access in HLR

Wireless Priority Service (WPS) in HLR

Remote Control Equipment in HLR

Optimal Routing for Late Call Forwarding

4.2.11 Roaming and Fraud Control

The following optional features which are available within the ‘‘Roaming andFraud Control’’.

Table 11 Optional features for Roaming and Fraud Control

Feature Name

SMS Spam Control in HLR

Roaming Restriction per Subscription

Immediate Service Termination (IST) in HLR

Operator Determined Barring in HLR for inter-zonal calls

Operator Determined Barring in HLR for call forwarded-to number

2G/3G Roaming Restriction in HLR (according to 3GPP R6)

Extended Roaming Service Control in HLR

Preferred Roaming Partner in HLR

4.2.12 Signalling Network Management

The following optional features which are available within the ‘‘SignallingNetwork Management’’.

Table 12 Optional features for Signalling Network Management

Feature Name

Signalling Transport over IP in HLR

SCCP Policing in HLR

MAP Policing in HLR

MTP Policing in HLR

26 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Functions

4.2.13 Standard Services

Table 13 Optional Features for Standard Services

Feature Name

MAP based interface HLR-AUC

Personalized Ring Back Tone support

IMS Centralized Services indicator support

271551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


28 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Operation and Maintenance

5 Operation and Maintenance

This section describes the Operation and Maintenance (O&M) principles,architecture and functions of the HLR FE on Blade HW.

Operation and Maintenance of the HLR FE covers all the actions the operationpersonnel needs to do for the HLR FE in order to connect it to the surroundingmobile network, to supervise its performance, to maintain its functions andbehavior, and all the security infrastructure and documentation needed for O&M

The following definitions are used within the O&M area:

APG O&M DomainIn a HLR FE on Blade HW this is the part that shallbe managed over the APG. This part provides theHLR FE specific service and consists of the followingcomponents:

• HLR Blades

• SPX

• APG

Blade Single sided CP APZ 214 0x, based on GEP2. In caseof HLR FE on Blade HW a blade will be a HLR/AUC-Scontaining whole functionality required for HLR, AUC,that is mainly the application logic and the trafficinterfaces SUA and LDAP termination.

Cluster Handler A APZ platform function, which provides informationabout the blades in the cluster in a consistent manner.I.e. before the application is notified (on each blade)about the available blades, the platform will performchecks concerning the blade availability and thecommunication paths. If the cluster handler detectschanges in the cluster (transient or permanent changes),it will notify the application.

Counter A counter is a single piece of data representing an itembeing measured.

Element ManagerProvides end user functions for the management ofnetwork elements on an individual basis. An elementmanager may be integrated in, or separate to, thenetwork element. An element manager may managemore than one network element.

291551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Ericsson Network IQ (ENIQ)Ericsson Network IQ is a product for performancemanagement in multi-vendor and multi-technologyenvironments, deployed on a wide range of networktechnologies and data sources.

Key Performance Indicator (KPI)A main measurement indicator, used to reflect thestatus of vital functionality.

Network ElementComprises the node and the platform on which the nodeis developed. Multiple nodes may coexist on the samenetwork element. A network element corresponds to aphysical entity in the network.

Network Manager SystemHas the same functions as the subnetwork manager,but with a wider scope. The network manager coversthe complete operator network, interfacing subnetworkmanagers or the network element directly.

Network Statistics (NWS)NWS is the Operation Support System (OSS)performance management application. It receives andstores counters from the managed network elementsand generates statistical reports.

Node It is a collection of features and functions whichimplement major functionality in the network. A nodemay run on its own physical network element or maybe collocated with other nodes on the same networkelement. A node is either a logical or physical networkelement. It typically acts as a data source and sink, andhas a data communication or terminal equipment.

Service It is one feature or functionality within a node.

Subnetwork ManagerProvides common management functions for thesubnetwork. The subnetwork manager correlatesinformation from the subnetwork into a consolidatedview.

User Denominates the person using the element manager,the subnetwork manager, or the network managementsystem.

30 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


User Data Consolidation (UDC)The User Data Consolidation is a solution that allows theseparation of traffic logic and data storage: CentralizedUser Database (CUDB) into different components. Itcomplements Ericsson world leading HLR and providescentralized storage of the subscriber profile, where theconnected network applications can fetch subscriberinformation in real time. This repository offers asingle point of data access including single point ofprovisioning.

The O&M functions are grouped into the categories of Equipment (Hardware),Software, Configuration, Performance, Security, and Fault Management. Thesecan be accessed via a Management System.

The management systems are shown here:

Figure 8 Management system architecture

Management system architecture is divided in the following three layers:

• The top layer is the Network Management Layer. This layer comprisesapplications covering specific aspects (for example, Fault Handling) of allparts of a complete network, regardless of technology or vendor of themanaged network elements. The layer is responsible for the managementof the complete network, which can consist of multiple systems, for example3G and 2G systems.

• The middle layer is the Sub-Network Management Layer. This layermanages the different parts of the GSM or WCDMA system (for example,WCDMA Radio or Core Network). The OSS-RC is Ericsson's Sub-NetworkManager, supporting centralized operation and maintenance of the radio

311551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


access as well as the core networks of both GSM and WCDMA systems. Itcontains online client applications for day-to-day handling of O&M functions,such as the collection and evaluation of alarms and performance data. TheOSS-RC management solution is based on the Telecom ManagementNetwork (TMN) model and the 3GPP standards. Furthermore, the OSS-RCsupports open interfaces, such as the 3GPP IRP (CORBA based). Openinterfaces based on 3GPP Integration Reference Points (IRP) are mainlysupported between the OSS-RC and the Network Management System(NMS). The interface between network elements and the sub-networkmanagement systems is proprietary in 3GPP, and thus proprietary betweenthe HLR Blade and OSS-RC.

• The lowest layer is the Element Management Layer. This layer is meant formanagement of individual nodes especially during initial setup and on sitetroubleshooting. Each node or network component has its own dedicatedElement Manager.

5.1 Equipment (Hardware) Management

Figure below shows an overview of the HLR FE on Blade HW hardware. Notethat this is only an example of one possible hardware (HW) configuration.

Figure 9 Example of possible hardware (HW) configuration

32 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


The recommended tool for making initial HW configurations and to configurethe IS O&M Domain is the ISM GUI. In the ISM GUI it is possible to view and tomake initial configurations for all Blade Systems in the node.

After initial configuration of the HLR FE on Blade HW further APG O&M DomainHW configurations are to be done via WinFIOL. The application configurationscan also be done from OSS.

5.2 Configuration Management

In order to provide an O&M one node view for a blade system, the APG 43is being updating enhancing the handling of MML commands in the clusterintroducing the Cluster Operation Mode.

The capabilities that the AXE offer to operators for MML handling are thefollowing two factors:

• The CPs scope

• The Cluster Operation Mode

Under normal conditions, The Cluster Operation Mode is used and only it willbe described in this document.

There are supported two modes in the Cluster Operation Mode:

• "Normal" mode, which is intended for normal operations of the cluster. Inthis mode both, normal and expert operators have access.

• "Expert" mode, which is mainly intended for maintenance activities (e.g.SW upgrades/updates). In this mode only expert operators have access.

There are supported three sessions in the Cluster Operation Mode:

• Cluster session, to be used for cluster level operations including theconfiguration commands.

• Restricted CP session, which is mainly used to retrieve information forblade or perform some local activity (mainly maintenance related) that doesnot change configuration data. Generally, configuration commands arenot allowed in this session.

• Unrestricted CP session, which is mainly used for maintenance purposes.

In Normal mode the three sessions apply, but in Expert Mode only Clusterand Unrestricted CP sessions apply.

There are three scopes for the MML Session:

• Single blade: the commands are addressed to just one specific blade;

331551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


• CP group: the operator can specify the blades that are required to beaddressed;

• Nothing: the Operative Group (blades in active status) is addressed.

In case a command is sent to a group of blades, APG 43 also provides aconsistency check mechanism mainly based in the outcome of the commandsthat has been executed. If the outputs are identical then a single output is sentto the operator, while if at least one of the outputs deviates then all individualoutputs are sent to the user.

More specifically, whenever any of the following occurs (during configurationactivity performed through a Cluster session):

• Discrepancies between individual printouts. Result printouts are notcompared.

• Mixture of procedure and answer printouts.

• Restart of a blade.

• Manual interruption of the connection.

Then APG identify that as inconsistency and will provide a log file where any ofthe above events will be logged and will arise an alarm, if not already given.

The MML session overview that exist in HLR/AUC FE on Blade HW is shownbelow:

34 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Figure 10 MML Session Overview

5.3 Software Management

In this chapter it is analyzed the HLR FE on Blade HW from the SoftwareManagement point of view in order to ease these activities from an operatorpoint of view.

In DLA, according to the principles of the architecture at a given time any servercould handle any transaction related to any subscriber. Thus, in order to keepthe business logic all application servers must be configured with the samedata, specifically here for HLR/AUC FE we refer to Application configurationdata and Service specific data. This will restrict the SW Management in theHLR FE on Blade HW as will be explained through the rest of the chapter.

5.3.1 Software Upgrade

The different Blade System, and Attached System (SPX and APG), entitieshave their own dedicated upgrade (and update) procedures and basically eachentity have to be upgraded separately. Generally, the upgrade of the IS partsshall be done prior to the upgrade of the HLR parts.

The different Blade Systems and Attached Systems (SPX and APG) can beupgraded individually by means of their dedicated Element Managers. IS O&MDomain components and the APG O&M Domain use the OSS-RC Software

351551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Management Organizer (SMO) for software upgrades and updates. For HLRblades the software loading is done by function change on one blade only anda cloning procedure to all remaining blades.

The ISM-UI provides support for downloading and changing software for theblade systems, however not for the blade systems belonging to the APG O&MDomain.

The OSS-RC SMO application provides support for the software transfer to thenode and support for automated upgrade of the whole APG O&M Domain bymeans of OPS Scripts. The OPS scripts are run in the SMO either directly or ata later scheduled point in time. The progress is shown in SMO.

5.3.2 SW Management

SW management in HLR FE contains SW upgrade (release change) andupdate (correction loading), license management and node backup.

HLR FE supports remote upgrade (and update), which can secure upgrading(and updating) of software for all HLRs from a centralized point. The automationof the upgrade (and update) implementation procedure into a software scripteliminates manual handling faults, thus increasing network availability.

The APG and the CP have their own dedicated upgrade (and update)procedures. APG updates (there are no APG upgrades) are decoupled fromCP software changes (upgrades or updates).

Some optional features are controlled by License Key Files (LKFs) installed inLicense Management (LM), which is running on the APG and on the CP. Formore information, see:Reference [6]

After HLR installation, there are 60 days to install the LKF (Grace Mode). Analarm will be raised by LM if LKF is missing. Optional features are availablefor 60 days period after which all features under LM control will becomeunavailable when no LKF is installed.

The CP backup is ordered by a MML command, and APG backup is orderedthrough AP command or by using of OSS-RC. Automated backup handlingfeature provides automated system backups for CP and APG by softwarescripts running on the OSS platform, which supports the output of smallbackups and/or large backups at times specified by parameters.

5.4 Performance Management

Performance management is a reporting function and provides the possibilityto evaluate the effectiveness and Quality of Service (QoS) of the networkelements by means of statistical data for the whole network. The purpose is toidentify defects in the network components such that corrective actions can betaken in order to improve the overall performance of the network. In addition,performance management plays an important role in facilitating network

36 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


planning, dimensioning, provisioning, maintenance, and follow-up of In ServicePerformance (ISP), QoS and other essential quality indicators.

The HLR FE on Blade HW performance management is based on programcounters that are stepped at certain events. The majority of the counters,including all call related counters are managed within the APG O&M Domain.CUDB also provides applications with the possibility of defining their ownset of counters related to the data stored in CUDB. The application is basedon the definition of scripts that calculate the desired counters by accessingthe data stored in CUDB and output them in (eXtended Markup Language)XML files. The monitoring of these counters is done by activating MeasuringPrograms (MP). The MPs are generating files with PM data as configured. Therecording period is configurable to 5, or 15 minutes. They can be configuredfrom the OSS-RC which then regularly fetches the performance data for furtherprocessing and graphical presentation. The PM files are read from the HLRFE on Blade HW by using FTP/SFTP.

The performance data can be further exported from OSS-RC to an externalmanagement system and stored on persistent media.

Figure below shows overview of the Performance Management for the HLR FEon Blade HW nodes.

Figure 11 Overview of Performance Management counter collection andreporting for the HLR FE on Blade HW

371551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Within HLR FE on Blade HW the counters are grouped together into logicalentities called object types. There might be several object instances of thesame object type. Each object instance has its own set of counter values.

These values are collected into files according to the configurations of the MPs.The files contain a similar set of counters for each HLR Blade in the node. Thatis, the same object types and counters are monitored for each HLR Blade CPwithin the node and reported separately for each CP in one file.

In HLR FE on Blade HW, in order to provide one node view from thePerformance Management point of view the cluster level and blade levelcounters are provided.

5.5 Fault Management

5.5.1 Alarms and Events

Fault management comprises the handling, subscription and logging ofalarms and events. Alarms are issued by the system when it recognises afault or malfunction that requires immediate action. Events are indications ofnoteworthy situations which do not require any immediate action. The list ofevents may contain valuable information for troubleshooting.

In a blade system it is possible that a failure/event common to all the bladeswill be detected by each of the blades arising the alarm due to the same error.However all alarms can be handled centrally from the OSS-RC which plays akey role in this sense. Fault Management applications in OSS-RC take care ofthe alarm filtering presentation and post-processing.

Generated alarms include the identification of the affected blade(s) and thetype of fault.

Note that the blades and SPXs might require different OPIs for the same alarm.When searching for the corresponding alarm OPI it is essential to know if thealarm is issued by a blade or an SPX. This information can be retrieved fromthe alarm header which contains the name or alias of the issuing entity. Theblade default names (BC0, BC1,...) and SPX default names (CP1, CP2,...) areused unless other alias names are given by the operator. For more informationsee: Reference [7]

5.5.2 Troubleshooting

For troubleshooting activities the HLR FE on Blade HW offers the followingfunctions:

• Call Path Tracing

Allows to print complete link chains of used HW and SW resources fromincoming to outgoing accesses.

38 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


• Command Controlled Test Call

Allows to set up a Test Call towards a Test Object from a Test PositionPhone (mobile phone).

• Test mode

Allows the operator to force subscribers (test-subscribers) based on theIMSI to use a specified blade as primary blade and another one as a buddyblade at location update.

For more information see:Reference [7]

5.6 Security Management

HLR FE, M2M FE and MNP FE nodes require at least user identification andauthorization AXE provided functionalities in order to manage them. In theAUC case, due to the sensitive information managed and stored into the node,additional security management mechanisms. In the following chapters it isdescribed how to configure several AXE functionalities in order to protect thesensitive information and detect security violations. These functionalities are:

• Identification & authentication: to identify each user entering the system.

• Access control: to control the access to the node depending on the userwho enters commands, the terminal from where commands are enteredand the network element from which the messages come.

• Security audit trail: to detect security violations and performanceproblems, having log files and reports containing the transactions that havetaken place in the exchange.

These functionalities must be combined to get a high level of security, takinginto account two aspects (specially for AUC FE node)

• The sensitive information itself: secret keys must be protected toavoid unauthorized people to disclose them. The key data included inprovisioning commands related to key handling must be kept secret Forthis reason, they are stored encrypted.

• The way to get this sensitive information: all commands allowing access,tracing or debugging the RP software must be restricted to authorizedpersonnel.

In the exchange, security measures must be taken to avoid that plain key dataappears in any log file.

O&M tasks are not always achieved in the local alphanumeric terminals but inremote Operation and Maintenance Centers (OMC) so, in order to maintain ahigh security level, it is necessary that measures related to Identification and

391551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Authentication, Access Control, Security Audit Trail and exclusion commandsfrom log files are taken into account to configure these centers.

5.6.1 Identification and Authentication

The functionality of identification and authentication is provided by the AuthoritySystem in the Man�machine Communication Subsystem (MCS). It providesthe capability to identify each user entering the system.

User’s identification and authentication data consist of a Usercode, the identitycode given to an individual, and a Password, the secret code used to verify thatthe user is who claims to be.

5.6.2 Access Control

This function provides protection against unauthorized use of resources.

Three different mechanisms can be used in the node to provide the accesscontrol service:

• Access control to enter the system: it is based on identification andauthentication functionality and is used to control that only allowed userscan enter the system.

• Command authority: consist of restricting the use of selected commandsonly to allowed users and terminals.

• Policing: consist of access restrictions to certain nodes and networkelements. The first step in access control is to check that the user is definedin the system and to verify, asking for a password, that is who claims to be.

5.6.3 Security Audit Trail

Audit logs should be inspected on a regular basis and appropriate action shouldbe taken on detection of security breaches.

The Security administrator is the responsible for configuring and inspectingthe audit trail.

The logging function is broken down in such a way that it can record anyoperator action in the system in two different logging files:

• Command log: it must always be used (it is not optional). It stores allcommands, with the logging category set, that have altered data since thelast memory dump.

The command log file is stored on hard disk in the volume RELVOLUMSW,file RELCMDHDF.

40 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


• Transaction Log: it is an optional function. It records all commandtransactions and printouts of interest in AXE, according to preset loggingconditions. A command transaction is defined as a command and its checkprintout, procedure printouts and answer printout. Both commands andprintouts are stored on the same file.

5.7 Accounting

This functional area is not applicable in HLR FE/AUC FE/MNP FE nodes.

5.8 Access to HLR FE on Ericsson Blade

The following four alternatives are available for O&M accessing the HLR FEon Ericsson node:

• Remote Access via the Sub-Network Management

• A central site where most O&M daily tasks are performed. From there, itis possible to run OSS-RC Applications. The Remote Access requires theuse of O&M intranet for secure communication towards a HLR FE node.

• Remote Element Management Access via the O&M Intranet

Run the applicable Element Manager, either directly or by first logging intothe Sub-Network Management System. O&M intranet must be in placeif this option is used.

• Local Element Management Onsite (Via Subnet LAN)

In this case the applicable Element Manager is connected to the O&Mintranet via a subnet and therefore the other nodes in the network, besidesthe HLR FE on Ericsson node, can still be accessed as well.

• Local Element Management Onsite (Direct Connection)

In this case the applicable Element Manager is directly connected to theHLR FE node, and there is no connection to the O&M intranet.

411551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


42 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Characteristics

6 Characteristics

The traffic model herein described takes into account the traffic receivedand generated by HLR FE node due to normal network function. Such aninformation is obtained considering a default traffic profile and subscriberprofile, described as well.

6.1 Traffic Profile

The main parameters related with traffic affecting the values shown on thetables are:

• 10% WCDMA subscribers and 90% GSM subscribers

• 100% GPRS and GSM subscribers

• GPRS active, CAMEL active, Location Services not active in the network.Average number of PDP contexts per subscriber (defined by profile) are 3.7.

6.2 Subscriber Profile

The main parameters related with traffic affecting the values shown on thetables are:

• GSM authentication: 3 triplets fetched per transaction

• WCDMA authentication: 3 quintets fetched per transaction

• 100% use of ISUP as signalling system

• 100% of VLR subscribers use MAP v3

6.3 Capacity

HLR FE, as UDC system product component, is not the entity permanentlystoring the subscriber data. Comparing it with the classical HLR node, thecapacity concept moves from a matter of subscriber capacity towards aprocessing capacity issue. However, since the processing needs are linked toa subscriber traffic profile, the capacity figures can be still provided in terms ofnumber of active subscribers in HLR FE.

In addition, HLR FE is not subject to a capacity analysis on its own. Whentaking part in UDC system product, it becomes an additional element for anexercise of network dimensioning.

431551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


This network dimensioning is not only based on HLR FE but also on CUDB andPG entities and an IP network in between.

In this UDC deployment scenario, and comparing with classical HLR node,all operations in HLR FE suffer an increase of the execution time needed tobe performed basically because of the introduction of the LDAP interface.However, the memory limit is not an issue in case of HLR FE, which is the caseof classic HLR for some APZ versions.

As mentioned before, HLR FE capacity also depends on the subscriber trafficprofile. Not all MAP operations require the same LDAP queries and, therefore,the different proportion of MAP operations from different subscriber trafficprofiles generates a different proportion of LDAP queries. This results thatdifferent traffic profiles reflects in different subscriber processing capacity inan HLR FE.

In addition, the activation of some optional features (like Multiple SubscriptionSupport, Mobile Number Portability and Preferred Roaming Partner) will implyadditional LDAP queries to obtain the needed data from CUDB, based on thesubscriber data model for UDC.

Apart from LDAP access, another aspect to be taken into account for capacityfigures calculation is the volume of SOAP notifications to be received fromCUDB. These notifications are linked to SAE Mobility Management function inHLR, when active. Capacity figures are to be calculated in both APG40/43and CP parts inside HLR FE.

However, this processing capacity is not an issue only at node level. UDCdeployment can easily solve it by escalating to the needed number of HLRFE nodes to cope with the subscriber capacity and activity demanded by theentire operator network.

The dimensioned HLR FE must be able to handle not only busy hour traffic, butalso peak load. The Ericsson HLR FE is designed as a high capacity node inorder to cope with these extreme situations

In summary, the capacity of an HLR FE has to be calculated for eachnetwork (traffic and subscriber profile, network deployment, etc.) and foreach functionality level. The HLR FE capacity is basically dependent on theprocessor limit; the required memory amount is not an issue apart from thesystem limits.

6.3.1 Dimensioning Assumptions

The subscriber numbers in the tables are referring to the maximum amount ofHLR subscribers and the same number of AUC subscribers that can be servedby the HLR FE on Blade HW node. These maximum values are obtained bytaking into account the 20% traffic peak margin.

44 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Characteristics

Table 14 HLR FE on Blade HW 13B capacity figures for ETSI standard

APZ 212 60

Number of subscribers 51 317 500

Table 15 HLR FE on Blade HW 13B capacity figures for ANSI standard

APZ 212 60


Table 16 MNP FE on Blade HW 13B capacity figures for ETSI standard

APZ 212 60


Table 17 MNP FE on Blade HW 13B capacity figures for ANSI standard

APZ 212 60


The maximum subscriber figures are presented here as the total node capacity.These subscriber numbers are the results of the adjusted calculation imposedby the limitation of any component of the cluster node.

451551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


46 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Interfaces and Protocols

7 Interfaces and Protocols

There are several interfaces and protocols on the HLR FE node. Find below asummary of them.

7.1 HLR FE Interfaces

The HLR FE is connected to different types of network elements:

• AUC FE

Which provides to the HLR FE authentication data.

A MAP based protocol is used between the HLR FE and the AUC FE. Thisinterface handles the fetching of authentication vectors.

• CUDB

Subscriber data storage, providing a single point of access to the subscriberdata to HLR FE. Communication between HLR FE and CUDB is performedby means of LDAP v3 protocol. Notifications from CUDB to HLR FE dueto SAE Mobility Management function, when a subscriber is roaming fromGPRS into SAE domain, are performed by means of SOAP 1.1 protocol.

• DCR

Which provides information about changes in the mobile user equipmentidentity.

A MAP based protocol is supported between the HLR FE and the DeviceConfiguration Register (DCR).

• HLR

Primary HLRs share the traffic load while the standby HLR FE is used forredundancy purposes. The mated pair of HLRs always consists of one of Nprimary HLRs and the standby HLR FE.

The signalling between primary HLRs and the standby HLR FE is carriedout by means of the Ericsson variant MAP V1.

• GMLC

Gateway Mobile Location Center (GMLC) interrogates the HLR FE forrouting information in order to obtain mobile positioning information fromthe serving MSC/VLR.

A MAP based protocol is supported between the HLR FE and the GMLC.

471551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


• GMSC

Gateway MSC (GMSC) interrogates the HLR FE for all terminating calls.HLR FE then sends routing information.

The same MAP protocols, but different operations, are supported betweenGMSC and the HLR FE as mentioned above.

• gsmSCF

HLR FE stores the CAMEL subscription information.

A MAP based protocol is supported between the HLR FE and the GSMService Control Function (gsmSCF).

• HSS

Which interrogates the HLR FE in order to retrieve roaming information aswell as the subscriber data needed for the Sh interface. A MAP basedprotocol with Ericsson proprietary extensions is supported between theHLR FE and the HSS.

• MG

HLR FE interwork with Mobility Gateway (MG) as if it were an MSC/VLR.

The same MAP protocols are supported as if it were an MSC/VLR.

• MNP FE

Which provides the functionality that makes it possible for subscribersto change GSM or WCDMA operator without changing their telephonenumber. The MNP FE follows the all relevant specifications applied fornumber portability on different markets.

• MSC/VLR

MSC/VLR handles location updating procedure, sending of authenticationvectors and restoration related procedures.

The Number 7 protocol Mobile Application Part (MAP) is supportedbetween the HLR FE and other GSM/WCDMA entities (MSC, GMSC etc.).Ericsson supports five different MAP protocols: GSM phase 1 MAP (MAPversion 1), GSM phase 2 MAP (MAP version 2), Ericsson protocol phase1 MAP, Ericsson protocol phase 2 MAP and GSM phase 2+ MAP (MAPversion 3) (including 3GPP Releases).

• OSS

Which may be used for Operation and Maintenance purposes. The HLRFE is also equipped with in-built O&M functionality, which makes the OSSoptional in UDC system product for this component.

48 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


APG40, APG43 and APG43/2 use TCP/IP to connect to OSS system.

• PG

Provisioning protocol termination implemented in Ericsson MultiActivation (EMA), writing the provisioned subscriber data into the CUDB.Communication between PG and HLR FE if performed by means of MMLcommands.

• SCP

The connection between SCP and HLR FE is meant for the SCP to retrieveinformation about the mobile station at anytime during an IN call.

A CS1+ based protocol is supported between the HLR FE and the SCP.

• SGSN

HLR FE contains GPRS subscription data and routing information.

3GPP MAP based protocol is supported between the HLR FE and theSGSN.

• SMS-GMSC

Short Message Service GMSC (SMS-GMSC) interrogates the HLR FE forterminating Short Message Services.

The same MAP protocols, but different operations, are supported betweenSMS-GMSC and the HLR FE as between the MSC/VLR and HLR FE.

• SMS-IWMSC

HLR FE uses Interworking MSC for Short Message Service (SMS-IWMSC)to alert the Service Centre when the subscriber is reachable again after anunsuccessful short message transfer.

The same MAP protocols, but different operations, are supported betweenSMS-IWMSC and the HLR FE as between the MSC/VLR and HLR FE.

• SMS-R

SMS Router (SMS-R) is an optional node in the network used when SMSHome Routing function is active. MAP based protocol is used betweenHLR FE and SMS-R.

7.2 M2M FE Interfaces

• AUC FE

Which provides to the M2M FE with authentication data.

491551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


A MAP based protocol is used between the M2M FE and the AUC FE. Thisinterface handles the fetching of authentication vectors.

• CUDB

Subscriber data storage, providing a single point of access to the subscriberdata to M2M FE. Communication between M2M FE and CUDB is performedby means of LDAP v3 protocol.

• DCR

Device Configuration Register (DCR) is updated by M2M FE, using aproprietary MAP message, with the needed relevant data to configure theM2M devices.

• GMLC

Which handles mobile positioning information stored in CUDB from theserving MSC/VLR.

• GMSC

Gateway MSC (GMSC) interrogates the M2M FE for all terminating calls.M2M FE then sends routing information.

The same MAP protocols, but different operations, are supported betweenGMSC and the M2M FE as mentioned above.

• gsmSCF

M2M FE stores the CAMEL subscription information.

A MAP based protocol is supported between the M2M FE and the GSMService Control Function (gsmSCF).

• M2M

Primary M2Ms share the traffic load while the standby M2M FE is used forredundancy purposes. The mated pair of M2Ms always consists of one ofN primary M2Ms and the standby M2M FE.

The signalling between primary M2Ms and the standby M2M FE is carriedout by means of the Ericsson variant MAP V1

• MG

MG interworks with the M2M FE as if it is a MSC/VLR.

• MNP FE

Which provides the functionality that makes it possible for M2M subscribersto change GSM or WCDMA operator without changing their telephone

50 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


number. The MNP FE follows the all relevant specifications applied fornumber portability on different markets.

• MSC/VLR

MSC/VLR handles location updating procedure, sending of authenticationvectors and restoration related procedures.

The Number 7 protocol Mobile Application Part (MAP) is supportedbetween the M2M FE and other GSM/WCDMA entities (MSC, GMSC, etc.).Ericsson supports five different MAP protocols: GSM phase 1 MAP (MAPversion 1), GSM phase 2 MAP (MAP version 2), Ericsson protocol phase1 MAP, Ericsson protocol phase 2 MAP and GSM phase 2+ MAP (MAPversion 3) (including 3GPP Releases).

• OSS

Which may be used for Operation and Maintenance purposes. The M2MFE is also equipped with in-built O&M functionality, which makes the OSSoptional in UDC system product for this component.


• PG

Provisioning protocol termination implemented in Ericsson MultiActivation (EMA), writing the provisioned subscriber data into the CUDB.Communication between PG and M2M FE if performed by means of MMLcommands.

• SGSN

M2M FE contains GPRS subscription data and routing information.

3GPP MAP based protocol is supported between the M2M FE and theSGSN.

• SMS-GMSC

SMS-GMSC interrogates the M2M FE for terminating Short MessageServices.

The same MAP protocols, but different operations, are supported betweenSMS-GMSC and the M2M as between the MSC/VLR and M2M FE.

• SMS-IWMSC

M2M uses SMS-IWMSC to alert the Service Centre when the subscriber isreachable again after an unsuccessful short message transfer.

The same MAP protocols, but different operations, are supported betweenSMS-IWMSC and the M2M FE as between the MSC/VLR and M2M FE.

511551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


• SMS-R

SMS-R is an optional node in the network used when SMS Home Routingfunction is active. MAP based protocol is used between M2M FE andSMS-R.

7.3 AUC FE Interfaces

The AUC FE is basically connected to HLR FE, CUDB, Operation andMaintenance systems and administration systems.

• CUDB

Subscriber data storage, providing a single point of access to the subscriberdata to AUC FE. Communication between AUC FE and CUDB is performedby means of LDAP v3 protocol.

• HLR FE

AUC FE provides the HLR FE (collocated or external) with authenticationdata.

An Ericsson MAP proprietary protocol is used between the HLR FE and theAUC FE. This interface handles the fetching of authentication vectors.

• HSS

AUC FE provides an external HSS with 3G authentication data.

An Ericsson MAPv1 proprietary protocol is used between the HSS and theAUC FE. This interface handles the fetching of authentication vectors.

• OSS

Which may be used for Operation and Maintenance purposes.

• PG

Provisioning protocol termination implemented in Ericsson MultiActivation (EMA), writing the provisioned subscriber data into the CUDB.Communication between PG and AUC FE if performed by means of MMLcommands.

Note: From HLR/AUC Front End perspective, same interfaces as in theclassic HLR/AUC are kept. Additionally, LDAP V3 is used for thecommunication of HLR/AUC Front End and CUDB.

7.4 MNP FE Interfaces

• CUDB

52 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


Subscriber data storage, providing a single point of access to the subscriberdata to MNP FE. Communication between MNP FE and CUDB is performedby means of LDAP v3 protocol.

• Gateway MSC

Which interrogates the HLR FE for all terminating calls. It also interrogateswith a MAP query to the MNP FE to get the subscriber portabilityinformation (routing number) to route the call to the recipient network whenthe number is ported out.

• GMLC

Which interrogates the HLR FE for routing information in order to obtainmobile positioning information from the serving MSC/VLR.

• HLR FE

This is the receiver of terminating calls. According to number portabilityinformation, the call for a subscriber is routed to an HLR FE or to a node inthe recipient network.

A MAP based protocol is supported between the MNP FE and the HLR FE.

• Legacy HLR

It can be the receiver of terminating calls for which the portability is solvedin an environment where legacy HLRs are deployed and only the numberportability function is hosted in UDC.

• MC

Which interrogates the HLR FE for terminating Short Message Servicescalls.

All the interrogations to HLR FE mentioned above are intercepted by MNPFE to solve the portability and rerouting those interrogations to one HLR FEapplication in the own network or in the recipient network.

• MG

A functional entity which enables intersystem roaming. MG interworks withthe HLR FE as if it is a MSC/VLR.

• MSC/VLR

Which sends to the HLR FE the interrogation about the Completion of Callsto Busy Subscriber (CCBS) service and any other messages.

• OSS

Which may be used for Operation and Maintenance purposes. The MNPFE is also equipped with in-built O&M functionality, which makes the OSS

531551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


optional in UDC system product for this component. APG40, APG43 andAPG43/2 use TCP/IP to connect to OSS system.

• PG

Provisioning protocol termination implemented in Ericsson MultiActivation (EMA), writing the provisioned subscriber data into the CUDB.Communication between PG and MNP FE if performed by means of MMLcommands.

• SCP

SCP interrogates the HLR FE about the Location data and/or MobileSubscriber State. This node is also responsible of setting the proper tariffto prepaid and postpaid subscribers.

• SGSN

Is one of the General Packet Radio Service (GPRS) logical nodes providingpacket routing from the SGSN service area. SGSN interrogates the HLRFE about GPRS subscription data and routing information.

• SMS-GMSC

Which interrogates the HLR FE for terminating Short Message Servicescalls and requests the inclusion of a Service Centre address in the MessageWaiting Data list.

• SMS-IWMSC

SMS-IWMSC is an MSC capable of receiving a Short Message from thePLMN and submitting it to the recipient Service Centre.

7.5 Common O&M and Provisioning• EMA

Ericsson Multi Activation server (EMA) is a product providing CustomerAdministration Systems (CAS) to exchange information with Ericssonnetwork elements containing service information. The CAS can also beconnected directly to the node.

The EMA and CAS are connected through an X.25 or TCP/IP interface.The protocols Telnet and FTP will be available directly to the IO systemAPG40/43.

• OSS

OSS may be used for O&M purposes. The node is also equipped within-built O&M functionality, which makes the OSS optional.


54 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Glossary

Glossary

AMsApplication Modules

ANSIAmerican National Standards Institute

APGAdjunct Processor Group

APG-CHSAPG - Charging Handler Subsystem

APG-IOAPG Input / Output

APSIApplication Platform Service Interface

AUCAuthentication Centre

AXEAUC

BSBlade Systems

CASCustomer Administration Systems

CCBSCompletion of Calls to Busy Subscriber

CCDACollect Call Dialling Automatic

CPCentral Processor

CUDBCentralized User Database

DCRDevice Configuration Register

DLAData Layered Architecture

EMAEricsson Multi Activation

ENIQEricsson Network IQ

ETSIEuropean Telecommunications StandardsInstitute

EXBExtension Switch Board

FEFront End

GMLCGateway Mobile Location Center

GMSCGateway MSC

GPRSGeneral Packet Radio Service

gsmSCFGSM Service Control Function

HLRHome Location Register

HSDPAHigh Speed DownLink Packet Access

HSSHome Subscriber Server

HSUPAHigh Speed Uplink Packet Access

IMSIInternational Mobile Subscriber Identity

INIntelligent Network

551551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


INAPIntelligent Network Application Part

IRPIntegration Reference Points

ISERIntegrated Site Edge Router

ISPIn Service Performance

ISTImmediate Service Termination

KPIKey Performance Indicator

LKFsLicense Key Files

LMLicense Management

M2MMachine to Machine

MAPMobile Application Part

MCSMan�machine Communication Subsystem

MGMobility Gateway

MNPMobile Number Portability

MPMeasuring Programs

NIENumber of Individuals Expansion Size

NMSNetwork Management System

NPHNumber Portability Handler

NWSNetwork Statistics

O&MOperation and Maintenance

OMCOperation and Maintenance Centers

OPIOperational Instruction

OSAOperating System Area

OSSOperation Support System

PGProvisioning Gateway

QoSQuality of Service

RMPResource Module Platform

RPRegional Processor

RTCfAReal Time Charging for All

SAESize Alteration Event

SCBSwitch Control Board

SCPService Control Point

SCXBSwitch Control Extension Board

SDFService Data Function

SGSNGPRS Support Node

SISSite Infrastructure Support

SMSystem Module

56 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Glossary

SMOSoftware Management Organizer

SMS-GMSCShort Message Service GMSC

SMS-IWMSCMSC for Short Message Service

SMS-RSMS Router

SOAPSimple Object Access Protocol

SPXSignaling Proxy

SSMSpecified System Module

STSStatistics And Traffic Measurement System

TMNTelecom Management Network

UDCUser Data Consolidation

USSDUnstructured SS Data

WPSWireless Priority Service

571551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY


58 1551-CSA 121 02/3 Uen PA3 | 2013-02-12

PRELIMIN

ARY

Reference List

Reference List

HLR FE Blade References

[1] Forlopp Handling and Recovery, 12/1553-CRZ 214 01 Uen

[2] Selective Restart, 13/1553-CRZ 214 01 Uen

[3] Traffic Isolation In HLR Front End Blade, 3/155 17-CSA 121 02/2

[4] Recovery In HLR Front End Blade, 2/155 17-CSA 121 02/2

[5] Cluster Handler, 3/155 17-ANZ 250 01

[6] License Management, 1/19817-CSA 121 02/2 Uen

[7] HLR-FE on Ericsson blade HW Troubleshooting and EmergencyRecovery Guideline, 9/1553-CSA 121 02/2 Uen1

591551-CSA 121 02/3 Uen PA3 | 2013-02-12

http://gask2web.ericsson.se/service/get?DocNo=12/1553-CRZ21401&Lang=EN&Rev=D&Format=PDFV1R2

http://gask2web.ericsson.se/service/get?DocNo=13/1553-CRZ21401&Lang=EN&Rev=C&Format=PDFV1R2

http://gask2web.ericsson.se/service/get?DocNo=3/15517-CSA12102/2&Lang=EN&Rev=A&Format=PDFV1R2

http://gask2web.ericsson.se/service/get?DocNo=2/15517-CSA12102/2&Lang=EN&Rev=A&Format=PDFV1R2

http://gask2web.ericsson.se/service/get?DocNo=3/15517-ANZ25001&Lang=EN&Rev=A&Format=PDFV1R2

http://gask2web.ericsson.se/service/get?DocNo=1/19817-CSA12102/2&Lang=EN&Rev=A&Format=PDFV1R2&a=b

http://gask2web.ericsson.se/service/get?DocNo=9/1553-CSA12102/2&Lang=EN&Rev=B&Format=PDFV1R5

http://gask2web.ericsson.se/service/get?DocNo=9/1553-CSA12102/2&Lang=EN&Rev=B&Format=PDFV1R5

hlr /m2m/mnp/auc fe on blade hw, node description

Documents