17 Jan
2014
17 Jan
'14
5:50 p.m.
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(a)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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)