About YateHSS/HLR

From YateBTS
Jump to: navigation, search

The YateHSS/HLR stores and manages the SIM database for mobile networks. It also manages multiple subscriber identities (from different technologies) in one server, providing seamless services over different networks. It is designed for use in GSM, UMTS, LTE, IMS, WiFi networks or any other type of network that uses MAP or Diameter for authentication.

The YateHSS/HLR includes a Home Location Register (HLR), an Authentication Center (Auc) (2G/3G) and a Home Subscriber Server (HSS) (4G LTE). The YateHSS/HLR exports a JSON API for integration with any SIM management and CRM systems. It is capable of interconnecting with all the VLRs implemented in a GSM mobile network, with any MME from a conventional LTE network, or with the YateUCN core network server.

As it is also an AuC, the YateHSS/HLR authenticates subscribers as they try to connect to the GSM, UMTS, or the LTE networks, to make phone calls, send SMSs and access mobile data.

YateHSS/HLR is catered to:

  • commercial solutions for MVNOs
  • medium or large MNOs

For roaming, YateHSS/HLR uses the SS7 (MAP) protocol in 2G networks and Diameter in 4G networks.

Important: We offer the SS7 configuration interface. For subscriber management you receive a JSON API which you must configure yourself.

YateHSS/HLR is easy to operate and manage remotely using the Yate Mobile Management Interface (MMI). The interface makes it accessible to add a new YateHSS/HLR unit, to setup a cluster of YateHSS/HLRs, to add subscribers, to modify and configure subscribers´ profiles and more.



  • Fully implemented in software using commodity hardware (e.g. Dell PowerEdge R430)
  • Scalable by adding multiple nodes in a cluster
  • JSON API over HTTP for configuration and management
  • Supports GSM, UMTS and LTE subscribers
  • Steering of roaming with hooks into external application
  • Multi-IMSI support with hooks into external application
  • Multi-operator support
  • Simultaneous support of MAP and Diameter
  • Super-Charger function supported in HLR
  • Separate CS, PS, EPS, IMS profiles for groups of subscribers
  • Configurable operator blocking in case of missing VPLMN features

Supported networks

  • 2G/3G over MAP (ETSI) protocol
  • 4G over MAP or Diameter protocol
  • IMS (VoLTE) over Diameter protocol

Supported authentication

  • 2G SIM using COMP128-1, 2 or 3 algorithms
  • 3G/4G USIM using MILENAGE algorithm
  • Derivation of 2G triplets from USIM quintuplets
  • IMS AKAv1-MD5 ISIM/USIM using MILENAGE algorithm
  • SIP MD5 Digest
  • Configurable partitioning of USIM/ISIM sequence number indexes

Communication protocols

    • ITU or ANSI SCCP and SS7 MTP
    • M2PA or M3UA-ASP over SIGTRAN, SCTP (CRC32)
    • E.164, E.212, E.214, TT or PC SCCP addressing
    • Can connect to multiple STP/GW
  • Diameter
    • 3GPP Applications S6a/S6d, Cx/Dx
    • SCTP or TCP transport
    • Can establish or listen for connections
    • Can connect to multiple Routing Agents
  • HTTP
    • JSON API server for configuration and subscriber management
    • REST API client for visited network change notification
  • SNMP
    • SNMP v2 or v3 for information retrieval
    • Traps sending for alarms
  • Telnet
    • Management CLI
    • Optional SSL and password protection

Supported services

  • Telephony calls
  • Short Message Service
  • Packet Switched Data
  • Evolved Packet System
  • IP Multimedia Subsystem

CS Services

  • Supplementary Services (per subscriber)
    • Call barring: BAOC, BOIC, BOIC-ExHC, BAIC, BIC-Roam
    • Call forwarding: CFU, CFB, CFNRC, CFNRY
    • Other: CLIR, CW, HOLD, MultiPTY
    • Password protection for service change
  • Operator barring (per subscriber)
  • CAMEL subscription (per profile)
  • USSD subscription (per profile)
    • Arbitrary number of prefixes to independent gateways

PS Services

  • Operator barring (per subscriber)
  • PDP Contexts (per profile)
    • Name, type, charging characteristics
    • QoS (basic + extensions)
    • APN OI Replacement, AMBR
  • CAMEL subscription (per profile)
  • APN OI Replacement (per profile)

EPS Services

  • PDN Connections (per profile)
    • Name, type, charging characteristics
    • QoS (LTE QCI, priorities)
    • APN OI Replacement, AMBR
    • PGW address and name
  • APN OI Replacement, AMBR, SRVCC, vSRVCC (per profile)

IMS Services

  • IMS private and public identities (per subscriber)
  • SIP username, authentication, realm (per subscriber)
  • Domain and CSCF configuration (per profile)
  • Initial Filter Criteria (per profile)
    • Configurable list of SPT groups
    • SPT types: RequestURI, Method, SIPHeader, SessionCase, SessionDescription
  • CAMEL subscription (per profile)
    • O-CSI, VT-CSI, D-CSI

High availability

  • Can be configured in a cluster of equal nodes
  • Subscriber data is replicated across all nodes
  • Requests can be distributed or balanced between nodes
  • Detection of communication failures
  • Automatic synchronization of new nodes
  • Automatic synchronization after failure

YateHSS/HLR in a 2G/3G network

