OpenBSC December 2009

openbsc@lists.osmocom.org

24 participants
47 discussions

by Sylvain Munaut

Here's a small series with some minor fixes I found when looking at multiple SMS in a single RR connection. For the MO case, it actually now works as described in the spec in the no-error case. But what can happen is that after the second CM SERVICE REQUEST, we may never receive the last CP-ACK of the previous transaction (and thus leak a transaction). The spec says than when receiving a CP-DATA after a CM SERVICE REQUEST we should consider we also implicitely received the last CP-ACK of the previous transaction ... that's not implemented yet. For the MT case, it currently makes several RR connection which is quite bad ... to be fixed. Sylvain

15 years, 6 months

payable freelance consulting on openbsc ?

by Viptel ApS - Kasper H. Hansen

Is there anyone well knowing about the signaling part in openbsc project there might be interested in the solving of a few specific tasks against payment? the results will be posted in the openbsc project also. Please contact me. Med venlig hilsen / Best regards Kasper Hessellund Hansen Denmark Khh at viptel.dk

15 years, 6 months

payable freelance consulting on openbsc ?

by Viptel ApS - Kasper H. Hansen

15 years, 6 months

LCR / RTP interface

by Harald Welte

Hi Andreas + List, I have now studied the new "RTP capable" lcr integration in detail. My sincere apologies once again for the long delay that this has been taking me. I really like the interface (like its predecessor). The major restriction at the moment seems to be its limitation to support only GSM Version 1 Full Rate. After doing some testing with the current 'lcr_rtp' branch in git, as well as the attempt to integrate handover support with the lcr/mncc interface, I am considering to add support for other codec types, too. GSM EFR (only exists in full-rate) is interesting for everyone, as almost all phones support it, and it renders significantly higher quality. GSM V1 halfrate is important for BS-11 users who want increased capacity, since this BTS does not support AMR-halfrate. GSM V1 full-rate is important for ip.access, since it is the only half-rate codec it supports, and thus the only way to increase capacity for this BTS. GSM AMR full-rate is probably of the least interest, but still nice to have. For the 26C3, I would love to run in a EFR-fullrate and AMR-halfrate configuration, depending on the phone's capabilities. 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

First successful handover

by Harald Welte

Hi! I've just committed the current state of the handover code to git. What is working so far: * receiving + parsing the measurement reports from both MS and BTS * performing the actual handover process, i.e. allocating / activating the new logical channel on the new BTS, waiting for the ACK, sending handover command to the MS, waiting for HO complete, HO fail or timeout, ... * a minimalistic handover decision making. without any averaging: If we have a cell that's >= 3dB better than the current one, try a handover. What's missing: * switching the actual traffic channel contents (i.e. re-configuring the RTP streams in the ip.access case, or reconfiguring the TRAU mux in E1 case) * better handover algorithm implementation including averaging I'm on a business trip tomorrow, but the code is already seeming to work quite fine, and it looks like: <0400> abis_rsl.c:980 MEASUREMENT RESULT NR=13 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-61dBm RXL-SUB-dl=-56dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1 <0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -70 dBm <80000> handover_decision.c:61 process meas res: No better cell <0400> abis_rsl.c:980 MEASUREMENT RESULT NR=14 RXL-FULL-ul=-47dBm RXL-SUB-ul=-47dBm RXQ-FULL-ul=0 RXQ-SUB-ul=0 BS_POWER=0 L1_MS_PWR= 10dBm L1_FPC=0 L1_TA=0 RXL-FULL-dl=-87dBm RXL-SUB-dl=-83dBm RXQ-FULL-dl=6 RXQ-SUB-dl=4 NUM_NEIGH=1 <0400> abis_rsl.c:1010 ARFCN=868 BSIC=63 => -69 dBm <80000> handover_decision.c:61 process meas res: Cell on ARFCN 868 is better, starting handover <80000> handover_logic.c:92 (old_lchan on BTS 0, new BTS 1): <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a CHANNEL ACTIVATE ACK <80000> handover_logic.c:151 handover activate ack, send HO Command <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 2 pd 06) Sending 0x2b to MS. <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0 <0010> abis_rsl.c:1107 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a <0010> abis_rsl.c:1082 HANDOVER DETECT access delay = 0 <0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 ESTABLISH INDICATION <0001> abis_rsl.c:1396 channel=(bts=1,trx=0,ts=2) chan_nr=0x0a sapi=0 DATA INDICATION <0008> gsm_04_08.c:1595 HANDOVER COMPLETE cause = Normal event <0002> handover_logic.c:203 lchan (bts=0,trx=0,ts=2,ch=0) decreases usage to: 0 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

Update on GSM network at 26C3

by Harald Welte

