OpenBSC December 2009

openbsc@lists.osmocom.org

24 participants
47 discussions

statistics tools for OpenBSC
by Harald Welte 26 Dec '09

26 Dec '09

Hi all! I've just added some code to OpenBSC which keeps counters for various events, such as the number of channel requests, how often we were out of channels, the number of delivered/submitted sms, paging statistics, etc. Those counters are available through the VTY for evaluation at runtime. There is now a "Counters" table in our database schema. It stores those counters in a generic way. The counters are stored to the database every minute. Each counter is identified by a string like "net.sms.delivered" The counters increment all the time, until OpenBSC terminates, when they will re-start from zero. I did not want to make the counters persistent (i.e. load them from the database) as it would cofuse users of the VTY. What's still missing now is some kind of script that uses those counters to generate something like nice charts. Given the way how the counters are stored in the database, it should be relatively easy to write a fairly generic tool that does not need any modification even if we add new counters. What I'm thinking is something like specifying the specific counters one is interested in at the command line, maybe also providing a start and end time. The graphs should then generally show the increments of the counters between two counter stores in the database. So if e.g. one minute ago the number of delivered SMS was '10', and now it is '15, then the actual value plotted in the graph should only be '5'. The only "difficulty" is to handle restarts of OpenBSC... but that's quite easy. All counters are monotonically incrementing, i.e. whenever you see a smaller counter, you can safely assume that openbsc was restarted and that we simply continue with the next diff, ignoring the negative one. If anyone is interested in working in such a tool (preferrably in python or perl, using their respective sqlite3 bindings), it would be greatly appreciated. However, please do coordinate on this mailing list... your time is too precious to be wasted by code duplication. Thanks in advance, 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)

3 7

URGENT: range 1024/512/256 encoding of neighbor cell list required
by Harald Welte 26 Dec '09

26 Dec '09

Hi! We've just finished most of the build-up of the GSM network at 26C3, and I've noticed that the ARFCN's that we've been allocated are further than 111 apart, i.e. we cannot use the 'variable bitmap' format that OpenBSC implements so far. If anyone understands (and/or has time to implement) the specification in GSM TS 04.08 10.5.2.13.3 / 10.5.2.13.4 / 10.5.2.13.5, or even the full algorithm as specified in "Annex J: Algorithm to encode frequency list information elements", I would be extremely grateful. Off to bed, will be yet another long day tomorrow. -- - 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)

1 0

SMS status
by Sylvain Munaut 25 Dec '09

25 Dec '09

Hi, Here's a little report on the SMS status: First, the good news is that in practice everything works fine with the handsets I tested. There are a few issues left to address but they don't seem to cause any operational troubles so far : * In MO transfers, the channel should be closed after the reception of CP-ACK, _unless_ a CM SERVICE REQUEST was sent just before on the channel. Currently the channel is just not closed AFAICT and it times out some time afterwards. * Double RF Channel Release : Here's the log of the end of a typical SMS transfer (MO in this case but MT has a similar problem) : <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=3 DATA INDICATION <0007> gsm_04_11.c:918 trans_id=c RX SMS CP-ACK [ pause ] <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=0 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1138 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK <0000> abis_rsl.c:1408 (bts=0,trx=0,ts=1) SAPI=3 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1138 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK As you see, when we receive a RELEASE INDICATION in abis_rsl_rx_rll, we call rsl_rf_chan_release directly. But we'll receive RELEASE INDICATION for both SAPI 0 & 3 and so we'll call it twice which is bad. I tried releasing channel _only_ if all SAPI are unused but the resulting effect was not what I expected : <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=3 DATA INDICATION <0007> gsm_04_11.c:927 trans_id=b RX SMS CP-ACK [ pause ] <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=0 RELEASE INDICATION [ pause ] <0004> abis_rsl.c:1137 (bts=0,trx=0,ts=1) <0004> abis_rsl.c:967 CONNECTION FAIL: RELEASINGCAUSE=0x01(Radio Link Failure) <0004> abis_rsl.c:975 <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1148 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK <0013> gsm_subscriber_base.c:subscr 35414 usage decreased usage to: 0 <0000> abis_rsl.c:1418 (bts=0,trx=0,ts=1) SAPI=3 RELEASE INDICATION <0004> abis_rsl.c:742 (bts=0,trx=0,ts=1) RF Channel Release CMD <0004> abis_rsl.c:1148 (bts=0,trx=0,ts=1) RF CHANNEL RELEASE ACK I need to read the spec and see what happens on a commercial network to understand better what should be done because I'm obviously missing something ... Sylvain

2 1

About the ipaccess-proxy
by Harald Welte 24 Dec '09

24 Dec '09

Hi all, I've committed a new program called ipaccess-proxy to openbsc git. It is - like the name implies - a proxy for the ip.access A-bis over IP protocol. Why would you want to do that? 1) to keep the BCCH live while you restart OpenBSC. This keeps the phones nice and happy on the network while you test/deploy new code 2) to inject packets into the A-bis stream, e.g. from a packet generation tool like scapy. ipaccess-proxy creates udp ports to do this. More documentation after the 26C3. -- - 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)