YateHSS/HLR has all the functions of a typical HLR subscriber database, and those of a typical AuC, as described below.

The AuC is the database that authenticates each SIM card that tries to connect to the 2G/3G core networks. As soon the SIM is authenticated, the HLR takes over and manages the SIM and its services. Each authentication involves an encryption key used to secure all the wireless communications between the mobile station and the core network.

The SIM card is the main identifier per subscriber that stores:

  • the international mobile subscriber identity (IMSI)
  • the shared secret authentication key (Ki)
  • an integrated circuit card identifier (ICCID)

The IMSI is the number used for identifying a subscriber. It has 15 digits or less and contains:

  • the Mobile Country code (MCC)
  • the Mobile Network Code (MNC)
  • the Mobile Subscription Identification Number (MSIN)

Also stored in the HLR is the MSISDN, also known as the subscriber's phone number.

The authentication key (Ki) is an input to an algorithm used for authenticating the SIM card to the mobile network. It is stored in both the SIM and the AuC, but encrypted over the network. The authentication process is a challenge/response mechanism without ever revealing the secret key.

YateHSS/HLR stores which services are assigned to the subscriber, such as: telephony, SMS, CAMEL, call forward unconditional, call forward no reply, call forward not reachable, barring of all incoming calls, call waiting, call hold, call line identification presentation, calling line identification restriction, connected line presentation, connected line restriction, multiparty.

YateHSS/HLR uses the SS7 MAP protocol to perform roaming. It also uses the following SS7 protocols for 2G/3G connectivity: SIGTRAN, SCTP with CRC checksum, M2UA ASP, ITU MTP, SCCP, TCAP, ANSI MTP, SCCP and TCAP.

YateHSS/HLR in a 4G network

YateHSS/HLR has all the functions of Home Subscriber Server central database in an LTE network.

For the 4G network, the HSS was designed to take over both the roles of an HLR and those of an AuC. It stores identifying information for all the subscribers of a 4G network, such as:

  • user identification and addressing, which matches the IMSI
  • the MSISDN, also known as the subscriber's phone number
  • user profile information (the services associated to the subscriber and its Quality of Service information)

The HSS generates security information for user identity keys and authenticates subscribers.

In a 4G network, YateHSS/HLR will hold all the information mentioned above, will authenticate subscribers and authorize access, will provide support for mobility management, and call and session setup.

YateHSS/HLR provides Diameter support for roaming. It also supports the following interfaces:

  • S6a/S6d (MME/SGSN to and from YateHSS/HLR) to provide Update Location, Authentication Info, Purge UE, Notify, Cancel Location, Insert Subscriber Data, Delete Subscriber Data, Reset
  • Cx/Dx (I-CSCF/S-CSCF to and from YateHSS/HLR) to provide User Authorization, Server Assignment, Location Info, Multimedia Authorization, Registration Termination, Push Profile

Identities and authentication in YateHSS/HLR

YateHSS uses a Public Identity, the MSISDN, to authenticate the subscriber.

Each Public Identity can have more Private Identities, depending on the network connection type: 2G/3G, 4G, WiFi, IMS etc.

Depending on the authentication type, YateHSS/HLR will use:

  • SIP authentication, through a username and a password
  • SS7 authentication, through the IMSI and the Ki
  • EAP SIM/AKA authentication, through the IMSI and the Ki

YateHSS/HLR stores all the possible private identities of any given subscriber.

YateHSS/HLR in various deployments

YateHSS/HLR can be deployed in various forms, as seen in the illustrations below.

In mixed networks

Yatehlr-hss 2G 3G 2015-7-2 version1.1 (1).png

For cable operators

Mvno 2015-6-26 version1.3 (1).png

In our Software-defined Mobile Network

Yate products hss 2015-2-23 schema version2.1.png

YateHSS/HLR architecture

YateHSS Arch.png

In the above image you can see the architecture of YateHSS/HLR:

  • Yate C++ modules add support for various protocols: MAP, Diameter and a module that adds clustering support. These protocols are included only in the private version of Yate.
  • An application layer built in Javascript.
    • A Javascript library that eases work with the above protocol modules.
    • Various Javascript scripts that implement the actual logic of YateHSS/HLR.
      • For example: auc_map.jsc, hss_map.jsc, auc_diam.jsc, hss_diam.jsc, hss_config.jsc.
      • The scripts use the Js library to communicate with the protocol modules and the MySQL database and add cluster support.
  • A MySQL database that stores subscribers, service profiles, subscriber profiles and SIMs.
  • Configuration and monitoring API and subscriber management API built in Javascript/PHP

Remote access for YateHSS/HLR operations and management

YateHSS/HLR is easy to operate and manage remotely using the Yate Mobile Management Interface (MMI). The interface makes it accessible to add a new YateHSS/HLR unit, to setup a cluster of YateHSS/HLRs, to add subscribers, to modify and configure subscribers´ profiles and more.

Here is a link to the YateMMI demo, with a preconfigured YateHSS/HLR equipment.

  • username: admin
  • password: admin

YateMMI's main benefit is the fact that operators care remotely manage all their entire network equipment using a single web interface.

Configuration resources

1. Linux Basics Installation for Dell PowerEdge R430

2. Node Parameters


4. JSON API for Configuration

5. JSON API for Subscriber Management