OpenBSC

openbsc@lists.osmocom.org

6 participants
4179 discussions

Re: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
by Dieter Spaar 07 Jul '09

07 Jul '09

Hello Nordin, On Tue, 07 Jul 2009 16:31:36 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > > But this means that your HTC needs more relevant GPRS settings before > deciding to register. So it than searches for altenatives, but since the > BA list is empty it starts all over again and the whole process repeats, > which might result in a long procedure before it gives up. This is what > it might could be the reason, I'm not sure. If the GPRS Indicator is set, SYSTEM INFORMATION 13 is needed to describe the GPRS properties. But SYSTEM INFORMATION 13 is not set yet (not possible for the BS-11 anyway) so the phone won't find it. Probably some phones don't care about it but some others insist to find it before going to register. This is probably one of the many places where there is no rule in the specification what should be done in such a situation so its up to the developer of the firmware (the phone could register and return an error only when GPRS is actually needed for a data connection). Of course I don't mean that the specification is incomplete, it just expects that certain things are done "right" (who would expect that people outside of the mobile phone industry play with a BTS ;-). Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

1 0

Re: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
by Dieter Spaar 07 Jul '09

07 Jul '09

Hello Nordin, On Mon, 06 Jul 2009 12:00:27 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > > I tried the parameters as you suggested for SI 1 as well as SI3, but > with no success. But I'm still curious if someone else on the list > registered a PDA-like mobilephone (with GPRS support) to his BTS > (BS11/nanoBTS1800). If so, I would like to try out his/her SI's settings. > With the modification I have sent I can register a HTC Touch Pro to the BS11 and the nanoBTS 1800. If GPRS is set in SYSTEM INFORMATION 3, the phone will not register. The process is a bit unstable, if the phone is powered on, the location update works as expected, if I try to register manually, it sometime fails without actually communication with the BTS. I don't know the reason for this behaviour yet. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Git repository via HTTP (port 80)
by Nordin 07 Jul '09

07 Jul '09

Hello guys, I made a repository for the OpenBSC project, see: http://repo.or.cz/w/openbsc.git Now you can update/clone the project from http://repo.or.cz/r/openbsc.git, like this: git clone http://repo.or.cz/r/openbsc.git It will be updated every hour (mirror mode). I needed that because our firewall blocks the git port 9418. Thank you for the tip Holger Freyther :) If you have any questions, don't hestitate to ask.

1 0

Re: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
by Dieter Spaar 06 Jul '09

06 Jul '09

Hello Nordin, On Fri, 03 Jul 2009 11:21:59 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > > Since we haven't done anything for GPRS support, this might be the > reason why a location update is not performed with bsc_hack. The problem you experience with the nanoBTS 1800 most certainly comes from an invalid System Information Type 1. It uses the bitmap type for the channel description which is only valid for GSM900. So all the phones should try to register with the BS-11 but for the nanoBTS 1800 phones which strictly confirm to the specification will ignore it and not try to register (there are some phones which don't care). You can try the "system_information" git branch from Harald, it will most certainly solve the problem. > P.S.: Is everybody on holiday...:) I guess the people are just busy... Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

4 4

Re: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
by Nordin 06 Jul '09

06 Jul '09

I tried the parameters as you suggested for SI 1 as well as SI3, but with no success. But I'm still curious if someone else on the list registered a PDA-like mobilephone (with GPRS support) to his BTS (BS11/nanoBTS1800). If so, I would like to try out his/her SI's settings. I still don't have the latest version as at the moment our firewall doesn't allow to (I ask the networkadmin later for that).

1 0

Re: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
by Dieter Spaar 06 Jul '09

06 Jul '09

Hello Nordin, On Fri, 03 Jul 2009 14:44:50 +0200, "Nordin" <bouchtaoui(a)gmail.com> wrote: > > I hope this will at least try to do a LOCATION UPDATE REQUEST. > But it suprises me that older mobilephones don't care about SI 1 (and > maybe more information on the BCCH) and just try to register whatever in > the BCCH is. I have further investigated the problem. Besides the fact that the channel allocation in SYSTEM INFORMATION 1 is not correct for GSM 1800, this is probably not the reason for the problem. Most certainly its just one wrong bit, the GPRS indicator in the SYSTEM INFORMATION 3 rest octets. The current setting is 0x80, 0x00, 0x00, 0x2B but it should be 0x80, 0x00, 0x08, 0x2B What might lead to some confusion is the meaning of "L" and "H" in the specification of CSN.1. For the rest octets the bit value is determined by a comparsion (XOR) to the padding byte 0x2B. So the value 0x08 above actually means "L" for the GPRS indicator, which means "No GPRS". Its seem that some phones are really sensible to this setting, some other GPRS capable phones just don't care and register to the network even if there is no GPRS. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

3 2

Re: OpenBSC with 2.5G or 3G mobile devices support? / Tested Phones
by Dieter Spaar 05 Jul '09

