About YateHSS/HLR, HSS HLR documentation
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: yateBTS 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.
Specifications
Features
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
MAP/SS7/SIGTRAN
- ITU TCAP, ETSI MAP v3
- 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
Evolved Packet System
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)
- ROAM, BAOC, BOIC, BOIC-ExHC, BAIC, BIC-Roam
CAMEL subscription (per profile)
- O-CSI, T-CSI, VT-CSI, D-CSI, M-CSI, SS-CSI
- MO-SMS-CSI, MT-SMS-CSI
USSD subscription (per profile)
- Arbitrary number of prefixes to independent gateways
PS Services
Operator barring (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)
- ROAM, BAOC, BOIC, BOIC-ExHC, BAIC, BIC-Roam
CAMEL subscription (per profile)
- O-CSI, T-CSI, VT-CSI, D-CSI, M-CSI, SS-CSI
- MO-SMS-CSI, MT-SMS-CSI
USSD subscription (per profile)
- Arbitrary number of prefixes to independent gateways
EPS Services
PDN connections (per profile)
- Name, type, charging characteristics
- QoS (LTE QCI, priorities)
- VPAA, SIPTO, LIPA
- 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, 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
For cable operators
In our Software-defined Mobile Network
YateHSS/HLR architecture
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.
A Javascript library that eases work with the above protocol modules.
- 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.
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.