Openbsc support for new BTS

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Fri Jan 17 16:50:49 UTC 2014


Hi Jason,

On Fri, Jan 17, 2014 at 04:11:46PM +0000, Jason DSouza wrote:
> During the configuration, openbsc takes quite a long time to configure
> all the physical timeslots. Octasic phy configures those physical
> channels instantly and sends ack to openbsc but openbsc state
> transition takes quite a long time to send the next physical timeslot
> config. Is there anything we could do to make this faster?

I don't think there are any delays in the OpenBSC codes, at least not
that I remember.  The OML configuration on the sysmoBTS or nanoBTS takes
only seconds for a single TRX.

I would appreciate if you could send a pcap file of the complete Abis
dialogue betewen osmo-bts and openbsc so I can see what might be causing
the delay.

> In Openbsc all the physical timeslot configurations are done at one
> time at the beginning and during calls only logical channels are
> configured and released but physical timeslots are always configured.

correct.

> We see a lot of unexpected channels are configured because of
> emergency calls and intruder calls (may be surrounding disturbances).

I suspect this is related to the fact that the RACH detection only has a
very weak CRC, which means that you get lots of false positives from
the PHY.  Is that the case?

> Those unwanted calls are not going through though, they create
> unnecessary problems. I have kept the auth policy as closed in the
> openbsc config.

I would strongly argue against running any 'open' network outside a
faraday cage.  So I believe you are doing it the 'right' way.

> Is there any way we can avoid those unwanted logical channel
> configurations happening for emergency and other intruder calls ?

You can tune a lot of the parameters.  In osmo-bts code itself, you can
set a threshold in terms of RxLevel or C/I (is that available for RACH
detection?) and drop all requests below a certain level or C/I

In the system information, you can play with paramters such as
Rx-Access-Level-Min.

If you have mobile phones with engineering modes, then you can set the
cell to barred in the SI and instruct your engineering mode phone to
ignore barred cells.  This way no real other phones would actually
communicate with your cell.

Finally, you can of course always use a duplexer + attenuator + coaxial
cable between phone and BTS to avoid any interference from the real
networks surrounding you.  We have some customers who use this with
cascaded splitters for up to 100 (!) mobile stations during device
testing.  You need phones with an antenna connector, though.

> How about the possibility of configuring physical channel
> configurations along with logical channel configurations on the go
> whenever ts is required? I understand Openbsc behavior should be
> modified in that case.

This is not supported by OpenBSC so far.  It is a classic BSC with
static timeslot configurations.  Our customers (or other production
users who are not our customers) so far didn't indicate a strong need for
dynamic allocation, so it is not implemented yet.

And yes, it would mean some architectural changes.  If there is
[commercial] demand, or somebody seriously wants to contribute some time
and effort in implementing it, we would apprecaite that.  Otherwise it's
just one of many potential wishlist items on a long list, sorry ;)

> Regarding sharing of the code, as I pointed out in my last email that
> I'm not able to push the changes onto the branch (as in below email),

Sorry for not getting back on that.  Like all Free Software projects I
know of, the git repositories only provide public read access.  Write
access is permitted only via git-over-ssh, and we would need your ssh
public key.  If you send that public key by private mail to me, I can
autorize you to commit to the repository.

Meanwhile, and independent of that, I suggest the use of 'git
send-email' on your series of commit, to generate a series of
automatically generated e-mail messages to the openbsc at lists.osmocom.org
mailing list for public review of the code.  If you feel hesitant due to
not having done this with git before: feel free to do a test run to my
personal e-mail address and I'll let you know if everything has worked.

> I'm also fine to share the tar file containing the changes if someone
> can help me create a branch on git repo.

Let's work on your git commit access and send the patch series by e-mail
meanwhile.   Thanks!

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list