HLR-FE Tutorial

The purpose of this document is to present an overview on the HLR-FE functions together with a short
presentation on how the node is connected to the core nodes from the logical and signaling point of view.

1. Introduction:
The HLR-FE 12A & User Data Consolidation (UDC) 12A solution

The HLR-FE 12A node is composed of four logical identities which communicate between them through
MAP protocol:

– HLR application
– AUC application
– MNP application
– M2M application

Benefits:

1. Can be implemented in a classical APZ based platform but also on EBS based platform ( Ericsson
Blade System)
2. Mobile Number Portability (MNP) and M2M are new functional options which can be deployed as a
stand-alone Front Ends or in combination with other functional entities (e.g. HLR, AUC) offering a higher
flexibility of deployment.
3. Improved features parity permitting that more operators to move into Data Layered Architecture
without impact on currently provided services.
4. Fast implementation of M2M support in HLR-FE to explore new business models to increase
revenue and expand business.

The UDC’s mandatory parts are the HLR-FE and the AuC-FE. HLR-FE offers the UDC interface
towards the Core Network and interfaces the following functional components inside the solution:

- Centralized User Data Base: subscriber data storage, providing a single point of access to the
subscriber data to HLR-FE. Communication between HLR-FE and Centralized User Database is performed
by means of LDAP v3 protocol.

- Provisioning Gateway: provisioning protocol termination, writing the provisioned subscriber data
into the Centralized User Database. Communication between Provisioning Gateway and HLR-FE is
performed by means of MML commands. Provisioning Gateway is a functionality which can be embedded in
Centralized User Database system.

HLR-FE Functions

HLR-FE is processing subscriber location, activity, and supplementary service information and acts as the
front-end interface between the CUDB and the mobile network infrastructure. This means that HLR-FE is
the component responsible for updating the network after both traffic or provisioning activities and also
providing authentication vector in order to guarantee subscriptions security.
 Functions:
- Call Handling function = HLR-FE is responsible for all subscriber related data both “dynamic” data
(location and supplementary service status) and permanent data (subscriber-associated numbers
and category information including services provided to the subscriber)

- HLR-FE is able to interwork, as part of UDC solution, both with GSM phase 1, GSM phase 2, GSM
phase 2+ and 3GPP release 7 networks

- support for Data Communications advanced services

- GPRS support. A MAP based interface is supported in order to connect HLR-FE node with Serving
GPRS Support Node (SGSN).

- WCDMA capabilities provide support for sending and receiving circuit-switched multimedia, which
use any combination of voice, video and data simultaneously, such as real-time video-telephony,
video show or still image while talking

- HSDPA

- Ericsson innovative services are also implemented:

a. CAMEL, Customized Applications for Mobile network Enhanced Logic, provides the mechanisms to
support operator specific services that are not covered by the standardized GSM services, also when
roaming outside the HPLMN by using Intelligent Network (IN) principles.
b. Mobility Management Intelligent Network Triggering allows a complete new line of services to provide
end-users with functionality to tailor their subscriptions to better fit their individual needs at each moment.
c. Location Services for both packet and circuit switched domain, provides the HLR-FE support to
Mobile Positioning System (MPS), and also supports multi-vendor mobile positioning environments.
d. Roaming Service Restriction provides with means to flexibly control restriction of subscriber services
in a specified area.
e. Extended Roaming Service Control allows flexibly by eitherinducing or changing subscriber services
per roaming area.
f. Immediate Service Termination enables the supervision and disconnection, if necessary, of all call
activities of the subscribers

AUC-FE Functions

The main function of the AuC-Front End is to provide to HLR and HSS the authentication vectors needed by
the authentication and ciphering processes used within the network. The AuC-Front End follows the 3GPP
specifications.
A direct MAP interface is provided towards Home Subscriber Server (HSS) for ISIM Authentication and Key
Agreement (AKA). IMS AKA is the scheme for authentication and key agreement in IMS.

