Page 29 - U4SSC Data and API requirements for centralized smart city platforms

Figure 12: Data flow via the SCHub

In terms of data processing needs, the fact that SCHub does not store the transformed data means
that the transformation must be repeated each time a client requests the data from the data sources.
For this reason, the SCHub must be appropriately sized according to both the clients’ needs as well
as the available data sources in large deployments. If necessary, it could also be split to multiple
instances that each serve a specific data source and have a common entry point behind a reverse
proxy for instance. Is should be noted however that the sizing considerations are not bound by
the number of different data sources but rather the size of the available data and the request
throughput the SCHub will have to maintain.

4.3 SCHub in the interoperability initiatives landscape

The goals and vision of SCHub is aligned to other data interoperability initiatives, such as Gaia-X,
FIWARE and SAREF described in section 3. In the sections below, the positioning of SCHub in
relation to these initiatives is discussed.

4.3.1 SCHub and Recommendations ITU-T Y.4201 and ITU-T Y.4200

In the context of the reference framework for SCPs introduced by Recommendation ITU-T Y.4201,
and the requirements for the interoperability of smart city platforms standardized by ITU-T Y.4200,
the SCHub is focusing primarily on the following aspects:

1) Acquisition/interconnection functions for integrating information from the different sources of
data (8.2.a, ITU-T Y.4201, 2018).

2) Supply information to the data/knowledge functions independently from the devices, and
formatting the acquired data according to semantic processing (8.2.b, ITU-T Y.4201, 2018).
3) Acquisition/interconnection functions are independent of network information and control
(8.2.c, ITU-T Y.4201, 2018).

4) Interconnection between applications and platforms (8.4, ITU-T Y.4201, 2018).

19