OpenBSC

openbsc@lists.osmocom.org

8 participants
4276 discussions

Project / Program naming
by Harald Welte 20 May '10

20 May '10

Hi all! I think it's about time that we seriously think about how to handle naming of the individual programs as well as the project itself. OpenBSC was always a mis-nomer since what we started with is much more than a BSC: It's an entire GSM network (excluding BTS) in one process. This was mostly due to the fact that OpenGSM was way too generic and I wasn't able to come up with a good name. Meanwhile, we've started project Osmocom (Open Soruce mobile Communications), where work is being done on the MS (phone) side of GSM. The idea was to have a name generic enough for sub-projects. There are currently two such projects: * OsmocomBB - the BaseBand firmware * libosmocore - the shared library with utilities that are used accross programs In OpenBSC, we currently have the following executables: * bsc_hack - the gsm network-in-a-box * bsc_msc_ip - the actual BSC-only version talking to a real MSC * bsc_nat - the A interface NAT * bsc_mgcp - the media control gateway * osmo-gbproxy - the Gb interface proxy * osmo-sgsn - the soon-to-be-working SGSN as well as a number of utilities like bs11-config, ipaccess-find, ipaccess-config, etc. What Zecke and me have decided some time ago is to move everything under the umbrella of the Osmocom project name. This menans that the homepage and git repositories will move to openbsc.osmocom.org/bsc.osmocom.org and git.osmocom.org (while keeping aliases/redirects in place). What worries me most is the naming of bsc_hack and bsc_msc_ip. I think bsc_msc_ip should be called osmo-bsc, as it is a true BSC implementation. For bsc_hack it's much harder. A logical name would be osmo-gnib (gsm network in a box), but as I've already received tons of complaints about osmocom, I'm not going to come up with even stranger acronyms. However, I want to rename it. It should be prefixed with "osmo-" and the name should not erroneously indicate that we're talking abuot something thats _only_ a BSC. Does anyone on this list have an idea for a good name? For all the other programs, I'd also advocate prefixing them with "osmo-", but that's less of a pressing concern right now. 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

GPRS / SGSN status update / HOWTO
by Harald Welte 19 May '10

19 May '10

Hi all! Thanks to the support from On-waves, I've been able to focus on my GPRS work during recent weeks. Today, I have managed to actually perform successful PDP context activation / deactivation using a nanoBTS, OpenBSC, OsmoSGSN and OpenGGSN. This is a big step forward, as it means that the GTP interface between our SGSN and OpenGGSN is up and running. The IP addresses allocated are from a pool defined on the GGSN side, and OpenGGSN opens a tun-device for it. Also, the GGSN implementation is much less proof-of-concept now, as it actually maintains propper MM context, PDP context and other state information. However, for reasons that I couldn't figure out (despite many hours of debugging): There are no user/data plane packets anymore. This was already working before I began the GTP / OpenGGSN intergration work 1-2 weeks ago. The PDP context is established successfully on the LLC-GMM SAPI, the phone shows that GPRS is up, but then it doesn't actually even send a single packet (SNDCP, XID exchange, ...) over any of the user data SAPIs. The SAPI and NSAPI have been assigned properly, and I could not find any differece looking at packet traces for both the cases. If you look at the NS-IP / Gb interface of the nanoBTS, not a single gprs protocol message arrives after the PDP context is activated. After a minute or two, the phone then simply disconnects with "Regular Disconnect" cause, as if nothing had happened. Putting the phone in front of an audio amplifier also doesn't reveal any noticable bursts being generated by the phone. For now I'm feeling a bit lost and will work on some other stuff before returning with renewed energy to the SGSN at some later point. In case you want to try it, the following steps are needed: 1) check out OpenGGSN from git://openbsc.gnumonks.org/openggsn.git (master branch), run the usual autoreconf -1 && ./configure && make install 2) check out current OpenBSC master branch and build it. Only if libgtp (installed by OpenGGSN) is found, it will build src/gprs/osmo-sgsn 3) the IP address where 4) Run OpenBSC like usual, however make sure that the followign settings are configured in the openbsc.cfg config file: gprs mode gprs gprs routing area 0 gprs cell bvci 2 gprs nsei 101 gprs nsvc 0 nsvci 101 gprs nsvc 0 local udp port 23000 gprs nsvc 0 remote udp port 23000 gprs nsvc 0 remote ip 123.192.152.236 Where the last ip address is the address of the machine where you will run OsmoSGSN. 5) Configure /etc/ggsn.cfg of your GGSN machine. Check /etc/ggsn.conf (example attached) Run $ sudo ./ggsn -l 192.168.100.239 -d where that address is the local _listening_ address of the GGSN 6) Then simply fire up osmo-sgsn. The only relevant config setting in osmo_sgsn.cfg is: sgsn nsip local port 23000 7) start your favorite mobile phone and register it to your network You can telnet to osmo-sgsn on port 4245, and type the followign commands for some interesting information: logging enable logging filter all 1 logging level ns info logging level bssgp debug logging level llc debug logging level gprs debug logging level mm debug show ns show bssgp show llc show mm-context all show pdp-context all Oh, and last, but not least: Wireshark can debug the Gb interface packets between BTS and SGSN, you simply have to select 'Decode as .... NSIP' on port 23000 packets. It also decodes the GTP between SGSN and GGSN without any extra setting. Have fun! -- - 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 1

