baseband-devel September 2010

baseband-devel@lists.osmocom.org

10 participants
22 discussions

job offer in berlin - breaking basebands, write open GSM tools

by Frank Rieger

I have a job offer in my company for a project to research into and build defenses against over-the air attacks breaking current 2G/3G basebands. The location is in Berlin, Germany, starting soon if possible. Remote work arrangements are not an option. The project is solidly financed by a public research grant, the company is nicely profitable for many years now. Requirements are detailed GSM knowledge, very good reverse engineering and at least decent C/C++ coding skills plus ability to work with a small team in english or german language. All research results of the project will be public and large parts of the development aspect will be on improving the open GSM / 3G tools and thus flow back to the community. Working hours are very relaxed, we are looking for someone who really dives into his work and does not just attend it. Mail me off list if you think you fit the profile. Thanks & Greetings from Berlin, Frank Rieger

14 years, 9 months

AW: Some L1 updates

by Andreas.Eversberg

> * we should not try to introduce new 'hacks' but rather remove old > ones by proper code hi harald, if you sync the osmocore of osmocom-bb, i could remove some "#warning"s due to unavailable structures: struct gsm48_frq_redef struct gsm48_ho_cpl struct gsm48_ho_fail regards, andreas

14 years, 9 months

Some L1 updates

by Sylvain Munaut

Hi, In my sylvain/testing branch, there a a few interesting changes: * Priority support for items in a scheduler bucket Basically for each sched_item, there is a now a priority field and they are executed in order. This allows for example to ensure that a scheduled freq change is executed before accesing the L1 parameters, or to make sure that a control channel RX is scheduled before a RACH TX ... For new items added into the bucket while executing itself (like the abort), those will obviously not be able to obey the priority and will always be executed afterwards. * Common DSP & TPU Scenario init & end Previously, each primitive _cmd initialized the TPU (with network/offset) to the timeslot and also ended the tpu & dsp scenario. This scheme doesn't work when you have several primitives that have a TPU window to open and/or a dsp scenario to run. (this happens when doing RACH in the same frame as reading a CCCH/BCCH bursts, or in the case of SDCCH8[4:7]). Now, each item specifies via some flags if he has a need for TPU and/or DSP. If one item of the bucket needs it, then the common code will handle. : - Aligning the TPU (via offset/network) to the 'base' timeslot (+3 TX offset still has to be added by the primitive) - Restoring base TPU alignement at the end. - Ending both TPU / DSP scenario when everything is done. * A5 support Andreas actually made L23 support and added a stub l1ctl_ command itself. Dieter and I actually made the L1 work in // and not surprisingly came up with very similar results given it's mainly: . Load the key in DSP API NDB & set the mode. . Set a fn parameter properly at each frame The rest is handled inside the dsp. I will now work on merging Dieter's work into the main branch above what I did. - TOA regulation loop to prevent drifting - TX power control - TCH support Cheers, Sylvain Munaut

14 years, 9 months

interface for measurement reports

by Andreas.Eversberg

hi, i like to add layer1 control for measurement reports. my idea is use use normal L1CTL_DATA_REQ with SACCH channel type for sending the (updated) report to layer1. the protocol and message type will be decoded by layer1, so it can detect if this is a measurement report or not. if it is a measurement report, it will overwrite the last stored measuement report. it will be sent whenever there is no other SACCH message in the queue of SACCH messages. if it is not a measurement report, it will be queued as usual. any better idea? andreas

14 years, 9 months

AW: Some L1 updates

by Andreas.Eversberg

really great work! i will check and play with it this weekend. looks like osmocom is getting to a state where it is "usable" very soon. andreas

14 years, 9 months

Re: osmocom with USRP1 as a sw-only MS?

by Sylvain Munaut

Hi, > What's the easiest way to list out the API for layer1.bin? (I can start > searching through the code myself but I thought I would ask first.) See include/l1ctl_proto.h But it's a pretty high level: things like - Go camp on the bcch/ccch - Open a dedicated channel with those parameters - Send this L2 frame ... PS: Make sure to answer to the list and not me. Sylvain

14 years, 9 months

AW: AW: assignment command / status of RR

by Andreas.Eversberg

> then i would suggest to expand the scheduling thing. i will see how > complex that would be... ok, i see that there is also a "one shot" scheduler with full frame number range. (sched_gsmtime.c) i think that i can use this to modify the current channel set. i have code to test it. i don't know if the callback function of the scheduled event is called before or after the actual transmission/reception of the burst, which also sets the right frequency. even if not, there will be only one frame lost.

14 years, 9 months

AW: AW: assignment command / status of RR

by Andreas.Eversberg

> The only function in rfch.c returns the parameter for a given time. > It does _NOT_ and should _NOT_ make any change to the parameter itself. > That's left up to the caller because we need to call that function several time. > If you want to introduce some call that configure the channel and make changes and stuff, put it into another function and make sure it's called when required. then i would suggest to expand the scheduling thing. i will see how complex that would be...

14 years, 9 months

AW: assignment command / status of RR

by Andreas.Eversberg

> Using the scheduler should be relatively easy, you can simply call > sched_gsmtime() and provide it a framenumber and a 'tdma_sched_item'. the > latter will contain the callback that is to be called once the current > framenumber will reach 'fn' as specified. what if there is already a scheduled item? in this case i must schedule the frequency change item before any other item. also the frame number of frequency change may be more than 255 frames ahead. my suggestion: because hopping sequence is a function of time, the starting time should also be included in this function (rfch.c).

14 years, 9 months

osmocom with USRP1 as a sw-only MS?

by Fabio Pietrosanti (naif)

Hi all, after some days digging into the various tools around the GSM opensource playground arena i started understanding better the various piece of software. It seems to me that there's a net separation between the GSM implementation stack of OpenBTS and Osmocom, also because the projects are born with different goals. With the current bb implementation of Osmocom inside Calypso based baseband processor of motorola, all the DSP logic is done directly by the mobile phones chip, right? Which with OpenBTS, it's OpenBTS itself that does the modulation/demodulation along with the USRP. Is there some project and or ideas to bring together the DSP codebase of OpenBTS, together with OsmocomBB to make a MS terminal based on USRP1 device with RFX900 boards? Fabio

14 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel September 2010