POWDER RDZ-in-RDZ: Nested RDZ

Having built POWDER-RDZ and enabled POWDER experiments to access spectrum through OpenZMS, a real zone management system with RDZ-based safety and coexistence properties, we created an initial example of our envisioned federated RDZ capabilities. We refer to this operational mode as RDZ-in-RDZ, and its extended architecture is shown in the figure below.

A nested, "inner" RDZ can serve as a real OpenZMS development environment than can sub-grant spectrum obtained from the root RDZ, but one where a POWDER user can change their "inner" RDZ deployment (e.g. replace OpenZMS components, employ different policies for analyzing and managing spectrum)---as well as a proving ground for future federated hierarchies of automatic spectrum management systems.

In this mode, POWDER-RDZ users may instantiate their own private RDZ---the "inner" RDZ---as a POWDER experiment that runs its own OpenZMS, whose spectrum is allocated by POWDER-RDZ---the "outer" RDZ. Users have full control of their "inner" RDZ, allowing them to replace components and test new workflows and algorithms---but they must provide the same safe coexistence guarantees as the outer RDZ. The user may then allocate spectrum for regular POWDER experiments via their inner RDZ instead of the outer RDZ. This functionality is specific to POWDER-RDZ, since it relies on the same experiment automation and radio infrastructure building blocks provided by the POWDER platform that were used to build POWDER-RDZ. However, it builds on the generic federated RDZ concept and uses the existing OpenZMS interfaces (spectrum provider, consumer, monitor) developed for standalone RDZ deployments---and therefore represent a prototype realization of hierarchical federation of two radio dynamic zones.

When an inner RDZ is created, it requests an allocation of spectrum just like any other POWDER-RDZ experiment would, but with the intent to further delegate this spectrum as grants to other POWDER experiments, using the Spectrum Provider interface (labeled "Spectrum Grant" in the figure). Thus, the inner RDZ receives a Grant of spectrum from the outer RDZ, and represents this as a Spectrum object (a delegation of spectrum with constraints) within its inner RDZ. The inner RDZ must provide safe coexistence for the experiments operating under its spectrum grants, so it requires similar monitoring data as the outer RDZ. To share resources efficiently, monitor data streaming into the outer RDZ is forwarded to the inner RDZ (again, using the existing Spectrum Monitor interfaces; labeled "Shared Monitor Observations" in the figure). The inner RDZ operator can also allocate their own inner SDR-based monitors, possibly running different monitoring software and data analysis pipelines.

To ensure that safe coexistence is guaranteed inside POWDER-RDZ, whether an experiment's spectrum is being managed by the inner or outer RDZ, the outer RDZ will terminate both grants and experiments allocated via the inner RDZ, if a transmission violation is detected via the monitors. This is a necessary feature for the virtualized aspect of POWDER-RDZ, although it is not part of the federated, hierarchical RDZ pattern. In a decentralized hierarchy of (sub)delegation of spectrum and policy, each level's zone management system would be responsible to operate safely within its delegated spectrum.