Fourth Industrial Revolution for Development: The Relevance of Cloud Federation in Healthcare Support

Inefficient healthcare is a major concern among many African nations and can be mitigated by building world-class infrastructure connecting different medical facilities for collaboration and resource sharing. Such infrastructure should support collection and exchange of medical data for the purpose of accessing expertise not available locally. It should be equipped with modern technologies of the fourth industrial revolution, providing decision support to doctors thereby enabling African nations leapfrog from poorly equipped to medically prepared. Sadly, world-class healthcare infrastructure are a missing piece in the African public health ecosystem. Medical facilities are either non-existent or prohibitively expensive when they exist. Federated cloud computing can provide a solution to this challenge. Being a model that allows collaboration between multiple Cloud service providers through resources pooling; it allows for the execution of tasks on computing resources flexibly and cost efficiently. This paper aims to connect unconnected medical facilities in Africa by proposing a Cloud federation for healthcare using cooperative and competitive collaboration models. Simulations were carried out to test the efficacy of these models using five different workload allocation schemes: First-Fit-Descending (FFD), Best-Fit-Descending (BFD), Binary-Search-Best-Fit (BSBF); Genetic Algorithm meta-heuristic and Stable Roommate Allocation economic model for both light and heavy workloads. Results of simulations revealed that the cooperative model resulted in lower delays but higher resource utilisation; while the competitive provided faster service delivery and better quality of service. BSBF and BFD resulted in the best resources utilisation and energy conservation. Finally, deployment considerations and potential business models for federated Cloud for African healthcare were presented.


Introduction
Cloud computing is a key technology which plays a vital role when interfacing the physical and virtual worlds in most fields of the fourth industrial revolution (4IR). There are numerous definitions of Cloud computing in literature, however that of the 1/25 NIST is arguably the most accepted. According to the NIST, Cloud computing is a model that enables pools of measurable computing resources be made available to users conveniently and ubiquitously [1]. One of the key characteristic of Cloud computing is elastic pool of resources, this implies a near infinitive resource scale. In actuality however, no Cloud Service Provider (CSP) is able to provide a limitless amount of resources to users. Beyond elasticity, Cloud resources need to be available at any time and from any location, globally. Although it is possible to achieve global coverage for a single site data centre, users would however experience increased latency/delay and reduction in throughput as distance grows. To this end, CSPs often have data centres located in multiple geographical areas in order to be as close to the users as possible -a concept known as multi-homing [2]. In the same vein, there are situations whereby a CSP does not have enough resource to cater for all its users; such a situation might arise for example during peak office hours (company websites), during promotions and sales (for e-commerce websites) or when students are resuming new academic sessions (for academic websites). Two potential solutions to problem of resource shortage and/or extended coverage are resource scaling (either vertically or horizontally [10]) and collaboration with other CSP. Resource scaling might however be extreme costly especially if demand spike is only for a limited and short amount of time. CSP collaboration on the other hand might prove to be a more cost-effective solution.
Cloud federation has emerged as a solution for CSP collaboration [3]. It is based on the economic model of federation game and one in which multiple CSPs combine their resources, in a way that allows for cross-utilization amongst themselves and improve quality of services (QoS) rendered to users [8]. Cloud federation also provides CSPs with an extended reach, as they are able to leverage on partner CSPs to reach disperse geographical locations. Cloud federation can be provided in one of three models [8,9], which are: infrastructure pooling (where resources of multiple CSPs are aggregated together and appear as a single virtual infrastructure, much similar to the disk striping or RAID0); hybrid federation, which combines resources across private and public Clouds and broker-based federation, wherein each CSP remains independent but are conjoined by a single broker. The focus of this paper is on the third model and one in which CSPs have the option to choose to join a federation or work independently.

