CovaDel: a blockchain-enabled secure and QoS-aware drone delivery framework for COVID-like pandemics

With increase in the use of contactless deliveries during the times such as COVID-19 pandemic, the emphasis was to minimize the human presence to reduce the spread of virus. In this regard, drones are one promising alternative to be used as delivery agents. However, security and Quality of Service (QoS) are major concerns while making use of drones for deliveries. In order to secure the drone communication system, we propose, CovaDel: a blockchain-based scheme to secure data transactions for the drone delivery use case that works in a phased manner. The proposed scheme make use of decoupled blockchain architecture to overcome the limited resources capabilities of drones to perform blockchain-based computations. Further, to ensure the QoS adherence, we also propose a QoS-aware communication approach that handles collisions and congestion on the basis of firefly algorithm’s attractiveness parameter (light intensity) received by the drones. Results obtained using a simulated environment verify the efficacy of the proposed scheme on the basis of gas consumed, transaction time, average network throughput, and delay.


Introduction
The transportation sector has helped the common life during the pandemic as it brought essential services and goods to the people. With the widespread emphasis of contactless deliveries of goods to the consumers, drones have become one potential solution for providing essential goods and services to the people. Many successful drone-based delivery services and systems are already in work such as, F-Drones, 7-Eleven, Swoop Aero [1], Zipline [2], Matternet, USPS HorseFly to name a few [3]. Drones offer many benefits to act as the promising delivery agents in COVID-like or disaster-hit scenarios, where the reach of humans is limited. These include their optimized designs, good coverage of area, low maintenance cost, and automated control with very less human involvement. In a typical drone delivery use-case, many entities are involved such as buyers, sellers, service providers, drones and their logistic planning. When all these different entities communicate with one another, it is essential to ensure prompt and secure information to the participating entities and deliver products at the right place in order to gain their trust through smooth operations and transactions. However, many security concerns (like, confidentiality, data manipulation, and authentication) and susceptibility of drones to cyber-attacks hinder their widespread rollout for delivering goods and general trust over their use [1]. Therefore, there is an urgent requirement of a streamlined system which can alleviate the security concerns and provide a secure mode of communication and trust between various involved entities.
In this regard, different researchers have tried to address these security concerns (like, confidentiality, data manipulation, event chronology, and authentication) inpart for different scenarios involving drones. For example, [4] proposed a framework to secure the Internet of Drone (IoD) ecosystem by protecting the drones by using multilevel and multi domain strategies. However, this often involves the use of heavy cryptographic computations which should be avoided in drone-based environment to save resources as well as provide speedy operations [5]. Although many research works have focused on the drones-based delivery services, there is still a major research gap concerning security in such systems for critical scenarios. One of the ways to address the security concerns is to use the blockchain technique which is based on a distributed ledger technology. The premise behind the use of blockchain is that the blocks in the blockchain are indestructible. It enables addition of data in the form of transactions and periodically update the transactions from various participating entities into blocks [6]. Overall, a block can be defined as the container of information in the form of chronological transitions thereby handling the issues like confidentiality and event chronology. In blockchain, every block has a header part and a trailer part. The header constitutes necessary control and administrative information required for ensuring consistency and verifiability of recorded transactions [7]. The trailer has actual transactions in it. To weave the blocks together, hashing operation is carried out to compute a fixed length output for any given input. The advantage of hashing is that for the same input, the output will be same, and even a minimal change in the input leads to a different output to a large extent.
Even though blockchain is an effective solution to deal with the security related issues, the computations involved in blockchain-based solutions can be computationally expensive for the (computation limited) drones. Blockchain has been found as a suitable solution for the drone delivery or other drone operations as pointed by many studies [8,9], but very little exploration has been done for the adaptability of blockchain in the context of disaster or pandemic like situations. One of the key reasons for this little exploration is related to the resource constraints associated with the drones. If the complete blockchain including data (trailer) and header is stored on drone, the storage requirements of drones become very high over whelming the drone resources. The structure of conventional blockchain is appropriate for all entities, however, it has certain limitations when adopted in the drones scenario. Motivated from the work in [10], a derivative of blockchain can be used in the drone delivery scenario. In the derived blockchain, the data and header parts can be decoupled from the blockchain to keep the storage requirement on drones to the minimum. The blockchain will contain only the header part of different blocks. Moreover, each drone can have its own block which is appendable in nature. This way every time new data is added to the block of the drone or existing is updated the resulting hash of the block data changes. The hash of the data of drones is embedded into the blockchain of headers. A complete blockchain and derived blockchain can be maintained with the service provider (or drone station) including blocks for all drones but the drones store only their own block. Therefore, in our proposed approach -named as CovaDel, we make use of decoupled blockchain architecture to reduce the computational burden on drones.
When we have large number of resources, optimal utilization becomes essential to have the desired output of the system. So, if a drone-based delivery system is to be scaled commercially it must be designed keeping the optimal resource allocation and utilization in mind. Hence, to use drones for the purpose of delivery a optimized drone scheduler is needed [11,12]. Specifically, in the case of drones, there are several attributes (status of physical resources, energy levels, and operational capabilities of hardware resources, etc) that must be taken into account before scheduling it for a mission or delivery. For example, if a drone is scheduled for delivery and during its flight any significant incident or delay occurs, then it may have to be divert its route or delivery plans. In such a case, it must have significant resources (like energy level) to sustain its flight considering the diversion or delay. If this is not considered by the scheduler then it may end up in delivery failure or any other untoward accident. Thus, effective scheduling mechanisms work as an enabler for ensuring that the quality of service (QoS) and quality of experience (QoE) parameters are met to make the system adaptable and worthy of deployment. In CovaDel, the scheduler considers all the above highlighted constraints before selecting a drone for delivery. To aid this process, a drone indexing approach is adopted that categorizes and index the drones based on its computational capabilities and physical resource status.
Moreover, the foundation of drone-based system relies primarily on the prompt communication between the involved entities and in this regard, some of the related communication concerns like, network congestion and collisions can have damaging impact on the overall QoS and QoE at the large. The density of the drones in a given area have big impact on the fluctuations of the bandwidth availability. This also impacts the on board resource utilization attributed to handling the network congestion [13]. Further, as the drones use wireless networks that uses shared channels with other coexisting networks like terrestrial and cellular networks resulting into interference, hence leading to collision of data packets. The corrupted data needs to be re-transmitted which is not always feasible due to the real time nature of the environment in which drones operate. Thus, because of this the drone delivery mechanisms should be robust enough to deal with the communication-based issues such as collisions and network congestion. In order to address this, CovaDel proposes a QoS-aware communication amongst the drones on the basis of firefly algorithm's attractiveness parameter. Firefly algorithm is an effective optimization technique that can be applied to swarms of drones [14]. The key parameters for the firefly are attractiveness, randomization and absorption that is influenced from tropical firefly behaviour.

Research approach and contributions
CovaDel is focused on the delivery of essential goods (or medicines) using drones in pandemic or disaster-like scenarios when the physical moment is restricted (or limited). This article is the extension of our previous work [15] where we have provided the preliminary results and information on the use of blockchain for COVID-like scenarios. The overview of the research approach adopted is presented in the form of a schematic diagram depicted in Fig. 1.
In CovaDel, the block structure used for drone-to-drone, drone-to-ground station communication, and data storage differs from the traditional blockchain approach (Sect. 4). The approach workflow is based on different phases responsible for the functioning of CovaDel. For each phase, a self executing code, i.e., smart contracts, is designed for the interaction between the user and the buyer for placing an order (details given in Sect. 5.1). Furthermore, smart contracts are designed for ensuring the delivery of the items and payment processing between the involved entities (Sects. 5.2 and 5.3) respectively. Drones have different attributes in terms of their flight capabilities, so selecting the right drone for the right delivery is an essential job at hand which is achieved through a multi-queue drone indexing phase (Sect. 5.4). The scheduling of drones is discussed in Sect. 5.5. A good experience is the key for the popularity of any system among masses, hence a QoE enabling mechanism which is possible by ensuring the QoS for the drone communication becomes essential. Thus, a QoS-aware communication approach that handles collisions and congestion situation effectively is proposed in Sect. 6. Some of the significant contributions in this work are listed below.
-A systematic architecture for drone delivery use case has been presented wherein blockchain has been used for secure data transactions. A decoupled blockchain has been used to overcome the challenge of limited resources capabilities of drones concerning the heavy computational perspective of blockchain process. -An end-to-end drone delivery mechanism using blockchain and multi-level queuing is designed considering different categories of drones based on their capabilities (such as weight, speed, fitness, battery, etc.). -A QoS-aware communication approach that handles collisions and congestion is proposed on the basis of light intensity received by the drones.

