Event Feed

The general idea of this is: Have Osmocom programs expose a feed of events reflecting internal state changes.

This feed would allow to have external users (consumers) of such a feed track what's happening inside the Osmocom programs, and visualize it in whatever form.


FSM creation

  • timestamp
  • source file (string)
  • source line (u32)
  • ptr (u32/u64)
  • fsm class (string)
  • ID (string)
  • parent ptr (if any)

FSM event

  • timestamp
  • source file (string)
  • source line (u32)
  • ptr (u32/64)
  • event number (u8/32)
  • state number (u8/32)
  • decoded/interpreted event payload? tlv?

FSM state change

  • timestamp
  • source file (string)
  • source line (u32)
  • ptr (u32/64)
  • old state number (u8/32)
  • new state number (u8/32)
  • timer number (int)
  • timer timeout (u32)
    • optional. old timer could also remain running!

FSM termination

  • timestamp
  • source file (string)
  • source line (u32)
  • ptr (u32/u64)
  • termination cause

FSM rename

  • timestamp
  • source file (string)
  • source line (u32)
  • ptr (u32/u64)
  • old id (string) ?
  • new id (string)

FSM reparent (change or unlink)

  • timestamp
  • ptr (u32/u64)
  • old parent ptr (u32/u64)
  • new parent ptr (u32/u64)

non-FSM events

  • measurement reports (bts/bsc)
  • "jolly fsm" like LAPDm, CC FSMs -> maybe convert them?
  • OsmoPCU: TBF / resoure block allocations per frame number
    • probably needs some quite different handling?


  • ability to enable/disable generation of events per FSM class [or instance?]
  • ability to do retroactive filtering in the visualization tool

format / encoding

  • don't generate JSON directly, let's avoid all the string encoding
  • use CTRL or other interface to query string tables of FSM events and FSM states at runtime
  • external program can use string tables + binary protocol to generate JSON feed for browser
  • external program can collect/aggregate feeds from multiple osmocom programs

visual representation

  • list of instances per FSM class
    • sort it by "most recent", "ID" or "will expire soonest"
  • history / time line for each FSM instance
  • relationship of parent/child FSMs, maybe some kind of tree structure?
  • show FSMs of different osmocom network elements in one view, i.e. BTS+BSC+MSC

misc ideas

  • pass out ptr/addr as u32/u64 to uniquely identify FSM
    • string ID would then only be needed during creation and rename
    • FSM class would then only be needed during creation
    • u32/u64 would be unique identifier for all FSM instances inside one osmo-* program
  • generate "FSM create" events with current state at start-up (optionally?)
Files (0)

Updated by laforge over 5 years ago · 3 revisions

Add picture from clipboard (Maximum size: 48.8 MB)