Cloud Federation for Healthcare Support in Africa
It is widely recognised that developing nations have missed many of the opportunities offered by the first three industrial revolutions. It is also expected that, cognisant of this sad fact, many developing countries will take advantage of the technologies of the fourth industrial revolution which are most relevant to their needs to leapfrog from poorly equipped to technologically prepared countries. The specific 4IR use-case scenario being considered in this paper is the application of Cloud federation to health care and medicine across African countries. This would allow for collaboration and resource pooling across the continent for improved health care services. The justification for a federated Cloud for medicine in Africa are numerous, few amongst which are: i. most African countries are either under-developed or developing. ii. access to world-class medical services is either non-existence or extremely expensive; however there are a handful of African countries with good medical facilities, which can offer tele / cyber-health [25] supports. iii. patients in many developing parts of Africans cannot afford the huge cost of flying abroad or to other African countries such as South Africa and Egypt for treatment. Cloud federation can therefore allow collaboration, wherein resources can be pooled together to carry out processes such as X-Rays and CT Scans interpretations, remote testing and diagnosis, and possibly conference surgeries -where multiple experts monitor and observe surgical procedures. To put this in context, we would describe an application scenario. Currently, there are only about 75 Cloud data 2/25 centres (DC) across the African countries according to [22] and Fig. 1 shows their distribution, with each bubble sized proportionality to the number of DCs in each country.

Figure 1. Sizes of Data Centres across Africa
From Fig. 1, only six countries have more than five DCs, while nine countries have between 1-3 data centres. This is a total of fifteen countries of the total fifty-four in Africa. The other countries either do not have or theirs' are below the DC standards as stipulated in [23,24]. Building DCs and capacity is a very expensive and time consuming process. Many African countries are still encumbered with economic sustainability and survival challenges to be considering Cloud DCs. Cloud federation can therefore be of immense value to these countries and the African continent in general. Fig. 2, shows a potential high-level Cloud federation network for medicine across Africa. Countries with a multiple DCs are chosen as regional hubs and distributed as follows: Egypt to the North, South Africa to the South, Kenya to the East, Nigeria to the West and DRC at the centre. A high bandwidth, low latency network connection between these hub nations would serve as the backbone of the federated system, while the hub countries serve as regional gateways into the network.
The Federation can be done in one of two models. In the first, the CSPs agree to work together, forming a single virtualized resource pool; we refer to this model as a co-operative federation. On the other hand the CSPs can decide at specific time intervals to work independently, we refer to this model as the competitive federation.

Contribution and Outline
For this work, we also consider five different workload allocations schemes to determine their effects on the co-operative or competitive Cloud federation. These allocation schemes include the heuristic models -First-Fit Descending, Best-Fit Descending and Binary-Search-Best-Fit; meta-heuristic model -Genetic Algorithm and an economic model in Stable Roommate Allocation. Resource utilization, QoS and allocation delays were considered as performance metrics. The specific contributions of this paper are: • A detailed performance comparison of five different workload allocation schemes and how they affect various metrics in co-operative and competitive cloud federations.
• A unique GA gene encoding scheme for the allocation of Cloud workloads to PMs.
• Potential business models for deployment of federated Cloud for health care in Africa.

Figure 2. High-level Conceptual Cloud Federation Network for Health care in Africa
The rest of this paper is organized as follows: following this introduction is a review of related work in section 2. In section 3, the Cloud federation models are presented, while the various workload allocation schemes considered are presented in section 4. Results of simulations done are presented and discussed in section 5. Deployment considerations and potential business models are presented in section 6; while section 7 concludes the paper with motivations for future works given.