Related work
The existing literature in this field is presented in this section driven in two research directions focusing on (1) research aspects, and (2) drone delivery use cases.

Research aspects in existing works
In [16], the authors evaluated a drone delivery case study related to healthcare field. The authors have studied various drone service providers, load capacities of various drones, and their suitability to the drone-based delivery services. Work by the authors in [17] includes the study of the environmental impact of using drone-based delivery services in comparison to motorcycle-based delivery of goods. The study clearly indicated the drone-based delivery holds superior to other means of goods delivery in terms of environmental impact. In [18], the authors have undertaken the study to provide an optimised delivery route planning using mobile ground station for the drones. The trajectory of the ground station is computed in a way that the ground station movement is minimum and the drones are capable of optimize their operations to maximize their coverage area. Kim et al. [19] suggested the use of mixed integer linear programming (MILP) model for planning drone activity to increase the count of drone-based parcel delivery that would take place on building rooftops. However, the major drawback of all these studies is that none of these works considered the security and privacy in drones.
In [20], the authors concluded that the any type of attack in drones can be fatal as it can stop its rotors mid air. Another similar work by authors in [21] on generic drone framework was presented along with its security assessment and resilience for security attacks like battery depletion, eavesdropping, jamming, replay and fabrication. In [22], the authors have presented a complete study of security aspects of IoT and related areas along with security mechanism to deal with the security concerns. All of these studies emphasize on the consideration of security flaws in drones, however, none of the above proposals considered a scenario related to product delivery or emergency delivery using drones. Since the delivery of commercial or non-commercial goods involve personal data or sensitive information related to the customers, it becomes essential to secure these transactions and maintain the integrity of the data. In view of these facts, the researchers in [1] have presented a framework for drone-based delivery of goods. The authors made use of cryptography to ensure confidentiality, authentication and non-repudiation. However, it seems that blockchain is better suited technology that can handle the various challenges concerning drone delivery. On one hand, blockchain can handle the transactions in drone delivery in a secure and tamper proof manner, while, on the other hand, we can utilize the smart contracts to verify and validate the authenticity of the transactions and flag out any potential violations.
Keeping in view of these facts, the authors in [23] presented blockchain, as a distributed ledger, which uses cryptographic methods to secure the shared data. It can also be used to ensure the accuracy of the data stored, as well as to improve the reliability and accountability of unmanned areal vehicles (UAVs). In another work [8], a framework for drone-based delivery empowered by blockchain was proposed to ensure system security. The proposed models uses practical Byzantine fault tolerance consensus mechanism for ensuring the consistence of the blockchain. The system was analysed against various security attacks. Another mechanism for validating the vendor packages was also presented in this work. In [9], the authors described the use of a blockchain and drone combination for delivery in countering COVID-19 to track, identify, handle, and regulate public health emergencies.

Drone delivery -industrial/commercial use cases
Drone delivery is a massive technology which has proven itself to be an essential part of futuristic transportation systems. Drones helps to redefine the conventional logistic industry, which results in saving of crucial operational time, resources and the cost. This section provides information about the various drone delivery applications categorized into three domains discussed below.
-Essentials and medicine Contactless deliveries are booming during the pandemic time and drones are playing an important role in connecting consumer and the service providers by catering to such demands. Drones have become the first choice for delivering the essential goods such as medicine [24], first aid and sensitization during the lockdown time as well as in disaster-hit areas [25]. Drones even help to deliver the transplanted organs in time bound manner which can save one's life [26]. e-commerce The delivery of parcels and goods with the help drone is popular these days. The logistics companies such as DHL [27], Anavia [28] and Amazon [29], utilizes the drones for automated delivery of their products to the consumers. Some use-cases such as [30] exploits the use of drones in the marine deliveries of goods and containers to-and-from vessel to consumers locations and offshore. It is believed that this process helps to reduce the carbon footprints. This is derived due the huge demand of faster, cheaper and ideally green forms of deliveries. -Grocery and food delivery 7 Eleven utilizes the drones for the delivery of grocery items to the customers [31]. To avail shop-to-home delivery, the customers register themselves on the site by providing the their home GPS coordinates for accurate delivery. Dominos, the famous pizza company, also focus on the use of drones to deliver hot pizzas in time bound delivery to its customers [32]. Moreover, a tacocopter (renamed from drone) to deliver tacos in San Fanscisco is designed by star simpson [33]. Table 1 show different drone delivery scenarios adopted by various organizations.

