hi,
i would like to start implementing the trx manager interface support to osmo-bts. before going to work, i'm writing this mail, because i like to read some pros and cons for my approach.
as already stated, thomas a. cooper already implemented an interface between sysmo-bts's dsp device and trx manager interface by using code from openbts, running in an own process [1]. i would like to follow a different approach by writing a scheduler and adding the udp interface for the trx(s). some benefits are in my oppinion:
- not having an extra process running with additional latency and overhead - smaller code, because only a small multiframe scheduler + udp interface for the trx is required (coding scheme and forward error correction code can be used from libosmocore.) - no running after dsp's api changes, (caused by newer firmware of sysmobts) - trx specific features and limitations can be considered. (vty options for setting special features, limitations can affect oml ack/nack responses to be considered by bsc) - no use of multithreading, use of talloc. the code is easier to debug and so becomes more stable. - easy to add initial support for BCCH(+SDCCH4), SDCCH8, TCH/F, TCH/H, PDCH (gprs) for a whide range of applications.
comments are welcome.
regards,
andreas
[1] http://scholar.lib.vt.edu/theses/available/etd-05082012-141540/unrestricted/...
I would suggest something like http://i.imgur.com/F20Q7.png
Where basically you have: - The osmo-bts core and all common BTS logic / A-bis interface and such - It talks to the lower L1 layer via the primitives defined in the spec for creation of channels and stuff. AFAIK it's "pretty" similar to the current DSP interface but some specific stuff might need to be made generic.
Then you have two possible L1 implementation speaking thos primitives - the sysmobts one which basically includes all the specific stuff to convert the 'generic' primitves into the specific call to the DSP.
- The TRX one which includes scheduler / channel coding internally and would use the UDP protocol used by OpenBTS This impl can itself offer a generic interface internally so that the OpenBTS UDP protocol is only one of the possible user of the scheduler / channel coding ...
Cheers,
Sylvain
Sylvain Munaut wrote:
- the sysmobts one which basically includes all the specific stuff
to convert the 'generic' primitves into the specific call to the DSP.
hi sylvain,
your mail inspired me, so i looked deeper at the l1_if.c of sysmobts code.
there is one major function (that calls several other functions): l1if_handle_ind(). it handles data (ph-data-ind, ph-rach-ind) received from dsp and triggers (ph-readytosend-ind) generation and transmission of data (ph-data-request) sent to dsp.
the primitives have a layer-1 header that is specific for the dsp of sysmobts. since the coding of data between l1 and the bts code is not defined in the gsm specs, i think this header is something that sould be used for a split between common and l1 specific part. i would suggest to move the handling and generation of primitives from l1_if.c of sysmobts code to the common part of osmo-bts and only keep the handling of dsp itself.
it would be nice to put femtobts/gsml1prim.h (currently a seperate git) to be part of the common include files. i don't know if the license of that header file allows that.
another thing i need to deeper look at is the oml.c of sysmobts specific code. many stuff could be moved to common part of osmo-bts also, if the layer 1 primitives are used to split between common part and l1 specific part.
the current osmo-bts-bb code would become (already became) obsolete and should be removed.
regards,
andreas
Hi Andreas,
On Fri, Jan 18, 2013 at 02:36:20PM +0100, Andreas Eversberg wrote:
as already stated, thomas a. cooper already implemented an interface between sysmo-bts's dsp device and trx manager interface by using code from openbts, running in an own process [1]. i would like to follow a different approach by writing a scheduler and adding the udp interface for the trx(s). some benefits are in my oppinion:
generally I'm not particular in favor or against any specific implementation. The different approaches all have their advantages and disadvantages.
Just one comment:
- not having an extra process running with additional latency and overhead
agreed, though on any reasonable x86 machine this is not a problem. It is only a problem on something as small as the ARM926 of the symsoBTS, but then there is no point of running this on the sysmoBTS ;)
- no running after dsp's api changes, (caused by newer firmware of sysmobts)
While there have been a number of changes over the last year, the interface is not expected to change anymore at this point. Also, most of the changes in the past were related to the board-specific "femtobts" primitives and not to the actual layer1 API.
So at least this should not be an argument.
Regards, Harald
baseband-devel@lists.osmocom.org
-
Andreas Eversberg -
Harald Welte -
Sylvain Munaut