baseband-devel

baseband-devel@lists.osmocom.org

2 participants
2003 discussions

Suggestions regarding the SIM code
by Harald Welte 23 Sep '10

23 Sep '10

Hi! I just found some time to have a look at the recent commit history and had a look at the SIM related code and had the following suggestions: 1) split the definitions from GSM TS 11.11 into a separate header file from the definitions that are OsmocomBB specific, and move the 11.11 header file into libosmocore 2) use msgb's for SIM messages. This way we can avoid all those manual buffer[N] = M type assignments and rather use msgb_put() constructs 3) even if not going for suggestion '2', it might be good to add some kind of a inline function abstracting out all the blocks that look like + buffer[0] = GSM1111_CLASS_GSM; + buffer[1] = GSM1111_INST_TERMINAL_PROFILE; + buffer[2] = 0x00; + buffer[3] = 0x00; + buffer[4] = length; with something like a "sim_buf_init(buffer, GSM11_INST_TERMINAL_PROFILE);" Of course those are simply suggestions... maybe for the day where somebody on this list is feeling bored and is looking for a quick and easy task to resolve. 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)

1 0

job offer in berlin - breaking basebands, write open GSM tools
by Frank Rieger 20 Sep '10

20 Sep '10

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

1 0

AW: Some L1 updates
by Andreas.Eversberg 17 Sep '10

17 Sep '10

> * 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

2 2

Some L1 updates
by Sylvain Munaut 16 Sep '10

16 Sep '10

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

2 1

interface for measurement reports
by Andreas.Eversberg 16 Sep '10

16 Sep '10

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

2 1

AW: Some L1 updates
by Andreas.Eversberg 16 Sep '10

16 Sep '10

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

1 0

Re: osmocom with USRP1 as a sw-only MS?
by Sylvain Munaut 14 Sep '10

14 Sep '10

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

1 0

AW: AW: assignment command / status of RR
by Andreas.Eversberg 08 Sep '10

08 Sep '10

> 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.

2 1

AW: AW: assignment command / status of RR
by Andreas.Eversberg 07 Sep '10

07 Sep '10

> 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...

1 0

AW: assignment command / status of RR
by Andreas.Eversberg 07 Sep '10

07 Sep '10

> 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).

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel