Overview
HLR Redundancy means that a backup registration of certain extensions will be performed, when the ordinary HLR cannot be accessed. A temporary backup HLR in a different server (LIM) is used. If the ordinary HLR recovers, a re-registration back towards this HLR can be done. In order not to overload the ordinary HLR’s server, the re-registration will be performed with a delay and distributed in time for IP extensions. CXN supports re-registration (Duration). Each location area regulates the load for CXN extensions.
Some services, like group functions and busy or queue functions are lost while registered to the backup HLR. Some services that depend on common or centralized resources can also be lost depending on configuration, see the section Interactions with other features.
If an arbitrary server (LIM) fails, SIP-, CXN-, and H.323-extensions can be temporarily registered to a backup HLR, located in another server (LIM) than the ordinary home LIM. With other words, a backup HLR is created when a generic user tries to register or re-register. To be able to create the backup HLR, a system database (Cassandra) with replication functions is used. The ULR will register towards the backup HLR.
Certain types of generic extensions, can be configured as “auto-registered”, and cannot support HLR redundancy. Those types are Remote extensions, certain SIP extensions (conference phones, elevator or reception SIP phones, MS Skype4B/Lync Forking clients for example), certain IP/SIP-DECT base stations and DECT-SMS servers, which are also implemented as a kind of auto-registered generic extension.
In the figure above Server X is the ordinary home server, where HLR is located. Server X is accessible, so the ordinary HLR is activated in Server X. ULR is registered to ordinary HLR, but located in Server Y.
There are a number of scenarios where HLR redundancy is relevant, from 2-LIM systems up to 124-LIM systems, with or without network redundancy. There are also scenarios with different server types or server capacities, from low-capacity Mitel ASU Lite to high-capacity standard servers. Ideally all servers should have similar capacities, to get a well-functioning and balanced system database environment.