From cec90c77924e749911ccba6abdd0e4a32b9904e1 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Tue, 25 Apr 2017 15:06:40 +0200 Subject: osmocon slides update --- 2017/roadmap-osmocon2017/roadmap.html | 4448 +++++++++++++++++++++++++++++++++ 1 file changed, 4448 insertions(+) create mode 100644 2017/roadmap-osmocon2017/roadmap.html (limited to '2017/roadmap-osmocon2017/roadmap.html') diff --git a/2017/roadmap-osmocon2017/roadmap.html b/2017/roadmap-osmocon2017/roadmap.html new file mode 100644 index 0000000..c1950f6 --- /dev/null +++ b/2017/roadmap-osmocon2017/roadmap.html @@ -0,0 +1,4448 @@ + + + + +Osmocom Callular Infrastructure Roadmap + + + + + + + + +
+

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

+
+
+ + -- cgit v1.2.3