Related Works
With respect to collaboration across nations, a number of solutions already exist particularly in the academic and research domain. One such is the African Research and Education Network (AfREN), which is a network established for collaboration and research across Universities and research centres across Africa [26]. It is a region based network and consists of ASREN covering the North and Mid-East Africa, WACREN for the West and Central Africa and UbuntuNet for the East and South African countries. Similar networks also exists globally such as the Asia-Pacific Advanced Network (APAN) [27], GEANT [30] in Europe and internet2 [31] in the USA.
A number of works have been done on providing infrastructure to support health across the African continent. In the work done by Bagula, et al. [41], the authors proposed a multi-layered framework for Cyber-Physical Healthcare which combines IoT and machine learning techniques. IoT was used for collection and muling of health data, while the machine learning techniques were used for patient triage. The potential advantage of this framework include better patient prioritization, better patient monitoring as well as cost and time savings. In a related work on IoT and healthcare, considerations for designing a full stack Remote Patient Monitoring system (RPM) for tele-medicine based on FiWARE was presented in [32]. FiWRE advocates openness and the authors proposed a solution inline with the FICHe guidelines. Critical considered to note when building such a system were give, some of which included design steps, device deployment, data -collection, muling, security and storage as well as system integration.
The authors in [4], considered the applications of Fog computing for storing sensitive 4/25 health information in a Cyber-healthcare system in a secure manner and proposed the Multi-Phased Data Security and Availability (MDSA) protocol. The fog networks helped cut down network latency, while the multi-phased security ensured end-to-end security coverage. In another related work, the authors in [42], proposed a Cloud-based medical triage service system. Upon collecting body vital signs from patients, the system analyses the information using either linear regression or k-means, benchmarking the obtained results again the WHO standard. In order to achieve collaborative health care system pan-African wide, standards have to be agreed upon for effective transmission and interpretation of patient medical / health records. This would foster interoperable between the various Cloud platforms spread across the continent. Lubamba and Bagula [43], had proposed a framework for the standardization of medical data. Their proposed model was based on the Health Level Seven (HL7) standard [44].
In their work, patient data had to be encoded into XML based HL7 format before being transmitted using HL7-CDA web service. From obtained results, the authors showed that their HL7 based model was able to transmit significantly more records, with minimal overhead impact when compared with the alternatives. The works above could be applied in the implementation of healthcare kiosks in developing countries as suggested in [28,29]. In the work done by Shimizu et al. [27], the authors presented medical use cases of combining the Asia-Pacific Research and Education Network (REN) with a Digital Video Transport System (DVTS). The DVTS allowed them obtain digital streams of images which could be transported via an IP network, while the REN provided a stable high-bandwidth network for transmission. A hundred different medical teleconferences were used as test, with images from live surgical sessions, endoscopy, transplants, nursing and health care amongst others. The authors in [33] also discussed on the potentials and advantages of introducing Tele-medicine in Africa, some of which includes: lowering medical costs, reducing geographical distance and cater for severe shortage of doctors across the African continent. Factors limiting the wide-spread adaptation of Tele-medicine as well as possible future directions were also presented.
Cloud computing has in the last two decades emerged as a reliable, robust and capable computing paradigm. It has therefore seen numerous practical application in almost all aspects of live. Cloud computing has also grown beyond the single-site, single provider solution it once was to one in which multiple CSPs work together to achieve set goals. Darzanos, et al. [8], had proposed a model for economically evaluating Cloud federation. They focused on workload delays within federated Cloud systems. With time being the main metric, they therefore modelled each CSP as an M/M/1. In the work, the resources of the CSPs were pooled and user workloads could be served by resources belonging to any of the participating CSPs. They finally developed a model for allocation that maximized the profit of the collective whole. In a latter work [9], the authors still considered each CSP as an M/M/1 but also considered the performance across three types of cloud federation models-weak, strong and elastic. The strong is a completely co-operative model, the weak is similar a competitive model, while the elastic can be described as a dynamically competitive model. In this work however, profit was dependent on energy consumption and QoS-adherence. Finally, the Shapley-value was used to profit sharing among the participating CSPs.
With respect to our choice of allocation schemes, we can consider the allocation of workloads to Cloud resources as a bin-packing problem [17], which in itself is a NP-hard problem. This therefore necessitates the use of non-intrinsic methods to solve, such as heuristic and meta-heuristic models. In terms of the heuristic, the first-fit, best-fit and their variance are arguably the most common. For Cloud workload allocation, the Best-fit-descending (BFD) has been widely used by numerous researchers [12,13,16], it therefore makes an excellent choice for our selection. First-fit-descending like BFD uses 5/25 has been shown to use the same amount of bins, but FFD is faster. With allocation speed being a core metric in this paper, we therefore considered FFD. In terms of meta-heuristic, the Genetic Algorithm has been widely used in many literature for workload allocation in Cloud computing environs. A few of these works are [11,14,15]. For a number of these work, energy conservation, QoS and resource utilization were metrics considered.
Economic concepts have been widely applied in solving computing related problems. Coalition games and game theories have been used for problems relating and involving multiple participants -such as in VM migration in federated computing [7] and dynamic resource re-allocation in [6]. The stable marriage/roommate economic models have been also used for workload allocation in Cloud computing environments [5].
The focus of a number of these works were either on medical collaboration via the Internet and/or various schemes for allocating workloads to Cloud resources. Unlike in these other works, in this paper we consider a Cloud federation system for improved user satisfaction and service delivery across the African continent. Like the work of [9], this work also compares the different cloud federation model, however we seeks to determine which of the two models is best suited for specific requirements -light or heavy usage demands. To achieve this, we applied various workload using a simulated federated network consisting of multiple CSPs working co-operatively or competitively to provide medical services across the continent.