information about Telnet interface
by AHMET GÜLTEKİN 18 May '10

18 May '10

Hi, Can anyone give me information about how i can connect and use telnet interface. I tried by typing " telnet IP 4242" on command line of a PC which was running bsc-hack program but i couldn't succeed. I want to send SMS and use silent call property by using telnet. Please help me. Ahmet.

3 2

gssm running problem
by zero cool 14 May '10

14 May '10

Hi all, once I ran the command ./gssm_usrp.py, I got following error: zero@zero-laptop:~/airprobe/gssm/src/python$ ./gssm_usrp.py Traceback (most recent call last): File "./gssm_usrp.py", line 5, in <module> from gnuradio import gr, usrp, db_dbs_rx, blks2 ImportError: cannot import name db_dbs_rx I searched over internet and found somewhere that Josh and Eric has mentioned that this version of gssm will not work with gnuradio 3.2, it will work with 3.1, is there any other way to run this program on gnuradio-3.2.2. kindly reply me please my configuration: I am using karmic, gnuradio3.2 with modified external 52MHz clock, please help me to get out from this problem On Thu, May 13, 2010 at 3:30 PM, <openbsc-request(a)lists.gnumonks.org> wrote: > Send OpenBSC mailing list submissions to > openbsc(a)lists.gnumonks.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.gnumonks.org/mailman/listinfo/openbsc > or, via email, send a message with subject or body 'help' to > openbsc-request(a)lists.gnumonks.org > > You can reach the person managing the list at > openbsc-owner(a)lists.gnumonks.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenBSC digest..." > > > Today's Topics: > > 1. Re: User location openbsc (Harald Welte) > 2. ipaccess-config changes in master (Holger Freyther) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 12 May 2010 12:52:59 +0200 > From: Harald Welte <laforge(a)gnumonks.org> > Subject: Re: User location openbsc > To: Fabrice Ismael Poundeu Tchouatieu > <fabrice.poundeu(a)smail.inf.fh-bonn-rhein-sieg.de> > Cc: openbsc(a)lists.gnumonks.org > Message-ID: <20100512105259.GP10052(a)prithivi.gnumonks.org> > Content-Type: text/plain; charset=us-ascii > > On Wed, May 12, 2010 at 11:14:27AM +0200, Fabrice Ismael Poundeu Tchouatieu > wrote: > > Hello Harald, > > can you please explain me how the subscriber location actually work > > in openbsc. i have seen that you also have a VLR implemented. How > > does this work? I actually just test the registration and calls in > > roaming mode. To which part of the Openbsc implementation > > (program-code) should i refer to for this (subscriber location > > implementation)? > > We don't really have/use any VLR. All we have is a subscriber table, > and each subscriber can have a completely different MCC/MNC as part of > his IMSI - we simply don't care. There is no distinction between > roaming and home network subscribers at all. > > All we care about is if the subscriber.authorized field is 0 or 1 in > the sql database. > > Regarding 'subscriber location' between multiple BTS: We simply store > the LAC of where the subscriber was last seen. > > -- > - 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) > > > > ------------------------------ > > Message: 2 > Date: Thu, 13 May 2010 01:00:21 +0800 > From: Holger Freyther <zecke(a)selfish.org> > Subject: ipaccess-config changes in master > To: openbsc(a)lists.gnumonks.org > Message-ID: <4BEADEA5.6050307(a)selfish.org> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi all, > > I have done various changes to the ipaccess-config application to work > with a multi-trx setup. I think I have tested everything on both > single-trx and multi-trx setup. If something with ipaccess-config does > not work anymore please shout and I will have a look. > > z. > > > > > ------------------------------ > > _______________________________________________ > OpenBSC mailing list > OpenBSC(a)lists.gnumonks.org > https://lists.gnumonks.org/mailman/listinfo/openbsc > > > End of OpenBSC Digest, Vol 17, Issue 7 > ************************************** > -- Thanks.....

1 0

ipaccess-config changes in master
by Holger Freyther 13 May '10

13 May '10

Hi all, I have done various changes to the ipaccess-config application to work with a multi-trx setup. I think I have tested everything on both single-trx and multi-trx setup. If something with ipaccess-config does not work anymore please shout and I will have a look. z.

1 0