Dear All, as you will know, we have applied for an experimental GSM license for the 26C3 (http://events.ccc.de/congress/2009/). Last week, the license was granted. However, only two ARFCN's have been granted (I applied for 8). As it turns out, this was a communication problem. Today they have acknowledged a third ARFCN. So we can have at least one single-TRX BTS on each floor. On wednesday they will determine whether we can have more than three, or if we'll have to live with three ARFCN only. If we get 6, it will be one dual-TRX BTS for each floor. If we get even more, the surplus ones can be used for random experiments. TODO items before 26C3 (for the next couple of days): * finish handover implementation (critical) * do some more testing with LCR integration (Andreas did it, but I also want to have more hands-on experience with it) * introduce log levels and/or per-subscriber tracing functionality to "see the signal among all the noise" while debugging problems in an otherwise busy network * ensure SMS implementation is more robust than at HAR * log all measurement reports to database for later analysis of handover performance. We could also get them from pcap files, so not strictly neccessary. Optional: * finish AMR-halfrate implementation, as this will increase our capacity. This includes dynamically selecting the codec that is used for each call. I don't think we'll manage finishing this, especially with the LCR integration. Standalone might be possible - but that is useless for 26C3 -- - 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

AW: Update on GSM network at 26C3

by Andreas.Eversberg

> Does it means that we won't be able to do OpenBTS experiments there? > We planned to test new USSD code in OpenBTS and it will be a shame to > cancel this plans. i think, if you don't transmit "too loud", i.e ranges lower than a few meters, no one would care. i use a leaky dummy load for testing.

15 years, 6 months

somes problems running OpenBSC with nanoBTS (1800)

by Fabrice Ismael Poundeu Tchouatieu

Hye everyone, i'm trying to build a small GSM Network using OpenBSC and nanoBTS. After the start of bsc_hack, when i try to scanned the network with my mobile station, i do find the right network. But when i try to register into this network, i'm not coming through. It's the first time that i'm trying to used OpenBSC and i do not exactly known how it works. below, a part of the output coming out after the start of bsc_hack: <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. DB: Failed to find the Subscriber. '0' '262##########' DB: Failed to find the Subscriber. '0' '262##########' DB: New Subscriber: ID 28, IMSI 262########## DB: Allocated extension 43234 for IMSI 262##########. <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############) DB: New Equipment: ID 124, IMEI 35############# DB: New EquipmentWatch: ID 124, IMSI 262##########, IMEI 35############# DB: Sync Equipment IMEI=35#############, classmark1=30 <0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH chan_nr=0x28 r=LOCATION_UPDATE ra=0x10 <0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL ACTIVATE ACK <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0 ESTABLISH INDICATION <0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x04 MI(23########) type=NORMAL <0002> gsm_04_08.c:293 lchan (bts=0,trx=0,ts=0,ch=1) increases usage to: 1 <0002> gsm_04_08_utils.c:144 (bts 0 trx 0 ts 0 pd 05) Sending 0x18 to MS. DB: Found Subscriber: ID 28, IMSI 262############, NAME '', TMSI 42########, EXTEN '43234', LAC 0, AUTH 0 DBI: The requested variable type does not match what libdbi thinks it should be libdbi: dbi_result_get_int_idx: field `classmark1` is not integer type <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x20 sapi=0 DATA INDICATION <0004> gsm_04_08.c:948 IDENTITY RESPONSE: mi_type=0x02 MI(35#############) DB: Updated EquipmentWatch: ID 124, IMSI 262############, IMEI 35############# DB: Sync Equipment IMEI=35#############, classmark1=30, classmark2=13 25 , classmark3=13 25 <0010> abis_rsl.c:1273 Activating ARFCN(514) TS(0) SS(1) lctype SDCCH chan_nr=0x28 r=LOCATION_UPDATE ra=0x06 <0010> abis_rsl.c:1088 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 CHANNEL ACTIVATE ACK <0001> abis_rsl.c:1377 channel=(bts=0,trx=0,ts=0) chan_nr=0x28 sapi=0 ESTABLISH INDICATION <0004> gsm_04_08.c:1402 LOCATION UPDATING REQUEST: mi_type=0x01 MI(262############) type=NORMAL <0002> gsm_04_08.c:293 lchan (bts=0,trx=0,ts=0,ch=1) increases usage to: 1 can someone please explains me if those outputs (about the Subscriber ID '28') are OK? Best regards; -- Fabrice Ismael Poundeu Tchouatieu ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

15 years, 6 months

nanoBTS 900

by Axel Walsleben

Hi List, i am searching for a used or new nanoBTS. Best would be an 900Mhz Model, but i take 'everything' i can get. I tried the Haralds Contact, but from there i didn't get any response. It seems that they are not willing to sell anything. :( Regards Axel

15 years, 6 months

ip.access BTS IML dissector for wireshark

by Jai Menon

Hi, Attached is a direct port of the IML dissector code from the ip.access code to wireshark SVN head with a few changes to make it work with the current API. This was done as part of Harald's GSM workout during FOSS.IN and he suggested I post it to this list. I haven't really tested this code since I dont have access to IML traces, but assuming the original code worked, this one should too. Hope this is possibly useful to someone :) -- Jai Menon

15 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC December 2009