1 0

christmas present
by WoMax 24 Dec '09

24 Dec '09

As a christmas present a friend of mine showed me some nanoBTS documents, I can't make copies but I remember some details I will post here ... LED status codes: red/steady: sw error, power-on fails orange/slow flash: ethernet disconnected red/fast blink: dongle attached, factory reset done red-green/fast flash: unit not configured orange/fast flash: code loading in progress orange/slow blink: TRX is waiting for OML orange/steady: self test in progress green/fast flash: OML established, NWL test running green-orange/slow blink: calibrating in progress green/slow flash: no radio carrier transmitted green/steady: operational state TIB pinout: Output-connector - pin 1-spare/fpga 2-spare/fpga 3-26mhz - 4-26mhz + 5-sync out + 6-sync out - 7-ppc serial out 8-ppc serial in 9-fpga serial out 10-gnd Input-connector - pin 1-10mhz in - 2-10mhz in + 3-26mhz in - 4-26mhz in + 5-sync in + 6-sync in - 7-frame sync 8-nc 9-reset 10-gnd A merry christmas, WoMax

1 0

Encryption support, please test :)
by Sylvain Munaut 24 Dec '09

24 Dec '09

Hi everyone, I've just pushed a branch sylvain/encryption on the OpenBSC git that contains my current patches to support encryption. Even if you don't have programmable SIMs, test it still works :) If a subscriber doesn't have a Ki set in the HLR or encryption isn't enabled in the config, the executed code path should be the exact same as before. It uses COMP128 as a3/a8 so you can use common programmable SIMs. Currently a secure channel is established for - LOCATION UPDATEs - CM SERVICE REQUEST. Support for PAGING RESPONSE is a little trickier and I haven't looked deeply into it. To enable : - Either recreate your HLR sqlite3, or update it like this (do a backup before hand !) : bash# sqlite3 hlr.sqlite3 sqlite> ALTER TABLE Subscriber ADD COLUMN ki BLOB; sqlite> UPDATE Meta SET value = '3' WHERE key='revision'; - Add a "a5 encryption 1" line to your openbsc.cfg to enable encryption using A5/1 - Set the Ki of the subscriber. Using the vty interface is the simplest : bash# telnet 127.0.0.1 4242 openbsc> enable openbsc# conf t openbsc# subscriber YOURIMSI openbsc# ki 0123456789abcdef0123456789abcdef Sylvain

1 0

ciphering on nanoBTS
by WoMax 23 Dec '09

23 Dec '09

Beware! Ciphering on nanoBTS is depending on the installed software. If you have a model 139/140 and the software is 120a... the A5/1 and A5/2 encryption is available; 120b... is A5/2 only and 120c... there is no encryption available. When you have a model 108/110 the software should start with 119 and with model 165 it starts with 168.

2 1

RRLP / ephemeris data
by Harald Welte 23 Dec '09

23 Dec '09

Dear Daniel and Jan, you have been working very closely with and on the u-blox GPS receiver during your work on the Openmoko GTA02. As far as I know, it is possible to obtain the ephemeris data from a u-blox receiver. I would like to see some code that obtains and converts that ephemeris data into the format described by the RRLP protocol specification. I know this involves asn.1 PER ugliness, but this can all be done well outside the OpenBSC codebase. What I'll propose is to simply use some pattern matching to determine the RRLP request for assistance data, and if such a request exists, open some file in the filesystem and send the contents binary as-is to the phone in response. Any responses from the phone are already stored in the database anyway. In case any of you are interested in working on something to generate the required ephemeris data and have time before or even at the 26C3, you can simply give me the resulting binary file, I can drop it into the OpenBSC directory and we'll see what happens. If this doesn't happen right now, it doesn't matter all that much, as the 26C3 is an indoor event and I don't think we'll be getting that many GPS fixes in such an environment anyway. But eventually, for the next outdoor test, and to do some more RRLP security research, the ephemeris data formatter would be really great! Cheers, 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)

2 6

UMTS
by WoMax 22 Dec '09

22 Dec '09

If there is a solution for UMTS (W-CDMA) coming, we don't need the expensive nanoBTS anymore. BTW I've still one for sale ... see at http://umts.zerber.us There are cheap W-CDMA BTS's out there, like Netgear DVG834GH, AT&T 3G Microcell, Alcatel-Lucent 9365 or the Vodafone Access Gateway you can buy in England for just 160 GBP each. All the femtocell's I know have built in GPS for timebase and security reason, so there is a lot to do for our purpose ... I guess the future is W-CDMA and I hope there will be openUMTS available soon ;-) Regards from Switzerland

2 1

new debug / logging architecture
by Harald Welte 22 Dec '09

22 Dec '09

Hi Holger, I'm happy with the new architecture. During testing I made a couple of bug fixes, which I applied to the new 'new-debug-arch' branch in the root directory of the git branch namespace. (i.e. not prefixed with holger/). It would be great if you could finish this work so we can benefit of it before the congress. I'll probably merge some initial parts already now (at least the new macro definitions) to start using log levels in the actual code - even if it doesn't get used yet. 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)

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC December 2009