Event Feed » History » Revision 2
Revision 1 (laforge, 06/22/2018 05:03 PM) → Revision 2/3 (laforge, 06/22/2018 05:03 PM)
{{>toc}}
h1. Event Feed
General idea: Feed of events pushed out from [each] Osmocom program
h2. Events
h3. FSM creation
* timestamp
* source file (string)
* source line (u32)
* ptr (u32/u64)
* fsm class (string)
* ID (string)
* parent ptr (if any)
h3. 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?
h3. 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!
h3. FSM termination
* timestamp
* source file (string)
* source line (u32)
* ptr (u32/u64)
* termination cause
h3. FSM rename
* timestamp
* source file (string)
* source line (u32)
* ptr (u32/u64)
* old id (string) ?
* new id (string)
h3. FSM reparent (change or unlink)
* timestamp
* ptr (u32/u64)
* old parent ptr (u32/u64)
* new parent ptr (u32/u64)
h3. 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?
h2. filtering
* ability to enable/disable generation of events per FSM class [or instance?]
* ability to do retroactive filtering in the visualization tool
h2. 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
h2. 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
h2. 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?)
