| == 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 <<vty-ref-osmohlr>> as well as the Control interface described in |
| <<hlr-ctrl>>. |
| |
| === 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 |
| |msc_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 |