# Designing a Softwarized Network Deployed on a Fleet of Drones for Rural Zone Monitoring
## 3 Service Chains to Realize the Video Broadcasting Infrastructure Elements  
In the proposed platform, each video transmitter is the source of one multipoint video stream that can be transcoded to different qualities and/or stored according to the requests coming from the clients. Consequently, as already said so far, the platform topology can be considered as a forest, that is, a set of trees that have the edge streamer nodes as leaves. More specifically, since each flow can be transcoded at different encoding qualities in different backbone node drones (BNDs), it follows that each flow is transmitted through a forest that is constituted by as many VDTs (transcoded VDTs) as the number of encoding qualities requested for it. The roots of these subtrees are the platform nodes where the transcoders are located. So, given an original flow \(f\), the flow derived by it with a quality \(q\) will be identified as \([f,q]\), and the transcoded VDT carrying \([f,q]\) will be indicated as \(T_{[f,q]}\). Management policies of the VDTs are in charge of the NFVO block residing in the orchestrator. This is a challenging and very broad topic widely discussed in past and current literature [52; 53]. Although the whole management problem is out of the scope of this paper, the computational load model described in the following section is a fundamental piece of it. Let us now describe the service chains running in the BNDs to implement both the acquirers, that manage traffic coming from video transmitters towards the platform, and the edge streamers, that manage traffic coming from the platform towards the clients. The service chain related to the Acquirer is shown in Figure 5a. Traffic coming from VTs enters a load balancer (LB) block, which subdivides it to the computation units that are currently active in the BND. The number of active computation units and the video flows that have to be managed by each computation unit are decided by the orchestrator that applies consolidation policies in order to concentrate the load on the smallest number of computation units for energy-saving purposes. When a video flow enters a computation unit, it is first analyzed by a deep packet inspector (DPI) block that forwards it to an acquirer (A) block, which is the root of the relative VDT. Then, if the flow has to be transcoded, it enters the transcoding section, which is constituted by a transcoder (TC) block for each required quality level. If more than one TC is needed for the same flow, the flow is first replicated by a point-to-multipoint (PM) block. Finally, the video flow, either original or transcoded, enters another PM block to create as many copies of the flow as the number of edge streamers that are present on the considered VDT. If some clients have requested to store a flow, a copy of it is created by another PM block and sent to the storage (ST) block. This last block saves only one copy of each video flow if at least one recording request has arrived to the system, and even if more than one recording requests have been received by the orchestrator for the same flow. In order to limit the unavailability probability of the drone where the flow is saved, the ST makes a FEC encoding [54], splitting the flow in \(M\) different parts such that, if any \(F\) of them, with \(F\leq M\), are available, the flow can be rebuilt. The flow parts are then sent to \(M\) different storage drones or fixed storage servers to be saved. The numbers \(M\) and \(F\), and the IP addresses of the \(M\) different storage elements are provided to the ST block by the orchestrator. The service chain of the edge streamer nodes is represented in Figure 5b. In these nodes, flows arrive from acquirers through the backbone mesh network, specifically by the acquirers that have some children in the considered edge streamer node.