A BROADCAST RECEIVE MODEL FOR COMPUTATIONAL OFFLOADING IN MOBILE CLOUD COMPUTING

Computational offloading is a vital part of mobile cloud computing which has attracted so much attention in recent times. It is a way of saving energy in mobile devices by sending an intensive task to a remote server for execution. However, in existing offloading systems, the opportunistic moments to offload a task are often short-lived. The social aware hybrid computational offloading framework involves outsourcing a task to any available surrogate either remote cloud, cloudlet or device to device, this comes with a drawback of super peer having to constantly supervise the network to discover peers. This takes a considerable amount of energy and time. This research aims to develop an improved model for peer discovery in computational offloading which relieves the use of the super peer and transfers the discovery process between network peers. We used a device profiler that serves as an information collector in peers on the network. We evaluated our model by developing an application for our client nodes in order to get information from our nodes. We evaluated our model by using ten peers with different processing power and RAM. On an average, discovery time for all peers in the existing model was 2040 milliseconds, while we have 1,213 milliseconds for our new model. Energy level for the existing model was 72.5% while we have 82.3% for our new model , evaluating our model with the existing one, it was discovered that we saved more energy and time.


INTRODUCTION
Mobile cloud computing is the hybrid of cloud computing technology, mobile cloud computing and wireless network makes good computational resources available to mobile users (Oladeji & Olubunmi, 2017). Computation offloading combats the shortcomings of Smart Mobile Devices (SMDs) such as limited battery lifetime, limited processing capabilities, and limited storage capacity by offloading the execution and workload to other capable systems with better performance and resources. Mobile Cloud Computing allows the SMDs to offload their workloads on the remote cloud servers and benefit from the Mobile cloud computing extensive resources (Amir, Mokhtar, Adil, Sarkhel H, Mohammed, & Mohammed, 2021). User demands increases quickly with a lot of resource-intensive and power-sapping applications. (Quang-Huy & Falko, 2020) Nowadays, mobile phones are used for more than making phone calls or sending texts, due to the provision of different mobile applications However, these devices' mobility is hindered by battery life and thus their usage is inhibited. (D. Ferreira et al, 2011) Due to the insubstantial computation resources, network, storage, and energy, mobile devices are inadequate for executing all computational tasks, especially tasks with big volumes and complex data structures (Hoa & Dong-Seong, 2023). This is more critical when a user does not have access to a source for recharging the battery . In such situations, as the battery life approaches its lowest energy levels, the user may experience frustration and anxiety, among others (Hosio et al, 2016). As the potential of mobile devices gains ground (in terms of CPU power, network connectivity etc), people increasingly use them for other tasks such as emailing, GPS routing, Internet banking, gaming etc. Even though they advance in technology, mobile devices will always be limited in resources, as restrictions on weight; size, battery life, and so on imposes limitations on computational resources and makes mobile devices more resource constrained than their non-mobile peers. Computational offloading systems can be categorized into cloudlets, remote cloud and device-to-device (D2D) (Shi et al, 2014). A lot of research work has gone into finding a solution to this problem with different researchers coming up with different models. As a mobile device is always linked to at least one source of network infrastructure throughout of the day, by merging cloudlet, device-to-device and remote cloud offloading, the availability of offloading support was increased. A community is formed by a set of people that are always together during particular hours, in the weekdays users tend to work in the same workplace or study in the same department. Generally, they encounter the same people during a specific period of time. Thus, this leads to the idea of a shortterm community among the peers which are regularly present at a specific time period in specific locations. Every node in the system is called a peer, cloudlets and remote servers are naturally super peers that sustain the system. Computation offloading is the process of sending computation intensive application components to a remote server. Recently, a number of computation offloading frameworks have been proposed with several approaches for applications on mobile devices. These applications are partitioned at different granularity levels and the components are sent to remote servers for remote execution in order to enhance the potential of Smart Mobile Devices. Computational offloading systems include cloud, cloudlets and device to device. CLOUD: The cloud infrastructure is equipped for open use whereby the users can offload one or more tasks to the cloud, e.g Amazon, Microsoft Azure and so on. CLOUDLETS: By relying on these cloud infrastructures computationally intensive tasks can be offloaded to the cloud. Cloudlets was a way to bring it closer since they are far from the mobile users, it serves as a middleware between the cloud and user. It can be said to be group of computers designed to quickly provide cloud computing services to mobile devices, such as smartphones, tablets and wearable devices within close geographical range-DEVICE-TO-DEVICE: Offloading to remote clouds and cloudlets were faced with offloading decisions such as mobility, latency, state of the device and so on, making it difficult to know exactly to offload. In order to address this issue, very recent works has relied on other devices that are carried around by other users which produces a low latency environment to offload. Study has shown that social relations tends to provide support for offloading in device-to-device (Cuervo et al, 2010) focused on using MAUI (Mobile assistant using infrastructure) for the reduction of energy consumption of mobile applications using fine-grained code offload, it decides at runtime which methods should be remotely implemented, driven by an optimization engine that attains the best energy savings possible under the mobile device's current connectivity limitation. There was a need for further enhancement on MAUI for future execution of more than one method /thread at a time. (Gordon et al, 2012) introduced COMET (Code Offload by Migrating Execution Transparently) a runtime system to allow plain multi-threaded applications to use multiple machines which was a drawback of MAUI, the system allows threads to move freely between machines depending on the workload. COMET uses the underlying memory model of the runtime to implement distributed shared memory (DSM) with as few connections between machines as possible. (Verbelen et al, 2012) provided middleware architecture between the cloud and the mobile device by introducing Cloudlets, offloading to the cloud is not always a solution, because of the high WAN latencies, especially for applications with real-time limitations such as augmented reality. Therefore the cloud has to be moved closer to the mobile user in the form of cloudlets. Instead of moving a complete virtual machine from the cloud to the cloudlet, they proposed a finer grained cloudlet concept that controls applications on a component level. (Habak et al, 2015) designed the Femtocloud system which provides a strong, self-configuring and multi-device mobile cloud out of a cluster of mobile devices. The architecture was developed to enable multiple mobile devices to be configured into a coordinated cloud computing service. It was said that there was a need to design a suitable user motivation system in the future due to the fact that Femtocloud relies on social awareness like students in a classroom, or a coffee shop, there was a need to sustain the system from collapsing. (Flores et al, 2017) tackled the limitation of Femtocloud by introducing a reputation and credit based mechanism scheme to the offloading system. A social-aware hybrid offloading system (HyMobi), which increases the range of offloading means, was designed. As a mobile device is always linked to at least one source of network infrastructure throughout the day, by merging cloudlet, device-to-device and remote cloud offloading, there was an increase the availability of offloading support. HyMobi was designed with an incentive mechanism based on credit and reputation, represented by points. A peer gathers points when it is sharing its computational resources to other peers' requests, e.g., by contributing resources, remaining in a particular place for a long time, a peer loses points when consuming resources of the community pool.

MATERIALS AND METHOD
The proposed model composes of three main parts, namely: i. The device peer, ii. The request handler, and iii. The code-offload processor.

The Device Peer
Every node in the system by default is called peer. This includes Cloudlets, any remote server providing system services or any mobile device. The peer is composed of three main sub-components which are: i. The network peer status table ii. The broadcast and receive module, and iii. The device profiler The network peer status table represents a small space in memory where the status of individual peer in the network is stored every specified interval which is managed by the broadcast and receive module.
The broadcast and receive module is responsible for the management of the network peer status table. The broadcast and receive module can assume different states at different times. The states that the broadcast and receive module can assume are four (4), which are: i. On, ii. Off, iii. Idle, and iv. Discovery.
The device profiler is responsible for the profiling of devices on the network. The device profiler is trigered when a new device enters the network or when a specified time interval that has been set before hand is expired. Another scenario when the device profiler could be trigered is when a device is about to leave the network.

The Request Handler
The request handler is the gateway where a request is processed based on its type, where the type of the request depends on the role of the peer. When a discovery request is received, the request handler responds to a request either from a peer or a set of peers who are interested in an offloading transaction. If the server is not maxed up already, it accepts the request and the offloading process handled by the code offloading processor is executed, but if it is maxed up already, then the requesting peer or peers will have to wait for the next opportuned time to perform a code offload process The code offload processor component captures the execution details of a computational task during runtime at the method level, e.g., name of the method, parameters, type of the method, etc. this module is responsible for handling the code offloading task of the network 242

End if End Procedure
The getDeviceStatus() module serves as the module for performing device status rating. This calculations help reduce the work of selecting the network device peer server. The calculations is based on three (3) parameters, which are: 1. The computing resource of the device, 2. The number of nodes connected to the device, and 3. The energy level of the device. The equation (1) below shows the the equation used for the device ranking. Score(Nc,Cc,Bc) = (Nc/N) * (Cc/100) * (Bc/100) Where: Nc = the number active connections to the device, Cc = the computing resource processing frequency, Bc = the battery level of the device.

RESULTS AND DISCUSSION
We evaluate and analyze two different aspects of the framework, i. peer discovery performance and ii. energy consumption , Huber Flores et al used ten mobile devices to carry out their experiment. We replicated that by also using ten devices, the result of the experiment is presented in table below. 243 Figure 2: The mobile client interface The figure above shows the broadcast and receive interface, the request handler handles a request by any peer to discover the server or leave the current network. When such a request is received, it checks to see if the peer has any on going code offloading process, and therefore triggers the device profiler which in turn collects necessary device status information at that particular time as seen in the figure above and updates the network device status table accordingly. We used ten devices just as in the existing model done by Flores et al, the devices has different rams and processors for easy comparison, the result above shows the average time it took to discover the peers used in our model, the found the average of 10 peers and compared it with the average discovery time of the existing model.

CONCLUSION
Computational offloading has been proposed as a solution for saving the battery life of the mobile devices therefore, in order to maximize computational offloading process overall, we improved the discovery process of these peers, developed a broadcast and receive model that can effectively gather devices information and update requesting peer. We improved the discovery time it takes to see a peer on the network and also reduced the energy it takes to search for a peer. A peer can offload a task to a more capable device on the network if it doesn't have enough resource to process its task.