The Cloud Federation Model
Typically, a federated model for Cloud computing includes different cloud providers collaborating by: i) sharing their resources while having each of them remaining an independent autonomous entity by keeping "thick walls" in between them; ii) having the applications running in this cloud of clouds while being unaware of location due to virtual local networks being designed and implemented to enable the inter-application components to communicate and iii) having cloud providers differentiate from each other in terms of cost and trust level.

Cloud Federation Model Formulation
When considering a federated cloud environment, the virtual machines allocated to the users' tasks can be migrated either to physical resources of the users' cloud provider or to physical resources of different cloud providers. Such an allocation of virtual resources to physical resources can lead to a cooperative model when users' virtual machines can be migrated anywhere or a competitive model when users' virtual machines can only be migrated to their providers' physical machines as expressed by Fig. 3. In our model, the resources which have been availed by a cloud provider j are 6/25 expressed by R pn (j) while demand for resources by a VM i during migration are expressed by D vn (i). The federated cloud computing problem consists of finding for each VM i in distress, a mapping to a physical resource provider j that maximises a utility function D(i, j) as defined below Note that as expressed by equation 1.b, P (i, j) is a binary parameter used in the model to differentiate between cooperative and competitive cloud computing as expressed below: Note that as expressed by equation 2, P (i, j) is used in the model to enable all participant providers to be elected for a VM migration under cooperative cloud computing and discard providers from participating in a Vm migration under competitive cloud computing when the VMs don't belong to their clients. shows the processes involved in workload migration in federated Cloud. The process starts with the allocation of workload to physical machine. The allocation is done in a way that the size of the Cloud resource j (R pn (j)) meets or exceeds the workload i's requirement (D vn (i)). With continuous allocation, the cloud resource j might becomes unable to meet workload requirements equation 1, hence the need to migrate workloads to other viable resources. The monitor -a component of the scheduler handles this process.

Cloud Migration Process
In the competitive federation, the workloads selected for migration are forwarded to the scheduler for re-allocation to other resources. This process is depicted in CSP 1 of Fig. 4. In the co-operative however, the selected workloads are forwarded to the global scheduler for re-allocation into a different cloud resource in the same or different CSP. This is as illustrated on the right of Fig. 4.

Cloud Workload Allocation Models
We have described the allocation of workloads to Cloud resources as a bin packing problem. In this section, we present the five various allocation models considered in this work for "packing" workloads into servers. The models are described as follows: 1. Best-Fit Descending (BFD): BFD is a greedy heuristic algorithm that has been shown to use (11/9 * optimalBins) + 1bins [17]. When applied in Cloud computing, virtual machines (VMs) are considered items to be put in bins while the physical machines (PMs) are considered as the bins. Both the VMs and PMs are of heterogeneous sizes. The allocation speed of BFD can be increased if the PMs are sorted in order of their capacity. In this work only the CPU is considered, thus the PMs are sorted in decreasing order of CPU. This is done to allow for a uniform basis of comparison across all the different workload allocation models compared.
2. First-Fit Descending (FFD): FFD is another variant of the greedy heuristic algorithm but unlike BFD, it assigns VMs to the first PM it finds that can accommodate it. The performance of this algorithm can also be significantly improved if the PMs are sorted in descending order, thus reducing search time for suitable PMs.
3. Binary-Search Best-Fit (BSBF): This is an algorithm proposed in [18], with the main objective of speeding up the PM search time. Rather than the linear PM search used by BFD and FFD, it instead builds a Red-Black Tree (RBT) using PM capacity (available CPU). Being a RBT, in theory it has a worse case search time complexity of log 2 n which is faster than BFD and FFD with complexities of at least n. There is however an additional time required to build and update the RBT which also needs to be taken into consideration. This notwithstanding, BSBF was reported by the authors to still be significantly faster than the other fit algorithms and conserves resources better; hence the reason for considering it in this paper.

