TS M30 files processing

Hopsing K hopsingk at gmail.com
Wed Mar 10 11:41:11 UTC 2010

2010/3/9 Harald Welte <laforge at gnumonks.org>

> Hi Hopsing K,
> On Mon, Mar 01, 2010 at 10:48:39PM +0100, Hopsing K wrote:
> > I was preparsing the TS M30g smStack a bit and
> > came out with something like this:
> > http://netplugin.sourceforge.net/  ++append+next++
> > htmltag/CC/cc_act.c.pinfo.main.php
> > (please concat the two url parts).
> Thanks for sharing this.
> However, please consider that even while the TSM30 code has been
> available online for some 5 years now (and thus the information
> contained in it can no longer be considered a trade secret): The code
> still has copyright, i.e. without the explicit approval of the copyright
> holders you cannot redistribute it and make copies (like now on
> netplugin.sf.net).

I know.

> > I wondered weather I could support this project a
> > bit by processing some more of the TS M30 files.
> Thanks a lot for your offer.  I suppose those people who look at the
> TSM30 code so far (including myself) are using non-networked tools like
> 'ctags' / 'etags' for source navigation.
I could generate file-based versions that could be run locally.
Still a local webserver is needed. If I pack all info in a single html
file it will be overloaded and you cant navigate...
ctags might be good however you cannot just click on macros to
expand and at the same time see the definition position, similary
you cannot click open a include position.
is kind of easier to handle. (When opening the above link it'll
take a while until it gets started, first the main page has to be fetched
inserted using ajax).

To be true, even if I can freely navigate the source I still cannot
understand it. Problem is well that GSM is too complex and
no documents availabe that describe a simple setup.

What I would like to have is:

 - For a minimal setup for a voicecall I'd want
  a flow diagram (the kind of diagram where time runs from top to bottom and
  calls/replies between i.e. Cellphone and BTS are shown a arrows left/right
 - Then in that flow diagram I'd need html links that pinpoint
   the location where the call is done in the TSM30 stack (using the
   prorocessed html) and be able to quickly jump to it.
 - At the same time have a link to the etsi standard page where
   the call/replies is specified.

That way I could visualize in practice how it works. There is no chance
I guess for someone to understand it otherwise. There are 100 of
etsi standards pages, at the same time you intuitively guess that it
cannot be that complex if it is a simple setup.

> >   Also some hint:
> >   Isnt there a software only way to run the stack:
> >   Put even Layer1 on the PC ? Then connect
> >   directly to BTC software? Kind off skip the messy
> >   embedded thing altogether for development.
> this is something I've been thinking about in the past. but then you
> need to
> 1) implement a 'fake BTS' that implements at least the Layer2 (possibly
>   also Layer1) over e.g. multicast IP
> 2) Connect this 'fake BTS' to OpenBSC
> 3) implement a 'fake layer1' for the MS side implementing the same
>   "Um over multicast IP" approach.
> From there on you can implement Layer2 and Layer3 on the phone side
> without having to go through the real layer1 or at least without having
> to go through the air.
> But without a clear path to later porting this on a real physical
> layer1, there would be little motivation of doing all that work.

I'd like to get involved in that, however these are my problems:
- I have no running system that I could debug and
  thereby learn how GSM works.
-  To  get a running system I would need to implement a software
   only system, however, I cannot implement that without knowledge
   of GSM
 That is kindof a deadlock.

Therefore I wonder weather the expert of GSM would share their
knowledge in the obove described way:
  - a flow diagram
  - the etsi standard pages (or simple rewrites of it)
  - the html parsed imlemention of a real TSM30 stack implement.
and linking that all together to get a way for a newbie to
get started.

> I think what makes OsmocomBB special is the very fact that we do not
> have to rely on simulation, but can do the "real thing".
> Nonetheleess, if somebody was interested in implementing what I've
> described, I'd be more than happy to help any such project and
> include the neccessary support in OpenBSC and/or OsmocomBB.
> --
> - 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20100310/60f87328/attachment.html>

More information about the baseband-devel mailing list