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