Design of the HyperSurface Networking Aspects

HYPERSURFACES (HSFs) comprise structurally reconflgurable metasurfaces whose electromagnetic properties can be changed via a software interface, using an embedded miniaturized network of controllers, enabling novel capabilities in wireless communications, including 5G applications. The resource constraints associated with the hardware testbed of this breakthrough technology, necessitate an interconnected architecture of a Network of Controllers (HSF-CN) that is distinct from, vet. reminiscent to, conventional architectures (e.g., Network-on-Chip (NoC) architectures).

To meet the requirements of the HSF hardware, the network is constructed via an irregular topology where network controllers are interconnected in a Manhattan-like geometry, with communication between controllers conducted using handshaking protocols [85,127]. Routing within the network is operated by an XY-YX algorithm [34].

This chapter presents the HSF-CN selected topology, and the adopted communication protocols, including fault management protocols. The design is evaluated using complementary techniques. The chapter also introduces the design and implementation specifics of the HyperSurface Gateway (GW). The GW design and implementation includes the selected hardware and software technologies, as well as the protocols for sequencing routing packets toward the HSF-CN and fault management protocols.

DESIGN REQUIREMENTS OF THE HYPERSURFACE CON TROLLER NETWORK

The HSF configuration layer constitutes a set of interconnected controllers that are responsible to configure the meta-material atoms. The controller interconnection forms the HyperSurface Controller Network (HSF-CN) that must be characterized by scalability and robustness [85].

Scalability is dictated by the large number of meta-atoms that will be accommodated in practice: small meta-atom size is required for correct meta-material operation; and the need to avoid EM interference. In particular, the size of the meta-atonr should be comparable to the incident wave wavelength Л (in the order of Л/2), while the metasurface thickness should be much smaller than the wavelength (in the order of Л/10). Scalability implies a simple controller design while the cost of each tile must be kept at a minimum. The potentially large surfaces to be covered, such as building walls, also necessitate designs of low power consumption.

Robustness is also required for the HSF-CN, i.e., the HSF-CN must be able to tolerate faulty controllers, especially in large scale HSFs that accommodate thousands of controllers. The CN architecture must offer reliable data delivery even in the presence of faults, foreseen due

Figure 5.1 Controller Node Communication Channels and Pin Allocation [85].

to imminent component failure(s), external influences such as acciden- tal/intentional damage, and loss of connectivity.

HYPERSURFACE NETWORKING COMPONENTS: THE HYPER SURFACE NETWORK CONTROLLER

The design of the HSF-CN is structured upon the design of the HSF-CN Controller. The HSF-CN controller is able to receive and handle software directives in the form of multiple network packets that contain configuration values. Moreover, the controller is able to use the configuration values and configure the meta-atoms under its responsibility. To accommodate the functionality of configuration packet handling in a robust manner, the HSF-CN controller implements three basic operations: configuration packet processing/consuming; configuration packet routing; and acknowledge the receipt of a configuration packet.

5.2.1 HyperSurface Controller Communication

Each controller needs 22 pins for the purposes of intra-tile communication, operations, and for meta-material configuration. The communication channel allocation of the controller is given in Fig. 5.1. The left diagram of the figure shows the available number of pins on the controller chip. The middle diagram shows the channel endpoint allocation for the controller. Each controller allocates two input channel endpoints and two output channel endpoints. The right diagram also shows the pin allocation for the four channel endpoints on the controller. At the hardware level [127,128], each channel endpoint requires three signals for implementing asynchronous communication (Section 5.6.1.2). Figure 5.1 also shows the spatial distribution of the channel endpoints; on a clockwise direction there are two input endpoints followed by the two output endpoints.

Figure 5.2 Left: Manhattan Topology with bidirectional channel at the edges; Right: Controller Orientations.

THE HYPERSURFACE CONTROLLER NETWORK TOPOLOGY

Based on the controller design and channel allocation, the proposed topology for the HSF-CN is the Manhattan-like network topology with bidirectional channels at the edges as presented in Fig. 5.2 (left). To spatially achieve the connectivity (input/output endpoint connection) of a Manhattan topology the controller is rotated, with all four 90-degree rotations used to form the topology. Figure 5.2 shows the four spatial directions of the controller. The controller orientations are referred to with letters a, b, e, and d as shown in Fig. 5.2 (right).

The Manhattan topology is a grid structure network topology [116]. Due to the limited number of channel endpoints and the requirement for a grid structure layout of the controllers, the proposed topology has unidirectional communication both row-wise and column-wise, with alternating communication direction flow’ both row-wise and columnwise. What distinguishes the proposed Manhattan topology, how’ever, from the one considered in the literature is the wraparounds: instead of connecting the opposite ends of a row/column, wraparounds connect neighbouring nodes on rows/columns where no connectivity is present. Our design choice of connecting neighbouring periphery controllers and not the ends of each row’ and each column is due to the hardware implementation: crossing the interconnection wires would require to add extra layers on the Printed Circuit Board (PCB) board that embeds the metasurface. Furthermore, the edge controllers would require components, e.g., transistors, with more signal drive to send signals over longer wires.

The adopted wraparound design, allows for connecting the Hyper- Surface Gateway by replacing a wraparound with a gateway device. The gateway device is responsible to connect the user and the HSF-CN, by processing and issuing software defined directives. As shown in Fig. 5.2 (left), for the purposes of the current HSF-CN design two gateways are connected to the Manhattan-like grid: one Gateway is to replace the wraparound between controllers (0,0) and (0,1). The output channel endpoint of the Gateway will be connected with the input channel endpoint of controller (0,0) and the input channel endpoint of the Gateway will be connected to the output channel endpoint of controller (0,1). This will allow for the Gateway controller to send packets directl}' to controller (0,0) and receive report packets from controller (0,1). A second gateway, that acts as a gateway for receiving acknowledgments, replaces the bottom right wraparound of the HSF-CN.

For the requirement of tiling, the topology is also chosen to contain an even number of controllers at the side of the grid. If an odd number of controllers is chosen, then it would not be possible to perform tiling and maintain the alternating sequence of the rows and columns of the multi-tile Manhattan topology in the larger formed topology.

5.3.1 HyperSurface Network Controller Addressing

Each controller in the HSF controller network needs to be uniquely identifiable via an addressing scheme. The addressing scheme used for the HSF controller network follows the Cartesian coordinates within the Manhattan-like grid as shown in the left diagram on Fig. 5.2 (left). The bottom left controller has (0, 0) as its ^-coordinates. The ж-axis increases from left to right and the у-axis increases from bottom to top.

5.3.2 HyperSurface Network Controller Channel Mapping

Output directions at the controller level are used to uniformly present the protocols within the Manhattan topology. This is done by mapping directions “up”, “down”, “left”, and “right” with the output endpoints of each controller. The mapping is done based on the orientation, i.e., type, of the controller within the topology. The type of each controller is determined by its Cartesian address. Specifically, due to the alternate direction characteristic of the Manhattan topology, the type of the controller is determined by the ж-coordinate, and respectively y- coordinate, modulo 2. Figure 5.3 show's a locally based routing scheme for a controller of type “a”.

Figure 5.3 Local Routing Directions.

Table 5.1 Mapping of Controller Outputs to Directions.

Specifically, the type “a” controller in the figure maps the routing directions “up”, “down”, “left”, and “right” to its two output channel endpoints. Direction “up” denotes sending to a higher y-coordinate, and direction “down” denotes sending to a lower у-coordinate. Similarly, direction “right” denotes sending to a higher ж-coordinate and direction “left” denotes sending to a lower ж-coordinate. In the case of a type “a” controller direction “up” is mapped to output endpoint 1 and direction “right” is mapped to output endpoint 2. This mapping allows for a direct routing according to the specification of the “up” and “right” directions. Moreover, direction “left” is mapped to output endpoint 1 (just as direction “up”) and direction “down” is mapped to output endpoint 2 (just as direction “right”). This is because routing in these cases cannot happen directly, rather it happens indirectly; type “a” controller indirectly routes a packet towards the “left” direction by first directing the packet to the “up” direction. Similarly, a type “a” controller indirectly routes a packet towards the “down” direction by routing the packet first towards the “right” direction. Table 5.1 shows the direct and indirect local level routing directions for all types of controllers.