Stable Roommate Allocation (SRA):
For this work, the stable roommate algorithm was adapted for application in Cloud workload allocations. The stable roommate is a version of stable marriage wherein one party is allowed to have multiple partners or a room is allowed to have more than one occupant. PMs are taken to represent men/rooms while VMs represent the user workloads to be allocated. Multiple VMs can be assigned to a PM, but a VM can only be assigned to a single PM. In implementing this, and similar to the work of Xu and Li [5], the VM preference list was built by considering PMs with available CPU greater than the VM's, while PM preference is based on VMs requests that a less than the PM's available CPU capacity. Prior to allocation, each room / man proposes to VMs. The VMs do not immediate accept the proposal(s) but adds them to a list of suitors. During the allocation phase, each VM cross references its list of suitors with its preference list and only accepts proposals that best suits it. The process is repeated until all VMs are matched to PMs. In this work, priority is placed on ensuring that all VMs are allocated. Hence it is possible for some PM(s) not to be matched to any VM. In fact this is desirable as it implies better resource utilization and lower energy consumption.  [14,20]. Like in those works, we also followed the classical GA steps described in [19], however our implementation was a bit different. We assumed a PM to be made up of two processing elements (PE). We then took a PM to represent 2 genes and a string of genes (chromosome) to represent a potential VM-PM allocation solution. In encoding our genes, when a PE is potentially allocated to a VM, we set it to 1 and to 0 if otherwise. This is as illustrated in Fig. 6. We performed partial mutation and only changed 0s to 1s. This was because changing a 1 to 0 would require de-allocating all VMs currently assigned to such a PE and then looking for new potential VMs to allocate. Rather than performing a repeated allocations, we created a different chromosome instead. Finally, we took fitness value to imply the number of 0s in the chromosome. Therefore, the chromosome with the highest number of 0s was selected as the best. This translates to a solution which uses the least amount of PMs to serve all VMs.

Results and Discussion
For this work, simulation were carried out using Cloudsim [21] and a data centre similar to that used in [12,16,18,20] was used and consisted of a number of heterogeneous PMs. These PMs were of two categories with specifications and power consumption models based on benchmarked data from real servers [36] and given as follows: category one had 2 CPU cores clocked at 1,860MHz and 4GB of memory, while the second category also had 2 CPU cores each clocked at 2,600MHz and with 4GB of memory.
To model the co-operative federated Cloud: a data centre with a total of 300 PMs was setup in CloudSim. User workloads were executed on any of four types of VMs, viz.: single core @ 2500MHz, single core @ 2000MHz, single core @ 1000MHz and single core @ 500MHz. Data used for this experiment were from anonymized workload traces of 9/25 VMs submitted to a Google cluster and PlanetLab. A total of 168 workload traces were used for each experiment and distributed as follows: 1. To simulate light user demands, the smallest 56 traces from the Google cluster TraceVersion1 [35] were used.
2. For heavy demands, 56 of the largest traces were extracted from PlanetLab dataset of 12th April, 2011 [34] and used.
3. For the medium, the 56 traces used were made up of a mix of large traces from Google cluster and light traces from PlanetLab dataset.
For the competitive federation on the other hand, three data centres were set up to simulate the countries with the most number of DCs as shown in Fig. 1. For a fair and consistent result, we assigned equal number of PMs to the countries, at 100 each. Similar to the co-operative, user workloads were also split into light, medium and heavy and were ran on VMs with similar configuration as those used for the co-operative federation.
In presenting the results, the performance of both federation models under light and heavy workloads were compared, those of medium workloads were omitted in order to conserve space. Seven metrics were considered and the obtained results are presented in the subsequent subsections:

Light Workload
Allocation Delay This is a measure of how long users have to wait before processing begins on their submitted workloads. Two delays are considered in this work, pre-processing delay and average delay. From the figure, the algorithms had varied pre-processing times under the two federation models. BSBF has the longest pre-processing delay for both the co-operative and competitive models at 3,943,250ns and 4,253,600ns respectively. This is due to the extra time spent building the binary search tree. BFD was second, at 1,795,000ns for co-operative and 3,533,900ns for competitive. FFD was the fastest of the three at 509,300ns for co-operative federation and 785,833ns for the competitive. Cumulatively, pre-processing delays were higher in competitive than in the co-operative federation.
2. Average Delay: A measure of the average time taken to allocate a VM to a PM. The results of this is shown in Fig. 8. BFD took the longest time, across both federation models, at 756,459.00ns for co-operative and 1,174,501.67ns for  This significant difference in speed between the algorithms can be attributed to their mode of operation. BFD searches through the entire list of PMs for one that best fits a given workload, while FFD assigns to the first capable PM it finds. The benefit of the binary search tree used by BSBF is most evident here and responsible for the lower delays compared to BFD and almost as fast as FFD. This observation is in line with that reported in [18].

