A Lightweight Leader Election Algorithm for IoT: Cloud Storage Use Case

In a distributed environment where IoT devices collaborate on shared data, ensuring a secure turn-taking process during data updates remains crucial. Unlike in centralized systems, the concept of mutexes is no longer applicable in distributed systems. This is where distributed locks and leader election mechanisms become essential. The BROGO (Branch Optima to Global Optimum) Leader Election Algorithm, known for its low power consumption, presents a compelling solution tailored for IoT systems. Notably, this algorithm achieves a remarkable 95% reduction in energy consumption compared to conventional techniques. In the context of this paper, we use the BROGO algorithm as a case study within the realm of cloud storage.


INTRODUCTION
The Internet of Things (IoT) and the associated Wireless Sensor Networks (WSNs) are particularly valuable in scenarios where sensors need placement in diverse or remote locations [1,7].WSNs comprise numerous devices that communicate through short-range wireless connections to transmit messages.Furthermore, these devices can relay collected data to a remote ground station or update a shared file in the cloud [11].
Cloud storage serves as a facilitative approach, offering convenient file availability, accessibility, and enhanced security through the implementation of various access control policies and cryptographic concepts [8,14].In this context, a leader election and blockchain algorithm for e-health in a cloud environment is introduced in [20], taking into consideration medical and healthcare requirements.Under normal circumstances, this study minimizes the message count but prolongs the processing time, prompting a comprehensive exploration of the pros and cons associated with the utilization of Blockchain technology.
In [24], the authors present a proposal for a scalable two-layer blockchain system designed for application in distributed multicloud storage.The key innovation lies in the introduction of a novel consensus algorithm, termed proof of storage allocation, for leader election or cluster head election [17] [16].This algorithm enables the leader to address data placement challenges, ensuring equitable solutions for data storage.To enhance scalability, the authors incorporate asynchronous consensus groups into the overall consensus process.
Numerous alternatives have been suggested in the literature.In the D-LPCN algorithm [23], the treatment initiates from the node positioned at the far left of the network, embedded in a plane with nodes determined by their coordinates.The identification of this particular node involves the application of any Leader Election technique.This poses a challenge in distributed systems, particularly in scenarios where data is dispersed among geographically isolated devices, such as in IoT environments.All proposed solutions necessitate the implementation of a low-energy routing scheme [9,13].
Except the Minimum Finding Algorithm [22], several approaches address this issue.In [2], the authors enhance the well-known leader election Ring scheme by reducing the number of transmitted messages through clock synchronization and an ideal connection between sender and receiver.However, these assumptions may not be sufficient in IoT [19], necessitating the use of more complex techniques to ensure synchronization.Another improvement is presented in [6], where the authors offer an enhanced version of Bully's algorithm that requires fewer messages but takes more time.In this scheme, each node compares its value with the received value and transmits only the greater one.In [12], the authors divided the network and conducted a pre-election to select a provisional leader.The main drawback of this algorithm is that in the event of a node crash, the contents of the memory will be erased.
In [5], the number of nodes is restricted to facilitate failure detection and initiate the leader election process.The authors assert that, even in the worst-case scenario, the scheme maintains ideal time and complexity.Another modification is presented in [18], where Bully's algorithm is adapted to improve processing time.The leader is selected based on performance and operational efficiency.In [4], the authors rely on an optimal transmission connection, overlooking issues such as time on air and collision problems, while incorporating fault detection algorithms.Proposing a dual-leader approach, [25] introduces a main leader and an assistant leader.In the event of a main leader crash, the assistant node can assume control, significantly reducing the frequency of elections in the system.
This paper adopts the BROGO algorithm [3] for IoT cloud storage.Unlike the Minimum Finding Algorithm, BROGO operates effectively in asynchronous environments without imposing any assumptions on the topology.Through a comparative analysis, this algorithm demonstrates a success rate exceeding 95%.
The remaining sections of the paper are organized as follows: In the subsequent section, a comprehensive review of the BROGO algorithm will be provided.Section 3 will delve into the use case of the BROGO algorithm.Ultimately, Section 4 will bring the paper to a conclusion.

BROGO ALGORITHM
To identify the leaves of the discovered spanning tree, BROGO employs the Flooding for Leaf Finding (FLF) Algorithm.The FLF Algorithm operates as follows: during the flooding procedure, following the transmission of each  1 message, the sender awaits an acknowledgment, denoted as the  2 message.Initially, every element, except for the root node, is regarded as a leaf.Upon receiving an acknowledgment, a sender is reclassified as a non-leaf node.
BROGO steps can be presented as follows: • Step 1: Assuming the network of Figure 1, BROGO executes the FLF algorithm to define a spanning tree together with its leaves.• Step 2: Each leaf will route a message from itself to the root.This operation will permit routing of the minimum value in each branch situated between the reference node and each leaf.The reference node will determine the global minimum from the received values.
• Step 3: The reference node will send a message to the global minimum node telling that it is the global minimum node.The outcome of the leadership election is demonstrated by the red node in Figure 1.
BROGO is simulated using CupCarbon [15].To compare the BROGO algorithm with the classical MinFind algorithm, 9 networks have been generated in a rectangular area of ( × ) 2 , where  takes the values from 200 to 1000 with  randomly generated nodes. is fixed to 10 nodes/ℎ 2 (ℎ: hectometer), i.e., 10 nodes in an area of 100 × 100 with asymmetric communications between nodes.
A comparison result is shown by Figure 2. As we can see, BROGO can achieve 79% in the first case (with random values) and 95% in the second case (with x-coordinate values).These values can be increased when the size of the network is increased.

CLOUD STORAGE USE CASE
Leader election is a commonly employed approach in distributed systems.In replicated relational databases such as MySQL and distributed key-value stores, a leader (also known as a master) is chosen from a set of nodes.All write operations are directed through the leader, allowing only the selected node to write at any given time.This is crucial to ensure that no writes are lost and that the integrity of the database is maintained.
Typically, leader election is utilized to guarantee exclusive access by a single entity to shared data or to ensure that a single entity effectively coordinates the work within a system.IoT systems leverage leader election mechanisms to streamline their operations.However, the process of selecting a leader is a nontrivial problem that requires careful consideration.

Why BROGO?
In addition to its lightweight design [10], BROGO boasts several other advantages, including: • Leader Election Mechanism: BROGO facilitates the election of a single node to serve as the leader, responsible for coordinating the actions of subordinate nodes.The algorithm is designed to handle events like network outages or process failures, ensuring a robust leadership selection process.• Ease of Implementation: BROGO is characterized by its ease of implementation and usage, streamlining the integration of leader election functionality into distributed systems.• Resilience to Failures: Demonstrating resilience, BROGO effectively copes with both transient and persistent failures, contributing to the overall reliability of the system.• Failure Detection: The algorithm enables the detection of leader failures or unavailability, allowing for timely response and adaptation to changes in the system.• Dynamic Scalability: In the event of system scaling back, BROGO allows for the termination of the leader, providing adaptability and dynamic adjustment.• Flexibility: BROGO offers exceptional flexibility, making it adaptable to diverse scenarios and system requirements, enhancing overall operational versatility.

Synchronization
To synchronize operations, we assume event-based models.Each element conducts a read and/or update process on the data file.Every process is defined by two instantaneous events, start and end.Subsequently, concurrent processes are ordered to match a valid sequential execution.Linearizability respects the real-time order of concurrent execution.Thus, the synchronization of events must follow a well-formed clock.Finally, processes occurring on various processors are ordered, and since they use a single version, any update must utilize a token to take place.Therefore, the order of processes follows the movements of the token.Figure 4 describes the proposed model.If data is not shared, the associated node can modify it at any time.Otherwise, the leader has complete control over access to the shared data.In scheduling access, the leader utilizes a set of predetermined rules, including the request importance, update time, etc.

Parallel Access
To enable parallel data usage and prevent collisions, "read" processes access data without acquiring the token, while "update" processes must obtain the token for execution.The token is represented as a file lock  ().Access to a "read" process may be denied if the data file is locked for an "update" process.To enhance parallelism, the data file can be partitioned into multiple segments, allowing nodes to access different segments concurrently.Each segment contains a range of bytes with a corresponding lock.Consequently, there are multiple locks for the same file, and each node must specify the required segment for access.The leader is then capable of selecting the nodes with the tokens and their respective segment numbers.
The leader is not required to retain the token; rather, the token is a flag present in each node.For lock acquisition, the leader node sets the token to 1 and resets it to 0 for lock release.The leader selects the token without the need for messages.In exceptional cases, when a node desires to acquire the token, it transmits a message to request the token.Thus, the respective node receives an acknowledgment response from the leader.

CONCLUSION
This paper presents a use case of a novel Leader Election algorithm designed for low energy consumption [21] in an IoT environment, specifically tailored for cloud storage.The BROGO algorithm establishes a spanning tree of the network, where IoT nodes route messages from each leaf to the root to transmit the minimum value in each branch.The root computes the minimum value from all the received branch minima and dispatches a message to the leader node (the one with the minimum value) to elect it.Then, we utilized the elected leader to regulate access to shared data in cloud storage, preventing erroneous updating results.In future work, we aim to implement BROGO and other leader election algorithms in other domains that demand low energy consumption.Competing interests: The authors declare no competing interests.

Figure 1 :
Figure 1: A leader election process using BROGO algorithm.

Figure 2 :Figure 3 :
Figure 2: Comparison between the BROGO algorithm and the MinFind algorithm.

Figure 4 :
Figure 4: Event-based model representation for cloud storage.