Key characteristics of the Ericsson AuC-Front End:

 High capacity and high availability
 Designed for flexible configurations
 Authentication and ciphering data provided in real time
 Use of distributed processors for authentication vectors generation
 Use of mechanisms to minimize the risk of fraud

AUC R13.2 also provides ISIM auth data upon request from HSS.
MNP-FE Functions

The MNP-FE, as a number portability environment takes part in the routing of call and non-call related
messages. It does this based on subscriber’s mobile number portability data from CUDB which is obtained
through a download mechanism. MNP-FE also participates in the subscriber provisioning process for
number portability related data, performing the validation of the subscriber data before being stored in
CUDB. The storage is done by the PG.

The MNP-FE has sophisticated mechanisms for control of overload at application level (MAP) and signaling
network level (SCCP) during high traffic situations allowing thus a quick deployment of new services to
network subscribers. Also, for congestion event control, an automatic mechanism for traffic sensitive files
ensures an optimal usage of software resources in each moment.

M2M-FE Functions

The M2M-Front End node provides mechanisms to allow the operator to administer and handle Machine-to-
Machine subscriptions and to administer the network IP addresses. It allows configuring the M2M devices
without end user intervention.

By means of downloading the M2M user data, the M2M-FE node controls the roaming of the M2M
subscribers, the handling of short messages services, handling of GPRS-related services.
The node updates the CUDB with the induced changes on the M2M subscriber profile and performs the
validation of the M2M subscriber data before being stored in the CUDB. The storage is done by the PG.

Automatic Device Configuration support is also included and allows the network to configure automatically
the M2M devices for use of data services by identifying non configured M2M devices and sending out
configuration SMS messages to them.

The M2M-FE is connected to the SGSN by a MAP based interface.

This document contains a general overview of the HLR-FE functions and connections to the other network
elements.

2. HLR-FE logical interfaces towards the core nodes

Let’s take a look at the logical view of the UDC interfaces:

 The HLR-FE, as part of UDC system product, is a controlling node, which only communicates with
other entities with signaling (no speech connections are set-up to the HLR-FE). Supported protocols are
compliant to relevant GSM and 3GPP specifications. The HLR-FE is connected to different types of network
elements:

1. MSC/VLR

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

2. Gateway MSC (GMSC)

Gateway MSC (GMSC) interrogates the HLR-FE for all terminating calls. HLR-FE then sends routing
information after fetching subscriber data from Centralized User Database. The same MAP protocols, but
different operations, are supported between GMSC and the HLR-FE as mentioned above.

3. Short Message Service GMSC (SMS-GMSC)

Short Message Service GMSC (SMS-GMSC) interrogates the HLR-FE for terminating Short Message
Services. The same MAP protocols, but different operations, are supported between SMSGMSC and the
HLR-FE as between the MSC/VLR and HLR-FE.

4. SMS-IWMSC
(SMS-IWMSC) provides the interworking MSC for Short Message Service (SMS-IWMSC). HLR-FE uses
SMS-IWMSC to alert the Service Centre when the subscriber is reachable again after an unsuccessful short
message transfer. The same MAP protocols, but different operations, are supported between SMSIWMSC
and the HLR-FE as between the MSC/VLR and HLR-FE.

5. AUC-Front End

Authentication Centre Front End provides the HLR-FE with authentication data.
A MAP based protocol is used between the HLR-FE and the AUC-Front End. This interface handles the
fetching of authentication vectors.

6. Serving GPRS Support Node SGSN

The Serving GPRS Support Node (SGSN) fetches from Centralized User Database GPRS subscription
data and routing information via HLR-FE. A MAP based protocol is supported between the HLR-FE and the
SGSN.

7. Service Control Point (SCP)

Service Control Point (SCP) provides the connection between SCP and HLR-FE is meant for the SCP to
retrieve information about the mobile station at anytime during an IN call. A CS1+ based protocol is
supported between the HLR-FE and the SCP. GSM Service Control Function (gsmSCF). HLR-FE fetches
from Centralized User Database the stored CAMEL subscription information. A MAP based protocol is
supported between the HLR-FE and the gsmSCF.

