This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Andreas, thanks for your introduction. On Mon, Feb 22, 2010 at 03:44:00PM +0100, Andreas.Eversberg wrote: > i like to put my experience into the osmocomBB project. therfore i > started working on the layer 3 "call control" (network layer, mobile > side) already. (TS 04.08) the application interface is almost identical, ok, great idea. I think as long as it makes sense, we should keep things as similar to OpenBSC as possible... Feel free to suggest further header files or utility functions that we should move from OpenBSC into libosmocom. Patches for this should go to the OpenBSC-devel mailinglist. > so osmocomBB can be used with linux-call-router also. pleae note that while the signalling plane integration might be relatively easy, I am more worried about the actual voice side of things. In a normal phone, the analog voice data is ADC-converted by the ABB (TWL3025/Iota), which sends it as stream of digital samples to the VSP (Voice Serial Port) of the DSP. The DSP then takes care of the voice frame processing (echo cancellation, codec, etc.) and generates the corresponding GSM bursts which are sent over the air. So in normal GSM phone operation, there is no way how to directly feed raw samples or codec frames from the ARM CPU and transmit them. Thus, it is unlikely that the existing DSP ROM code has any such mode - or rather even more unlikely that any of the existing source code (like TSM30 source) would use any such feature, even if it was present in the DSP ROM code. So to get voice data from lcr sent over GSM, there probably needs to be some binary patching of the DSP firmware. Sylvain and Dieter probably know most about that so far - but even that knowledge is relatively limited, as I understand > the next goal is to implement "radio ressource" protocol and "mobility > management" protocol (real state machine), and i hope to get help with that. > all three protocols are required to do voice calls. Please make your work available as soon as possible, even if it is still incomplete. If you want to push it to a branch of osmocom-bb.git, I can give you an account. I'm now going to be busy with real world items over the next couple of days, so don't expect much progress here. Next week, Zecke and myself intend to actually get the layer2 (lapdm) implemented and have bi-directional communication from the PC to the BTS/BSC on SDCCH's working. > my motivations for joining the project are at the moment: > - having a cool (graphical) network monitor sounds great. I think if you want this kind of application with you on a handheld device, the Openmoko phones are the ideal target. There's a Calypso based chipset that we can run our custom firmware on, and it is connected to a [relatively] powerful application processor that can run Linux + UI toolkit, a GPS receiver and which has access to extensive storage (microSD). It would be great to make the most powerful GSM protocol analyzer, e.g. to constantly iterate over all cells that can be found, obtain the full BCCH information. Geo-tag that with GPS coordinates and create a full map of how the networks look like. Not just Cell-ID, but things like Cell Allocation, the HSN/MAIO you get assigned when requesting channels, etc. I suspect at some point we could even do things like BTS/BSC vendor/model fingerprinting based on implementation details, like OS fingerprinting works with nmap right now :) > - backup line for PBX, PBX in a car. great, but see above: There's a DSP related challenge involved > - attaching (virtual) test SIM via phone's menu yes, that's a very interesting option indeed. Which is one more reason why we'd like to see a fairly complete ISO 7816 filesystem implementation in Free Software C code. This can then be either compiled for a hardware emulator (or even FUNcard), or we could simply compile it for our ARM target and include it in the phone. > - changing IMEI via phone's menu Sure. Or random-generate one at power-up. > i hope this project make as much phun as openbsc. I hope it will make even more fun :) -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)