System model
In this section, the various components of the drone delivery system are discussed. In the system model, blockchain is used to ensure a secure communication environment and smart contracts ensure the trust of various entities (buyer, seller, drone, service provider, etc.). Any change in the system state during the drone delivery process is referenced as a transaction on the blockchain. Figure 2 presents the system model for the drone delivery scenario, various components of which are discussed as follows.

Seller
In the proposed model, the products are sold by an entity called seller (S). It provides the details and cost of the products to a cloud-based service provider (CS) for product listing on the online platform. S continuously updates the product information to CS with respect to its availability in the warehouse (W).

Buyer
A buyer (B) can use the CS platform to buy any product listed there. B can browse products and finally place the order on the CS platform. However, before the buyer can actually place the order, a smart contract should be prepared by S which must be accepted by B to avoid any future conflicts. Once the contract is executed, an invoice (IV O k ) is generated for the kth order (O k ) placed by jth buyer (B j ) with ith seller (S i ).

Cloud-based service provider
CS offers an online merchandise service wherein it lists the products sold by (S). It is responsible for online product listing and the management of the order received from B in the proposed architecture. It provides middleware services to the B and S in a systematic manner. The key roles of CS are enlisted below:

Warehouse
S i stores its products at W and continuously updates the availability status of the product to the CS. When IV O k is generated by S i for O k , the process to prepare the product for shipping (delivery) is initiated at W.

Drone station
The drones are responsible for the product delivery from W to the address provided by B. The drones are located in the facility called drone station (DS). The flight of i th drone (D i ) begins from DS leading towards the shipment pickup from the W and then delivering it to B j on the address provided in SH O k . After successful shipping of the product(s), D i moves back to DS. At DS, the drones might be categorised into following categories based on their properties and states.
-Unfit drones(D U i ) When D i returns from a delivery, the status of the physical resources is monitored by the DS. This status includes battery levels, operations of hardware components, or other physical resources. If the battery status (BT i ) of D i is below a threshold required for the shortest possible flight in the future, then D i has to charge its battery to be eligible to join the fit list.
-Fit drones (D F i ) D i that has all its operational resources in functional order and BT i above a threshold value (BT T H ), then it is considered to be fit. Algorithm 2 is then used to select a drone for delivery from the fit list.

Blockchain architecture
In proposed technique similar to [15], blockchain is used by the participating entities for the storage of the information. To ensure the participation of trusted entities only, private blockchain is used. In the private blockchain, only permitted participants can join in the network. Moreover the allowed participants are only allowed to perform the authorized operations. The structural component of BC where the data is actually stored is known as block [34]. Each block is composed of two parts known as header and trailer. The header has the data management and link information, whereas the trailer stores the data.

Header part
This part has all the information related to the control and management of the blocks. More details on the components of header are as below: -Sequence number The blocks are created as the time passes by. This means that the block (BL i ) is created after BL i−1 and before BL i+1 . The block gets stored in chronological order of their creation with the help of control information field known as sequence number (SQ i ). -Timestamp Blockchain has a problem, known as forking, where the consistent state of blockchain with different entities is different because the main fork is split into different forks. To identify the occurrence of the events, a timestamp (TS i ) of block generation is embedded inside the header. -Previous block hash The biggest advantage that blockchain brings in is the distributed data storage along with the property that transactions once committed are immutable. This is achieved through embedding the hash of the previous block into the new block being made, i.e., in ith block, the hash of the i − 1th block is stored as previous block hash (H BL i−1 ). -Current block hash Based on the difficulty level, the computed current block hash has certain number of leading bits as zero in the target hash value. -Nonce The hash of the current block can only be achieved if we set a value inside the header that forces the output hash to be of specific nature. It is achieved using pseudo random numbers called nonce (N).

Trailer part
The area where the data is stored inside the block is known as trailer part. The trailer in the proposed blockchain model comprises the following: -Smart contract When B places an order, it is converted into SC which is signed by S and B as an agreement. -Shipping If the shipping information is manipulated by an attacker, the product may be delivered to the wrong address. Hence, to keep the shipping information immutable, it is stored on the blockchain.
The structure of BC is appropriate for all entities except the drone due to its resource limitations. If the complete blockchain is stored on a drone, it may lead to the over whelming of drone resources. Thus, a decoupled blockchain (BC D ) is used for drones and GS communications. The data and header parts are decoupled from the blockchain to keep the storage requirement on drones to the minimum. The BC D comprises only the header part of different blocks. Moreover, each drone has its own block which is appendable in nature. This way every time new data is added to the block of the drone, the resulting hash of the data block changes. The hash of the data of drones is embedded into the blockchain of headers, i.e., BC D . The blockchains are maintained with the CS, while the drones store only their own block excluding the data of other drones within the BC D . The block structure used in BC D for drone-to-drone and drone-to-ground station communication, and data storage differs from the BC in the following aspects: -Header In the decoupled blockchain, the header contains the control information for D i . This includes the hash of previous block, drone attributes such as payload capacity (D max pld ), ratted battery capacity (D rtd bat ), hash of drones registration identity (H D id ), timestamp of block header creation (T hdr ), drones public key (D -Data The data is not stored on the blockchain and only the MRH of the data is stored inside the header to ensure integrity. However, the DS and CS maintain the complete copy of data and header for drone interactions, while the drones store the current mission-related data (D cur i(d) ) only. The proposed framework for drone-based delivery scenario consists of several phases that work in tandem to achieve the overall objective. These phases are discussed in the following sections.

Initial agreement and smart contract creation phase
The first phase deals with establishing an agreement between the B and S. This agreement is translated in to a smart contract that is deployed on the blockchain. The actions performed in this phase are depicted in Fig. 3.
• S i sends an enquiry (ENQ S i I j ) to W for the available quantity of the item (I j ). • When W receives ENQ S i I j , it authenticates S i from the list of registered sellers (S reg ) and the following condition should be true.
• CS send the SC k to S i for preparation of invoice(IV O k ). Finally, the IV O k is sent to the B j through CS.

Delivery phase
The second phase deals with the delivery of the product from W to the buyers address. The actions of the involved entities are as shown in Fig. 4.
-CS adds SC k into the BC. Initially, SC k is added to the pool of un-mined transactions (T nm x ) in the form of T SC k .
-B and S act as miners on the BC. The transaction between B j and S i , i.e., T SC k is verified and further sent for mining into the block of BC. If either of the involved entities can't verify T SC k , it is denied and aborted. The SC k is executed by BC D and the status is notified to S i .

Payment phase
The third phase is related to the payment to the S i from the B j 's reserve. The SC is auto executed once the order is delivered to B j and the corresponding amount is transferred to the S i 's cash wallet. The interaction between various entities is shown in Fig. 5. -B j agrees to the SC made by the CS by signing it, i.e., SC k and the same is forwarded to the BC through CS. -On receiving SC k , the BC reserves the amount of virtual cash (VC B j ) corresponding to the SC k from the available virtual cash (VC B j ) of B j . -The updated VC B j is returned to B j to eliminate the double spending problem, as B j is not able to spend the reserved amount until O k either succeeds. -Once I j is delivered by D i to B j , it initiates the order completion flag (O cmp k ).
-On receiving O cmp k , the SC k is triggered on the BC that adds VC SC k to the Virtual cash(VC S i ) of S i . -The updated VC S i is returned to the S i leading to the completion of payment.

Multi-queue drone indexing phase
Initially, the drones are categorized into fit and Un-fit drone queue based on their current battery status. Further, the available drones are segregated into the heavy range queue (Q H R ), moderate range queue (Q M R ), and low range queue (Q L R ) using the proposed multi-queue drone indexing algorithm (Algorithm 1). In the algorithm, τ max , and τ mod are variable and can be fixed based on the drone technology. Similarly, R max , and R mod are also variable and can be fixed based on a specific drone model. The proposed approach helps to select a suitable drone for the delivery. The queue manager supervise all the queues and update the status of all the loaded and unloaded drones in the defined queues. Further, the algorithmic complexity is tight upper bound defined as θ(n).

Drone scheduling phase
GS is assigned with the task of optimal selection of drones for shipping the product (O k ) to the delivery address. The CS provides the list of the requested products S O k to the GS for further processing. ) and delivery timing (O dt k ) and TP are the total number of products to ship at various locations. • The approach return the mapped D i → O k to the W, which further hands over the O k to the D i for delivery to the assigned location.
The distance of the destination B j from the warehouse W is computed using the following equation as suggested in [34]: The algorithmic complexity of this algorithm is calculated as O(T P + N ).

18: RETURN ← D i 6 QoS-aware communication approach
CovaDel is strictly dependent on timely data/information from the participating entities. At a given time, multiple drones may be out for delivery (or other missions) so they can communicate among themselves and to the GS to pass the vital information (like, drone density or critical incident in the region) that can aid the drone-based delivery process. The density of the drones flying in a given region can lead towards the bandwidth fluctuations thereby limiting availability of the communication resources. This can further end up in network collisions and thereby network congestion. Now, the collisions and congestion in the network can eventually effect the QoS metrics and therefore degrade the QoE for the drone delivery scenario. The proposed QoS-aware communication approach helps to establish a connection between any two drones for sharing prompt information while adhering to the QoS metrics (end-to-end delay and network throughput). The aims of this approach are concerned with the collision avoidance and congestion control in order to to provide adequate QoS for the underlying communications related to drone delivery process. This approach adopts accurate positioning beacons for collision avoidance among drones and then apply congestion-avoidance policy to coordinate the communication.
This approach uses the properties of fire-fly optimization algorithm [35] and proposes an efficient mechanism based on light-intensity formation (an attractiveness parameter) to enhance QoS in drone communications. Firefly algorithm considers the concept of flashing light (produced through the process of bio-luminescence) generated by fire flies and correlate it to signaling systems. The fundamental functions related to the fire fly's flashing light, also known as attractiveness functions include, (a) to attract mating partners, and (b) to attract prey. Additionally, the flash light is also used as a signal for protective warning. The rate, pattern and related time are key aspects of flashing light that form a part of signalling system between fire flies.
The flashing light concept has been idealized and associated with objective functions related to optimization to formulate a firefly algorithm in [35]. This algorithm follows three key rules, (a) all fireflies are unisex and they can attract each other irrespective of their sex (ideally fit in case of drones), (b) attractiveness is correlated to brightness and both decrease with an increase in the distance, and (c) the brightness can vary with respect to the representation of the objective function. Further, this algorithm relies on two key concepts, (a) variation in the light intensity, and (b) formulation of attractiveness. Looking in to these two factors, the attractiveness of a firefly can be decided on the basis of its brightness (higher or lighter light intensity) and thereby linked to an objective function. We have applied this concept for drone communications and defined two objectives related to collision avoidance and congestion control based on the light intensity (brightness) that varies with an increase in the distance between the drones in a given area.
Inspired form the above concept, a communication approach has been designed wherein we have used the time slot mechanism proposed in [14] to form a connection between drones. Based on this, the proposed approach establish collision avoidance strategy through accurate position beacons as suggested in [36] and thereafter use the congestion control policy to realize the communication. The positioning of the beacons is vital and the effect of localization of drones is critical for drone delivery scenario. As drones have high mobility, the anchor points for the localization tend to change and finding appropriate anchor points is crucial. The proposed technique uses the light intensity parameter for optimization of the drone communications, that relies on the effective beacon positioning and hence provides effectiveness in areas with no fixed infrastructure to deploy the congestion avoidance policies. On the other side of the coin, the beacon position impacts the efficiency of the congestion avoidance which is susceptible to fail if the beacons are not chosen effectively.
In this approach, the average-light intensity received by the drones positioned at location L i and L j becomes the base of the proposed collision avoidance approach. In this regard, we define the average-light intensity (

(r )
A,i ) received by the drones as below [14].
where, the attraction value between two drones concerning irmth is denoted by α (t) i , initial attraction value is represented by α (t) i,0 , γ denotes the density of a drones in its neighbourhood, η represents the rate of change with respect to the present route, and inverse of probability of connectivity is represented by β.

(R)
A,i is computed for all the drones in the region, where γ act as the varying factor to enforce the varied number of inter-connected drones. Based on location-awareness, this model identifies collision possibilities as follows.
where, T H R represents a threshold and D represents a set of drones.
The work pattern of the original firefly algorithm tends to increase the light intensity (attractiveness or brightness) that doesn't fit with the requirement of the proposed model. The requirement of this approach is concerned with the lower light intensity as higher intensity (brightness) depicts the possibility of a collision. Thus, we used the modified firefly algorithm from [14] that operates in a reverse pattern thereby triggering the collision avoidance mechanism within the defined time cycle in an efficient manner.
Once the collision possibilities are identified, the next task relates to the congestion control in the network. For this purpose, for the incoming traffic, the intensity mechanism (of firefly algorithm) is used as the base to decrease (or increase) the congestion window by using lower (or higher) streaks for any given connection as proposed in [14]. Let us say, the traffic rate between any two drones is (V i, j ), then the congestioncontrol mechanism works for both drones in a simultaneous manner while considering (or managing) their transmissions (τ ) and receptions. The congestion-control evaluations can be expressed as below.
where, v denotes the velocity of the drone, θ represents the current heading of a drone, ΔC is the possibility of a connection between the drones and ranges between 0 and 1 for any incoming drones, and C ( cp) represents the number of channels for the connected components in average connectivity in a network.
In the above defined congestion-control evaluation, if at an instance there is an increase in the value of C (r ) i , then the network may end up in congestion. Thus, the proposed model need to adjust traffic based on the following condition.
where, T H R represents the threshold that is based on the average rate that is sustainable over a defined number of channels. Based on the above evaluations, the Algorithm 3 represents the workflow of the QoS-aware drone communications. Here, the first step involves satisfying the collision avoidance criteria. The mechanism continuously checks the possibilities of collisions over the defined way-points thereby averting any possible termination in the transmission. The mechanism ensures that a drone must satisfy the defined light-intensity constraints keeping in view of the neighbouring drone. If in a case, these conditions are not satisfied or doesn't hold TRUE, then an instant feedback is triggered so that the timing control can consider it while providing a time slot for next drone communication.
Once the collision-avoidance possibilities are satisfied, the next step includes the fulfilment of congestion control evaluations. The algorithm checks the possible collisions over the way-points in a continuous manner by managing the size of the congestion window. This helps to prevent any unintentional breakage in the transmissions and traffic overloading scenario. Once both the criterion are satisfied, we

Experimental evaluation and discussion
The proposed scheme is evaluated on the basis of three directions, (1) blockchain validation for smart contracts, (2) numerical validation, and (3) QoS validation based on simulation experiments.

Blockchain validation using ethereum-based test network
The smart contacts are used in the proposed framework to ensure the integrity of the system resulting in trust of the involved entities. The experimental setup for validation is elaborated below.
-Environment setup The logic used in the proposed scheme is translated in the form of smart contacts, which are executed through remix IDE [37] in combination with web3 scripting environment. The performance is evaluated on an Ethereum-based test network [38]. Metamask [39] account has been setup to access the Ropsten test network wherein the smart contacts are deployed. This environment is setup on a personal machine with a fixed hardware configuration configuration (Intel i7 7700HQ, 16GB RAM, PC4-19200 DDR4 2400MHz, Overclocked to 3.8GHz, Nvidia GeForce GTX 1060 (4GB)).
The effectiveness of the smart contracts, which is regarded as mileage according to Ethereum terminology, is evaluated through the price paid for the gas for deployment of the smart contracts. The first tested smart contact is for the interaction between the buyer and the seller. The results obtained are depicted in Fig. 6a, suggesting the effect of the paid gas price on the transaction throughput. With more cost paid for gas per unit transaction, the transaction throughput increases. The improvement ratio in transaction though is more around the lower end, whereas moving towards expensive transactions does not improve the throughput proportionately. Hence, to meet the requirements of the QoS, the gas amount has to be chosen accordingly to control the deployability of the proposed approach. Next, we validated the effect of the consecutive number of buyers in the proposed framework on the amount of gas consumption for smart contract execution. The findings are depicted in Fig. 6b, representing the trend that with an increase in the number of transactions, the gas requirement and hence the cost of deployment tends to increase in a controlled manner. In the end, the model is validated for the mining time with respect to the number of transactions that are simultaneously committed and the results are depicted in Fig. 6c. The results suggests the non linear variation of mining time which can be attributed to the miners. The possible explanations for the variation include the nonce whose computation is probabilistic in nature. Sometime nonce is computed very quickly, whereas sometimes it takes a longer set of combinations to be tried by the miners before a successful resultant. These validations give valuable insights into the resource consumption and the load of computation related to CovaDel.

Numerical validation based on computation and communication costs
The proposed model witness number of interactions between different parties. So, we compute the computational and communication costs related to these parties.

Computational cost
The computational cost associated for each phase is calculated as below.
-Initial agreement and smart contract phase In the initial agreement phase, four entities B j , S i , CS and W are involved. B j perform 5 append operations taking 0.6 ms in total and one digital signature computation which includes the encryption of SC k using the private key of buyer costing 1.2 ms. CS performs one search operation requiring at least 2 ms which tends to increase with the larger database and 4 append operations requiring 0.45 ms. S i requires 3 append operations to generate the invoice requiring 0.3ms. Lastly, the W performs one search operation requiring 2 ms. Hence, the total computational cost in this phase is 6.55 ms. -Delivery phase In this phase, B j performs one comparison operation to check the transaction from T SC k requiring 0.5ms. When the order gets delivered, B j needs to generate O cmp k to indicate the receipt of product which requires 0.2 ms. S i needs to do one comparison operation in order to validate the T SC k which is to be added to the blockchain requiring 0.5 ms. CS adds the T SC k of SC k into blockchain for which it first adds it into the T nm x requiring 0.2 ms. After verification by B j and S i , the T SC k is finally mined into the block requiring 2 ms and added to the BC D . Then, the extraction of SH O x from the smart contract requires 0.3 ms. The smart contract is added to the blockchain requiring 1 ms. After delivery the smart contract is executed by the blockchain requiring 2 ms. DS executes the drone scheduling algorithm for which 5 comparison operations are performed requiring 2.5 ms, 6 addition operations requiring 1.8 ms, and searching requiring 0.5 ms. D i collects the information from BC D and then processes the flight plan requiring 2 ms. It also updates its status on the BC D which needs 0.4 ms. Cumulatively, the computational cost of the delivery phase accounts to 12.9 ms.
-Payment phase The final phase of payment processing requires the BC to perform one subtraction operation requiring 0.3 ms and one addition requiring 0.3 ms.
The CS needs to perform the trigger on SC k requiring 0.2 ms. Hence, the total cumulative computational cost of the payment phase is 0.8ms. This brings the total computational cost of all the three phases to 20.25 ms.

Communication cost
The communication cost for different phases is calculated as below: -Initial agreement and smart contract phase The communication cost of the proposed scheme is 640 bits per item.

Simulation study for QoS validation
To understand the performance of the proposed scheme, the validation is performed through a simulation study performed using Network Simulator (NS-2). The length of RTS, CTS and ACK packets considered for the evaluations is 170, 120, and 120 bits, respectively. The physical layer header and default packet lengths are same as 802.11b (pause time 2s). The performance results are evaluated on the basis of network throughput and end-to-end delay. To guarantee the QoS satisfaction, a maximum resource utilization must be achieved with an increase in the average transmission rate. The network throughput increases when the achieved utilization rate nears the permissible rate. However, the average network throughput decreases when we increase the number of users. The proposed scheme aims to handle the above challenge by sustaining the average network throughput to its best, even when the number of drones are increased. Fig. 7a shows the variation of the average network throughput with respect to an increase in the number of drones (10,15,20) and the number of users (100, 200, 300) requesting delivery. The end-to-end transmission delay is dependant on many factors and it is not possible to control all these factors. But, the major contributors to the overall delay can be considered as processing and queuing tasks. If both of these tasks are controlled effectively, then it is possible to reduce the overall end-to-end delay. The proposed approach provides a very simple processing model supported by a multi-level queuing scheme for drone scheduling and product delivery. The proposed congestion and collision-aware transmission scheme helps to reduce the overall end-to-end delay in the network. Fig. 7b shows the variation of average delay with respect to an increase in the number of drones (10,15,20) and the number of users (100, 200, 300). It depicts that the delay increases with an increase in the number of users in contrast to the number of drones. If we increase the number of drones and reduce the number of users, then a lower delay is observed.

Complexity comparison in contrast with existing similar works
Various existing proposals have explored the problems related to drones but most of them have not considered the drone delivery case. Here, the proposed work is compared (a) (b) Fig. 7 a Average network throughput, and b Average end-to-end delay with the existing works in terms of the complexities of the underlying approaches. The findings are summarized in the Table 2.

Conclusion
The proposed framework leverages the advantages of blockchain and smart contracts resulting into more transparent delivery operations COVID-19 like situations. Here, a derived blockchain is proposed for the part of the model where the normal blockchain will not be very suitable candidate still preserving the heritage of immutability of blockchain. In this framework, a virtual currency-based transactions are presented eliminating the reliance on third parties for payment processing hence eliminating the extra burden in terms of monetary cost. One of the key contribution comes from the drone scheduling algorithm which is backed by multi level queuing model ensuring optimal allocation of drones for various delivery jobs with minimal overhead. Incorporation of the QoS aware drone to drone communication approach has brought forward advantage of meeting the most challenging service levels in such scenarios. The proposed framework have been verified and validated for its reliability and performance in a simulated environment. The results indicate the performance of the system is effective. Further, the model is evaluated theoretically for the communication and computation costs which also favours the model.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.