Execution Time
In this paper, execution time is taken to mean the total time spent servicing user workloads. Fig. 9 shows a comparison of execution times of the different allocation schemes for both federation models when light workloads are submitted. For the co-operative federation, BFD resulted in the quickest execution time, this is followed by SRA, FFD, BSBF and finally GAVA. For the competitive federation, SRA and GAVA were the quickest, followed by FFD, BSBF and BFD. It is important to note that these times difference are only in factions of seconds. For all algorithms, workload execution took shorter time to complete in the competitive federation than in the co-operative.

Resource Utilization
The five allocation algorithms were compared to determine how well they utilize resource when allocating workload to PMs. Two results are presented, the first being resource utilization right after allocation and the second being after optimizing the allocation. Optimizing the allocation aims to reduce the number of resources used by consolidating workloads into fewer number of PMs. From the result shown in Figure 10, for both co-operative and competitive federation equal number of resources were used across all but GAVA and SRA. For GAVA, co-operative federation was slightly better with 120 PMs versus 123 in competitive federation; similar results were obtained for SRA with 67 PM for co-operative and 69 for competitive. Across all allocation, BSBF resulted in the best matching of VMs to PMs and utilized only 63 PMs. BFD and FFD followed closely with 66 PMs, while GAVA gave the worst. It must however be noted that, the result is based on a fitness function set to 65% utilization and 200 epochs; a lower fitness function and more epochs might have resulted in lowered values, though at the cost of an even longer training time. Cumulatively, the co-operative federation model was slightly better as it utilized an average of 76 units of resource compared to the 78 used in the competitive federation.  The main purpose for considering the resource utilization after consolidation is to determine how well each algorithm performed in terms of packing workloads into PMs. The lower the change in number of resources utilized between "before consolidation" and "after consolidation", the better the algorithms is at packing.

Energy Conservation
Besides effective resource utilization, conservation of energy is also very vital to CSPs, as there is a global drive to reduce energy consumption and carbon emissions for the 12/25 purpose of a greener earth. Comparisons of the five algorithm with respect to energy conservation for both federation models are shown in Fig. 12 and Fig. 13. Figure 12. Energy consumption before consolidation In Fig. 12, energy consumption levels were almost similar across all algorithms and for both federation model. This is in line with the resource utilization levels shown in Fig. 10. Overall, energy consumption in co-operative federation, were slightly better than that of competitive. Furthermore, BSBF with 34.8KWh conserved energy the most across both federation models. It was followed by BFD and FFD both at 35.4KWh; SRA at 36.9KWh (competitive), 35.9KWh (co-operative). GAVA had the most energy consumption at 67.4KWh and 65.0KWh for competitive and co-operative federated clouds respectively.
Results of energy utilization after consolidation are shown in Fig. 13. From the graph, the co-operative Cloud federation model resulted in higher energy consumption compared to the competitive. This held true for all the five workload allocation schemes.

Quality of Service
This is a measure of the dissatisfaction index of users to the allocation / servicing of their workloads. It is often expressed in form of a Service Level Agreement (SLA). For this work, the SLA metric used was similar to that used in [12,16,18] and many other works. Fig. 14, shows a comparison of the average SLA violation for each of the algorithms and across the two cloud federation models for light user workloads. From the figure, violation percentage remained equal across all the algorithms and federation models. This result might be attributed to the fact that the users' workloads were light weight and similar and that the PMs were more than capable of serving them with minimal SLA violations.

Number of VM Migrations
The last metric considered is the migration count and it is a measure of the number of times, user workloads were moved to different PMs, either for consolidation purposes or to reduce SLA/QoS violations. The results in Fig. 15, shows that user workloads are   Fig. 7, BSBF again had the longest pre-processing delay for both the competitive and co-operative models at 4,611,366.67ns and 3,699,650.00ns respectively. BFD was second, at 2,905,150.00ns for competitive and 1,726,300.00ns for co-operative. FFD was the fastest of the three at 639,500.00ns for the competitive and 579,800.00ns for co-operative federation. Similar to result obtained with the light weight workloads, pre-processing delays were higher in the competitive federation model than in the co-operative model.  Delay Fig. 17, shows that BFD resulted in longest delay at 756,459.00ns for co-operative and 1,299,219.00ns for competitive. FFD was the fastest at 123,338.50ns for the co-operative and 111,508.00ns for competitive. Finally, BSBF was much faster than BFD but not as fast as FFD with 191,440.67ns for the co-operative model and 194,762.00ns for the competitive. As observed with the light weight, workloads experienced lower delays in the co-operative versus the competitive Cloud federation model.

