Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Improving sensor-cloud : energy efficiency, security, sensory data transmission, and quality of service Zhu, Chunsheng 2016

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2016_september_zhu_chunsheng.pdf [ 2.25MB ]
Metadata
JSON: 24-1.0305686.json
JSON-LD: 24-1.0305686-ld.json
RDF/XML (Pretty): 24-1.0305686-rdf.xml
RDF/JSON: 24-1.0305686-rdf.json
Turtle: 24-1.0305686-turtle.txt
N-Triples: 24-1.0305686-rdf-ntriples.txt
Original Record: 24-1.0305686-source.json
Full Text
24-1.0305686-fulltext.txt
Citation
24-1.0305686.ris

Full Text

Improving Sensor-Cloud: EnergyEfficiency, Security, Sensory DataTransmission, and Quality of ServicebyChunsheng ZhuB.E., Dalian University of Technology, 2010M.Sc., St. Francis Xavier University, 2012A THESIS SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFDOCTOR OF PHILOSOPHYinThe Faculty of Graduate and Postdoctoral Studies(Electrical and Computer Engineering)THE UNIVERSITY OF BRITISH COLUMBIA(Vancouver)June 2016c© Chunsheng Zhu 2016AbstractRecently, induced by incorporating 1) the ubiquitous data gathering capabilities of wireless sensor net-works (WSNs) as well as 2) the powerful data storage and data processing abilities of cloud computing(CC), Sensor-Cloud is attracting growing attention from both academia and industry. However, Sensor-Cloud is still in its infancy and a lot of research efforts are expected to emerge in this area.Improving Sensor-Cloud, this thesis first presents the important research issues that are yet to bewidely investigated by other researchers regarding the energy efficiency, security, sensory data transmissionand quality of service (QoS) of Sensor-Cloud, respectively. Further, our accomplished work regardingsolving the identified research issues is described.Particularly, two collaborative location-based sleep scheduling (CLSS) schemes are designed. Basedon the locations of mobile users, CLSS dynamically determines the awake or asleep status of each sensornode to reduce energy consumption of the WSN integrated with mobile cloud. An authenticated trustand reputation calculation and management (ATRCM) system is introduced. ATRCM considers i) theauthenticity of cloud service provider (CSP) and sensor network provider (SNP); ii) the attribute require-ment of cloud service user (CSU) and CSP; iii) the cost, trust, and reputation of the service of CSP andSNP. A mechanism named TPSS is shown. TPSS consists of two main parts: 1) time and priority-basedselective data transmission (TPSDT) for WSN gateway to selectively transmit sensory data to the cloudiiAbstractand 2) priority-based sleep scheduling (PSS) algorithm for WSN to save energy consumption. Trust-Assisted Sensor-Cloud (TASC) is exhibited. In TASC, the sensory data is gathered and transmitted tocloud, by the trusted sensors (i.e., sensors which own trust values surpassing a threshold) in WSN. Thesensory data is stored, processed and on demand delivered to users, by the trusted data centers (i.e., datacenters which own trust values surpassing a threshold) in cloud.The analytical and experimental results conducted in our work show that the proposed approachescan effectively alleviate the corresponding research issues, respectively. We hope our work can attractmore research into Sensor-Cloud to make it develop faster and better.iiiPrefaceAbout this thesis, there are a number of related publications as listed below. Chapter 2 is related to J1and C1. Chapter 3 is related to J2 and C2. Chapter 4 is related to J3. Chapter 5 is related to J4 andC3. Chapter 1 and Chapter 6 are fully or partially related to all the listed publications.With respect to all the listed publications, I am the principal contributor, regarding the neededdevotion (reviewing related work, identifying research issues, proposing solutions, performing analysis,conducting evaluations, writing manuscripts). The contributions of my co-authors are shown as follows.My supervisor (i.e., Prof. Victor C. M. Leung), supervised all the listed publications as well as improvedtheir writing. Dr. Hasen Nicanfar who was a PhD Student at The University of British Columbia, assistedme in revising J2, based on reviewers’ comments about authentication and system security analysis. Dr.Zhengguo Sheng who was a Postdoctoral Fellow at The University of British Columbia, assisted me inanalyzing the research issues in J3. Mr. Xiuhua Li who is a PhD Student at The University of BritishColumbia, assisted me in performing the mathematical analysis in J4, J5 and C7. Mr. Hai Wang who isa PhD Student at Toyota Technological Institute at Chicago in United States, assisted me in conductingthe evaluations in J6, C5 and C6. The remaining co-authors (i.e., Prof. Laurence T. Yang, Prof. Lei Shu,Prof. Edith C.-H. Ngai, Prof. Joel J. P. C. Rodrigues, Prof. Takahiro Hara, Prof. Shojiro Nishio, Prof.Lei Wang, Prof. Wenxiang Li, Prof. Wei Chen, Prof. Hong Ji, Prof. Xi Li, Dr. Xiping Hu, Mr. XiulongivPrefaceLiu), helped me by providing suggestions about the introduction sections of the related publications.Publications related to Chapter 1, Chapter 2 and Chapter 6J1: Chunsheng Zhu, Victor C. M. Leung, Laurence T. Yang, and Lei Shu, “Collaborative Location-based Sleep Scheduling for Wireless Sensor Networks Integrated with Mobile Cloud Computing,”IEEE Transactions on Computers, vol. 64, no. 7, pp. 1844-1856, Jul. 2015. (One of the populararticles published in IEEE Transactions on Computers for Dec. 2015)C1: Chunsheng Zhu, Victor C. M. Leung, Laurence T. Yang, Xiping Hu, and Lei Shu, “CollaborativeLocation-based Sleep Scheduling to Integrate Wireless Sensor Networks with Mobile Cloud Com-puting,” in Proc. IEEE Global Communications Conference Workshops (GLOBECOM WKSHPS),2013, pp. 452-457.Publications related to Chapter 1, Chapter 3 and Chapter 6J2: Chunsheng Zhu, Hasen Nicanfar, Victor C. M. Leung, and Laurence T. Yang, “An AuthenticatedTrust and Reputation Calculation and Management System for Cloud and Sensor Networks Inte-gration,” IEEE Transactions on Information Forensics and Security, vol. 10, no. 1, pp. 118-131,Jan. 2015.C2: Chunsheng Zhu, Hasen Nicanfar, Victor C. M. Leung, Wenxiang Li, and Laurence T. Yang, “ATrust and Reputation Management System for Cloud and Sensor Networks Integration,” in Proc.IEEE International Conference on Communications (ICC), 2014, pp. 557-562.vPrefacePublications related to Chapter 1, Chapter 4 and Chapter 6J3: Chunsheng Zhu, Zhengguo Sheng, Victor C. M. Leung, Lei Shu, and Laurence T. Yang, “TowardsOffering More Useful Data Reliably to Mobile Cloud from Wireless Sensor Network,” IEEE Trans-actions on Emerging Topics in Computing, vol. 3, no. 1, pp. 84-94, Mar. 2015. (One of the populararticles published in IEEE Transactions on Emerging Topics in Computing for Dec. 2015)Publications related to Chapter 1, Chapter 5 and Chapter 6J4: Chunsheng Zhu, Xiuhua Li, Victor C. M. Leung, Laurence T. Yang, and Lei Shu, “Towards TrustableSensor-Cloud: Trust-Assisted Sensor-Cloud,” To be submitted to a journal in IEEE Transactions,13 pages, double column, 2016.C3: Chunsheng Zhu, Victor C. M. Leung, Laurence T. Yang, Lei Shu, Joel J. P. C. Rodrigues, and XiuhuaLi, “Trust Assistance in Sensor-Cloud,” in Proc. IEEE Conference on Computer CommunicationsWorkshops (INFOCOM WKSHPS), 2015, pp. 342-347.Publications partially related to Chapter 1 and Chapter 6J5: Chunsheng Zhu, Xiuhua Li, Victor C. M. Leung, Laurence T. Yang, Edith C.-H. Ngai, and Lei Shu,“Towards Pricing for Sensor-Cloud,” Submitted to a journal in IEEE Transactions, 12 pages, doublecolumn, Nov. 2015.J6: Chunsheng Zhu, Hai Wang, Xiulong Liu, Lei Shu, Laurence T. Yang, and Victor C. M. Leung,“A Novel Sensory Data Processing Framework to Integrate Sensor Networks With Mobile Cloud,”Accepted for publication in IEEE Systems Journal, 12 pages, double column, Jan. 2014.viPrefaceJ7: Chunsheng Zhu, Victor C. M. Leung, Lei Shu, and Edith C.-H. Ngai, “Green Internet of Things forSmart World,” IEEE Access, vol. 3, pp. 2151-2162, Nov. 2015. (Invited paper) (One of the populararticles published in IEEE Access/IEEE Xplore for Dec. 2015)J8: Chunsheng Zhu, Laurence T. Yang, Lei Shu, Victor C. M. Leung, Takahiro Hara, and ShojiroNishio, “Insights of Top-k Query in Duty-Cycled Wireless Sensor Networks,” IEEE Transactionson Industrial Electronics, vol. 62, no. 2, pp. 1317-1328, Feb. 2015. (Nominated by IEEE IndustrialElectronics Society Technology News in Jul. 2015 issue)J9: Chunsheng Zhu, Laurence T. Yang, Lei Shu, Victor C. M. Leung, Joel J. P. C. Rodrigues, and LeiWang, “Sleep Scheduling for Geographic Routing in Duty-Cycled Mobile Sensor Networks,” IEEETransactions on Industrial Electronics, vol. 61, no. 11, pp. 6346-6355, Nov. 2014.L1: Chunsheng Zhu, Lei Shu, Xiping Hu, Laurence T. Yang, and Victor C. M. Leung, “Review of CKNbased Sleep Scheduling in Duty-Cycled Wireless Sensor Network,” IEEE CommSoft E-letters, vol.1, no. 2, pp. 5-9, Dec. 2012. (Invited paper)C4: Chunsheng Zhu, Victor C. M. Leung, Xiping Hu, Lei Shu, and Laurence T. Yang, “A Review ofKey Issues that Concern the Feasibility of Mobile Cloud Computing,” in Proc. IEEE InternationalConference on Cyber, Physical and Social Computing (CPSCom), 2013, pp. 769-776.C5: Chunsheng Zhu, Victor C. M. Leung, Hai Wang, Wei Chen, and Xiulong Liu, “Providing DesirableData to Users when Integrating Wireless Sensor Networks with Mobile Cloud,” in Proc. IEEE5th International Conference on Cloud Computing Technology and Science (CloudCom), 2013, pp.607-614.viiPrefaceC6: Chunsheng Zhu, Hai Wang, Victor C. M. Leung, Lei Shu, and Laurence T. Yang, “An Evaluation ofUser Importance When Integrating Social Networks and Mobile Cloud Computing,” in Proc. IEEEGlobal Communications Conference (GLOBECOM), 2014, pp. 2935-2940.C7: Chunsheng Zhu, Xiuhua Li, Victor C. M. Leung, Xiping Hu, and Laurence T. Yang, “Job Schedulingfor Cloud Computing Integrated with Wireless Sensor Network,” in Proc. IEEE 6th InternationalConference on Cloud Computing Technology and Science (CloudCom), 2014, pp. 62-69.C8: Chunsheng Zhu, Victor C. M. Leung, Edith C.-H. Ngai, Laurence T. Yang, Lei Shu, and XiuhuaLi, “Pricing Models for Sensor-Cloud,” in Proc. IEEE 7th International Conference on CloudComputing Technology and Science (CloudCom), 2015, pp. 454-457.C9: Chunsheng Zhu, Xi Li, Hong Ji, and Victor C. M. Leung, “Towards Integration of Wireless SensorNetworks and Cloud Computing,” in Proc. IEEE 7th International Conference on Cloud ComputingTechnology and Science (CloudCom), 2015, pp. 491-494.viiiTable of ContentsAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iiPreface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivTable of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ixList of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvList of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiGlossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiiDedication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2ixTable of Contents1.1.3 Sensor-Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1 Improving the Performance of WSN with Cloud . . . . . . . . . . . . . . . . . . . 51.2.2 Better Utilizing the Sensory Data of WSN with Cloud . . . . . . . . . . . . . . . 61.3 Research Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.1 Research Issues about Energy Efficiency of Sensor-Cloud . . . . . . . . . . . . . . 71.3.2 Research Issues about Security of Sensor-Cloud . . . . . . . . . . . . . . . . . . . 81.3.3 Research Issues about Sensory Data Transmission of Sensor-Cloud . . . . . . . . . 81.3.4 Research Issues about QoS of Sensor-Cloud . . . . . . . . . . . . . . . . . . . . . . 91.4 Contributions of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5 Organization of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Collaborative Location-based Sleep Scheduling for Wireless Sensor Networks Inte-grated with Mobile Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1 MCC-WSN Integration Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.1 Overall System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.2 Overall WSN Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3 WSN Energy Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.4 WSN Event Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Proposed CLSS Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.1 Mobile User Location List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.2 CLSS Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Theoretical Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22xTable of Contents2.3.1 Time Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.3 Network Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.4 Network Work Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.5 Comparison of CLSS1 and CLSS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.6 Theorems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4 Numerical Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.1 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.2 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 An Authenticated Trust and Reputation Calculation and Management System forCloud and Sensor Networks Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP andSNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.1 Authentication of CSP and SNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2.2 Preliminaries of SLA and PLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.2.3 Preliminaries of Trust and Reputation . . . . . . . . . . . . . . . . . . . . . . . . . 493.2.4 Preliminaries of TCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.2.5 Trust of Service of CSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2.6 Reputation of Service of CSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53xiTable of Contents3.2.7 Trust of Service of SNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.2.8 Reputation of Service of SNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3 Proposed ATRCM System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.3.2 Authentication Flowchart of CSP and SNP . . . . . . . . . . . . . . . . . . . . . . 583.3.3 Trust and Reputation Calculation and Management Flowchart between CSU andCSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.3.4 Trust and Reputation Calculation and Management Flowchart between CSP andSNPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4 Evaluation of System Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.4.1 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.4.2 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633.5 Analysis of System Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.5.1 First Adversary Model: Good Mouthing and Bad Mouthing Attacks . . . . . . . . 713.5.2 Second Adversary Model: Collusion Attack . . . . . . . . . . . . . . . . . . . . . . 723.5.3 Third Adversary Model: White-Washing Attack . . . . . . . . . . . . . . . . . . . 744 Towards Offering More Useful Data Reliably to Mobile Cloud from Wireless SensorNetwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.1 Usefulness of Sensory Data and Reliability of WSN . . . . . . . . . . . . . . . . . . . . . 764.1.1 Usefulness of Sensory Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.1.2 Reliability of WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.2 WSN-MCC Integration System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79xiiTable of Contents4.3 TPSDT and PSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3.1 TPSDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.3.2 PSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.4 Proposed TPSS Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.4.2 Scheme Characteristics and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 874.5 Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.5.1 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.5.2 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935 Trust-Assisted Sensor-Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.2 Proposed TASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.2.1 Preliminaries about Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.2.2 Overview of TASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.2.3 Trust-Assisted WSN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.2.4 Trust-Assisted Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 995.3 Trust Values Computation, ITASC & CTASC & MTASC . . . . . . . . . . . . . . . . . . 1015.3.1 Trust Values of Sensor Nodes and Data Centers . . . . . . . . . . . . . . . . . . . 1015.3.2 ITASC, CTASC and MTASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045.4 Analysis of TASC and SCWTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.4.1 General Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.4.2 Throughput and Response Time of SC . . . . . . . . . . . . . . . . . . . . . . . . 108xiiiTable of Contents5.4.3 Paths in SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.4.4 Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.5 Numerical Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.5.1 Evaluation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.5.2 Evaluation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156 Conclusions and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125xivList of Tables2.1 Main notation definitions in Chapter 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Main notation definitions continued in Chapter 2 . . . . . . . . . . . . . . . . . . . . . . . 162.3 Evaluation parameters in Chapter 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1 Main notation definitions in Chapter 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2 Main notation definitions continued in Chapter 3 . . . . . . . . . . . . . . . . . . . . . . . 453.3 Authentication flowchart of CSP and SNP . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4 Trust and reputation calculation and management flowchart between CSU and CSPs . . . 573.5 Trust and reputation calculation and management flowchart between CSP and SNPs . . . 583.6 Parameters of CSUs and qualified CSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.7 Parameters of qualified CSPs and SNPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.8 Weight set 1 of CSUs and corresponding choices . . . . . . . . . . . . . . . . . . . . . . . 663.9 Weight set 1 of qualified CSPs and corresponding choices . . . . . . . . . . . . . . . . . . 673.10 Weight set 2 of CSUs and corresponding choices . . . . . . . . . . . . . . . . . . . . . . . 673.11 Weight set 2 of qualified CSPs and corresponding choices . . . . . . . . . . . . . . . . . . 674.1 Example of point vs time & priority (PTP) table . . . . . . . . . . . . . . . . . . . . . . . 80xvList of Tables4.2 Evaluation parameters in Chapter 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.1 Features of proposed TASCs (i.e., ITASC, CTASC and MTASC) . . . . . . . . . . . . . . 104xviList of Figures1.1 Examples of Sensor-Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1 Example of time line of always on (AO) scheme . . . . . . . . . . . . . . . . . . . . . . . . 222.2 Example of time line of CLSS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 Example of time line of CLSS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4 Access behavior of mobile user 1 (a), mobile user 2 (b) and mobile user 3 (c) . . . . . . . 372.5 Theoretical analysis: network lifetime of CLSS1, CLSS2 and AO schemes for mobile user 1(a), mobile user 2 (b) and mobile user 3 (c); network work rate of CLSS1, CLSS2 and AOschemes for mobile user 1 (d), mobile user 2 (e) and mobile user 3 (f). Both CLSS1 andCLSS2 have longer network lifetime than AO. CLSS1 has lower network work rate thanAO and CLSS2 has the same network work rate as AO. CLSS1 has longer network lifetimeand lower network work rate than CLSS2. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39xviiList of Figures2.6 Simulation analysis: network lifetime of CLSS1, CLSS2 and AO schemes for mobile user 1(a), mobile user 2 (b) and mobile user 3 (c); network work rate of CLSS1, CLSS2 and AOschemes for mobile user 1 (d), mobile user 2 (e) and mobile user 3 (f). Both CLSS1 andCLSS2 own longer network lifetime than AO. CLSS1 achieves lower network work rate thanAO and CLSS2 achieves the same network work rate as AO. CLSS1 owns larger networklifetime and lower network work rate than CLSS2. . . . . . . . . . . . . . . . . . . . . . . 403.1 Different weight set for a CSU and corresponding choice about CSP . . . . . . . . . . . . 693.2 Different weight set for a qualified CSP and corresponding choice about SNP . . . . . . . 704.1 Proposed TPSS scheme to gather and transmit sensory data for WSN-MCC integration . 864.2 General scheme (GS) to gather and transmit sensory data for WSN-MCC integration . . . 884.3 Average usefulness of sensory data for each mobile user in week 1 (a); in week 2 (b) and inweek 3 (c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.4 Average reliability of WSN for each mobile user in week 1 (a); in week 2 (b) and in week3 (c) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.1 An instance about TASC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.2 An instance about states of trust-assisted WSN . . . . . . . . . . . . . . . . . . . . . . . . 985.3 An instance about states of trust-assisted cloud . . . . . . . . . . . . . . . . . . . . . . . . 1005.4 An instance about paths in SC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1095.5 TASC to SCWTA ratio (%) on throughput in Scenario 1: P1-F1 (a), P1-F2 (b), P2-F1 (c),P2-F2 (d) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116xviiiList of Figures5.6 TASC to SCWTA ratio (%) on response time in Scenario 1: P1-F1 (a), P1-F2 (b), P2-F1(c), P2-F2 (d) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1175.7 TASC to SCWTA ratio (%) on throughput in Scenario 2: P1-F1 (a), P1-F2 (b), P2-F1 (c),P2-F2 (d) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1185.8 TASC to SCWTA ratio (%) on response time in Scenario 2: P1-F1 (a), P1-F2 (b), P2-F1(c), P2-F2 (d) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1196.1 A vision of Social-Sensor-Cloud (SSC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124xixGlossaryAO Always OnATRCM Authenticated Trust and Reputation Calculation and ManagementBitC Body-in-the-CloudCC Cloud ComputingCLSS Collaborative Location-based Sleep SchedulingCSP Cloud Service ProviderCSU Cloud Service UserCTASC Collaborative TASCEC-CKN Energy-Consumption based Connected K-NeighborhoodGPS Global Positioning SystemGS General SchemeIaaS Infrastructure as a ServiceIEC International Electrotechnical CommissionISMS Information Security Management SystemISO International Organization for StandardizationITASC Independent TASCxxGlossaryLooCI Loosely-coupled Component InfrastructureMCC Mobile Cloud ComputingMTASC Mutual TASCPaaS Platform as a ServicePDFs Probability Density FunctionsPLA Privacy Level AgreementPSS Priority-based Sleep SchedulingPTP Point vs Time & PriorityQoS Quality of ServiceSaaS Software as a ServiceSC Sensor-CloudSCWTA SC Without Trust AssistanceSLA Service Level AgreementSNP Sensor Network ProviderSSC Social-Sensor-CloudTA Trust AgentTASC Trust-Assisted Sensor-CloudTCE Trusted Center EntityTPSDT Time and Priority-based Selective Data TransmissionWSN Wireless Sensor NetworkxxiAcknowledgementsFirst of all, I would like to express my deepest gratitude to my supervisor, Prof. Victor C. M. Leung.He offered me constant guidance, support and encouragement regarding both my research and my life.Without his commitment, this thesis would be impossible. I learn a lot from him and I will never forgetthe effort and time he devoted. I hope he is healthy and happy every day.I also want to thank my supervisory committee members, university examiners, external examiner,and co-authors. They provided me valuable advices about presenting and improving my work. It is anhonor for me to have them and I am grateful to all of them.In addition, I shall thank my colleagues and friends, for their kind help in my life. I wish them all thebest.Finally, I am greatly indebted to my family members, for their endless and unconditional love. Ideeply appreciate them and I love them.All the work about the thesis topic was supported by a Four Year Doctoral Fellowship from TheUniversity of British Columbia and by funding from the Natural Sciences and Engineering ResearchCouncil of Canada, the ICICS/TELUS People & Planet Friendly Home Initiative at The University ofBritish Columbia, TELUS and other industry partners.xxiiDedicationTo my familyxxiiiChapter 1Introduction1.1 Motivation1.1.1 Wireless Sensor NetworksWireless sensor networks (WSNs) [1] [2] [3] are networks consisting of spatially distributed autonomoussensors, which are capable of sensing the physical or environmental conditions (e.g., temperature, sound,vibration, pressure, motion, etc.). WSNs are widely focused due to their great potential in areas ofcivilian, industry and military (e.g., forest fire detection, industrial process monitoring, traffic monitoring,battlefield surveillance, etc.), which could change the traditional way for people to interact with thephysical world. For instance, regarding forest fire detection, since sensor nodes can be strategically,randomly, and densely deployed in a forest, the exact origin of a forest fire can be relayed to the end usersbefore the forest fire turns uncontrollable without the vision of physical fire. In addition, with respectto battlefield surveillance, as sensors are able to be deployed to continuously monitor the condition ofcritical terrains, approach routes, paths and straits in a battlefield, the activities of the opposing forcescan be closely watched by surveillance center without the involvement of physical scouts.11.1. Motivation1.1.2 Cloud ComputingCloud computing (CC) [4] [5] [6] is a novel computing model for enabling convenient, on-demand networkaccess to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications,services). CC is featured by that users can elastically utilize the infrastructure (e.g., networks, servers, andstorages), platforms (e.g., operating systems and middleware services), and softwares (e.g., applicationprograms) offered by cloud providers in an on-demand manner. Not only the operating cost and businessrisks as well as maintenance expenses of service providers can be substantially lowered with CC, but alsothe service scale can be expanded on demand and web-based easy access for clients could be providedbenefiting from CC.By further integrating CC into a mobile environment, mobile cloud computing (MCC) [7] [8] [9] canoffload much of the data processing and storage tasks from mobile devices (e.g., smart phones, tablets,etc.) to the cloud. MCC is widely considered to not only greatly relieve the processing, storage andenergy capacity limitations of mobile devices, but also provide users with many new mobile services (e.g.,mobile cloud learning, mobile cloud gaming, mobile cloud healthcare). For instance, regarding mobilecloud learning, traditional mobile learning may encounter various issues (e.g., high storage cost, lowprocessing speed and limited education resources) on mobile devices. By moving the learning platform tothe cloud, learners and teachers can achieve much faster processing speed as well as much richer learningand teaching resources in terms of available information, using just a simple client on the mobile device.21.1. MotivationCloud 1CSP1Cloud 2CSP2Cloud 3Cloud CSUCSU3SNP CSPCSP3SNP3SNP2SNP1CSU2CSU1Transmit sensory dataSend data feedbacksReply data requestsSend data requestsFigure 1.1: Examples of Sensor-Cloud31.1. Motivation1.1.3 Sensor-CloudDefined by IntelliSys1, Sensor-Cloud is “an infrastructure that allows truly pervasive computation usingsensors as an interface between physical and cyber worlds, the data-compute clusters as the cyber backboneand the internet as the communication medium” [10] [11]. According to MicroStrains2, Sensor-Cloud is “aunique sensor data storage, visualization and remote management platform that leverages powerful cloudcomputing technologies to provide excellent data scalability, rapid visualization, and user programmableanalysis” [10] [11].Attracting increasing interest from both academic and industrial communities, Sensor-Cloud (i.e.,WSN-CC integration, WSN-MCC integration, CC-WSN integration, MCC-WSN integration, SC ) [10][11] [12] [13] [14] [15] [16] is actually a new paradigm, motivated by incorporating 1) the ubiquitous datagathering capabilities of WSNs as well as 2) the powerful data storage and data processing abilities of CC.Specifically, as shown in Fig. 1.1, sensor network provider (SNP), cloud service provider (CSP) and cloudservice user (CSU) are included in Sensor-Cloud. The SNP offers different types of sensor nodes (e.g.,static sensors, mobile sensors, video sensors) which form the WSN, collecting various sensory data (e.g.,temperature, humidity, motion, sound, vibration, pressure) about the surrounding environment. TheCSP provides the powerful cloud which is consisted of data centers, storing and processing the sensorydata transmitted from the WSN. The CSU is the sensory data buyer, issuing data requests to the cloudon demand. In this whole process, SNPs act as the sensory data sources for CSPs. CSUs are the sensorydata requesters for CSPs.With Sensor-Cloud, there are a lot of advantages [10] [11] [12] [13] [14] [15] [16], benefiting the users1http://www3.ntu.edu.sg/intellisys/index.html2http://www.sensorcloud.com/system-overview41.2. Related Workand the WSN as well as the cloud. For instance, the users can have access to their required sensorydata from cloud anytime and anywhere if there is network connection, instead of being stick to theirdesks. The utility of WSN can be increased, by being able to serve multiple applications via the cloud.The services the cloud provides can be greatly enriched, by offering the services that the WSN provides(e.g., healthcare monitoring, environmental monitoring, forest fire detection, landslide detection, etc.).However, Sensor-Cloud is still in its infancy and a lot of research efforts are expected to emerge in thisarea [10] [11] [12] [13] [14] [15] [16].1.2 Related WorkFor the state of the art, current literatures about Sensor-Cloud mainly focus on the following two aspects:1) improving the performance of WSN with cloud; 2) better utilizing the sensory data of WSN with cloud.1.2.1 Improving the Performance of WSN with CloudAbout 1) improving the performance of WSN with cloud, a collaborative computing framework which in-tegrates cloud and wireless body sensor networks is proposed in [17], reducing sensory data’s transmissionsand computation time to enhance the WSN’s performance about detecting fall events and reconstructing3-D motions. To effectively configure body sensor networks in an adaptive and stable manner by seekingthe trade-offs among conflicting objectives (e.g., resource consumption and data yield), a cloud-integratedarchitecture named in Body-in-the-Cloud (BitC) is presented in [18]. For sharing the network resourcesamong any two multimedia sensor nodes, a channel characterization scheme is shown in [19], combining across-layer admission control in dynamic cloud-based multimedia sensor networks. Aiming at improvingthe packet transmission error rate as well as the number of end-to-end hops of a WSN, an integration51.2. Related Workarchitecture based on cloud and WSN is introduced in [20], which assumes that the cloud acts as a vir-tual sink with many sink points collecting the sensory data from sensors. About enhancing the latencyperformance as well as the memory of WSN, a framework to integrate WSN and cloud is designed in [21],combining a lightweight component model and a dynamic proxy-based approach. Lightweight componentmodel utilizes the publicly available Loosely-coupled Component Infrastructure (LooCI) middleware forcomponent management and dynamic proxies are added to the LooCI middleware to connect the sensorswith the cloud.1.2.2 Better Utilizing the Sensory Data of WSN with CloudRegarding 2) better utilizing the sensory data of WSN with cloud, a cloud-based platform (i.e., Wiki-Health) is introduced in [22], for storing, tagging, retrieving, analyzing, comparing and searching healthsensory data. Similarly, the motivation of [23] is to design and develop a virtualized middleware platformbased on cloud, to perform the collection, management and integration of sensory data from WSNs, whileconducting the management of businesses enabled by the infrastructure of sensors. Moreover, consideringthe scenario that the cloud utilizes the sensory data to make real time alert in critical situations, an eventmatching algorithm based on subscriber category is proposed in [24], for distributing the sensory datato appropriate subscriber. In addition, to make adequate use of the sensory data gathered by a WSN, aframework to integrate CC and WSN is depicted in [25], where the requests of users are served via threeservice layers (i.e., Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service(SaaS)) either from an archive collecting sensory data from WSN to data centers, or from a live querywhich is issued to the corresponding WSN. For providing an effective and flexible security mechanism thatguarantees confidentiality, integrity as well as fine grained access control to the e-health sensory data,61.3. Research Issuesa secure and scalable cloud-based architecture is recommended in [26] to integrate e-health WSNs, byutilizing the cloud servers to ensure sensory data storage and sensory data encryption and decryption.1.3 Research IssuesTo the best of our knowledge, concerning Sensor-Cloud, the following important research issues are yetto be widely investigated by other researchers, in terms of the energy efficiency, security, sensory datatransmission and quality of service (QoS) of Sensor-Cloud, respectively.1.3.1 Research Issues about Energy Efficiency of Sensor-Cloud• MCC applications are often utilized in a location specific way [27] [28] [29]. For example, the onlinework schedule application might be useful when the mobile user is on the way to work, but notwhen the mobile user is in a restaurant in the evening. Similarly, the traffic news application maybe accessed by the mobile user to obtain the traffic information of a certain region before the mobileuser actually gets there, while it is unlikely that the mobile user will always pay attention to thetraffic news regardless of his or her current location. Also, thinking about a tourism navigationapplication which guides the mobile user to walk directly to the specific sightseeing place, such anapplication might be favorable when the mobile user is in fact in or near the tourism area. Whereas,it is not necessarily accessed when the mobile user is at home. In short, the current locations ofmobile users usually determine the specific data mobile users might request.• Most sensors are usually equipped with non-rechargeable batteries with limited energy [30] [31] [32].If the sensor nodes continuously transmit the collected data to the cloud, the energy of these sensor71.3. Research Issuesnodes will be depleted quickly and the lifetime of the WSN will be short.1.3.2 Research Issues about Security of Sensor-Cloud• Authentication of CSPs and SNPs: Malicious attackers may impersonate authentic CSPs to com-municate with CSUs, or fake to be authentic SNPs to communicate with CSPs. Then CSUs andCSPs cannot eventually achieve any service from the fake CSPs and SNPs respectively. In themeantime, the trust and reputation of the genuine CSPs and SNPs are also impaired by these fakeCSPs and SNPs.• Trust and reputation calculation and management of CSPs and SNPs: Without trust and reputationcalculation and management of CSPs and SNPs, it is easy for CSU to choose a CSP with low trustand reputation. Then the service from CSP to CSU fails to be successfully delivered quite often.Moreover, CSP may easily select an untrustworthy SNP that delivers the service that the CSPrequests with an unacceptable large latency. In addition, the untrustworthy SNP probably mayonly be able to provide the requested service for a very short time period unexpectedly.These two issues not only seriously impede the CSU from obtaining the desirable service they wantfrom the authentic CSP, but also prevent the CSP from obtaining the satisfied service from the genuineSNP.1.3.3 Research Issues about Sensory Data Transmission of Sensor-CloudIn these potential applications of Sensor-Cloud (e.g., ubiquitous healthcare monitoring, environmentalmonitoring for disaster detection, agriculture and irrigation control, earth observation, transportation81.3. Research Issuesand vehicle real-time visualization, tunnel monitoring, wildlife monitoring) [10], quite a number of themactually require the WSN to reliably offer sensory data that are more useful to the cloud based on therequests of the mobile users.Take smart house monitoring as an instance, although various monitored information about the wholehouse gathered by the strategically deployed video sensors, image sensors and other types of sensors canbe offloaded to the cloud to let the owner of the house or other authenticated and permitted people con-veniently access their desired sensory data with the mobile devices (e.g., smart phones, tablet computers),it is expected that videos from some locations (e.g., storage room) are of little interest, while videos fromother locations (e.g., front door, back door, windows) are considered to be more important to make surethat there is no unexpected intrusion into the house.Thus, not all the sensory data are useful (i.e., actually utilized) for the cloud to satisfy user requests,while transmitting these data (i.e., multimedia data) to the cloud will use substantial network bandwidth.From this point, we can observe that 1) sensory data that are more useful to the mobile users should beoffered from WSN to cloud. On the other hand, to perform the goal of monitoring the house intelligently,the WSN needs to successfully gather and transmit the collected information (e.g., videos, images) to thecloud continuously, which means that 2) the sensory data should be reliably offered from the WSN to thecloud.1.3.4 Research Issues about QoS of Sensor-CloudEnhancing quality of service (QoS) of Sensor-Cloud with trust assistance: QoS is always a fascinating andvaluable topic, as QoS (e.g., throughput, response time) always plays a vital role for users to eventuallyuse the service (e.g., service provided by Sensor-Cloud). Trust is supposed to enhance the performance91.4. Contributions of Thesisof an existing system, by assigning trust value to the entity of the system. Potential way to improve theQoS of Sensor-Cloud (e.g., with trust assistance) is always worth to be explored.1.4 Contributions of ThesisImproving Sensor-Cloud, this thesis further describes our accomplished work, aiming at tackling the iden-tified research issues. The performed analytical and experimental results demonstrate that the approachesproposed in our work can effectively mitigate the corresponding research issues respectively. We hope ourwork can attract more research into Sensor-Cloud, to make it develop faster and better. The detailedcontributions of this thesis are summarized as follows.• In Chapter 2, to solve the identified research issues about energy efficiency of Sensor-Cloud, wepropose two collaborative location-based sleep scheduling (CLSS) schemes for WSNs integrated withMCC. Considering the locations of mobile users, the awake or asleep state of sensor nodes in theintegrated WSN are dynamically changed in the CLSS schemes to reduce the energy consumption.Specially, CLSS1 focuses on maximizing savings in energy consumption of the integrated WSN andCLSS2 considers also the scalability and robustness of the integrated WSN. These schemes arefurther evaluated analytically and by simulations to show that they can prolong the lifetime of theintegrated WSN while satisfying the data requests of the mobile users.• In Chapter 3, for solving the identified research issues about security of Sensor-Cloud, we first analyzethe authentication of CSPs and SNPs as well as the trust and reputation about the services of CSPsand SNPs. Further, we propose an authenticated trust and reputation calculation and management(ATRCM) system for CC-WSN integration. Particularly, considering (i) the authenticity of CSP101.4. Contributions of Thesisand SNP; (ii) the attribute requirement of CSU and CSP; (iii) the cost, trust and reputation of theservice of CSP and SNP, the proposed ATRCM system achieves the following three functions: a)authenticating CSP and SNP to avoid malicious impersonation attacks; b) calculating and managingtrust and reputation regarding the service of CSP and SNP; c) helping CSU choose desirable CSPand assisting CSP in selecting appropriate SNP. Detailed analysis and design as well as furtherfunctionality evaluation results are presented to demonstrate the effectiveness of ATRCM, followedwith system security analysis.• In Chapter 4, motivated by solving the identified research issues about sensory data transmission ofSensor-Cloud for supporting these WSN-MCC integration applications that require WSN to reliablycollect and send data that are more useful to the mobile users to cloud, we first identify the criticalissues that affect the usefulness of sensory data and reliability of WSN, and then propose a WSN-MCC integration scheme named TPSS. Specifically, TPSS includes two parts: 1) TPSDT (Time andPriority based Selective Data Transmission) for WSN gateway to selectively transmit sensory datathat are more useful to the cloud, considering the time and priority features of the data requestedby the mobile user; 2) PSS (Priority-based Sleep Scheduling) algorithm for WSN to save energyconsumption so that it can gather and transmit sensory data in a more reliable way. Analytical andexperimental results demonstrate the effectiveness of TPSS, in enhancing the usefulness of sensorydata and reliability of WSN for WSN-MCC integration.• In Chapter 5, triggered by solving the identified research issues about QoS of Sensor-Cloud, weintroduce TASC (Trust-Assisted SC), enhancing the QoS that the sensory data is achieved by usersfrom SC. Specifically, the trusted sensors (i.e., sensors which own trust values surpassing a threshold)in WSN are utilized by TASC, for gathering and transmitting the sensory data to the cloud. Then111.5. Organization of Thesisthe trusted data centers (i.e., data centers which own trust values surpassing a threshold) in cloud areused by TASC, for storing and processing the sensory data as well as further on demand deliveringthe sensory data to users. Furthermore, regarding the application of TASC, we discuss the methodsto compute the trust values of sensor nodes and data centers in TASC. In addition, concerningthe design of TASC, we present three types of TASC (i.e., ITASC (independent TASC), CTASC(collaborative TASC), MTASC (mutual TASC)). With extensive analysis and numerical results, itis shown that the throughput and response time that the sensory data is achieved by users from SCcan be greatly enhanced with TASC, in contrast to SCWTA (SC without trust assistance).1.5 Organization of ThesisFor the rest of this thesis, Chapter 2 shows our work regarding solving the identified research issues aboutenergy efficiency of Sensor-Cloud. The MCC-WSN integration model and the proposed CLSS schemesare shown, followed with the related theoretical analysis and numerical results. Chapter 3 describesour work to solve the identified research issues about security of Sensor-Cloud. The system model isdescribed, followed with the discussion about the authentication of CSPs and SNPs as well as the trustand reputation about the services of CSPs and SNPs. Then the design, functionality evaluation results andsecurity analysis about the proposed ATRCM system are shown. Chapter 4 presents our work motivatedby solving the identified research issues about sensory data transmission of Sensor-Cloud. The criticalissues that affect the usefulness of sensory data and reliability of WSN are discussed. Then the WSN-MCC integration system model and TPSDT as well as PSS are presented, followed with the introductionabout the proposed TPSS scheme and its evaluations. Chapter 5 introduces our work triggered by solvingthe identified research issues about QoS of Sensor-Cloud. The system model and the proposed TASC are121.5. Organization of Thesisintroduced. With that, the trust values computation in TASC is discussed and three types of TASC (i.e.,ITASC, CTASC and MTASC) are designed. Further, the analysis and numerical results about TASC andSCWTA are shown. Chapter 6 concludes the thesis and discusses the future work.13Chapter 2Collaborative Location-based SleepScheduling for Wireless Sensor NetworksIntegrated with Mobile CloudComputing2.1 MCC-WSN Integration ModelThe MCC-WSN integration model in this chapter is presented as follows and the main notations used inthis chapter are summarized in Table 2.1 and Table 2.2.2.1.1 Overall System ModelThere is one cloud c and we assume that there are M mobile users (i.e., u1, u2, · · · , uM ) as well as Mmultihop WSNs (i.e., wsn1, wsn2, · · · , wsnM ). Each WSN acts as a sensory data source for the cloud toreply the data requests issued by each corresponding mobile user. We suppose that the mobile device used142.1. MCC-WSN Integration ModelTable 2.1: Main notation definitions in Chapter 2Symbol Definition| | Number of elements in a setA Area of WSNB Set of linksc Cloudd Transmission distanceea Energy consumption of power amplificationof one byte to cover a 1 m distanceer Energy consumption of receiving a byteet Energy consumption of transmitting a byteEo Node initial energyER Energy consumption of receiving a packetET Energy consumption of transmitting a packeth Packet lengthi Sensor nodeI Set of sensor nodesk k in EC-CKNL Mobile user location listLh Mobile user location history listLp Mobile user predication location list152.1. MCC-WSN Integration ModelTable 2.2: Main notation definitions continued in Chapter 2Symbol DefinitionM Number of mobile users or WSNsN Total number of sensor nodes in WSNNL Network lifetimeNL0 Network lifetime of AONL1 Network lifetime of CLSS1NL2 Network lifetime of CLSS2NWR Network work rateNWR0 Network work rate of AONWR1 Network work rate of CLSS1NWR2 Network work rate of CLSS2pXY (x, y) Independent probability distribution of eventsq Number of packets transmitted from a nodeto each neighbor node if an event is detecteds Base stationt Time epoch intervaltr Transmission radiusT TimeTP Time epochu Mobile userλ Average event rateρ Node density162.1. MCC-WSN Integration Modelby the mobile user has the global positioning system (GPS) and the mobile user utilizes the StarTrackservice in [33]. There is a base station s with unlimited energy supply, serving as the gateway betweeneach WSN and the cloud. Time T is divided into time epochs and the interval of each time epoch TP ist.2.1.2 Overall WSN ModelThe multihop WSN is uniformly randomly deployed with N sensor nodes in a two dimensions area A.The whole network is modeled by a graph G = (I,B), where I = {i1, i2, · · · , iN} is the set of sensor nodesand B = {b(1,2), b(2,3), · · · , b(N−1,N)} is the set of links. Each node has the same transmission radius tr.Any two sensors ii and ij are neighbors if they are within the transmission range of each other. Any twosensors ii and ij are 2-hop neighbors if b(ii,ij) /∈ B and there exists another node iw satisfying b(ii,iw) ∈ B,b(iw,ij) ∈ B or b(ij ,iw) ∈ B, b(iw,ii) ∈ B.2.1.3 WSN Energy ModelThe energy consumed by a sensor to transmit and receive one byte, and power-amplify each transmittedbyte to cover the distance of 1 m are et mJ , er mJ and ea mJ/m2, respectively. The energy model is thefirst order model shown as follows in [34] [35] [36]. Including the packet header and body containing thesensed data, the consumed energy to transmit and receive a packet of length h bytes over distance d areET , ER:ET = et · h+ ea · h · d2 (2.1)172.2. Proposed CLSS SchemesER = er · h (2.2)2.1.4 WSN Event ModelGenerally, an event which has a characterizable distribution in space and time, is sensed when a sensornode receives a signal with power above a predetermined threshold. Assume that the temporal eventbehavior over the entire sensing region A is a Poisson process with an average event rate λ. In addition,given that the spatial distribution of events is characterized by an independent probability distributiongiven by pXY (x, y). Then the probability that an event occurring in Ai is detected by a sensor node i isas follows [37] [38].pei =∫AipXY (x, y)∫A pXY (x, y)(2.3)2.2 Proposed CLSS SchemesIn this section, we first show the mechanisms to obtain the mobile user location list and then present ourproposed CLSS schemes.2.2.1 Mobile User Location ListMobile User Location History ListTo achieve the location list L of mobile user u, the location history of u is extracted by the cloud c basedon the StarTrack service. Specifically, StarTrack in [33] is a mobile client application and it periodically182.2. Proposed CLSS Schemescaptures the user’s current location (e.g., with GPS) and relays the location information to the StarTrackserver which runs as a service in the cloud c. Further, the StarTrack server processes these location dataand decomposes them into various tracks (i.e., discrete representations of trips taken by the mobile user).The points of these tracks are operational and retrievable through a high-level application programminginterface and they make up the location history list named as Lh.Mobile User Predication Location ListTo obtain the mobile user predication location list Lp, we utilize the following method that is similar withthe Place Transition Graph utilized as in [27]. The key idea is that the future locations of the mobileuser would be associated with the frequently visited locations of the mobile user, thus it is likely that thefuture track of the mobile user will be constituted by these frequently visited locations. For instance, if amobile user goes to restaurant A and gym B from office C very often, it is obvious that the mobile userwill go to gym B from restaurant A, or go to restaurant A from gym B someday in the future.Particularly, we compute a frequently visited location list Lf first. This Lf is obtained by iterating overall the retrieved tracks and selecting the end points of the retrieved tracks of the mobile user. Then Lf isupdated by further removing the end points of the tracks that only appear once. With that, an adjacencymatrix in which the numbers of rows and columns correspond to the number of the elements in the updatedLf is constructed. Finally, the match of each element in the row and the column except the match withtwo same points becomes a new track (i.e., the prediction track). All points without repetition excludingthe starting and end points of the prediction tracks constitute the mobile user predication location listLp.The mobile user location history list Lh and mobile user predication location list Lp constitute the192.2. Proposed CLSS SchemesPseudocode of CLSS1 schemeStep 1: Cloud c obtains mobile user u’s current location lu.Step 2: If lu ∈ L, c sends flag A to base station s. Otherwise, c sends s flag Z.Step 3: s broadcasts flag to sensor nodes.Step 4: Run Step 5 at each node i.Step 5: If node i receives flag A, remain awake. Otherwise, go to sleep.location list L of the mobile user.2.2.2 CLSS SchemesThere are two collaborative location-based sleep scheduling (CLSS) schemes for the integrated WSN andthe pseudocodes of these two CLSS schemes (i.e., CLSS1 and CLSS2) in each time epoch TP are as shownabove and below.CLSS1Regarding CLSS1 scheme, cloud c first obtains the current location lu of mobile user u (Step 1 of CLSS1).Then according to whether lu is in the location list L or not, a flag A or Z is sent to base station sby cloud c (Step 2 of CLSS1). Base station s further broadcasts the flags. At last, each sensor node idetermines its awake or asleep state according to the flag it receives in each time epoch TP (Step 3 toStep 5 of CLSS1).CLSS2In terms of CLSS2, the first 4 steps are the same as that of CLSS1. The difference between CLSS2 andCLSS1 lies in Step 5. In Step 5 of CLSS2, when sensor node i receives flag Z, i will be sleep scheduledusing the energy-consumption based connected k-neighborhood (EC-CKN) sleep scheduling scheme [36].202.2. Proposed CLSS SchemesPseudocode of CLSS2 schemeStep 1: Cloud c obtains mobile user u’s current location lu.Step 2: If lu ∈ L, c sends flag A to base station s. Otherwise, c sends s flag Z.Step 3: s broadcasts flag to sensor nodes.Step 4: Run Step 5 at each node i.Step 5: If node i receives flag A, remain awake. Otherwise, run Step 6 to Step 12.Step 6 to Step 12 are the pseudocodes of EC-CKN schemeStep 6: Get the current residual energy Eranki.Step 7: Broadcast Eranki and receive the ranks of its currently awake neighbors Ni. Let Ri be theset of these ranks.Step 8: Broadcast Ri and receive Rj from each j ∈ Ni.Step 9: If |Ni| < k or |Nj | < k for any j ∈ Ni, remain awake. Go to Step 12.Step 10: Compute Ci = {j|j ∈ Ni and Erankj > Eranki}.Step 11: Go to sleep if both the following conditions hold. Remain awake otherwise.• Any two nodes in Ci are connected either directly themselves or indirectly through nodeswithin i’s 2-hop neighborhood that have Erank more than Eranki.• Any node in Ni has at least k neighbors from Ci.Step 12: Return.212.3. Theoretical AnalysisRegarding EC-CKN, the current residual energy rank (i.e., Eranki) of each node i is obtained first (Step6 of CLSS2) and the subset Ci of i’s currently awake neighbors that have Erank > Eranki is computed(Step 10 of CLSS2). Before a node i can go to sleep in each time epoch TP , the following two conditionsshould hold: (1) all nodes in Ci are connected by nodes with Erank > Eranki (2) each of its neighborsowns at least k neighbors from Ci (Step 11 of CLSS2).2.3 Theoretical Analysisl1 l2 l3 l4 l5 l6 l7 l8Time lineMobile user locationNode statusAwake Awake Awake Awake Awake Awake AwakeAwakeAwakeTime epoch…..…..Figure 2.1: Example of time line of always on (AO) schemel1 l2 l3 l4 l5 l6 l7 l8Time lineMobile user locationAwake Awake Awake Awake Awake Awake AwakeAwakeAsleep…..Node status…..Time epochFigure 2.2: Example of time line of CLSS1222.3. Theoretical Analysisl1 l2 l3 l4 l5 l6 l7 l8Time lineMobile user locationAwake Awake Awake Awake Awake Awake AwakeAwakeDynamically awake and asleepTime epoch…..Node status…..Figure 2.3: Example of time line of CLSS22.3.1 Time LineFig. 2.1 shows the example of the time line of the always on (AO) scheme, in which sensor nodes arealways working to transmit the sensory data to the cloud. Fig. 2.2 and Fig. 2.3 present the examples ofthe time line of CLSS1 and CLSS2 schemes, respectively. Based on the graphical depictions in these threefigures and the algorithmic descriptions in Section 2.2, we can observe the following properties aboutthese three schemes in each time epoch TP : 1) In AO, no matter the mobile user’s current location is inL or not, the sensor node is always awake; 2) About CLSS1, when the location of the mobile user is in L,the sensor nodes will be awake. Otherwise, the sensor nodes will be asleep to save energy; 3) RegardingCLSS2, if the mobile user’s current location is in L, the sensor nodes will also be awake. Otherwise, thesensor nodes are dynamically asleep and awake for saving energy based on EC-CKN.2.3.2 PreliminariesFrom [36] [39] [40], we can determine that for a uniformly randomly deployed WSN with N nodes in atwo dimensional area A, the node density is ρ = NA .232.3. Theoretical AnalysisThe expected distance to the nearest neighbor for each sensor is as follows [36] [39] [40].Ed =12√ρ(2.4)The expected number of neighbors for each sensor is as follows [36] [39] [40].Enb = ρpitr2 (2.5)In addition, from [37] [38], we can obtain that the expected number of events that occur in timeinterval t at node i is as follows.Ene = λ · pei (2.6)Let q be the number of packets transmitted from a node to each neighbor node if an event is detected,then the expected total number of transmitted packets for a node i is as follows.Q = Ene · q · Enb = λ · pei · q · Enb (2.7)2.3.3 Network LifetimeThere are different definitions of network lifetime [41] [42], since when the network is considered non-functional depends on the specific application. It could be calculated as the instant when the first sensor242.3. Theoretical Analysisnode dies, or when a percentage of sensor nodes have exhausted their energy, or when area coverage is nolonger available.In this chapter, we assume that the initial energy reserve of each sensor is Eo. With the time intervalt, the network lifetime NL can be defined as follows, in which x is unknown.NL = xt (2.8)In the following sections, we first analyze the packet transmissions during each time epoch TP of AOand CLSS1 as well as CLSS2 schemes. Further, we deduce the average energy consumption of a sensornode in each time epoch TP and then determine the corresponding network lifetime.Network Lifetime of AOFor AO scheme, each sensor node is always awake in each time epoch TP , no matter the mobile user’slocation is in the location list L or not. Then the average energy consumption of a sensor node in eachtime epoch TP for AO is:E0 =(ET + ER)Q+ (ET + ER)Q2= ET ·Q+ ER ·Q (2.9)The network lifetime of AO is:NL0 =EoE0· t = EoET ·Q+ ER ·Q · t (2.10)252.3. Theoretical AnalysisNetwork Lifetime of CLSS1For CLSS1 scheme, during each time epoch TP , base station s broadcasts the flags to sensor nodes first.The energy consumption of the sensor node for this part is generally ETEnb + ER. If the sensor shouldbe awake after receiving flag A, the energy consumption of a sensor node being awake for transmittingdata packets is (ET + ER)Q. If the sensor can be asleep after receiving flag Z, then there is no energyconsumption.Hence, the average energy consumption for a sensor node during each time epoch TP for CLSS1 isE1 = ETEnb + ER +(ET + ER)Q2= ET · (Enb + Q2) + ER · (1 + Q2)(2.11)In addition, the network lifetime of CLSS1 isNL1 =EoE1· t=EoET · (Enb + Q2 ) + ER · (1 + Q2 )· t(2.12)Network Lifetime of CLSS2Regarding CLSS2 scheme, base station s also first broadcasts the flags to sensor nodes during each timeepoch TP . The energy consumption of the sensor node for this part is generally ETEnb+ER as well. Theenergy consumption of a sensor node if it remains awake to transmit data packets is also (ET + ER)Q ifthe sensor receives flag A. When the sensor receives flag Z, the sensor is dynamically asleep and awake.Specifically, each sensor broadcasts Eranki and receives the ranks of its currently awake neighbors. The262.3. Theoretical Analysisenergy consumption for broadcasting and receiving packets in this part is (ET +ER)Enb. Also each sensorbroadcasts Ri and receives Rj from each j ∈ Ni. The energy consumption for this part is (ET +ER)Enbas well. If the sensor is determined to be awake after satisfying the corresponding condition, let theenergy consumption of such an awake node during data transmission be (ET + ER) · Q′ , where Q′ isthe expected total number of transmitted packets for an awake node in an EC-CKN based network. Ifthe sensor determines to be asleep after meeting the corresponding requirement, then there is no energyconsumption.Thus the average energy consumption for a sensor node during each time epoch TP for CLSS2 isE2 =ETEnb + ER +(ET + ER)Q2+(ET + ER)Enb + (ET + ER)Enb +(ET+ER)Q′22=ET (2Enb +Q2+Q′4) + ER(1 + Enb +Q2+Q′4)(2.13)Then, the network lifetime of CLSS2 isNL2 =EoE2· t=EoET (2Enb +Q2 +Q′4 ) + ER(1 + Enb +Q2 +Q′4 )· t(2.14)In the following, we analyze Q′. Let Eanb be the expected number of awake neighbors for each sensorafter EC-CKN sleep scheduling and f = EanbEnb < 1, we can further deduce thatQ′= fQ (2.15)272.3. Theoretical AnalysisThe analysis of Eanb is as shown in [36].Eanb ≤cklnNξ(2.16)where c is a constant > 96, k is the parameter in the EC-CKN, and ξ ≥ 4(k + lnN).2.3.4 Network Work RateThe network work rate NWR is defined as the number of time epochs during which the network needsto work (i.e., always on or sleep scheduled), divided by its network lifetime. In this chapter, we assumethat during the network lifetime NL, the number of time epochs when the mobile user’s location is in themobile user location list L is |L| and the number of time epochs when the mobile user’s location is not inthe mobile user location list L is NL− |L| (|L| < NL).Network Work Rate of AOAs the network is always on in AO no matter the mobile user’s location is in L or not during its networklifetime, thus the network work rate of AO (i.e., NWR0) is as follows.NWR0 =|L|+NL0 − |L|NL0= 100% (2.17)Network Work Rate of CLSS1Since the network lifetime of CLSS1 is NL1 and the network resulting from CLSS1 only needs to bealways on when the location of the mobile user is in L, the network work rate of CLSS1 (i.e., NWR1) isas follows.282.3. Theoretical AnalysisNWR1 =|L|NL1(2.18)Network Work Rate of CLSS2As the network lifetime of CLSS2 is NL2 and the CLSS2 based network has to be always on if the mobileuser’s location is in L or sleep scheduled otherwise, the network work rate of CLSS2 (i.e., NWR2) is asfollows.NWR2 =|L|+NL2 − |L|NL2= 100% (2.19)2.3.5 Comparison of CLSS1 and CLSS2The comparison of CLSS1 network lifetime (i.e., NL1) and CLSS2 network lifetime (i.e., NL2) as well asthe contrast of CLSS1 network work rate (i.e., NWR1) and CLSS2 network work rate (i.e., NWR2) areshown as follows.292.3. Theoretical AnalysisNL1NL2=EoET · (Enb + Q2 ) + ER · (1 + Q2 )· t ÷EoET (2Enb +Q2 +Q′4 ) + ER(1 + Enb +Q2 +Q′4 )· t=ET (2Enb +Q2 +fQ4 ) + ER(1 + Enb +Q2 +fQ4 )ET · (Enb + Q2 ) + ER · (1 + Q2 )=ET (2EnbQ +Q2Q +fQ4Q ) + ER(1Q +EnbQ +Q2Q +fQ4Q )ET · (EnbQ + Q2Q) + ER · ( 1Q + Q2Q)=ET (12 +f4 ) + ER(12 +f4 )ET · 12 + ER · 12(Q→∞)=ET (2 + f) + ER(2 + f)ET · 2 + ER · 2 (Q→∞)(2.20)Referring to equation (2.20) about NL1NL2 , we can further obtainNWR1NWR2=|L|NL1÷ |L|+NL2 − |L|NL2=|L||L|+NL2 − |L| ·NL2NL1=|L|NL2· ET · 2 + ER · 2ET · (2 + f) + ER · (2 + f) (Q→∞)=|L|NL2· ET + ERET · (1 + f2 ) + ER · (1 + f2 )(Q→∞)(2.21)2.3.6 TheoremsTheorem 2.3.1. In terms of CLSS2, a sensor node i will always have at least min(k, oi) awake neighborsafter sleep scheduling, if it has oi neighbors in the original sensor network.Proof: For CLSS2, if the mobile user’s location lu ∈ L, flag A will be sent from cloud c to base station302.3. Theoretical Analysiss. Then every sensor node i will receive flag A and be awake. In this case, i will have oi awake neighborsafter sleep scheduling.In the case that a node i receives flag Z from the base station s, we perform the following analysis[43] [44] [45]. If oi < k, all of i’s neighbors should be awake (Step 9 of CLSS2) and i will have oi awakeneighbors. Otherwise if oi ≥ k, we prove the theorem by contradiction. First, we assume that a node iwill not have at least k awake neighbors after running CLSS2, i.e., we can suppose that the m’th (m ≤ k)lowest ranked neighbor (e.g., v) of i, decides to sleep. Then Ci will own at most m − 1 nodes which areneighbors of i. But since m − 1 < k, v cannot go to sleep according to Step 11 of CLSS2. This is acontradiction. In other words, the k lowest ranked neighbors of i will all be awake after running CLSS2.Thus, i will always have at least k awake neighbors.Theorem 2.3.2. In terms of CLSS2, running the scheme creates a connected network if the originalsensor network is connected.Proof: Regarding CLSS2, if the mobile user’s location lu ∈ L, flag A will be sent to base stations. Further, every sensor node receives flag A which indicates that they should all be awake. Then theresultant network is connected.Otherwise if base station s issues flag Z to sensor node i, we prove this theorem by contradiction [43][44] [45]. First, we assume that the output network after running CLSS2 is not connected. Then thedeleted nodes (asleep nodes determined by CLSS2) are put back in the network in descending order oftheir ranks. Let i be the first node making the sensor network connected again. Note that by the timewe put i back, all the members of Ci are already present and nodes in Ci are already connected by nodeswith Erank > Eranki. Let v be a node that was disconnected from Ci but now becomes connected toCi by i. However, this contradicts the fact that i can sleep only if all its neighbors (including v) are312.3. Theoretical Analysisconnected to ≥ k nodes in Ci (Step 11 of CLSS2).Theorem 2.3.3. With CLSS schemes, the WSN lifetime of the MCC-WSN integration will be prolongedwhile the data requests of mobile users will still be satisfied.Proof: About CLSS1, sensor nodes will go to sleep if they do not receive flag A from the base stations during the time epoch (Step 5 of CLSS1). This actually indicates that a lot of energy consumptionwill be saved, since usually sensor nodes will transmit a lot of data packets to the base station if theyare not in the asleep status. Even though there is extra flag broadcast energy consumption, these energyconsumption are negligible, compared with the data transmission energy consumption when sensor nodesare awake. Thus, the WSN lifetime of MCC-WSN integration will be prolonged with CLSS1.This also can be easily observed, by comparing equation (2.11) and equation (2.9) shown as follows,since Enb << Q.ET · (Enb + Q2) + ER · (1 + Q2) < ET ·Q+ ER ·Q (2.22)EoET · (Enb + Q2 ) + ER · (1 + Q2 )· t >EoET ·Q+ ER ·Q · t(2.23)Then,NL1 > NL0 (2.24)Concerning CLSS2, if sensor nodes do not receive flag A from base station s during the time epoch,322.3. Theoretical Analysisthey will be sleep scheduled according to the EC-CKN scheme (Step 5 of CLSS2). In this case, similarwith CLSS1, quite an amount of data transmission energy consumption will also be saved, as only asubset of sensor nodes will be awake under some certain conditions (Step 11 of CLSS2). Hence, the WSNlifetime of MCC-WSN integration will also be extended with CLSS2.This could be obtained from equation (2.13) and equation (2.9), since Enb << Q and Q′ < Q.ET (2Enb +Q2+Q′4) + ER(1 + Enb +Q2+Q′4) <ET ·Q+ ER ·Q(2.25)EoET (2Enb +Q2 +Q′4 ) + ER(1 + Enb +Q2 +Q′4 )· t >EoET ·Q+ ER ·Q · t(2.26)With that,NL2 > NL0 (2.27)Regarding the data requests of mobile users for MCC-WSN integration with CLSS1, since the mobileapplications are location specific and all sensor nodes will be awake if the mobile user’s location lu ∈ L,all sensory data required by the mobile users will be obtained.In terms of utilizing CLSS2 for WSN to integrate with MCC, from Theorem 2.3.2, we can achievethat a connected network will always be produced with CLSS2 if the original sensor network is connected.In addition, this connected network is regardless of the mobile user’s location lu. Furthermore, fromTheorem 2.3.1, we can obtain that each sensor node i will always own at least min(k, oi) awake neighbors332.3. Theoretical Analysiswith CLSS2, if it has oi neighbors in the original sensor network. This indicates that the k actually couldbe tuned to offer enough awake sensor nodes, which ensure sufficient area coverage or target coverageaccording to the requirement of specific WSN application in CLSS2. Hence, the sensory data required bythe mobile users for MCC-WSN integration with CLSS2 can also be achieved.Theorem 2.3.4. With CLSS1 scheme, the WSN work rate of the MCC-WSN integration will be enhanced.With CLSS2 scheme, the WSN work rate of the MCC-WSN integration remains unchanged.Proof: This theorem can be easily analyzed as follows, based on equation (2.17) to equation (2.19).|L|NL1<|L|+NL0 − |L|NL1<|L|+NL0 − |L|NL0= 100% (2.28)|L|+NL2 − |L|NL2= 100% =|L|+NL0 − |L|NL0= 100% (2.29)Thus,NWR1 < NWR0 & NWR2 = NWR0 (2.30)Theorem 2.3.5. The network lifetime of CLSS1 is larger than that of CLSS2, while the network workrate of CLSS1 is shorter than that of CLSS2.Proof: Referring to equation (2.20) and equation (2.21), with |L| < NL2, we can easily achieve thefollowing.NL1NL2> 1 &NWR1NWR2< 1 (2.31)Then,342.4. Numerical ResultsNL1 > NL2 & NWR1 < NWR2 (2.32)The theorem is obtained.2.3.7 SummaryFrom the above analysis, we can obtain the following insights.• 1) Both CLSS1 and CLSS2 have longer network lifetime than AO.• 2) CLSS1 has lower network work rate than AO and CLSS2 has the same network work rate as AO.• 3) CLSS1 has longer network lifetime and lower network work rate than CLSS2.• 4) CLSS1 maximizes the energy saving, while CLSS2 is scalable and robust. Reason: When thelocation of the mobile user u is not in L, all sensor nodes go to sleep in CLSS1 while sensor nodes aredynamically awake and asleep according to EC-CKN in CLSS2. EC-CKN sleep scheduling basednetwork can still gather data and the k in EC-CKN can be tuned to achieve satisfied area coverageor target coverage. This can ensure that the WSN still provides sufficient data to cloud c, evenwhen the location of u is not in L.2.4 Numerical ResultsWe compare the WSN lifetime of MCC-WSN integration with CLSS and without CLSS (i.e., AO) schemes,as the data requests of mobile users will be both satisfied with either CLSS schemes or AO scheme basedon the previous analysis. Due to that the network lifetime of the non-rechargeable WSN is generally352.4. Numerical Resultsmuch shorter than the lifetime of the cloud, the WSN lifetime of the MCC-WSN integration could also betaken as the lifetime of MCC-WSN integration. Specifically, when the integrated WSN is not functional,the mobile user may no longer obtain the required sensory data from the cloud any more. Then theintegration framework of MCC-WSN is considered not working any more. In addition, the WSN workrate of MCC-WSN integration with CLSS schemes and AO scheme are compared.2.4.1 Evaluation SetupIn this evaluation, inspired by the behaviors that mobile users utilize the mobile application, we focus onthe following three representative mobile users utilizing the StarTrack service, capturing and relaying themobile user’s location information to the StarTrack server in the cloud.• 1) For mobile user 1, we assume that the mobile user accesses the mobile application with a cycle.For each cycle, the mobile application is accessed from every 1 minute to every 5 minutes and thereare total 6 accesses as shown in Fig. 2.4(a).• 2) Regarding mobile user 2, we suppose that the mobile user utilizes the mobile application alsowith a cycle. In this cycle, mobile user accesses the mobile application according to a parabolawith maximum value which is 5 (i.e., every 5 minutes) and minimum value which is 1 (i.e., every 1minute). There are total 10 accesses for this cycle as shown in Fig. 2.4(b).• 3) With respect to mobile user 3, the mobile user utilizes the mobile application with a randominterval between 1 minute and 10 minutes as shown in Fig. 2.4(c).The track of each mobile user is observed and recorded to obtain a database, containing the currentlocations of mobile users as well as the location lists of mobile users. This database is to be further362.4. Numerical Results 0 5 10 15 20 1  2  3  4  5  6#Time in an access cycle (minute)#Order in an access cycleMobile user 1(a) 0 5 10 15 20 25 30 35 1  2  3  4  5  6  7  8  9  10#Time in an access cycle (minute)#Order in an access cycleMobile user 2(b) 0 10 20 30 40 50 60 1  2  3  4  5  6  7  8  9  10#Time in an access cycle (minute)#Order in an access cycleMobile user 3(c)Figure 2.4: Access behavior of mobile user 1 (a), mobile user 2 (b) and mobile user 3 (c)Table 2.3: Evaluation parameters in Chapter 2Parameter Parameter valueNetwork size 600×600 m2Number of sensor nodes 100-1000k in EC-CKN 1Average event rate 50 times/minuteInitial energy 100000 mJTransmission energy 0.0144 mJReception energy 0.00576 mJTransmission amplifier energy 0.0288 nJ/m2Transmission radius 60 mPacket length 12 bytesNumber of packets 1000Time epoch interval 1 minute372.4. Numerical Resultsutilized by the WSN simulator NetTopo 3 [46] to conduct the simulation of each integrated WSN foreach mobile user. The WSN size is 600×600 m2. The number of randomly uniformly deployed sensornodes ranges from 100 to 1000 (every time increased by 100). The value of k in EC-CKN is 1, which isthe minimum value of k in EC-CKN. For every number of deployed sensor nodes, 100 different networktopologies are generated with 100 different seeds and the average event rate is 50 times/minute. Theinitial energy of each node is 100000 mJ . The energy consumed by a sensor to transmit and receive onebyte, and power-amplify each transmitted byte to cover the distance of 1 m are 0.0144 mJ , 0.00576 mJand 0.0288 nJ/m2 respectively [40] [44]. The transmission radius of each node is 60 m. The length ofeach packet is 12 bytes and each node transmits 1000 packets to each neighbor node in each time epochwhich lasts 1 minute. Table 2.3 presents the evaluation parameters for each mobile user.2.4.2 Evaluation ResultsFig. 2.5 depicts the theoretical analysis of network lifetime and network work rate of CLSS1 and CLSS2as well as AO schemes for mobile user 1, mobile user 2 and mobile user 3. The simulation analysis ofnetwork lifetime and network work rate of CLSS1 and CLSS2 as well as AO schemes for mobile user 1,mobile user 2 and mobile user 3 are shown in Fig. 2.6. From Fig. 2.5 and Fig. 2.6, we can first observethat the theoretical results approximate the simulation results very much, which proves that our modelis ponderable for analyzing the sleep scheduling mechanisms for WSNs to integrate with MCC.Specifically, Fig. 2.5(a) to Fig. 2.5(c) and Fig. 2.6(a) to Fig. 2.6(c) graph the network lifetime ofCLSS1 and CLSS2 as well as AO schemes for different mobile users, in theory and in simulation respec-tively. From these six graphs, we can obviously observe that the WSN lifetime of MCC-WSN integration3NetTopo (online at http://sourceforge.net/projects/nettopo/) is an open source software on SourceForge for simulatingand visualizing WSNs.382.4. Numerical Results 0 200 400 600 800 1000 1200 1400 1600 1800 100  200  300  400  500  600  700  800  900 1000#Lifetime (minute)#Number of nodesCLSS1CLSS2AO(a) 0 200 400 600 800 1000 1200 1400 1600 1800 100  200  300  400  500  600  700  800  900 1000#Lifetime (minute)#Number of nodesCLSS1CLSS2AO(b) 0 200 400 600 800 1000 1200 1400 1600 1800 100  200  300  400  500  600  700  800  900 1000#Lifetime (minute)#Number of nodesCLSS1CLSS2AO(c) 0 20 40 60 80 100 100  200  300  400  500  600  700  800  900 1000#Network work rate (%)#Number of nodesCLSS1CLSS2AO(d) 0 20 40 60 80 100 100  200  300  400  500  600  700  800  900 1000#Network work rate (%)#Number of nodesCLSS1CLSS2AO(e) 0 20 40 60 80 100 100  200  300  400  500  600  700  800  900 1000#Network work rate (%)#Number of nodesCLSS1CLSS2AO(f)Figure 2.5: Theoretical analysis: network lifetime of CLSS1, CLSS2 and AO schemes for mobile user 1(a), mobile user 2 (b) and mobile user 3 (c); network work rate of CLSS1, CLSS2 and AO schemes formobile user 1 (d), mobile user 2 (e) and mobile user 3 (f). Both CLSS1 and CLSS2 have longer networklifetime than AO. CLSS1 has lower network work rate than AO and CLSS2 has the same network workrate as AO. CLSS1 has longer network lifetime and lower network work rate than CLSS2.392.4. Numerical Results 0 200 400 600 800 1000 1200 1400 1600 1800 100  200  300  400  500  600  700  800  900 1000#Lifetime (minute)#Number of nodesCLSS1CLSS2AO(a) 0 200 400 600 800 1000 1200 1400 1600 1800 100  200  300  400  500  600  700  800  900 1000#Lifetime (minute)#Number of nodesCLSS1CLSS2AO(b) 0 200 400 600 800 1000 1200 1400 1600 1800 100  200  300  400  500  600  700  800  900 1000#Lifetime (minute)#Number of nodesCLSS1CLSS2AO(c) 0 20 40 60 80 100 100  200  300  400  500  600  700  800  900 1000#Network work rate (%)#Number of nodesCLSS1CLSS2AO(d) 0 20 40 60 80 100 100  200  300  400  500  600  700  800  900 1000#Network work rate (%)#Number of nodesCLSS1CLSS2AO(e) 0 20 40 60 80 100 100  200  300  400  500  600  700  800  900 1000#Network work rate (%)#Number of nodesCLSS1CLSS2AO(f)Figure 2.6: Simulation analysis: network lifetime of CLSS1, CLSS2 and AO schemes for mobile user 1 (a),mobile user 2 (b) and mobile user 3 (c); network work rate of CLSS1, CLSS2 and AO schemes for mobileuser 1 (d), mobile user 2 (e) and mobile user 3 (f). Both CLSS1 and CLSS2 own longer network lifetimethan AO. CLSS1 achieves lower network work rate than AO and CLSS2 achieves the same network workrate as AO. CLSS1 owns larger network lifetime and lower network work rate than CLSS2.402.4. Numerical Resultsare greatly enhanced with either CLSS1 or CLSS2, compared with that with AO scheme. Moreover, thenetwork work rate of CLSS1 and CLSS2 as well as AO schemes in theory and in simulation for variousmobile users are depicted from Fig. 2.5(d) to Fig. 2.5(f) and Fig. 2.6(d) to Fig. 2.6(f), respectively.These six pictures demonstrate that the WSN work rate of MCC-WSN integration with CLSS1 scheme ismuch lower than that with AO scheme, while the WSN work rate of MCC-WSN integration with CLSS2scheme is the same as that with AO scheme.In addition, with respect to CLSS1 and CLSS2, compared with CLSS2, the network lifetime withCLSS1 presented in Fig. 2.5(a) to Fig. 2.5(c) and Fig. 2.6(a) to Fig. 2.6(c) is longer. The networkwork rate in CLSS1 is lower than that in CLSS2, which are shown in Fig. 2.5(d) to Fig. 2.5(f) andFig. 2.6(d) to Fig. 2.6(f). However, CLSS2 is more scalable and robust to unexpected mobile user datarequests compared with CLSS1, since a subset of sensor nodes in CLSS2 still form a connected networkand transmit the collected sensory data to the cloud, even when the location of the mobile user is not inthe location list.2.4.3 SummaryFrom the above evaluation results in both theory and simulation, we can achieve the following.• 1) In terms of CLSS schemes and AO scheme, all the theoretical results approximate all the simu-lation results very much.• 2) Comparing CLSS schemes and AO scheme, both CLSS1 and CLSS2 have longer network lifetimethan AO. In addition, CLSS1 has lower network work rate than AO and CLSS2 has the samenetwork work rate as AO.412.4. Numerical Results• 3) Comparing CLSS1 and CLSS2, CLSS1 owns larger network lifetime and lower network work ratethan CLSS2.42Chapter 3An Authenticated Trust and ReputationCalculation and Management System forCloud and Sensor Networks Integration3.1 System ModelThe system model in this chapter is shown as follows, while the main used notations in this chapter aresummarized in Table 3.1 and Table 3.2.• There are multiple CSUs, CSPs and SNPs. The number of CSU, CSP and SNP are Nu, Nc andNk, respectively. CSUSet = {CSU1, CSU2, . . . , CSUNu}. CSPSet = {CSP1, CSP2, . . . , CSPNc}.SNPSet = {SNP1, SNP2, . . . , SNPNk}.• Each CSU, CSP and SNP have several attributes. Particularly, the data service requested andrequired by the CSU owns the following attributes: data service pay (DSP); data type (DT);data size (DS); data request speed (DRS); data service time (DST). The cloud service provided andmanaged by each CSP has the following characteristics: cloud service charge (CSC); cloud operation433.1. System ModelTable 3.1: Main notation definitions in Chapter 3Symbol DefinitionCOC Cloud Operation CostCPS Cloud Processing SpeedCRT Cloud Response TimeCSC Cloud Service ChargeCSN Cloud Server NumberCSP Cloud Service ProviderCSPSet Set of CSPsCSS Cloud Storage SizeCST Cloud Service TypeCSU Cloud Service UserCSUSet Set of CSUsDRS Data Request SpeedDS Data SizeDSP Data Service PayDST Data Service TimeDT Data TypePLA Privacy Level AgreementSLA Service Level AgreementSNC Sensor Network CoverageSNL Sensor Network LifetimeSNN Sensor Node NumberSNOC Sensor Network Operation CostSNP Sensor Network ProviderSNPSet Set of SNPsSNRT Sensor Network Response TimeSNSC Sensor Network Service ChargeSNSP Sensor Network Service PaySNT Sensor Network ThroughputST Sensor TypeTCE Trusted Center Entity443.1. System ModelTable 3.2: Main notation definitions continued in Chapter 3Symbol DefinitionCbc Acceptable range for CcCbk Acceptable range for Ck|Cbc| Interval of Cbc|Cbk| Interval of CbkCc CSC-DSPCk SNSC-SNSPctc Certificate of CSPctk Certificate of SNPRc Reputation value of service provided by CSPRk Reputation value of service provided by SNPRsc Minimum acceptable reputation value for service of CSPRsk Minimum acceptable reputation value for service of SNPTcu Trust value of service from CSP to CSUTkc Trust value of service from SNP to CSPTscu Minimum acceptable trust value of service from CSP to CSUTskc Minimum acceptable trust value of service from SNP to CSPαc Weight with respect to the importance of Ccαk Weight with respect to the importance of Ckβc Weight with respect to the importance of Tcuβk Weight with respect to the importance of Tkcγc Weight with respect to the importance of Rcγk Weight with respect to the importance of Rk453.1. System Modelcost (COC); sensor network service pay (SNSP); cloud service type (CST); cloud server number(CSN); cloud storage size (CSS); cloud processing speed (CPS); cloud operation time (COT); cloudresponse time (CRT). The sensor network offered and managed by each SNP is with the followingproperties: sensor network service charge (SNSC); sensor network operation cost (SNOC); sensortype (ST); sensor node number (SNN); sensor network coverage (SNC); sensor network throughput(SNT); sensor network lifetime (SNL); sensor network response time (SNRT).• There is a trust value (i.e., Tcu) of each service from each CSP to each CSU and there is a trustvalue (i.e., Tkc) of each service from each SNP to each CSP. In addition, there is a reputation value(i.e., Rc) of each service provided by each CSP and there is a reputation value (i.e., Rk) of eachservice provided by each SNP.• Each CSU owns a minimum acceptable trust value (i.e., Tscu) of each service from each CSP to theCSU. Moreover, each CSP has a minimum acceptable trust value (i.e., Tskc) of each service fromeach SNP to the CSP. Similarly, each CSU owns a minimum acceptable reputation value (i.e., Rsc)with respect to each service of each CSP. And each CSP has a minimum acceptable reputation value(i.e., Rsk) in terms of each service of each SNP.• There is a cost difference (i.e., Cc) between the CSC of CSP and DSP of CSU for each service, i.e.,Cc=CSC-DSP.• There is a cost difference (i.e., Ck) between the SNSC of SNP and SNSP of CSP for each service,i.e., Ck=SNSC-SNSP.• Each CSU owns an acceptable range (i.e., Cbc) about Cc. In addition, each CSP owns an acceptablerange (i.e., Cbk) about Ck. The interval of Cbc and Cbk are |Cbc| and |Cbk|, respectively.463.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNP• Each CSU has three weights (i.e., αc, βc and γc) in terms of the importance of Cc, Tcu and Rc, whileαc + βc + γc = 1. Similarly, each CSP owns three weights (i.e., αk, βk, γk) about the importance ofCk, Tkc and Rk, while αk + βk + γk = 1.3.2 Authentication of CSP and SNP as well as Trust and Reputationof Service of CSP and SNPIn this section, we first discuss the authentication of CSP and SNP. With that, we give some preliminariesabout service level agreement (SLA) and privacy level agreement (PLA), followed with the preliminariesof trust and reputation and the preliminaries of trusted center entity (TCE). Finally, we discuss andanalyze the trust and reputation with respect to the service of CSP and SNP respectively.3.2.1 Authentication of CSP and SNPIn this chapter, as the key of our work is to enable CSU to choose the authentic and desirable CSP aswell as assist CSP in selecting genuine and appropriate SNP, we focus on the authentication of CSP andSNP rather than the authentication of CSU. Specifically, the CSP needs to prove its authenticity to CSUand SNP has to show its authenticity to CSP. Here, ISO/IEC 27001 certification [47] [48] is applied toauthenticate CSP and SNP, as it is an internationally recognized information security management sys-tem (ISMS) standard by the International Organization for Standardization (ISO) and the InternationalElectrotechnical Commission (IEC). It requires that the information management of an organization (e.g.,CSP or SNP) meets (i) the organization’s information security risks are systematically examined; (ii) acoherent and comprehensive suite of information security controls is designed and implemented to solve473.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNPthose risks that are deemed unacceptable; (iii) an overarching management process is adopted to ensurethat the information security controls continue to satisfy the organization’s information security needson an ongoing basis. Particularly, it provides confidence and assurance to trading clients of the organiza-tion, as the security status of the organization is audited to be qualified, by issuing a certificate with theISO/IEC 27001 certification. After CSP and SNP are certificated with ISO/IEC 27001, they obtain thecertificates (i.e., ctc and ctk) respectively.3.2.2 Preliminaries of SLA and PLAAn SLA [49] [50] is a negotiated agreement between two or more parties, in which one is the customerand the others are service providers. In short, it is a part of a service contract, in which a service isformally defined. SLA specifies the levels of availability, serviceability, performance, operation and otherattributes of the service. Usually, an SLA addresses the following segments about a service: definition,performance measurement, problem management, duties, warranties, termination. The subject of SLA isthe result of the service received by the customer.An PLA [51] is an agreement to describe the level of privacy protection that the CSP will maintain.Thus it is an appendix to the SLA between CSU and CSP. The SLA between CSU and CSP providesspecific parameters and minimum levels on other performance (e.g., cloud processing speed, cloud oper-ation time) of the cloud service, while PLA addresses information privacy and personal data protectionissues about the cloud service.483.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNP3.2.3 Preliminaries of Trust and ReputationDefined by Merriam Webster’s Dictionary, trust is “assured reliance on the character, ability, strength ortruth of someone or something” and reputation is “overall quality or character as seen or judged by peoplein general”. However, trust and reputation are multidisciplinary concepts with different definitions andevaluations in various fields (e.g., psychology, sociology, economics, philosophy, wireless networks) [52][53] [54]. For example, in the scenario of wireless communications, “Trust of a node A in a node B isthe subjective expectation of node A receiving positive outcomes from the interaction with node B in aspecific context”. Also, “Reputation is the global perception of a node’s trustworthiness in a network”.Generally, to evaluate trust from an entity (e.g., A or trustor) to another entity (e.g., B or trustee), Aneeds to gather evidence (e.g., honest, selfish, malicious behaviors), representing the satisfaction, aboutB either through direct interaction or information provided by third-parties [52], [53] [54]. With that,trustor (A) maps the gathered information from the evidence space to the trust space through a prede-fined mapping function and an aggregation function to obtain the trustworthiness value of trustee (B).Specifically, the trustworthiness obtained by mapping evidences from direct interaction is known as directtrust, while the trustworthiness achieved through mapping evidences from third-parties is indirect trust.Furthermore, a trustor can bring into account recent trust, which reflects only the recent behaviors, as wellas historical trust, which is built from the past experiences and it reflects long-term behavioral pattern.For instance, using indirect trust and historical trust helps trustor to protect trust evaluation (and trustsystem in general) from attacks such as good mouthing and bad mouthing, or sudden selfishness of atrustee. More discussion about these terms and definitions can be found in our references, for instance in[55]. In addition, to evaluate reputation about a trustee (e.g., B), the aggregated trust opinion of a groupof entities are usually taken to represent the reputation value [56] [57].493.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNPA widely used way to map the observed information from the evidence space to the trust space isthe beta distribution [58] [59] [60] illustrated as follows. Let s and f represent the (collective) amount ofpositive and negative feedbacks in the evidence space about target entity, then the trustworthiness t of asubject node is then computed as t = s+1f+s+2 .3.2.4 Preliminaries of TCEIn this chapter, based on the five main roles (e.g., cloud customer, cloud provider, cloud broker, cloudauditor and cloud carrier) in CC [61], we assume that the role of the cloud auditor is assigned to TCE.Furthermore, we assume that TCE consists of multiple entities in various locations with a shared andsecured database, e.g., in a data center. Specifically, the duties of TCE are introduced as follows.• Duty 1) Receiving the copies of signed SLAs and PLAs from CSUs, CSPs and SNPs.• Duty 2) Receiving the feedbacks from CSUs about the services of CSPs and receiving the feedbacksfrom CSPs about the services of SNPs, based on signed SLAs and PLAs.• Duty 3) Auditing whether received copies are genuine as well as auditing whether received feedbacksthat are to be utilized to calculate Tcu, Tkc, Rc and Rk are genuine, by security audit, privacy impactaudit and performance audit, and etc. [62].• Duty 4) Calculating and managing (i.e. storing and updating) Tcu, Tkc, Rc and Rk, with the genuinehistorical feedbacks received from CSUs about the services of CSPs and the genuine historicalfeedbacks from CSPs about the services of SNPs based on genuinely signed SLAs and PLAs.• Duty 5) Replying Tcu, Tkc, Rc and Rk values if these values are requested by CSUs or CSPs.503.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNP• Duty 6) Auditing whether the Tcu, Tkc, Rc and Rk values received by CSUs and CSPs are genuine,by security auditing, privacy impact auditing and performance auditing, and etc. [62].• Duty 7) Monitoring the process of the proposed ATRCM system to detect misbehaviors of CSUs,CSPs or SNPs that affect the process of ATRCM.3.2.5 Trust of Service of CSPFrom Fig. 1.1, we can obtain that the fulfillment of service of CSP needs to receive and store the rawsensory data from SNP first. Then CSP processes the raw sensory data and stores the processed sensorydata. Finally, CSP transmits the processed sensory data to CSU on demand. In this process, there arevarious types of trust (e.g., cloud data storage trust, cloud data processing trust, cloud data privacy trust,cloud data transmission trust) which might concern the CSU to choose the service of CSP. Furthermore,for various CSUs, the types of trust that they concern are different.In this chapter, we assume that the following three types of trust about CSP concern the CSU tochoose the service of CSP and we further show how they are calculated.• i) Cloud data processing trust: This trust is related to whether cloud processes the raw sensory datawith error. TCE has a database which dynamically stores the non-error number (i.e., Sc1) and errornumber (i.e., Fc1) of data processing of each service from CSP to the CSU in the history, with thefeedbacks about the historical SLAs regarding the service. The trust value of cloud data processingtrust (i.e., Tc1) is calculated by TCE via equation (3.1).Tc1 =Sc1 + 1Fc1 + Sc1 + 2(3.1)513.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNP• ii) Cloud data privacy trust: This trust is about whether the sensory data stored on cloud can beaccessed by others. Based on the feedbacks about previous PLAs regarding the service, assume thenumber that the sensory data accessed by others with respect to each service from CSP to CSU inthe history stored on TCE database is Fc2. As CSU is generally sensitive about the data privacy,the trust value of cloud data privacy trust (i.e., Tc2) is presented by TCE through equation (3.2).Tc2 =1, Fc2 = 00, Fc2 > 0(3.2)• iii) Cloud data transmission trust: This trust is with respect to whether the data transmission fromCSP to CSU is successful. Using the feedbacks of previous SLAs regarding the service, with thesuccess number (i.e., Sc3) and failure number (i.e., Fc3) of data transmission of each service fromCSP to the CSU in the history on TCE database, the cloud data transmission trust (i.e., Tc3) isshown by TCE as per equation (3.3).Tc3 =Sc3 + 1Fc3 + Sc3 + 2(3.3)In summary, with respect to Tcu value calculation, the trust value Tcu of each service from CSP toCSU is calculated by TCE with a combination function (i.e. CF ) of three-dimensional trust (i.e., clouddata processing trust, cloud data privacy trust and cloud data transmission trust), as per equation (3.4).Tcu = CF (Tc1, Tc2, Tc3) (3.4)523.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNPSpecifically, about CF , there are many different ways to combine multi-dimensional trust. For exam-ple, a probabilistic trust model based on the Dirichlet distribution to combine multi-dimensional trustis shown in [63], by estimating the probability that each contract dimension will be successfully fulfilledas well as the correlations between these estimates. In addition, an MeTrust model is presented in [64],enabling each user to choose a dimension as a primary dimension and put different weights on differentdimensions for trust calculation.In this chapter, we assume that these three types of trust (i.e., cloud data processing trust, cloud dataprivacy trust and cloud data transmission trust) are considered with equal weight and then the minimumtrust value in these three trust values is taken as Tcu, through equation (3.5).Tcu = Minimum{Tc1, Tc2, Tc3} (3.5)3.2.6 Reputation of Service of CSPIn this chapter, based on the feedbacks of previous SLAs about the service, we assume that if the CSUchose the service of the CSP, then it means that the CSU somehow trusted that CSP and decided touse the service of the CSP. Let us assume that the number of CSUs that chose the service of the CSP isCNc and the number of CSUs that needed the service to receive from a CSP is N′u (N′u ≤ Nu). Then thereputation value (i.e., Rc) of the service of the CSU is calculated by TCE following [56] [57] via equation(3.6).Rc =CNcN ′u(3.6)533.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNP3.2.7 Trust of Service of SNPBased on Fig. 1.1, we can also observe that the service of SNP requires the sensor nodes to be deployedfirst and then sense, store and process data to achieve data collection. At last, the collected sensory dataare transmitted from SNP to the CSP.Similarly, in this chapter, we assume that the following four kinds of trust about SNP consist of thetrust of service of SNP in the above process.• i) Sensor data collection trust: This trust concerns whether the sensor network collects the requiredsensory data with error. Utilizing the feedbacks of previous SLAs regarding each service, given thatthe non-error number and error number of data collection of each service from SNP to CSP in thehistory on the TCE database are Sk1 and Fk1, respectively. The trust value of sensor data collectiontrust (i.e., Tk1) is calculated by TCE as follows.Tk1 =Sk1 + 1Fk1 + Sk1 + 2(3.7)• ii) Sensor network lifetime trust: This trust aims to analyze whether the lifetime of the real deployedsensor network matches the sensor network lifetime the SNP demonstrates, as energy consumptionis the primary concern of sensor network. Assume that the matching number and non-matchingnumber of the sensor network lifetime of each service from SNP to CSP in the history recorded byTCE are Sk2 and Fk2 respectively, with the feedbacks of historial SLAs regarding each service. Thesensor network lifetime trust (i.e., Tk2) is shown by TCE as follows.Tk2 =Sk2 + 1Fk2 + Sk2 + 2(3.8)543.2. Authentication of CSP and SNP as well as Trust and Reputation of Service of CSP and SNP• iii) Sensor network response time trust: This trust researches whether the response time of the realdeployed sensor network matches the sensor network response time the SNP demonstrates, since theresponse time of sensor network is with quite uncertainty due to various factors (e.g., sensor dies,bad weather). TCE records the matching number (i.e., Sk3) and non-matching number (i.e., Fk2)of the sensor network response time of each service from SNP to CSP in the history with feedbacksabout previous SLAs. The sensor network response time trust (i.e., Tk3) is obtained by TCE asfollows.Tk3 =Sk3 + 1Fk3 + Sk3 + 2(3.9)• iv) Sensor data transmission trust: This trust cares whether the data transmission from SNP toCSP is successful or not. TCE owns a database which dynamically stores the success number(i.e., Sk4) and failure number (i.e., Fk4) of data transmission of each service from SNP to the CSPin the history, based on the feedbacks of previous SLAs regarding each service. The sensor datatransmission trust value (i.e., Tk4) is presented by TCE as follows.Tk4 =Sk4 + 1Fk4 + Sk4 + 2(3.10)In summary, concerning Tkc value calculation, we also assume that these four types of trust (i.e.,sensor data collection trust, sensor network lifetime trust, sensor network response time trust and sensordata transmission trust) are considered equally and the minimum value of these four trust values is takenas the trust value Tkc of the service from SNP to CSP, calculated by TCE as follows:Tkc = Minimum{Tk1, Tk2, Tk3, Tk4} (3.11)553.3. Proposed ATRCM System3.2.8 Reputation of Service of SNPAbout Rk value calculation, with the feedbacks of previous SLAs about the service, given that if the CSPchose the service of an SNP, then it also means that the CSP somehow trusted the SNP and decided touse the service of the SNP. Further, denote that the number of CSPs that chose the service of the SNPis CNc and the number of CSPs that required the service to receive from a SNP is N′c (N′c ≤ Nc), thereputation value of the service of the SNP is calculated by TCE following [56] [57] as follows.Rk =CNkN ′c(3.12)3.3 Proposed ATRCM System3.3.1 System OverviewThe proposed authenticated trust and reputation calculation and management (ATRCM) system is in-troduced from the following three parts:• Part 1) Authentication flowchart of CSP and SNP;• Part 2) Trust and reputation calculation and management flowchart between CSU and CSPs;• Part 3) Trust and reputation calculation and management flowchart between CSP and SNPs.Specifically, Part 1) shown in Table 3.3 aims at a) identity authentication of CSP and SNP to avoidmalicious impersonation attacks, based on the certificate of ISO/IEC 27001 certification [47] [48] illus-trated in Section 3.2. In addition, Part 2) and Part 3) presented in Table 3.4 and Table 3.5 focus on563.3. Proposed ATRCM SystemTable 3.3: Authentication flowchart of CSP and SNPStep CSUs CSPs SNPsStart1 Provide ctc to CSU Provide ctk to CSP2 Check ctc and filter CSPs Check ctk and filter SNPsEndTable 3.4: Trust and reputation calculation and management flowchart between CSU and CSPsStep CSPs CSU TCE CSUStart1 Provide attributes Checks CSPs attributesand filters CSPs2 Issues requests to TCE Replies Tcu Checks Tcuand filters CSPs3 Issues requests to TCE Replies Rc Checks Rcand filters CSPs4 Calculates Cc5 Checks ctcand chooses the service of CSPand informs TCE6 Checks ctc and sends feedbacks Updates Tcu and RcEnd573.3. Proposed ATRCM SystemTable 3.5: Trust and reputation calculation and management flowchart between CSP and SNPsStep SNPs CSP TCE CSPStart1 Provide attributes Checks SNPs attributesand filters SNPs2 Issues requests to TCE Replies Tkc Checks Tkcand filters SNPs3 Issues requests to TCE Replies Rk Checks Rkand filters SNPs4 Calculates Ck5 Checks ctkand chooses the service of SNPand informs TCE6 Checks ctk and sends feedbacks Updates Tkc and RkEnd(b) calculation and management of trust and reputation with respect to the service of CSP and SNP aswell as (c) helping the CSU choose desirable CSP and assisting the CSP in selecting appropriate SNP,considering the attribute requirement of CSU and CSP as well as cost, trust and reputation of the serviceof CSP and SNP.3.3.2 Authentication Flowchart of CSP and SNP• Step 1: CSPs provide the certificate ctc to CSU and CSU checks whether the signature of thecertificate is valid and whether the certificate is revoked. CSU filters the CSPs that are not qualified.• Step 2: SNPs offer the certificate ctk to CSP and CSP checks whether the signature of the certificateis valid and whether the certificate is revoked. CSP filters the SNPs that are not qualified.583.3. Proposed ATRCM System3.3.3 Trust and Reputation Calculation and Management Flowchart between CSUand CSPs• Step 1: CSU checks whether the characteristics of CSPs satisfy the attribute requirement of CSU.Filter the CSPs that are not satisfied.CST ⊇ DTCSS ≥ DSCPS ≥ DRSCOT ≥ DST(3.13)• Step 2: CSU issues requests to TCE and achieves the Tcu value of the service from CSP to the CSU.CSU checks whether the Tcu value is greater than or equal to the Tscu value. Filter the CSPs thatare not satisfied.Tcu ≥ Tscu (3.14)• Step 3: CSU issues requests to TCE and achieves the Rc value of the service offered by the CSP.CSU checks whether the Rc value is greater than or equal to the Rsc value. Filter the CSPs thatare not satisfied.Rc ≥ Rsc (3.15)593.3. Proposed ATRCM System• Step 4: CSU calculates the Cc value between CSC of CSP and DSP of CSU and checks whether theCc value is within the Cbc range. Filter the CSPs that are not satisfied.Cc ∈ Cbc (3.16)• Step 5: CSU checks whether ctc is revoked and chooses the service offered by the CSP with themaximum Mc and informs TCE about signed SLA or PLA.Mc = −αc · Cc|Cbc| + βc · Tcu + γc ·Rc (3.17)• Step 6: CSU checks whether ctc is revoked before using the service from the CSP. CSU sendsfeedbacks about the service of the CSP to TCE based on PLA and SLA after the termination ofservice. TCE stores and updates the Tcu value as well as the Rc value with the equations illustratedin Section 3.2.3.3.4 Trust and Reputation Calculation and Management Flowchart between CSPand SNPs• Step 1: CSP checks whether the characteristics of SNPs satisfy the attribute requirement of CSP.CSP also checks whether the characteristics of SNP satisfy the attribute requirement of CSU. Filterthe SNPs that are not satisfied.603.3. Proposed ATRCM SystemST ⊇ DTSNC ⊇ DSSNT ≥ DRSSNL ≥ DST(3.18)CST ⊇ STCSS ≥ SNCCPS ≥ SNTCOT ≥ SNL(3.19)• Step 2: CSP issues requests to TCE and receives the Tkc value of the service from SNP to the CSP.CSP checks whether the Tkc value is more than or equal to the Tskc value. Filter the SNPs that arenot satisfied.Tkc ≥ Tskc (3.20)• Step 3: CSP issues requests to TCE and receives the Rk value of the service offered by the SNP.CSP checks whether the Rk value is more than or equal to the Rsk value. Filter the SNPs that arenot satisfied.Rk ≥ Rsk (3.21)613.3. Proposed ATRCM System• Step 4: CSP calculates the Ck value between SNSC of SNP and SNSP of CSP and checks whetherthe Ck value is within the Cbk range. Filter the SNPs that are not satisfied.Ck ∈ Cbk (3.22)• Step 5: CSP checks whether ctk is revoked and chooses the service offered by the SNP with themaximum Mk and informs TCE about signed SLA or PLA.Mk = −αk · Ck|Cbk| + βk · Tkc + γk ·Rk (3.23)• Step 6: CSP checks whether ctk is revoked before utilizing the service of the SNP. After the end ofservice, CSP sends feedbacks about the service of SNP to TCE based on SLA and PLA. TCE storesand updates the Tkc value and the Rk value with the equations presented in Section 3.2.Note: In the aforementioned steps, during the utilization of the service, the ctc of the chosen CSP orthe ctk of the selected SNP may still be revoked. Furthermore, the Tcu or the Rc of the service of thechosen CSP may be lower than Tscu or Rsc, respectively. Similarly, the Tkc or the Rk of the service of theselected SNP is possible to be lower than Tskc or Rsk respectively. In such cases, the system flowchartsare performed again to enable the CSU to choose a new CSP or make the CSP select a new SNP. Inaddition, although the check of ctc, Tcu and Rc is the duty of CSU as well as the check of ctk, Tkc and Rkis the duty of CSP, TCE can support these duties for CSU and CSP as well if necessary.623.4. Evaluation of System Functionality3.4 Evaluation of System FunctionalityIn this section, we evaluate whether our proposed ATRCM system can fulfill the predetermined functions:a) authenticating CSP and SNP to avoid malicious impersonation attacks; b) calculating and managingtrust and reputation regarding the service of CSP and SNP; c) helping CSU choose desirable CSP andassisting CSP in selecting appropriate SNP, based on (i) the authenticity of CSP and SNP; (ii) theattribute requirement of CSU and CSP as well as (iii) the cost, trust and reputation of the service of CSPand SNP.3.4.1 Evaluation SetupTo perform the evaluation, all the three aimed functions are analyzed based on the flowcharts and processesof the corresponding functions. Particularly, the third function is evaluated utilizing two representativecase studies to demonstrate the effectiveness of ATRCM. Case study 1 involves a small quantities of CSUs,CSPs and SNPs, while case study 2 involves a large number of CSUs, CSPs and SNPs. The evaluationprocesses of the third function shown in these two case studies are universal for CSUs, CSPs and SNPswith other attributes and parameters.3.4.2 Evaluation ResultsAuthenticating CSP and SNPWith respect to the authentication of CSP and SNP, Part 1) authentication flowchart of CSP and SNPshown in Section 3.3 presents the detailed steps.Based on the flowchart, we can observe that if a malicious attacker impersonates the authentic CSP633.4. Evaluation of System Functionalityor authentic SNP, then it needs to own the ctc certificate or the ctk certificate first. If it cannot providea certificate, then it is not a genuine organization. In addition, even if the malicious attacker further a)offers a fake certificate (e.g., fctc or fctk) or b) provides a real but revoked certificate (e.g., rctc or rctk),it still cannot launch the impersonation attacks, since CSU and CSP check whether the signature of thecertificate is valid and whether the certificate is revoked.Thus, we can achieve that our proposed ATRCM system is able to prevent malicious impersonationattacks, by enforcing the CSP or SNP providing a valid certificate. Meanwhile, as the valid certificate ofCSP and SNP are obtained through ISO/IEC 27001 certification, the CSU will start trading with CSPand CSP will begin trading with SNP, with more confidence and assurance.Calculating and Managing Trust and Reputation of Service of CSP and SNPFor the calculation and management of trust and reputation with respect to the service of the CSP andSNP, the detailed processes are illustrated in Section 3.2.Particularly, calculation and management of trust regarding the service of the CSP are based on clouddata processing trust (i.e., Tc1 shown in equation (3.1)), cloud data privacy trust (i.e., Tc2 shown inequation (3.2)) and cloud data transmission trust (i.e., Tc3 shown in equation (3.3)). The minimum valueof Tc1, Tc2 and Tc3 is the trust value of the service of the CSP. Moreover, the history that CSUs chosethe service of the CSP and the history that CSUs needed the service to receive from a CSP are utilizedto calculate and manage the reputation about the service of the CSP (i.e., Rc shown in equation 3.6).Furthermore, calculating and managing the trust of the service of the SNP take sensor data collectiontrust (i.e., Tk1 presented in equation (3.7)), sensor network lifetime trust (Tk2 presented in equation(3.8)), sensor network response time trust (i.e., Tk3 presented in equation (3.9)) as well as sensor data643.4. Evaluation of System Functionalitytransmission trust (i.e., Tk4 presented in equation (3.10)) into account. The trust value of the service ofthe SNP is the minimum value of Tk1, Tk2, Tk3 and Tk4. Finally, the calculation and management of thereputation of the service of the SNP (i.e., Rk presented in equation (3.12)) are based on the history thatCSPs selected the service of the SNP and the history that CSPs required the service to receive from aSNP.From the above analysis, we can obtain that the proposed ARTCM system is capable of calculatingand managing the trust and reputation about the service of CSP and SNP.Helping CSU Choose Desirable CSP and Assisting CSP in Selecting Appropriate SNPRegarding helping CSU to choose desirable CSP as well as assisting CSP in selecting appropriate SNP,Part 2) Trust and reputation calculation and management flowchart between CSU and CSPs and Part 3)Trust and reputation calculation and management flowchart between CSP and SNPs shown in Section 3.3,present the detailed mechanisms to validate our demonstration. Specifically, from equation (3.17) andequation (3.23), we can see that the cost and trust as well as the reputation of the service of CSP andSNP are utilized for CSU and CSP to make the corresponding choice.Case Study 1: In the following sample case study, there are three CSUs, four CSPs and five SNPs.With the filter process of the Step 1 of Part 2) and Part 3), we assume that one CSP and two SNPs arefiltered out as their attributes do not satisfy the requirements. Then there are three CSUs, three CSPsand three SNPs, in which all characteristics of CSPs satisfy the attribute requirement of CSUs and allcharacteristics of SNPs satisfy the attribute requirement of CSPs.In the following, Table 3.6 shows the detailed parameters with respect to CSUs and qualified CSPsabout Cc, Tcu, Rc, Cbc, Tscu and Rsc, which will be used from Step 2 to Step 5 of Part 2). And table 3.7653.4. Evaluation of System FunctionalityTable 3.6: Parameters of CSUs and qualified CSPsCc Tcu Rc Cbc Tscu RscCSU1 ↔ CSP1 -10 0.7 0.8 [-30, 30] 0.5 0.5CSU1 ↔ CSP2 -15 0.8 0.7 [-30, 30] 0.5 0.5CSU1 ↔ CSP3 -20 0.9 0.6 [-30, 30] 0.5 0.5CSU2 ↔ CSP1 -15 0.7 0.8 [-30, 30] 0.5 0.5CSU2 ↔ CSP2 -20 0.8 0.7 [-30, 30] 0.5 0.5CSU2 ↔ CSP3 -25 0.9 0.6 [-30, 30] 0.5 0.5CSU3 ↔ CSP1 -20 0.7 0.8 [-30, 30] 0.5 0.5CSU3 ↔ CSP2 -25 0.8 0.7 [-30, 30] 0.5 0.5CSU3 ↔ CSP3 -30 0.9 0.6 [-30, 30] 0.5 0.5Table 3.7: Parameters of qualified CSPs and SNPsCk Tkc Rk Cbk Tskc RskCSP1 ↔ SNP1 -10 0.8 0.7 [-30, 30] 0.5 0.5CSP1 ↔ SNP2 -15 0.7 0.6 [-30, 30] 0.5 0.5CSP1 ↔ SNP3 -20 0.6 0.5 [-30, 30] 0.5 0.5CSP2 ↔ SNP1 -15 0.8 0.7 [-30, 30] 0.5 0.5CSP2 ↔ SNP2 -20 0.7 0.6 [-30, 30] 0.5 0.5CSP2 ↔ SNP3 -25 0.6 0.5 [-30, 30] 0.5 0.5CSP3 ↔ SNP1 -20 0.8 0.7 [-30, 30] 0.5 0.5CSP3 ↔ SNP2 -25 0.7 0.6 [-30, 30] 0.5 0.5CSP3 ↔ SNP3 -30 0.6 0.5 [-30, 30] 0.5 0.5Table 3.8: Weight set 1 of CSUs and corresponding choicesαc βc γc ChoiceCSU1 1/3 1/3 1/3 CSP3CSU2 1/2 1/4 1/4 CSP3CSU3 1/5 2/5 2/5 CSP3663.4. Evaluation of System FunctionalityTable 3.9: Weight set 1 of qualified CSPs and corresponding choicesαk βk γk ChoiceCSP1 1/3 1/3 1/3 SNP1CSP2 1/2 1/4 1/4 SNP1CSP3 1/5 2/5 2/5 SNP1Table 3.10: Weight set 2 of CSUs and corresponding choicesαc βc γc ChoiceCSU1 1 0 0 CSP3CSU2 0 1 0 CSP3CSU3 0 0 1 CSP1Table 3.11: Weight set 2 of qualified CSPs and corresponding choicesαk βk γk ChoiceCSP1 1 0 0 SNP3CSP2 0 1 0 SNP1CSP3 0 0 1 SNP1673.4. Evaluation of System Functionalitypresents the detailed parameters regarding qualified CSPs and SNPs, that will be utilized from Step 2 toStep 5 of Part 3) about Ck, Tkc, Rk, Cbk, Tskc and Rsk. Moreover, two typical weight sets about αc, βc,γc as well as αk, βk and γk are used to validate the effectiveness. In weight set 1, CSUs and CSPs takeCc, Tcu and Rc all into account. For weight set 2, CSUs and CSPs only consider one of Ck, Tkc and Rk.Weight set 1 of CSUs and the corresponding choices with respect to CSPs are shown in Table 3.8.Meanwhile, weight set 1 of qualified CSPs and the corresponding choices with respect to SNPs are shownin Table 3.9. With equation (3.17) and equation (3.23), we can get that CSU1, CSU2 and CSU3 allchoose CSP3 as shown in Table 3.8. In addition, CSP1, CSP2 and CSP3 all select SNP1 as presented inTable 3.9.Furthermore, Table 3.10 and Table 3.11 present weight set 2 of CSUs and the corresponding choiceswith respect to CSPs as well as weight set 2 of qualified CSPs and the corresponding choices with respectto SNPs, respectively. Similarly, based on equation (3.17) and equation (3.23), we can obtain that CSU1and CSU2 select CSP3 while CSU3 chooses CSP1 as presented in Table 3.10. Meanwhile, CSP1 choosesSNP3 while CSP2 and CSP3 both select SNP1 as shown in Table 3.11.Case Study 2: In the following sample case study, there are one hundred CSUs, one hundred and fiftyCSPs and two hundred SNPs. With the filter process of the Step 1 of Part 2) and Part 3), we suppose thatfifty CSPs and one hundred SNPs are filtered out as their characteristics are not satisfied. Then thereare one hundred CSUs, one hundred CSPs and one hundred SNPs, in which all characteristics of CSPssatisfy the attribute requirement of CSUs and all characteristics of SNPs satisfy the attribute requirementof CSPs.In the following, the detailed parameters with respect to CSUs and qualified CSPs about Cc, Tcu, Rc,Cbc, Tscu and Rsc are randomly initialized and they will be utilized from Step 2 to Step 5 of Part 2).683.4. Evaluation of System Functionality 0 10 20 30 40 50 60 70 80 90 100 0  10  20  30  40  50  60  70  80  90  100#Corresponding choice about CSP#Different weight set for a CSUFigure 3.1: Different weight set for a CSU and corresponding choice about CSPSimilarly, the detailed parameters about qualified CSPs and SNPs are randomly initialized and they willbe used from Step 2 to Step 5 of Part 3) about Ck, Tkc, Rk, Cbk, Tskc and Rsk. In addition, one hundreddifferent weight sets about αc, βc, γc as well as αk, βk and γk are randomly initialized to validate theeffectiveness.Different weight sets for a CSU and the corresponding choices regarding CSPs are shown in Fig. 3.1.Meanwhile, different weight sets for a qualified CSP and the corresponding choices regarding SNPs areshown in Fig. 3.2. With equation (3.17) and equation (3.23), we can get that the CSU can choose CSPand CSP can choose SNP as shown in Fig. 3.1 and Fig. 3.2, respectively.693.4. Evaluation of System Functionality 0 10 20 30 40 50 60 70 80 90 100 0  10  20  30  40  50  60  70  80  90  100#Corresponding choice about SNP#Different weight set for a qualified CSPFigure 3.2: Different weight set for a qualified CSP and corresponding choice about SNPSummaryFrom the above evaluation results, we can observe that our proposed ATRCM system is indeed ableto assist the CSU in selecting authentic and desirable CSP as well as help CSP choose authentic andappropriate SNP, considering (i) the authenticity of CSP and SNP and (ii) the attribute requirement ofCSU and CSP as well as (iii) the cost, trust and reputation of the service of CSP and SNP.Moreover, we can deduce that different weight sets do not always change the corresponding results forCSU to choose CSP, by comparing the weight sets and corresponding choices about CSPs in Table 3.8with that in Table 3.10 and observing the corresponding choices about CSPs with different weight sets703.5. Analysis of System Securityshown in Fig. 3.1. Similarly, the corresponding choices for CSP to select SNP are not always be affectedby changing weight sets, comparing the weight sets and corresponding choices about SNPs in Table 3.9with that in Table 3.11 and observing the corresponding choices about SNPs with different weight setspresented in Fig. 3.2.3.5 Analysis of System SecurityIn this section, we analyze our proposed ATRCM system from the view of security by providing a fewadversary models, in which we follow Dolev-Yao approach [65]. Particularly, we analyze whether ATRCMis immune to the following four attacks [66] [67] (i.e., good mouthing attack, bad mouthing attack,collusion attack and white-washing attack).3.5.1 First Adversary Model: Good Mouthing and Bad Mouthing AttacksMechanismThe adversary (e.g., a malicious CSU or a malicious CSP) provides a malicious feedback about its experi-ence with another party (a CSP or a SNP). For example, a malicious CSU provides a malicious feedbackabout its experience with a CSP or a malicious CSP provides a malicious feedback about its experiencewith a SNP, even if the experience actually does not exist. The feedback could be wrong positive feedback(i.e., good mouthing attack) or wrong negative feedback (i.e., bad mouthing attack).713.5. Analysis of System SecurityInitial CapabilityThe adversary knows the operational mechanism of ATRCM system and is free to produce wrong feedbacksabout any service of any CSP or any SNP.Capability during the AttackDuring the attack, the adversary is able to send feedbacks periodically to the TCE about the experiencevia a secure communication.DiscussionThe good mouthing and bad mouthing attack cannot maliciously subvert the trust or reputation value asthe adversary wishes, because of the following:• False feedbacks from the adversary to the TCE will not be utilized to calculate the trust or reputationvalue, as whether the feedbacks received by TCE are genuine are audited by TCE.• The trust and reputation of a CSP or a SNP on providing a service are largely dependent on thehistorical feedbacks of previous SLAs or PLAs about the service, meaning that the historical trustvalues can effectively maintain the trust or reputation.3.5.2 Second Adversary Model: Collusion AttackMechanismThe adversaries (i.e., malicious CSUs or malicious CSPs or malicious SNPs) collude other parties mutu-ally (e.g., a malicious CSU collude a malicious CSP or a malicious CSP collude a malicious SNP) and723.5. Analysis of System Securityparticipate in events that generate real positive feedbacks for the colluding participants.Initial CapabilityThe adversaries know about the operational mechanism of ATRCM system and they are free to colludeany CSP or any SNP mutually.Capability during the AttackDuring the attack, the adversaries are able to to change their colluding parties dynamically, withoutnoticing TCE.DiscussionFrom [68], since the colluders are synthesizing events that create verifiable feedbacks between CSUs andCSPs or between CSPs and SNPs in a collective way, they are able to improve their trust and reputationvalues faster than the honest participants or counter the effects of possible negative feedbacks. Thus, itis hard to mitigate the collusion attack, without detecting and reacting to the groups of colluders whointeract exclusively with each other, while discovering these colluders that are formulated as discoveringa clique of a certain size within a graph is known to be NP-complete and only heuristic-based solutionshave been proposed.On the other hand, to launch the collusion attack, since TCE is supposed to be informed about thesigned SLAs or PLAs and TCE is capable of monitoring the process of system (i.e., TCE has the roleof the cloud auditor), TCE should sense the service delivery at the minimum. Therefore, in case of thisattack, the colluding participants should initially report dummy SLAs or PLAs to TCE followed by bogus733.5. Analysis of System Securityfeedbacks, and then do not actually deliver the service. However, if the service delivery is not actuallyperformed, TCE will detect this. Thus, TCE can detect this attack and further filter out the bogusfeedbacks.Note: In case of the first and second adversary models, since in the trust and reputation managementsystem punishment is a normal action after finding a malicious entity, the TCE punishes the attacker.For instance, the TCE can filter out the feedbacks initiated by an adversary after finding an attacklunched by the adversary. Then, the TCE can decrease the services provided to the adversary to punishthe adversary. Therefore, these attacks are costly for the adversary and the high cost can prevent theadversary to perform the attacks.3.5.3 Third Adversary Model: White-Washing AttackMechanismThe adversary (e.g., a malicious CSP or a malicious SNP) resets a poor trust or reputation, by rejoiningthe system with a new identity and a fresh trust or reputation.Initial CapabilityThe adversary knows the operational mechanism of ATRCM system, and is free to re-enter the systemat any time with a new identity and a fresh trust or reputation.Capability during the AttackDuring the attack, the adversary is able to switch their identities dynamically, without informing TCE.743.5. Analysis of System SecurityDiscussionThe white-washing attack cannot mislead the honest customers by resetting a poor trust or reputationas the adversary wishes, because of the following:• In case of a malicious CSU, the adversary can rejoin the system only to lunch other attacks suchas bad mouthing attack. However, since the trust and reputation evaluation of CSU is not withinour system targets, rejoining the system does not affect the trust or reputation value of the CSU.In fact, these two values are not utilized by ATRCM system.• When a malicious CSP or a malicious SNP rejoins the system as a new identity, it needs to beauthenticated by the CSU or the CSP based on the ISO/IEC 27001 certification, then the CSU orthe CSP will know its original identity and rejoining purpose.• The trust and reputation are different in the ATRCM system in terms of newcomers and participantsthat have shown good behaviors for a long time. Thus, it is hard to cheat the honest customers byletting them easily choose newcomers.• Finally, even if the adversary resets its negative trust value and restarts as a fresh entity, in return theadversary loses its reputation completely (as per equation (3.6) and equation (3.12)). Furthermore,the reputation is a positive value all the time, and resetting it puts the adversary in a vulnerableand risky position of not being selected by any customer for a long time (as per equation (3.17) andequation (3.23)).75Chapter 4Towards Offering More Useful DataReliably to Mobile Cloud from WirelessSensor Network4.1 Usefulness of Sensory Data and Reliability of WSN4.1.1 Usefulness of Sensory DataIn the context of WSN-MCC integration, this chapter considers the usefulness of sensory data accordingto whether the sensory data offered by the WSN is eventually utilized by the cloud to satisfy the datarequests from mobile users. We observe that characteristics of user data requests are key factors thataffect the usefulness of sensory data.User Data Request CharacteristicsThe behavior that a user issues data requests to the cloud is usually characterized by Time [69] [70]. Forexample, it is very common in our daily life that “usually someone (say, Bob) will do something (say,764.1. Usefulness of Sensory Data and Reliability of WSNwatch a talk show) with some mobile device during some time period (e.g., 2:00 pm to 3:00 pm)”. Inaddition, the content of the data requested by a user usually has Priority [70] [71]. For instance, althoughthe traffic information of the whole city has some value to a certain extent, a lot of mobile users maybe more interested in the traffic information of the downtown than the traffic information in a quietcountryside during the same time period. Meanwhile, a substantial number of mobile users may only beinterested in the traffic information of a certain set of places (e.g., company, living residence, restaurant,school) among all the places in the city.In short, the transmitted data from the WSN to the cloud may not be fully utilized by the cloudto satisfy the mobile users’ data requests, as mobile users generally issue data requests for some certaincontents for a specific time period. Thus, it is not necessary for the WSN to always transmit all the sensorydata to the cloud, since it is not efficient and it also increases the transmission bandwidth requirementand exacerbates the network traffic.However, all sensory data still need to be able to be collected by sensors, as mobile users may requestdata from any sensor at any time, though with highly varied probabilities. In this chapter, since usuallythe data request behaviors of mobile users are characterized by time and priority and there are variousfactors (e.g., communication interference, network congestion, limited bandwidth) [72] [73] that affectthe data gathering and data transmission latency, we ignore the issue regarding latency of gathering andtransmitting data to satisfy data requests from mobile users.4.1.2 Reliability of WSNIn WSN-MCC integration, one aspect of WSN reliability relates to whether the WSN is continuously ableto gather and transmit the sensory data to the cloud successfully. We observe the following critical issues774.1. Usefulness of Sensory Data and Reliability of WSNconcerning the reliability of WSN.Depletion of Sensor EnergyGenerally, sensors will deplete their limited battery power by performing data sensing, processing andtransmission after a certain period of time, as they are often equipped with batteries that are not recharge-able and battery replacement may also be impractical [74] [75]. Particularly, the sensors close to thegateway are serving as intermediary nodes that forward most packets to the gateway on behalf of thesource nodes. Therefore they may deplete their energy sooner than other sensors and form holes in theWSN where no data can be collected for the cloud, or cause the WSN to be disconnected.Failures in Sensory Data TransmissionsThe data transmissions from one sensor to another sensor and from the WSN to the cloud may encounterfailures or losses, due to various factors such as network congestion, limited bandwidth or interference[72] [76]. In such cases, if the WSN does not perform data retransmission, then the cloud cannot obtainthe sensory data coming from the WSN. In this chapter, we consider that this reliability issue is alwaysovercome through data retransmissions.Limit in Storage Space for Sensory DataAs stated in [77], data storage is a very serious issue for WSN, since a large volume of collected dataneeds to be archived for future information retrieval. In addition, when sensors are deployed to gathermultimedia data such as images or videos that usually have large sizes, this further aggravates the demandon sensory data storage space. If the sensors do not have available storage space to store the sensed data,784.2. WSN-MCC Integration System Modelthen the cloud cannot obtain any sensory data, even if the sensors have enough residual energy to gatherand transmit data and the data transmissions from WSN to cloud are successful. In this chapter, weassume that sensors have sufficient storage space.In this chapter, we do not consider the sensory data transmission failure and sensory data storagespace limit issues for reasons given above, but instead focus on the sensor energy depletion issue, whichstrongly affects the reliability of a WSN.4.2 WSN-MCC Integration System ModelThe WSN-MCC integration system is modeled and analyzed in this chapter based on the followingassumptions.• There is one cloud C and M mobile users (i.e., U = (u1, u2, . . . , uM )) as well as M WSNs (i.e.,WSN = (wsn1, wsn2, . . . , wsnM )). Each WSN gathers and transmits data to the cloud to satisfythe data requests from each corresponding mobile user.• Each WSN consists of one gateway g as well as N sensor nodes (i.e., I = (i1, i2, . . . , iN )).• Each gateway g is externally powered with an unlimited energy supply. Each sensor node i hasa limited energy supply powered by a non-rechargeable and non-replaceable battery, which has aninitial energy eo and a residual energy ei.• Time is divided into Z time periods (i.e., T = (t1, t2, . . . , tZ)).794.3. TPSDT and PSSTable 4.1: Example of point vs time & priority (PTP) tablePoint of Interest 9 am-10 am 10 am-11 am 11 am-12 pm 12 pm-1 pm . . .i1 10% 5% 20% 15% . . .i2 20% 5% 0% 15% . . .i3 20% 10% 0% 15% . . .i4 10% 10% 0% 10% . . .i5 20% 20% 0% 15% . . .i6 10% 20% 30% 15% . . .i7 5% 20% 40% 5% . . .i8 0% 5% 0% 5% . . .. . . . . . . . . . . . . . . . . .4.3 TPSDT and PSSIn this section, we present and discuss the proposed 1) TPSDT mechanism for WSN gateway to selectivelytransmit sensory data that are more useful to the cloud and 2) PSS mechanism for WSN to save energyconsumption so that it can gather and transmit data in a more reliable way.4.3.1 TPSDTThe difference between our proposed TPSDT and other selective data transmission methods (e.g., [78][79] [80]) in WSN is that TPSDT is the first method for WSN gateway to selectively transmit data to thecloud, considering the time and priority characteristics of the data requested by the mobile user. Thesecharacteristics are recorded in a Point vs Time & Priority (PTP) table maintained in the cloud for eachmobile user, where each point corresponds to a sensor node and the time reflects the specific time periodand the priority reflects the probability that the mobile user requests data from the corresponding sensornode during that time period.804.3. TPSDT and PSSPTP TableBased on the time and priority features illustrated in Section 4.1 about mobile user data requests, weconsider that the cloud is able to analyze the historical behaviors of mobile user data requests and thenmaintain a PTP table of each mobile user with respect to time and priority for sensor nodes of interest.An example of this PTP table reflecting the interest of a mobile user is shown in Table 4.1. Specifically,the probability that the data requests correspond to each point of interest, as shown in the PTP table,represents the priority of the requested data to the mobile user. A higher probability connected to a givenpoint in a specific time period means that the mobile user is more interested in that point and is morelikely to issue data requests for the point in that specific time period.Assume the number of data requests issued for a point of interest (e.g., sensor node i) during eachspecific time period t in the history is rti . In addition, given that the number of data requests issued to allpoints for each specific time period t in the history is Rt. The probability (i.e., pti) that the data requestsconcern the sensor node i in each specific time period t is calculated as follows.pti =rtiRt(4.1)In addition, for the whole WSN-MCC integration, there are Z time periods and N sensor nodes. Thus,1 =i=iN∑i=i1pti (t = t1, t2, . . . , tZ) (4.2)This PTP table obtained for each mobile user is updated dynamically by the cloud C and sent to thegateway g of each corresponding WSN.814.3. TPSDT and PSSDetails of TPSDTWith the PTP table, the process of our proposed TPSDT for each WSN gateway to selectively transmitdata that are more useful to the cloud is shown as follows.• 1) Each gateway g sets a timer, which records the current time.• 2) For each time period t, each gateway g sends the sensory data to the cloud C, according to thestart time and end time of t in the PTP table.• 3) Particularly, for the transmitted data content, each gateway g sends the sensory data gatheredby each sensor node in order, according to the priorities (i.e., probabilities in the PTP table). Thesensory data gathered by the points of interest with larger priorities are sent first, followed withsensory data collected by those with lower priorities. The sensory data coming from the points ofinterest with no priority (i.e., probability is 0%) in the PTP table are not transmitted.4.3.2 PSSThe difference between our proposed PSS and other sleep scheduling algorithms (e.g., [43] [44] [45] [81])in WSN is that PSS first incorporates the time and priority characteristics of the data requested by themobile user into the WSN sleep scheduling process to gather and transmit data for the cloud, with PTPtable.Design FactorsThe design of the proposed PSS algorithm considers the following three factors: 1) the points of interest(i.e., sensor nodes of interest in WSN) in the PTP table with probability larger than 0% should be awake824.3. TPSDT and PSSPseudocode of PSS algorithmFirst: Run the following at gateway g during each time period t.Step 1: Gateway g obtains PTP table.Step 2: If pti > 0, g sends flag A to node i.Step 3: Run the second part at each node i.Second: Run the following at each node i during each time period t.Step 1: Get the current residual energy rank ei.Step 2: Broadcast ei and receive the energy ranks of its currently awake neighbors Ni. Let Ei be theset of these ranks.Step 3: Broadcast Ei and receive Ej from each j ∈ Ni.Step 4: If |Ni| < k or |Nj | < k for any j ∈ Ni, remain awake. Go to Step 7.Step 5: Compute Ci = {j|j ∈ Ni and ej > ei}.Step 6: Go to sleep if both the following conditions hold. Remain awake otherwise.• Any two nodes in Ci are connected either directly themselves or indirectly through nodeswithin i’s 2-hop neighborhood that have e more than ei.• Any node in Ni has at least k neighbors from Ci.• It does not receive flag A.Step 7: Return.in each time period t, since mobile user requires sensory data gathered by these sensor nodes; 2) the wholesleep scheduled network should be connected so that data transmissions from sensor nodes to gateway canbe performed; 3) only a subset of all sensor nodes should be awake in each time period t to reduce energyconsumption - the sensor nodes that are scheduled to be awake should generally have more residual energythan the nodes that are scheduled to be asleep, so that network lifetime could be further prolonged.Details of PSSConsidering the above three design factors, the pseudocode of the proposed PSS algorithm is as shownabove.834.3. TPSDT and PSSAnalysis of PSSProperty 1: The PSS algorithm guarantees that sensor nodes required to satisfy the anticipated datarequests of mobile users are awake.Discussion: We discuss this property by observing the execution process of PSS. Particularly, withrespect to the sensor nodes from which mobile users require data, these sensor nodes are actually thepoints of interest in the PTP table with the corresponding probabilities larger than 0% (i.e., pti > 0).From step 2 of the first part of PSS, we can observe that sensor node i will receive flag A if pti > 0.Further, with step 6 of the second part of PSS, sensor nodes that receive the flag A cannot be asleep. Inother words, sensor nodes receiving flag A will all be awake so as to gather and transmit data requestedby the mobile users.Property 2: PSS algorithm maintains a connected network if the original network is connected.Discussion: We discuss this property by contradiction [43] [44] [45]. Given that the sleep schedulednetwork after running the PSS is not connected. Then, we put the deleted nodes (asleep nodes determinedby PSS) back in the network, in descending order of their energy ranks. Let i be the first sensor nodemaking the network connected again. Note that by the time we put i back, all the members of Ci arealready present and sensor nodes in Ci are already connected since they are connected by nodes withe > ei. Let v be a node that was disconnected from Ci but now is connected to Ci by i. Then, thiscontradicts the fact that i can sleep only if all its neighbors (including v) are connected to ≥ k nodes inCi (Step 6 of the second part of PSS).Property 3: The PSS algorithm prolongs the network lifetime compared with the always-on WSN.Discussion: We discuss this property by analyzing the execution results after running PSS algorithm.First, from the entire steps of PSS, we can observe that after PSS, there is a subset of sensor nodes that844.4. Proposed TPSS Schemedetermine to be awake and there is another subset of sensor nodes that are asleep. As only a subset ofsensor nodes need to be awake, the energy consumption will be saved and the network lifetime will beprolonged, compared with the always on WSN scheme in which all sensors are always awake.Second, based on step 6 of the second part of PSS, we can observe that after PSS, the asleep sensornodes satisfy that 1) Any two nodes in Ci are connected either directly themselves or indirectly throughnodes within i’s 2-hop neighborhood that have e more than ei. This constraint means that the awakenodes own more residual energy than the asleep sensor nodes after sleep scheduling. By letting the sensornodes with more residual energy rather than the sensor nodes with less residual energy be awake toperform data sensing, data storage and data processing, the network lifetime is further prolonged.4.4 Proposed TPSS Scheme4.4.1 OverviewFig. 4.1 shows the proposed TPSS scheme to gather and transmit sensory data for WSN-MCC integration,towards reliably offering data which are more useful to the mobile users from WSN to cloud. The detailedsteps of TPSS for each WSN to gather and transmit sensory data for each corresponding mobile user aredepicted as follows.• 1) Sensor nodes determine their awake and asleep states with PSS.• 2) Sensor nodes sense the environmental data with a set frequency and store the sensory data aswell as process the sensory data.• 3) Sensor nodes send the processed sensory data to the gateway g with the many to one and hop854.4. Proposed TPSS SchemeMobile userCloudSend data requestsTPSDTSend data queryData retransmissionSensor gatewayData processingSend data queryData retransmissionData storageData transmissionData retransmissionData request characteristicsData transmissionTimeProrityPowerful data processingPowerful data storagePSSVideo sensorMobile sensorStatic sensor Data processingData sensingData storageFigure 4.1: Proposed TPSS scheme to gather and transmit sensory data for WSN-MCC integration864.4. Proposed TPSS Schemeby hop pattern.• 4) Gateway g stores the received sensory data and then processes the sensory data.• 5) Gateway g selectively transmits the sensory data to the cloud C with TPSDT.• 6) Cloud C further stores and processes the received sensory data.• 7) If data transmission from i to g or g to C experiences data losses or failures, i or g performs dataretransmission until the data transmission is successful.• 8) Mobile user u issues data requests to cloud C and cloud C transmits the requested sensory datato the mobile user u.• 9) If data transmission from C to u encounters data losses or failures, C performs data retransmissionuntil the data transmission is successful.• 10) Cloud C dynamically updates the PTP table with equation (4.1) if the time and priority featuresof the requested data of the mobile user are changed and sends the updated PTP table to gatewayin each time period t.4.4.2 Scheme Characteristics and AnalysisFig. 4.2 shows the general scheme (GS) to gather and transmit sensory data for WSN-MCC integration.Comparing Fig. 4.2 and Fig. 4.1, based on the above introductions, we can see that our proposed TPSSshares the same technique with GS (i.e., data retransmission) to mitigate data transmission losses orfailures in sensory data transmissions for improving the reliability of WSN during WSN-MCC integration.874.4. Proposed TPSS SchemeSensor gatewayVideo sensorMobile sensorStatic sensorMobile userCloudSend data requestsSend data querySend data queryData processingData sensingData storageData transmissionData retransmissionData transmissionData retransmissionData processingData storagePowerful data processingPowerful data storageData transmissionData retransmissionFigure 4.2: General scheme (GS) to gather and transmit sensory data for WSN-MCC integration884.4. Proposed TPSS SchemeIn addition, we can observe that TPSS differs from GS to gather and transmit sensory data forWSN-MCC integration, with respect to the following two aspects.TPSDT for WSN GatewayIn our proposed TPSS, the gateway g selectively transmits the sensory data to the cloud C with TPSDT.This design is to enhance the usefulness of sensory data, since TPSDT data transmission is based onthe PTP table deduced from the time and priority features of the data requested by the mobile user.Thus, normally the successfully transmitted sensory data to the cloud will all be utilized to answer mobileuser data requests.In the case that the mobile user u issues data requests for sensory data currently not stored in thecloud C in the time period t, as the PTP table is dynamically updated with equation (4.1) if the timeand priority features of the requested data of the mobile user are changed in t (Step 10 of the TPSS),running the PSS algorithm with the updated PTP table in t makes the sensor nodes from which mobileuser requires data awake (property 1 of PSS). In other words, the cloud is capable of answering theunexpected data requests by dynamically updating PTP table.Moreover, as the sensory data are selectively transmitted from WSN gateway to the cloud with TPS-DT, the bandwidth requirement and network congestion are reduced meanwhile. This can also enhancethe reliability of WSN, as it alleviates the data transmission loss failure or loss issue to some extent.PSS for WSNIn our proposed TPSS, the sensor nodes dynamically determine their awake and asleep states accordingto PSS.894.5. EvaluationsThis design can greatly improve the reliability of WSN, since PSS can greatly save the energy con-sumption and prolong the network lifetime (property 3 of PSS) so that WSN can gather and transmit datalonger. Specifically, when sensors normally work for a certain period of time, the energy of the sensors willbe consumed very fast and sensor nodes will die and cannot work any more. With PSS, sensor nodes aredynamically awake and asleep and only a subset of sensor nodes with more residual energy are required tobe awake in each time period, this will greatly alleviate the sensory energy depletion issue that seriouslyaffects the reliability of WSN and the lifetime of WSN will be greatly enhanced.4.5 Evaluations4.5.1 Evaluation SetupTo perform evaluations, we compare our proposed TPSS with GS to gather and transmit sensory datafor WSN-MCC integration. Then we analyze whether our proposed TPSS is effective in enhancing theusefulness of sensory data and reliability of WSN.WSN-MCC Integration SystemWe assume that there is one cloud and 10 mobile users and 10 WSNs. Each WSN gathers and transmitsdata to the cloud, enabling it to reply to data requests from each corresponding mobile user. We furtherassume that each WSN consists of one gateway, which has an unlimited energy supply, and 100 sensornodes, each of which has an initial energy of 100000 mJ . Time is divided into 24 time periods, each onehour long. The detailed evaluation parameters are summarized in Table 4.2.904.5. EvaluationsTable 4.2: Evaluation parameters in Chapter 4Parameter Parameter valueNumber of clouds 1Number of users 10Number of WSNs 10Number of sensor nodes 100Number of gateways 1Initial sensor energy 100000 mJTime period 1 hourNetwork size 800×600 m2Default transmission radius 60 mTransmission energy 0.0144 mJReception energy 0.00576 mJTransmission amplifier energy 0.0288 nJ/m2Packet length 12 bytesNumber of packets 1000k in PSS 1Usefulness of Sensory DataThe usefulness of sensory data offered from a WSN to a cloud is evaluated, by analyzing how much theoffered data from the WSN to the cloud is utilized to answer mobile user data requests, as illustrated inSection 4.1.To analyze the usefulness of sensory data, the mobile user data request features (i.e., time and priorityof the data requested by the mobile user) have to be obtained first. Regarding this, we perform thefollowing experiment. We use a database resulting from 10 mobile users watching a surveillance videofor three consecutive weeks from 10:00 am to 4:00 pm. For each day, we observe the time and priorityof the data requested by the mobile users and they are transformed to different PTP tables. Then thesame 10 mobile users watch the same surveillance video for another three consecutive weeks from 10:00914.5. Evaluationsam to 4:00 pm and we analyze the usefulness of sensory data offered by TPSS and GS with the followingassumptions.For TPSS, we assume that the PTP tables are maintained by the cloud and further utilized by WSNgateways to transmit sensory data to the cloud with TPSDT for the 10 mobile users. For GS, we assumethat the WSN gateways will transmit all sensory data to the cloud for the 10 mobile users, withoututilizing the PTP tables. With that, the usefulness of sensory data which is actually the utility of thesensory data offered from the WSN to the cloud for each mobile user, could be respectively obtained forTPSS and GS as follows. Regarding TPSS, we analyze the percentage that the time and priority of therequested data of each mobile user observed in the previous three consecutive weeks are also observedin the subsequent three consecutive weeks. Regarding GS, we directly obtain the utility of the sensorydata offered from the WSN to the cloud for each mobile user, by comparing the whole surveillance videowith the content that each mobile user requests in the subsequent three consecutive weeks. The averageutility of the sensory data offered from WSN to the cloud for each mobile user in each week is taken asthe average usefulness of sensory data for each mobile user in each week.Reliability of WSNThe reliability of WSN is evaluated by analyzing how long the WSN is able to gather and transmit sensorydata to the cloud, as illustrated in Section 4.1. Specifically, we observe the network lifetime of WSN.In this chapter, the network lifetime of WSN is the time from the instant of network deployment to theinstant when the first sensor node runs out of energy [42].To analyze the reliability of WSN, we obtain the network lifetime of WSN in NetTopo [46], with eachPTP table for each mobile user in the subsequent three consecutive weeks. For both TPSS and GS, the924.5. Evaluations 0 20 40 60 80 100 1  2  3  4  5  6  7  8  9  10#Usefulness of sensory data (%)#Mobile userTPSSGS(a) 0 20 40 60 80 100 1  2  3  4  5  6  7  8  9  10#Usefulness of sensory data (%)#Mobile userTPSSGS(b) 0 20 40 60 80 100 1  2  3  4  5  6  7  8  9  10#Usefulness of sensory data (%)#Mobile userTPSSGS(c)Figure 4.3: Average usefulness of sensory data for each mobile user in week 1 (a); in week 2 (b) and inweek 3 (c)network size is 800×600 m2 and the default transmission radius is 60 m. The energy consumed by asensor to transmit and receive one byte are, respectively, 0.0144 mJ and 0.00576 mJ [45] [75] [82]. Theenergy consumed by a sensor to power-amplify each transmitted byte to cover the distance of 1 m is0.0288 nJ/m2 [45] [75] [82]. The packet length is 12 bytes and there are 1000 packets transmitted duringthe communication time of each node [45] [75] [82]. The k in PSS is 1, which is the minimum value ofk in PSS. The average value of the network lifetime of WSN gathering and transmitting data for eachmobile user in each week is taken as the average reliability of WSN for each mobile user in each week.4.5.2 Evaluation ResultsThe evaluation results with respect to usefulness of sensory data and reliability of WSN for each mobileuser in each week are shown in Fig. 4.3 and Fig. 4.4, respectively.From Fig. 4.3, we can observe that, averaging over all mobile users, around 85% of the sensory datasent to the cloud with TPSS are useful to the mobile users, whereas only around 45% of the sensory data934.5. Evaluations 0 100 200 300 400 500 1  2  3  4  5  6  7  8  9  10#Reliaiblity of WSN (hour)#Mobile userTPSSGS(a) 0 100 200 300 400 500 1  2  3  4  5  6  7  8  9  10#Reliaiblity of WSN (hour)#Mobile userTPSSGS(b) 0 100 200 300 400 500 1  2  3  4  5  6  7  8  9  10#Reliaiblity of WSN (hour)#Mobile userTPSSGS(c)Figure 4.4: Average reliability of WSN for each mobile user in week 1 (a); in week 2 (b) and in week 3 (c)sent to the cloud with GS are useful to the mobile users. The same results are obtained for each of thethree weeks observed. This demonstrates that TPSS greatly improves the usefulness of sensory data dueto the fact that mobile users generally request data over time according to the PTP tables.From Fig. 4.4, we can observe that the reliability of WSN is also greatly enhanced with TPSScomparing GS. Particularly, the three sub-figures show that over each of the three weeks observed, thereliability of WSN with GS is around 180 hours for all the mobile users, while the reliability of WSN withTPSS varies among different mobile users but averages to around 400 hours.In summary, TPSS substantially outperforms GS in terms of usefulness of sensory data and reliabilityof WSN. Moreover, for different mobile users with various data request characteristics indicated by dif-ferent PTP tables, the usefulness of sensory data varies considerably for both TPSS and GS, as indicatedin Fig. 4.3, while only the reliability of WSN for TPSS changes with mobile users as shown in Fig. 4.4.94Chapter 5Trust-Assisted Sensor-Cloud5.1 System ModelThe system model in this chapter is summarized as below.• A WSN includes one sink node sk, one source node se and η normal sensor nodes (i.e., WSN =sk, se, i1, i2, i3, . . . , iη). The data from se is gathered and transmitted to the sk via normal sensornodes and the data rate in the WSN is r kbps.• A cloud includes φ data centers (i.e., Cloud = j1, j2, j3, . . . , jφ).• δ Users (i.e., Users = u1, u2, u3, . . . , uδ) request the sensory data from cloud. The sensory data istransmitted from the WSN to the cloud.• Time consists of τ time epochs (i.e., Time = t1, t2, t3, . . . , tτ ). For each time epoch t, each sensornode i has a trust value vst(i) and each data center j owns a trust value vdt(j).955.2. Proposed TASC5.2 Proposed TASCAbout this section, some preliminary information regarding trust [52] [55] [83] is introduced first, followedwith the overview about the proposed TASC.5.2.1 Preliminaries about TrustTrust is “assured reliance on the character, ability, strength or truth of someone or something”, defined inMerriam Webster’s Dictionary. In fact, trust is with different definitions and evaluations regarding variousareas (e.g., wireless networks, sociology, philosophy, psychology, economics) [52] [83]. For example, thetrust from node A to node B in terms of wireless communications, is the subjective expectation that nodeA achieves desirable outcomes from node B based on their interactions.Generally, to perform the evaluation of trust from one subject (named as trustor) to another subject(named as trustee), the evidences (e.g., honesty, selfishness, vicious behaviors) reflecting the satisfactionregarding the trustee are needed. The evidences are either information based on direct interactions, orinformation coming from third-parties [55] [83]. Specifically, obtained through mapping evidences origi-nated from direct interactions, the trustworthiness is direct trust. Achieved through mapping evidencesoffered by third-parties, the trustworthiness is indirect trust or recommendation based trust. Furthermore,defined as a weighted combination of direct and indirect trust, the recent behaviors are shown by recenttrust. Defined with an exponential averaging update function of previous recent trusts, the long-termbehaviors based on the previous experiences are presented by historical trust. Derived from both recentand historical trust, the expected performance of the target is demonstrated by expected trust.After the trustor gathers various evidences about the trustee, the trustor achieves the trustworthinessvalue of the trustee, by using a function to map the collected evidences to the trustworthiness [52] [83].965.2. Proposed TASCFor instance, the beta distribution presented as below is one kind of function to compute trustworthiness.Specifically, given that the accumulative amounts of positive and negative outcomes from the trustee inthe evidences are ∆ and Λ, the the trustee’s trustworthiness v is computed as v = ∆+1Λ+∆+2 .5.2.2 Overview of TASCTrust-assisted WSNSend data requestsReply data requestsNormal sensor nodeSend data queriesData transmissionTrust-assisted CloudData center 2Data center 3Data center 1Source node Sink node Data centerUser 2User 3User 1UsersTrusted sensor Non-trusted sensor Trusted data center Non-trusted data centerFigure 5.1: An instance about TASCFig. 5.1 shows an instance of TASC. With respect to TASC, the sensory data is gathered and trans-mitted to the cloud, by the trusted sensors (i.e., sensors which own trust values surpassing a threshold)in WSN. Then the sensory data is stored, processed and on demand delivered to the users, by the trusteddata centers (i.e., data centers which own trust values surpassing a threshold) in cloud. In particular, 1)trust-assisted WSN and 2) trust-assisted cloud, are included in TASC.975.2. Proposed TASC(a) (b)(c) (d)Figure 5.2: An instance about states of trust-assisted WSN985.2. Proposed TASC5.2.3 Trust-Assisted WSNAbout trust-assisted WSN, the same trust value vso is owned by each sensor i initially. After a coupleof time epochs (e.g., in the tth time epoch), due to that every sensor’s behavioral pattern (e.g., datagathering history, data transmission history) is various generally, every sensor’s trust value vst(i) ischanged in general. Specifically, higher trust values should be associated with the sensors that have lessnegative behavioral patterns. In addition, lower trust values should be associated with those sensors thathave more negative behavioral patterns.Moreover, the status that a sensor is trusted or not dynamically changes with time, as presented inFig. 5.2 concerning trust-assisted WSN’s states. Namely, previous non-trusted sensors can turn intotrusted sensors, while previous trusted sensors can turn into non-trusted sensors. However, in terms ofusing sensors, trusted sensors are utilized for gathering and delivering sensory data to the cloud.5.2.4 Trust-Assisted CloudRegarding trust-assisted cloud, initially, the same trust value vdo is owned by each data center j. Aftera certain period (e.g., in the tth time epoch), the behavioral pattern (e.g., data storage history, dataprocessing history, data delivery history) of every data center is different generally. Therefore, every datacenter’s trust value vdt(j) is changed in general. Particularly, higher trust values should be associatedwith the data centers which have less negative behavioral patterns. Meanwhile, lower trust values shouldbe associated with those data centers which have more negative behavioral patterns.Furthermore, the status that a data center is trusted or not also changes with time, as shown in Fig.5.3 regarding trust-assisted cloud’s states. In other words, multiple non-trusted data centers and multipletrusted data centers could exist. When data centers are used, trusted data centers are used for storing,995.2. Proposed TASCData center 1Data center 1Data center 2Data center 3Data center 1Data center 2Data center 3Data center 1(a) (b)Data center 1Data center 1Data center 2Data center 3Data center 1Data center 2Data center 3Data center 1(c) (d)Figure 5.3: An instance about states of trust-assisted cloud1005.3. Trust Values Computation, ITASC & CTASC & MTASCprocessing and then on demand delivering the sensory data to users.5.3 Trust Values Computation, ITASC & CTASC & MTASCIn this section, the methods to compute trust values of sensor nodes and data centers in TASC arediscussed first, followed with the introduction regarding the proposed three types of TASC (i.e., ITASC,CTASC and MTASC).5.3.1 Trust Values of Sensor Nodes and Data CentersFor the state of art, there are various methods [52] [53] [54] that can be applied, to calculate the trustvalues of sensor nodes and data centers. Specifically, trust computation approaches can be summarizedinto distributed trust computations in which every sensor node or data center computes its own value oftrust on its neighbors; or centralized trust computations where a central agent manages or helps the sensornode or data center in trust computations. For distributed trust computations, direct trust, indirect trustor a hybrid of direct trust and indirect trust (i.e., recent trust, historical trust or expected trust) is utilizedby the trustor to calculate the trust value of the trustee. Regarding centralized trust computations,usually a TA (trust agent) that can be accessed by all sensor nodes or data centers in the community,is assumed. Then the trust values are computed by the TA for the whole group. Or the TA assists thesensor nodes or the data centers in their trust computations, by offering the initial trust values on targetsensor nodes or data centers. In addition, one or many TAs might exist, based on the size of the WSNand cloud.In this chapter, since different trust value computation methods have their own advantages and dis-advantages, the historical trust that presents the long-term behavior is taken, as an instance to compute1015.3. Trust Values Computation, ITASC & CTASC & MTASCthe trust value vst(i) of the sensor node i and the trust value vdt(j) of the data center j. Particularly, thefollowing approaches [55] are shown, to compute the sensor nodes’ trust values and data centers’ trustvalues.Computation of Trust Values of Sensor NodesAssume that up to z transactions in the tth time epoch, the historical trust which agent ps (i.e., a sensornode in WSN) owns regarding agent qs (i.e., another sensor node in WSN) is vstz(ps, qs). In addition, theforgetting factor (discounting older experiences) is ρs(0 ≤ ρs ≤ 1) and vs00(ps, qs) = 0.vstz(ps, qs) =ρs× vstz−1(ps, qs) + Satstz−1(ps, qs)2(5.1)In the above, considering agent qs’s service up to z transactions in the tth time epoch, Satstz(ps, qs)means the amount of satisfaction agent ps owns regarding agent qs. The following presents the detailedupdate function about the satisfaction.Satstz(ps, qs) = α× Satscur + (1− α)× Satstz−1(ps, qs) (5.2)α is a weight. Satst0(ps, qs) = Satst−1last(ps, qs). Namely, the initial satisfaction value is Sats00(ps, qs) =0. And satisfaction value at the beginning of tth time epoch, is the same as the satisfaction value lastcomputed in the (t− 1)th time epoch. Moreover, the satisfaction value about the most recent transactionis Satscur, which is updated with a feedback system based on the following function.1025.3. Trust Values Computation, ITASC & CTASC & MTASCSatscur =0, if transaction is fully unsatisfactory;1, if transaction is fully satisfactory;∈ (0, 1), otherwise.(5.3)Computation of Trust Values of Data CentersGiven that up to z transactions in the tth time epoch, the historical trust which agent pd (i.e., a datacenter in cloud) owns regarding agent qd (i.e., another data center in cloud) is vdtz(pd, qd). The forgettingfactor (discounting older experiences) is %d(0 ≤ %d ≤ 1) and vd00(pd, qd) = 0.vdtz(pd, qd) =%d× vdtz−1(pd, qd) + Satdtz−1(pd, qd)2(5.4)Where considering agent qd’s service up to z transactions in the tth time epoch, Satdtz(pd, qd) meansthe amount of satisfaction agent pd owns regarding agent qd. The detailed satisfaction update functionis presented as below.Satdtz(pd, qd) = β × Satdcur + (1− β)× Satdtz−1(pd, qd) (5.5)Similarly, β is also a weight. Satdt0(pd, qd) = Satdt−1last(pd, qd) and Satd00(pd, qd) = 0. Satdcur meansthe satisfaction value, regarding the most recent transaction. It is updated with the same feedback system,as utilized in the previous computation of trust values of sensor nodes.1035.3. Trust Values Computation, ITASC & CTASC & MTASCTable 5.1: Features of proposed TASCs (i.e., ITASC, CTASC and MTASC)TASCs FeaturesITASC Sensor nodes’ trust values and trust value threshold are determined by WSN;Data center’s trust values and trust value threshold are determined by cloud.CTASC Sensor nodes’ trust values are determined by WSN;Sensor nodes’ trust value threshold is determined by collaboration of WSN and cloud;Data centers’ trust values are determined by cloud;Data centers’ trust value threshold is determined by collaboration of WSN, cloud and users.MTASC Sensor nodes’ trust values and trust value threshold are determined by WSN;Data center’s trust values and trust value threshold are determined by cloud;There are trust values, regarding WSNs and clouds as well as users;There are mutual trust value thresholds, among WSNs and clouds as well as users.5.3.2 ITASC, CTASC and MTASCCharacteristics about the proposed three types of TASC (i.e., ITASC, CTASC and MTASC) are sum-marized in Table 5.1 and the detailed information about ITASC, CTASC and MTASC are shown asfollows.ITASCIn ITASC, the sensor nodes’ trust values and data centers’ trust values are determined by the WSN andthe cloud, independently. The trust value thresholds of sensor nodes and data centers are also chosen bythe WSN and the cloud, independently. The detailed process is shown as follows.1. The WSN obtains the trust value of each sensor node, the cloud achieves the trust value of eachdata center, with the trust value calculation methods discussed in Section 5.3.1 respectively.2. In each time epoch, according to a) whether the transmission path can be formed in WSN, the trust1045.3. Trust Values Computation, ITASC & CTASC & MTASCvalue threshold of sensor nodes is determined by the WSN. In addition, considering b) whether thetask can be fulfilled in cloud, the trust value threshold of data centers is chosen by the cloud. Afterthe trust value thresholds of sensor nodes and data centers are selected, the trusted sensor nodesand trusted data centers are used in the WSN and the cloud, respectively.3. From the WSN to the cloud, the sensory data is gathered and transmitted. From the cloud to theusers, the sensory data is stored, processed and further on demand delivered.CTASCFor CTASC, the Step 1) and Step 3) of CTASC are the same as that of ITASC, except Step 2) of CTASC.Namely, regarding the trust value threshold selection in Step 2) of CTASC, WSN not only considers a)whether the transmission path can be formed in WSN, but it also incorporates b) the previous interactionswith cloud resulting from various sensor nodes’ trust value thresholds in the history. Similarly, the cloudtakes into account both c) whether the task can be fulfilled in cloud and d) the previous interactions withWSN and users leading by different data centers’ trust value thresholds in the past.In other words, comparing CTASC with ITASC, the trust values of sensor nodes and data centersare both chosen by the WSN and the cloud independently. However, the trust value threshold of sensornodes is determined by the collaboration of WSN and cloud in CTASC. The trust value threshold of datacenters is determined by the collaboration of WSN, cloud and users in CTASC. Collaborating WSN andcloud as well as users during the trust value threshold selection procedure, is to choose more appropriatetrust value thresholds, considering the previous interactions among the WSN, the cloud and the userstriggered by different trust value thresholds in the history.1055.3. Trust Values Computation, ITASC & CTASC & MTASCMTASCIn ITASC and CTASC, it is only assumed that i) there are trust values of the sensor nodes in the WSNand trust values of the data centers in the cloud; ii) there is trust value threshold about the sensor nodesin the WSN and there is trust value threshold about the data centers in the cloud. In MTASC, apart fromi) and ii), it is supposed that iii) there are trust values regarding the WSN (VWSN ), the cloud (VCloud)and the user (VUser); iv) there are mutual trust value thresholds between WSNs and clouds as well asusers.Specifically, in MTASC, sensor nodes’ trust values and trust value threshold are determined by WSN.Data center’s trust values and trust value threshold are determined by cloud. The trust values of theWSN (VWSN ), the cloud (VCloud) and the user (VUser), can be achieved with the trust and reputationmanagement system (e.g., [83]). The mutual trust value thresholds among WSNs and clouds as well asusers, are determined by them mutually. For example, the trust value threshold d3 for WSN to choosecloud is determined by WSN. The trust value threshold d4 for cloud to select WSN is chosen by the cloud.Similarly, the threshold d5 for cloud to trust user is cloud’s decision and the threshold d6 for user to trustcloud is user’s decision.The detailed steps of MTASC are presented as below.1. Comparing VWSN s, VClouds, VUsers with d3s, d4s, d5s, d6s (e.g., VWSN needs to surpass d4; VCloudneeds to surpass d3 and d6; VUser needs to surpass d5), each WSN chooses the cloud(s) it trusts.Similarly, each cloud selects the WSN(s) and the user(s) it trusts. Each user chooses the trustedcloud(s). With this process, the mutual trust between WSNs and clouds as well as users, areestablished. Namely, the WSNs and clouds as well as users trust each other mutually.1065.4. Analysis of TASC and SCWTA2. Step 1) of ITASC3. Step 2) of ITASC4. Step 3) of ITASCAbout VWSN , VCloud, VUser, they actually mean the confidence that WSN, cloud and user have shownto each other facing uncertainty in future transactions. Regarding the mutual trust value thresholds, d3and d6 together determine whether the cloud is qualified to deal with the sensory data from WSN aswell as handle the data requests from user. d4 and d5, determine whether the WSN and the user aretrustworthy, respectively. By utilizing VWSN s, VClouds, VUsers and d3s, d4s, d5s, d6s, WSNs and clouds aswell as users will start mutual transactions with more confidence.5.4 Analysis of TASC and SCWTARegarding this section, a general comparison of TASC and SCWTA is performed first, followed with thedefinition about the throughput and response time of a SC. Then a path concept in SC is introduced.With that, the detailed analysis is performed about TASC and SCWTA, in terms of the throughput andresponse time.5.4.1 General Comparison1. TASC: Owning trust values surpassing a certain threshold, the trusted sensor nodes perform thesensory data gathering and transmission in WSN. Meanwhile, having trust values surpassing acertain threshold, the trusted data centers implement the sensory data storage, processing and1075.4. Analysis of TASC and SCWTAon demand delivery in cloud. Therefore, the probability that the sensory data could be achievedsuccessfully from the WSN’s source node to the SC’s user is higher, with less data loss. The neededtime for the achievement of sensory data from the WSN’s source node to the SC’s user is also low.2. SCWTA: The sensor nodes and data centers are used, ignoring their trust values. As a result, thegathering and transmission of sensory data in WSN may be conducted by some sensor nodes whichhave very low trust values. In addition, the storage, processing and further on demand delivery ofsensory data in cloud may be implemented by some data centers which have very low trust values.With such manner, it is low, in terms of the chances that the sensory data is achieved successfully bythe SC’s user from the WSN’s source node. Also, it is low, regarding the proportion of the sensorydata achieved successfully by the SC’s user from the WSN’s source node. In addition, it is high,about the corresponding time required for the sensory data to be achieved by the SC’s user fromthe WSN’s source node.5.4.2 Throughput and Response Time of SC1. Response time (RTSC) of a SC is defined, as the end to end time needed to receive the sensorydata by the SC’s user from the WSN’s source node. This includes the time needed by the sensornodes (for performing sensory data collection and transmission) in WSN and the time required bythe data centers (for performing sensory data storage, processing and delivery) in the cloud.2. Throughput (THSC) of a SC is defined, as the end to end successfully received sensory data by theSC’s user from the WSN’s source node, divided by the end to end response time.1085.4. Analysis of TASC and SCWTAWSNNormal sensor nodeCloudData center 2Data center 3Data center 1Source node Sink node Data centerUser 2User 3User 1UsersFigure 5.4: An instance about paths in SC5.4.3 Paths in SCFig. 5.4 presents an instance of the paths (named as SC paths) from the WSN’s source node to the SC’suser in a SC. Further, it can be observed that for different SC paths, the sensor nodes’ trust values andthe data centers’ trust values in the SC paths should be different generally. In addition, the response timeand throughput utilizing different SC paths to offer sensory data to the SC’s user, should be different ingeneral.Intuitively, it is assumed that if the sensor nodes’ trust values and the data centers’ trust valuesare higher in a SC path, then the corresponding response time using the SC path is lower and thecorresponding throughput utilizing the SC path is higher. In other words, it is supposed that there is adecreasing function, which associates the RTSC with the trust values of sensor nodes and data centers inthe SC path. There is also an increasing function that relates the THSC to the sensor nodes’ trust valuesand data centers’ trust values in the SC path.1095.4. Analysis of TASC and SCWTANote: 1) Since the selection of SC path is with respect to the routing strategy which is a well discussedanother topic, the SC path selection is not discussed in this chapter. Instead, the focus is analyzing RTSCand THSC . 2) The computations of the sensor nodes’ trust values and the data centers’s trust values, arealready analyzed in Section 5.3.1. Thus in each time epoch, each sensor node’s trust value and each datacenter’s trust value, can be obtained for performing the next analysis.5.4.4 Detailed AnalysisFor SCWTA, in each time epoch, assume that in the selected SC path, there are N sensor nodes withtrust values xn (n ≤ N) and M cloud data centers with trust values ym (m ≤ M). About TASC, in thechosen SC path, assume that there are C sensor nodes and D data centers. Trust values of them are ac(c ≤ C) and bd (d ≤ D), respectively.Regarding SCWTA and TASC, generally there are different sensor nodes and data centers in the SCpaths. In particular, xn and ym are random in SCWTA, while ac and bd surpass certain trust valuethresholds in TASC. In addition, assume that the decreasing function that associates each sensor node’sresponse time with each sensor node’s trust value is g1 in the SC path. Similarly, the decreasing functionthat relates each data center’s response time to each data center’s trust value is g2 in the SC path.With the above assumptions, the expected RTSC and expected THSC are analyzed. Particularly, thefocus is analyzing the expected RTSC , since the expected THSC is achieved with the following equation,in which r is the data rate and ι is a parameter indicating the proportion after data loss due to variousfactors (e.g., interference, etc.) affecting sensory data gathering, storage, processing and transmission.E{THSC} = r · ιE{RTSC} (5.6)1105.4. Analysis of TASC and SCWTAIn the following, for simplicity, e1 is denoted as the RTSC of SCWTA and e2 is denoted as the RTSCof TASC, followed with the analysis about E{e1} and E{e2} with respect to four detailed distribution-function combinations.e1 =∑Nn=1 g1(xn)+∑Mm=1 g2(ym), e2 =∑Cc=1 g1(ac)+∑Dd=1 g2(bd). X = [x1, . . . , xN ], Y = [y1, . . . , yM ].A = [a1, . . . , aC ], B = [b1, . . . , bD]. X,Y ∈ [0, 1], A ∈ [Th1, 1], B ∈ [Th2, 1]. X,Y,A,B are independent.Besides, X and A have similar distributions while Y and B have similar distributions. The functionsg1(x) and g2(y) are decreasing w.r.t. x and y, respectively. Thus, the expectations of e1 and e2 can beobtained asE{e1} = N · E{g1(x)}+M · E{g2(y)}, (5.7)E{e2} = C · E{g1(a)}+D · E{g2(b)} (5.8)where x, y ∈ [0, 1], a ∈ [Th1, 1], b ∈ [Th2, 1]. Besides, x and a have similar distributions while y and bhave similar distributions.Denote fX(x), fY (y), fA(a) and fB(b) as the probability density functions (PDFs) of x, y, a and b,respectively. Moreover, fA(a) and fB(b) are normalized asfA(a) =1∫ 1Th1fX(x)dxfX(a), a ∈ [Th1, 1], (5.9)andfB(b) =1∫ 1Th2fY (y)dyfY (b), b ∈ [Th2, 1], (5.10)respectively.In terms of the functions fX(x) and fY (y), two cases are considered as follows.1115.4. Analysis of TASC and SCWTA1. P1: Uniform distribution, i.e., fX(x) = 1, x ∈ [0, 1], and fY (y) = 1, y ∈ [0, 1].2. P2: Normalized exponential distribution, i.e., fX(x) =λ11−e−λ1 e−λ1x, x ∈ [0, 1], and fY (y) =λ21−e−λ2 e−λ2y, y ∈ [0, 1]. Here, λ1 and λ2 are positive constant parameters.In terms of the functions g1(x) and g2(y), two cases are also considered as follows.1. F1: Inverse function, i.e., g1(x) =k1x+ε1, x ∈ [0, 1], and g2(y) = k2y+ε2 , y ∈ [0, 1]. Here, (k1, k2) arepositive constant parameters and (ε1, ε2) are nonnegative constant parameters.2. F2: Negative exponential function, i.e., g1(x) = e−h1x+θ1 , x ∈ [0, 1], and g2(y) = e−h2y+θ2 , y ∈ [0, 1].Here, (h1, h2) are positive constant parameters and (θ1, θ2) are nonnegative constant parameters.Note that E{g1(x)} =∫ 10 fX(x)g1(x)dx, E{g2(y)} =∫ 10 fY (y)g2(y)dy, E{g1(a)} =∫ 1Th1fA(a)g1(a)daand E{g2(b)} =∫ 1Th2fB(b)g2(b)db. Thus, based on equation (5.7), equation (5.8), equation (5.9) andequation (5.10), the following four distribution-function combinations can be achieved and analyzed.P1-F1fA(a) =11−Th1 , a ∈ [Th1, 1], and fB(b) = 11−Th2 , b ∈ [Th2, 1]. Thus, it can be obtained that E{e1} =k1N ln(1 + 1ε1)+ k2M ln(1 + 1ε2)and E{e2} = k1C1−Th1 ln(1+ε1Th1+ε1)+ k2D1−Th2 ln(1+ε2Th2+ε2).P1-F2Likewise, fA(a) =11−Th1 , a ∈ [Th1, 1], and fB(b) = 11−Th2 , b ∈ [Th2, 1]. Thus, it can be got that E{e1} =Nh1eθ1(1−e−h1)+ Mh2 eθ2(1−e−h2) and E{e2} = Ch1(1−Th1)eθ1(e−h1Th1−e−h1)+ Dh2(1−Th2)eθ2(e−h2Th2−e−h2).1125.5. Numerical ResultsP2-F1fA(a) =λ1e−λ1Th1−e−λ1 e−λ1a, a ∈ [Th1, 1], and fB(b) = λ2e−λ2Th2−e−λ2 e−λ2b, b ∈ [Th2, 1]. DefineQ(lo, up, λ, ε) =∫ uploλs+εe−λsds, which can be calculated with numerical methods once (lo, up, λ, ε) is given. Thus, it can beachieved that E{e1} = k1N1−e−λ1Q(0, 1, λ1, ε1)+ k2M1−e−λ2Q(0, 1, λ2, ε2) and E{e2} = k1Ce−λ1Th1−e−λ1Q(Th1, 1, λ1, ε1)+k2De−λ2Th2−e−λ2Q(Th2, 1, λ2, ε2).P2-F2Similarly, fA(a) =λ1e−λ1Th1−e−λ1 e−λ1a, a ∈ [Th1, 1], and fB(b) = λ2e−λ2Th2−e−λ2 e−λ2b, b ∈ [Th2, 1]. Thus, itcan be got that E{e1} = λ1N(λ1+h1)(1−e−λ1 )eθ1[1− e−(λ1+h1)]+ λ2M(λ2+h2)(1−e−λ2 )eθ2[1− e−(λ2+h2)] and E{e2} =λ1C(λ1+h1)(e−λ1Th1−e−λ1 )eθ1[e−(λ1+h1)Th1 − e−(λ1+h1)]+ λ2D(λ2+h2)(e−λ2Th2−e−λ2 )eθ2[e−(λ2+h2)Th2 − e−(λ2+h2)].Note: In this chapter, affecting the chances that the sensory data is received successfully and theproportion of the sensory data received successfully by the SC’s user from the WSN’s source node, variousfactors are considered. In other words, it is assumed that the end to end successfully received sensorydata (i.e., r · ι) by the SC’s user from the WSN’s source node, are the same for TASC and SCWTA, inthe following section that analyzes numerical results.5.5 Numerical ResultsDetermining the effectiveness of TASC about enhancing the QoS that the sensory data is achieved byusers from SC, TASC is in contrast to SCWTA. The throughput and response time analyzed above areutilized as the evaluation metrics. Performed in NetTopo [46], the detailed simulation is presented asbelow.1135.5. Numerical Results5.5.1 Evaluation SetupThe system includes one WSN, one cloud and 10 users. One sink node, one source node and 100 normalsensors nodes are included in the WSN, with a date rate which is 1000 kbps. The WSN transmits thesensory data to the cloud including 10 data centers. Sensory data in the cloud is further on demandrequested by each user. Each time epoch is 1 s.In general, the sensor nodes’ trust values and the data centers’ trust values surpass certain thresholds,in TASC. The sensor nodes’ trust values and the data centers’ trust values are random values ranging from0 and 1, in SCWTA. The following two scenarios show the detailed information regarding the evaluation.• Scenario 1: For comparing the throughput and response time of TASC and SCWTA, 100 simulationswith various topologies are utilized. In these topologies, the number of sensor nodes changes from1 to 20 and the number of data centers changes from 1 to 5 in the SC path, for both TASC andSCWTA. About TASC, both sensor nodes’ trust value thresholds and data centers’ trust valuethresholds are set to be 0.5. In terms of SCWTA, each sensor node’s trust value and each datacenter’s trust value are always random values ranging from 0 and 1.• Scenario 2: For analyzing trust value thresholds’ impacts on throughput and response time, aspecific topology in which the SC path includes 10 sensor nodes and 2 data centers is utilized,for both TASC and SCWTA. For this topology, the sensor nodes’ trust value thresholds and datacenters’ trust value thresholds are varied 7 times (from 0.0 to 0.7) in TASC. Particularly, for eachtime, the trust value threshold is increased by 0.1 in TASC. Meanwhile, each sensor node’s trustvalue and each data center’s trust value are still always random values, ranging from 0 and 1 inSCWTA.1145.5. Numerical ResultsIn particular, in terms of the parameters about the distributions and functions illustrated in Section5.4.4, it is set that (λ1, λ2) = (1, 3), (k1, ε1, k2, ε2) = (0.5, 0.5, 0.1, 0.1), (h1, θ1, h2, θ2) = (1, 0.3, 2, 0.1). Inaddition, the TASC to SCWTA ratios (%) on the throughput and the response time resulting from thesame topology (i.e., the same distribution-function combination) are utilized to compare the performanceof TASC and SCWTA, since it is more fair that the analysis is based on the throughput and responsetime regarding the same topology.5.5.2 Evaluation ResultsRegarding the TASC to SCWTA ratios (%) on throughput and response time in Scenario 1, Fig. 5.5(a)to Fig. 5.5(d) and Fig. 5.6(a) to Fig. 5.6(d) depict the evaluation results, respectively. Particularly, fromthese figures, it can be obviously achieved that in different topologies, the throughput of TASC nearlyalways outperforms the throughput of SCWTA a lot. In the meantime, the response time of TASC almostalways substantially falls behind the response time of SCWTA.Moreover, with respect to the TASC to SCWTA ratios (%) on throughput and response time inScenario 2, Fig. 5.7(a) to Fig. 5.7(d) and Fig. 5.8(a) to Fig. 5.8(d) describe the evaluation results,respectively. It can be obtained from those figures that in terms of different trust value thresholds, TASCstill owns larger throughput than SCWTA, while TASC still owns smaller response time than SCWTA.In particular, the TASC to SCWTA ratio (%) on throughput can be increased and the TASC to SCWTAratio (%) on response time can be decreased, by growing the trust value thresholds in general.1155.5. Numerical Results1234505101520135140145150155160165Data centers in cloudSensor nodes in WSNRatio (%) on throughputP1-F1(a)1234505101520130135140145150155160Data centers in cloudSensor nodes in WSNRatio (%) on throughputP1-F2(b)1234505101520140160180200220Data centers in cloudSensor nodes in WSNRatio (%) on throughputP2-F1(c)1234505101520140150160170180190200Data centers in cloudSensor nodes in WSNRatio (%) on throughputP2-F2(d)Figure 5.5: TASC to SCWTA ratio (%) on throughput in Scenario 1: P1-F1 (a), P1-F2 (b), P2-F1 (c),P2-F2 (d)1165.5. Numerical Results12345051015206062646668707274Data centers in cloudSensor nodes in WSNRatio (%) on response timeP1-F1(a)12345051015206264666870727476Data centers in cloudSensor nodes in WSNRatio (%) on response timeP1-F2(b)1234505101520455055606570Data centers in cloudSensor nodes in WSNRatio (%) on response timeP2-F1(c)1234505101520505560657075Data centers in cloudSensor nodes in WSNRatio (%) on response timeP2-F2(d)Figure 5.6: TASC to SCWTA ratio (%) on response time in Scenario 1: P1-F1 (a), P1-F2 (b), P2-F1 (c),P2-F2 (d)1175.5. Numerical Results00.20.40.60.800.20.40.60.8100110120130140150160Th2Th1Ratio (%) on throughputP1-F1(a)00.20.40.60.800.20.40.60.8100110120130140150160Th2Th1Ratio (%) on throughputP1-F2(b)00.20.40.60.800.20.40.60.8100120140160180Th2Th1Ratio (%) on throughputP2-F1(c)00.20.40.60.800.20.40.60.8100110120130140150160170Th2Th1Ratio (%) on throughputP2-F2(d)Figure 5.7: TASC to SCWTA ratio (%) on throughput in Scenario 2: P1-F1 (a), P1-F2 (b), P2-F1 (c),P2-F2 (d)1185.5. Numerical Results00.20.40.60.800.10.20.30.40.50.60.760708090100Th1Th2Ratio (%) on response timeP1-F1(a)00.20.40.60.800.10.20.30.40.50.60.760708090100Th1Th2Ratio (%) on response timeP1-F2(b)00.20.40.60.800.10.20.30.40.50.60.75060708090100Th1Th2Ratio (%) on response timeP2-F1(c)00.20.40.60.800.10.20.30.40.50.60.75060708090100Th1Th2Ratio (%) on response timeP2-F2(d)Figure 5.8: TASC to SCWTA ratio (%) on response time in Scenario 2: P1-F1 (a), P1-F2 (b), P2-F1 (c),P2-F2 (d)119Chapter 6Conclusions and Future Work6.1 ConclusionsThis thesis focuses on Sensor-Cloud, which is a valuable and challenging topic. Particularly, improvingSensor-Cloud, the important research issues that are yet to be widely investigated by other researchersabout the energy efficiency, security, sensory data transmission and QoS of Sensor-Cloud have beenidentified in this thesis. Further, regarding solving those identified research issues, our accomplished workhas been shown.• In Chapter 2, solving the identified research issues about energy efficiency of Sensor-Cloud, wehave proposed two CLSS schemes (i.e., CLSS1 and CLSS2) for WSNs integrated with MCC. CLSSschemes involve both the WSN and the cloud and then dynamically change the awake or asleepstatus of the sensor node in the integrated WSN, based on the locations of mobile users. CLSS1focuses on saving the most energy consumption of the integrated WSN and CLSS2 further paysattention to the scalability and robustness of the integrated WSN. For the integration of MCC andWSNs, both theoretical and simulation results have been shown and they have demonstrated thatCLSS1 and CLSS2 could prolong the lifetime of the integrated WSN while still satisfying the datarequests of mobile users.1206.1. Conclusions• In Chapter 3, solving the identified research issues about security of Sensor-Cloud, we have proposedan ATRCM system for CC-WSN integration. Discussion and analysis about the authentication ofCSP and SNP as well as the trust and reputation with respect to the service provided by CSPand SNP have been presented, followed with detailed design and functionality evaluation about theproposed ATRCM system. All these have presented that the proposed ATRCM system achievesthe following three functions for CC-WSN integration: a) authenticating CSP and SNP to avoidmalicious impersonation attacks; b) calculating and managing trust and reputation regarding theservice of CSP and SNP; c) helping CSU choose desirable CSP and assisting CSP in selectingappropriate SNP, based on (i) the authenticity of CSP and SNP; (ii) the attribute requirement ofCSU and CSP; (iii) the cost, trust and reputation of the service of CSP and SNP. In addition, oursystem security analysis powered by three adversary models has shown that our proposed system issecure versus main attacks on a trust and reputation management system, such as good mouthing,bad mouthing, collusion and white-washing attacks, which are the most important attacks in ourcase.• In Chapter 4, solving the identified research issues about sensory data transmission of Sensor-Cloudto support WSN-MCC integration applications that need more useful data offered reliably from theWSN to the cloud, we have identified the critical issues that impede the usefulness of sensory dataand reliability of WSN, and proposed a WSN-MCC integration scheme named TPSS to addresssome of these issues. Specifically, TPSS consists of the following two main parts: 1) TPSDT forWSN gateway to selectively transmit sensory data that are more useful to the cloud, considering thetime and priority features of the data requested by the mobile user; 2) PSS algorithm for WSN tosave energy consumption so that it can gather and transmit data more reliably. Both analytical and1216.2. Future Workexperimental results regarding TPSS have been presented to demonstrate the effectiveness of TPSSin improving the usefulness of sensory data and reliability of WSN for WSN-MCC integration.• In Chapter 5, solving the identified research issues about QoS of Sensor-Cloud, we have proposed theconcept of TASC to enhance the throughput and response time that the sensory data is achievedby users from SC. In TASC, the sensory data gathering and transmission from WSN to cloudare performed by trusted sensors, while the sensory data storage and processing as well as ondemand delivery from cloud to users are conducted by trusted data centers. Moreover, regardingthe application of TASC, the methods to compute sensor nodes’ trust values and data centers’trust values have been discussed. In addition, about the design of TASC, three types of TASC(i.e., ITASC, CTASC, MTASC) have been presented. In contrast to SCWTA, further extensiveanalysis and numerical results have also been shown to demonstrate the effectiveness of TASCabout improving the throughput and response time that the sensory data is achieved by users fromSC.We hope our work can attract more research into Sensor-Cloud for making it develop faster and better.6.2 Future WorkAbout the possible extensions of our work presented in this thesis, they are shown as follows.• Topology design for TASC : In Chapter 5, we have proposed a TASC concept, which could improvethe throughput and response time that the sensory data is achieved by users from SC. In particular,TASC utilizes the trusted sensors to perform the sensory data gathering and transmission fromWSN to cloud. Moreover, TASC uses the trusted data centers to perform the sensory data storage1226.2. Future Workand processing as well as on demand delivery from cloud to users. Concerning the extension of thiswork, we can observe that TASC will be effective when there are sufficient sensors in WSN andsufficient data centers in cloud. Thus, it is worthwhile discussing the following point that couldinfluence whether there are sufficient sensors in WSN and whether there are sufficient data centersin cloud: the design of the topology for TASC.• TASC with multiple trust value thresholds: In Chapter 5, the trusted sensors in WSN are defined asthe sensors which own trust values surpassing a threshold. In addition, the trusted data centers incloud are defined as the data centers which own trust values surpassing a threshold. For the currentTASC, although the trust value thresholds are dynamically determined in each time epoch, the trustvalue thresholds for all the sensors in the WSN are the same and the trust value thresholds for allthe data centers in the cloud are the same. Considering the variant of this work, we can study theTASC with multiple trust value thresholds, in which the trust value thresholds for different sensorsin the WSN are different and the trust value thresholds for different data centers in the cloud aredifferent. New theoretical analysis might be needed and new numerical results might appear.• Social-Sensor-Cloud (SSC): We envision that the Sensor-Cloud could evolve into SSC, in which socialnetworks (SNs) [84] [85] [86], WSN and cloud connect and complement each other, as shown in Fig.6.1. In Social-Cloud, integrating SNs and CC, there is already much research (e.g., [57] [87] [88][89]), in which the key idea is to share the cloud resources and services utilizing the relationshipsestablished between members of a SN. In SSC, leveraging SNs, not only will the Sensor-Cloudresources and services be shared, but also the SNs could be used to improve Sensor-Cloud in thefollowing ways. i) Sharing the Sensor-Cloud resources and services to other users with SNs, couldsubstantially reduce the resources and services requested by the Sensor-Cloud users. As a result,1236.2. Future Workthe energy consumption of Sensor-Cloud could be decreased dramatically. ii) Based on the amountof resource consumption and service usages created by a variety of users in SNs, the deployment ofresources could be optimized and the waste of resources could be reduced in Sensor-Cloud.CloudWSNsOffice SchoolCitySNsFigure 6.1: A vision of Social-Sensor-Cloud (SSC)124Bibliography[1] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, “Wireless sensor networks: a survey,”Comput. Netw., vol. 38, no. 4, pp. 393–422, Mar. 2002.[2] M. Li and Y. Liu, “Underground coal mine monitoring with wireless sensor networks,” ACM Trans.Sens. Netw, vol. 5, no. 2, pp. 1–29, Mar. 2009.[3] C. Zhu, L. Shu, T. Hara, L. Wang, S. Nishio, and L. T. Yang, “A survey on communication and datamanagement issues in mobile sensor networks,” Wirel. Commun. Mob. Comput., vol. 14, no. 1, pp.19–36, Jan. 2014.[4] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandic, “Cloud computing and emerging itplatforms: Vision, hype, and reality for delivering computing as the 5th utility,” Future GenerationComput. Syst., vol. 25, no. 6, pp. 599–616, Jun. 2009.[5] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: state-of-the-art and research challenges,”J. Ineternet Serv. Appl., vol. 1, no. 1, pp. 7–18, May 2010.[6] J. Baliga, R. W. A. Ayre, K. Hinton, and R. S. Tucker, “Green cloud computing: Balancing energyin processing, storage, and transport,” Proc. IEEE, vol. 99, no. 1, pp. 149–167, Jan. 2011.125Bibliography[7] Y. Xu and S. Mao, “A survey of mobile cloud computing for rich media applications,” IEEE WirelessCommun., vol. 20, no. 3, pp. 46–53, Jun. 2013.[8] H. T. Dinh, C. Lee, D. Niyato, and P. Wang, “A survey of mobile cloud computing: Architecture,applications, and approaches,” Wirel. Commun. Mob. Comput., vol. 13, no. 18, pp. 1587–1611, Dec.2013.[9] A. R. Khan, M. Othman, S. A. Madani, and S. U. Khan, “A survey of mobile cloud computingapplication models,” IEEE Commun. Surveys Tuts., vol. 16, no. 1, pp. 393–413, First Quarter 2014.[10] A. Alamri, W. S. Ansari, M. M. Hassan, M. S. Hossain, A. Alelaiwi, and M. A. Hossain, “A survey onsensor-cloud: Architecture, applications, and approaches,” Int. J. Distrib. Sensor Netw., pp. 1–18,2013.[11] S. Misra, S. Chatterjee, and M. S. Obaidat, “On theoretical modeling of sensor cloud: A paradigmshift from wireless sensor network,” IEEE Syst. J., vol. PP, no. 99, pp. 1–10, Nov. 2014.[12] S. Madria, V. Kumar, and R. Dalvi, “Sensor cloud: A cloud of virtual sensors,” IEEE Softw., vol. 31,no. 2, pp. 70–77, Mar.-Apr. 2014.[13] S. Misra, S. Bera, A. Mondal, R. Tirkey, H.-C. Chao, and S. Chattopadhyay, “Optimal gatewayselection in sensor-cloud framework for health monitoring,” IET Wirel. Sens. Syst., vol. 4, no. 2, pp.61–68, Jun. 2014.[14] S. Chatterjee and S. Misra, “Target tracking using sensor-cloud: Sensor-target mapping in presenceof overlapping coverage,” IEEE Commun. Lett., vol. 18, no. 8, pp. 1435–1438, Aug. 2014.126Bibliography[15] C. Zhu, X. Li, H. Ji, and V. C. M. Leung, “Towards integration of wireless sensor networks and cloudcomputing,” in Proc. 7th IEEE Int. Conf. Cloud Comput. Technol. Sci., 2015, pp. 491–494.[16] C. Zhu, V. C. M. Leung, L. Shu, and E. C.-H. Ngai, “Green internet of things for smart world,”IEEE Access, vol. 3, pp. 2151–2162, Nov. 2015.[17] C.-F. Lai, M. Chen, J.-S. Pan, C.-H. Youn, and H.-C. Chao, “A collaborative computing frameworkof cloud network and wbsn applied to fall detection and 3-d motion reconstruction,” IEEE J. Biomed.Health Inform., vol. 18, no. 2, pp. 457–466, Mar. 2014.[18] C.-R. Yi, J. Suzuki, D. H. Phan, S. Omura, and R. Hosoya, “An evolutionary game theoretic ap-proach for configuring cloud-integrated body sensor networks,” in Proc. IEEE 13th Int. Symp. Netw.Comput. and Appl., 2014, pp. 277–281.[19] L. D. P. Mendes, J. J. P. C. Rodrigues, J. Lloret, and S. Sendra, “Cross-layer dynamic admissioncontrol for cloud-based multimedia sensor networks,” IEEE Syst. J., vol. 8, no. 1, pp. 235–246, Mar.2014.[20] P. Zhang, Z. Yan, and H. Sun, “A novel architecture based on cloud computing for wireless sensornetwork,” in Proc. 2nd Int. Conf. Comput. Sci. Electron. Eng., 2013, pp. 472–475.[21] W. Wang, K. Lee, and D. Murray, “Integrating sensors with the cloud using dynamic proxies,” inProc. IEEE 23rd Int. Symp. Pers. Indoor Mobile Radio Commun., 2012, pp. 1466–1471.[22] Y. Li, L. Guo, C. Wu, C.-H. Lee, and Y. Guo, “Building a cloud-based platform for personal healthsensor data management,” in Proc. IEEE-EMBS Int. Conf. Biomed. and Health Inform., 2014, pp.223–226.127Bibliography[23] D. Vouyioukas, A. Moralis, M. Sardis, D. Drakoulis, G. Labropoulos, S. Kyriazakos, and D. Dres,“Epikouros - virtualized platforms using heterogeneous sensor services in cloud computing environ-ment,” in Proc. 4th Int. Conf. Wireless Commun., Veh. Technol., Inf. Theory and Aerospace &Electron. Syst., 2014, pp. 1–5.[24] S. S. Grace and M. R. Sumalatha, “Event matching based on subscriber category in sensor cloud,”in Proc. Int. Conf. Recent Trends in Inf. Technol., 2014, pp. 1–5.[25] K. Ahmed and M. Gregory, “Integrating wireless sensor networks with cloud computing,” in Proc.7th Int. Conf. Mobile Ad-hoc Sensor Netw., 2011, pp. 364–366.[26] A. Lounis, A. Hadjidj, A. Bouabdallah, and Y. Challal, “Secure and scalable cloud-based architecturefor e-health wireless sensor networks,” in Proc. 21st Int. Conf. Comput. Commun. Netw., 2012, pp.1–7.[27] P. Stuedi, I. Mohomed, and D. Terry, “Wherestore: Location-based data storage for mobile devicesinteracting with the cloud,” in Proc. 1st ACM Workshop Mob. Cloud Comput. & Serv.: Soc. Netw.Beyond, 2010, pp. 1–8.[28] Y. Man and Y. Liu, “Towards an energy-efficient framework for location-triggered mobile applica-tion,” in Proc. Australasian Conf. Telecommun. Netw. Appl., 2010, pp. 3644–3647.[29] R. Meier and V. Cahill, “On event-based middleware for location-aware mobile applications,” IEEETrans. Softw. Eng, vol. 36, no. 3, pp. 409–430, May-Jun. 2010.[30] M. Cardei and D.-Z. Du, “Improving wireless sensor network lifetime through power aware organi-zation,” Wirel. Netw., vol. 11, no. 3, pp. 333–340, May 2005.128Bibliography[31] C. Park, K. Lahiri, and A. Raghunathan, “Battery discharge characteristics of wireless sensor nodes:an experimental analysis,” in Proc. 2nd Annual IEEE Commun. Soc. Conf. Sens. Ad Hoc Commun.Netw., 2005, pp. 430–440.[32] R. R. Rout and S. K. Ghosh, “Enhancement of lifetime using duty cycle and network coding inwireless sensor networks,” IEEE Trans. Wireless Commun., vol. 12, no. 2, pp. 656–667, Feb. 2013.[33] G. Ananthanarayanan, M. Haridasan, I. Mohomed, D. Terry, and C. A. Thekkath, “Startrack: aframework for enabling track-based applications,” in Proc. 7th Int. Conf. Mob. Syst., Appl., Serv.,2009, pp. 207–220.[34] W. R. Heinzelman, A. Chandrakasan, and H. Balakrishman, “Energy-efficient communication proto-col for wireless microsensor networks,” in Proc. 33rd Annual Hawaii Int. Conf. Syst. Sci., 2000, pp.3005–3014.[35] S. Lindsey and C. S. Raghavendra, “Pegasis: Power-efficient gathering in sensor information system-s,” in Proc. IEEE Aerospace Conf., 2002, pp. 1125–1130.[36] L. Wang, Z. Yuan, L. Shu, L. Shi, and Z. Qin, “An energy-efficient ckn algorithm for duty-cycledwireless sensor networks,” Int. J. Distrib. Sensor Netw., pp. 1–15, 2012.[37] A. Sinha and A. Chandrakasan, “Dynamic power management in wireless sensor networks,” IEEEDes. Test. Comput., vol. 18, no. 2, pp. 62–74, Mar./Apr. 2001.[38] R. C. Luo and O. Chen, “Mobile sensor node deployment and asynchronous power management forwireless sensor networks,” IEEE Trans. Ind. Electron., vol. 59, no. 5, pp. 2377–2385, May 2012.129Bibliography[39] C. Bettstetter, “On the minimum node degree and connectivity of a wireless multihop network,” inProc. The 3rd ACM Int. Symp. Mob. Ad Hoc Netw. Comput., 2002, pp. 80–91.[40] C. Zhu, L. T. Yang, L. Shu, T. Hara, and S. Nishio, “Implementing top-k query in duty-cycledwireless sensor networks,” in Proc. 7th Int. Conf. Wirel. Commun. Mob. Comput. Conf., 2011, pp.553–558.[41] W. Wang, V. Srinivasan, and K.-C. Chua, “Extending the lifetime of wireless sensor networks throughmobile relays,” IEEE/ACM Trans. Netw., vol. 16, no. 5, pp. 1108–1120, Oct. 2008.[42] Y. T. Hou, Y. Shi, and H. D. Sherali, “Rate allocation and network lifetime problems for wirelesssensor networks,” IEEE/ACM Trans. Netw., vol. 16, no. 2, pp. 321–334, Apr. 2008.[43] S. Nath and P. B. Gibbons, “Communicating via fireflies: Geographic routing on duty-cycled sensors,”in Proc. ACM/IEEE Int. Conf. Inf. Process. Sens. Netw., 2007, pp. 440–449.[44] C. Zhu, L. T. Yang, L. Shu, J. J. P. C. Rodrigues, and T. Hara, “A geographic routing oriented sleepscheduling algorithm in duty-cycled sensor networks,” in Proc. IEEE Int. Conf. Commun., 2012, pp.5473–5477.[45] C. Zhu, L. T. Yang, L. Shu, V. C. M. Leung, J. J. P. C. Rodrigues, and L. Wang, “Sleep schedulingfor geographic routing in duty-cycled mobile sensor networks,” IEEE Trans. Ind. Electron., vol. 61,no. 11, pp. 6346–6355, Nov. 2014.[46] L. Shu, M. Hauswirth, H.-C. Chao, M. Chen, and Y. Zhang, “Nettopo: A framework of simulationand visualization for wireless sensor networks,” Ad Hoc Netw., vol. 9, no. 5, pp. 799–820, Jul. 2011.130Bibliography[47] C. Pelnekar, “Planning for and implementing iso 27001,” Inf. Syst. Audit Control Assoc. J., vol. 4,2011.[48] ISO, “Iso/iec 27001:2013 information technology - security techniques - information security man-agement systems - requirements,” 2013.[49] N. Karten, “How to establish service level agreements,” published as a Book, 2003.[50] P. Wieder, J. M. Butler, W. Theilmann, and R. Yahyapour, “Service level agreements for cloudcomputing,” published as a Book, 2011.[51] “Privacy level agreement outline for the sale of cloud services in the european union,” published byCloud Security Alliance, 2013.[52] H. Yu, Z. Shen, C. Miao, C. Leung, and D. Niyato, “A survey of trust and reputation managementsystems in wireless communications,” Proc. IEEE, vol. 98, no. 10, pp. 1755–1772, Oct. 2010.[53] J.-H. Cho, A. Swami, and I.-R. Chen, “A survey on trust management for mobile ad hoc networks,”IEEE Commun. Surveys Tuts., vol. 13, no. 4, pp. 562–583, Fourth Quarter 2011.[54] K. Govindan and P. Mohapatra, “Trust computations and trust dynamics in mobile adhoc networks:A survey,” IEEE Commun. Surveys Tuts., vol. 14, no. 2, pp. 279–298, Second Quarter 2012.[55] A. Das and M. M. Islam, “Securedtrust: A dynamic trust computation model for secured communi-cation in multiagent systems,” IEEE Trans. Dependable Secure Comput., vol. 9, no. 2, pp. 261–274,Mar.-Apr. 2012.131Bibliography[56] J. M. Pujol, R. Sanguesa, and J. Delgado, “Extracting reputation in multi agent systems by meansof social network topology,” in Proc. 1st Int. Joint Conf. Auton. Agents Multiagent Syst., 2002, pp.467–474.[57] C. Zhu, H. Wang, V. C. M. Leung, L. Shu, and L. T. Yang, “An evaluation of user importance whenintegrating social networks and mobile cloud computing,” in Proc. IEEE Global Commun. Conf.,2014, pp. 2935–2940.[58] A. Josang and R. Ismail, “The beta reputation system,” in Proc. 15th Bled Electron. Commer. Conf.,2002, pp. 324–337.[59] S. Ganeriwal, L. K. Balzano, and M. B. Srivastava, “Reputation-based framework for high integritysensor networks,” ACM Trans. Sens. Netw., vol. 4, no. 3, May 2008.[60] T. Qin, H. Yu, C. Leung, Z. Shen, and C. Miao, “Towards a trust aware cognitive radio architecture,”ACM SIGMOBILE Mob. Comput. Commun. Rev., vol. 13, no. 2, pp. 86–95, Apr. 2009.[61] W. Viriyasitavat and A. Martin, “A survey of trust in workflows and relevant contexts,” IEEECommun. Surveys Tuts., vol. 14, no. 3, pp. 911–940, Third Quarter 2012.[62] “Us government cloud computing technology roadmap volume ii release 1.0 (draft),” National Insti-tute of Standard and Technology, Nov. 2011.[63] S. Reece, A. Rogers, S. Roberts, and N. R. Jennings, “Rumours and reputation: evaluating multi-dimensional trust within a decentralised reputation system,” in Proc. 6th Int. Joint Conf. Auton.Agents Multiagent Syst., 2007, pp. 1063–1070.132Bibliography[64] G. Wang and J. Wu, “Multi-dimensional evidence-based trust management with multi-trusted paths,”Future Generation Comput. Syst., vol. 27, no. 5, pp. 529–538, May 2011.[65] D. Dolev and A. Yao, “On the security of public key protocols,” IEEE Trans. Inf. Theory, vol. 29,no. 2, pp. 198–208, Mar. 1983.[66] Y. L. Sun, Z. Han, W. Yu, and K. J. R. Liu, “A trust evaluation framework in distributed networks:Vulnerability analysis and defense against attacks,” in Proc. 25th IEEE Int. Conf. Comput. Commun.,2006, pp. 1–13.[67] Y. Sun and Y. Liu, “Security of online reputation systems: The evolution of attacks and defenses,”IEEE Signal Process. Mag., vol. 29, no. 2, pp. 87–97, Mar. 2012.[68] K. Hoffman, D. Zage, and C. Nita-Rotaru, “A survey of attack and defense techniques for reputationsystems,” ACM Comput. Surv., vol. 42, no. 1, Dec. 2009.[69] F. Wang, J. Liu, and M. Chen, “Calms: Cloud-assisted live media streaming for globalized demandswith time/region diversities,” in Proc. IEEE Int. Conf. Comput. Commun., 2012, pp. 199–207.[70] B. Pan, X. Wang, C.-P. Hong, and S.-D. Kim, “Amvp-cloud: A framework of adaptive mobile videostreaming and user behavior oriented video pre-fetching in the clouds,” in Proc. IEEE 12th Int. Conf.Comput. Inf. Technol., 2012, pp. 398–405.[71] A. M. Riad, M. Elmogy, and A. I. Shehab, “A framework for cloud p2p vod system based on user’sbehavior analysis,” Int. J. Comput. Appl., vol. 76, no. 6, pp. 20–26, Aug. 2013.[72] F. Hu, Y. Xiao, and Q. Hao, “Congestion-aware, loss-resilient bio-monitoring sensor networking formobile health applications,” IEEE J. Sel. Areas Commun., vol. 27, no. 4, pp. 450–465, May 2009.133Bibliography[73] W. Fang, F. Liu, F. Yang, L. Shu, and S. Nishio, “Energy-efficient cooperative communication fordata transmission in wireless sensor networks,” IEEE Trans. Consum. Electron., vol. 56, no. 4, pp.2185–2192, Nov. 2010.[74] C. Zhu, H. Wang, X. Liu, L. Shu, L. T. Yang, and V. C. M. Leung, “A novel sensory data processingframework to integrate sensor networks with mobile cloud,” IEEE Syst. J., vol. PP, no. 99, pp. 1–12,Jan. 2014.[75] C. Zhu, V. C. M. Leung, L. T. Yang, and L. Shu, “Collaborative location-based sleep scheduling forwireless sensor networks integrated with mobile cloud computing,” IEEE Trans. Comput., vol. 64,no. 7, pp. 1844–1856, Jul. 2015.[76] W. Fang, J. Chen, L. Shu, T. Chu, and D. Qian, “Congestion avoidance, detection and alleviationin wireless sensor networks,” J. Zhejiang Univ. Sci. C, vol. 11, no. 1, pp. 63–73, Jan. 2010.[77] B. Sheng, Q. Li, and W. Mao, “Optimize storage placement in sensor networks,” IEEE Trans. MobileComput., vol. 9, no. 10, pp. 1437–1450, Oct. 2010.[78] R. Arroyo-Valles, A. G. Marques, and J. Cid-Sueiro, “Optimal selective transmission under energyconstraints in sensor networks,” IEEE Trans. Mobile Comput., vol. 8, no. 11, pp. 1524–1538, Nov.2009.[79] G. Battistelli, A. Benavoli, and L. Chisci, “Data-driven strategies for selective data transmission insensor networks,” in Proc. IEEE 51st Annu. Conf. Decis. Control, 2012, pp. 800–805.[80] R. Arroyo-Valles, A. G. Marques, and J. Cid-Sueiro, “Optimal selective forwarding for energy savingin wireless sensor networks,” IEEE Trans. Wireless Commun., vol. 10, no. 1, pp. 164–175, Jan. 2011.134Bibliography[81] C. Zhu, L. T. Yang, L. Shu, T. Q. Duong, and S. Nishio, “Secured energy-aware sleep schedulingalgorithm in duty-cycled sensor networks,” in Proc. IEEE Int. Conf. Commun., 2012, pp. 1953–1957.[82] C. Zhu, L. T. Yang, L. Shu, V. C. M. Leung, T. Hara, and S. Nishio, “Insights of top-k query induty-cycled wireless sensor networks,” IEEE Trans. Ind. Electron., vol. 62, no. 2, pp. 1317–1328,Feb. 2015.[83] C. Zhu, H. Nicanfar, V. C. M. Leung, and L. T. Yang, “An authenticated trust and reputationcalculation and management system for cloud and sensor networks integration,” IEEE Trans. Inf.Forensics Security, vol. 10, no. 1, pp. 118–131, Jan. 2015.[84] Y. Jiang and J. C. Jiang, “Understanding social networks from a multiagent perspective,” IEEETrans. Parallel Distrib. Syst., vol. 25, no. 10, pp. 2743–2759, Oct. 2014.[85] A. M. Vegni and V. Loscri, “A survey on vehicular social networks,” IEEE Commun. Surveys Tuts.,vol. 17, no. 4, pp. 2397–2419, Fourth Quarter 2015.[86] F. Hao, G. Min, Z. Pei, D.-S. Park, and L. T. Yang, “k-clique communities detection in socialnetworks based on formal concept analysis,” IEEE Syst. J., vol. PP, no. 99, pp. 1–10, Jun. 2015.[87] K. Chard, K. Bubendorfer, S. Caton, and O. F. Rana, “Social cloud computing: A vision for sociallymotivated resource sharing,” IEEE Trans. Services Comput., vol. 5, no. 4, pp. 551–563, FourthQuarter 2012.[88] F. Hao, G. Min, J. Chen, F. Wang, M. Lin, C. Luo, and L. T. Yang, “An optimized computationalmodel for multi-community-cloud social collaboration,” IEEE Trans. Services Comput., vol. 7, no. 3,pp. 346–358, Jul.-Sept. 2014.135Bibliography[89] S. Caton, C. Haas, K. Chard, K. Bubendorfer, and O. F. Rana, “A social compute cloud: Allocatingand sharing infrastructure resources via social networks,” IEEE Trans. Services Comput., vol. 7,no. 3, pp. 359–372, Jul.-Sept. 2014.136

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0305686/manifest

Comment

Related Items