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 etween them through
!"# protocol:
$ HLR application
$ "%& application
$ !'# application
$ !(! application
)enefits:
1. &an e implemented in a classical "#* ased platform ut also on E)+ ased platform , Ericsson
)lade +-stem.
2. !oile 'umer #ortailit- ,!'#. and !(! are new functional options which can e deplo-ed as a
stand-alone Front Ends or in comination with other functional entities ,e.g. HLR/ "%&. offering a higher
fle0iilit- of deplo-ment.
3. Improved features parit- permitting that more operators to move into 1ata La-ered "rchitecture
without impact on currentl- provided services.
4. Fast implementation of !(! support in HLR-FE to e0plore new usiness models to increase
revenue and e0pand usiness.
The UDC2s mandator- parts are the HLR-FE and the "u&-FE. HLR-FE offers the %1& interface
towards the &ore 'etwor3 and interfaces the following functional components inside the solution:
- &entrali4ed %ser 1ata )ase: suscrier data storage/ providing a single point of access to the
suscrier data to HLR-FE. &ommunication etween HLR-FE and &entrali4ed %ser 1ataase is performed
- means of L1"# v5 protocol.
- #rovisioning 6atewa-: provisioning protocol termination/ writing the provisioned suscrier data
into the &entrali4ed %ser 1ataase. &ommunication etween #rovisioning 6atewa- and HLR-FE is
performed - means of !!L commands. #rovisioning 6atewa- is a functionalit- which can e emedded in
&entrali4ed %ser 1ataase s-stem.
HLR-FE Functions
HLR-FE is processing suscrier location/ activit-/ and supplementar- service information and acts as the
front-end interface etween the &%1) and the moile networ3 infrastructure. This means that HLR-FE is
the component responsile for updating the networ3 after oth traffic or provisioning activities and also
providing authentication vector in order to guarantee suscriptions securit-.
Functions:
- &all Handling function 7 HLR-FE is responsile for all suscrier related data oth 8d-namic9 data
,location and supplementar- service status. and permanent data ,suscrier-associated numers
and categor- information including services provided to the suscrier.
- HLR-FE is ale to interwor3/ as part of %1& solution/ oth with 6+! phase 1/ 6+! phase (/ 6+!
phase (: and 56## release ; networ3s
- support for 1ata &ommunications advanced services
- 6#R+ support. " !"# ased interface is supported in order to connect HLR-FE node with +erving
6#R+ +upport 'ode ,+6+'..
- <&1!" capailities provide support for sending and receiving circuit-switched multimedia/ which
use an- comination of voice/ video and data simultaneousl-/ such as real-time video-telephon-/
video show or still image while tal3ing
- H+1#"
- Ericsson innovative services are also implemented:
a. &"!EL/ &ustomi4ed "pplications for !oile networ3 Enhanced Logic/ provides the mechanisms to
support operator specific services that are not covered - the standardi4ed 6+! services/ also when
roaming outside the H#L!' - using Intelligent 'etwor3 ,I'. principles.
. !oilit- !anagement Intelligent 'etwor3 Triggering allows a complete new line of services to provide
end-users with functionalit- to tailor their suscriptions to etter fit their individual needs at each moment.
c. Location +ervices for oth pac3et and circuit switched domain/ provides the HLR-FE support to
!oile #ositioning +-stem ,!#+./ and also supports multi-vendor moile positioning environments.
d. Roaming +ervice Restriction provides with means to fle0il- control restriction of suscrier services
in a specified area.
e. E0tended Roaming +ervice &ontrol allows fle0il- - eitherinducing or changing suscrier services
per roaming area.
f. Immediate +ervice Termination enales the supervision and disconnection/ if necessar-/ of all call
activities of the suscriers
AUC-FE Functions
The main function of the "u&-Front End is to provide to HLR and H++ the authentication vectors needed -
the authentication and ciphering processes used within the networ3. The "u&-Front End follows the 56##
specifications.
" direct !"# interface is provided towards Home +uscrier +erver ,H++. for I+I! "uthentication and =e-
"greement ,"=".. I!+ "=" is the scheme for authentication and 3e- agreement in I!+.
=e- characteristics of the Ericsson "u&-Front End:
High capacit- and high availailit-
1esigned for fle0ile configurations
"uthentication and ciphering data provided in real time
%se of distriuted processors for authentication vectors generation
%se of mechanisms to minimi4e the ris3 of fraud
"%& R15.( also provides I+I! auth data upon re>uest from H++.
M!-FE Functions
The !'#-FE/ as a numer portailit- environment ta3es part in the routing of call and non-call related
messages. It does this ased on suscrier2s moile numer portailit- data from &%1) which is otained
through a download mechanism. !'#-FE also participates in the suscrier provisioning process for
numer portailit- related data/ performing the validation of the suscrier data efore eing stored in
&%1). The storage is done - the #6.
The !'#-FE has sophisticated mechanisms for control of overload at application level ,!"#. and signaling
networ3 level ,+&&#. during high traffic situations allowing thus a >uic3 deplo-ment of new services to
networ3 suscriers. "lso/ 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 !(!-Front End node provides mechanisms to allow the operator to administer and handle !achine-to-
!achine suscri"tions and to administer the networ3 I# addresses. It allows configuring the !(! devices
without end user intervention.
)- means of downloading the !(! user data/ the !(!-FE node controls the roaming of the !2!
suscriers# the handling of short messages services# handling of $%R&-related services.
The node updates the &%1) with the induced changes on the !(! suscrier profile and performs the
validation of the !2! suscrier data efore eing stored in the &%1). The storage is done - the #6.
"utomatic 1evice &onfiguration support is also included and allows the networ3 to configure automaticall-
the !(! devices for use of data services - identif-ing non configured !(! devices and sending out
configuration +!+ messages to them.
The !(!-FE is connected to the +6+' - a !"# ased interface.
This document contains a general overview of the HLR-FE functions and connections to the other networ3
elements.
(. HLR-FE logical interfaces towards the core nodes
Let2s ta3e a loo3 at the logical view of the %1& interfaces:
The HLR-FE/ as part of %1& s-stem product/ is a controlling node/ which onl- communicates with
other entities with signaling ,no speech connections are set-up to the HLR-FE.. +upported protocols are
compliant to relevant 6+! and 56## specifications. The HLR-FE is connected to different t-pes of networ3
elements:
1' !&C()LR
The 'umer ; protocol !oile "pplication #art ,!"#. is supported etween the HLR-FE and other
6+!?<&1!" entities ,!+&/ 6!+& etc.. Ericsson supports five different !"# protocols@ 6+! phase 1
!"# ,!"# version 1./ 6+! phase ( !"# ,!"# version (./ Ericsson protocol phase 1 !"#/ Ericsson
protocol phase ( !"# and 6+! phase (: !"# ,!"# version 5. ,including 56## Releases.
2' $atewa* !&C +$!&C,
6atewa- !+& ,6!+&. interrogates the HLR-FE for all terminating calls. HLR-FE then sends routing
information after fetching suscrier data from &entrali4ed %ser 1ataase. The same !"# protocols/ ut
different operations/ are supported etween 6!+& and the HLR-FE as mentioned aove.
-' &hort !essage &ervice $!&C +&!&-$!&C,
+hort !essage +ervice 6!+& ,+!+-6!+&. interrogates the HLR-FE for terminating +hort !essage
+ervices. The same !"# protocols/ ut different operations/ are supported etween +!+6!+& and the
HLR-FE as etween the !+&?ALR and HLR-FE.
.' &!&-/0!&C
,+!+-I<!+&. provides the interwor3ing !+& for +hort !essage +ervice ,+!+-I<!+&.. HLR-FE uses
+!+-I<!+& to alert the +ervice &entre when the suscrier is reachale again after an unsuccessful short
message transfer. The same !"# protocols/ ut different operations/ are supported etween +!+I<!+&
and the HLR-FE as etween the !+&?ALR and HLR-FE.
1' AUC-Front End
"uthentication &entre Front End provides the HLR-FE with authentication data.
" !"# ased protocol is used etween the HLR-FE and the "%&-Front End. This interface handles the
fetching of authentication vectors.
2' &erving $%R& &u""ort 3ode &$&3
The +erving 6#R+ +upport 'ode ,+6+'. fetches from &entrali4ed %ser 1ataase 6#R+ suscription
data and routing information via HLR-FE. " !"# ased protocol is supported etween the HLR-FE and the
+6+'.
4' &ervice Control %oint +&C%,
+ervice &ontrol #oint ,+&#. provides the connection etween +&# and HLR-FE is meant for the +&# to
retrieve information aout the moile station at an-time during an I' call. " &+1: ased protocol is
supported etween the HLR-FE and the +&#. 6+! +ervice &ontrol Function ,gsm+&F.. HLR-FE fetches
from &entrali4ed %ser 1ataase the stored &"!EL suscription information. " !"# ased protocol is
supported etween the HLR-FE and the gsm+&F.
5' !oilit* $atewa* +!$,
!oilit- 6atewa- ,!6. HLR-FE interwor3s with it as if it were an !+&?ALR. The same !"# protocols are
supported as if it were an !+&?ALR.
6' $atewa* !oile Location Center +$!LC,
6atewa- !oile Location &enter ,6!L&./ which interrogates the HLR-FE for routing information in order to
otain moile positioning information stored in &entrali4ed %ser 1ataase from the serving !+&?ALR. "
!"# ased protocol is supported etween the HLR-FE and the 6!L&. "utomatic 1evice &onfiguration
,"1&. The "utomatic 1evice &onfiguration ,"1&. provides information aout changes in the moile user2s
e>uipment identit-. " !"# ased protocol is supported etween the HLR-FE and the "1&.
17' 8"erations &u""ort &*stem +8&&,
Bperations +upport +-stem ,B++./ which ma- e used for Bperation and !aintenance purposes. The
HLR-FE is also e>uipped with in-uilt BC! functionalit-/ which ma3es the B++ optional in %1& s-stem
product for this component. "#6DE/ "#6D5 and "#6D5?( use T&#?I# to connect to B++ s-stem.
11' Home &uscrier &erver +H&&,
Home +uscrier +erver ,H++./ which interrogates the HLR-FE in order to retrieve roaming information as
well as the suscrier data needed for the +h interface. " !"# ased protocol with Ericsson proprietar-
e0tensions is supported etween the HLR-FE and the H++.
5. HLR-FE signaling connectivit- with the &ore nodes
Each HLR-FE will e identified in the signaling networ3 and can e addressed directl- from &' nodes at all
signaling levels for routing purposes:
o "t the "CC! level each HLR-FE has its own E.1FD 6loal Title
o "t the MT!#M$UA level each HLR-FE has its own +ignaling #oint &ode
o "t the "CT! level each HLR-FE can have multiple local I# addresses ,either ecause the +&T#
association is multi-homed/ or ecause there are several +&T# associations allocated to the same HLR-
FE..
"ll the lades within a node share the same HLR-FE configuration: same own 6T and the same own +#&
,defined as Ghosted +#&2.. "lso the same local I# addresses are common in the HLR-FE. The HLR-FE on
Ericsson )lade H< includes an internal +#& for the +#H/ that internal +#& is not needed to e configured
in the &' nodes due to no traffic is going to e directed to that internal +#&.
In short/ the &' %1& signaling connectivit- is as follows:
o In general all the HLR-FEs will e directl- or indirectl- ,via +T#. connected via the signaling
networ3 to all &ore 'etwor3 nodes interwor3ing with HLR-FE. For e0ample/ !+&?ALRs will e connected to
all HLR-FEs. +ome nodes ma- onl- e connected to some HLR-FE.
o 1ata has to e configured at the &' nodes/ an- intervening nodes and the HLR-FE/ in order for
these two wa-s signaling to ta3e place. The HLR-FE supports T1!/ "T! and I# ,using !5%" C +&T#. as
signaling transport towards &' nodes.
"ll HLR?"%& Front Ends can wor3 as a pool. The amount of HLR?"%& Front Ends that can wor3 as a pool
depends on the ++;?+I6TR"' load sharing capailities of the nodes connected to them:
I Ericsson !+& ,R1D.1. C +T# ,R1D.1. support:
$ Loadsharing on ( routes at +&&# level
$ Loadsharing on D routes at !T# level
$ Loadsharing on FD routes at !5%" level
I Ericsson +6+' supports:
$ Loadsharing on ( routes at +&&# level
$ Loadsharing on J routes at !T# level
$ Loadsharing on J routes at !5%" level
"i%nalin% Distri&ution ("D) 'unction
The +1 is a mandator- function from the point of view of the %1& solution/ ut ma- or ma- not e provided
- the %1& +olution/ depends on customer re>uirements. It is not a ph-sical node ut a function that must
e performed - the core networ3 in order to full- reali4e the enefits of the %1& solution.
" +ignaling 1istriution Function allows distriution of the load from the &ore 'etwor3 nodes to the FEs in
the pool. The distriution function can e hosted either:
- - the &' nodes
- - an intermediate node ,such as +T# for ++; or standalone +LF node for
1iameter.
- - some of the FE ,+LF can e collocated on H++-FE.
,'etwor3 level distriution.
In the %1& solution architecture/ all the HLR-FEs form a "ool of -FEs an- one of which can handle an initial
!"# message incoming from the &' signaling networ3. The -FEs in the pool ma- all have e>ual capacit- or
some ma- have greater capacit- than others.
The +1 function is responsile for ta3ing re>uests addressed to the pool of $FEs and distriuting the
re>uest to a specific availale HLR-FE. This distriution should e done using a 8weighted capacit- round
roin9 algorithm such that the -FEs with the greatest capacit- handle the greatest numer of !"#.
Figure elow will e0plain the general %1& information flow:
,HLR-FE in pool.
1. " new !"# operation is originated - a &' node ,e.g. !+&.. The re>uest will e addressed using a 6T
,either an I!+I/ an !+I+1' or an HLR numer.
(. The +1 function either at the originating node or an intermediate node ,such as an +R#. distriutes the
re>uest to a specific HLR-FE. In this case/ the +1 function selects HLR-FE 1
5. The first message of this new !"# transaction is sent to HLR-FE 1
D. HLR-FE 1responds to the re>uest and includes its own 6loal Title ,6T-1. in the response.
J. The response to the re>uest at step 1 is now returned via the signaling networ3 to the &' node. The &'
node notes the 6T-1in the &g#" and sends suse>uent re>uests ,F. in the same transaction directl- to
HLR-FE (.
F. These re>uests are not suKect to +1 and are routed - the signaling networ3 directl- to HLR-FE(. The
+1 function used to distriute the initial message within the !"# transaction to a specific Front End in the
pool can e performed using standard signaling routing mechanisms: +&&# or !T#?!5%" or a
comination of oth.
Co((on Address
In the %1& solution architecture/ all the HLR-FE form a 8pool9 of -FEs an- one of which can handle an initial
!"# message incoming from the &' signaling networ3. "t the +&&# level the pool of -FEs is identified - a
common HLR numer 6loal Titles ased on I!+I !+I+1' or HLR 'umer for routing !"# operations are
translated into a single 1#& at +&&# level. This 1#& is a common +#& shared - all the -FEs in the pool
of HLR-FE. In addition each HLR-FE has its own +#&.
"CC!
+ignaling distriution for initial !"# messages can e done at +&&# level using 6loal Titles for +&&#
addressing ased on one of the following:
- an E.(1D !oile 6loal Title derived from the I!+I ,when &&ITT or IT%-T +&&# is used./ or an E.(1(
numer originall- derived from an I!+I ,when "'+I +&&# is used.@
- an !+I+1' ,E.1FD.@
- an HLR numer ,E.1FD.
!"# operations will e distriuted across several +&&# routes in load sharing mode. The precise numer
of routes will depend on the capailit- of the e>uipment in the &' node performing the +&&# distriution.
Each +&&# route will have a different HLR-FE as final destination.
MT!#M$UA
"t !T# level/ the signaling is distriuted via signaling lin3s in load sharing. If the HLR-FEs in the pool have
une>ual capacit-/ then ideall- this distriution should e done using 8capacit- weighted round roin9
scheduling to ensure that HLR-FEs are loaded according to their capacit-. If the HLR-FE in the pool have
e>ual capacit- then simple 8round-roin9 scheduling can e used.
"t !5%" level/ the signaling through I# is distriuted via +&&# associations in load sharing. If the
HLR-FE in the pool has une>ual capacit-/ then ideall- this distriution should e done using 8capacit-
weighted round roin9 scheduling to ensure that HLR-FE is loaded according to their capacit-. If this is not
availale/ then more associations should e allocated to those servers with greatest capacit- within the
overall limits of the numer of associations availale. If the HLR-FE in the pool has e>ual capacit- then
simple 8round-roin9 scheduling can e used.
"ll the HLR-FE form a 8pool9 of servers. "t the +&&# level the pool of servers is identified - a common
HLR numer. 6loal Titles ased on I!+I !+I+1' or HLR 'umer for routing !"# operations are
translated into a single 1#& at +&&# level. This 1#& is a common +#& shared - all the servers in the
pool of HLR-FE. In addition each HLR-FE has its own +#&. "t !T# or !5%" level initial !"# messages
directed towards the common +#& will e distriuted across the availale servers in the pool. Each
!T#?!5%" lin3set?association will have a different HLR-FE as final destination.