## 5 Example
### Introducing the Networking Layer  
To the configuration of Figure 3, we now add the _Cloud_ and the _Networking layer_ to fully implement the configuration of Figure 1. Flows between application entities must pass through the Networking layer, and so storage entities (such as databases, servers, etc.) have been added to the Cloud; hence, at least an equivalent storage entity (i.e., with the same label) is associated with each equivalence class of application entities. Storage entities are identified with primes. For example, we have added an entity \(G^{\prime}\) that allows the _ReanimationWkstrn_, entity \(G\), to retrieve the data received from the sensors. We have also deleted any entity-to-entity channels that are not transited by a storage entity. Note that the required data flows between application entities (and no others) are still obtained by transitivity. In Figure 7, we see that databases A\({}^{\prime}\), B\({}^{\prime}\), G\({}^{\prime}\), and K\({}^{\prime}\) were added to function as storage entities. The partial order of equivalence classes implemented by this configuration is shown in Figure 8.  
For the implementation configuration of Figure 9, the sensors are connected to access points that transfer their data to first-level cloud routers. These cloud routers forward the data to the storage entities. Finally, second-level routers are configured to connect the user endpoints to the first level of cloud routers. By adding the required routers, we obtain the configuration shown. Figure 8: Partial order for the centralized architecture. Figure 7: Cloud configuration for Figure 3.  
The configuration of Figure 9 is an extension of the configuration of Figure 6, obtained by adding the mentioned new storage entities or databases and a router among them. As required, all the storage entities are connected to the _Cloud Router_, the application entities are connected to the _App Router_, and the sensors are connected to an _Access point_, which in turn is connected to the _Cloud router_, just as in Figure 7. No direct communication between application entities occurs, and all data passes through the _Cloud Router_. However, communication between storage entities is allowed to permit data flows to higher levels in partial order. This having been done, we must configure our routers; again, we do this by constructing the labeling tables. The _Cloud router_ will have the function of allowing application entities and sensors (right column) to send data to the storage entities. So, for example, data sent from sensor \(J\) that detects _SallyPulse_ will arrive at the _Cloud router_ through the _Access point_. The router will find the rows containing \(J\), which are the ones for storage entities _B_\({}^{\prime}\) and _G_\({}^{\prime}\), and forward the data to these entities. If the destination is not found in any row of the first router, the latter will send the data to the second router. Note, for example, that \(Label()=[\mathit{SallyPulse}]\) and \(Label(B)=Label(B^{\prime})=Lab(D)=[\mathit{SallyPulse},\mathit{Stat2}]\). So by label inclusion, each of \(\{\)_J_, \(B\), \(D\), _B_\({}^{\prime}\)\(\}\) can flow to _B_\({}^{\prime}\), as specified in the labeling table. These are all and only entities whose labels are included in the label of _B_\({}^{\prime}\), and so they are all and only entities whose data should be allowed to flow to _B_\({}^{\prime}\), as shown in Figure 10. The table in Figure 10 can be easily constructed from the partial order of Figure 8, using the same formula \(x\in\mathit{Holds}(y)\)_iff \(Label(x)\subseteq\mathit{Label}(y)\)_ that was introduced in Section 4.2. Once the data reaches the _App Router_ the same treatment is done: we check which row of the labeling table applies according to the provenance of the data, we send the data to each designated entity, and we drop the rest.