network originated handover
by Open Bsc 12 May '10

12 May '10

Hi, Does anyone know how to create a network originated handover for a selected subscriber on an Ericsson network? Thanks for your answers.. Alper

3 3

OpenGGSN git repository with fixes
by Harald Welte 04 May '10

04 May '10

Hi! I've created a git repository for OpenGGSN, and imported the apparently abandoned openggsn code using git cvsimport. You can clone the repo via "git clone git://openbsc.gnumonks.org/openggsn.git Please note: This is not meant as an attempt to fork or openggsn. I just wanted to add all the fixed that had been contributed to the sourceforge bug tracker to the latest released openggsn code (including a DoS fix from 6 years ago)... so I might as well make this available to others. I'm still hoping to get in touch with the original author and see what we can do to bring those fixes back into mainline and help openggsn's future. 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

OpenBSC gprs-sgsn branch merged into master !
by Harald Welte 04 May '10

04 May '10

Hi all! Since the SGSN was now built as a separate program, the modifications to OpenBSC specific files are none, and the modifications to some shared files were minimal (e.g. adding a new debug category). Thus, I have decided it is no longer useful to keep the gprs-sgsn branch as a separate branch. The GPRS code can now be found in the master branch. Also, all gprs related code is moved to src/gprs to make the distinction more clear. I don't expect any of my upcomign work on the GPRS side to touch the regular BSC codebase in src/ The ipaccess-* executables are now also built in src/ipaccess and I think we should gradually give the code more structure. Too many source file in one directory make things complicated and make it too easy to have strange dependencies. 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

GPRS SGSN status update
by Harald Welte 03 May '10

03 May '10

Hi! The gprs-sgsn branch has seen quite a number of changes during the last week, most of them are related to the gb-proxy that I'm currently implementing. The Gb-proxy can multiplex several Gb connections (each to one BTS) and present them as one NS-VC with many BSSGP-VC (one for each BTS) to the SGSN. The proxy is not needed for most users OpenBSC operation. However, I have now also adapted the SGSN support inside OpenBSC to the modified NS and BSSGP code for the proxy. Furthermore, I've fixed many of its limitations and it should now be fairly generic, working with multiple BTSs, etc. Also, the SGSN is now a standalone program called osmo_sgsn. A lot of the legacy cruft has been eliminated, i.e. the SGSN code does no longer need the gsm_network/bts/trx/... data structures that are not applicable to the GPRS network model anyway. As a result, GPRS ATTACH and RA UPDATE are working again, like they did months ago. I'm now still stuck somewhere in PDP context activation, and am confident that this will be solved tomorrow. After that point, the actual data plane can be worked on, i.e. flow control and fragmentation, as well as somehow actually routing IP packets into the LLC connection. 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 2

Inter-layer state / references / control buffer
by Harald Welte 01 May '10

01 May '10

Hi! I'm getting to a point where we need to associate more and more state and/or references with every individual msgb. In the circuit switched BSC case, every message (msgb) is associated with a logical channel (lchan) through which it is sent. However, in the packet switched case, this is not the case. Rather, a msgb is received on a particular NS-VC, inside a particular BSSGP-VC, inside a LLC session, etc. When we pass a msgb through the protocol layers and back, we somehow need to identify where to send the response to. Once we actually reach the 04.08/04.11 layer, things become a bit less difficult. In the end, all messages are at least somehow associated with a 'subscriber'. If a message passes from the UDP socket into the NS protocol and into BSSGP, we need to know the BSVCI and NSVCI if we want to send a response back. One option would be to pass those values as explicit function call arguments, which is partially what my current code is doing. But the more layers we traverse, the longer the function arguments get. Furthermore, there are parts of our protocol (04.08 and 04.11 particularly) that can either be transported on top of 08.58 (RSL) or LLC/BSSGP/NS. Those upper layers shouldn't really care what the underlying transport looks like. One possible option is to somehow identify the NS-VC and BSSGP-VC by putting an identifier or pointer into a 'struct msgb' member. This would require libosmocore changes every time we add some bits here or there. Another option is to introduce something similar to the skb->cb in the linux kernel: A 'control buffer' area of unspecified content provide by the core networking code as part of every sk_buff, which gets type-casted to the IPCB or TCB-CB when the msgb enters the respective protocol layer. The advantage is that we could have one msgb structure definition with the typecasting functions/macros being part of the application (e.g. openbsc) The problem with this is: Its scope is limited to whatever is the current layer of the protocol stack. The IPCB is overwritten with the TCBCB once the message enters TCP. In our case, we would actually want to have the associated data to persist even while the msgb passes from one layer into another. This would mean that there is a more-or-less static structure containing all the various identifiers, which is then typecasted to the control buffer. While this might not be ideal, it definitely keeps the details hidden away from libosmocore, which is good. Any comments are welcome, 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 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC