-
Notifications
You must be signed in to change notification settings - Fork 2
/
2_DAPNET_Network_Definition.tex
129 lines (101 loc) · 5.92 KB
/
2_DAPNET_Network_Definition.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
\chapter{DAPNET Network Definition}
\section{Cluster Description}
\subsection{Real-time Message delivery with RabbitMQ}
\label{dapnetdef:clusterdesc:rabbitmq}
\subsection{Distributed Database with CouchDB}
\label{dapnetdef:clusterdesc:couchdb}
\subsection{Authentication Concept}
\subsection{Integration of new Nodes}
\section{Interface Overview and Purpose}
\subsection{RabbitMQ Exchange}
There are 3 exchanges on each RabbitMQ instance available:
\begin{description}
\item[dapnet.calls] Messages that are distributed to all nodes
\item[dapnet.local\_calls] Messages coming only from the local node instance
\item[dapnet.telemetry] Messages containing telemetry from transmitters
\end{description}
Transmitters publish their telemetry data to the \textbf{dapnet.telemetry}
exchange, while consume the data to be transmitted from a queue that is bound to
the \textbf{dapnet.calls} and \textbf{dapnet.local\_calls} exchanges.
The idea is to distinguish between \textit{local} data coming from the local
Core instance and data coming from the DAPNET network. This is necessary, as for
example the calls to set the time on the pagers are generated by the local Core
and not shall not distributed to other Cores and their connected transmitter to
avoid duplicates.
\subsubsection{dapnet.calls}
This federated exchange receives calls from all Core instances. Personal calls
are always published to this exchange, as they are unique and only published by
the Core that receives the call via the \hyperref[dapnetdef:corerestapi]{Core
REST API}. Rubric content is also emitted here. The transmitter to receive the
call is defined via the routing key.
\subsubsection{dapnet.local\_calls}
The the local Core publishes special calls to this exchange, like the time set
calls, the rubric names and repetitions of rubric content for the local
connected transmitters.
In short, all calls that are generated by the
\hyperref[dapnetdef:other:scheduler]{Scheduler} on a Core instance are published
to this exchange. As the scheduler runs on every node, otherwise the calls would
be transmitted several times by the same transmitter. This exchange is not
federated with other RabbitMQ instances on other Cores.
\subsubsection{dapnet.telemetry}
On each Core instance, the
\hyperref[dapnetdef:statisticstatustelemetry]{Statistic, Status and Telemetry}
microservice described in section \ref{dapnetdef:statisticstatustelemetry} is
consuming the telemetry of all transmitters. The received data is stored and
delivered via the \hyperref[dapnetdef:corerestapi]{Core REST API} and the
\hyperref[dapnetdef:websocket]{Websocket API} in section
\ref{dapnetdef:websocket} to connected websites or apps.
\subsection{CouchDB Interface}
\label{dapnetdef:couchdbinterface}
The CouchDB interface is a REST interface defined in the CouchDB documentation.
All communication with the CouchDB database are done by means of the interface.
No user should be able to connect to the CouchDB REST interface, only the Core
software components should be able to do so. The local node can access CouchDB
with randomly created credentials which are automatically generated on the first
startup of the node. For database replication, the other nodes are authenticated
by their authentication key in the nodes database.
\subsection{Core REST API}
\label{dapnetdef:corerestapi}
The Core REST API is the main interface for user interactions with the DAPNET network.
\subsection{Statistic, Status and Telemetry REST API}
\label{dapnetdef:statisticstatustelemetry}
\subsection{Websocket for real-time updates on configuration, Statistics and Telemetry API}
\label{dapnetdef:websocket}
\subsection{MQTT Fanout for third-party consumers}
\label{dapnetdef:mqttfanout}
In order to allow third-party application to consume the data sent out by DAPNET
transmitters in an easy and most generic way, there is an MQTT brocker on each
Core. As the \hyperref[dapnetdef:clusterdesc:rabbitmq]{RabbitMQ} instance
already has a plugin to act as an MQTT broker, this solution is chosen.
To dynamically manage the third-party applications attached to DAPNET, there is
a \hyperref[dapnetdef:clusterdesc:couchdb]{CouchDB}-Database containing the
existing third-party descriptive names, corresponding MQTT topic names and
authentication credentials to be allowed to subscribe to the that specific MQTT
topic.
It is a intention to not fan out every content on DAPNET to every third-party
application but let the user decide if personal calls directed to her/him will
be available on other third-party applications or not. The website will display
opt-in checkboxes for each subscriber to enable or disable the message delivery
for each third-party application. As we have had some issues in this topic in
the past, this seems the best but still generic and dynamic solution.
The fan out consists of the source and destination callsign, the destination RIC
and SubRIC and an array of callsign and geographic location of the transmitters,
where this specific call is supposed to be sent out by DAPNET transmitters. The
type of transmitter is also given. The reason to output also the transmitter and
their location is to enable third-party applications to estimate the content's
distribution geographic area and take adequate action for their own delivery or
further processing. (Example: Regional Rubric content to Regional DMR Group
SMS.)
The third-party applications can (if access is granted) only read from the
topic. All Core instaces have read/write access to publish the data.
The MQTT topics are kept local on the Core instance and are never distributed
between DAPNET-Cores.
\section{Other Definitions}
\subsection{Scheduler}
\label{dapnetdef:other:scheduler}
\subsection{User Roles and Permissions}
There are two types of users: Admins and Non-Admins. Admins are allowed to do
everything. Non-Admins are just allowed to edit the entities that they own and
send calls.
\todo{Make overview of data displayed to Non-Admin users from
CouchDB in REST-Calls (see \ref{protocoldef:microservicesapi}.}