== Managing Subscribers Subscribers are kept in a local SQLite database file and can be managed via VTY and CTRL interfaces. This section provides some examples; also refer to the OsmoHLR VTY reference manual <> as well as the Control interface described in <>. === Example: Add/Update/Delete Subscriber via VTY The following telnet VTY session adds a subscriber complete with GSM (2G) and UMTS (3G and 2G) authentication tokens, and finally removes the subscriber again; it assumes that osmo-hlr is running and listening for telnet VTY connections on localhost: ---- $ telnet localhost 4258 include::../example_subscriber_add_update_delete.vty[] ---- [[subscriber-params]] === Subscriber Parameters The following parameters are managed for each subscriber of the HLR, modelled roughly after 3GPP TS 23.008, version 13.3.0; note that not all of these parameters are necessarily in active use. The `aud3g` table also applies to 2G networks: it provides UMTS AKA tokens for Milenage authentication, which is available both on 3G and 2G networks. On 2G, when both MS and network are R99 capable (like OsmoMSC and OsmoSGSN are), the full UMTS AKA with Milenage keys from `aud_3g`, using AUTN and extended RES tokens, is available. With pre-R99 MS or network configurations, the GSM AKA compatible variant of Milenage, still using the Milenage keys from `aud_3g` but transceiving only RAND and SRES, may be applicable. (See 3GPP TS 33.102, chapter 6.8.1, Authentication and key agreement of UMTS subscribers.) .OsmoHLR's subscriber parameters [options="header",width="100%",cols="20%,20%,60%"] |=== |Name|Example|Description |imsi|901700000014701|identity of the SIM/USIM, 3GPP TS 23.008 chapter 2.1.1.1 |msisdn|2342123|number to dial to reach this subscriber (multiple MSISDNs can be stored per subscriber), 3GPP TS 23.008 chapter 2.1.2 |imeisv|4234234234234275|identity of the mobile device and software version, 3GPP TS 23.008 chapter 2.2.3 |aud2g.algo|comp128v3|Authentication algorithm ID for GSM AKA, corresponds to enum osmo_auth_algo |aud2g.ki||Subscriber's secret key (128bit) |aud3g.algo|milenage|Authentication algorithm ID for UMTS AKA (applies to both 3G and 2G networks), corresponds to enum osmo_auth_algo |aud3g.k|(32 hexadecimal digits)|Subscriber's secret key (128bit) |aud3g.op|(32 hexadecimal digits)|Operator's secret key (128bit) |aud3g.opc|(32 hexadecimal digits)|Secret key derived from OP and K (128bit), alternative to using OP which does not disclose OP to subscribers |aud3g.sqn|123|Sequence number of last used key (64bit unsigned) |aud3g.ind_bitlen|5|Nr of index bits at lower SQN end |apn|| |vlr_number||3GPP TS 23.008 chapter 2.4.5 |hlr_number||3GPP TS 23.008 chapter 2.4.6 |sgsn_number||3GPP TS 23.008 chapter 2.4.8.1 |sgsn_address||3GPP TS 23.008 chapter 2.13.10 |ggsn_number||3GPP TS 23.008 chapter 2.4.8.2 |gmlc_number||3GPP TS 23.008 chapter 2.4.9.2 |smsc_number||3GPP TS 23.008 chapter 2.4.23 |periodic_lu_tmr||3GPP TS 23.008 chapter 2.4.24 |periodic_rau_tau_tmr||3GPP TS 23.008 chapter 2.13.115 |nam_cs|1|Enable/disable voice access (3GPP TS 23.008 chapter 2.1.1.2: network access mode) |nam_ps|0|Enable/disable data access (3GPP TS 23.008 chapter 2.1.1.2: network access mode) |lmsi||3GPP TS 23.008 chapter 2.1.8 |ms_purged_cs|0|3GPP TS 23.008 chapter 2.7.5 |ms_purged_ps|1|3GPP TS 23.008 chapter 2.7.6 |=== === Configuring the Subscribers Create on Demand Feature Usually a HLR will only allow mobile equipment (ME) on the network, if the HLR has a subscriber entry with the ME's IMSI. But OsmoHLR can also be configured to automatically create new entries for new IMSIs, with the `subscriber-create-on-demand` VTY option. The obvious use case is creating the new subscriber entry and then allowing the ME to use both the CS (Circuit Switched) and PS (Packet Switched) NAM (Network Access Mode). .osmo-hlr.cfg ---- hlr subscriber-create-on-demand 5 cs+ps ---- On the other hand, operators might only want to give network access to IMSIs, of which they know the owner. In order to do that, one can set the default NAM to `none` and manually approve new subscribers by changing the NAM (e.g. over the VTY, see the example below). Oftentimes it is hard to know, which IMSI belongs to which ME, but the IMEI is readily available. If you configure your MSC to send IMEI checking requests to the HLR, before sending location update requests, the subscribers created on demand can also have the IMEI stored in the HLR database. With OsmoMSC, this is done by writing `check-imei-rqd early` in the `msc` section of osmo-msc.cfg. Then enable storing the IMEI when receiving check IMEI requests with `store-imei` in the OsmoHLR configuration. .osmo-msc.cfg ---- msc check-imei-rqd early ---- .osmo-hlr.cfg ---- hlr subscriber-create-on-demand 5 none store-imei ---- .Example: Enabling CS and PS NAM via VTY for a known IMEI ---- OsmoHLR> enable OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 <1> IMEI: 35761300444848 CS disabled <2> PS disabled <2> OsmoHLR# subscriber imei 35761300444848 update network-access-mode cs+ps OsmoHLR# subscriber imei 35761300444848 show ID: 1 IMSI: 123456789023000 MSISDN: 58192 IMEI: 35761300444848 ---- <1> Randomly generated 5 digit MSISDN <2> Disabled CS and PS NAM prevent the subscriber from accessing the network