Page 83 - ITU Journal, Future and evolving technologies - Volume 1 (2020), Issue 1, Inaugural issue

ITU Journal on Future and Evolving Technologies, Volume 1 (2020), Issue 1

back is executed. In general, an API callback can refer corresponding protocol. This notifies the intra-tile con-
to a number of common requests such as: trol network to assign the switch element states to their
suitable values. Finally, feedback from a successful or
ˆ Detect the number and type of accessible tiles in
failed configuration setup is received from the tile, noti-
the environment.
fying the user. The state of the newly set configuration
ˆ Get the current state of all switch elements or set is evaluated through either the identification of failed or
them to a specific configuration. unresponsive switches, or by activating the sensing app,
in controlled conditions, as a self-diagnosing tool for the
ˆ Check the health status and handle interrupts from tile.
the tiles or the Database. A more advanced API callback may involve the assign-

Prior to any other callback, the API follows an initi- ment of a secondary or supplementary functionality, on
ation process, while the software detects all presently top of an already existing operation. For instance, the
Metamaterial Middleware may receive independent re-
active and connected (discoverable) tiles by broadcast-
quests from different users to steer the wavefront of sev-
ing a corresponding network message. The tiles report
eral point power sources (i.e. the users’ cellphones) to-
their location and a unique identifier, e.g. a fixed value,
wards the direction of a single nearby network hotspot.
that associates all tiles with the same hardware speci-
This can be handled by the API in many ways. In the
fications. The API validates the support of the active
case where several tiles are present in the environment,
tiles by checking if the identifier exists in the tile list
each tile can be repurposed to host a separate func-
present in the database. It, then, retrieves the switch
tionality, distributing all users to their own active tiles.
element arrays that correspond to these tiles and re-
When this is not feasible, the API can divide a single
mains idle until a new “get” or “set” request is received
tile into separate areas and associate the respective el-
for a currently active or new configuration, respectively.
ement switches to different configurations (the division
This means that the API is now open to receive new
is usually performed in equal-sized rectangular patterns,
functionality requests from a user, physically operating
but interlacing can, also, be used). Lastly, two function-
the software, or generate its own requests by reacting to
alities can be combined into a single one, when a cor-
unexpected changes in the environment of devices linked
responding physical interpretation exists. For example,
to the MS network. When a new functionality request is
received, the API retrieves one of the available configu- two separate steering operations, from the same source,
rations from the Database and translates it to a proper may be combined into a single dual-splitting operation,
set of element states on an active metamaterial tile. The expressed by a single unified pattern on the metamate-
corresponding API callback process is illustrated in Fig. rial.
8. In particular, the Caller (user) executes a metama- In other cases, the configuration resolver may need to
terial Function Deployment request, which, in turn, in- combine several functionalities to produce a special new
vokes the Configuration Resolver, identifying a tile that application. This occurs when a functionality is pa-
supports the requested functionality. Next, the resolver rameterized by a continuous variable (e.g. a steering
queries the Database and returns a configuration that angle), while the Metamaterial Middleware can eval-
uate and store only a finite number of entries in the
matches the intended metamaterial application, looking
database. In such a scenario, the resolver seeks the two
for a proper entry in the ¡Configuration¿ table. The API
closest matching entries through an appropriate mini-
creates a string command, using the tile identifier and a
mization function (e.g. for a beam-steering operation,
hardware representation of the element state variables,
the minimum distance between the requested and cur-
which is, then, conveyed to the tile Gateway using the
rently stored steering angles), whereas performing an
user
interpolation of the switch state values.
Configuration To ensure a seamless operation, the API is reinforced
Resolver
with a set of specialised algorithms to handle unex-
pected failures in the hardware or communication net-
(?) TID supporting FID NxM work. So, a tile must include all necessary identification
matrix
capabilities (e.g. the ability to identify power loss in its
switch elements), and be able to notify the Metamaterial
Hypersurface
Gateway NxM Middleware in case of failure. The API is, then, respon-
states
sible for handling these errors by ensuring no loss of the
Callback
consumes current functionality [32]. For illustration, if a group of
switch elements is stuck to an unresponsive state, the
Fig. 8 – A metamaterial Function Deployment request initiates an Metamaterial Middleware may instantly seek the clos-
API callback on the tile (TID). The Configuration Resolver seeks
an appropriate configuration that supports the selected function- est matching functionality with a fixed configuration for
ality (FID). The matrix of states is conveyed to the HyperSurface the faulty elements. In more severe cases of demanding
Gateway, where it is translated to a set of corresponding hardware human intervention, like an unresponsive network (af-
states. ter a certain timeout), the API is also responsible for
© International Telecommunication Union, 2020 63