The iCampus prototype consists of a number of pervasive applications designed to facilitate campus users in their daily activities. The prototype is based on our iShadow architecture [1]. In the following sections, we first describe the iShadow architecture and then discuss pervasive applications built on top of it.
8.1.1 iShadow: Pervasive Computing Environment
We developed a pervasive computing environment called Intelligent Shadow (iShadow) to provide minimal but flexible system support for adaptive pervasive applications [1]. The goals of iShadow include: (1) build a smart, pervasive computing platform, which offers fundamental functions to diverse applications and (2) provide customized user experience. Users personalize the services according to their preferences, which embodies the philosophy that pervasive computing is human-centric. By utilizing the basic services provided by iShadow, the system is capable of unobtrusively tracking the user and adjusting accordingly. The name iShadow illustrates the idea that our system accompanies a user like a shadow wherever the user goes, and it offers personalized services based on user context. Specifically, iShadow concentrates on the general architecture, offering flexible, low-level support to the pervasive applications through gracefully integrating human attention with computation. The key techniques of iShadow include:
■ We design a lightweight user-shadow model to cater to context awareness and to track the user anytime, anywhere. Moreover, the user-shadow can be tailored to context and user preferences.
■ We provide a scalable, distributed resource discovery mechanism that is based on a hash structure with two synchronization methods.
■ We offer a potent context inference mechanism. iShadow employs the ontology to represent context and Bayesian networks for causal reasoning with which ontology does not cope well.
Figure 8.1 illustrates the hierarchical structure of iShadow, consisting of a devices layer, a middleware layer, and application layers. The devices layer provides a means for users to access services in pervasive computing environments. Computing devices include a PC, cell phone, and a personal digital assistant (PDA); sensor devices mainly contain devices that sense the physical environment; and network devices make sure the network is connected. These devices differ in terms of computation capability, memory, and human interface, leading to the heterogeneity in pervasive computing.
The middleware layer is crucial to iShadow and consists of resource management, user management, context awareness, message management, service management, and data management—where resource management and user management are two essential modules. We restrict the communication among middleware modules by means of a security control bus. A broad consensus of design and development has been reached from the existing architecture of the pervasive computing environment [2–5]. For instance, data management, service management, and message management are almost implemented in a parallel manner; whereas context representation using ontology is much more efficient [6,7]. We have designed the iShadow architecture similarly to the previous work. During the process, our architecture has gradually developed three distinctive characteristics: a lightweight user-shadow model in a user tracking module, scalable resource discovery in a resource discovery module, and a potent context inference mechanism in a context-awareness module.
Figure 8.1 The hierarchical structure of the iShadow environment.
The application layer of iShadow refers to various applications, relying on the services provided by the middleware layer. In a sense, any application in specific smart spaces can be rapidly prototyped by calling the lower-level service. We cooperate with international collaborators in researching key pervasive computing issues by building a smart campus, smart car, and smart office using the iShadow architecture. Note that we focus on the salient characteristics of iShadow and omit the remainder modules of iShadow that have been extensively studied in previous systems (e.g., Gaia [8], EasyLiving [9], and Aura [10]).
8.1.2 Applications in iCampus Prototype
Based on the iShadow architecture, we have developed a number of pervasive applications for a campus environment. Figure 8.2 illustrates our iCampus prototype and three scenarios: student dorm area, office area, and work area for teaching. The user can access iCampus networks by PC, PDA, cell phone, or laptop across the campus. The prototype includes various services such as a map service, photo sharing service, search service, and daily work assisting service.
■ Map service. This is deployed on our campus as an application of the campus guide. When a user visits the campus, the map service guides the user in navigating our campus. Map service varies with the user identification. If the user is a visitor to our campus, the map service will give detailed directions and provide some introductory information related to the user’s location. For the users who often go to the university, the map service just shows some scenic pictures and the routes that the users are traversing.
■ Photo sharing service. After a user takes some beautiful photos of a campus building, he is able to upload them to the photo sharing service, which facilitates the sharing of photos and the construction of a social network.
■ Search service. The abundant resources of our university cannot be indexed by commercial search engines such as Google, Yahoo, and Baidu because of the access control and other security techniques. However, school resources are valuable to both students and faculty. We implemented a small-scale search engine, which only indexes the school resources. Our search engine can search according to the user preference, such as a profession and research interest.
■ Daily work assisting service. This is an interesting service, designed to be used during a user’s work day. When approaching his office or lab, the user wakes up his PC via a handheld device, such as a PDA or cell phone. Then, his PC will check his most used e-mail box; update his subscribed morning paper; synchronize the calendar among the PDA, the PC itself, and his Google calendar; and notify the user about new e-mails and appointments. When the time to leave work is approaching, the service notifies the user of the weather or about the bus according to the real-time situation.
Figure 8.2 (a) iCampus architecture and (b) three scenarios of our campus, covering about 2,843,421 m2.
We created an intelligent shadow for each user and utilized the shadow to track the user. When a user moves into or leaves a scenario, a resource discovery module will become aware of the change in λ period and notify the system, which makes some adaptations correspondingly. We extract the user preferences and current contexts from the map service, photo sharing service, calendar information, and the user’s search behavior. Then, we use ontology or Bayesian networks to infer high-level contexts. Finally, the system will give the user recommendations or will execute actions. As a result, we hide the computing and greatly improve the user experience. Figure 8.3a through d is made up of snapshots of the map service, photo sharing service, search service, and the notification service, respectively.
Figure 8.3 The application screenshots of the iCampus prototype: (a) campus guide running at PDA; (b) campus guide running at Web; (c) school bus notification; and (d) morning paper notification.
8.2 IPSpace: An IPv6-Enabled Intelligent Space
A ubiquitous computing environment is a seamless fusion of the physical world and cyberspace, where people are able to access relevant information through any device, anytime, and anywhere in the social intelligent space. To realize this vision, a key problem to solve is how to make various types of devices, especially traditional nondigital equipment, able to connect to the pervasive space. We developed a prototype system called IPSpace, which is based on IPv6 protocol and enables traditional devices to communicate with cyberspace.
IPv6 is the next-generation network designed to replace IPv4. The 128-bit address space of IPv6 could supply an almost infinite address space and every device from mobiles to sensors could have an independent IP address. In additional, IPv6 has a stateless autoconfiguration protocol that is quite advantageous in deployment of large quantities of sensors without human intervention. However, IP connectivity is desired by WSNs but running a full-fledged IPv6 protocol is not suitable for sensors. In RFC 4944, IETF proposed 6LoWPAN [11], a first industry standard solution for IP communication in a low rate on an IEEE 802.15.4 linklayer. Specifically, 6LoWPAN is an adaptation layer between 802.15.4 and IPv6 and is used in our system for connecting various types of devices.
IPSpace faces several challenges. The first is resource management and discovery. Traditionally, applications built on sensor networks always work in a centralized architecture. Sensor devices send their data to target servers. Servers are responsible for processing these raw data and integrating them into different applications. External user requests could not reach end devices but could reach servers. With the 6LoWPAN, every device could be routed by an IP, and so a new distributed interoperation mode is introduced in the personal networks. Changing from centralized operations to a distributed mode, how to find the service provided by the device, and how to manage these distributed services are important issues.
The second challenge is security. In the MAC layer 802.15.4 [12], the symmetric key AES algorithm is used for the encryption and is often implemented in the hardware. However, differing from previous threats, in the IP-enabled LR-WPANs, every device could be reached by an external IP address so there will be new attacks on the application layer; but 6LoWPAN does not specify any end-to-end security mechanism. Moreover, due to low-power and low computation capacity characteristics, a traditional security mechanism may not work directly, and software implementation is not acceptable for these tiny devices where complex hardware implementation contradicts low power consumption.
We propose an IP-enabled service LR-WPANs scheme with 6LoWPAN protocol. Specifically, we use Web services technology to make devices work as service providers. An XML format is used to enhance interoperability among devices. Finally, a multilayer authentication mechanism is used in our scheme to provide security.
8.2.1 IPSpace Architecture Overview
Figure 8.4 depicts an overview of the IPSpace architecture. There are three layers: the device layer, the service layer, and the security layer.
The device layer contains the end device, coordinator, and service grids. There are three types of devices defined in the 802.15.4 standard—the coordinator, the reduce function device (RFD), and the full function device (FFD). The coordinator is responsible for initiating a personal area network (PAN) and working as a gateway to other networks. There is exactly one coordinator in PAN. The RFD device is implemented in low-cost losing performance to router the frame. The FFD is a device with complete stack and will often work as a router in the mesh topology. The end device is the basic element in IPSpace that has the sensor function and is responsible for collecting context information. Both the RFD and FFD devices can work as an end device. The coordinator is the initiator in PAN and has interfaces to connect to the Internet; it is a gateway router that sits between the IPv6 network and the 802.15.4-based LR-WPANs. Its calculation capability is more powerful than most end devices, and it has much more RAM space for storing routing information. In our architecture, the coordinator plays a role not only in maintaining a PAN but also in providing service registration functions for end devices to register their services with it. The coordinator, as a gateway router, will filter the external packet and ensure a reliable session between the external device and the internal device. In home use, a PC with an 802.15.4 transceiver can play the role of the coordinator as well. The coordinator is not capable of processing large quantities of service requests simultaneously. Clusters or high-performance mainframes compose service grids. Service grids establish repositories for services provided by sensors. Moreover, distributed services are integrated together to form large applications in service grids. Compared with the coordinator, service grids offer high reliability for large chunks of service requests and for user verification.
Figure 8.4 IPSpace architecture.
At the service layer, each device is a service provider in 6LoWPAN. However, different types of sensors are always in inconsistent data formats that result in poor exchangeability. XML language is a standardized and semantic data format that is platform-independent and self-described. Using XML in wireless sensor networks (WSNs) is a quite useful approach for supporting complex data management. Moreover, XML is a key element for Web services.
We use Web services technology for data exchange among devices in the service layer. With Web services, we convert a sensor function into a Web-service function, making it easy to be accessed by any Internet browsers. Considering the low-power characteristic of WSNs, running full-fledged Web services on devices is not practical. A lightweight middleware serves as an adaptation layer between Web services and the underlying communication framework. A function provided by sensors calls registration API from the middleware to notify the middleware that this function will work as a service. The middleware has a list of registered functions defined by our specified XML elements and sends these function descriptions in XML format to the coordinator when a device joins a 6LoWPAN. The coordinator will register these received function descriptions as services. The middleware of the coordinator supports translation from our specified service descriptions to Web services. The coordinator is a minimum service registration center for end devices in its domain. Service grids are centers of services from sensors. Using center management not only provides a more convenient approach for searching right services but also supports more management technologies for networks such as access control and load balancing.
In security architecture, a multilayer authentication mechanism is proposed to address the network and application layer security that is not defined by IETF. The characteristics of 6LoWPAN and sensor devices require a light and scalable authentication mechanism. Although a traditional public-key cryptosystem works well in an IP network, it is not appropriate for WSNs. We adopt a multilayer, symmetric-key cryptography mechanism that is fast for those tiny devices and requires fewer resources than a public-key cryptosystem. We also use a ticket to build a secure connection between the user and services with which the cost for verification decreases.
Figure 8.5 shows the security architecture. The gateway servers between the Internet and PAN are called service grids. They are responsible for user authentication in the security architecture. They would check whether or not a user is valid. It is likely that different end devices offer different services. SSO [13] is applied to the architecture in order to reduce password fatigue from different user name and password combinations and to reduce time spent re-entering passwords for the same user.
Figure 8.5 System security architecture.
User names and passwords should be stored in service grids’ databases by administrators in advance. To avoid eavesdropping attacks, the client performs a one-way function (hash, usually) on the entered password, and this becomes the primary key (Kp) of the user.
The client sends a plain text message with the user ID and pre-authentication data to the service grids on behalf of the user. The pre-authentication data are a timestamp encrypted by Kp. It is used to verify that the user knows the password so that he/she could be trusted as a valid user. The service grids generates the Kp by hashing the password of the user found at the database and decrypts the timestamp to check if the client is a valid user.
If service grids are responsible for the user’s state after a logon session, the service grids must keep in touch with the client. This could lead to the service grids becoming a bottleneck in the whole system. To solve this problem, a ticket called a TSSO is used to manage the user’s state. In this case, TSSO is a long-term ticket that the client keeps. After a user obtains a TSSO, he/she could directly request services. The TSSO ticket is encrypted so that the client could not know its content.
After successfully logging on to the network, the user could request services in the PAN. The session key gained from the service grids is useful here. The user tells the coordinator which service he/she would like to use and shows the TSSO. Figure 8.6 shows the authentication process.
Figure 8.6 Process of user authentication.
8.2.2 Lightweight Embedded Web Services
Web services are XML-based protocols designed for addressing the interoperability among different applications and platforms and for delivering universal access to other applications. A sensor network itself is a data-centric network that is in accordance with service architecture.
Considering that a full set of Web services implemented on tiny sensor devices will cost too much CPU time, we built a lightweight, service middleware layer to implement service communication. The middleware defines several XML elements to describe methods working as services in a concise way comparing Web services and containing a CGI function to finish the HTTP transmission. Figure 8.7 depicts the service registration process. When an end node joins a 6LoWPAN, it first communicates with the coordinator, configures its IPv6 address, and obtains the coordinator address. After the configuration, the middleware sends the registration message of services provided by the sensor device to the coordinator in the XML format. The coordinator receives the service registration message, and the middleware layer of the coordinator will translate the service description to the Web services, creating the WSDL and SOAP definitions of the service. Finally, the coordinator will acknowledge to the sensor device denoting that the registration process is finished.
Figure 8.8 describes how our service module responds to the external request. In the service registration process, the coordinator has created the WSDL to describe the service, and the external user will get the WSDL to create a remote object and send the SOAP message to request service.
When a SOAP request comes in, the Web services module receives the request and redirects it to the service middleware. The coordinator provides the middleware with a full Web services stack for translating the Web services element to our middleware elements, even though it is not supported by end devices. After the translation process finishes, the middleware sends the service request to the end devices via the coordinator. End devices receive the request and parse the service name and input parameters; then they provide the target service handler with the parameters. After obtaining the return value, the end node will send the result, wrapped by middleware, to the coordinator. The coordinator middleware decomposes the response message and sends the value to the user in SOAP.
Figure 8.7 Service registration process.
Figure 8.8 Service request process.
From a hardware perspective, current embedded sensor devices are suites that include a sensor, an MCU, and a radio transceiver. There are many bus interfaces among the chips, and sequence control is different among the chips. For the software viewer, embedded sensor devices are becoming more complex when writing programs implementing entire protocol suites, including 802.15.4, 6LoWPAN, IP stack, and so on. Fortunately, current CPU and memory power can also support a lightweight operating system. In our service solution, we choose Contiki [14] to run on the embedded devices. Contiki uses Protothreads [15], a lightweight stackless thread mechanism, to implement a multithreading function.
Compared with TinyOS [16], which is another reputable sensor operating system (OS), Protothreads does not need a stack to maintain the thread context state, which decreases the memory usage for context switching. Protothreads uses a short-type variable to store the line number it has executed, and this property makes the thread continue to run from its last point. Moreover, a short-type integer only takes 2 bytes of memory space to save context info. Multithreading is a good feature for sensor devices because it increases the throughput and CPU effective usage. Another advantage of Contiki is that it contains an adaptive communication stack for WSNs and supports 6LoWPAN and uIP [17] natively.
In our implementation, a service middleware supports the user-defined functions, working as the Web services for external requests. When programmers implement functions to fulfill requirements such as retrieving context temperature, they can focus on implementing the application logic. We provide an underlying communication framework in the service middleware, and programmers just need to write some configurations and invoke some APIs from the middleware. How to publish the function and response external requests are left to the service middleware. An example is depicted in Figure 8.9. Function getTemp is written to obtain the surrounding temperature. There is no need for the programmer to write a network packet transmission code in it because this will be done by our middleware.
To expose the getTemp function as a service, we first write a services configuration XML file to define functions that will work as the service. Programmers call the API REGISTER_SERVICE to notify the middleware about the existence of the function. After the function registration, the middleware will create a handler for this function. The middleware will create a table to store the key value of the function name and handler. When an external SOAP request arrives at the coordinator, the middleware on the coordinator translates the SOAP request to our defined service format and sends this to the end node device. When the middleware receives the request, it will extract the service name from the request and look up the table to find the right handler to respond to the request. The handler is responsible for invoking the responding function and responding to the request with the return value.
Figure 8.9 Example of middleware.
We evaluate our IPSpace service module on the testbed of Raven kits [18] produced by Atmel. Raven is an evaluation and starter kit for demonstration of 6LoWPAN applications. The Raven kits comprise two AVR Raven boards and a USB stick. All devices have a 2.4 GHz transceiver for sending and receiving a wireless signal. The two AVR Raven boards are used as RFD devices, and the USB stick connects to a computer by the USB interface. Connecting with the USB stick, the computer works as the coordinator in this 6LoWPAN network. Raven kits are constructed in a default star topology, and all data packets need to pass through the coordinator. Memory is a key constraint for tiny devices. Take the Raven board as an example Atmel 1284p, the main processor unit on the board, has a 16 KB SRAM chip memory. Implementing service onboard requires a TCP stack, and we use the uIP for decreasing memory usage.
Figure 8.10 shows the example messages used in our experiment. In Table 8.1, we show the memory usage increase in each part. The base example has a primitive getTemp function that reads the temperature. In the base example, there is no networking code so the temperature could not be sent to other devices. We use the lightweight middleware to make the getTemp function work as a service. The code is stored in the text segment and the text segment is stored in ROM (128 KB on Raven boards). The data segment and Bss segment are stored in SRAM. Compared with the base example, after translating into service, there are 881 bytes more memory usage including the data and Bss segments. The whole memory usage is 11,362 bytes less than 16 KB.
Figure 8.10 Example messages.
Table 8.1 Code Size and Memory Usage
Text (byte) |
Data (byte) |
Bss (byte) |
|
Base example |
39,866 |
1111 |
9370 |
After service translation |
44,958 |
1407 |
9955 |
Data Length (byte) |
Latency (second) |
|
Request message |
108 |
3.7 |
Registration message |
79 |
3.1 |
Table 8.2 shows the latency of the request message and the registration message from our example. The data length item is the length of the example XML message in the application layer. The latency is comprised of the MCU process time and the wireless transmission time. The latency is acceptable for most of the applications.
Urban Computing at Microsoft Research Asia
http://research.microsoft.com/en-us/projects/urbancomputing/
Urban computing acquires and analyzes large and heterogeneous data generated by a diversity of sources in urban spaces to tackle the major issues that cities face—such as air pollution, increased energy consumption, and traffic congestion.
Interaction Design Foundation: Wearable Computing
https://www.interaction-design.org/encyclopedia/wearable_computing.html
This section covers wearable computing, which is the study or practice of inventing, designing, building, or using miniature body-borne computational and sensory devices.
Gabriel: Wearable Cognitive Assistance Using Cloudlets
This project at Carnegie Mellon University introduces cloudlet as a new architectural element that arises from the convergence of mobile computing and cloud computing. This enabling technology supports new cognitive assistance applications that will seamlessly enhance a user’s ability to interact with the real world.
1. D. Zhang, H. Guan, J. Zhou, F. Tang, and M. Guo. iShadow: Yet another pervasive computing environment. In Proceedings of International Symposium on Parallel and Distributed Processing with Applications (ISPA), pp. 261–268, 2008.
2. R. Masuoka, Y. Labrou, B. Parsia, and E. Sirin. Ontology-enabled pervasive computing applications. IEEE Intelligent Systems, 18(5): 68–72, 2003.
3. D. Garlan, D. Siewiorek, A. Smailagic, and P. Steenkiste. Project aura: Toward distraction-free pervasive computing. In IEEE Pervasive Computing, pp. 22–31, 2002.
4. K. Henricksen, J. Indulska, and A. Rakotonirainy. Modeling context information in pervasive computing systems. In Proceedings of the 1st International Conference on Pervasive Computing, pp. 167–180, 2002.
5. G. Banavar and A. Bernstein. Software infrastructure and design challenges for ubiquitous computing applications. Communications of the ACM, 45(12): 92–96, 2002.
6. H. Chen, T. Finin, and A. Joshi. An ontology for context-aware pervasive computing environments. The Knowledge Engineering Review, 18(3): 197–207, 2004.
7. X. Wang, D. Zhang, T. Gu, and H. Pung. Ontology based context modeling and reasoning using OWL. PerCom Workshops, pp. 18–22, 2004.
8. M. Romań, C. K. Hess, R. Cerqueira, and A. Ranganathan. Gaia: A middleware infrastructure to enable active spaces. In IEEE Pervasive Computing, pp. 74–83, 2002.
9. B. Brumitt, B. Meyers, J. Krumm, A. Kern, and S. A. Shafer. EasyLiving: Technologies for intelligent environments. In Proceedings of 2nd International Symposium on Handheld and Ubiquitous Computing, HUC 2000, pp. 12–29, 2000.
10. J. P. Sousa and D. Garlan. Aura: An architectural framework for user mobility in ubiquitous computing environments. In Proceedings of 3rd IEEE/IFIP Conference on Software Architecture, pp. 29–43, 2002.
11. Transmission of IPv6 Packets over IEEE 802.15.4 Networks. 2007. Available from: http://www.ietf.org/rfc/rfc4944.txt, accessed on May 3, 2015.
12. IEEE standard 802.15.4-2006. Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs). 2006.
13. Dae-Hee Seo, Im-Yeong Lee, Soo-Young Chae and Choon-Soo Kim, Single sign-on authentication model using MAS (multiagent system), In Proceedings of IEEE Pacific Rim Conference on Communications, Computers and signal Processing (PACRIM), August 28–30, pp. 692–695, 2003.
14. A. Dunkels, B. Grönvall, and T. Voigt. Contiki—A lightweight and flexible operating system for tiny networked sensors. In IEEE EmNets 2004.
15. A. Dunkels, O. Schmidt, T. Voigt, and M. Ali. Protothreads: Simplifying event-driven programming of memory-constrained embedded systems. In ACM SenSys 2006.
16. TinyOS. Available from: http://www.tinyos.net/, accessed on December 20, 2009.
17. uIP. Available from: http://www.sics.se/~adam/uip/index.php/Main_Page, accessed on December 20, 2009.
18. ATAVRRZRAVEN 2.4 GHz Evaluation and Starter Kit. Available from: http://www.atmel.com/dyn/Products/tools_card.asp?tool_id=4291, accessed on December 20, 2009.