OpenBSC

openbsc@lists.osmocom.org

16 participants
4247 discussions

AW: Operation management in the MSC code
by Andreas.Eversberg 15 Jun '10

15 Jun '10

>1.) kill the transaction... >2.) generalize it with the "operation". Right now we do have two >operations, one for LU, one for AUTH, we should have them for USSD, SMS >and CC as well. hi holger, the "transaction" represents the instance of calling party / called party / sms sender / ... will the states of it be moved to the "operation"? (e.g. call state, transaction_id, callref, protocol) in this case the call control / sms must use "operation" instance instead. i currently use "transaction" in osmocom-bb for call control and later sms and supplementary services. i think that the sms code should be re-usable in osmocom-bb, so the "operation" instance should be equal (defined in libosmocore) and the sms function sould be available in something like a "libsms", like the "libvty". note: osmocom-bb is at a point where SMS could be sent and received, if a shared sms library would be available. andreas

3 2

open bsc and lcr: layer_3 thread read socket error
by Richard Zahoransky 15 Jun '10

15 Jun '10

Hello, my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research. We have successfully installed OpenBSC, Asterisk, LCR and mISDN. Lcr starts correctly (as far as I can say). The nanoBTS connects to OpenBSC and boot up. On the local machine, we can place outgoing calls with asterisk but when we dial from the cellphones, the lcr prints out: "layer3_thread read socket error No space left on device". I don't know if this is an error in LCR, OpenBSC, mISDN or just in my own config files. We ran through the How-to "OpenBSC_LCR" on http://openbsc.osmocom.org/trac/wiki: gsm is enabled in options.conf GSM interface is active in interface.conf mISDN_l1loop interfaces are created and the routing.conf looks also as described: ----------------------routing.conf (lcr)---------------------- [main] interface=GSM : remote application=asterisk context=btsctrl #interface=xyz : goto ruleset=xyz extern : goto ruleset=extern intern : goto ruleset=intern : disconnect cause=31 ------------------------------------------------------------- the rest of the file is untouched. on the local asterisk, the chan_lcr.so is loaded. the context btsctrl is defined is the extensions.conf: ----------------------extension.conf (asterisk)-------------- [default] exten => _0.,1,Dial(SIP/10${EXTEN}@comsys02) [btsctrl] exten => _X.,1,Set,CALLERID(num)=5552342 exten => _X.,n,dial(SIP/10${EXTEN}@comsys02) ------------------------------------------------------------- it connects to the remote asterisk server as user comsys02, defined in sip.conf ----------------------sip.conf (asterisk)-------------------- register => comsys02:xxx@132.230.4.8/comsys02 [general] port=5060 bindaddr=0.0.0.0 [btsctrl] type=friend context=default secret=xxx host=dynamic [comsys02] type=friend context=btsctrl username=comsys02 fromuser=comsys02 secret=xxx host=132.230.4.8 qualify=yes nat=yes ------------------------------------------------------------- now everything seems to work, but when i dial a number, it prints out: "layer3_thread read socket error No space left on device", many times per second. On the phone I hear static noise. lcradmin prints out the following: ACTION (match) action remote line 8 EP(1): ACTION remote (setup) number 076719235 remote as* EP(1): SETUP ACKNOWLEDGE to CH(1) EP(1): TONE to CH(1) directory default name dialing EP(1): TONE to CH(1) directory default name cause_10 EP(1): DISCONNECT to CH(1) cause value=16 location=1-Lo* CH(1): MNCC_DISC_REQ LCR<-BSC port 1 progress coding=3 * CH(1): MNCC_REL_IND LCR<-BSC port 1 cause coding=0 loca* EP(1): RELEASE from CH(1) cause value=31 location=1-Loc* EP(1): ACTION hangup and the local asterisk output is: NOTICE[10941]: chan_lcr.c:1731 handle_retry: [call=NULL ast=NULL] Retry to open socket. NOTICE[10941]: chan_lcr.c:364 send_message: [call=NULL ast=NULL] Sending MESSAGE_NEWREF to socket. maybe someone also encountered this problem or can help us with the configuration many thanks in advance and best regards, richard

3 2

AW: open bsc and lcr: layer_3 thread read socket error
by Andreas.Eversberg 15 Jun '10

15 Jun '10

hi, first try the bsc_hack. it has a bult-in MSC, so you can call from mobile phone to mobile phone. if this works, try to use LCR without asterisk. if you have no ISDN card, then you can also dial via LCR from mobile to mobile. if this works, then try asterisk... andreas On 06/15/2010 08:19 PM, Richard Zahoransky wrote: > Hello, > > my name is Richard and I am working on OpenBSC and LCR for my university. We plan to deploy a GSM-Network on the campus for research.

1 0

Operation management in the MSC code
by Holger Freyther 15 Jun '10

15 Jun '10

Hi, I am going through the SMS code right now and try to convert it to the BSC API and there is something that is quite bad. There are many paths were sending a SMS can end, some do not free the SMS, some not the transaction, some do not remove lock on the channel. I would like to make the radical proposal to solve that. 1.) kill the transaction... 2.) generalize it with the "operation". Right now we do have two operations, one for LU, one for AUTH, we should have them for USSD, SMS and CC as well. Each gsm_subscriber_connection (MSC data) has an operation manager, when a lchan is opened we will attempt to create an operation for the initial message, at the end of one operation the operation manager will check if all operations are completed and then send a clear using the BSC API. The consequence of that is: 1.) we get rid of the refcount and can close channels faster 2.) we will notice... when we run into a timeout and should not... I know this will be a bigger change on the MSC side of things but what do you guys think about it? z.

2 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC