MeFoRE: QoE based Resource Estimation at Fog to ... - IEEE Xplore

2016 23rd International Conference on Telecommunications (ICT)

MeFoRE: QoE based Resource Estimation at Fog to Enhance QoS in IoT Mohammad Aazam, Marc St-Hilaire, Chung-Horng Lung, Ioannis Lambadaris Department of Systems and Computer Engineering Carleton University, Ottawa, Canada [email protected], [email protected], [email protected], [email protected] Abstract— Internet of Things (IoT) is now transitioning from theory to practice. This means that a lot of data will be generated and the management of this data is going to be a big challenge. To transform IoT into reality and build upon realistic and more useful services, better resource management is required at the perception layer. In this regard, Fog computing plays a very vital role. With the advent of Vehicular Ad hoc Networks (VANET) and remote healthcare and monitoring, quick response time and latency minimization are required. However, the receiving nodes have a very fluctuating behavior in resource consumption especially if they are mobile. Fog, a localized cloud placed close to the underlying IoTs, provides the means to cater such issues by analyzing the behavior of the nodes and estimating resources accordingly. Similarly, Service Level Agreement (SLA) management and meeting the Quality of Service (QoS) requirements also become issues. In this paper, we devise a methodology, referred to as MEdia FOg Resource Estimation (MeFoRE), to provide resource estimation on the basis of service give-up ratio, also called Relinquish Rate (RR), and enhance QoS on the basis of previous Quality of Experience (QoE) and Net Promoter Score (NPS) records. The algorithms are implemented using CloudSim and applied on real IoT traces on the basis of Amazon EC2 resource pricing. Index Terms—IoT; Cloud of Things; Fog computing; Edge computing; Amazon EC2; resource management.

I. INTRODUCTION IoT-based services are becoming popular rapidly. The number of connected devices has reached 9 billion and by 2020, they are expected to grow further up to 24 billion [1]. With such rate of increase in the number of heterogeneous devices being part of IoT and generating data, it is not possible anymore for an IoT to efficiently manage the data, power, and bandwidth [2]. Therefore, a lot of service oriented tasks would be performed in the cloud, creating amalgamation of IoT and cloud computing [3]. In this case, a localized micro datacenter would be present close to the underlying nodes for the purpose of offloading the tasks and preprocessing the raw data. That micro datacenter is known as Fog or Edge. Fog also helps in minimizing delays and increase service quality by incorporating better responsiveness, making it inevitable for multimedia streaming and other delay sensitive services. There comes a situation when the cloud is connected with IoT that generates multimedia data. Video on Demand (VoD), Visual Sensor Network or CCTV connected to cloud are examples of such a scenario. Since multimedia content consumes more processing power, storage space, and scheduling resources, it becomes important to manage them effectively to perform efficient resource management in the

978-1-5090-1990-8/16/$31.00 ©2016 IEEE

cloud. Specially, with mobile devices and other IoT nodes which do not have a reliable connectivity behavior, the cost considerably increases when it comes to resource allocation and a lot of resources go underutilized because of unexpected and unreliable behavior of the Cloud Service Customer (CSC). Furthermore, mission critical and latency sensitive IoT services require very quick response and processing. In that case, it is not feasible to communicate through the distant cloud, over the Internet. Fog computing plays a very vital role in this regard [3]. The concept of Fog computing is to bring networking resources near the perception layer. Fog resources lie between the perception layer and the cloud layer. Fog computing is an extension of the traditional cloud computing paradigm to the edge of the network, helping to create more refined and contextaware services [4]. Fog provides low latency and high quality streaming to mobile nodes including moving vehicles through proxies and access points located accordingly, like along highways and tracks. Likewise, resource and power constrained individual nodes, Wireless Sensor Networks (WSNs) and Virtual Sensor Networks (VSNs) would be able to take advantage from the presence of Fogs. Since Fog is localized, it suits the services related to video streaming, emergency and disaster management, gaming, healthcare, augmented reality, graph/data mining [5] etc. In our previous work [6], we proposed a basic mathematical model for resource estimation in Fog. In the current paper, we provide a methodology for historical record-based resource estimation to mitigate resource underutilization as well as enhance service quality for multimedia IoTs. We named it MEdia FOg Resource Estimation (MeFoRE). The contributions of this work are two folds. First, we extend the model to propose resource management of IoTs at Fog on the basis of historical records of CSC, which can help in efficient, effective, and fair management of resources. Second, to enhance QoS, we work on previous QoE records, specifically on the basis of Net Promoter Score (NPS) to allocate resources accordingly in such a way that the required QoS is achieved and reliable service is provided. NPS is a QoE feedback given by the CSC on a scale of 0-10. Where CSCs with 0-6 NPS are known as distractors, 7-8 are passive, and 9-10 are promoters. Therefore, the default case would neither be positive (promoters) or negative (distractors). It would be the mean of passive, which is 7.5. The model presented in this paper has been validated with partial implementation on a real IoT Crawdad trace [7]. In addition to


that, the model is implemented based on the Amazon EC21 pricing to get realistic outcome. Netflix, Dropbox, NASDAQ, iCloud, Bitcasa, etc. all use Amazon’s service for cloud storage. II. RELATED WORK Fog computing is still a very new concept, due to which, there is not a lot of literature available on it. Most of the works still focus mainly on cloud resource management. The scenario of Fog computing or Cloud of Things (CoT) has not been deliberated by most of the past works. Below are a few examples of relevant papers on IoT resource management. Abu-Elkheir et al. [8] elaborate on the organization of data in IoT. The authors indicate how distinctive design parameters would work for management of the data. But how that data and IoT nodes are going to be handled at the cloud layer and how resources are to be managed for the generated data are not part of this study. Cubo et al. [9] present their work on the integration of heterogeneous devices accessible via cloud. The presented work, however, does not deal with the key issue of management of resources for such devices in the cloud. Ning and Wang discuss in [10] the potentials of IoTs and the volume of data it is going to produce. The authors also underscore efficient management of resources for the future Internet, in which heterogeneous IoTs would be a vital part. Chatterjee and Misra [11] provide a mapping of sensors to their respective targets through a sensor-cloud infrastructure. But how every node or sensor is allocated with resources in a dynamic fashion is not part of this study. Sammarco and Iera [12] analyze Constrained Application Protocol (CoAP) for IoTs and discuss service management and method for exploiting resources of IoT nodes. Tei and Gurgen [13] emphasize on the significance of the integration of cloud-IoT. They discuss preliminary outcomes of a project in this domain. In [14], Rakpong et al. consider resource allocation in mobile cloud computing environment. They deliberate on communication/radio resources and computing resources, but their work only focuses on decision making for coalition of resources to increase service provider’s revenue. Distefano et al. [15] contribute in presenting an outline for the integration of the underlying IoT nodes with the cloud. However, the challenge of dynamic and node-based resource management is not a focus of this study. Bonomi et al. [4] present a basic architecture for Fog computing, which does not include its practical implications and resource management for IoTs. Similarly, Stolfo et al. [16] present data protection through Fog computing, but do not discuss resource management and associated matters. III.

MEFORE MODEL

The underlying IoT nodes, whether they are part of a VANET, an emergency or rescue related ad hoc network, online gaming, or VoD, CSCs contact the relevant Fog to get the required service. Fog performs SLA negotiation with the CSCs. Fog is responsible to provide the best possible service to the CSCs but also has to ensure that resources are not underutilized. In this regard, Fog looks for the reliability in the resource consumption by the CSCs. Hence, Fog estimates resources 1 http://aws.amazon.com/ec2

according to the previous service relinquish records as well as the QoE (NPS in this model). Resources are increased whenever the SLA was not met in the previous case so that better service is provided and CSC's loyalty is gained. Resource estimation is done in the following way: ∑

+ (Ʋ ∗ (

ℜ= ∑ ∑

) ∗ (Ѻ )),

−

=0

) ∗ (1 − x¯ Ѻ )),

+ (Ʋ ∗ (

−

∑

+ (Ʋ ∗ ѡ) ∗ (1 − x¯ Ѻ ))

(

=0 (1)

( | )) −

ѡ = (1 − x¯ ( ℜ∊{

,

,

,

∑

⎧ ⎪ ⎪ =

, ,

∑

⎨∑ ⎪ ⎪∑ ⎩

,

=0

x¯

>

,

x¯

≥ x¯

∑

,

x¯

≥ x¯

−

( | ) =

x¯ (∑ 0.3

=

ℎ}

∑

=

∗∑

(

(2)

(3)

(4) ( | ))

− x¯ )

> 0, =0

(5) (6)

Where ℜ represents the required resources, is the ) and NPS ratio generated on the basis of the overall NPS ( currently requesting CSC’s recorded NPS ( ). Ʋ is the basic price of the requested service. is the default RR, which is applied on a new CSC when previous RR does not exist. Its value is 0.3, which is the average of low relinquish probability (0.1 to 0.5, from the complete range of 0-1). ѡ is the loyalty ratio which comes from the Service oriented Relinquish rate (SR) of a particular customer of giving up the same resource that is being currently requested, subtracted by variance. x¯ ( ( | ) ), which is the average SR, has its value between 01. has four cases as presented in (3). In case 1, when the CSC is new and no previous NPS record exists, then default NPS ( ) is applied, which is 7.5. However, there is a possibility that the currently required service may have a better ) than the default value (7.5). In that case, overall NPS ( more priority is given to the overall NPS since it is opined by more users. This is where case 2 is applied. In case 3, when , which is the NPS given by CSC for number of occasions, is available and greater than the overall NPS, then it has a higher priority because it would eventually lead to increase the overall NPS of the service and attains CSC’s


loyalty. Case 4 is applied for all other scenarios. All types of represents NPS’ are calculated through (4), in which promotors and represents distractors.

Ѻ =

x¯ (x¯ (∑ 0.3

0 < ≤ 0.5 , 0.5 < ≤ 1 (7) ( | ) )), ( | ) ) > 0, (8) =0

( | ) represents RR for a particular service for number of recorded occasions. For a service being requested for the first time with no previous records, the is the variance of the SR. default value of 0.3 is applied. CSCs, especially mobile users, can have a fluctuating behavior in utilizing resources, which may lead to deception while making judgement about resource allocation. That is why, in our model, we have taken into account variance of RR, which helps determining the actual behavior of each customer. Ѻ represents the Overall Relinquish rate (OR), not specific to any particular service. Here, it should be noted that ( | ) determines the RR of the particular service that the customer is currently requesting, while Ѻ is the RR which includes all the activities/services a particular customer has been doing/requesting. The last activity of the user in this regard tells about his most recent RR. That is why, it is given more importance and the average is taken again. In case of a new customer, when there is no historical data for that user, the default value is set to a low RR of 0.3. IV.

SETUP, IMPLICATIONS, AND OUTCOME

In this section, we present the implementation results of our service model, along with the discussion on each result. We defined our service model through algorithms to evaluate the effectiveness in CoT business. Our main objective is to observe the influence of the performance factors on the system and test the feasibility of our method on the basis of actual Crawdad trace [7] which was partially applicable for RR through the link strength and quality parameters such as the Received Signal Strength Indicator (RSSI) and the Link Quality Indicator (LQI). RSSI is a measure of Radio Frequency (RF) power of the channel, coming from WiFi, Bluetooth, or other IEEE 802.15.4 transmitters. LQI determines the quality of the link. It is a cumulative value used in multi-hop networks. Especially for Personal Area Networks (PANs) and WSNs, such measure is deemed important where the user is mobile and link quality fluctuates. We have used the QoS measures from the trace in our model as well, other than the user generated feedback, which was generated through Random Number Generator (RNG) algorithm. Degradation in quality becomes a reason for service relinquishing. Crawdad’s trace is a packet delivery performance over an 802.15.4 link under different stack parameter configurations for more than 6 months. “The data set consists of measurements of the data delivery performance of a WSN link with nearly 200 million packets in the data set” [7].

We have considered different parameters to estimate the required resources for different types of users. TABLE I shows the setting for the basic parameters. TABLE I: KEY PARAMETERS’ SETTING FOR EVALUATION Parameters Range 0.3 Default SR ( ) 0.3 Default OR (Ѻ ) 7.5 Default NPS ( ) 0~1 Relinquish rate (P) Service price (Ʋ ) USD 85.3 ~ USD 1000 Variance range 0 ~ 0.16 Minimum VRV 3.89

A. Resource Estimation for New CSCs When different CSCs with diverse behaviors make a request for a service, the Fog has to decide the amount of resources that has to be allocated for that service, based on the previous records of service utilization, QoS, and QoE. CSCs with more loyal behavior get more resources. Similarly, CSCs who experienced bad QoS previously would be allocated with more resources, so that loyalty of such CSCs is gained and more reliable and profitable business process is maintained. For new customers (i.e. the Fog has no past record for them), the default RR value (0.3) is applied. This is done by anticipating the new CSC to be somewhat reliable. Considering the fact that datacenter resources are precious, therefore not all the possible resources are assigned to an unknown new CSC. Instead, the default rate is applied, which is the average of low RR, as explained earlier with the model. Fig. 1 presents the unit of estimated resources, termed as Virtual Resource Value (VRV) in our model. The resources are estimated according to different services. The actual mapping of VRV is done by the Cloud Service Provider (CSP) keeping in view the type of service and the amount of resources required accordingly. The first instance of CSC requesting for Amazon EC2 service priced at USD 85.3 gets VRV 8 without considering QoE or NPS. Since the CSCs are new here and they have never provided any NPS before for this service, the overall NPS ( ) is applied (given in TABLE II) with the default value (7.5). This way, additional resources are estimated as the value of VRVNPS is 10. Same is the case with the other instances. This is how the proposed algorithm works on the basis of previous RR, NPS, and QoS and eventually service quality is enhanced and SLA violation is mitigated.

Figure 1. Resource estimation for new CSCs, for different Amazon EC2 services.


Service NPSo

TABLE II: OVERALL NPS FOR NEW CSC CASE. 1 2 3 4 5 6 4 7 4 9 5 6

7 3

TABLE III shows an illustrative scenario of how mapping can be performed by the CSP, according to its resource pool and the type of service being provided. For a VoD service, S1, VRV 8 is mapped to corresponding Resource Pool Level (RPL). VRV 8 8 16

previous estimation of 23.03 VRV. Similarly, considering CSC 6, where NPS is 1 (~worst), the estimated resources are increased with a higher ratio (10.24 to 17.24). Here, it should also be noted that CSCs' previous RR also has an effect on the resource estimation. More reliable customers get more resources.

TABLE III: ILLUSTRATIVE SCENARIO OF VRV MAPPING. RPL Service Resource Pool CPU: 10%, GPU: 12%, Memory: 15%, L1 S1: VoD Storage: 0%, Bandwidth: 200Kbps Guarantee: 70% S2: CPU: 8%, GPU: 6%, Memory: 8% L1 Storage: 12%, Bandwidth: 100Kbps HealthMo Guarantee: 80% nitoring CPU: 20%, GPU: 24%, Memory: 30% L2 S1: VoD Storage: 0%, Bandwidth: 400Kbps Guarantee: 85%

Then, according to the type of service being provided, the mapping is performed to the actual resource pool. Among the available resources for service 1, CSP allocates 10% of CPU, 12% of GPU, 15% of memory, and data rate of 200Kbps. Storage is not required for this service, therefore, it is 0%. The guarantee of allocation of these resources is 70%, which means that at least 70% of the resources are guaranteed. Resources are increased or decreased accordingly as per the requirements of the service. This is only an example. This mapping would vary according to the type of service and available resource pool at the CSP. B. Resource Estimation for an Existing CSCs, Requiring Service (Amazon EC2 $85.3, 1X800 SSD) In the case when CSC is returning and its previous record exists but requiring service S for the first time, then the Fog can make use of the available overall record. This way, a more customized resource allocation can be made possible. But there is a possibility that the NPS given by this CSC for the current service is lower than the overall NPS, which is given by the rest of the customers. In this case, since the majority of users have a better experience with this service, more priority is given to that so that biasness is avoided. Case 3 of (3) is applied here. We have also used automatic NPS in this analysis, which we get from our Crawdad trace (RSSI and LQI) based on software agent’s feedback, residing in the recipient’s device. Otherwise, the CSCs will always give low NPS to get more resources next time. In this scenario, NPSo was fixed at 7. Here the result is presented for the Amazon EC2 1X800 SSD storage service, priced at USD 85.3 per 100 hours. The unit is greater for loyal (L) customers, while it is smaller for disloyal (H) customers, because of their behavior. Since there are more chances of an H customer to relinquish the service, hence, more priority and quality is provided to the more loyal customer, having low RR. Fig. 2 shows the estimation of resources on the basis of OR, keeping SR to default 0.3. In case of CSC 1, OR is 0.1, which means the customer is very loyal. In this case, the previous overall NPS is fixed at 7, which means that more resources would be required this time to enhance the QoS. Hence, VRVNPS is 24.03, which is increased as compared to the

Figure 2. Res. estim. for existing CSC with variable NPSc and fixed NPSo.

C. Resource Estimation when > Continuing the previous case with the other scenario when NPSc is higher than NPSo, resource estimation is different. Case 4 of (2) is applied here. NPSo is fixed at 6 in this case.

Figure 3. Res. estim. for existing CSC when NPSc is higher than NPSo.

In Fig. 3, CSC 1 has OR=0.1 and NPSc=7. This means that better resource provisioning is required this time to enhance the quality and meet the SLA. VRVNPS is 24.2. Since the CSC has given better NPS as compared to the rest of the customers (NPSo) which was 6, therefore, it is important to keep the loyalty and provide better service this time. This will positively affect the NPSo and eventually more customers are attracted towards the service because of being popular and better in quality. Comparing CSC 1 with CSC 3, both having the same NPSc, but still different VRVNPS, because of having different RR. More reliable customers get more resources. This way, the resource allocation is done keeping in view NPSo, NPSc, SR, and OR.


D. Resource Estimation with Variable OR Variance As mentioned earlier, the service RR is very fluctuating in the case of IoT devices and mobile nodes. Due to this, the variance in OR is also included in the user characteristics while determining resources. Similarly, the NPSr, which comes from NPSo and NPSc, also has its impact on the amount of estimated resources. NPSr of 1 means that NPSc and NPSo are the same. The higher the value of NPSr above 1, the bigger the difference between the experiences of customers. Specifically, this would be more important when NPSc is lower than NPSo, since it means that the current CSC had a bad experience of the service before and gaining its loyalty is important now to enhance the overall impact of the service. This section presents the effect of the variability in OR variance (TABLE IV) as well as NPSr. In this part, in Fig. 4, comparing CSC 1 with 3 (where CSC 3 has an unreliable OR of 0.7), we can clearly see that CSC 3 gets significantly less resources. Similarly, CSC 1 and 2 do not have a big difference in their respective reliability behaviors and therefore get slightly different amount of resources on the basis of their previous QoE. Thus, NPSr is having its effect here. CSC

1

Variance

0.16

TABLE IV: VARIANCE IN OR. 2 3 0.013

0.0033

4

5

0.04

0.053

delay sensitive services, QoS has also been included in this work. We have made use of automatic and user provided QoE in the form of NPS to enhance QoS and incorporate more reliable service delivery. The presented method helps determine resources according to the behavior and historical record of the customer as well as the required service quality, minimizing resource underutilization and enhancing QoS. The implementation is based on real IoT traces and Amazon EC2 service. REFERENCES [1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9] [10] Figure 4. Effect of variance on overall resource estimation.

V. CONCLUSION AND FUTURE WORK Rapidly increasing IoT-based services have triggered the need for more sophisticated ways to handle heterogeneous devices, fluctuating connectivity, and data generating behaviors. Energy and resource constrained IoT nodes require their computation tasks to be offloaded. Furthermore, healthcare, emergency, and multimedia services require quick response with minimum latency. With IoT-Cloud communications, it becomes difficult to achieve that, having cloud reachable through a shared, unreliable core network. Fog computing provides the solution by bringing cloud resources to the edge of the underlying IoTs and other end nodes. However, with heterogeneous devices being part of IoTs, it is difficult to predict how much resources will be consumed and whether the requesting nodes, devices, or sensors are going to fully utilize the resources they have requested. Due to this uncertainty, the probability of resource utilization is incorporated while performing resource estimation. Moreover, since the focus is on

[11]

[12] [13]

[14]

[15]

[16]

Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M., Internet of Things (IoT): A vision, architectural elements, and future directions. Future Generation Computer Systems, 29(7), 1645-1660, 2013. Shaukat, U., Ahmed, E., Anwar, Z., & Xia, F. Cloudlet deployment in local wireless networks: Motivation, architectures, applications, and open challenges. Journal of Network and Computer Applications, 62, 18-40, 2016. Aazam, M., & Huh, E. N. Fog computing and smart gateway based communication for cloud of things. In Future Internet of Things and Cloud (FiCloud), 2014 International Conference on, 464-470, IEEE, August 2014. Bonomi, F., Milito, R., Zhu, J., & Addepalli, S. Fog computing and its role in the internet of things. In Proceedings of the first edition of the MCC workshop on Mobile cloud computing, 13-16, ACM, August 2012. Nawaz, W., Khan, K. U., Lee, Y. K., & Lee, S., Intra graph clustering using collaborative similarity measure. Distributed and Parallel Databases, 33(4), 583-603, 2015. Aazam, M., & Huh, E. N., Dynamic resource provisioning through Fog micro datacenter. In Pervasive Computing and Communication Workshops (PerCom Workshops), 2015 IEEE International Conference on, pp. 105-110. IEEE, March 2015. Songwei F., Yan Z., CRAWDAD dataset due/packet̻delivery (v. 2015̻04̻01), traceset: packet̻metadata, downloaded from http://crawdad.org/due/packet̻delivery/20150401/packet̻metadata, doi:10.15783/C7NP4Z, April 2015. Abu-Elkheir, M., Hayajneh, M., & Ali, N. A. Data management for the internet of things: Design primitives and solution. Sensors, 13(11), 15582-15612, 2013. Cubo, J., Nieto, A., & Pimentel, E., A cloud-based Internet of Things platform for ambient assisted living. Sensors, 14(8), 14070-14105, 2014. Ning, H., & Wang, Z., Future internet of things architecture: like mankind neural system or social organization framework? Communications Letters, IEEE, 15(4), 461-463, 2011. Chatterjee, S., & Misra, S., Target tracking using sensor-cloud: Sensortarget mapping in presence of overlapping coverage. Communications Letters, IEEE, 18(8), 1435-1438, 2014. Sammarco, C., & Iera, A., Improving service management in the internet of things. Sensors, 12(9), 11888-11909, 2014. Tei, K., & Gurgen, L., Clout: Cloud of things for empowering the citizen clout in smart cities. In Internet of Things (WF-IoT), 2014 IEEE World Forum on, 369-370, IEEE, March 2014. Kaewpuang, R., Niyato, D., Wang, P., & Hossain, E., A framework for cooperative resource management in mobile cloud computing. Selected Areas in Communications, IEEE Journal on, 31(12), 2685-2700, 2013. Distefano, S., Merlino, G., & Puliafito, A., Enabling the cloud of things. In Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), 2012 Sixth International Conference on, 858-863, IEEE, July 2012. Stolfo, S. J., Salem, M. B., & Keromytis, A. D., Fog computing: Mitigating insider data theft attacks in the cloud. In Security and Privacy Workshops (SPW), 2012 IEEE Symposium on, 125-128, IEEE, May 2012.