05 Jul '09

Hello Harald, On Sun, 5 Jul 2009 04:42:20 +0200, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > where did you find this XOR? I just searched through 04.07 and 04.08 and > didn't find any indication thereof. Sure, the padding bit sequence ix 0x2b, so > all spare bits have to be padded with that. But where did you get the XOR > from? I started to search deeper because I was a bit confused how the Message Decoding Tool from Joachim Goeller interpreted the rest octets. I looked at some phone firmware how they do it and found it there. Later I also found a good explanation at http://csn1.info (they sell a tool which can be used to generate message parsing source code for various specifications). > Also, this would mean that if we put explicitly 0x2b into the padding of > our messages, then it would result in all-zero 0x00 on the air, since > > 0x2b xor 0x2b == 0x00 The XOR is actually only used for "L" and "H", basically it means that if a bit at an "L"/"H" position is different from the padding sequence, its an "H". At least this is how I understand it. > I'm now looking at an actual abis trace from a production cell with GPRS > enabled, and it has > > "0x80, 0x00, 0x80, 0x0b" Here is how I would interpret it according to GSM 04.08, 10.5.2.34: Selection Parameter: byte 0: 0x80 ^ 0x2B = 0xAB, (bit 7) -> H (15 bits for parameter follow) Power Offset: byte 2: 0x80 ^ 0x2B = 0xAB, (bit 7) -> H ( 2 bits for parameter follow) System Information 2ter Indicator: byte 2: 0x80 ^ 0x2B = 0xAB, (bit 4) -> L (has no parameters) Early Classmark Sending Control: byte 2: 0x80 ^ 0x2B = 0xAB, (bit 3) -> H (has no parameters) Scheduling if and where: byte 2: 0x80 ^ 0x2B = 0xAB, (bit 2) -> L GPRS Indicator: byte 2: 0x80 ^ 0x2B = 0xAB, (bit 1) -> H ( 4 bits for parameter follow) > During early start of the BTS, SI3 rest octets are set to > > "0x80, 0x00, 0x83, 0x2b" The only difference is that at this stage GPRS is not yet set: GPRS Indicator: byte 2: 0x83 ^ 0x2B = 0xA8, (bit 1) -> L Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 2

Re: AW: patches again
by Dieter Spaar 05 Jul '09

05 Jul '09

Hello Andreas, On Mon, 29 Jun 2009 23:37:51 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > this was the problem. finally got the measurement reports (--debug > ....:DMEAS). you just need to add to misdn.c: > > case DL_UNITDATA_IND: > > and everything is fine. Great, so this is solved. I noticed one minor problem, its the meaning of the MEAS-VALID flag. The spec says that "0" means "valid" and "1" is "not valid". So if (!(meas_rep.flags & MEAS_REP_F_VALID)) should be changed or the parsing of the measurement result where this flag is set. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

updated wireshark patches / call for help
by Harald Welte 04 Jul '09

04 Jul '09

Hi! I've just committed some recent improvements of the Abis dissection of wireshark to git. There's some initial work on a 12.21 OML decoder in epan/dissectors/packet-abis_oml.c. It will happily decode the common FOM header and tell you the name of the message as well as list all attributes in it. It does not yet understand details on how to parse all the various attributes. If anyone wants to make himself familiar with this part of GSM, get a copy of 12.21, look at OpenBSC or protocol traces and add more of that attribute parsing code! The A-bis/IP dissector has only been improved slightly. If you apply abisip.patch and abis_oml.patch to current wireshark svn, you will be able to decode 94-99% of what you see in any capture between OpenBSC and a nanoBTS. I currently don't have access to a BS-11, so I cannot test the wireshark code with it. In case somebody wants to send me some pcap files of BS-11 traces, either by using the openbsc pcap option or by tracing it through mISDN, I'm more than happy to make sure that it works on thos traces, too. Testing as well as contributed patches are also always welcome! Thanks, -- - 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 2

Patch 39: WAS: Re: patches again
by Holger Freyther 04 Jul '09

04 Jul '09

On Sunday 28 June 2009 18:47:31 Andreas.Eversberg wrote: > patch 39: the location update process did not work, if mobile station > uses tmsi when comming from a different network. in this case the > reject-timer must also be started, and we wait for imsi identity > response. in case we can't find the subscriber or if we have an > unimplemented location update, we release location update process and > send a reject. Sorry, to me it seems the patch is doing something else... 1.) if (!subscr) { DEBUGPC(DRR, "<- Can't find any subscriber for this ID\n"); /* FIXME: request id? close channel? */ + release_loc_updating_req(lchan); + gsm0408_loc_upd_rej(lchan, reject_cause); return -EINVAL; } I think we can just move the schedule_reject from two lines below the if to the top. What do you think? 2.) The patch changes the policy from delayed reject (to not make the MS come back immediately) to a direct one. What is the reasoning?

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC