Project

General

Profile

Event Feed » History » Version 3

laforge, 06/22/2018 05:32 PM

1 1 laforge
{{>toc}}
2 2 laforge
3 1 laforge
h1. Event Feed
4
5 3 laforge
The general idea of this is: Have Osmocom programs expose a feed of events reflecting internal state changes.
6
7
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.
8 1 laforge
9
h2. Events
10
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                             
11
h3. FSM creation    
12
                                                                                                                                                 
13
* timestamp                                                                                                                                         
14
* source file (string)
15
* source line (u32)
16
* ptr (u32/u64)
17
* fsm class (string)
18
* ID (string)
19
* parent ptr (if any)
20
21
h3. FSM event
22
23
* timestamp
24
* source file (string)
25
* source line (u32)
26
* ptr (u32/64)
27
* event number (u8/32)
28
* state number (u8/32)
29
* decoded/interpreted event payload? tlv?
30
31
h3. FSM state change
32
33
* timestamp
34
* source file (string)
35
* source line (u32)
36
* ptr (u32/64)
37
* old state number (u8/32)
38
* new state number (u8/32)
39
* timer number (int)
40
* timer timeout (u32)
41
** optional. old timer could also remain running!
42
43
h3. FSM termination
44
45
* timestamp
46
* source file (string)
47
* source line (u32)
48
* ptr (u32/u64)
49
* termination cause
50
51
h3. FSM rename
52
53
* timestamp
54
* source file (string)
55
* source line (u32)
56
* ptr (u32/u64)
57
* old id (string) ?
58
* new id (string)
59
60
h3. FSM reparent (change or unlink)
61
62
* timestamp
63
* ptr (u32/u64)
64
* old parent ptr (u32/u64)
65
* new parent ptr (u32/u64)
66
67
h3. non-FSM events
68
69
* measurement reports (bts/bsc)
70
* "jolly fsm" like LAPDm, CC FSMs -> maybe convert them?
71
* OsmoPCU: TBF / resoure block allocations per frame number
72
** probably needs some quite different handling?
73
74
75
h2. filtering
76
77
* ability to enable/disable generation of events per FSM class [or instance?]
78
* ability to do retroactive filtering in the visualization tool
79
80
h2. format / encoding 
81
82
* don't generate JSON directly, let's avoid all the string encoding
83
* use CTRL or other interface to query string tables of FSM events and FSM states at runtime
84
* external program can use string tables + binary protocol to generate JSON feed for browser
85
* external program can collect/aggregate feeds from multiple osmocom programs
86
87
h2. visual representation
88
89
* list of instances per FSM class
90
** sort it by "most recent", "ID" or "will expire soonest"
91
* history / time line for each FSM instance
92
* relationship of parent/child FSMs, maybe some kind of tree structure?
93
* show FSMs of different osmocom network elements in one view, i.e. BTS+BSC+MSC
94
95
96
h2. misc ideas
97
98
* pass out ptr/addr as u32/u64 to uniquely identify FSM
99
** string ID would then only be needed during creation and rename
100
** FSM class would then only be needed during creation
101
** u32/u64 would be unique identifier for all FSM instances inside one osmo-* program
102
* generate "FSM create" events with current state at start-up (optionally?)
Add picture from clipboard (Maximum size: 48.8 MB)