laforge at gnumonks.org
Tue Feb 23 09:23:37 UTC 2010
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
> 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
> 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
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)
More information about the baseband-devel