What is the YateHSS/HLR cluster?
The YateHSS/HLR cluster is a mechanism that allows operators to increase the number of SS7 and Diameter transactions and the number of subscribers. A single cluster can contain up to 10 nodes and each node supports approximately 100,000 subscribers. Each node is identical to the others and contains:
as well as other modules for SS7/MAP and Diameter.
YateHSS/HLR
HSS/HLR/AuC SIM subscribers management
See the product here ››
How does the YateHSS/HLR cluster work?
The YateHSS/HLR cluster uses replication, so that each node contains the same subscriber information of the entire cluster. Replication allows for different equipment in the network to easily interrogate the YateHSS/HLR cluster, irrespective of subscribers’ possible identities.
Adding a new node
To add a new node, the operator needs to:
- set the PC, GT, connections to the STP (M2PA link or M3UA), and the Diameter connection to the DRA
Operators can use the YateMMI management interface to easily perform the first two configuration steps. After configuring the new node identity, the cluster connection to the other nodes is done automatically.
The first node is usually the one though which all the subscriber data is added/modified and is used as a reference point. If the first node is unavailable, the YateMMI will use a different YateHSS/HLR server.
The cluster module
The cluster module synchronizes subscriber information within all the nodes in the cluster. The new node will automatically synchronize to the rest of the nodes in the cluster in less than an hour.
If a node in the cluster is down and during that time subscriber information is updated or changed, the old information will only be marked as deleted. The cluster module will update the new subscriber information to the reconnected node and will finally delete the old information from the entire cluster.
YateHSS/HLR cluster for SS7/MAP use
Identifying subscribers and their location can be done through both IMSI and MSISDN unique to each subscriber.
Identifying the subscriber by the MSISDN
In the case of a mobile terminated (MT) call, the Gateway Mobile Switching Center (GMSC) receives the call for the subscriber. It must send a sendRoutingInfo to the YateHSS/HLR asking for the location where the subscriber is registered. In this case the subscriber is identified by the MSISDN.
The GMSC connects to any of the STPs in the network, as they are equivalent and any of them can route the cluster to perform Location Update. The STPs have a common identity, while the YateHSS/HLR nodes have different identities.
Identifying the subscriber by the IMSI
When the mobile device first registers to the network or when it moves to another area, it contacts the Visitor Location Register (VLR). The VLR notifies the YateHSS/HLR of the subscriber’s new location by sending an updateLocation request for the IMSI associated to the subscriber’s SIM card.
YateHSS/HLR cluster for Diameter use
In the case of Diameter, a subscriber can be identified though multiple possible identities (IMSI, MSISDN or different IMS and SIP identities).
Identifying the subscriber by the IMS public/private identity
The subscriber registers a public identity, but the authentication is done using a private identity. The private identity can be provisioned in the SIM card or it can be derived from the IMSI. After the registration procedure, the YateHSS/HLR cluster knows which S-CSCF will provide services for this subscriber.
When the subscriber receives an MT call or an SMS, these are sent to one of his public identities. The I-CSCF interrogates any YateHSS/HLR cluster to find the S-CSCF that handles that service for the specific public identity.
Identifying the subscriber by the IMSI
When a subscriber connects to the MME in the Visited Network, its location needs to be updated through by the IMSI. The MME starts a location update procedure, and connects to a DRA. The DRA knows which YateHSS/HLR can perform the location update and interrogates the correct one.
The YateHSS/HLR replies with a single, longer message that contains all the requested information. The procedure is different in LTE network because Diameter is an IP based protocol that can route longer messages.
What happens when a node is down?
Ideally, all the nodes in the YateHSS/HLR clusters work without issues. However, some problems may still arise:
- In this case, a very small number of subscribers might be affected: just those whose location information changed recently and wasn’t propagated to the other servers.
- The other nodes will handle all the requests until this node is back up and resynchronized.
- If the users notice a problem and reboot their phones, the location information will be updated, and their service will be restored.
- In this case, the location could be updated in one node but the other node is interrogated.
- It is advisable to disconnect the server completely. Still, if there are only two nodes, then resynchronizing them is trickier and is done on a case by case basis.
In conclusion, when problems appear with one of the nodes, some of the subscribers could experience some missed SMSs/calls, but the network continues to function and the other nodes take the load of the affected node.
Conclusions
We have noticed that most small operators and MVNOs need traffic capacity more than increasing their network’s subscriber capacity. By choosing our solution, operators can easily add a new node to increase the number of transactions and to balance traffic between the YateHSS/HLR nodes in the cluster. The YateHSS/HLR cluster allows operators to scale as they go, so there is no need to invest in an expensive solution from the start.
Through the cluster protocol that connects all nodes in the cluster, the new element rapidly synchronizes to the rest of the nodes and is ready for use. A cluster with nodes that use the replication technology reduces equipment investment because it does not require the deployment of custom STPs and DRAs, which can choose from the subscribers divided between the nodes.
Even if one of the entities is down and some subscribers could be affected if changes were updated in that node and weren’t replicated, the majority of the subscribers won’t be affected so service continuity is assured.
