3f9d1977df
Each VLR requesting auth tuples should use a distinct IND pool for 3G auth. So far we tied the IND to the GSUP peer connection; MSC and SGSN were always distinct GSUP peers, they ended up using distinct INDs. However, we have implemented a GSUP proxy, so that, in a distributed setup, a remotely roaming subscriber has only one direct GSUP peer proxying for both remote MSC and SGSN. That means as soon as a subscriber roams to a different site, we would use the GSUP proxy name to determine the IND instead of the separate MSC and SGSN. The site's MSC and SGSN appear as the same client, get the same IND bucket, waste SQNs rapidly and cause auth tuple generation load. So instead of using the local client as IND, persistently keep a list of VLR names and assign a different IND to each. Use the gsup_req->source_name as indicator, which reflects the actual remote VLR's name (remote MSC or SGSN). Persist the site <-> IND assignments in the database. Add an IND test to db_test.c There was an earlier patch version that separated the IND pools by cn_domain, but it turned out to add complex semantics, while only solving one aspect of the "adjacent VLR" problem. We need a solution not only for CS vs PS, but also for 2,3G vs 4G, and for sites that are physically adjacent to each other. This patch version does not offer any automatic solution for that -- as soon as more than 2^IND_bitlen (usually 32) VLRs show up, it is the responsibility of the admin to ensure the 'ind' table in the hlr.db does not have unfortunate IND assignments. So far no VTY commands exist for that, they may be added in the future. Related: OS#4319 Change-Id: I6f0a6bbef3a27507605c3b4a0e1a89bdfd468374 |
||
---|---|---|
contrib | ||
debian | ||
doc | ||
include | ||
sql | ||
src | ||
tests | ||
.gitignore | ||
.gitreview | ||
COPYING | ||
Makefile.am | ||
README.md | ||
TODO-RELEASE | ||
configure.ac | ||
git-version-gen | ||
libosmo-gsup-client.pc.in | ||
libosmo-mslookup.pc.in |
README.md
osmo-hlr - Osmocom HLR Implementation
This repository contains a C-language implementation of a GSM Home Location Register (HLR). It is part of the Osmocom Open Source Mobile Communications project.
Warning: While the HLR logical functionality is implemented, OsmoHLR does not use the ETSI/3GPP TCAP/MAP protocol stack. Instead, a much simpler custom protocol (GSUP) is used. This means, OsmoHLR is of no use outside the context of an Osmocom core network. You can use it with OsmoMSC, OsmoSGSN etc. - but not with third party components.
Homepage
The official homepage of the project is https://osmocom.org/projects/osmo-hlr/wiki
GIT Repository
You can clone from the official osmo-hlr.git repository using
git clone git://git.osmocom.org/osmo-hlr.git
git clone https://git.osmocom.org/osmo-hlr.git
There is a cgit interface at https://git.osmocom.org/osmo-hlr/
Documentation
User Manuals and VTY reference manuals are [optionally] built in PDF form as part of the build process.
Pre-rendered PDF version of the current "master" can be found at User Manual as well as the VTY reference manuals
Mailing List
Discussions related to osmo-hlr are happening on the openbsc@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/openbsc for subscription options and the list archive.
Please observe the Osmocom Mailing List Rules when posting.
Contributing
Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards
We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details
The current patch queue for osmo-hlr can be seen at https://gerrit.osmocom.org/#/q/project:osmo-hlr+status:open