Distributed Architecture

As stated in our principal scenario, SALES adopts both a fixed wireless infrastructure and a mobile wireless infrastructure based on ad-hoc communications between nodes. Exploiting the physical locality principle, our solution groups nodes in physical proximity, and specifies the general architecture proposed earlier to obtain a final three-level tree-like hierarchical distributed architecture. The SALES fixed infrastructure introduces a limited hierarchy to enhance scalability and to manage context data according to different physical localities. Besides, the SALES mobile infrastructure introduces a hierarchy to reduce management overhead and to guide routing between different clusters by using specific cluster heads, i.e., coordinator nodes.

Consequently, SALES clearly distinguishes four node types:

  • Central Node (CN) – SALES root is a logical centralized entity that provides context data persistency. It acts as context data source in our system to provide context data unavailable on lower levels. It's hidden by lower levels, and it can be realized as a cluster to grant scalability.
  • Base Node (BN) – BNs are the SALES-enabled wireless infrastructure entry points. Each BN is connected to some APs and serves all lower coordinator nodes connected through them. It may act also as context data source, and facilitates context data dissemination by means of routing and caching facilities: in fact, according to locality principles, it caches context data to speed up subsequent accesses, and it builds a context-based routing infrastructure with other peers to guide context data request.
  • Coordinator User Node (CUN) – CUN is a group cluster head. Like a BN, it may act as context data source and sink, and includes routing and caching facilities. To handle device mobility, each CUN realizes management protocols to create and maintain an association with proper available BN, and proactively emits presence beacon to allow discovery from other devices. To further limit context wireless traffic towards upper levels, CUNs support multi-hop ad-hoc connectivity among nearby groups. Since each CUN manages both infrastructure and ad-hoc communications, it is typically a dual-homed device.
  • Simple User Node (SUN) – Each user node device that simply takes part in a group is a SUN. It acts as context data source and sink in our system, and it must be associated with an available CUN to access to the fixed infrastructure. SUN support is very lightweight and, consequently, it is specifically tailored to very resource-constrained devices.