Hi Harald,

I'm happy at least somebody notices this work :)

I am reading the code on a daily basis, so no change is unnoticed :-)

I am also reading your blog and watched most of your presentations on CCC.

But back on the topic. I went through the code and for the first time I thought that the OM2000 code is somewhat generic and can be reused of the Nokia part. Then I realised that only the high level of the OML is standardised, the information elements for example do not, and the stuff in OM2000 files are specific to the RBS2000.

Anyway, will take a closer look an try to figure out how this can be implemented for the Nokia part.

Maybe this one will be a bit more interesting: there is a chance I can put my hands on a DBS3900 with a 2G baseband card in it :-) I am not sure how similar Huawei's IP Abis implementation is to what we have now, but I can certainly take a look :-)

There's also some outstanding commits for Nokia regarding hopping, will try to rebase them for the current state of the BSC code and send it to you.

Regards, Csaba ----- Eredeti üzenet ----- Feladó: "Harald Welte" laforge@gnumonks.org Címzett: "Sipos Csaba" sipos.csaba@kvk.uni-obuda.hu Másolatot kap: "OpenBSC Mailing List" openbsc@lists.osmocom.org Elküldött üzenetek: Vasárnap, 2016. Július 10. 21:55:30 Tárgy: Re: Full state machine implementation

Hi Sipos,

On Sun, Jul 10, 2016 at 06:43:51PM +0200, Sipos Csaba wrote:

Just seen your branch regarding FSM:

http://cgit.osmocom.org/openbsc/log/?h=laforge/om2000-fsm

I'm happy at least somebody notices this work :)

It's not complete yet (hence the WIP), and it currently only implements the initialization as set of hierarchical state machines. The FSMs terminate once initialization is done. This could and should probably be further extended to having the BSC-side per-MO FSMs running persistently and tracking the state of their counterparts in the BTS.

I also committed the OM2000 MO initialization sequences messace sequence charts to osmo-gsm-manuals, in case you're curious to see how code corresponds the protocol messages.

Do you think this is also doable for the Nokia Site BTS series?

Of course, why not? I've never looked too deep at the Nokia OML dialect/flavor though. I think for most users the more important part would be the generic one for the TS 12.21 managed objects, which then helps for nanoBTS, OsmoBTS and BS-11.

Because if you think its doable, based on your work I a would like to try and implement this for Nokia support too, as even between different Site versions (InSite, Metro and UltraStie), there are some differences in the OML initialization (especially in the timing of it) which is now handled by hard coded values, instead of a proper state machine.

Sure, I think it would make a lot of sense, technically. I'm just not sure how many OpenBSC useres with Nokia BTS are out there. But that shouldn't keep you from doing it, if you feel an urge to do so :)

Hi Neels,

On Mon, Jul 11, 2016 at 03:15:00PM +0200, Neels Hofmeyr wrote:

On Sun, Jul 10, 2016 at 09:55:30PM +0200, Harald Welte wrote:

...

I'm happy at least somebody notices this work :)

I've actually more than once yearned for the FSM,

My comment above was not about the FSM, but about the OM2000 work, which is quite special-interest.

basically every time I'm fiddling with a request-response schema, tweaking timeout callbacks or trying to guard against messages coming in at the wrong time...

Well, it's not going to be the grand unified theory that solves everything. It's an attempt at putting some more structure into some of the problems we need to solve, but I'm not sure if the first incarnation is already doing a good job at it. Implementing libvlr and OM2000 is sort of a test-ballon for it.

While I like the "structured-ness" and the features about automatic clean-up of child FSMs, reporting of termination to the parent, ... there are also some parts that definitely leave much room for improvement. There's a lot of boilerplate code. I don't really like code generation that much, but maybe some macros could already help with that.

To me it seems that the FSM would improve correctness, reliability and maintainability at pretty much every interface I'm dealing with so far :)

Possibly, but the question is also one about 'how verbose / expressive is the code you need to do it' (I think too verbose / too little expressive yet with current osmo_fsm), and how easy is it to read.

Finally, when handing in opaque structures as part of events, it all goes via 'void *' type casts. So a new class of problems could be introduced by this, one that we currently don't really have (except for osmocom-style signals)