OpenBSC March 2010

openbsc@lists.osmocom.org

23 participants
36 discussions

[PATCH 0/1] Add bport0/1 support for bs11_config

by Daniel Willmann

Hello, second try to add support to bs11_config for bport0/1 configuration. This time with enum abis_bs11_line_cfg. It seems sometimes creating bport1 fails, even LMT shows create obj greyed out. Don't know why yet. Regards, Daniel Willmann Daniel Willmann (1): Add {create,delete}-bport1 and bport0-{star,multidrop} to bs11-config openbsc/include/openbsc/abis_nm.h | 10 +++++++++- openbsc/src/abis_nm.c | 31 +++++++++++++++++++++++++++++-- openbsc/src/bs11_config.c | 26 ++++++++++++++++++++++++++ 3 files changed, 64 insertions(+), 3 deletions(-)

14 years, 10 months

Can't start nanoBTS properly.

by Nordin

I downloaded and built the latest version of openbsc/libosmocore (that's today's version), but when running, it hangs on this part: <0005> abis_nm.c:519 OC=BASEBAND TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK IP=10.100.1.22 PORT=3003 STREAM=0x00 <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,00) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,01) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,02) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,03) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,04) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,05) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,06) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=CHANNEL(03) INST=(00,00,07) CHANGE ADMINISTRATIVE STATE NACK CAUSE=Message cannot be performed <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1770 Set TRX Attr (bts=0,trx=0) <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) ADM=Unlocked <0005> abis_nm.c:519 OC=RADIO CARRIER(02) INST=(00,00,ff) Sending OPSTART It stops there and nanoBTS keeps blinking green light. When running an older version (without libosmocore), it works well. Is this a familiar behaviour, any idea? Thnx.

15 years, 6 months

building a connection (and communication) between two different nanoBTS GSM Cells

by Fabrice Ismael Poundeu Tchouatieu

Hallo guys, just a question. Did some of you can tell me the best way to connect two different GSM cells (two nanoBTS) and build the communication between the two of them over my IP network? Which components(Astersik, LCR, mISDN ....)are requested for that? is it possible at all? Thanks!! -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

15 years, 6 months

OpenBSC GPRS status update

by Harald Welte

Hi all! As some of you may have noticed, there are some references to GPRS in the openbsc 'master' branch now. The code in there is sufficient to configure a nanoBTS via OML and RSL (SI13) to establish contact with an existing NS-over-IP capable SGSN. All that needs to be done is to set a couple of parameters at the BTS level in openbsc.cfg. I've documented them briefly in the wiki (VTY reference page). Also, at least one of your timeslots have to be of PDCH pchan type. We don't implement dynamic TCH/PDCH switching yet. As the changes required to get this initialization/configuration done are non-invasive, I decided to include them in the master branch right away. If you set 'gprs enabled 0' in your openbsc.cfg, all GPRS functionality should be disabled. This is of course only the first step. The much bigger work will be in the grps-sgsn branch, where work will continue on completing the BSSGP and LLC protocol implementations and the actual SGSN + GGSN functionality. The goal is of course to eliminate the need for an external SGSN/GGSN completely. 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)

15 years, 6 months

Openbsc sounds great, but where can i get the hardware ?

by amed etambelli

Hello there, I was reading throught the openbsc website, and its really a great project i would like to test and particiopate in. Installed the software, the only problem is that i dont have the hardware to test it !!! My question : I am looking for the hardware to test it eg. for one Siemens Bs11 (since the ip.access is a bit too expensive for my pocket :) ), is there a chance to buy such device from any one ? Who is selling this devices ? greets amed _________________________________________________________________ http://redirect.gimas.net/?n=M1003xWin7Geschenk2_WW Hol dir das Gratis-Geschenkpaket von Windows 7 für deinen PC ab!

15 years, 6 months

Merge plan for the On-Waves branch to master

by Holger Freyther

Hi, I have finally an idea on how to go from varpoware "oh I need to merge that" to actually merging stuff and started to work on that. The one goal I have is to create a BSC/MSC split inside our codebase and to make MSC functionality only communicate via a given BSC API. This move will allow to do some things transparently to the MSC code, it includes automatic RLL establishes for SAPI, very early/early assignment will become transparent and in the future I can roll out my "subscriber task" scheduler to do stuff like SMS submit during a voice call... Here is my plan on how to get there... 1.) Create a new structure for the MS Connection. This would happen on a GSM 0808 Complete Layer3 Information message (e.g. CM Service Request, Paging Response). The name I picked is total rubish but can easily changed later. I have embedded this connection into the struct gsm_lchan and moved all MSC attributes into this new structure. So right now we have a 1:1 mapping between a GSM LCHAN and the Subscriber Connection. 2.) Moved transaction code to work on this new structure instead of the lchan, I verified MT-SMS, MO-SMS, MT-Call, MO-Call. So the plan is to remove the occurence of GSM LCHAN from the MSC code paths, this will also mean to remove direct calls to RSL, RLL, paging.c. 3.) I picked gsm_04_11.c as the first file from the MSC (actually SMSC) code to go without the lchan. I have removed the direct call to RSL and placed it behind a new GSM0808 DTAP API. This would be the place where we figure out the real LCHAN.. This is all working and I can build on top of that until I reach the goal at which point I can forward port some of my code from the On Waves branch and instead of playing MSC myself, put it into SCCP... <- now comes the stuff that I want to complete by the end of next month -> 4.) Currently when compiling you see a "BROKEN" warning, this is more that it is broken conceptually as the code handles paging and RLL establishment by itself. So the idea will be to move my "bssap.c" code to master and handle the RLL establishment and paging inside the new BSC API. This would involve queuing of messages... 5.) Remove the callback for SMS from abis_rsl.c and create a bsc_api_init with callbacks for various things (mostly Create Connection, Clear Request, Data). At this point the gsm_04_11.c will be free of BSC code. 6.) Move it to gsm_04_08. This will involve adding new commands (resembling the GSM 08.08) message names, sharing some callbacks between SAPI=0 and SAPI=3 and having a dispatch. E.g. later we should have a handler for new connection which would run authentication and then dispatch the handling of the connection to a task, on task completion close the channel or give it to the next task. After this we should magically be able to switch between very early/early assignment in the BSC code and the MSC will not recognize this, also TCH/H handling with be mostly transparent. 7.) Remove the 1:1 mapping of of GSM LChan to the new struct. Actually the new struct should include two lchan's (in case of handover or assignment), I will have to figure out on how to marry the handover code with that... 8.) I could rebuild my bsc_msc_ip.c on top of the new BSC API and all I need to do is to handle MSC. We could also create a msc_bsc_ip.c which takes these SCCP messages and sticks it into the MSC code of ours and we have a MSC. as usual... any help is more than welcome. z.

15 years, 6 months

Whether to include a cells own BCCH in the BCCH Allocation

by Harald Welte

Hi! I don't exactly remember in which context I was last communicating with whom of you about the question whether or not the BA of a cell should include its own BCCH frequency or not. I think from commercial networks we could see both behaviors, and it was thus unclear what we should do for OpenBSC. I've now found a reference for this in the GMS specs: GSM 3.22 Chapter 4.8: > NOTE: The PLMN operator cannot expect the ME to store the BCCH or > CPBCCH carrier frequency of the serving cell in the SIM unless the > BA(BCCH) includes the BCCH or CPBCCH carrier frequency on which it is > broadcast. So now we know at least the difference when it comes to those two options. 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)

15 years, 6 months

Re: layer3 work / issues

by Dieter Spaar

Hello Harald, On Sun, 28 Mar 2010 13:16:36 +0800, "Harald Welte" <laforge(a)gnumonks.org> wrote: > > as far as I know, it has to change on every retransmission. Dieter is > probably the person who knows all RACH aspects in detail, maybe he can > comment on this. According to the specification the random value has to change on every transmission: a random reference which is drawn randomly from a uniform probability distribution for every new transmission. In the TSM30 firmware this is done by having a table with random values and an index into the table which is initialised to a random value when the Immediate Assignment Procedure is started and incremented with every random number taken for a retransmission. The table has 32 values because the random reference is not larger than 5 bits. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 6 months

layer3 work / issues

by Harald Welte

Hi Andreas, some comments regarding your issues.txt: > must random value in chan_request change on every resend or only on > every RR establishment? (currently it changes on every RR > establishment only.) as far as I know, it has to change on every retransmission. Dieter is probably the person who knows all RACH aspects in detail, maybe he can comment on this. > must be expanded: struct osmocom_ms: no problem here, expand it how you see fit. I just generally prefer caller-allocated structures to callee-allocated ones, and I'd like to use static allocation whenever possible. So if there's only one 'struct rrlayer' per ms, then we should simply include 'struct rrlayer' as sub-structure of 'struct osmocom_ms', rather than having two structures and pointers between them. > OpenBSC: if tx-msg fails during process, the msg must be freed to > avoid memory leak. I don't understand, can you please explain this further? > random acces via RSL? I think we simply add some new / non-standard primitives, as it does not have any notion of RACH bursts. It might also be possible to encode it as UNIT DATA REQUEST for channel (chan_nr) RACH (CCCH uplink), but then we still cannot specify details like at which frame number, etc. From what I can see, your RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom RSLms message and nothing specified in the original RSLms spec. 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)

15 years, 6 months

JFYI: moving 'debug.[ch]' to libosmocore

by Harald Welte

Hi! One of the bigger missing parts in libosmocore is the debug support that we have in OpenBSC, including support for multiple debug categories, log levels, log targets, filters, context, etc. I'm currently half-way through splitting/generalizing the core code from the OpenBSC specific bits (like IMSI context/filter). It's coming along quite nicely - actually less of a problem than I originally thought. The purpose of this is (as usual) to enable OsmocomBB to use the same codebase as OpenBSC for logging/debugging. So this mail is simply a heads-up that some changes will be visible in this area, once again requiring you to update + build libosmocore and OpenBSC after the changes have been committed. The good news, at least it should fail gracefully now, as the OpenBSC autotools magic is now requesting a certain libosmocore version during ./configure. 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)

15 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC March 2010