Hi Andreas,
I'm going to pick up your questions as found in your preliminary http://home.eversberg.eu/alpha3/ code.
I took the liberty of posting to the ML, as other people will definitely be interested in this, too.
1) why is layer2 a socket client?
because we want to develop layer2 + layer3 + everything above on the PC first, while keeping the L1 on the phone. This makes debugging much easier. Later we will simply move the code to the phone and run it in one or multiple tasks of the operating system, replacing sercomm + unix socket with message queues.
2) where is layer3 to go?
I think we can directly put it into the layer2 program, but try to keep a clean seperation between l2 and l3, using the REQUEST/RESPONSE/INDICATION primitives.
3) where should the app (layer4) go? library or console?
it should live on top of the l23 stack, preferrably as its own program.
There is a lot of sense for having the application (UI) as its own process/thread, and the stack in its process/thread.
4) Is the TLV parser buffer-overflow safe?
TLV parser (libosmocore) is not buffer-overflow safe, patches are appreciated.
5) classmark1 lsb/msb twisted:
I have no idea :)
6) lchan/ms mapping.
I don't have a clear idea on this either. I'm not so sure if the 'lchan' concept makes much sense in a phone at all. A phone typically only uses one dedicated channel at any given point - with corner cases in the event of a handover, where we 'switch back' to the old channel if establishing the new channel fails.
7) ms instantiation for multiple devices
I think this is not really an important issue at the moment. If there are multiple phones, there should be multiple instances (processes) of the layer23 stack. A normal application would also exist 1:1 for each stack instance.
If you think of some PBX application, than I also think it is easier to have one instance (process or thread) of the stack for each phone.
After all, the primary target for us is to make layer2+3 work in a phone, and there it will definitely be one instance for one phone.
One additional comment:
Please make sure that the common/shared code between OpenBSC and your Layer3 does get moved into libosmocore. I'm thinking particularly abotu code for parsing and generating the various IE's. We don't want to keep multiple implementations around...
Thanks again for all your help, Harald
On Monday 01 March 2010 09:47:27 Harald Welte wrote:
- classmark1 lsb/msb twisted:
I have no idea :)
Some of our OpenBSC structures don't work nicely on MSB machines. This means we have to write our bitfields the other way around for that. It would be nice if we could have a macro or such to do it...
- lchan/ms mapping.
I don't have a clear idea on this either. I'm not so sure if the 'lchan' concept makes much sense in a phone at all. A phone typically only uses one dedicated channel at any given point - with corner cases in the event of a handover, where we 'switch back' to the old channel if establishing the new channel fails.
I would go for a primitive "lchan" that layer2 can operate on. In some cases we need to know the chan type on LAPDm for timeouts, retries... and for the case of the assignment command and such we need to move a LAPDm "session" from one chan to another and back again.
Hi Andreas.
As you may have noticed, we have reached a point with L1 and 'layer23' where your L3 work could actually be testea, given the following preconditions:
* BTS with no frequency hopping, no encryption * combined CCCH (with SDCCH/4 on TRX0)
the 'layer23' program already sends a fake LOC UPD REQ to the BTS, just to test if the transmit path is working.
I didn't want to continue at this point, as there are many other tasks that desperately need attention - but also since you have been starting with work on MM procedures like location updating by yourself.
If you configure a BS-11 or nanoBTS with OpenBSC to use a combined CCCH, you should be able to develop your code and immediately test it on the 'live' system.
I would really appreciate if you could start a git branch with your code added to the 'layer23' program - even if it doesn't compile yet and is incomplete.
This way everybody is aware of what you are doing and we don't get any duplicate work.
Cheers, Harald
baseband-devel@lists.osmocom.org