## 6 Network Reconfigurations  
In the IoT, the network topology may be continuously transformed or reconfigured with the creation or removal of entities and communications channels. This can occur for many reasons, notably by the intervention of system administrators or by the effect of policies. For example, in some systems, some reconfigurations are determined by policies expressed in terms of time, such as that at certain times, certain entities may change their permissions (i.e., labels) or disappear altogether, while others may be created. The  
Figure 10: Labeling table for Figure 6.  
routing tables must be updated at each such event, but the implementation configuration will remain the one in Figure 1 or Figure 9. It is a useful property of the partial order model that a partial order exists for any network, and so our method can be used to construct new routing tables after each network reconfiguration (note that, on the contrary, if a lattice-structured network is reconfigured, the result may not be lattice-structured). Reconfigurations may affect only some routing tables. In our partial order model, the reconfigurations that matter are the changes in the domination relation, because these are the only ones that can change the data flows. Reconfigurations that do not change this relation are adding or removing channels that are implied by transitivity. Consequently, we consider three types of reconfigurations: introduction or removal of entities, or label changes. The label of an entity can be specified in one of two ways:  
* Explicitly: in this case, the label indicates the intended contents of the entity and, by inference, its _Channel_ and _CF_ relations
* Implicitly, in this case, the _Channel_ or _CF_ relations of the entity are given, along with, by inference, its intended contents and label. For implementation efficiency, it should be considered that different networks will have different update needs. For example, some networks may have very frequent label changes but much less frequent additions or removals. In this case, the algorithms and data structures will have to be optimized for quick label changes, and it may not matter if they perform less well for the other operations. Adding backward links in the labeling tables will help speed up certain searches but will also increase the amount of memory required for the tables. Further, the labeling tables may have to be kept sorted according to some criteria to speed up searches. Such decisions should be left to the designers of specific systems. Standard data structure theory proposes methods that can be used for optimizing the reconfiguration methods, and we leave this to further research. * _Addition of new entities_: Three types of entities can be introduced: sensors, storage entities, and application entities. In each case, we assume that the new entity comes with a label, see above. * Adding a sensor: The sensor's labels contain only the names of the sensors themselves, along with the names of other equivalent sensors, if any. In the implementation configuration, the new sensor must be attached to the appropriate access point. In the labeling tables, a line must be added for the new entity, containing in the _Holds_ column the name of the equivalent sensors. Further, the name of the new sensor must be added to the _Holds_ lists of all entities that should receive data from it. * Adding a storage entity: If it is decided to add a new storage entity to the cloud layer, the change to the implementation configuration is the appearance of this entity attached to the _cloud router_. Concerning the labeling table, this new entity will have to belong to one of the already existing equivalence classes. This one already must have at least one storage entity (otherwise it will be disconnected from the other entities). Then the new entity must be added to the labeling table with the same _Holds_ list as the other entities in its equivalence class; it must also be included in the _Holds_ lists of all the entities in its equivalence class.