diff options
| -rw-r--r-- | 2017/roadmap-osmocon2017/roadmap.adoc | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/2017/roadmap-osmocon2017/roadmap.adoc b/2017/roadmap-osmocon2017/roadmap.adoc new file mode 100644 index 0000000..583f6bd --- /dev/null +++ b/2017/roadmap-osmocon2017/roadmap.adoc @@ -0,0 +1,192 @@ +Osmocom Callular Infrastructure Roadmap +======================================= +:author: Harald Welte +:copyright: Harald Welte (License: CC-BY-SA) +:backend: slidy +:max-width: 45em + +== Disclaimer + +People like Dieter, Holger, Daniel and I have invested lots of our +spare time in the early years. So funding for that came from other +paid work, and Osmocom projects were a hobby. It was a lot of fun, but +it's not a sustainable basis for the scope of the projects at this +time. + +Today, our development is driven by + +* what people contribute patches for, and/or +* what companies and consultants in the project get development + contracts for (e.g. sysmocom customers) + +This means in general that *very little will happen, unless somebody +commits to putting resources at it!* + + +== Major Roadmap Areas + +* Splitting up the NITB +* Code Quality +* Testing +* Integration between 2G and 3G +* External Interfaces + + +== OsmoNITB + +* has been at the heart of most Osmocom based cellular networks +* is generally doing a good job, but suffers from some issues +* NITB includes BSC, but BSC code also used to build OsmoBSC +** No way to test OsmoBSC without a proprietary MSC :( +* NITB includes sqlite3 based HLR +** synchronous/blocking access from single-threaded OsmoNITB +** sqlite3 (particularly via DBI) scalability issues + +== RIP NITB; Long Live OsmoMSC + +* New *OsmoMSC = OsmoNITB - BSC - HLR* +* New OsmoHLR (GSUP interface only) +* 3GPP A-over-IP for OsmoBSC + OsmoMSC +** New SCCP+M3UA stack, libosmo-sigtran +* M3UA based IuCS/IuPS in HNB-GW, MSC, SGSN +** used to be SUA, as it was simpler initially +* Single code base/branch for 2G and 3G + +-> typical 2G setup will become *OsmoBSC + OsmoMSC + OsmoHLR* + +== OsmoSTP + +Signal Transfer Point, part of libosmo-sccp + +* M3UA + SUA support +* Connectionless and Conenction Oriented SCCP +* Used primarily for RAN-CN interface (A, Iu) so far + + +== osmo_fsm + osmo_prim + +osmo_fsm:: structured approach to state machines + +osmo_prim:: structured approach towards primitives at SAP between layers + +== osmo_fsm + +Generalized finite state machine (FSM) abstraction + +* pure C language, no pre-processor / code-generator +* description of states, permitted events in a state, permitted + output states +* buit-in timer support. Default action on expiry: Destroy FSM +* parent/children relationship, allows hierarchy of FSMs + +Much more maintainable and deterministic than the many implicit or +non-existing state machines in older code + +== osmo_fsm so far + +* Ericsson OM2000 managed objects +* Connection-Oriented SCCP +* M3UA/SUA ASP + AS state machine +* All VLR FSMs (LU, Auth, ...) in OsmoMSC +* AMR DTX in OsmoBTS + +== osmo_fsm candidates + +* LAPD + LAPDm code +* A-bis OML managed objects +* GSM Call Control (maybe even CAMEL-like FSMs?) + +More osmo_fsm Would greatly improve code quality, testability and +maintainability + +* but who wants to invest in that? Any volunteers? + +== Testing + +* unit test coverage of most code is poor, needs attention +** coverage of new code much better than old code +* osmo_fsm state introspection via CTRL enables better testing +* end-to-end system testing software: *osmo-gsm-tester* + +== osmo-gsm-tester + +* python language for managing BTSs + Modems +** supports different BTS models +** can execute suites of test cases on each software version for all BTS models +* RF cabling between BTSs and Modems to avoid RF interference + +-> GOAL: Daily functional testing on all supported platforms/configs + +== osmo-gsm-tester + +* core python infrastructure working +* jenkins integration for testing new builds working +* modem hardware being replaced due to poor ofono support for SL8082 + +TODO: + +* modem integration using better supported hardware +* more actual test cases beyond SMS + LU +* 3G support + +== External Interfaces + +* *VTY* is a human interface, not intended for consumption by software +** text output syntax not guaranteed stable +** inefficient +** commands get added during development to help developers + +* *CTRL* interface is the programmatic interface +** but developers don't need it during development +** all commands so far added due to user request/requirement +*** let us know what you need exposed! +** only way to fundamentally change this is to automatically export things without extra effort + +=> Roadmap is to put more effort into CTRL completeness + +== Grand Unified Config Theory + +Big Wishlist item: + +* Unified configuration store / MIB with +** automatic VTY printer/parser generation +** automatic CTRL interface exposure +** telnet/VTY process + MIB daemon outside actual applications + +But who will fund this / put resources at it? + +== Integration between 2G and 3G + +* so far, 2G and 3G live separate to each other +* we want integration +** cross-advertisement of neighbor cells +** inter-RAT mobility +** inter-RAT hand-over +* combined PS + CS attach +* SMS over packet switched + +== Operation / Maintenance + +* generation of Alarms in BTS + PCU (done) +* report via CTRL TRAP as well as A-bis OML (done) +* centralized reporting / collections of Alarms (tbd) + +-> we need to generate more alarms in abnormal situations + +* generation of more stat, counters / KPIs +** lots of work spent in 2016 on this alrady + +-> we need aggregation/interpretation/analysis of that data + +== Further Wishlist + +* move SMSC out of OsmoMSC +* GSUP to MAP gateway +* billing interfaces +* LTE MME/S-GW-/P-GW +** biggest issue is lack of good FOSS asn.1 tools for C +** we either have to ditch C, or invest lots of time in tools :/ + +== EOF + +End of File |