OpenBSC June 2010

openbsc@lists.osmocom.org

26 participants
52 discussions

GPRS/SGSN progress update
by Harald Welte 11 Jun '10

11 Jun '10

Hi all, I've been working on the SGSN code again for two days, and there is quite a bit of progress, even if it doesn't really make much difference in what you can do. I'm still working on the signalling plane, an we still cannot send/receive user plane packets (the actual TCP/IP). However, a number of bugs / misunderstandings have been fixed: 1) When we send BSSGP Downlink-Unitdata, we have to always include the IMSI of the target phone, as well as the "MS Radio Access Capabilities" IE. This is apparently needed for the BTS to know when and how it can schedule packets to be sent on the radio interface. However, I personally think it's an ugly layering violation. All this information is part of the "GMM State" in the SGSN, i.e. higher than layer3. It now needs to be passed through LLC down into BSSGP, where it is used :( 2) LLC UI Frames have sequence numbers that need to be incremented with every frame. 3) Some phones apparently don't like it if they don't get a P-TMSI allocated during GPRS ATTACH and ROUTEING AREA UPDATE. According to the spec, it's optional and I thought I could skip that feature to make things easier initially. 4) There are two levels of C/R (Command/Response) bits, one at the LLC and the other at the BSSGP layer. The LLC bit is now set correctly, but the BSSGP C/R packet seems to be set even wrong by the BTS. However, I'm now simulating the behaviour of exissting Gb protocol traces 5) The 04.08 GMM timers T3350 and T3370 have been implemented properly, including re-transmissions of the according MM frames 6) As part of P-TMSI Reallocation, there are time windows when the SGSN has to consider both the old and the newly allocated P-TMSI are valid simultaneously Finally, I've found one other bug that I'm about to fix now: When we assign a new P-TMSI, this implicitly means that the TLLI will change, too. Since the TLLI changes, the LLC protocol created a new "LL Entity" data structure and re-started the sequence number at 0, resulting in all messages being dropped in the phone until the sequence number is higher than the previous one. I have some hope that this is the last bug before I can see packets on the data plane coming out the TUN device on OpenGGSN. After that, there are still the following major TODOs: * actually check the HLR rather than accepting every IMSI * implement BSSGP flow control for BVC and MS level * implement SNDCP fragmentation/reassembly Followed by more optional features, such as * implement SNDCP header compression * implement SNDCP payload compression * implement LLC re-transmissions * implement GEA3 encryption 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)

3 7

Encryption branch
by Harald Welte 11 Jun '10

11 Jun '10

Dear Sylvaion, I've tried my best to forward-port your 'sylvain/encryption' branch to current OpenBSC, and you can find the result in laforge/encryption. I haven't yet had time to test it, but I wouldn't be surprised to see something break, considering that your code predated the introduction of 'gsm_subscriber_connection'. Unfortunately merging the branch to master is also not really an option right now, as it is likely to cause trouble with the BSC/MSC split, as we will have to align our encryption support with how the A-Interface between BSC and MSC handles things. Nonetheless, I really would like to see this feature move ahead. There is definitely a demand for it in the research community. 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)

4 13

UMTS support??
by Nordin 10 Jun '10

10 Jun '10

Well guys, Just being curious, are there any plans for UMTS support? I remember Harald said something about an ASN.1 PER was an obstacle to start for UMTS support. Are there also nanoBTS for UMTS, I only know of 2G devices... It was just quite on the list :p Greetz, Nordin :-)

4 6

Hello, UMTS support and HSS/HLR
by Dragos Vingarzan 10 Jun '10

10 Jun '10