8. Mobility Gateway (MG)

Mobility Gateway (MG) HLR-FE interworks with it as if it were an MSC/VLR. The same MAP protocols are
supported as if it were an MSC/VLR.

9. Gateway Mobile Location Center (GMLC)

Gateway Mobile Location Center (GMLC), which interrogates the HLR-FE for routing information in order to
obtain mobile positioning information stored in Centralized User Database from the serving MSC/VLR. A
MAP based protocol is supported between the HLR-FE and the GMLC. Automatic Device Configuration
(ADC) The Automatic Device Configuration (ADC) provides information about changes in the mobile user’s
equipment identity. A MAP based protocol is supported between the HLR-FE and the ADC.

10. Operations Support System (OSS)

Operations Support System (OSS), which may be used for Operation and Maintenance purposes. The
HLR-FE is also equipped with in-built O&M functionality, which makes the OSS optional in UDC system
product for this component. APG40, APG43 and APG43/2 use TCP/IP to connect to OSS system.

11. Home Subscriber Server (HSS)

Home Subscriber Server (HSS), which interrogates the HLR-FE in order to retrieve roaming information as
well as the subscriber data needed for the Sh interface. A MAP based protocol with Ericsson proprietary
extensions is supported between the HLR-FE and the HSS.
 3. HLR-FE signaling connectivity with the Core nodes

Each HLR-FE will be identified in the signaling network and can be addressed directly from CN nodes at all
signaling levels for routing purposes:

o At the SCCP level each HLR-FE has its own E.164 Global Title
o At the MTP/M3UA level each HLR-FE has its own Signaling Point Code
o At the SCTP level each HLR-FE can have multiple local IP addresses (either because the SCTP
association is multi-homed, or because there are several SCTP associations allocated to the same HLR-
FE).

All the blades within a node share the same HLR-FE configuration: same own GT and the same own SPC
(defined as ‘hosted SPC’). Also the same local IP addresses are common in the HLR-FE. The HLR-FE on
Ericsson Blade HW includes an internal SPC for the SPX, that internal SPC is not needed to be configured
in the CN nodes due to no traffic is going to be directed to that internal SPC.

In short, the CN   UDC signaling connectivity is as follows:

o In general all the HLR-FEs will be directly or indirectly (via STP) connected via the signaling
network to all Core Network nodes interworking with HLR-FE. For example, MSC/VLRs will be connected to
all HLR-FEs. Some nodes may only be connected to some HLR-FE.

o Data has to be configured at the CN nodes, any intervening nodes and the HLR-FE, in order for
these two ways signaling to take place. The HLR-FE supports TDM, ATM and IP (using M3UA & SCTP) as
signaling transport towards CN nodes.

All HLR/AUC Front Ends can work as a pool. The amount of HLR/AUC Front Ends that can work as a pool
depends on the SS7/SIGTRAN load sharing capabilities of the nodes connected to them:

› Ericsson MSC (R14.1) & STP (R14.1) support:

– Loadsharing on 2 routes at SCCP level

– Loadsharing on 4 routes at MTP level
– Loadsharing on 64 routes at M3UA level

› Ericsson SGSN supports:

– Loadsharing on 2 routes at SCCP level

– Loadsharing on 5 routes at MTP level
– Loadsharing on 5 routes at M3UA level

Signaling Distribution (SD) function

The SD is a mandatory function from the point of view of the UDC solution, but may or may not be provided
by the UDC Solution, depends on customer requirements. It is not a physical node but a function that must
be performed by the core network in order to fully realize the benefits of the UDC solution.

A Signaling Distribution Function allows distribution of the load from the Core Network nodes to the FEs in
the pool. The distribution function can be hosted either:
- by the CN nodes
- by an intermediate node (such as STP for SS7 or standalone SLF node for
Diameter)
- by some of the FE (SLF can be collocated on HSS-FE)

(Network level distribution)

In the UDC solution architecture, all the HLR-FEs form a pool of -FEs any one of which can handle an initial
MAP message incoming from the CN signaling network. The -FEs in the pool may all have equal capacity or
some may have greater capacity than others.

The SD function is responsible for taking requests addressed to the pool of –FEs and distributing the
request to a specific available HLR-FE. This distribution should be done using a “weighted capacity round
robin” algorithm such that the -FEs with the greatest capacity handle the greatest number of MAP.
Figure below will explain the general UDC information flow:
 (HLR-FE in pool)

1. A new MAP operation is originated by a CN node (e.g. MSC). The request will be addressed using a GT
(either an IMSI, an MSISDN or an HLR number.

2. The SD function either at the originating node or an intermediate node (such as an SRP) distributes the
request to a specific HLR-FE. In this case, the SD function selects HLR-FE 1
3. The first message of this new MAP transaction is sent to HLR-FE 1

4. HLR-FE 1responds to the request and includes its own Global Title (GT-1) in the response.

5. The response to the request at step 1 is now returned via the signaling network to the CN node. The CN
node notes the GT-1in the CgPA and sends subsequent requests (6) in the same transaction directly to
HLR-FE 2.

6. These requests are not subject to SD and are routed by the signaling network directly to HLR-FE2. The
SD function used to distribute the initial message within the MAP transaction to a specific Front End in the
pool can be performed using standard signaling routing mechanisms: SCCP or MTP/M3UA or a
combination of both.

Common Address

In the UDC solution architecture, all the HLR-FE form a “pool” of -FEs any one of which can handle an initial
MAP message incoming from the CN signaling network. At the SCCP level the pool of -FEs is identified by a
common HLR number Global Titles based on IMSI MSISDN or HLR Number for routing MAP operations are
translated into a single DPC at SCCP level. This DPC is a common SPC shared by all the -FEs in the pool
of HLR-FE. In addition each HLR-FE has its own SPC.

SCCP

Signaling distribution for initial MAP messages can be done at SCCP level using Global Titles for SCCP
addressing based on one of the following:
- an E.214 Mobile Global Title derived from the IMSI (when CCITT or ITU-T SCCP is used), or an E.212
number originally derived from an IMSI (when ANSI SCCP is used);
- an MSISDN (E.164);
- an HLR number (E.164)
MAP operations will be distributed across several SCCP routes in load sharing mode. The precise number
of routes will depend on the capability of the equipment in the CN node performing the SCCP distribution.
Each SCCP route will have a different HLR-FE as final destination.

MTP/M3UA

At MTP level, the signaling is distributed via signaling links in load sharing. If the HLR-FEs in the pool have
unequal capacity, then ideally this distribution should be done using “capacity weighted round robin”
scheduling to ensure that HLR-FEs are loaded according to their capacity. If the HLR-FE in the pool have
equal capacity then simple “round-robin” scheduling can be used.

At M3UA level, the signaling through IP is distributed via SCCP associations in load sharing. If the
HLR-FE in the pool has unequal capacity, then ideally this distribution should be done using “capacity
weighted round robin” scheduling to ensure that HLR-FE is loaded according to their capacity. If this is not
available, then more associations should be allocated to those servers with greatest capacity within the
overall limits of the number of associations available. If the HLR-FE in the pool has equal capacity then
simple “round-robin” scheduling can be used.

All the HLR-FE form a “pool” of servers. At the SCCP level the pool of servers is identified by a common
HLR number. Global Titles based on IMSI MSISDN or HLR Number for routing MAP operations are
translated into a single DPC at SCCP level. This DPC is a common SPC shared by all the servers in the
pool of HLR-FE. In addition each HLR-FE has its own SPC. At MTP or M3UA level initial MAP messages
directed towards the common SPC will be distributed across the available servers in the pool. Each
MTP/M3UA linkset/association will have a different HLR-FE as final destination.