OpenBSC

openbsc@lists.osmocom.org

1 participants
4154 discussions

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, 7 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, 7 months

[PATCH] bugfix: additional functionality indicator only appears in TP_VPF_ENHANCED

by Steffen 'stefreak' Neubauer

The patch is attached ("bugfix"). You can simply merge the stefreak/trivia branch (but there is one more change in it, see the second patch attached. abis_nm.c was executable, that's a really trivial change). Greetings, Steffen

15 years, 7 months

Re: Issues on initial setup with BS-11

by Dieter Spaar

Hello Paul, On Thu, 03 Dec 2009 17:51:45 +0000, "Paul Dolan" <paul(a)dolan.ie> wrote: > > Any other ideas/things to try/etc. would be greatly appreciated! Can you check the "PLL set" and "PLL work" values with bs11_config ? If the BS-11 is locked to the E1 clock, it could be that the clock of the BS-11 is too far away from the correct value so that a phone will only find the official networks but not the one of the BS-11. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 7 months

packet_gsm-ipa update patch

by Anand Raj Manickam

Hi , Please find the patch for packet_gsm-ipa.c attached . This patch updates few fields. Thanks, Anand

15 years, 7 months

Re: Issues on initial setup with BS-11

by Dieter Spaar

Hello Paul, On Wed, 02 Dec 2009 22:36:53 +0000, s4dd(a)losers.yore.ma wrote: > Any help you guys could give is much appreciated! I think the problem is the "Invalid Channel Combination!!!" error message. Try to change "phys_chan_config" of timeslot 1 from "SDCCH8" to "TCH/F". From my understanding of verify_chan_comb() "SDCCH8" is not allowed on the same TRX that already has "CCCH+SDCCH4" so I wonder why it is set in the config file (this only applies to the BS11). Sorry, I don't have a ready BS11 configuration at hand right now, so I can't test it. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

15 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC