# Formal Algebraic Model of an Edge Data Center with a Redundant Ring Topology
## 6 Formal Algebraic Model
However, some tasks might require extra processing capabilities, and in such a case, the orchestrator must send raw data up to the cloud server for it to have the further processing conducted and send them back again, as in this model, the cloud is supposed to deal with all types of requests related to raw data. With all those pieces of information, here they are the models for the objects involved in the processing hierarchy. To start with, poles are identified as \(P_{i}\), where \(i=\{1\cdots 4\}\), such that \(AllPoles=4\), and its model is exposed in (4), as it may just read raw data \(d\) from the environment '_env_' and send it upwards to a broker \(u\), or otherwise, read processed data \(e\) from a broker and send it to the environment so as to act on it. Hence, \(d\) goes upwards and \(e\) does downwards. Furthermore, channels between the environment and a pole, as well as between a pole and a broker are both bidirectional, where directions of the traffic flows involved are stated through an arrow, which applies to all models presented. \[P_{i}=\sum_{i=1}^{AllPoles}\left(r_{env\to i}(d)\cdot s_{i\to u}(d)+r_{u\to i}(e) \cdot s_{i\to env}(e)\right)\cdot P_{i} \tag{4}\]  
The drone is known as \(D_{j}\), where \(j\) would account for further drones involved, even though just 1 is considered now, such that \(AllPones=1\), whilst its model is expressed in (5), where its actions are those related to the pole. \[D_{j}=\sum_{j=1}^{AllPones}\left(r_{env\to j}(d)\cdot s_{j\to u}(d)+r_{u\to j}(e) \cdot s_{j\to env}(e)\right)\cdot D_{j} \tag{5}\]  
The broker is called \(B_{u}\), where \(u\) would make for future brokers involved, although only 1 is considered now, such that \(AllBokers=1\), whereas its model is shown in (6). Basically, it may receive raw data \(d\) from any end device (that being either a pole \(i\) or a drone \(j\)), and in turn, it may either process them with the help of an AI tool named \(AI_{B}\) and send back the processed data \(e\) to that end device, or otherwise, send the raw data \(d\) up to an orchestrator \(v\) if such processing requires more computing power. \[ \begin{split}& B_{u}=\sum_{k=1}^{AllPokers}\left(\left(r_{i\to u}(d)+r_{j \to u}(d)\right)\cdot\\ &\left(\left(s_{u\to i}(e)+s_{u\to j}(e)\right)\triangleleft AI_{ B}\triangleright s_{u\to v}(d)\right)\right)\cdot B_{u}\end{split}  \tag{6}\]  
The orchestrator is named \(O_{v}\), where \(v\) would be kept for future orchestrators put in place, even though just 1 is accounted, such that \(AllOrchs=1\), whilst its model is depicted in (7). Its task is to receive raw data \(d\) from a broker, and then, it may process them by using an AI tool called \(AI_{O}\), that being more powerful that the one being shown for the brokers, and in turn, processed data \(e\) are forwarded to the proper broker. In addition, that processed data might also be sent up to a cloud server \(w\) just in case the processing power needed is not enough. \[O_{v}=\sum_{p=1}^{AllOrchs}\left(r_{u\to v}(d)\cdot\left(s_{v\to w}(e) \triangleleft AI_{O}\triangleright s_{v\to u}(d)\right)\right)\cdot O_{v} \tag{7}\] \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Object** & **Type** & **Location** & **Migrate** \\ \hline pole 1 & fixed end device & quadrant 1 & No \\ pole 2 & fixed end device & quadrant 2 & No \\ pole 3 & fixed end device & quadrant 3 & No \\ pole 4 & fixed end device & quadrant 4 & No \\ \hline drone 1 & moving end device & move around & No \\ \hline broker 1 & edge server & physical host & Yes \\ \hline orchestrator 1 & fog server & physical host & Yes \\ \hline cloud 1 & cloud server & cloud host & No \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Objects taking part in the model proposed. The cloud is addressed as \(C_{w}\), where \(n\) would be used if more than one cloud server were employed, although only 1 is considered now, in a way that \(AllClouds=1\), whereas its model is exhibited in (8).