Figure 17. Average workload allocation delay
Execution Time Fig. 18 shows a comparison of execution times of the different allocation schemes for both federation models when heavy workloads are submitted. In both the co-operative and competitive models, BSBF resulted in the quickest execution time and was closely followed by BFD. For the competitive, GAVA was the third fastest, followed by FFD and SRA; while for the co-operative federation, SRA was the third fastest, followed by FFD and GAVA. As stated above, these times difference are only in thousandth of seconds and might not be overly significant in life environments. In general and similar to the light weight workloads, execution took shorter time to complete in the competitive federation than in the co-operative federation.

Resource Utilization
From the result shown in Fig. 19, for both co-operative and competitive federation equal number of resources were used across all but SRA. For SRA, 67 PM were used in the co-operative model compared to 69 in the competitive. Like with the light-weight workloads, across all allocation schemes the BSBF also resulted in the best matching of VMs to PMs and utilized the least number of PMs (66). BFD and FFD came second with 66 PMs, while GAVA utilized 119 PMs. comparatively, the co-operative federation model was slightly better as it utilized an average of 76.2 units of resource compared to the 76.6 used in the competitive federation. Fig. 20 shows the utilization after workload consolidation. BSBF, again resulted in the least utilization for both federation models. BFD's allocation was consolidated to 18    Results of energy utilization after consolidation are shown in Fig. 22. From the graph, it can clearly be seen that for each algorithm, significantly more energy was consumed under the competitive model, than in the co-operative federation model. The only exception was GAVA where the values were closer at 35.31KWh for the competitive model and 35.03KWh in the co-operative.

Figure 22. Energy consumption after consolidation
Quality of Service   Fig. 23, shows a comparison of the average SLA violation for each of the algorithms and across the two cloud federation models, when heavy workloads are considered. All the algorithms performed poorly, with at least 30% workload violation. This was expected as a large proportion of the workloads required resources that could only be provided by the 2,600MHz PMs, in essence reducing the number of useable resources in the data centre by 50%.
BSBF resulted in the least violation of all the algorithms and for both the competitive and co-operative federation at 30.76% and 30.85% respectively. This was followed by GAVA with 35.05% for competitive and 40.62% for co-operative. The other results are as shown in the figure. Overall, workloads experienced higher violation in the co-operative federation versus in the competitive.

Number of VM Migrations
The results in Fig. 24, shows that user workloads are migrated more often in the competitive than in the co-operative federated Cloud than in the competitive.

Summary of Results
Tables 1 and 2 provide a summary of the obtained results in a concise manner. On Table  1, a comparison of the two Cloud federation model is shown with their performances shown for the various metrics considered. From the table, workloads experienced lower delays in the co-operative Cloud federation but slower overall execution time compared to the competitive federation. In terms of resource utilization, the co-operative model was the better option to use for lighter workloads while competitive was best suited for  heavier workloads. When energy consumption is considered, the co-operative federation is better for heavier workloads as it conserves energy better, while the competitive was better for lighter weigh workloads. In terms of providing satisfactory services, the competitive model was better overall, as it resulted in lower QoS violations for heavy workloads, while remaining at par with the co-operative federation for lighter workloads. Table 2 considers the performance of the various allocation schemes across the various metrics, workload types and federation models. From the table, FFD resulted in the shortest delay, followed by BFD and BSBF. This is understandable as BFD seeks through the entire PM list for the best-fit, while BSBF has to create and constantly update its BST during the allocation process. For overall execution time, BFD was the fastest while GAVA was the slowest for the co-operative federation. For the competitive, GAVA was fastest for light weight workloads and BSBF fastest for heavy workloads. With respect to resource utilization both before and after consolidation, BSBF was the most effective and was closely followed by BFD. This can be attributed to both algorithm seeking to allocate workloads to resources that fits the best. Similar trends are observed for energy conservation (before consolidation). For energy conservation (after consolidation), BSBF was better for all but light weigh workloads in the co-operative federation where it was marginally lost to BFD.
Across both federation models, all the allocation schemes gave similar results for the light weight workloads. For the heavy workloads, however, BSBF resulted in the least violation and was followed by GAVA, SRA, FFD and BFD. Finally, in terms of VM migration, for the co-operative federation the SRA economic model resulted in the least number of migration for both heavy and light weight workloads. It performed equally well in the competitive model being only slightly outperformed by BFD. BSBF and GAVA on the other hand resulted in the highest number of migrations.   [37,38] had presented a number of ways in which Cloud computing could be applied to medicine. Some of the application areas included: preservation of medical data, medical training, medical imagery, online billing systems, medical inventory management systems etc. These are services and/or facilities that should be available in all standard medical facilities of repute, however this is not the case for hospitals in developing countries across Africa. As stated in the introductory section of this paper, Cloud federation and collaboration can help improve the quality of medical services in Africa. To put this in perspective and tie it to the models and results presented in this paper thus far, these aforementioned Cloud medical applications can be grouped into heavy and light weight workloads based on our perception of data size and system (resource) requirements. Table 3 shows some potential application areas of Cloud computing in medicine and mappings to corresponding workload category.

