• Table of contents
• Event Feed
  • Events
    • FSM creation
    • FSM event
    • FSM state change
    • FSM termination
    • FSM rename
    • FSM reparent (change or unlink)
    • non-FSM events
  • filtering
  • format / encoding
  • visual representation
  • misc ideas

Event Feed¶

General idea: Feed of events pushed out from [each] Osmocom program

Events¶

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?

filtering¶

• 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?)