Hi,
I want to setup a BTS where only a few subscribers (about 10) are allowed to connect but I do not want any other IMSI/IMEI to be stored in the DB as I have noticed that when the number of subscribers in the database reaches a few thousands the network starts to crash more frequently. Is there an option to prevent all undesired subscribers from being stored in the DB or should I modify the code.
best regards, Robert
On 08/12/2017 03:55, robert wrote:
Hi,
I want to setup a BTS where only a few subscribers (about 10) are allowed to connect but I do not want any other IMSI/IMEI to be stored in the DB as I have noticed that when the number of subscribers in the database reaches a few thousands the network starts to crash more frequently.
Hi Robert,
First, I have many systems running with many 1000s of subscribers in the database. I do not observe that the network starts to crash, not more frequently, not at all. Maybe you might want to look elsewhere for the cause of your woes.
You give very little information about your config, but I believe subscriber-create-on-demand might be what you are looking for. You'll find it detailed in the manual: http://ftp.osmocom.org/docs/latest/osmonitb-usermanual.pdf
I assume it does, but I'm not 100% sure if disabling subscriber-create-on-demand will prevent the creation of entries in the Equipment table,
Is there an option to prevent all undesired subscribers from being stored in the DB or should I modify the code.
You can always have a look in the code to verify about the Equipment Table.
Hi,
Since it is working fine with you then maybe I should check my setup. I am using an old version of osmo-nitb, I installed it maybe a year earlier. I will consider updating my setup. Should I go with a newer version of osmo-nitb or should I use the new packages (OsmoMSC, OsmoHLR …) ?
best regards, Robert
On Dec 8, 2017, at 3:16 PM, Keith keith@rhizomatica.org wrote:
On 08/12/2017 03:55, robert wrote:
Hi,
I want to setup a BTS where only a few subscribers (about 10) are allowed to connect but I do not want any other IMSI/IMEI to be stored in the DB as I have noticed that when the number of subscribers in the database reaches a few thousands the network starts to crash more frequently.
Hi Robert,
First, I have many systems running with many 1000s of subscribers in the database. I do not observe that the network starts to crash, not more frequently, not at all. Maybe you might want to look elsewhere for the cause of your woes.
You give very little information about your config, but I believe subscriber-create-on-demand might be what you are looking for. You'll find it detailed in the manual: http://ftp.osmocom.org/docs/latest/osmonitb-usermanual.pdf
I assume it does, but I'm not 100% sure if disabling subscriber-create-on-demand will prevent the creation of entries in the Equipment table,
Is there an option to prevent all undesired subscribers from being stored in the DB or should I modify the code.
You can always have a look in the code to verify about the Equipment Table.
Hi,
On 08/12/17 14:51, robert wrote:
I am using an old version of osmo-nitb, I installed it maybe a year earlier. I will consider updating my setup. Should I go with a newer version of osmo-nitb or should I use the new packages (OsmoMSC, OsmoHLR …) ?
As far as I know, almost all the features present in osmo-nitb are supported in new packages, and osmo-nitb is mostly discontinued nowadays in favor the the new packages. That may help you take a decision regarding this matter.
On Fri, Dec 08, 2017 at 03:58:39PM +0100, Pau Espin Pedrol wrote:
Hi,
On 08/12/17 14:51, robert wrote:
I am using an old version of osmo-nitb, I installed it maybe a year earlier. I will consider updating my setup. Should I go with a newer version of osmo-nitb or should I use the new packages (OsmoMSC, OsmoHLR …) ?
As far as I know, almost all the features present in osmo-nitb are supported in new packages, and osmo-nitb is mostly discontinued nowadays in favor the the new packages. That may help you take a decision regarding this matter.
Here is a quick list of features not present in the split components that come to mind:
- no subscriber-create-on-demand, i.e. you have to explicitly enter all subscribers' IMSIs in the HLR *before* they are accepted by the network. The database will not grow automatically (which robert may like). https://osmocom.org/issues/2542
- in osmo-nitb we could easily log/query which BTS and which timeslot a subscriber was served on. Now you need to ask (each) BSC for that and correlate phone number to TMSI manually. We may want to add Osmocom-specific TLVs to the A interface in order to communicate that information to OsmoMSC and re-enable the old feature set. Related:
- we no longer support Osmocom specific TLVs in SMPP messages, which used to provide information only available on the BSC layer. https://osmocom.org/issues/2390
Things you *get* from the split repositories:
- same subscriber database for CS and PS (OsmoHLR). - no blocking of the core network while accessing the db = more scalable. - support for 3G. - support for Milenage (UMTS authentication). - support of a true A interface between BSC and MSC. - you're set up for the future: new development focuses here, hardly any effort will be spent on OsmoNITB (without explicit requests and funding)
~N
Hi,
my current setup uses two arfcn as described by https://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/. Is it possible to do the same with the new packages ?
best regards, Robert
Hi Robert,
On Mon, Dec 18, 2017 at 02:08:39PM +0200, robert wrote:
my current setup uses two arfcn as described by https://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/. Is it possible to do the same with the new packages ?
what's the "new packages"? Are you referring to the OsmoBSC+OsmoMSC+OsmoHLR setup?
There's no change whatsoever in terms of the number of TRX you use. That's only related to OsmoTRX and OsmoBTS, both of which have not been changed as part of the transition away from OsmoNITB.
On Dec 18, 2017, at 3:50 PM, Harald Welte laforge@gnumonks.org wrote:
Hi Robert,
On Mon, Dec 18, 2017 at 02:08:39PM +0200, robert wrote:
my current setup uses two arfcn as described by https://umtrx.org/multi-bts-with-osmocom-and-a-single-umtrx/. Is it possible to do the same with the new packages ?
what's the "new packages"? Are you referring to the OsmoBSC+OsmoMSC+OsmoHLR setup?
Yes
There's no change whatsoever in terms of the number of TRX you use. That's only related to OsmoTRX and OsmoBTS, both of which have not been changed as part of the transition away from OsmoNITB.
OK. So I should have no problem in setting multiple TRX.
Best regards, Robert
-
Harald Welte -
Keith -
Neels Hofmeyr -
Pau Espin Pedrol -
robert