Hi guys, wow, finally found this project/list :). First a bit of background: working at Fraunhofer FOKUS, in Berlin; "maintaining" openimscore.org (when I still find the time); working on openepc.net; currently doing some prototypes for the LTE access part - MME/HSS/eNodeB - only Layer 3 and up. What brings me here is that I have a need for getting a test-bed setup as complete as possible, without black-boxes.The ultimate dream is to have everything from radio to application layers running on COTS hardware for test-bed purposes (nothing commercial). Obviously I am coming from the upper layers to the lower ones, as we had to satisfy first the Application Server guys. So far we've done prototypes for P/I/S-CSCF, HSS(Cx,Sh) and some light MGCF, BGCF/etc with the OpenIMSCore. With OpenEPC we are adding some PDN-Gw, ANGw(SGw/ePDG), PCRF, PCEF, BBERF, ANDSF, HSS (Sp) and working on the afore-mentioned MME, HSS(S6a,etc), eNodeB. Of course, all are prototypes, but we try to make them as inter-operable as economically feasible. Now I am also very interested in UMTS. We're demo-ing EPS hand-overs and the sort between WiFi, LTE (just using it as an air bridge for now) and 3G, but we use commercial 3G, which is quite frustrating as it seems to have a directly proportional probability to fail with the number of phones present in the demo room. However, I do have an Oyster 3G femto from ip.access and would very much like to explore on how can I use it in an environment completely under control. I know about other BTS alternatives, but I really just need the PS part and I need good data-rates. (CS is out of scope for me as it's supposed to be phased out at a point and we have already the all-IP stuff on top, even like 3GPP likes to see it) I see that I am not the only one interested. Now I am still trying to get some more documentation from ip.access. If any of you already figured out how to do the basic operations or at least what is required, I would really appreciate the pointers. Then regarding the HLR - it seems that you have some troubles with it. Well, we have done a couple of HSSs in the past 5 or so years, which is supposed to be an HLR evolution suitable for all-IP environments. So we have all the irrelevant, but required, DB back-end, provisioning interfaces or AKA authentication sorted. Unfortunately it only has support for Diameter, with RADIUS on the road-map due to integration with non-3GPP trusted access networks (WPA with EAP-SIM/EAP-AKA). Also these days I am trying to add support for LTE network attachments through the S6a Diameter interface. If you can provide me with some quick requirements to what you need for the HLR, I hope that we could help. Cheers, -Dragos

2 2

bts for sale
by Rabbit 10 Jun '10

10 Jun '10

Sorry for the intrusion but I thought maybe someone here would be interested. I have two ipaccess bts 165au to sell. Both are fully working with POE. I'm also including the ipaccess software and manuals. Software: BTS installer, BTS Manager, IPaccess BSC which runs on redhat(all rpm files). Also have an msc which runs on windows but you'll need a license and dongle to make it work or defeat the dongle. Documentations are PDFs. You can pick it up in London or can ship it. pics: http://tinypic.com/3ia3muxg

3 3

Rejecting cause
by jason mercury 09 Jun '10

09 Jun '10

Hi , I have same problem with Luca. I could not attach my phone (Nokia N79) to the network unless I close and re-open my phone. When authorized=0 I could not see any location update reject log related my phone on the screen. Changing reject cause was helpful for some other phones but It did not work for N79. I have seen a error message on the bsc_hack screen I think that this can be related to the problem: <0000> abis_rsl.c:1237 (bts=0,trx=0,ts=0,ss=0) ERROR INDICATION cause=Timer T200 expired (N200+1) times Please help. Thanks. Jason.

2 1

Rejecting cause
by Luca Bertoncello 09 Jun '10

09 Jun '10

Hi, all! If I try to change to my Test-Network with my mobile phone (not known from network and not yet authorized!!) I can't change (of course). Then I authorize my phone and I try again. It does not work. I have to turn off and on my phone in order to change to the network. I got the information that I can solve this problem by changing the reject cause (location updating reject cause). Unfortunately I don't know any cause that say the phone "OK, try again later", so that my phone will try again later. Can someone help me and say me a code? I have to give a numeric code, but I don't know any. It was suggested to send a "network failure" or "congestion" or "overload", but I don't know the code for these cause... Thanks for your help! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

2 1

Future of the HLR
by Harald Welte 05 Jun '10

05 Jun '10

Hi all! One of the issues I want to adress in the coming weeks is the HLR. At the moment, we don't have an HLR in the traditional GSM sense. We have something that corresponds to the same function, but without all of the usual interfaces. This is not a problem in itself, as we do not intend to interwork the internal-MSC of the OpenBSC with a traditional HLR at this point. The current implemnetation just synchronously calls subscriber_get(), which does a database lookup. It expects this lookup to succeed synchronously, which is only true as long as nobody else is accessing the hlr.sqlite3 database simultaneously. This is problem 'A'. Simultaneous accesses to the database could either be manual updates, or the 'hlrsync.pl' script, or some other kind of user interface to the database. The problem gets worse if we now start to have a SGSN. The SGSN currently does not access hlr.sqlite3. But if I start to implement it, we will have concurrent accesses from bsc_hack and osmo-sgsn to the sqlite3 database, which means that problem 'A' will become worse. So what needs to be done: 1) Accesses like subscriber_get() need to become asynchronous, i.e. at the time we search for a subscriber we simply issue a call and do some state transition. Once the database process is finished retrieving the subscriber data, we can continue the operation. 2) Introduce an actual message-based protocol between the HLR database process and the OpenBSC and OsmoSGSN software. Both of those fit together quite nicely. And rather than inventing our own protocol, we should directly use the GSM MAP (09.02) messages intended for the respective operations. That might sound complex, but we can leave out the other parts of SS7 (MTP, SCCP, TCAP) for now. But if we already start to encode the information elements and messages themselves according to MAP, we would have a very clear migration path towards * turning our HLR into something that can interoperate with real GSM networks * allowing our Layer3/MSC code in OpenBSC to use a real GSM HLR The MAP asn.1 code can be processed quite nicely by asn1c, thus it should be possible to integrate with our C code quite nicely. I'm right now studying TCAP and how it is being used by MAP in order to determine if (and how much of) TCAP we would need. After that is finished, I'll likely start working on a minimal HLR process (using the sqlite3 database backend) and then convert the OpenBSC code to asynchonous MAP-based subscriber lookups. 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)

1 0

Setting the power of a BTS
by Luca Bertoncello 04 Jun '10

04 Jun '10

Hi, List! I'm new to OpenBSC, and I'm experimenting some configuration of the program. Now I have to try to change the power of the BaseStation, so that I can set how far mobile phones can catch the signal of my BaseStation. I thought, I can change the values of "ms max power" or "nominal power", but I don't see any difference. Is it possible to do what I try? If yes, how? Thanks for any help! -- _______________________________________________________________________ Luca Bertoncello Entwicklung Mail: bertoncello(a)netzing.de NETZING Solutions AG Tel.: 0351/41381 - 0 Kesselsdorfer Str. 216, 01169 Dresden Fax: 0351/41381 - 12 HRB 18926 / Ust.ID DE211326547 Mail: netzing.ag(a)netzing.de _______________________________________________________________________

5 10

OpenBTS OML sequencing / startup problems
by Harald Welte 04 Jun '10

04 Jun '10

Hi zecke, one of the things that I've been thinking about earlier today while talking with Roch was the fact that we do the A-bis OML overlapping / asynchronously, i.e. if we send a 'set attribute ...' or 'opstart' message, we never wait for the acknowledgement before sending the next message. While this might be efficient and compliant with the specification, it is likely to expose bugs like race conditions in software that has never been tested against it. So one of the ideas would be to make the abis_nm.c layer queue up messages during abis_nm_sendmsg() and determine based on the messagetype if it is a message that we're expecting an ACK/NACK as response. If yes, delay transmission of further enqueued OML messages until such ACK/NACK is received. Of course, there probably should also be a timer whose expiration should generate at least a log file entry (and after which we continue with the next message from the queue) I'm not sure if you feel in the mood for implementing something like this or not. I can also stop with GPRS work and have a look at it. This request/response tracking would probably also be useful once we extend our ability to send OML messages from e.g. external applications. We could then notice who submitted the message and deliver the result back to the caller without having to consider re-ordering or something like that. Regards, Harlad -- - 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 June 2010