baseband-devel September 2018

baseband-devel@lists.osmocom.org

3 participants
6 discussions

Start a nNew thread

Engagetted !
by Sébastien Lorquet 14 Oct '25

14 Oct '25

http://www.engadget.com/2010/12/29/researchers-eavesdrop-on-encrypted-gsm-c… Congrats!

7 7

Calypso BTS
by phreaker1983 16 Nov '19

16 Nov '19

I tried to install CalypsoBTS have libosmocore installed, osmo-bts osmobsc, libosmo-netif, libosmo-abis, ortp, trx, libosmo-dsp everything went without errors, following the instructions I created: touch ~/.osmocom/open-bsc.cfg , then when you run : osmo-nitb -c ~/.osmocom/open-bsc.cfg-l ~/.osmocom/hlr.sqlite3-P-C --debug=DRLL:CC:MM:RR:RSL:NM shows me:<0005> bsc_init.c:498 Failed to parse the config file: '/root/.osmocom/open-bsc.cfg' file tried to create as administrator but without success , pleas help me -- View this message in context: http://baseband-devel.722152.n3.nabble.com/Calypso-BTS-tp4026753.html Sent from the baseband-devel mailing list archive at Nabble.com.

6 13

Fwd: OSMOCOM-BB HandOver
by Muhammad Awais Aslam 12 Jan '19

12 Jan '19

Hi, We have been working on the handover feature in OsmocomBB and have managed to make some progress including SB/BSIC detection in dedicated mode which was not previously being successfully done in firmware. I wanted to share it and seek guidance on the last bit of handover implementation on which we are stuck. I hope someone would be able to help us or make use of our work. We took code related to handover from the osmocom-bb jolly branch by manually adding/deleting stuff in the master branch as updating to the latest copy was giving us issues. We added code from the “Safely change TPU offset on TS change or sync change” commit till the “Use only sel_si for information about the current cell” commit. Using the handover code in the jolly branch and after making the changes explained below we were able to obtain the handover command from the BTS. The synchronized handover case works sometimes though still not every time, however the non-synchronized case doesn't work at all as we are not able to get the physical information command from the new cell. I'll explain the changes/additions we made to achieve this. Firstly, we noted that in dedicated mode SB burst was not being detected. Changes were required at three main places in order to correctly perform FB/SB detection: - It was seen that the results for SB were being read from DSP API location dsp_api.db_r->a_sch which is for the idle mode. The results had to be read from the dsp_api.ndb->a_sch26 location for the dedicated case if TCH_SB_DSP_TASK is used. - After reading the FB we needed to update the quarter-bit offset of the TPU using the TOA of the FB to sync it with the start of frame of the neighbour cell in order to catch the SB (by changing the vaule of l1s.tpu_offset using the TOA of the FB). - Frequency compensation needed to be performed using the afc_correct function before reading the SB. * We actually kind of cheated a bit by adding 3 frames to the original idle frame in order to give us more time to perform FB/SB detection including the synchronizations mentioned above. This was because we weren't that proficient with the code and someone with more understanding could do this better. The call did not get dropped. We used the initial added “idle” frame to perform the quarter-bit and frequency compensation which was reversed in the idle frame with the response function to tune back to the serving cell. These things, when added to the code did the trick and BSIC of the neighbours was obtained. Once the BSICs were decoded the measurement report sent to the BTS became meaningful and the handover command was received. Upon receiving handover command, access bursts needed to be sent on the new channel which again was not currently being implemented properly as in order to tune to the new cell we needed to know its quarter-bit offset for start of frame, frequency compensation and absolute frame number which were not previously being obtained. Now that we were able to detect FB and SB these values were stored for the neighbours following detection of these bursts and were used to tune to a neighbour cell in case of a handover to it before the sending of access bursts. However, here is where we are stuck. We were expecting a physical information message following the access bursts but were not able to receive it due to which the handover failed. If only that could be achieved we believe handover should be successful. Either we are not syncing properly to the new cell or we might not be following GSM protocol properly. We also might not be reading the FACCH properly for physical information message after tuning to the new cell as we couldn't really understand that bit very well. We wanted someone expertise on this matter and were hoping our work could be of use. We were more interested in getting the work done first up. Best Regards, M. Awais Aslam

3 3

no GSMTAP-Header-Remover in Gnuradio
by Thomas Baach 17 Oct '18

17 Oct '18

2 1

Save the Date: OsmoCon 2018 on October 18-19, 2018
by Harald Welte 16 Oct '18

16 Oct '18

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - 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

Questions regarding maintaining synchronization of a mobile station
by Piotr Krysik 21 Sep '18

21 Sep '18

Hi all, Gr-gsm's receiver currently relies on having SCH channel to keep synchronization. I want to remove that requirement so it'll be more usable in an SDR based burst transceiver for OsmocomBB. To do this it would be great to know how normal mobile phones maintain synchronization, something I don't know currently. Especially: 1. How often mobile station (MS) checks if the synchronization is kept? 2. What is usually used to check if synchronization is kept, especially when a MS is on a traffic channel? 3. How MS regains synchronization? Does it always do full FCCH+SCH scan? Thanks in advance, Piotr Krysik

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel September 2018