Essay preview
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
1
Context Aware Computing for The Internet of Things: A Survey Charith Perera, Student Member, IEEE, Arkady Zaslavsky, Member, IEEE, Peter Christen, and Dimitrios Georgakopoulos, Member, IEEE Abstract—As we are moving towards the Internet of Things (IoT), the number of sensors deployed around the world is growing at a rapid pace. Market research has shown a significant growth of sensor deployments over the past decade and has predicted a significant increment of the growth rate in the future. These sensors continuously generate enormous amounts of data. However, in order to add value to raw sensor data we need to understand it. Collection, modelling, reasoning, and distribution of context in relation to sensor data plays critical role in this challenge. Context-aware computing has proven to be successful in understanding sensor data. In this paper, we survey context awareness from an IoT perspective. We present the necessary background by introducing the IoT paradigm and context-aware fundamentals at the beginning. Then we provide an in-depth analysis of context life cycle. We evaluate a subset of projects (50) which represent the majority of research and commercial solutions proposed in the field of context-aware computing conducted over the last decade (2001-2011) based on our own taxonomy. Finally, based on our evaluation, we highlight the lessons to be learnt from the past and some possible directions for future research. The survey addresses a broad range of techniques, methods, models, functionalities, systems, applications, and middleware solutions related to context awareness and IoT. Our goal is not only to analyse, compare and consolidate past research work but also to appreciate their findings and discuss their applicability towards the IoT. Index Terms—Internet of things, context awareness, sensor networks, sensor data, context life cycle, context reasoning, context modelling, ubiquitous, pervasive, mobile, middleware.
I. I NTRODUCTION ONTEXT awareness, as a core feature of ubiquitous and pervasive computing systems, has existed and been employed since the early 1990s. The focus on context-aware computing evolved from desktop applications, web applications, mobile computing, pervasive/ubiquitous computing to the Internet of Things (IoT) over the last decade. However, context-aware computing became more popular with the introduction of the term ‘ubiquitous computing’ by Mark Weiser [1] in his ground-breaking paper The Computer for the 21st Century in 1991. Then the term ‘context-aware’ was first used by Schilit and Theimer [2] in 1994. Since then, research into context-awareness has been established as a well known research area in computer science. Many researchers have proposed definitions and explanations of different aspects of context-aware computing, as we will
C
Charith Perera, Arkady Zaslavsky and Dimitrios Georgakopoulos are with the Information and Communication Centre, Commonwealth Scientific and Industrial Research Organisation, Canberra, ACT, 2601, Australia (e-mail: fi[email protected]) Peter Christen is with the Research School of Computer Science, The Australian National University, Canberra, ACT 0200, Australia. (e-mail: [email protected]) Manuscript received xxx xx, xxxx; revised xxx xx, xxxx.
discuss briefly in Section III. The definitions for ‘context’ and ‘context-awareness’ that are widely accepted by the research community today were proposed by Abowd et al. [3] in 1999. During the last two decades, researchers and engineers have developed a significant amount of prototypes, systems, and solutions using context-aware computing techniques. Even though the focus varied depending on each project, one aspect remained fairly unchanged: that is the number of data sources (e.g. software and hardware sources). For example, most of the proposed solutions collect data from a limited number of physical (hardware) and virtual (software) sensors. In these situations, collecting and analysing sensor data from all the sources is possible and feasible due to limited numbers. In contrast, IoT envisions an era where billions of sensors are connected to the Internet, which means it is not feasible to process all the data collected by those sensors. Therefore, context-awareness will play a critical role in deciding what data needs to be processed and much more. Due to advances in sensor technology, sensors are getting more powerful, cheaper and smaller in size, which has stimulated large scale deployments. As a result, today we have a large number of sensors already deployed and it is predicted that the numbers will grow rapidly over the next decade [4]. Ultimately, these sensors will generate big data [5]. The data we collect may not have any value unless we analyse, interpret, and understand it. Context-aware computing has played an important role in tackling this challenge in previous paradigms, such as mobile and pervasive, which lead us to believe that it would continue to be successful in the IoT paradigm as well. Context-aware computing allows us to store context1 information linked to sensor data so the interpretation can be done easily and more meaningfully. In addition, understanding context makes it easier to perform machine to machine communication as it is a core element in the IoT vision. When large numbers of sensors are deployed, and start generating data, the traditional application based approach (i.e. connect sensors directly to applications individually and manually) becomes infeasible. In order to address this inefficiency, significant amounts of middleware solutions are introduced by researchers. Each middleware solution focuses on different aspects in the IoT, such as device management, interoperability, platform portability, context-awareness, security and privacy, 1 The term ‘context’ implicitly provide the meaning of ‘information’ according to the widely accepted definition provided by [3]. Therefore, it is inaccurate to use the term ‘context information’ where ‘information’ is explicitly mentioned. However, research community and documents on the web frequently use the term ‘context information’. Therefore, we also use both terms interchangeably.
arXiv:1305.0982v1 [cs.SE] 5 May 2013
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
2
and many more. Even though, some solutions address multiple aspects, an ideal middleware solution that addresses all the aspects required by the IoT is yet to be designed. In this survey, we consider identifying the context-aware computing related features and functionalities that are required by an ideal IoT middleware solution as a key task. There have been several surveys conducted in relation to this field. We briefly introduce these surveys in chronological order. Chen and Kotz [6] (2000) have surveyed context awareness, focusing on applications, what context they use, and how contextual information is leveraged. In 2004, Strang and Linnhoff-Popien [7] compared the most popular context modelling techniques in the field. Middleware solutions for sensor networks are surveyed by Molla and Ahamed [8] in 2006. Two separate surveys were conducted by Kjaer [9] and Baldauf et al. [10] in 2007 on context-aware systems and middleware solutions using different taxonomies. Both surveys compared limited numbers, but different projects with very little overlap. c et al. [11] (2009) reviewed popular context representation and reasoning from a pervasive computing perspective. In 2010, Bettini et al. [12] also comprehensively surveyed context modelling and reasoning by focusing on techniques rather than projects. In the same year another survey was done by Saeed and Waheed [13] focusing on architectures in the context-aware middleware domain. Bandyopadhyay et al. [14] have conducted a survey on existing popular Internet of Things middleware solutions in 2011. In 2012, Makris et al. [15] have conducted a survey on context-aware mobile and wireless networking (CAMoWiN) domain where they have identified all the possible components of a typical CAMoWiN architecture. The latest survey is done by Bellavista et al. [16] (2013) which is focused on context distribution for mobile ubiquitous systems. Our survey differs from the previous literature surveys mentioned above in many ways. Most of the surveys evaluated a limited number of projects. In contrast, we selected a large number of projects (50) covering a decade, based on the unique criteria that will be explained at the end of this section. These projects are different in scale. Some are large scale projects and others corresponds to small scale contributions. We took a much broader viewpoint compared to some of the previous surveys, as they have focused on specific elements such as modelling, reasoning, etc. Finally and most importantly, our taxonomy formation and organisation is completely different. Rather than building a theoretical taxonomy and then trying to classify existing research projects, prototypes and systems according to it, we use a practical approach. We built our taxonomy based on past research projects by identifying the features, models, techniques, functionalities and approaches they employed at higher levels (e.g. we do not consider implementation/code level differences between different solutions). We consolidated this information and analysed the capabilities of each solution or the project. We believe this approach allows us to highlight the areas where researchers have mostly (priorities) and rarely (non-priorities) focused their attention and the reasons behind. Further, we have also used a non-taxonomical project based evaluation, where we highlight how the different combinations of components are
designed, developed and used in each project. This allows to discuss their applicability from an IoT perspective. Our objectives in revisiting the literature are threefold: 1) to learn how context-aware computing techniques have helped to develop solutions in the past, 2) how can we apply those techniques to solve problems in the future in different paradigms such as the IoT, and 3) to highlight open challenges and to discuss future research directions. This paper is organised into sections as follows: Section II provides an introduction to the IoT. In this section, we briefly describe the history and evolution of the Internet. Then we explain what the IoT is, followed by a list of application domains and statistics that show the significance of the IoT. We also describe the relationship between sensor networks and the IoT. Comparisons of popular IoT middleware solutions are presented at the end of the section in order to highlight existing research gaps. In Section III, we present context awareness fundamentals such as context-aware related definitions, context types and categorisation schemes, features and characteristics, and context awareness management design principles. In Section IV, we conduct our main discussion based on context life cycle where we identify four stages: acquisition, modelling, reasoning, and distribution. Section V briefly discusses the highlights of each project, which we use for the comparison later. Finally, Section VI discusses the lessons learn from the literature and Section VII identifies future research directions and challenges. Conclusion remarks are presented in Section VIII. For this literature review, we analyse, compare, classify a subset of both small scale and large scale projects (50) which represent the majority of research and commercial solutions proposed in the field of context-aware computing based on our own taxonomy. We selected the existing solutions to be reviewed based on different criteria. Mainly, we selected projects that were conducted over the last decade (2001-2011). We also considered main focus, techniques used, popularity, comprehensiveness, information availability, and the year of publication, in order to make sure that our review provides a balanced view on context-aware computing research. II. T HE I NTERNET OF T HINGS PARADIGM In this section, we briefly introduce the IoT paradigm. Our intention is not to survey the IoT, but to present some fundamental information (e.g. how Internet evolved, what is the IoT, statistics related to IoT, underline technologies, characteristics, and research gaps in IoT paradigm) that will help with understanding the historic movements and the direction into which technology is moving today. The IoT paradigm has its own concepts and characteristics. It also shares significant amounts of concepts with other computer fields. The IoT bundles different technologies (e.g. sensor hardware/firmware, semantic, cloud, data modelling, storing, reasoning, processing, communication technologies) together to build its vision. We apply the existing technologies in different ways based on the characteristics and demands of the IoT. The IoT does not revolutionise our lives or the field of computing. It is another step in the evolution of the Internet we already have.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
3
Network
Host
The Internet
Mobile-Internet
Mobile Device Mobile Device Host
Mobiles + People + PCs
People Mobile Device Host Host Host Host
Internet of Things
Host Host Web Host Host
Host Host Mobile Device Host Mobile Device Mobile Device Host
People
Interconnected Objects
Fig. 1. Evolution of the Internet in five phases. The evolution of Internet begins with connecting two computers together and then moved towards creating World Wide Web by connecting large number of computers together. The mobile-Internet emerged by connecting mobile devices to the Internet. Then, peoples’ identities joined the Internet via social networks. Finally, it is moving towards Internet of Things by connecting every day objects to the Internet.
A. Evolution of Internet Before we investigate the IoT in depth, it is worthwhile to look at the evolution of the Internet. In the late 1960s, communication between two computers was made possible through a computer network [17]. In the early 1980s the TCP/IP stack was introduced. Then, commercial use of the Internet started in the late 1980s. Later, the World Wide Web (WWW) became available in 1991 which made the Internet more popular and stimulate the rapid growth. Web of Things (WoT) [18], which based on WWW, is a part of IoT. Later, mobile devices connected to the Internet and formed the mobile-Internet [19]. With the emergence of social networking, users started to become connected together over the Internet. The next step in the IoT is where objects around us will be able to connect to each other (e.g. machine to machine) and communicate via the Internet [20]. Figure 1 illustrates the five phases in the evolution of the Internet. B. What is the Internet of Things? During the past decade, the IoT has gained significant attention in academia as well as industry. The main reasons behind this interest are the capabilities that the IoT [22], [23] will offer. It promises to create a world where all the objects (also called smart objects [24]) around us are connected to the Internet and communicate with each other with minimum human intervention [25]. The ultimate goal is to create ‘a better world for human beings’, where objects around us know what we like, what we want, and what we need and act accordingly without explicit instructions [26]. The term ‘Internet of Things’ was firstly coined by Kevin Ashton [27] in a presentation in 1998. He has mentioned “The Internet of Things has the potential to change the world, just as the Internet did. Maybe even more so”. Then, the MIT Auto-ID centre presented their IoT vision in 2001 [28]. Later, IoT was formally introduced by the International Telecommunication Union (ITU) by the ITU Internet report in 2005 [29]. The IoT encompasses a significant amount of technologies that drive its vision. In the document, Vision and challenges
for realising the Internet of Things, by CERP-IoT [4], a comprehensive set of technologies was listed. IoT is a very broad vision. The research into the IoT is still in its infancy. Therefore, there aren’t any standard definitions for IoT. The following definitions were provided by different researchers. Definition by [30]: “Things have identities and virtual personalities operating in smart spaces using intelligent interfaces to connect and communicate within social, environment, and user contexts.” • Definition by [20]:“The semantic origin of the expression is composed by two words and concepts: Internet and Thing, where Internet can be defined as the world-wide network of interconnected computer networks, based on a standard communication protocol, the Internet suite (TCP/IP), while Thing is an object not precisely identifiable Therefore, semantically, Internet of Things means a world-wide network of interconnected objects uniquely addressable, based on standard communication protocols.” •
Anytime Any context Anything Any device Anyone Anybody
Internet of Things
Any place Anywhere Any path Any Network Any Service Any Business
Fig. 2. Definition of the Internet of Things: The Internet of Things allows people and things to be connected anytime, anyplace, with anything and anyone, ideally using any path/network and any service [21].
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
4
Definition by [21]: “The Internet of Things allows people and things2 to be connected Anytime, Anyplace, with Anything and Anyone, ideally using Any path/network and Any service.” We accept the last definition provided by [21] for our research work, because we believe, this definition encapsulates the broader vision of IoT. Figure 2 illustrates the definition more clearly. The broadness of IoT can be identified by evaluating the application domains presented in Section II-C. •
together through different technologies and protocols. One such approach is through the Internet. The components and the layered structure of a typical sensor network are discussed in Section II-F. We discuss how sensor networks and the IoT work together in Section II-G. However, there are other technologies that can complement the sensing and communication infrastructure in IoT paradigm such as traditional ad-hoc networks. These are clearly a different technology from sensor networks and have many weaknesses. The differences are comprehensively discussed in [39]. There are three main architectures in sensor networks: flat architecture (data transfers from static sensor nodes to the sink node using a multi-hop fashion), two-layer architecture (more static and mobile sink nodes are deployed to collect data from sensor nodes), and three-layer architecture (multiple sensor networks are connected together over the Internet). Therefore, IoT follows a three-layer architecture. Most of the sensors deployed today are wireless. There are several major wireless technologies used to build wireless sensor networks: wireless personal area network (WPAN) (e.g. Bluetooth), wireless local area network (WLAN) (e.g. Wi-Fi), wireless metropolitan area network (WMAN) (e.g. WiMAX), wireless wide area network (WWAN) (e.g. 2G and 3G networks), and satellite network (e.g. GPS). Sensor networks also use two types of protocols for communication: non-IP based (e.g: Zigbee and Sensor-Net) and IP-based protocols (NanoStack, PhyNet, and IPv6). The sensor network is not a concept that emerged with the IoT. The concept of a sensor network and related research existed a long time before the IoT was introduced. However, sensor networks were used in limited domains to achieve specific purposes, such as environment monitoring [40], agriculture [35], medical care [41], event detection [42], structural health monitoring [43], etc. Further, there are three categories of sensor networks that comprise the IoT [44]: body sensor networks (BSN), object sensor networks (OSN), and environment sensor networks (ESN). Molla and Ahamed [8] identified ten challenges that need to be considered when developing sensor network middleware solutions: abstraction support, data fusion, resource constraints, dynamic topology, application knowledge, programming paradigm, adaptability, scalability, security, and QoS support. A comparison of different sensor network middleware solutions is also provided based on the above parameters. Several selected projects are also discussed in brief in order to discover the approaches they take to address various challenges associated with sensor networks. Some of the major sensor network middleware approaches are IrisNet, JWebDust, Hourglass, HiFi, Cougar, Impala, SINA, Mate, TinyDB, Smart Object, Agilla, TinyCubus, TinyLime, EnviroTrack, Mires, Hood, and Smart Messages. Some of the above approaches are surveyed in [8], [45]. A survey on web based wireless sensor architectures and applications is presented in [46].
C. IoT Application Domains The IoT, interconnection and communication between everyday objects, enables many applications in many domains. The application domain can be mainly divided in to three categories based on their focus [23], [4]: industry, environment, and society. The magnitude of the applications can be seen in the statistics presented in Section II-D. Supply chain management [31], transportation and logistics [32], aerospace, aviation, and automotive are some of the industry focused applications of IoT. Telecommunication, medical technology [33], healthcare, smart building, home [34] and office, media, entertainment, and ticketing are some of the society focused applications of IoT. Agriculture and breeding [35], [36], recycling, disaster alerting, environmental monitoring are some of the environment focused applications. Asin and Gascon [37] listed 54 application domains under twelve categories: smart cities, smart environment, smart water, smart metering, security and emergencies, retail, logistics, industrial control, smart agriculture, smart animal farming, domestic and home automation, and eHealth. D. IoT Related Statistics The vision of the IoT is heavily energised by statistics and predictions. We present the statistics to justify our focus on the IoT and to show the magnitude of the challenges. It is estimated that there about 1.5 billion Internet-enabled PCs and over 1 billion Internet-enabled mobile phones today. These two categories will be joined with Internet-enabled devices (smart objects [24])) in the future. By 2020, there will be 50 to 100 billion devices connected to the Internet [4]. According to BCC Research [38], the global market for sensors was around $56.3 billion in 2010. In 2011, it was around $62.8 billion. Global market for sensors is expected to increase to $91.5 billion by 2016, at a compound annual growth rate of 7.8%. E. The Essential Component of IoT: Sensor Networks We provide a brief introduction to sensor networks in this section as it is the most essential component of the IoT. A sensor network comprises one or more sensor nodes, which communicate between themselves using wired and wireless technologies. In sensor networks, sensors can be homogeneous or heterogeneous. Multiple sensor networks can be connected 2 We use both terms, ‘objects’ and ‘things’ interchangeably to give the same meaning as they are frequently used in IoT related documentation. Some other terms used by the research community are ‘smart objects’, ‘devices’, ‘nodes’.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
5
F. Layers in Sensor Networks We have presented a typical structure of a sensor network in Figure 3. It comprises the most common components in a sensor network. As we have shown, with the orange coloured arrows, data flows from right to left. Data is generated by the low-end sensor nodes and high-end sensor nodes. Then, data is collected by mobile and static sink nodes. The sink nodes send the data to low-end computational devices. These devices perform a certain amount of processing on the sensor data. Then, the data is sent to high-end computational devices to be processed further. Finally, data reaches the cloud where it will be shared, stored, and processed significantly. High-end Low-end Computational Computational Devices Devices Sink Nodes Static Sink Node
Cloud (Internet)
Sensor Networks (SN2) High-end Low-end Sensor Sensor Nodes Nodes
Mobile Sink Node
Layer 6 Layer 5 Layer 4 Layer 3 Layer 2 Layer 1
Fig. 3. Layered structure of a sensor network: These layers are identified based on the capabilities posed by the devices. In IoT, this layered architecture may have additional number of sub layers as it is expected to comprises large verity of in sensing capabilities.
Based on the capabilities of the devices involved in a sensor network, we have identified six layers. Information can be processed in any layer. Capability means the processing, memory, communication, and energy capacity. Capabilities increase from layer one to layer six. Based on our identification of layers, it is evident that an ideal system should understand the capability differences, and perform data management accordingly. It is all about efficiency and effectiveness. For example, perform processing in the first few layers could reduce data communication. However, devices in the first few layers do not have a sufficient amount of energy and processing power to do comprehensive data processing [47]. IoT research needs to find more efficient and effective ways of data management, such as collecting, modelling, reasoning, distributing. G. Relationship Between Sensor Networks and IoT In earlier sections we introduced both IoT and sensor network concepts. In this section we explain the relationship between the two concepts. Previously, we argued that sensor networks are the most essential components of the IoT. Figure 4 illustrates the big picture. The IoT comprises sensors and actuators. The data is collected using sensors. Then, it is processed and decisions are made. Finally, actuators perform the decided actions. This process is further discussed in Section IV. Further, integration between wireless sensor networks and the IoT are comprehensively discussed in [48]. The difference between sensor networks (SN) and the IoT is largely unexplored and blurred. We can elaborate some of the characteristics of both SN and IoT to identify the differences. • SN comprises of the sensor hardware (sensors and actuators), firmware and a thin layer of software. The IoT
comprises everything that SN comprises and further it comprises a thick layer of software such as middleware systems, frameworks, APIs and many more software components. The software layer is installed across computational devices (both low and high-end) and the cloud. • From their origin, SNs were designed, developed, and used for specific application purposes, for example, detecting bush fire [44]. In the early days, sensor networks were largely used for monitoring purposes and not for actuation [49]. In contrast, IoT is not focused on specific applications. The IoT can be explained as a general purpose sensor network [50]. Therefore, the IoT should support many kinds of applications. During the stage of deploying sensors, the IoT would not be targeted to collect specific types of sensor data, rather it would deploy sensors where they can be used for various application domains. For example, company may deploy sensors, such as pressure sensors, on a newly built bridge to track its structural health. However, these sensors may be reused and connect with many other sensors in order to track traffic at a later stage. Therefore, middleware solutions, frameworks, and APIs are designed to provide generic services and functionalities such as intelligence, semantic interoperability, context-awareness, etc. that are required to perform communication between sensors and actuators effectively. • Sensor networks can exist without the IoT. However, the IoT cannot exist without SN, because SN provides the majority of hardware (e.g. sensing and communicating) infrastructure support, through providing access to sensors and actuators. There are several other technologies that can provide access to sensor hardware, such as wireless ad-hoc networks. However, they are not scalable and cannot accommodate the needs of the IoT individually [39], though they can complement the IoT infrastructure. As is clearly depicted in Figure 4, SN are a part of the IoT. However, the IoT is not a part of SN. Users Services
Applications Internet of Things Middleware + Frameworks + APIs
Sensor Network Firmware Sensors Actuators
Other Technologies
Fig. 4.
Relationship between sensor networks and IoT.
H. Characteristics of the IoT In Section II-G, we highlighted the differences between sensor networks and the IoT. Further, we briefly explore the characteristics of the IoT from a research perspective. Based on
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
6
previous research efforts we identified seven major characteristics in the IoT [4]: intelligence, architecture, complex system, size considerations, time considerations, space considerations, and everything-as-a-service. These characteristics need to be considered when developing IoT solutions throughout all the phases from design, development, implement and evaluation. • Intelligence: This means the application of knowledge. First the knowledge needs to be generated by collecting data and reasoning it. Transforming the collected raw data into knowledge (high-level information) can be done by collecting, modelling, and reasoning the context. Context can be used to fuse sensor data together to infer new knowledge. Once we have knowledge, it can be applied towards more intelligent interaction and communication. • Architecture: IoT should be facilitated by a hybrid architecture which comprises many different architectures. Primarily there would be two architectures: event driven [51] and time driven. Some sensors produce data when an event occurs (e.g. door sensor); the rest produce data continuously, based on specified time frames (e.g. temperature sensor). Mostly, the IoT and SN are event driven [52]. Event-Condition-Action (ECA) rules are commonly used in such systems. • Complex system: The IoT comprises a large number of objects (sensors and actuators) that interact autonomously. New objects will start communicating and existing ones will disappear. Currently, there are millions of sensors deployed around the world [53]. Interactions may differ significantly depending on the objects capabilities. Some objects may have very few capabilities, and as such store very limited information and do no processing at all. In contrast, some objects may have larger memory, processing, and reasoning capabilities, which make them more intelligent. • Size considerations: It is predicted that there will be 50100 billion devices connected to the Internet by 2020 [4]. The IoT needs to facilitate the interaction among these objects. The numbers will grow continuously and will never decrease. Similar to the number of objects, number of interactions may also increase significantly. • Time considerations: The IoT could handle billions of parallel and simultaneous events, due to the massive number of interactions. Real-time data processing is essential. • Space considerations: The precise geographic location of a object will be critical [54] as location plays a significant role in context-aware computing. When the number of objects get larger, tracking becomes a key requirement. Interactions are highly dependent on their locations, their surroundings, and presence of other entities (e.g. objects and people). • Everything-as-a-service: Due to the popularity of cloud computing [55], consuming resources as a service [56] such as Platform-as-a-Service (PaaS), Infrastructure-as-aService (IaaS), Software-as-a-Service (SaaS), has become main stream. Everything-as-a-service [57] model is highly efficient, scalable, and easy to use. IoT demands significant amounts of infrastructure to be put in place in order to make its vision a reality, where it would follow a community or crowd based approach. Therefore, sharing would be essential, where an everything-as-a-service model would suit mostly sensing-as-a-service [5].
I. Middleware Support for IoT As we mentioned at the beginning, the IoT needs to be supported by middleware solutions. “Middleware is a software layer that stands between the networked operating system and the application and provides well known reusable solutions to frequently encountered problems like heterogeneity, interoperability, security, dependability [58].” The functionalities required by IoT middleware solutions are explained in detail in [4], [19], [20], [21], [29]. In addition, challenges in developing middleware solutions for the IoT are discussed in [59]. We present the summary of a survey conducted by Bandyopadhyay et al. [14]. They have selected the leading middleware solutions and analyse them based on their functionalities, each one offers, device management, interoperation, platform portability, context-awareness, and security and privacy. Table I shows the survey results. By the time we were preparing this survey, some of the middleware solutions listed (i.e. GSN and ASPIRE) were in the processing of extending towards next generation solutions (i.e. EU FP7 project OpenIoT (20122014) [60]) by combining each other’s strengths. TABLE I I OT M IDDLEWARE C OMPARISON [14] Middleware Hydra [61] ISMB [62] ASPIRE [63] UBIWARE [64] UBISOAP [65] UBIROAD [66] GSN [67] SMEPP [68] SOCRADES [69] SIRENA [70] WHEREX [71] × × × × × × × × × × × × × × × × × DM I PP CA SP
Legend: Device Management (DM), Interoperation (I), Platform Portability (PP), Context Awareness (CA), Security & Privacy (SP)
J. Research Gaps According to Table I, it can be seen that the majority of the IoT middleware solutions do not provide context-awareness functionality. In contrast, almost all the solutions are highly focused on device management, which involves connecting sensors to the IoT middleware. In the early days, contextawareness was strongly bound to pervasive and ubiquitous computing. Even though there were some middleware solutions that provided an amount of context-aware functionality, they did not satisfy the requirements that the IoT demands. We discuss the issues and drawbacks with existing solutions, in detail, in Section V. We discuss some of the research directions in Section VII. In this section, we introduced the IoT paradigm and highlighted the importance of context-awareness for the IoT. We also learnt that context-awareness has not been addressed in existing IoT focused solutions, which motivates us to survey the solutions in other paradigms to evaluate the applicability of context-aware computing techniques toward IoT. In the next section we discuss context-aware fundamentals that helps us understand the in-depth discussions in the later sections.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
7
III. C ONTEXT AWARENESS F UNDAMENTALS This section discusses definitions of context and context awareness, context-aware features, types of context and categorisation schemes, different levels and characteristics of context-awareness, and finally, context management design principles in the IoT paradigm. A. Context-awareness Related Definitions 1) Definition of Context: The term context has been defined by many researchers. Dey et al. [72] evaluated and highlighted the weaknesses of these definitions. Dey claimed that the definition provided by Schilit and Theimer [2] was based on examples and cannot be used to identify new context. Further, Dey claimed that definitions provided by Brown [73], Franklin and Flachsbart [74], Rodden et al. [75], Hull et al. [76], and Ward et al. [77] used synonyms to refer to context, such as environment and situation. Therefore, these definitions also cannot be used to identify new context. Abowd and Mynatt [78] identified the five W’s (Who, What, Where, When, Why) as the minimum information that is necessary to understand context. Schilit et al. [79] and Pascoe [80] have also defined the term context. Dey claimed that these definitions were too specific and cannot be used to identify context in a broader sense and provided a definition for context as follows: “Context is any information that can be used to characterise the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves [3].” We accept the definition of context provided by Abowd et al. [3] to be used in this research work, because this definition can be used to identify context from data in general. If we consider a data element, by using this definition, we can easily identify whether the data element is context or not. A number of dictionaries have also defined and explained the word context: • Synonyms [81]: “Circumstance, situation, phase, position, posture, attitude, place, point; terms; regime; footing, standing, status, occasion, surroundings, environment, location, dependence.” • Definition by FOLDOC [82]: “That which surrounds, and gives meaning to, something else.” • Definition by WordNet [83]: “Discourse that surrounds a language unit and helps to determine its interpretation” • Definition by Longman [84]: “The situation, events, or information that are related to something and that help you to understand it” In addition, Sanchez et al. [85] explained the distinction between raw data and context information as follows: • Raw (sensor) data: Is unprocessed and retrieved directly from the data source, such as sensors. • Context information: Is generated by processing raw sensor data. Further, it is checked for consistency and meta data is added. For example, the sensor readings produced by GPS sensors can be considered as raw sensor data. Once we put the GPS sensor readings in such a way that it represents a geographical
location, we call it context information. Therefore in general, the raw data values produced by sensors can be considered as data. If this data can be used to generate context information, we identify these data as context. Therefore, mostly what we capture from sensors are data not the context information. Ahn and Kim [86] define context (also called compound events) as a set of interrelated events with logical and timing relations among them. They also define an event as an occurrence that triggers a condition in a target area. There are two categories of events: discrete events and continuous events. If the sampling rate is p: • Discrete events: An event that occurs at time t and t + p, there are considered to have been two separate event instances. (e.g. a door open, lights on, etc.) • Continuous events: An event instance lasting for at least time p, where an event occurring at time t and t + p, cannot be considered as two separate events. (e.g. raining, having a shower, driving a car, etc.) 2) Definition of Context-awareness: The term context awareness, also called sentient, was first introduced by Schilit and Theimer [2] in 1994. Later, it was defined by Ryan et al. [87]. In both cases, the focus was on computer applications and systems. As stated by Abowd et al. [3], those definitions are too specific and cannot be used to identify whether a given system is a context-aware system or not. Therefore, Dey has defined the term context-awareness as follows: “A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user’s task. [3]” We accept the above definition on context-awareness to be used in our research work, because we can use this definition to identify context-aware systems from the rest. If we consider a system, by using this definition we can easily identify whether this system is a context-aware system or not. Context awareness frameworks typically should support acquisition, representation, delivery, and reaction [72]. In addition, there are three main approaches that we can follow to build contextaware applications [88]. • No application-level context model: Applications perform all the actions, such as context acquisition, pre-processing, storing, and reasoning within the application boundaries. • Implicit context model: Applications uses libraries, frameworks, and toolkits to perform context acquisition, preprocessing, storing, and reasoning tasks. It provides a standard design to follow that makes it easier to build the applications quickly. However, still the context is hard bound to the application. • Explicit context model: Applications uses a context management infrastructure or middleware solution. Therefore, actions such as context acquisition, pre-processing, storing, and reasoning lie outside the application boundaries. Context management and application are clearly separated and can be developed and extend independently. 3) Definition of Context Model and Context Attribute: We adopt the following interpretations of context model and context attributes provided by Henricksen [89] based on Abowd et al. [3] in our research work.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
8
“A context model identifies a concrete subset of the context that is realistically attainable from sensors, applications and users and able to be exploited in the execution of the task. The context model that is employed by a given context-aware application is usually explicitly specified by the application developer, but may evolve over time [89].” “A context attribute is an element of the context model describing the context. A context attribute has an identifier, a type and a value, and optionally a collection of properties describing specific characteristics [89].” 4) Definition of Quality of Context: There are number of definitions and parameters that have been proposed in the literature regarding quality of context (QoC). A survey on QoC is presented in [16]. QoC is defined using a set of parameters that expresses the quality of requirements and properties of the context data. After evaluating a number of different parameter proposals in the literature, [16] has defined QoC based on three parameters: context data validity, context data precision, and context data up-to-dateness. QoC are being used to resolve context data conflicts. Further, they claim that QoC is depend on quality of the physical sensor, quality of the context data, and quality of the delivery process. B. Context-aware Features After analysing and comparing the two previous efforts conducted by Schilit et al. [79] and Pascoe [80], Abowd et al. [3] identified three features that a context-aware application can support: presentation, execution, and tagging. Even though, the IoT vision was not known at the time these features are identified, they are highly applicable to the IoT paradigm as well. We elaborate these features from an IoT perspective. • Presentation: Context can be used to decide what information and services need to be presented to the user. Let us consider a smart [22] environment scenario. When a user enters a supermarket and takes their smart phone out, what they want to see is their shopping list. Context-aware mobile applications need to connect to kitchen appliances such as a smart refrigerator [90] in the home to retrieve the shopping list and present it to the user. This provides the idea of presenting information based on context such as location, time, etc. By definition, IoT promises to provide any service anytime, anyplace, with anything and anyone, ideally using any path/network. • Execution: Automatic execution of services is also a critical feature in the IoT paradigm. Let us consider a smart home [22] environment. When a user starts driving home from their office, the IoT application employed in the house should switch on the air condition system and switch on the coffee machine to be ready to use by the time the user steps into their house. These actions need to be taken automatically based on the context. Machine-to-machine communication is a significant part of the IoT. • Tagging: In the IoT paradigm, there will be a large number of sensors attached to everyday objects. These objects will produce large volumes of sensor data that has to be collected, analysed, fused and interpreted [91]. Sensor data produced by a single sensor will not provide the necessary information
that can be used to fully understand the situation. Therefore, sensor data collected through multiple sensors needs to be fused together. In order to accomplish the sensor data fusion task, context needs to be collected. Context needs to be tagged together with the sensor data to be processed and understood later. Context annotation plays a significant role in context-aware computing research. We also call this tagging operation as annotation as well. C. Context Types and Categorisation Schemes Different researchers have identified context types differently based of different perspectives. Abowd et al. [3] introduced one of the leading mechanisms of defining context types. They identified location, identity, time, and activity as the primary context types. Further, they defined secondary context as the context that can be found using primary context. For example, given primary context such as a person’s identity, we can acquire many pieces of related information such as phone numbers, addresses, email addresses, etc. However, using this definition we are unable to identify the type of a given context. Let us consider two GPS sensors located in two different locations. We can retrieve GPS values to identify the position of each sensor. However, we can only find the distance between the two sensors by performing calculations based on the raw values generated by the two sensor. The question is, ‘what is the category that distance belongs to?’ ‘is it primary or secondary?’ The distance is not just a value that we sensed. We computed the distance by fusing two pieces of context. The above definition does not represent this accurately. Thus, we define a context categorisation scheme (i.e. primary and secondary) that can be used to classify a given data value (e.g. single data item such as current time) of context in terms of an operational perspective (i.e. how the data was acquired). However, the same data value can be considered as primary context in one scenario and secondary context in another. For example, if we collect the blood pressure level of a patient directly from a sensor attached to the patient, it could be identified as primary context. However, if we derive the same information from a patient’s health record by connecting to the hospital database, we call it secondary context. Therefore, the same information can be acquired using different techniques. It is important to understand that the quality, validity, accuracy, cost and effort of acquisition, etc. may varied significantly based on the techniques used. This would be more challenging in the IoT paradigm, because there would be a large amount of data sources that can be used to retrieve the same data value. To decide which source and technique to use would be a difficult task. We will revisit this challenge in Section VI. In addition, a similar type of context information can be classified as both primary and secondary. For example, location can be raw GPS data values or the name of the location (e.g. city, road, restaurant). Therefore, identifying a location as primary context without examining how the data has been collected is fairly inaccurate. Figure 5 depicts how the context can be identified using our context type definitions.
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
9
TABLE II D IFFERENT C ONTEXT C ATEGORISATION S CHEMES AND T HEIR S COPES (2006) Miao and Yuan [96] (2005) Van Bunningen [95]
(2000) Chen and Kotz [6]
(2003) Henricksen [89]
(2003) Prekop & Burnett [92], Gustavsen [93], Hofer [94]
(2009) Mei & Easterbrook [100]
(2007) Guan [97]
Context Types User Computing (System) Physical (Environment) Historical Social Networking Things Sensor Who (Identity) Where (Location) When (Time) What (Activity) Why Sensed Static Profiled Derived Operational Conceptual Objective Cognitive External (Physical) Internal (Logical) Low-level (Observable) High-level (Non-Observable)
Categories of Context (Conceptual Perspective) Activity Time Identity Location
Primary context: Any information retrieved without using existing context and without performing any kind of sensor data fusion operations (e.g. GPS sensor readings as location information). • Secondary context: Any information that can be computed using primary context. The secondary context can be computed by using sensor data fusion operations or data retrieval operations such as web service calls (e.g. identify the distance between two sensors by applying sensor data fusion operations on two raw GPS sensor values). Further, retrieved context such as phone numbers, addresses, email addresses, birthdays, list of friends from a contact information provider based on a personal identity as the primary context can also be identified as secondary context. •
Categories of Context (Operational Perspective) Primary Secondary Distance of two sensors computed using GPS values Image of a map retrieved from map service provider Retrieve friend list from users Facebook profile Identify a face of a person using facial recognition system Calculate the season based on the weather information Predict the time based on the current activity and calender Predict the user activity based on the user calender Find the user activity based on mobile phone sensors such as GPS, gyroscope, accelerometer
Location data from GPS sensor (e.g. longitude and latitude)
Identify user based on RFID tag
Read time from a clock
We acknowledge location, identity, time, and activity as important context information. The IoT paradigm needs to consider more comprehensive categorisation schemes in a hierarchical manner, such as major categories, sub categories and so on. Operational categorisation schemes allow us to understand the issues and challenges in data acquisition techniques, as well as quality and cost factors related to context. In contrast, conceptual categorisation allows an understanding of the conceptual relationships between context. We have to integrate perspective in order to model context precisely. We compare different context categorisation schemes in Table IV.
Identify opening door activity from a door sensor
Fig. 5. Context categorisation in two different perspectives: conceptual and operational. It shows why both operational and conceptual categorisation schemes are important in IoT paradigm as the capture different perspectives.
In addition to the two categorisation schemes we discussed earlier there are several other schemes introduced by different researchers focusing on different perspectives. Further, we highlight relationships between different context categories
(2011) Yanwei [103]
(2010) Rizou [101]
(1994) Schilit [79]
(1994) Schilit [79]
(2007) Chong [98]
(2009) Zhong [99]
(1999) Abowd [3]
(1997) Ryan [87]
(2011) Liu [102]
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. X, NO. X, XXXX XXXX
10
TABLE III R ELATIONSHIP B ETWEEN D IFFERENT C ONTEXT C ATEGORIES High-level (Non-Observable) Low-level (Observable) Physical (Environment)
Computing (System)
External (Physical)
Where (Location)
Conceptual
...