Deployment Considerations
In considering new projects, products or process, the SWOT analysis is often used by organizations, as it easily identifies the potential weaknesses and threats. It also sheds light on the unique advantages of their product as well as the potential opportunities they can tap into. In Table 4, the various aspects of the SWOT analysis of Cloud federation for health care in Africa are itemized.
3. Business Models A number of business models for Cloud computing and related technologies have been discussed in [39,40]. This section presents business models that can be applied to Cloud federation based on a number of perspective. These models are shown on Table 5. PaaS -a platform to incorporate multiple systems.

Conclusion
Malnutrition, epidemic diseases and high human mortality rate are a few of the common trends in many African countries. Many of these are associated with the high level of poverty and poor state of infrastructure, especially those related to health. There are however a few countries in Africa with better than average health care facilities and those with world-class ones. Thus an imbalance exist across African nations in terms of health care. A solution to this would be to build world-class hospitals across every cities across the continent, but the cost of this is prohibitively expensive. An alternative solution is to leverage on technology and Cloud computing in particular. Cloud computing has emerged as a computing paradigm that converts computing from a product to a paid service. By leveraging on the Cloud, medical expertise can be "imported" at a comparatively cheaper cost. Amongst the offering of Cloud computing is on-demand access to computing resources, cost savings. These features are however not often achievable by a single Cloud Service Provider (CSP) without adverse effect on service quality which is pertinent to health care. In a bid to achieve these without compromising quality, CSPs have to collaborate and form Cloud federations. Cloud federation across the African continent can prove to be an effective solution to some of the health care infrastructural challenges. In this paper, two Cloud federation models were considered -the co-operative and competitive. Five different Cloud workload allocation schemes -three heuristic based (First-Fit-Descending (FFD), Best-Fit-Descending (BFD) and Binary-Search-Best-Fit (BSBF), one meta-heuristic (Genetic Algorithm (GAVA)) and one economic model (Stable Roommate Allocation (SRA)) to determine their performance and effect on co-operative federation, where participating CSPs work and pool resources together and in competitive federation, where participants utilize their resources independently. Service delay, resource utilization, energy conservation and adherence to Service Level Agreements (SLA) were metrics considered and experimental simulations were conducted on both light and heavy workloads. Obtained results show that the co-operative federation resulted in the least allocation delays and utilized resources better, while the competitive federation was faster in completing user tasks with lower violations on agreed service level. With respect to the allocation algorithms, FFD was the fastest overall, while BSBF was the • Improvement in level of health care services across the African continent.
• Cost savings for patients • Cost savings for the hospitals and country in general • Collaboration and team work between medical practitioners across Africa • Potential reduction in mortality rate in developing countries across Africa • High cost of purchasing and installing communication facilities.
• There is the need to educate / train medical and support staff to use the facilities.
• Human inherent resistance to change.

Opportunities Threats
• Potential for economic growth of African countries.
• State-of-the-art medical and technological facilities • High scalability • Potential to apply machine learning and artificial intelligence to find hidden pattern and improve on medical services.
• Security -a security breach could result in exposure of sensitive patient information.
• Over-reliance on network and communication facilities -an outage or network downtime could be fatal especially in emergency situations or during a surgical procedure.
• Diverse polices and information usage acts across counties.
most effective for resources utilization, energy conservation and service adherence. Finally, this paper presented deployment considerations for federated Cloud for health care across Africa as well as various potential business models. For future works, the effect of cost and penalties associated with SLA violations might be considered as well as a hybrid combination of these algorithms in a bid to find an optimal solution. Also for the most effective network architecture, government policies, and ethical considerations for this trans-national Cloud federation can be looked into. ii. Patients have no way of ensuring that the hospital pays the CSP.